FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-05-2008, 04:59 AM
Alex Lancaster
 
Default f-spot is orphaned: in danger of being removed from Fedora

f-spot is currently orphaned and is scheduled to be deleted if it
doesn't build from source:

https://bugzilla.redhat.com/show_bug.cgi?id=449506

One of the reasons it's currently failing to build is because of the
gnome-sharp issue detailed in this thread:

http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html

I'm working on getting this to build because it requires a new
unpackaged gnome-desktop-sharp package But in the long-term I don't
have time to be the primary maintainer, so if somebody else would like
to step up to be primary maintainer that would be great.

Alex



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-05-2008, 05:08 AM
Nigel Jones
 
Default f-spot is orphaned: in danger of being removed from Fedora

Alex Lancaster wrote:

f-spot is currently orphaned and is scheduled to be deleted if it
doesn't build from source:

https://bugzilla.redhat.com/show_bug.cgi?id=449506

One of the reasons it's currently failing to build is because of the
gnome-sharp issue detailed in this thread:

http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html

I'm working on getting this to build because it requires a new
unpackaged gnome-desktop-sharp package But in the long-term I don't
have time to be the primary maintainer, so if somebody else would like
to step up to be primary maintainer that would be great.

Actually, I'd noticed this too, I'm willing to be a primary maintainer,
and I was actually looking at getting gnome-desktop-sharp done, but if
you already have that's fine by me.


- Nigel

Alex






--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-05-2008, 05:14 AM
Alex Lancaster
 
Default f-spot is orphaned: in danger of being removed from Fedora

>>>>> "NJ" == Nigel Jones writes:

[...]

NJ> Alex Lancaster wrote:

>> I'm working on getting this to build because it requires a new
>> unpackaged gnome-desktop-sharp package But in the long-term I don't
>> have time to be the primary maintainer, so if somebody else would
>> like to step up to be primary maintainer that would be great.
>>
NJ> Actually, I'd noticed this too, I'm willing to be a primary
NJ> maintainer, and I was actually looking at getting
NJ> gnome-desktop-sharp done, but if you already have that's fine by
NJ> me.

I was only going package gnome-desktop-sharp myself as a last resort.
Actually, I would prefer just to review it if you could package it,
that would be great. I've reviewed a few mono packages but I don't
really use mono myself, so that's why I'd prefer that somebody else be
the maintainer.

Alex

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-05-2008, 04:39 PM
Scott Henson
 
Default f-spot is orphaned: in danger of being removed from Fedora

Nigel Jones wrote:

Alex Lancaster wrote:

f-spot is currently orphaned and is scheduled to be deleted if it
doesn't build from source:

https://bugzilla.redhat.com/show_bug.cgi?id=449506

One of the reasons it's currently failing to build is because of the
gnome-sharp issue detailed in this thread:

http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html

I'm working on getting this to build because it requires a new
unpackaged gnome-desktop-sharp package But in the long-term I don't
have time to be the primary maintainer, so if somebody else would like
to step up to be primary maintainer that would be great.

Actually, I'd noticed this too, I'm willing to be a primary maintainer,
and I was actually looking at getting gnome-desktop-sharp done, but if
you already have that's fine by me.




I would be willing to comaintain if you need some help.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-05-2008, 09:05 PM
Alex Lancaster
 
Default f-spot is orphaned: in danger of being removed from Fedora

>> Alex Lancaster wrote:

>> f-spot is currently orphaned and is scheduled to be deleted if it
>>> doesn't build from source:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=449506
>>>
>>> One of the reasons it's currently failing to build is because of
>>> the gnome-sharp issue detailed in this thread:
>>>
>>> http://www.redhat.com/archives/fedora-devel-list/2008-July/msg00198.html

>>> I'm working on getting this to build because it requires a new
>>> unpackaged gnome-desktop-sharp package But in the long-term I
>>> don't have time to be the primary maintainer, so if somebody else
>>> would like to step up to be primary maintainer that would be
>>> great.

SH> Nigel Jones wrote:

>> Actually, I'd noticed this too, I'm willing to be a primary
>> maintainer, and I was actually looking at getting
>> gnome-desktop-sharp done, but if you already have that's fine by
>> me.

>>>>> "SH" == Scott Henson writes:

SH> I would be willing to comaintain if you need some help.

