On Mon, Aug 19, 2024 at 09:49:28PM +0200, Ulrich Mueller wrote:

I pushed a fix to virtualx.eclass for you.

That addpredict looks like a workaround, not like a real fix of the
problem.

It's a fix in that it correctly tells Sandbox that upstream mesas use a
predictive fopen(..., RDWR) and Gentoo expects it to *NOT* actually use the
device in the ebuild context.

It doesn't fix the underlying problem of Xvfb accessing /dev/dri/*. It works around it by breaking Xvfb via the sandbox.

Especially, the many warnings mentioned by grozin are still
there. With the patched virtualx.eclass, I still see more than thousand
messages in Xvfb.log:
   libEGL warning: failed to open /dev/dri/card0: Permission denied

The manual does correctly build despite that warning from mesa, because it
correctly falls back.

Also, was this so urgent that you had to push the eclass change without
prior mailing list review?

Low impact, fixes blockage.

The impact of changing an eclass willy nilly without asking anyone for @X11 or anyone affected?

We've had mesa-24.2.0* in the tree for a while now. We had plenty of tinderbox runs testing. This is the only package that fails with those sandbox violations. No other @sci stuff, no @kde stuff.

The "Low impact, fixes blockage." fix would have been to add that addpredict line to the affected package, file a bug and ask the people that actually know about mesa.

Reminder to all, if you go looking for bugs, you'll find more than you expected.

Git bisect of mesa points to the relevant upstream commits that introduced the flaws.

1. The init behavior changed here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30426/diffs
   This was added between mesa-24.2.0-rc3 and mesa-24.2.0-rc4
   It always probes those /dev/ files now.

2. I *also* found a similar failure upstream between 24.0.9 and 24.1.0; with USE=llvm specifically:
   https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805/diffs#81e929dbdc766bd46257096f260549cbdeba18fc_1133_1161

sandbox snippet for USE=llvm:
F: open_wr
S: deny
P: /dev/udmabuf
A: /dev/udmabuf
R: /dev/udmabuf
C: Xvfb -displayfd 1 -screen 0 1280x1024x24 +extension RANDR 

"addpredict /dev/udmabuf" should also enable other cases to be stricter:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48b4885e4f9a19ccc4c1489a387e38fb3b7d62b7

and re-enable tests here:
https://bugs.gentoo.org/933257

Oddly enough fricas also has an automagic dependency on xvfb-run...

FYI: this actually fixes the access for fricas:

diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index f7318eafc59..21995b9dcc7 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -107,13 +107,12 @@ virtx() {
 
 	local i=0
 	local retval=0
-	local xvfbargs=( -screen 0 1280x1024x24 +extension RANDR )
+	local xvfbargs=( -screen 0 1280x1024x24 +extension RANDR -extension GLX )
 
 	debug-print "${FUNCNAME}: running Xvfb hack"
 	export XAUTHORITY=
 
 	einfo "Starting Xvfb ..."
-	addpredict /dev/dri/ # Needed for Xvfb w/ >=mesa-24.2.0
 
 	debug-print "${FUNCNAME}: Xvfb -displayfd 1 ${xvfbargs[*]}"
 	local logfile=${T}/Xvfb.log