Re: Running IceCat in a container

[ng0 <ng0@n0.is>]

Ludovic Courtès transcribed 4.0K bytes:
> Heya,
> 
> Mike Gerwitz <mtg@gnu.org> skribis:
> 
> > On Thu, Jan 25, 2018 at 23:16:47 +0100, Ludovic Courtès wrote:
> >> If you drop the attached file under guix/scripts/, you can then run:
> >>
> >>   guix run icecat icecat
> >>
> >> and similar.  This particular example doesn’t work well because of the
> >> font issue you’re familiar with, but you get the idea.  :-)
> 
> I also realized that we can support:
> 
>   guix run icecat
> 
> which looks up ‘icecat’ in $PATH, and “readlink -f” to get at the
> underlying store item.  This would be faster (and probably more
> convenient) than “building” icecat as the script currently does.
> 
> > I sent a few patches moments ago that I've been sitting on for a
> > bit.  My intent was originally to go further, but I ran out of
> > time.  But I didn't think `guix environment' was the appropriate place
> > to put such things---this script, though, is a good starting point for
> > them.
> 
> Agreed.  I like the ideas in the patches you sent, but I’m not sure
> ‘guix environment’ is the right place for them.  It goes beyond the
> typical job of ‘guix environment’.
> 
> > For example, if one of the dependencies of a program is X11, it can
> > automatically share the X paths (unless overridden by the user).  Same
> > with DBUS, sound devices, etc.  I mentioned previous ideas earlier in
> > the thread.
> 
> Indeed, that’s a good idea.  It may be good enough to pattern-match the
> store file names.
> 
> The attached version follows this suggestion:
> 
> --8<---------------cut here---------------start------------->8---
> ludo@ribbon ~/src/guix$ ./pre-inst-env guix run xdpyinfo |head
> 
> name of display:    :0.0
> version number:    11.0
> vendor string:    The X.Org Foundation
> vendor release number:    11906000
> X.Org version: 1.19.6
> maximum request size:  16777212 bytes
> motion buffer size:  256
> bitmap unit, bit order, padding:    32, LSBFirst, 32
> image byte order:    LSBFirst
> ludo@ribbon ~/src/guix$ ./pre-inst-env guix run ls -la .
> 
> total 0
> drwxr-xr-x 2 0 0 40 Jan 29 16:40 .
> drwxr-xr-x 3 0 0 60 Jan 29 16:40 ..
> --8<---------------cut here---------------end--------------->8---
> 
> For some reason IceCat and Evince crash with a GDK error, whereas GIMP
> and Xpdf are fine.
> 
> > I'd also want to integrate changes I made to `guix environment'.  If
> > people here like the changes and they are merged, I'd want to refactor
> > it into a common place, not just copy the code.
> 
> Yes, it’d be nice to have a module of utilities for environment
> management.
> 
> >            ;; container script to invoke IceCat
> >            (mkdir-p bin-dir)
> >            (call-with-output-file (string-append bin-dir "icecat-container")
> >              (lambda (port)
> >                (format port "#!/bin/bash")))
> >
> >            ;; fontconfig configuration
> >            (mkdir-p fc-dir)
> >            (call-with-output-file fc-mtg
> >              (lambda (port)
> >                (format port (string-append "<?xml version=\"1.0\"?>
> > <!DOCTYPE fontconfig SYSTEM \"fonts.dtd\">
> > <fontconfig>
> >   <dir>" (string-append (assoc-ref %build-inputs "font-dejavu")
> >                         "/share/fonts") "</dir>
> >   <cachedir>" fc-cache-dir "</cachedir>
> > </fontconfig>\n"))))
> >
> >            (setenv "PATH"
> >                    (string-append (assoc-ref %build-inputs "fontconfig")
> >                                   "/bin"))
> >            (setenv "FONTCONFIG_FILE" fc-mtg)
> >            (setenv "XDG_DATA_HOME" share-dir)
> >
> >            (mkdir-p cache-dir)
> >            (invoke "fc-cache" "-fv")))))
> 
> Nice!
> 
> Actually there are really two approaches we could use.  One is to create
> wrappers like this one that do the right thing, independently of what
> the user’s profile contains (‘guix package’ could even generate wrappers
> automatically in some cases.)
> 
> The second approach is a ‘guix run/environment’ kind of command that
> generates the environment at run time.
> 
> There are pros and cons to both, I think.
>
> Food for thought!

Interesting ideas in this thread, I just tried your last version of guix run!

Couldn't we use both? For example, we can not predict where people will store their
mail and which applications they define in the config of the mailing application
to send it and receive it (case for environment) but we can predict roughly what
will be needed for w3m to be sandboxed.

> Thanks,
> Ludo’.
> 
> 

-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is