After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 340762 - faad2 RPM packages incompatible
faad2 RPM packages incompatible
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-05 17:52 UTC by Eric Bair
Modified: 2006-05-11 20:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Eric Bair 2006-05-05 17:52:01 UTC
I upgraded my gstreamer-plugins-bad package this morning, and when I did so, I lost my ability to import or play m4a files in rhythmbox.  When I tried to import a set of m4a files into rhythmbox, I got the following message:

Internal GStreamer problem; file a bug

I imported a set of m4a files last night (before updating gstreamer-plugins-bad), and it worked without a problem.

For what it's worth, here are the versions of gstreamer-plugins-bad and faad2 that I am using:

$ rpm -q gstreamer-plugins-bad faad2
gstreamer-plugins-bad-0.10.3-0.gst.1.5
faad2-2.0-8.fc5.rf

Also, it's worth noting that this is an x86_64 machine.  (I'm not sure if the problem exists on my i386 machine; I haven't finished upgrading that machine yet.)
Comment 1 Tim-Philipp Müller 2006-05-05 18:04:58 UTC
Could you make such a file available somewhere online by any chance?

Comment 2 Eric Bair 2006-05-05 20:32:21 UTC
Actually, I think I may have figured out the problem already.  As noted above, when I encountered the error, I was using faad2 version faad2-2.0-8.fc5.rf.  When I "upgraded" to faad2 version faad2-2.0-8.lvn5, the problem I described above disappeared.

Hence, I'm not sure that this is a bug in gst-plugins-bad or even gstreamer per se.  This seems to be a problem with faad2, and it's a problem that I've encountered before.  More specifically, it appears that version 2.0-8 of the faad2 packages distributed by freshrpms/dries are incompatible with the faad2 package distributed by livna.  Any package that is built using the freshrpms/dries version of faad2 won't play m4a files on a system where the livna version of faad2 is installed, and similarly, a package build against the livna version of faad2 won't play m4a files on a system where the freshrpms/dries version of faad2 is installed.

I'm almost certain that's the reason that my gstreamer-plugins-bad plugin stopped working when I upgraded this morning.  Previously I was using the gstreamer-plugins-bad package distributed by freshrpms, which was presumably built against the freshprms version of faad2.  When I upgraded to the gstreamer-plugins-bad package distributed by gstreamer, I assume it was built against the livna version of faad2, and hence the problem.

I'm not sure what is the best way to deal with the issue.  I plan on filing bug reports at both livna and freshrpms to let them know that even though their respective faad2 packages have the same version number, they are incompatible with one another.  Ideally they would make their packages compatible, but that might be too much to hope for.  At the bare minimum, it seems like they should give the two packages different version numbers and make sure that any package depending of faad2 insists on having the correct version installed.

Also, I should mention that this only seems to be a problem on x86_64 machines.  On my i386 machine, the livna version of faad2 is installed, but I can play m4a files using packages distributed by freshrpms/dries without any problems (at least that I have observed thus far).
Comment 3 Tim-Philipp Müller 2006-05-08 17:03:01 UTC
I thought it was only the header declarations that are different/messed up.
Comment 4 Michael Smith 2006-05-09 09:10:38 UTC
I haven't looked into any details of this bug, but the FAAD situation in general is extremely broken:

  1) Upstream hasn't done any releases in years.
  2) Upstream CVS is ABI incompatible with the most recent release
     (I think at least some distributions use CVS snapshots, rather than the release?)
  3) Upstream CVS is API incompatible with the most recent release. It has a layer of macro-compatibility shims, but...
  4) Upstream CVS AND the latest release both have broken public headers, that declare two functions incorrectly (in a way that only breaks on 64 bit systems). We have a Truly Evil Hack that redefines these things locally correctly, but this breaks the API-compatibility hacks.

The end result is: we only compile against the latest release, NOT against upstream CVS. Might be possible to work around given sufficient energy. Due to ABI incompatibilities, we also don't link against CVS. Nothing we can do about that part.

At a guess, this bug involves this problem in some way.

Comment 5 Thomas Vander Stichele 2006-05-11 20:44:27 UTC
don't mix repositories, the pages for the gstreamer repository clearly state this.

fixing faad is outside of the scope of this bug.

closing.