OK, so now that gnome-desktop-sharp has been passed, it gets passed
the gtktml dependency check, but now fails due to some mono error,
which maybe just beyond my mono skills to diagnose/fix. I see a
series of error messages like the following:

error CS0136: A local variable named `result' cannot be declared in this scope because it would give a different meaning to `result', which is already used in a `method argument' scope to denote something else generated/VolumeAdapter.cs(152,72): (Location of the symbol related to previous error)
error CS0136: A local variable named `result' cannot be declared in this scope because it would give a different meaning to `result', which is already used in a `method argument' scope to denote something else generated/VolumeAdapter.cs(183,72): (Location of the symbol related to previous error)
Compilation failed: 12 error(s), 0 warnings

See this for more details:
http://koji.fedoraproject.org/koji/getfile?taskID=698211&name=build.log

http://koji.fedoraproject.org/koji/taskinfo?taskID=698211

Any help from any mono hackers out there gratefully appreciated!

Alex

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-06-2008, 12:04 AM
Kevin Kofler
 
Default f-spot is orphaned: in danger of being removed from Fedora

Alex Lancaster <alexl <at> users.sourceforge.net> writes:
> error CS0136: A local variable named `result' cannot be declared in this
> scope because it would give a different meaning to `result', which is already
> used in a `method argument' scope to denote something else
> generated/VolumeAdapter.cs(152,72): (Location of the symbol related to
> previous error)

This error message says you have a variable in an inner scope shadowing a
variable in an outer scope. This is allowed in "the programmer is always right"
type languages like C or C++, but not in "let's try to prevent common mistakes
by banning the constructs which cause them" type languages like Java or C#.
(The potential mistake in this case is of course confusing the variables with
the same name, i.e. trying to refer to the outer "result" variable and getting
the inner one instead.)

The obvious fix is of course to rename the local "result" variable to something
non-conflicting. Given that this code appears to be automatically generated,
the patch will probably have to be applied to the generator.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-06-2008, 12:35 AM
"David Nielsen"
 
Default f-spot is orphaned: in danger of being removed from Fedora

2008/7/6 Kevin Kofler <kevin.kofler@chello.at>:

Alex Lancaster <alexl <at> users.sourceforge.net> writes:

> error CS0136: A local variable named `result' cannot be declared in this

> scope because it would give a different meaning to `result', which is already

> used in a `method argument' scope to denote something else

> generated/VolumeAdapter.cs(152,72): (Location of the symbol related to

> previous error)



This error message says you have a variable in an inner scope shadowing a

variable in an outer scope. This is allowed in "the programmer is always right"

type languages like C or C++, but not in "let's try to prevent common mistakes

by banning the constructs which cause them" type languages like Java or C#.

(The potential mistake in this case is of course confusing the variables with

the same name, i.e. trying to refer to the outer "result" variable and getting

the inner one instead.)



The obvious fix is of course to rename the local "result" variable to something

non-conflicting. Given that this code appears to be automatically generated,

the patch will probably have to be applied to the generator.
The more disturbing thing, if I read the output correctly is that it happens while compiling gio-sharp.dll which definitely shouldn't be in f-spot. I haven't had time to take a stab at the offending code but it feels like it is including gnome-desktop-sharp stuff. In that case the correct fix would be making it use the system libraries.



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-06-2008, 12:40 AM
Alex Lancaster
 
Default f-spot is orphaned: in danger of being removed from Fedora

>>>>> "KK" == Kevin Kofler writes:

