[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.

[Abhishek Cherath]

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

>> 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.
>

Gotcha.

>> 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.

I see, so something along these lines?
```C
const char* guixLocPath = g_getenv("GUIX_LOCPATH");
char** locPaths = NULL;
if (guixLocPath != NULL) {
   locPaths = g_strsplit(guixLocPath,':', 4096);
   for (int i = 0; i < g_strv_length(locPaths); i++) {
       sandboxArgs.appendVector(Vector<CString>({
        "--ro-bind", *locPaths[i], *locPaths[i]
       }));
   }
   g_strfreev(locPaths);
}
```

>> > 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.

Sounds good to me! Will send v4 with just that.