From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4EDAA15852A for ; Tue, 20 Aug 2024 16:06:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B1172BC017; Tue, 20 Aug 2024 16:06:21 +0000 (UTC) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 433292BC013 for ; Tue, 20 Aug 2024 16:06:21 +0000 (UTC) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a8666734767so15530766b.1 for ; Tue, 20 Aug 2024 09:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724169980; x=1724774780; darn=lists.gentoo.org; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=uDlUT6eTncq8HVLV+ilynelpf47SRa/DCNWea1rpBiw=; b=cNUFdbIltGfScqLJabemauprHm+Y5sg6EN9WXtqN8hjKkar2vrJilykEExAhxl+8v4 1BRZXsfXxV5PNkyF5vruTB39T1n+1a2bsGAUXhlC9acakA6IvQXEDlpThTPTF6CD4qug 2TEKuSx9zeToBk+j4o7tJHYpDxAjmf6zUdLJjiGLz19XjcVz3AZ3LvTY/LcfqOCgX6Yx rAfXpeLddBvE4ryQ1DqVA9XlhK/3HY0aYY36sd/WHBTeFv1716ttXUdPWODOEBhcHL5Z x7zXTYnO/QpZ8HYjoId9Tp0Hh3O+Ut/hv2dMhILYEdWcyWo585gGspYXIVHgjB6ucDb5 ljQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724169980; x=1724774780; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uDlUT6eTncq8HVLV+ilynelpf47SRa/DCNWea1rpBiw=; b=AGy8pquF+/4vjWYdXPnMRPYJce2u7jIuJf5+ZAY3nFi4vj4K1jpJHIJ4Cw5GjsvwiG 7oEtRGPq/zddOvvDEluwOSaKZMEQ0KyfXl2SrZa/WF/ZEkikhFsGphFfU4vCHFtSmsYq cfBFciVQfwigSBw8hMvIsgRrm4daEVy1xVYXqWty3skyj9NwyhSpF2581oBtjPt0AkN6 jSzC3tRb26LFmmowYn0oiZgW6AB0ldwnWjyOgW1hgafLhFQHRcZ7Gc1GYSQDSG1iMkLn pc9wkduTYupgjBHKBfh5Sgoj6g8vNd3cB+AtQe9e1MaCDVZez0YQFDLGRhOxugXQM5Bh 7KNw== X-Gm-Message-State: AOJu0Ywv/vOkxRD2DOppXR0+TTQIZkU6nBkuxsCZ3NKQNAHwG+sQEVzU PBnqtZhTyxbTTutJigpqsNdhj8ey9S8B/zzgfpvpg3vtjMvraDbjFwOFrg== X-Google-Smtp-Source: AGHT+IGRHo9qtq/eAhIJZoC6luumbWNX4yriQxuiYk8ZXscuGQ8wMa91TFhPfF+fd2oLxhg9g2g2Bw== X-Received: by 2002:a17:907:d589:b0:a77:d7f1:42eb with SMTP id a640c23a62f3a-a839292e82cmr1113757066b.23.1724169979011; Tue, 20 Aug 2024 09:06:19 -0700 (PDT) Received: from ?IPV6:2a02:8109:c30f:4600:8cd5:a6f2:eca9:990a? ([2a02:8109:c30f:4600:8cd5:a6f2:eca9:990a]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a83838cefafsm770318866b.49.2024.08.20.09.06.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Aug 2024 09:06:18 -0700 (PDT) Sender: Paul Content-Type: multipart/alternative; boundary="------------bYnvPTwgfA5KVy2z9zqgJHAE" Message-ID: Date: Tue, 20 Aug 2024 18:06:17 +0200 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] fricas[doc] now fails to emerge To: gentoo-dev@lists.gentoo.org References: <7e6d0c73-4f51-1122-5ad0-1b933f02fddc@woodpecker.gentoo.org> Content-Language: en-US From: Paul Zander In-Reply-To: X-Archives-Salt: 64059ebe-c5dd-4903-814b-92487bd45381 X-Archives-Hash: 8fa2dba7c6d03d5dd34fe3a6771d01a1 This is a multi-part message in MIME format. --------------bYnvPTwgfA5KVy2z9zqgJHAE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------bYnvPTwgfA5KVy2z9zqgJHAE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
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

--------------bYnvPTwgfA5KVy2z9zqgJHAE--