KK> Alex Lancaster <alexl <at> users.sourceforge.net> writes:
>> error CS0136: A local variable named `result' cannot be declared in
>> this scope because it would give a different meaning to `result',
>> which is already used in a `method argument' scope to denote
>> something else generated/VolumeAdapter.cs(152,72): (Location of the
>> symbol related to previous error)

KK> This error message says you have a variable in an inner scope
KK> shadowing a variable in an outer scope. This is allowed in "the
KK> programmer is always right" type languages like C or C++, but not
KK> in "let's try to prevent common mistakes by banning the constructs
KK> which cause them" type languages like Java or C#. (The potential
KK> mistake in this case is of course confusing the variables with the
KK> same name, i.e. trying to refer to the outer "result" variable and
KK> getting the inner one instead.)

KK> The obvious fix is of course to rename the local "result" variable
KK> to something non-conflicting. Given that this code appears to be
KK> automatically generated, the patch will probably have to be
KK> applied to the generator.

OK, thanks for the explanation, but my mono skills are weak to
non-existent so I'm not about to go try patching the
generator... hopefully somebody else will jump in.

The next question is why did this appear now and not in previous
releases of f-spot/mono? What changed? Is the version of mono now in
rawhide more picky or did f-spot introduce an error? I suspect that
f-spot 0.4.4 introduced an error because this didn't occur with the
previous version of f-spot: 0.4.3, but it's odd that it hasn't come up
on the f-spot mailing list and several people have been building from
source there. I'll take it up on the f-spot list/IRC channel, but if
anybody knows anything more about f-spot please let me know.

Alex

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-06-2008, 12:51 AM
Alex Lancaster
 
Default f-spot is orphaned: in danger of being removed from Fedora

>>>>> "DN" == David Nielsen writes:

[...]

DN> The more disturbing thing, if I read the output correctly is that
DN> it happens while compiling gio-sharp.dll which definitely
DN> shouldn't be in f-spot. I haven't had time to take a stab at the
DN> offending code but it feels like it is including
DN> gnome-desktop-sharp stuff. In that case the correct fix would be
DN> making it use the system libraries.

This is an ongoing issue with f-spot, I had tracked down a number of
these issues previously and with some help from the Debian maintainer
had patched them to use system libraries, but perhaps f-spot has gone
and done it again. See:

https://bugzilla.redhat.com/show_bug.cgi?id=442343

Although I did notice that the configure script does check for the
presence of gnome-desktop-sharp, the absence of which was causing the
builds to originally fail. The question is if it tries to detect it,
why doesn't it use it?

Alex

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-06-2008, 03:08 AM
"David Nielsen"
 
Default f-spot is orphaned: in danger of being removed from Fedora

2008/7/6 Alex Lancaster <alexl@users.sourceforge.net>:

>>>>> "DN" == David Nielsen *writes:



[...]



DN> The more disturbing thing, if I read the output correctly is that

DN> it happens while compiling gio-sharp.dll which definitely

DN> shouldn't be in f-spot. I haven't had time to take a stab at the

DN> offending code but it feels like it is including

DN> gnome-desktop-sharp stuff. In that case the correct fix would be

DN> making it use the system libraries.



This is an ongoing issue with f-spot, I had tracked down a number of

these issues previously and with some help from the Debian maintainer

had patched them to use system libraries, but perhaps f-spot has gone

and done it again. *See:



https://bugzilla.redhat.com/show_bug.cgi?id=442343



Although I did notice that the configure script does check for the

presence of gnome-desktop-sharp, the absence of which was causing the

builds to originally fail. *The question is if it tries to detect it,

why doesn't it use it?
The programmer works in mysterious ways, most likely if this is the cause it is code added in the interim between now and when distributions have packages available. If you need the functionality, often the desire to wait for a package or a tarball release is low as it can set you back months for no good reason. At least it does not seem that they are using a pre compiled binary this time which is a step in the right direction. I think we should see it as a sign to be more proactive about getting support libraries into Fedora and keeping them updated.. I suspect though that repeating this will, once again, fall on deaf ears.


Now back to the desire to create a Mono SIG, this would alliviate the problem for Mono packages a little. Currently I ping pong a bit with Paul to get new Mono libraries into Fedora but Paul unfortunately has a tendency to disappear for months at the time due to real world constraints (pesky real life). E.g. he currently has the dependencies (3 packages) that would allow us to ship MonoDevelop 1.0 in review but has let them sit for 2 months without providing updates to pending comments. Having more hands would definitely help both him and Fedora as a whole, and a more coordinated approach to our Mono stack wouldn't hurt either.


So consider this a call to arms. We need a clear agenda, there is still much great Mono software not in Fedora. What we have is maintained by very few people, leaving us with problems relating to maintainer burnout or outright disappearance. We clearly have problems staying current and ensuring that downstream has access to the libraries they need, nor do we have a process which can be used to streamline the introduction of said software (and just look at how fast we can be when we want to, gnome-desktop-sharp was in Fedora within a day). The packaging guidelines probably need a review as well, surely there is room for improvement.


So who is with me?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org