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 744134 - gst-plugin-scanner should show the plugin emitting errors and warnings
gst-plugin-scanner should show the plugin emitting errors and warnings
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-07 17:24 UTC by Pacho Ramos
Modified: 2018-11-03 12:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build.log (117.44 KB, text/plain)
2015-02-07 17:24 UTC, Pacho Ramos
Details

Description Pacho Ramos 2015-02-07 17:24:30 UTC
Created attachment 296333 [details]
build.log

On Gentoo we run compilations inside a sandbox system to prevent unwanted access to files and devices from "real" system. That way, we are getting now errors as gst-plugin-scanner wants to access to /dev/video0 directly. 

Probably this access is due to a plugin loaded by gst-plugin-scanner but, as it doesn't show any more output than:
(gst-plugin-scanner:23320): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to open display ':0'

(gst-plugin-scanner:23320): GStreamer-CRITICAL **: gst_structure_new_empty: assertion 'gst_structure_validate_name (name)' failed
 * ACCESS DENIED:  open_wr:      /dev/video0


It's near impossible to know what plugin is causing this issue

The attached full build.log is from farstream-0.2.6, whose building calls gst-plugin-scanner and hits this problem

Thanks a lot
Comment 1 Pacho Ramos 2015-02-07 17:36:17 UTC
OK, I found this is caused by v4l2 plugin :)

Anyway, it would still be useful to, at least, show the loaded plugins processed by gst-plugin-scanner to figure out more easily where is failing
Comment 2 Pacho Ramos 2015-02-12 12:03:28 UTC
Also, maybe gst-plugin-scanner shouldn't allow this accesses as I don't see how that would be needed for checking if a plugin is present or not
Comment 3 Olivier Crête 2015-02-12 16:10:12 UTC
The plugin-scanner doesn't only check only if the plugins are present, but also which elements are in the plugin. Like a few other plugins, the v4l2 plugin exposes different elements based on what is present on the platform. In the case of v4l2, it does it by checking what kind of v4l2 devices there are and if any are m2m encoder/decoder/converter devices. So it is needed. Just allow access in the ebuild, the Gentoo sandbox was always stupid anyway, doing properly requires using namespaces and stuff.
Comment 4 GStreamer system administrator 2018-11-03 12:25:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/92.