Bug 1581325

This problem was highlighted with gstreamer1-plugins-good-1.14.1 in updates-testing.

Rebuilding f28 GA gstreamer1-plugins-good using GA gstreamer1-1.14.0-1.fc28.x86_64 also fails, which seems to show the problem is elsewhere.

Manually running 
gst-inspect-1.0 --print-plugin-auto-install-info --rpm <foo>
on individual installed plugins during build also works as expected

the plot thickens

I think 'file' is to blame, gstreamer1.prov includes:
        xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut -d: -f1 )


$ rpm -q file
file-5.32-3.fc28.x86_64
$ file -L /usr/lib64/gstreamer-1.0/libgstgtk.so
/usr/lib64/gstreamer-1.0/libgstgtk.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=36571638e503d65491eb210008f00ebc052d9ade, stripped


$ rpm -q file
file-5.33-2.fc28.x86_64
$ file -L /usr/lib64/gstreamer-1.0/libgstgtk.so
/usr/lib64/gstreamer-1.0/libgstgtk.so: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=36571638e503d65491eb210008f00ebc052d9ade, stripped

Note the output changed :-/

ELF 64-bit LSB shared object => ELF 64-bit LSB pie executable

Filed "file" bug #1581343

That said, I question whether such a strict check like the grep from comment #2 is required.  it's already already matching filenames that include "libgst" that ends in ".so"

Options include:
* relax solist check to *just* ELF
* relax solist check to include "pie executable" in addition to "shared object"
* wait for file to fix behavior change
* (some better idea)

Another option:
* limit search of objects to consider to gst1 plugins dir, ie, output from `pkg-config gstreamer-1.0 --variable=pluginsdir`

For example, the status quo misses some plugins there that are not named of the form libgst*.so , on my f28 box, that includes:
/usr/lib64/gstreamer-1.0/libfsmsnconference.so
/usr/lib64/gstreamer-1.0/libfsrawconference.so
/usr/lib64/gstreamer-1.0/libfsrtpconference.so
/usr/lib64/gstreamer-1.0/libfsrtpxdata.so
/usr/lib64/gstreamer-1.0/libfsvideoanyrate.so

One suggestion in the linked bug was to use readelf to search for a well-known symbol.  One possibility is gst_plugin_desc, but according to
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPlugin.html
"A plugin should export a symbol gst_plugin_desc ..."
note that not a MUST, so note sure we can rely on that one

Is it possible to try to load all potential plug-ins at build time and generate Provides: for them only if they load successfully?

(In reply to Rex Dieter from comment #6)
> One suggestion in the linked bug was to use readelf to search for a
> well-known symbol.  One possibility is gst_plugin_desc, but according to
> https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/
> GstPlugin.html
> "A plugin should export a symbol gst_plugin_desc ..."
> note that not a MUST, so note sure we can rely on that one

You can't rely on that symbol anymore, it changed to gst_plugin_{name}_desc where {name} is the plugin name derived from the .so filename.

I would just check for ELF. The list of all ELF .so files are then passed to gst-inspect-1.0 that will then try to open it, verify that it is a plugin with the right symbol and if all that works, generate a list of the plugins in the .so

Thanks, I do have some unaddressed concerns though

* checking *all* ELF .so files may be slower (perhaps not significantly)

* Comment #5 , not all gstreamer plugins are named libgst*.so it seems

* Comment #5 , what about limiting search to well-known locations of gst plugins? (instead of anything matching libgst*.so)?

> checking *all* ELF .so files may be slower (perhaps not significantly)

AFAICS the script only checks the plugins that were built by the package so the number of .so files that are not plugins but match libgst*.so are small.

> not all gstreamer plugins are named libgst*.so it seems

# rpm -qf /usr/lib64/gstreamer-1.0/libfsmsnconference.so
farstream02-0.2.7-7.fc28.x86_64

These are not plugins shipped by official gstreamer packages.

> what about limiting search to well-known locations of gst plugins? (instead of anything matching libgst*.so)?

All the plugins should also be in the /usr/lib64/gstreamer-1.0/ directory so I guess it could be added as an extra constraint.

I think I understand now.. The gstreamer1.prov script is run for each rpm that is installed, not only the gstreamer ones. It should be fast and preferably only look in places where plugins can be. So my new proposal is:

1) only look in the plugin install dir (/usr/lib64/gstreamer-1.0/)
2) check all ELF files matching lib*.so

gstreamer1-1.14.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3fa0939e00

gstreamer1-plugins-base-1.14.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6a15f4c138

gstreamer1-plugins-good-1.14.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-560c25093c

gstreamer1-plugins-bad-free-1.14.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e2e3df868d

gstreamer1-plugins-ugly-free-1.14.1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e84487acad

gstreamer1-1.14.1-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3fa0939e00

gstreamer1-plugins-base-1.14.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-6a15f4c138

gstreamer1-plugins-good-1.14.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-560c25093c

gstreamer1-plugins-bad-free-1.14.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e2e3df868d

gstreamer1-plugins-ugly-free-1.14.1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e84487acad

gstreamer1-1.14.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

gstreamer1-plugins-base-1.14.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

gstreamer1-plugins-good-1.14.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

gstreamer1-plugins-bad-free-1.14.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

gstreamer1-plugins-ugly-free-1.14.1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

The non -free updates on rpmfusion are missing:

* http://koji.rpmfusion.org/koji/packageinfo?packageID=82
* http://koji.rpmfusion.org/koji/packageinfo?packageID=84

"dnf update" fails now e.g. with:

 Problem: package gstreamer1-plugins-ugly-1.14.0-1.fc28.x86_64 requires gstreamer1-plugins-ugly-free(x86-64) = 1.14.0, but none of the providers can be installed
  - cannot install both gstreamer1-plugins-ugly-free-1.14.1-3.fc28.x86_64 and gstreamer1-plugins-ugly-free-1.14.0-1.fc28.x86_64
  - cannot install both gstreamer1-plugins-ugly-free-1.14.0-1.fc28.x86_64 and gstreamer1-plugins-ugly-free-1.14.1-3.fc28.x86_64

That's not a fedora issue, that's something for rpmfusion.

That said, I can help work on it there as time allows.