From: ludo@gnu.org (Ludovic Courtès)
To: Mike Gerwitz <mtg@gnu.org>
Cc: help-guix@gnu.org
Subject: Re: Running IceCat in a container
Date: Mon, 29 Jan 2018 17:47:58 +0100 [thread overview]
Message-ID: <87lgggligx.fsf@gnu.org> (raw)
In-Reply-To: <87po5xgtue.fsf@gnu.org> (Mike Gerwitz's message of "Thu, 25 Jan 2018 22:52:09 -0500")
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!
Thanks,
Ludo’.
next prev parent reply other threads:[~2018-01-29 16:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 1:56 Running IceCat in a container Mike Gerwitz
2018-01-16 16:30 ` Ludovic Courtès
2018-01-17 2:25 ` Mike Gerwitz
2018-01-17 19:05 ` Mike Gerwitz
2018-01-17 23:20 ` Leo Famulari
2018-01-18 1:53 ` Mike Gerwitz
2018-01-25 14:34 ` Ludovic Courtès
2018-01-25 22:16 ` Ludovic Courtès
2018-01-26 3:52 ` Mike Gerwitz
2018-01-29 16:47 ` Ludovic Courtès [this message]
2018-01-30 2:19 ` Ricardo Wurmus
2018-01-30 17:21 ` Running code from packs in containers Ludovic Courtès
2018-03-19 17:42 ` Running IceCat in a container ng0
2018-01-29 16:48 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgggligx.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=help-guix@gnu.org \
--cc=mtg@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).