Am 20.08.24 um 16:52 schrieb Robin H. Johnson:
> 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.
This is the hallmark of a workaround.
>> 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