The new all-c libmusepack 1.1, although slotted, overwrites some of the older includes. Which is fine for the new xmms and bmp plugins, but kills gst-plugins-musepack-0.8.7 which is still not updated. I guess gst devel team might switch soon, but until then libmusepack-1.1 should at least block the gst plugin. Reproducible: Always Steps to Reproduce: 1. emerge =libmusepack-1.1 2. emerge gst-plugins-musepack Actual Results: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gst-libs -I../../gst-libs -D_LARGEFILE_SOURCE -D_FILE_OFFS ET_BITS=64 -pthread -I/usr/include/gstreamer-0.8 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxm l2 -DGST_DISABLE_DEPRECATED -Wall -O2 -march=athlon-xp -fomit-frame-pointer -pipe -MT libgstmusepack_la-gstmusepackdec.lo -MD -MP -MF .deps/libgstmusepack_la-gstmusepackdec.Tpo -c gstmusepackdec.cpp -fPIC -DPIC -o .libs/libgstmusepack_la-gst musepackdec.o gstmusepackdec.cpp: In function `gboolean gst_musepack_stream_init(GstMusepackDec*)': gstmusepackdec.cpp:364: error: variable `StreamInfo si' has initializer but incomplete type gstmusepackdec.cpp:364: error: invalid use of undefined type `struct StreamInfo' /usr/include/musepack/mpc_dec.h:26: error: forward declaration of `struct StreamInfo' gstmusepackdec.cpp:371: error: `ERROR_CODE_OK' undeclared (first use this function) gstmusepackdec.cpp:371: error: (Each undeclared identifier is reported only once for each function it appears in.)
noddy: No need to block anything. The dependency needs to be changed.
if it's abi incompatible (which is likely), then it is a reasonable step to block everything that uses it (i bet other libmpc based plugins will exhibit the same problems). If libmusepack is slotted & overwrites its own includes (of the earlier 1.0 slot), then that is a bug & should be fixed asap.
Created attachment 50336 [details, diff] gst-plugins libmusepack 1.1 patch this has been fixed in gst-plugins CVS a few days ago: http://bugzilla.gnome.org/show_bug.cgi?id=165446 I've got a modified ebuild who applies the patches, but it's ugly, because some files must be renamed too (ext/musepack/*cpp --> .c) and I'm not so good with patch and sed... but now everything works.
>if it's abi incompatible (which is likely), then it is a reasonable step to block everything that uses it Why? It just shouldn't go stable as long as depending stuff breaks and can't be marked stable as well. Who runs ~arch deserves what he get and can it mask locally, imho. :)
Nononono, that's "masked". "Known-broken" is somehow canonically related to "masked". "Known-broken" simply... err, _transcends_ the notion of "unstable" ;) I think it should be blocked instead of doing an ugly solution -- and even instead of fixing libmusepack slotting -- simply because it's a transient problem, to be gone in the next release of gst-plugins. Since AFAIK the gst plugin is the last package in portage dependant on the old library, that's actually the elegant solution ATM.
~arch is not meant to be broken lightly. Yes it is testing, but not for 'known broken' stuff. Anyway, people don't run straight ~arch or non-~arch systems and do whatever you can imagine to their sys, adding a couple of safeguards if possible is not a bad idea. Anyway, I'm more concerned about the slotting, if what is said is true (both slots occupying the same space), this should be fixed NOW, not later.
*** Bug 82602 has been marked as a duplicate of this bug. ***
all of these issues have been taken care of.
