> Well, there is still gnomebaker that is in fe4. If we remove it we'll > break updates. Or is a solution for it in sight? Am i talking about gnomebaker? No. Does gnomebaker use gstreamer08-python in Extras and thus will be affected by the 64bit related packaging problems associated with that package which can only be resolved after gst08 and gst08-plugins gets into Extras? No. Do i know anything about the specific gstreamer elements that gnomebaker requires and whether they have been ported to gst 0.10 yet or not? No. I have no idea where upstream gnomebaker development is in terms of transitioning to gst 0.10 so I can not answer as to whether gnomebaker in extras-development can be successfully patched to use gst 0.10 without loss of functionality. I think transitioning to gst 0.10 asap would be more worthwhile for gnomebaker instead of working on gst08 deployment in Extras if the currently available gst 0.10 in core-development has the necessary plugin functionality. But since I have not seen the maintainer of gnomebaker in Extras express interest in trying to patch in a transition to gst 0.10, I haven't spent any time on it. If he'd rather work out the gst08 dep issues instead of figuring out how gnomebaker can be transitioned to use gst 0.10 via some patches.. that's his decision. And from the brief discussion i had over the weekend, ignacio had started an informal review of gst08 and there was some question about whether rpaths are a blocker for Extras packages or not since the default rpmlint doesn't include the check. What I do know is that istanbul can not be transitioned yet because of specific missing functionality. Okay that's sort of a lie. I could most likely transition the istanbul package to gst 0.10 right now... and the resulting shipped application would be garunteed not to work because of missing gst element support for the screencapture element. That's the fun thing about gstreamer being plugin based. I can very well release an istanbul package that provides no useful functionality and get it through the build system barring any weird arch specific packaging problems in the dependancy chain. I'd be tempted to do exactly that if there was an fc4 istanbul package available and i needed to preserve the upgrade path and just leave a bug report open detailing the problem... but i dont have an upgrade path to worry about. What I do know is that the specific gstreamer element functionality istanbul requires to function, according to the upstreamer developer of istanbul, is not present in the currently available gst 0.10 release in core development. I can't tell you what prevents gnomebaker from being patched to transition to gst 0.10, if anything at all is in fact preventing it other than the manhours to do it. Sadly the sf.net sites aren't behaving right now so I can not pull the upstream gnomebaker source and look at what its using from the available gstreamer functionality. -jef -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
