I have some patches for the gstreamer-related ebuilds. gstreamer-0.6.4.ebuild can be copied directly to gstreamer-0.7.1.ebuild and work. gst-plugins-0.6.4.ebuild needs a patch to remove an epatch line that refers to a patch that doesn't exist for 0.7.1. I also removed the noppcasm.patch but can't test that change. The gst-plugins eclass needs a patch to add some extra plugins that 0.7.1 defines. At the moment, gst-plugins-oss isn't compiling, but I haven't fixed it yet. Reproducible: Always Steps to Reproduce:
Created attachment 20673 [details, diff] /gst-plugins-0.7.1.ebuild.patch Good job with making the ebuilds version-agnostic. This patch removes both patches. Someone with a ppc needs to test whether that's a good idea.
Created attachment 20674 [details, diff] gst-plugins.eclass.patch This adds the new plugins to the my_gst_plugins list.
Created attachment 20700 [details] gst-plugins-0.7.1.ebuild Both src_compile in the ebuild and gst-plugins_src_configure in the gst-plugins eclass called elibtoolize. Before I removed elibtoolize from the ebuild, none of the libraries installed had a .so extension. After removing it, they do. Strange.
Created attachment 20715 [details] gst-plugins-oss-0.7.1.ebuild This is a hack to allow gst-plugins-oss to build. The sys/oss Makefile depends on $(top_builddir)/gst-libs/gst/mixer/libgstmixer.la, which doesn't get built under the gst-plugins.eclass. So my ebuild makes the gst-libs/gst/mixer directory before the src/oss directory. This means it won't work with the patch in bug #32696
I was able to install gstreamer-0.7.1.ebuild ok by copying over gstreamer-0.6.4.ebuild. I then put attachemnts 20700 and 20715 in the appropriate directories in /usr/local/portage, and tried to emerge gst-plugins-0.7.1. I eventually got this error: Making all in xvid make[3]: Entering directory `/var/tmp/portage/gst-plugins-0.7.1/work/gst-plugins-0.7.1/ext/xvid' if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gst-libs -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -I/usr/include/gstreamer-0.7 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DGST_DISABLE_DEPRECATED -Wall -march=athlon-xp -O2 -pipe -MT libgstxvid_la-gstxvidenc.lo -MD -MP -MF ".deps/libgstxvid_la-gstxvidenc.Tpo" \ -c -o libgstxvid_la-gstxvidenc.lo `test -f 'gstxvidenc.c' || echo './'`gstxvidenc.c; \ then mv -f ".deps/libgstxvid_la-gstxvidenc.Tpo" ".deps/libgstxvid_la-gstxvidenc.Plo"; \ else rm -f ".deps/libgstxvid_la-gstxvidenc.Tpo"; exit 1; \ fi mkdir .libs rm: cannot remove `': Invalid argument gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gst-libs -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -I/usr/include/gstreamer-0.7 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DGST_DISABLE_DEPRECATED -Wall -march=athlon-xp -O2 -pipe -MT libgstxvid_la-gstxvidenc.lo -MD -MP -MF .deps/libgstxvid_la-gstxvidenc.Tpo -c gstxvidenc.c -fPIC -DPIC -o .libs/libgstxvid_la-gstxvidenc.o In file included from gstxvidenc.c:28: gstxvidenc.h:24:21: gstxvid.h: No such file or directory gstxvidenc.c: In function `gst_xvidenc_class_init': gstxvidenc.c:151: warning: implicit declaration of function `gst_xvid_init' gstxvidenc.c: In function `gst_xvidenc_setup': gstxvidenc.c:242: warning: implicit declaration of function `gst_xvid_error' make[3]: *** [libgstxvid_la-gstxvidenc.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/gst-plugins-0.7.1/work/gst-plugins-0.7.1/ext/xvid' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gst-plugins-0.7.1/work/gst-plugins-0.7.1/ext' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gst-plugins-0.7.1/work/gst-plugins-0.7.1' make: *** [all] Error 2
Mason, your problem is fixed by attachment 20674 [details, diff], which is a patch to the gst-plugins eclass.
The spider element (maybe all autoplugging) seems not to work with my ebuilds. This looks like a gstreamer problem rather than an ebuild problem. I have also been informed that 0.7.1 is b0rked. So I'm going to write a cvs ebuild instead. I think the right way to do this is to make gst*-cvs ebuilds, but if anyone has a better idea, I'm open to suggestions.
Ok, using that patch I was able to build gst-plugins and then gst-plugins-oss, gst-plugins-gnomevfs, and gst-plugins-vorbis. Using gst-launch works ok to play a .ogg file using osssink. I am going to try compiling rhythmbox-0.6 now and see if that works.
Installed rhythmbox-0.6 and it picked up gstreamer-0.7 and is using. Playback is working fine. I've tested various combinations of gst-launch-0.7 with different types of files and they all have worked ok, including using the spider element. For both rhythmbox and the various gst-plugins, I've merely copied over the 0.6.4 ebuild and they have worked great (after the gst-plugins eclass patch :) ).
Created attachment 20738 [details] gstreamer-cvs-0.7.2.ebuild gstreamer downloaded from CVS HEAD. The version number is pretty arbitrary, but it does need to be 0.7.x so the programs are installed with the right suffix.
Created attachment 20739 [details] gst-plugins-cvs-0.7.2.ebuild gst-plugins downloaded from CVS HEAD. There's also yet another plugin added to the plugin list.
Created attachment 20740 [details] gst-plugins-cvs.eclass This eclass gets the gst-plugins-* from CVS HEAD. Most gst-plugins-* ebuilds can be converted to gst-plugins-cvs-* just by changing their inherit line to refer to this eclass instead of gst-plugins. Correction to last attachment's comment: the new plugin was added here.
Created attachment 20741 [details] gst-plugins-oss-cvs-0.7.2.ebuild gst-plugins-oss now refers to something in the gst-libs/gst directory, so this ebuild builds all of that in addition to the plugin itself. It's probably possible to prune this some, but running autogen.sh and configure take most of the time anyway so I didn't bother.
When the gst-plugins-* ebuilds seem to hang when running automake, they actually haven't. It just takes a very long time to run. You can make gst-plugins-<plugin>-cvs ebuilds just by copying the non-cvs ebuild and changing the inherit line to point to the gst-plugins-cvs eclass. The cvs ebuilds play music fine using gst-launch, gnome-vfs, and spider. Rhythmbox 0.7 almost-head also works.
this is nice for a local tree, but 0.7 series are development series. They cannot go in the portage tree because they're unstable and most gst using apps don't work guaranteed well with these series. Not to start about the cvs stuff. Afaic i don't even bother with creating all loose plugin ebuilds for the 0.7 series in my local tree, it's too much work. Just use the gst-plugins ebuilds as they were before we split the plugins up for your local experimenting pleasure. I'd suggest a local binary tree for experimenting with the 0.7 series cvs and just use a real cvs checkout, not ebuilds. Thats much easier for developing at least.
foser: I actually made the ebuilds to help with rhythmbox 0.7 development. So I'm not all that interested in modifiying the gstreamer code, but we do need the CVS since rhythmbox doesn't work with 0.7.1, and ebuilds make it easy to uninstall later. I don't mind if these ebuilds never make it into the main tree, but is it all right to use this bug as a well-known place to put the gstreamer ebuilds needed for rhythmbox development?
