The ebuild does not pull in yasm, and the build subsequently fails. build.log attached. This is probably related to various packages recently being removed from the @system set.
Created attachment 283363 [details] build.log
Created attachment 283365 [details] emerge --info
Yeah, thanks. Noticed also we are missing a lot of deps as a consequence of not using system ffmpeg/libav, so many of the build deps of ffmpeg/libav too, though only a few because the bundled libav is not built with any external codec libraries usages, because there are for most of those separate dedicated gstreamer plugins. Yasm is needed for some MMX optimized code building iirc. The current plan is to fix this by doing the necessary things gst-ffmpeg upstream to have system libav a more supported configuration and then use the system packages instead of bundled in Gentoo. The upstream work involves reporting the runtime version of libav in the plugin description, as shown by e.g "gst-inspect-0.10 --plugin ffmpeg |grep Description". Currently it tells it's "local snapshot" when using bundled and something like "system snapshot" if system version, but need to add the runtime version of the system libav to there, so that upstream knows when it's a newer version than tested or so.
*** Bug 379525 has been marked as a duplicate of this bug. ***
Is there a bug upstream for this? If so could it be referenced in this bz?
Ok so if upstream is going to be the fix, why not just make a new ebuild NOW so that those of us installing new systems don't wonder "why the bloody hell is NASM trying to be called instead of YASM and failing" I don't know how long its going to take for upstream to care about making libav work right. What I *do* know is that for emerging a new system that wants to pull in gstreamer with ffmpeg, it stops the works up because libav isn't a system installed package yet. I also know that this fix took me 1 minute to do once I realized the simple error. --- /usr/portage/media-plugins/gst-plugins-ffmpeg/gst-plugins-ffmpeg-0.10.12.ebuild 2011-10-21 11:25:32.000000000 -0400 +++ gst-plugins-ffmpeg-0.10.12.ebuild 2011-10-25 13:32:01.511642226 -0400 @@ -27,7 +27,8 @@ RDEPEND=">=media-libs/gstreamer-0.10.31 >=media-libs/gst-plugins-base-0.10.31 - orc? ( >=dev-lang/orc-0.4.6 )" + orc? ( >=dev-lang/orc-0.4.6 ) + dev-lang/yasm" DEPEND="${RDEPEND} dev-util/pkgconfig"
Err that should have been depend, not rdepend. Its too early still. --- /usr/portage/media-plugins/gst-plugins-ffmpeg/gst-plugins-ffmpeg-0.10.12.ebuild 2011-10-21 11:25:32.000000000 -0400 +++ gst-plugins-ffmpeg-0.10.12.ebuild 2011-10-25 13:37:20.148658550 -0400 @@ -29,7 +29,8 @@ >=media-libs/gst-plugins-base-0.10.31 orc? ( >=dev-lang/orc-0.4.6 )" DEPEND="${RDEPEND} - dev-util/pkgconfig" + dev-util/pkgconfig + dev-lang/yasm" src_compile() { append-flags -fno-strict-aliasing
Created attachment 290815 [details, diff] Simple patch to make it work and stop weird errors until upstream fixes whatever needs to be done with libav
Simple workaround if you're pulling in the gnome meta package. Leave your profile set to the default when emerging. This won't pull in the plugins, but does pull in the dependency. Then switch to the gnome profile and emerge again! Hika
Hey, masters! Now is 2012 year, but this bug "online". Are your know about this nuance?
What is holding this up? Is there something holding this up, or is it really just a single missing dependency?
There are probably many things that should be done if we keep using bundled libav. Not just a USE=mmx yasm dep, but probably a lot more. The idea was to make the work needed to use system libav instead, but that somehow got out of my attention for a while and wasn't done. I'll add the deps or make it use system libav after I have done the version bumps of the next big releases of the rest of gstreamer stack. Help welcome in the system libav library usage, what's needed seems to be described in comment #3 already.
Not to be rude but until the next versions are bumpbed, gst-plugins-ffmpeg continues to fail unless someone unwittingly installs yasm first or blunders across this bug report... :-)
not needed anymore with gst-plugins-ffmpeg-0.10.13_p201211 since it uses system ffmpeg
