reassign 421167 gstreamer0.10 thanks Am Donnerstag, den 26.04.2007, 20:09 -0700 schrieb Joe Wreschnig: > On Thu, 2007-04-26 at 23:21 +0200, Martin wrote: > > Package: quodlibet > > Version: 0.23.1-1 > > Severity: grave > > Justification: renders package unusable > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Quod Libet fails to start, pops up a message saying "Quod Libet could > > not find the 'filesrc' GStreamer element. Check your GStreamer > > installation." It used to work fine before/during the freeze. > > ... > > Versions of packages quodlibet recommends: > > ii gstreamer0.10-alsa 0.10.12-2 GStreamer plugin for ALSA > > pn gstreamer0.10-gnomevfs <none> (no description available) > > ^-- This would be why. In 0.10.10 and all previous versions, a filesrc > object would be returned: > > >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") > <__main__.GstFileSrc object () at 0x402076bc> > > Now, in unstable: > >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") > <__main__.GstGnomeVFSSrc object () at 0xb7d6393c> > > And if I remove gstreamer0.10-gnomevfs: > >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") > >>> > > So, filesrc is in fact broken. > > Blah blah API compatibility, blah blah you need unit tests, blah blah, > no one listens to me, blah STOP BREAKING MY SOFTWARE DAMNIT. > > The GStreamer changelog says: > > 2007-02-13 Sebastian Dröge <[EMAIL PROTECTED]> > > * plugins/elements/gstfilesink.c: (gst_file_sink_uri_set_uri): > * plugins/elements/gstfilesrc.c: (gst_file_src_uri_set_uri): > Also check for an absolute path following file:// in the filesrc > element. Remove redundant check and call g_path_is_absolute() on the > unescaped location. > > Sebastian, do you understand what an API is, and why changes like that > ARE NOT ALLOWED, especially in point releases?
Sure, this was just to break the software of Joe Wreschnig. Could you please calm down so we can talk about how to get this fixed properly? Thanks First lets get this change in the correct context, this is only a continuation of another change by Sébastien Moutte: > 2007-02-10 Sébastien Moutte <[EMAIL PROTECTED]> > * plugins/elements/gstfilesrc.c:(gst_file_src_uri_set_uri): > Fix a bug on Windows in uri format check. Now the prefix checked > is file:// and next we check if the path after file:// is absolute. which OTOH is a fix needed for my first change in that direction: > 2007-02-02 Sebastian Dröge <[EMAIL PROTECTED]> > > reviewed by: Wim Taymans <[EMAIL PROTECTED]> > > * plugins/elements/gstfilesink.c: (gst_file_sink_uri_set_uri): > * plugins/elements/gstfilesrc.c: (gst_file_src_uri_set_uri): > Allow file://localhost/foo/bar URLs and correctly fail for every other > hostname that one sets. This was gnomevfssrc is linked for those if > installed as it can handle it (#403172) As you can see this change wasn't only decided by me and it also wasn't intentional that it breaks things in that way. Also please read the corresponding upstream bugreport. I agree that the fix for this bug was not at all complete and this special case should be handled too. Is "file://" the only URL that causes a problem for you or is quodlibet using "file://blabla/bla" in general? (note that there are only two slashes after the colon) "file://" is not a valid URI, it's only the protocol part of some URI. Then according to rfc1738 "file://blabla/bla" corresponds to the location "/bla" on the host "blabla". Then, if quodlibet wants to check for the element "filesrc" it should just check if it can create a "filesrc" element and not check if there is some random element that might support the "file://" protocol. Apart from that, would you be fine if I just special case "file://" and allow that as a valid URI for filesrc as a workaround for this? "file://blabla/bla" would still not be handled and this could be argued as an API change too. Not that using an "file://blabla/bla" URI worked before but you could at least set it on the element and the same applies for "file://" too btw.... I talked with Wim about this on IRC now and he also has the opinion that a) file:// is simply not a valid URI but b) that this needs to be fixed by special casing the file:// URI for API stability reasons only. I'll change that in CVS for now and also upload a new gstreamer0.10 package with that change. If there's still an issue then please first calm down and then file a bug against the relevant package. Bye PS: For better checking if an URI protocol is support by any element I'll also add a gst_uri_protocol_is_supported() function later btw...
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
