2008/7/6 Alex Lancaster <alexl@xxxxxxxxxxxxxxxxxxxxx>:
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?
>>>>> "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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
