From: Paul Zander <negril.nx+gentoo@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] fricas[doc] now fails to emerge
Date: Tue, 20 Aug 2024 18:06:17 +0200 [thread overview]
Message-ID: <c96260ad-12d2-4515-b779-a258fd394800@gmail.com> (raw)
In-Reply-To: <robbat2-20240820T045536-064590337Z@orbis-terrarum.net>
[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5678 bytes --]
next prev parent reply other threads:[~2024-08-20 16:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-17 14:46 [gentoo-dev] fricas[doc] now fails to emerge Andrey Grozin
2024-08-17 17:13 ` Robin H. Johnson
2024-08-17 18:04 ` negril.nx+gentoo
[not found] ` <e383fc49-484a-493a-bb2b-e1e684bb87fd@uni-rostock.de>
2024-08-18 16:20 ` Andrey Grozin
2024-08-19 18:18 ` Robin H. Johnson
2024-08-19 19:49 ` Ulrich Mueller
2024-08-20 14:52 ` Robin H. Johnson
2024-08-20 16:06 ` Paul Zander [this message]
2024-08-20 19:18 ` Robin H. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c96260ad-12d2-4515-b779-a258fd394800@gmail.com \
--to=negril.nx+gentoo@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox