sandbox violation on compile for /root/.gconfd and /root/.gconf Reproducible: Always
Created attachment 265769 [details] sandbox logs
Created attachment 265771 [details, diff] patch to fix sandbox violation
That looks like a duplicate of a report we had for in tree ebuilds. We should also stop adding workarounds like this and work on our eclasses sanitizing functions instead.
Created attachment 266027 [details, diff] Patch to fix sandbox violation at eclass level thanks for your comment, Gilles. I've patched eclass too, but I'm less confident about side effects.
*** Bug 360697 has been marked as a duplicate of this bug. ***
well i see only on the version number and if it dont suit, i make a new report. else some other developer will complain agin
This bug is still valid for totem-3.0.0.
For reference: the current official solution for this is to compile with FEATURES=userpriv .
the best solution are dont compile in X, go in a tyy console and emerge from there, so u have not to change anything. it it works
*** Bug 362397 has been marked as a duplicate of this bug. ***
There's a patch to not detect gconf sinks at all in totem now. This should work around the issue till we can figure out how to fix it properly. Please don't close this bug till we can find a proper solution (or till GConf is killed).
Same with 3.2.0.
I can't see anything about this in current totem-3.2 ebuild in the tree, how was this handled finally? At eclass level?
with totem-3.4.0 --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-23993.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /dev/dri/card0 A: /dev/dri/card0 R: /dev/dri/card0 C: /usr/libexec/gstreamer-0.10/gst-plugin-scanner -l --------------------------------------------------------------------------------
(In reply to comment #14) > with totem-3.4.0 > > --------------------------- ACCESS VIOLATION SUMMARY > --------------------------- > LOG FILE "/var/log/sandbox/sandbox-23993.log" > > VERSION 1.0 > FORMAT: F - Function called > FORMAT: S - Access Status > FORMAT: P - Path as passed to function > FORMAT: A - Absolute Path (not canonical) > FORMAT: R - Canonical Path > FORMAT: C - Command Line > > F: open_wr > S: deny > P: /dev/dri/card0 > A: /dev/dri/card0 > R: /dev/dri/card0 > C: /usr/libexec/gstreamer-0.10/gst-plugin-scanner -l > ----------------------------------------------------------------------------- > --- Can you try with src_compile() { DISPLAY="999invalid" gnome2_src_compile } in the ebuild?
(In reply to comment #14) > with totem-3.4.0 > > --------------------------- ACCESS VIOLATION SUMMARY > --------------------------- > LOG FILE "/var/log/sandbox/sandbox-23993.log" > > VERSION 1.0 > FORMAT: F - Function called > FORMAT: S - Access Status > FORMAT: P - Path as passed to function > FORMAT: A - Absolute Path (not canonical) > FORMAT: R - Canonical Path > FORMAT: C - Command Line > > F: open_wr > S: deny > P: /dev/dri/card0 > A: /dev/dri/card0 > R: /dev/dri/card0 > C: /usr/libexec/gstreamer-0.10/gst-plugin-scanner -l > ----------------------------------------------------------------------------- > --- These particular violations occur only when FEATURES=-userpriv and are caused by gst-inspect-0.10, which is run by configure to check for various gst plugins. Fixed in the overlay by the usual hack of passing DISPLAY=999invalid to configure.
+ 12 Jan 2013; Gilles Dartiguelongue <eva@gentoo.org> totem-2.32.0-r2.ebuild, + totem-3.4.3.ebuild, totem-3.6.3-r1.ebuild: + Workaround sandbox violations due to gst-inspect, bug #358755 & co. + I have disabled gst-inspect in configure like I did in sound-juicer. This is more annoyance for us than necessary since we check configure.ac changes in bumps hence dependencies should already be satisfied at this point of the build. Possible alternative solution would be to chase down all gstreamer plugins that need to open a GL context on mere scan which seems silly.
