Description of problem: 32 bit applications fail to find any GStreamer element with errors like: (gst-plugin-scanner:24901): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-1.0/libgstvideoconvert.so': /usr/lib/gstreamer-1.0/libgstvideoconvert.so: wrong ELF class: ELFCLASS32 Version-Release number of selected component (if applicable): This impacts all versions of the gstreamer1 package from 1.0.10-1 in Fedora 18 to 1.12.1-1 in Fedora 26. How reproducible: 100% reproducible. Steps to Reproduce: 1. Install a 64 bit version of Fedora. 2. Install the 32 bit GStreamer packages: dnf install gstreamer1-plugins-base.i686 3. Download and extract the 32 bit gstreamer1 package for your Fedora version. For instance mkdir gst1 cd gst1 dnf download gstreamer1.i686 rpm2cpio gstreamer1*.rpm | cpio -idmv 4. Clear the 32 bit registry and run the 32 bit gst-inspect-1.0 tool to force recreating it: rm ~/.cache/gstreamer-1.0/registry.i686.bin ~/gst1/usr/bin/gst-inspect-1.0 videoconvert Note that while in this case we are using the standard 32 bit gst-inspect-1.0 binary, this affects any 32 bit application. In particular it impacts Wine and thus any 32 bit Windows application (such as games) that depends on winegstreamer.dll. Actual results: $ ~/gst1/usr/bin/gst-inspect-1.0 videoconvert [...] (gst-plugin-scanner:24820): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-1.0/libgstvideoconvert.so': /usr/lib/gstreamer-1.0/libgstvideoconvert.so: wrong ELF class: ELFCLASS32 [...] No such element or plugin 'videoconvert' Expected results: Information about the videoconvert element of the 32 bit gstreamer1-plugins-base package. Additional info: The reason for this bug is that scanning the plugins is delegated to /usr/libexec/gstreamer-1.0/gst-plugin-scanner. However on a 64 bit system this is a 64 bit executable provided by gstreamer1.x86_64 which is thus only able to load 64 bit GStreamer plugins. As proof, the above issue can be fixed by running the following commands: * As root: mv /usr/libexec/gstreamer-1.0/gst-plugin-scanner /usr/libexec/gstreamer-1.0/gst-plugin-scanner.x86_64 cp /home/user/gst1/usr/libexec/gstreamer-1.0/gst-plugin-scanner /usr/libexec/gstreamer-1.0 * Then in the user account the 32 bit gst-inspect-1.0 command will then return the expected result: rm ~/.cache/gstreamer-1.0/registry.i686.bin ~/gst1/usr/bin/gst-inspect-1.0 videoconvert However this is obviously not a proper fix since that breaks scanning 64 bit plugins.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I retested this bug in Fedora 28 with gstreamer1-1.14.0-1.fc28.x86_64 and this bug is still present. In fact absolutely nothing has changed.
marking Futurefeature to avoid auto-close
So, if I understand correctly, /usr/libexec/gstreamer-1.0/gst-plugin-scanner is not architecture agnostic, and needs to live somewhere arch-specific. Anyone seeing this mind filing a bug upstream, https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29
This looks more like a packaging bug than an upstream one to me (for instance it works on Debian). Why should it be reported upstream?
debian doesn't use /usr/libexec , that may be why it's not evident there. As a matter of fact, one immediate change I'm considering is adding --libexecdir=%{_libdir} to the configure step to move these to a multilib-safe location.
(In reply to Falcon Marly from comment #4) > The 32-bit libraries are still included, so Steam and other applications > will keep on being supported. The same will happen to CentOS/EPEL 6 at the > moment a new 64 bit only driver series. I have managed this issue with the > help of link https://hpetechnicalsupportnumber.com/hp-customer-care-number/. > So, you can visit there for a proper solution. It is very helping. The HP link just takes me to an HP logon page. Can you be more specific with the issue number?
The 'needinfo' flag was set by a now deleted spam comment (nicolasmithusa). Hopefully this will clear it.
This issue is still present in Fedora 32.
I've just had a Fedora 32 upgrade failure that may be related. From dnf.log: dnf.exceptions.DepsolveError: Problem: both package rpmfusion-free-obsolete-packages-32-3.fc32.noarch and fedora-obsolete-packages-32-44.noarch obsolete gstreamer-plugins-ugly < 0.10.19-34 - conflicting requests 2020-05-25T02:47:08Z CRITICAL Error: Problem: both package rpmfusion-free-obsolete-packages-32-3.fc32.noarch and fedora-obsolete-packages-32-44.noarch obsolete gstreamer-plugins-ugly < 0.10.19-34 - conflicting requests 2020-05-25T02:47:08Z INFO (try to add '--skip-broken' to skip uninstallable packages) 2020-05-25T02:47:08Z DDEBUG Cleaning up. The "skip-broken" did not work. I've had other 32 install problems, but it now seems down to this.
(In reply to nordquest from comment #13) > I've just had a Fedora 32 upgrade failure that may be related. From dnf.log: > > dnf.exceptions.DepsolveError: > Problem: both package rpmfusion-free-obsolete-packages-32-3.fc32.noarch and > fedora-obsolete-packages-32-44.noarch obsolete gstreamer-plugins-ugly < > 0.10.19-34 [...] That's not related at all.
(In reply to Francois Gouget from comment #14) > That's not related at all. Of course.
Here are some more details: * A simple way to know if gst-plugin-scanner has broken the registry.i686.bin file is to run strings on it: $ strings .cache/gstreamer-1.0/registry.i686.bin | head -n12 1.3.0 libgstcoreelements.so Plugin for blacklisted file /usr/lib/gstreamer-1.0/libgstcoreelements.so 0.0.0 BLACKLIST BLACKLIST BLACKLIST BLACKLIST libgstcoretracers.so Plugin for blacklisted file /usr/lib/gstreamer-1.0/libgstcoretracers.so The 'BLACKLIST' lines indicate gst-plugin-scanner failed to load the plugin and thus marked it to be ignored. * It is possible for a 32-bit application to avoid triggering this bug: the trick is to pass the --gst-disable-registry-fork option to gst_init_check(): BOOL *status = param; char argv0[] = "wine"; char argv1[] = "--gst-disable-registry-fork"; [...] *status = gst_init_check(&argc, &argv, &err); * Wine uses this workaround so it will not _trigger_ this bug. But GStreamer's tools (e.g. gst-inspect-1.0) and probably most other tools don't use the workaround and thus will break 32-bit GStreamer. * Once registry.i686.bin has been filled with bad data every application is impacted, including Wine, and the issue will only be fixed once a 32-bit application using the workaround performs a registry update. In other words, one must hope that after a plugins upgrade the first 32-bit application to trigger the registry file update is one that uses the workaround. This leads to a situation where things work or break seemingly at random.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.