[bug#70446] [PATCH v3] gnu: webkitgtk: Add locale and dri access to gtk sandbox in order to silence gtk locale warnings and enable hardware accelerated video, respectively. Adjust bubblewrap wrapper to add user profile locale and dri directories.

[Liliana Marie Prikler]

Am Freitag, dem 19.04.2024 um 20:22 -0400 schrieb Abhishek Cherath:
> Hello,
> 
> > > ++        "--ro-bind-try", userLocaleDir, userLocaleDir,
> > > ++
> > > ++        // Bind mount the dri dir in profile
> > > ++        "--ro-bind-try", userDriDir, userDriDir,
> > For reference, why are these two needed here?  Can't we do this
> > with the locales and drivers referenced below?  Should we perhaps
> > expand GUIX_LOCPATH here?
> 
> Initially, I only had the system paths below those. I added these
> so that people could have hardware accel by only installing the
> required drivers in their local profiles (as recommended in 69971,
> unless I entirely misunderstood)
Ah, yes, Maxim did mention this, but yeah, non-static paths are NG
(nogood) here.  There really is no reason that those paths ought to
exist or be useful in a container, for example.

> I'm afraid I don't really know what adding stuff to GUIX_LOCPATH
> would do. That's for foreign distros, correct? To reiterate, The
> locale problem here is that the bubblewrapped process doesn't have
> access to the locales, without which it throws warnings.
Adding stuff *from* GUIX_LOCPATH, the idea being that this is where we
already advocate locales be put.

> > Note that any item you add here which references the user home will
> > fail to be loaded correctly when using `guix shell' in a way that
> > hides it; or even just using `guix shell' normally with a user who
> > doesn't have the hardware-accelerated drivers in their home.  For
> > system paths, this is somewhat different, since we can more or less
> > expect them to exist and mirror the layout of other distros to some
> > extent.
> 
> Hmm, since it's in an ro-bind-try, that'll cause the drivers not to
> work, and fall back to trying the system drivers. Is there a better
> solution you could recommend?
Unless a hard dependency on Mesa is appropriate (which we'd have to
confirm), I think just rolling with the system ones is okay.

Cheers