Re: [gentoo-dev] fricas[doc] now fails to emerge

["Robin H. Johnson" <robbat2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

On Tue, Aug 20, 2024 at 06:06:17PM +0200, Paul Zander wrote:
> >> 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.
Hiding the errors also isn't a fix - it's just picking a different code path.

virtualx has detection automagic in what Mesa drivers are actually loading; and
that certainly contributes to the problems.

> >> 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?
Who was affected by the breakage? Grozin.
The tree has a sprawl of addpredict/addwrite /dev/dri/ entries; because this
isn't handled consistently at the Xvfb/mesa level.

> 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.
See below about libeproxy - it's failing because of the same files.

> 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.
If I didn't know about mesa, why do you think I commented on this thread, and
provided bisect showing where upstream introduced the change in behavior?

> Oddly enough fricas also has an automagic dependency on xvfb-run...
@grozin: please do fix the automagic behavior in fricas; it's clearly not fatal
either, because my test environment does not have xvfb-run installed at all.

> FYI: this actually fixes the access for fricas:
Your patch would "fix" fricas, but I think it will break anything else
that explicitly relies on GLX inside Xvfb; and would need a tinderbox
run to verify what that is. There is an even worse potential outcome in your
patch: tests might skip some cases because they probe for the GLX extension and
skip those cases.

It would not surprise me if there are other packages already broken, and
not detected in the prior testing.

As a fast example, media-libs/libepoxy, fails already because it wants
GLX in src_test. It was broken before per bug #823786, and still broken
with my patch, and yours outright disables what it wants to test.  I think it's
mucking with sandbox in another way, because even with both config explicitly
permitting writes, it still shows Xvfb errors to them:

libepoxy-1.5.10-r3.ebuild:
==
multilib_src_test() {
    export MESA_LOADER_DRIVER_OVERRIDE=llvmpipe
    export LIBGL_KOPPER_DISABLE=true
    export LIBGL_KOPPER_DRI2=true
    export GALLIUM_DRIVER=llvmpipe
    export LIBGL_ALWAYS_SOFTWARE=true
    addwrite /dev/dri/card0
    addwrite /dev/udmabuf
    addwrite /dev/dri/renderD128
    virtx meson_src_test
}
==


$ head /var/tmp/portage-tmpfs/portage/media-libs/libepoxy-1.5.10-r3/temp/Xvfb.log 
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
libEGL warning: failed to open /dev/dri/card0: Permission denied
...

And yet running the same test outside of the ebuild works fine.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation President & Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]