bug#47106: Bubblewrap hates Guix containers 😞

[Bengt Richter]

Hi,

On +2021-03-13 12:07:51 +0100, Leo Prikler wrote:
> Hi!
> Am Samstag, den 13.03.2021, 11:48 +0100 schrieb Ludovic Courtès:
> > Hi!
> > 
> > Leo Prikler <leo.prikler@student.tugraz.at> skribis:
> > 
> > > both Epiphany and Eolie (post fixing #47097; will submit patch
> > > shortly)
> > > fail inside Guix containers with the suggested incantation.  After
> > > getting the environment to no longer complain about $DISPLAY by
> > > adding
> > > `--preserve="XAUTHORITY" --expose=$XAUTHORITY', it repeatedly
> > > outputsn
> > > lines like
> > > bwrap: Can't find source path /sys/class: No such file or directory
> > > before closing the process altogether.
> > 
> > What is ‘bwrap’ looking for?  /sys is mounted inside ‘guix
> > environment -C’,
> > but perhaps it needs something special?
> > 
> > I suggest running these things (or ‘bwrap’ directly) in ‘strace -f -o
> > log’ inside the container to see.
> It seems to be 
> > openat(AT_FDCWD, "/sys/class/dmi/id/chassis_type", O_RDONLY) = -1
> > ENOENT (No such file or directory)
> > openat(AT_FDCWD, "/sys/firmware/acpi/pm_profile", O_RDONLY) = -1
> > ENOENT (No such file or directory)
> 
> I haven't repeated that for all warnings of similar kind, but if I add
> `--expose=/sys/block --expose=/sys/class --expose=/sys/bus --
> expose=/sys/dev --expose=/sys/devices` to the invocation, I instead get
> a warning, that the WebKitWebProcess can't open $DISPLAY.  I'm not sure
> how to resolve that one, given that I already had to sneak DISPLAY and
> XAUTHORITY into the container, but it's a start.
> 
> Regards,
> Leo
> 
Does $DISPLAY mean ":0" and does the Wayland server answer that with
its XWayland X-interface?

I am wonderering how that is resolved inside a container.

HTH with the detective work ;)

-- 
Regards,
Bengt Richter