Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS
Hi, On Sat, Dec 31, 2005, Josh Triplett wrote: The attached patch (also temporarily available at http://psas.pdx.edu/~josh/gstreamer along with a pre-built deb) implements support for the spc plugin in EXTRA_PLUGINS. Note that after applying the patch, you need to re-run ./autogen.sh --noconfigure, since the patch fixes a bug in configure.ac which led to HAVE_CPU_I386 and the other CPU variables not being set. To build the SPC plugin, just add spc to EXTRA_PLUGINS in debian/rules, run debian/rules maint, and then build the package. The preferred solution would be to always build the spc plugin, rather than only via EXTRA_PLUGINS; however, this patch at least makes it relatively easy to create a gstreamer0.8-spc deb. FYI, SPC received criticism that it should be built against libspc, and that it might be non-free, hence I didn't include it in the first place. Now it is unmaintained. It is absent from the packages that are acceptable in the 0.10 series. If you fixed configure.ac by: -GST_DOC() +GST_DOCBOOK_CHECK() Then this might be worthwhile to send upstream, could you explain how it break things to call GST_DOC instead of GST_DOCBOOK_CHECK? I certainly see it is wrong, but I had no problem with it until now. (I've reported that upstream.) Bye, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS
Hi, On Sun, Jan 08, 2006, Josh Triplett wrote: Using a library is a certainly a reasonable idea; two questions: 1) Do you mean libspc (which I haven't heard of and can't seem to find) or libopenspc? I meant libopenspc indeed. 2) Anti Resonance's SPC emulator is generally considered the most technically superior, both on the grounds of faithful reproduction and possible enhancement; given that Anti Resonance's code and libopenspc are equally non-portable, I don't think it's worth moving to a library unless that library gives some other advantage. It seems reasonable to build against a shared library to ease security upgrades. That's a more serious concern; however, the code appears to be Freely licensed by upstream. Can you point to any particular issue or concern you have, or that you've seen raised previously? No, I walked through the 0.8 bugs looking for things possibly obsolete in 0.10, and wanted to give you some feedback on the discussions I recall about that plugin. This was both on IRC and in the mailing-lists IIRC. I did notice that spc didn't seem to be present in 0.10. I think this is due to stricter policy upstream: plugin have to be maintained actively by one person and blessed by some gstreamer hacker. I think SPC lacks the active maintenance right now. If you fixed configure.ac by: -GST_DOC() +GST_DOCBOOK_CHECK() Then this might be worthwhile to send upstream, could you explain how it break things to call GST_DOC instead of GST_DOCBOOK_CHECK? I certainly see it is wrong, but I had no problem with it until now. I think it has already been fixed upstream, in newer versions than the one currently in Debian. The issue is that GST_DOC was renamed to GST_DOCBOOK_CHECK, but configure.ac wasn't updated accordingly. This caused the immediately subsequent code to fail, which happened to be the code which checked the target CPU to determine which arch-specific code was acceptable; since SPC needs those target CPU variables set, it fails unless this issue is fixed. Ok, I saw the rename in 0.10, but I only saw the GST_DOC() call in configure today. I'm likely to reupload a package to address that. Might it be possible to include this EXTRA_PLUGINS support until spc can be sufficiently fixed to be more suitable for building by default? It would make enhancing and testing gstreamer0.8-spc significantly easier. That I've done in -4, but you replied faster than I uploaded. :-P Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS
Loïc Minier wrote: On Sat, Dec 31, 2005, Josh Triplett wrote: The attached patch (also temporarily available at http://psas.pdx.edu/~josh/gstreamer along with a pre-built deb) implements support for the spc plugin in EXTRA_PLUGINS. Note that after applying the patch, you need to re-run ./autogen.sh --noconfigure, since the patch fixes a bug in configure.ac which led to HAVE_CPU_I386 and the other CPU variables not being set. To build the SPC plugin, just add spc to EXTRA_PLUGINS in debian/rules, run debian/rules maint, and then build the package. The preferred solution would be to always build the spc plugin, rather than only via EXTRA_PLUGINS; however, this patch at least makes it relatively easy to create a gstreamer0.8-spc deb. FYI, SPC received criticism that it should be built against libspc, Using a library is a certainly a reasonable idea; two questions: 1) Do you mean libspc (which I haven't heard of and can't seem to find) or libopenspc? 2) Anti Resonance's SPC emulator is generally considered the most technically superior, both on the grounds of faithful reproduction and possible enhancement; given that Anti Resonance's code and libopenspc are equally non-portable, I don't think it's worth moving to a library unless that library gives some other advantage. and that it might be non-free, That's a more serious concern; however, the code appears to be Freely licensed by upstream. Can you point to any particular issue or concern you have, or that you've seen raised previously? hence I didn't include it in the first place. Now it is unmaintained. It is absent from the packages that are acceptable in the 0.10 series. I did notice that spc didn't seem to be present in 0.10. The biggest problem with the spc plugin at the moment is that it does not read the length information out of the SPC ID666 tag, and thus doesn't know when to stop playing an SPC, so it plays forever until stopped. This needs to be fixed for the SPC plugin to be usable. Other than that one issue (which should be easy to fix for someone who understands gstreamer plugins enough to know how to say when the audio stops; reading out the length field is trivial), the SPC plugin seems like a reasonable item to include. If you fixed configure.ac by: -GST_DOC() +GST_DOCBOOK_CHECK() Then this might be worthwhile to send upstream, could you explain how it break things to call GST_DOC instead of GST_DOCBOOK_CHECK? I certainly see it is wrong, but I had no problem with it until now. I think it has already been fixed upstream, in newer versions than the one currently in Debian. The issue is that GST_DOC was renamed to GST_DOCBOOK_CHECK, but configure.ac wasn't updated accordingly. This caused the immediately subsequent code to fail, which happened to be the code which checked the target CPU to determine which arch-specific code was acceptable; since SPC needs those target CPU variables set, it fails unless this issue is fixed. Might it be possible to include this EXTRA_PLUGINS support until spc can be sufficiently fixed to be more suitable for building by default? It would make enhancing and testing gstreamer0.8-spc significantly easier. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS
Loïc Minier wrote: On Sun, Jan 08, 2006, Josh Triplett wrote: 2) Anti Resonance's SPC emulator is generally considered the most technically superior, both on the grounds of faithful reproduction and possible enhancement; given that Anti Resonance's code and libopenspc are equally non-portable, I don't think it's worth moving to a library unless that library gives some other advantage. It seems reasonable to build against a shared library to ease security upgrades. That does indeed seem like some other advantage. :) That's a more serious concern; however, the code appears to be Freely licensed by upstream. Can you point to any particular issue or concern you have, or that you've seen raised previously? No, I walked through the 0.8 bugs looking for things possibly obsolete in 0.10, and wanted to give you some feedback on the discussions I recall about that plugin. This was both on IRC and in the mailing-lists IIRC. OK. Well, in the absence of someone pointing to some part of the code that is non-free, I'm inclined to believe the Free licensing put in place by upstream, for now. I did notice that spc didn't seem to be present in 0.10. I think this is due to stricter policy upstream: plugin have to be maintained actively by one person and blessed by some gstreamer hacker. I think SPC lacks the active maintenance right now. Ah, I see. Does that include the -bad and -ugly sets of plugins? If you fixed configure.ac by: -GST_DOC() +GST_DOCBOOK_CHECK() Then this might be worthwhile to send upstream, could you explain how it break things to call GST_DOC instead of GST_DOCBOOK_CHECK? I certainly see it is wrong, but I had no problem with it until now. I think it has already been fixed upstream, in newer versions than the one currently in Debian. The issue is that GST_DOC was renamed to GST_DOCBOOK_CHECK, but configure.ac wasn't updated accordingly. This caused the immediately subsequent code to fail, which happened to be the code which checked the target CPU to determine which arch-specific code was acceptable; since SPC needs those target CPU variables set, it fails unless this issue is fixed. Ok, I saw the rename in 0.10, but I only saw the GST_DOC() call in configure today. I'm likely to reupload a package to address that. Cool. Might it be possible to include this EXTRA_PLUGINS support until spc can be sufficiently fixed to be more suitable for building by default? It would make enhancing and testing gstreamer0.8-spc significantly easier. That I've done in -4, but you replied faster than I uploaded. :-P Thanks! - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS
On Sun, Jan 08, 2006, Josh Triplett wrote: I think this is due to stricter policy upstream: plugin have to be maintained actively by one person and blessed by some gstreamer hacker. I think SPC lacks the active maintenance right now. Ah, I see. Does that include the -bad and -ugly sets of plugins? Well, I think plugins not satisfying this criteria are moved to -bad, which I won't upload for Debian. Fixing this can promote the plugin to other modules. Bye, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS
Package: gst-plugins0.8 Version: 0.8.11-3 Tags: patch The attached patch (also temporarily available at http://psas.pdx.edu/~josh/gstreamer along with a pre-built deb) implements support for the spc plugin in EXTRA_PLUGINS. Note that after applying the patch, you need to re-run ./autogen.sh --noconfigure, since the patch fixes a bug in configure.ac which led to HAVE_CPU_I386 and the other CPU variables not being set. To build the SPC plugin, just add spc to EXTRA_PLUGINS in debian/rules, run debian/rules maint, and then build the package. The preferred solution would be to always build the spc plugin, rather than only via EXTRA_PLUGINS; however, this patch at least makes it relatively easy to create a gstreamer0.8-spc deb. - Josh Triplett signature.asc Description: OpenPGP digital signature
