Re: Recipe for latest release of firefox?
On Tue, Oct 01, 2019 at 23:10:01 -0400, Amin Bandali wrote: > I think I’m in a similar situation as you: I, too, use IceCat every day, > in and out of Guix, but don’t know much about Firefox internals as of > now. I also sadly have little time on my hands, at least until the end > of this year. But I too think a bit of time is better than none at all; > so I’d be willing to give [co-]maintaining IceCat a shot, especially if > I may have someone else’s help along the way :). Great! Thank you. Being a GNU maintainer comes with certain responsibilities and expectations, so I'll get in touch with you privately to clarify whether that's what you're looking for, or if you're just looking to contribute to the project. >> If I don't hear back from Rubén by the end of next week, I'll either >> call him at the FSF or seek the answers elsewhere. >> > > Rubén usually hangs out at #trisquel-dev on Fridays 12-1pm. You may be > able to catch him there if you’re around. I'll be working then, unfortunately. But if anyone here is available to ping him there, do feel free! I'll ping him via email before I try to get in touch elsewhere. -- Mike Gerwitz signature.asc Description: PGP signature
Re: Recipe for latest release of firefox?
On Sun, Sep 29, 2019 at 18:14:08 -0400, Christopher Lemmer Webber wrote: > Does someone have a recipe, or channel, for the latest release of > Firefox? FYI, I contacted Rubén recently asking a number of questions to determine whether I may be able to take up [co-]maintaining IceCat. But while I use IceCat daily, I know very little about Firefox from a development perspective. So if there is anyone willing to take the time to answer some questions of mine to get me up to speed more quickly, I'd appreciate it. If there are people who would be willing to help maintain IceCat, that'd be even better. I don't have a lot of time, but considering that IceCat is effectively unmaintained, a little bit of time is better than no time. If I don't hear back from Rubén by the end of next week, I'll either call him at the FSF or seek the answers elsewhere. As far as packaging it for Guix goes---I can't commit to doing that yet, since I have very little experience there too and IceCat isn't the easiest thing to package. But if I do take up [co-]maintainership, the ideal situation would be for me or someone else to update Guix the same day that IceCat releases are published to gnu.org, or even produce the releases using Guix, as Mark has done. I'll have more information in the next couple of weeks. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: /var/guix/db/db.sqlite corruption
On Sat, Aug 03, 2019 at 02:28:01 -0700, Chris Marusich wrote: > I've also seen this happen. I opened a bug report about it recently: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36687 Ah, when I originally researched this issue, you hadn't yet reported that bug. I should have checked again. I'll reply there with my Message-Id. Thanks for pointing it out. > Did you remember to stop the guix-daemon and verify that no processes > were accessing the database file when you did all of this? If not, then > I wouldn't be surprised to see bizarre behavior. Yeah I had stopped the daemon and was running it manually to pass `--debug'. The errors I was getting were not only from Guix---it was also happening with the sqlite3 command. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
/var/guix/db/db.sqlite corruption
A while back, I ran out of disk space while running `guix package -i`,
during a build. I then noticed that `guix gc` would, after outputting
some number of "deleting" lines, fail with an error that's approximately
this (I forgot to make a copy):
guix gc: error: executing SQLite query: malformed database image
This error appears to come from nix/libstore/sqlite.cc, and the last
portion of the message comes from `sqlite3_errmsg`, so I don't think
this is Guix's fault.
I had already run e2fsck on many occasions since this happened a couple
months back and there are no disk errors.
To work around it, I dumped the DB:
$ sqlite3 db.sqlite .dump > ~/bak.sql
The final line of that file contains this:
ROLLBACK; -- due to errors
Understandable. I replaced that with "COMMIT;", and:
$ mv db.sqlite{,-bak}
$ sqlite3 db.sqlite < ~/bak.sql
This produced a database that was 4MiB smaller than the original. :x
But now `guix gc` works.[*]
So my questions are:
- Is there a way to regenerate the database?
- What bad things could happen with what I just did?
Thanks, and please nobody reading this message in a list archive in the
future do the above without first reading replies to this thread; I
don't want to be responsible for anything bad that may result! :)
[*]: Actually, I had some other bizarre issues. After I recreated the
DB, I started getting more generic I/O errors. There were no errors in
dmesg. But when I moved the file to a different location (e.g. my home
directory), it worked (via `sqlite3`). If I moved it back to
`/var/guix/db/db.sqlite`, I/O errors once again. If I ran `.dump` from
that dir, empty. If I moved it to my home dir and ran `.dump`, I got
the full dump. This problem didn't resolve until after a reboot. I
haven't seen anything like that before, and I don't want to
speculate. I should have tried flushing the kernel I/O cache before
rebooting to see if that would have fixed it.
--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com
signature.asc
Description: PGP signature
Re: Icecat doesn't display any text
On Tue, Jul 09, 2019 at 16:32:45 +, Todor Kondić wrote: > I solved it by either, > > * installing bunch of new fonts > * running fc-cache -f > * re-sourcing .guix-profile/etc/profile > * hash guix > > or some combination of the above. Sourcing the profile would define XDG_DATA_DIRS, which is required for font display. Installing fonts and running fc-cache may have provided fonts in ~/.guix-profile/share/fonts, which is part of XDG_DATA_DIRS. This is a known issue (which I experience when running Icecat in a container) that hopefully can be addressed by someone who knows a bit more than me about the proper way to fix the problem. :) It's a problem for people on foreign distros. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Adding NitoKey Rules to U-Dev Rules
On Fri, Jul 05, 2019 at 15:56:26 -0400, Raghav Gururajan wrote: > I have NitroKey (https://nitrokey.com). To make it work, it appears > nitrokey rules (https://raw.githubusercontent.com/Nitrokey/libnitrokey/ > master/data/41-nitrokey.rules) has to be added to udev rules > (/etc/udev/rules.d/). Not sure how to do this in guix way. Any ideas? Is it not working for you today? I have a Nitrokey Pro that I purchased at least a couple years back that I use every day on a Guix system, including to sign this email. Here's my dmesg output: --8<---cut here---start->8--- [12763.938755] usb 6-2: new full-speed USB device number 9 using uhci_hcd [12764.125823] usb 6-2: New USB device found, idVendor=20a0, idProduct=4108, bcdDevice= 1.00 [12764.125827] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [12764.125830] usb 6-2: Product: Nitrokey Pro [12764.125832] usb 6-2: Manufacturer: Nitrokey [12764.125835] usb 6-2: SerialNumber: [12764.134361] input: Nitrokey Nitrokey Pro as /devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/0003:20A0:4108.0008/input/input20 [12764.191376] hid-generic 0003:20A0:4108.0008: input,hidraw0: USB HID v1.10 Keyboard [Nitrokey Nitrokey Pro] on usb-:00:1d.0-2/input0 --8<---cut here---end--->8--- Maybe there's trouble with newer versions or different types of keys, though. With regards to udev rules---I haven't done so myself, but see `udev-rule' in the Guix manual under `Base Services'. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Documenting current state of isolating icecat
e-page "https://mikegerwitz.com/;)
(build-system trivial-build-system)
(source #f)
(native-inputs
`(("fontconfig" ,fontconfig)))
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let* ((share-dir (string-append %output "/share"))
(cache-dir (string-append %output "/var/cache"))
(bin-dir (string-append %output "/bin"))
(fc-dir(string-append share-dir "/fontconfig/conf.avail"))
(fc-mtg(string-append fc-dir "/52-mtg-container.conf"))
(fc-cache-dir (string-append cache-dir "/fontconfig"))
(fonts-dir (string-append share-dir "/fonts")))
;; 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 "
" (string-append (assoc-ref %build-inputs "font-dejavu")
"/share/fonts") ""
;;" (string-append (assoc-ref %build-inputs "font-adobe-source-han-sans")
;; "/share/fonts") "
"
" fc-cache-dir "
\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")
(propagated-inputs
`(("icecat" ,icecat)
("zenity" ,zenity)
("font-dejavu" ,font-dejavu)
;;("pulseaudio" ,pulseaudio)
;;("font-adobe-source-han-sans", font-adobe-source-han-sans)
))
(synopsis "GNU IceCat packaged for running within a container")
(description
"GNU IceCat packaged with various fonts (including multi-lingual).
Suitable for use within a container.")
(license license:gpl3+)))
#+END_SRC
It might be in a mangled state, though, because I can't remember where I
left off with it. I think `font-adobe-source-han-sans' is only
commented out because there weren't substitutes and building it takes
forever and is massive. `pulseaudio' was me starting to try to play
around with audio, but I made no progress and spent very little time.
Hopefully that's a good starting point for others, and again, please
check out Ludo's script that I haven't had a chance to. My personal
ideal, which I think Ludo shares, is to be able to containerize any
program with sane defaults without having to write package definitions
like the one above, so he's headed in the right direction.
--
Mike Gerwitz
signature.asc
Description: PGP signature
Re: Do not use tor with browsers other than tor browser
s to download tor browser from the tor > project website. AFAIK, tor browser for GNU/Linux are built with free > software only. In the future, we may want to build it ourselves, but of > course we need to be careful not to introduce fingerprinting bugs. > > [0]: https://privacypatterns.org/patterns/Anonymity-set > > Thanks, > Alex > -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Problem with Tor & IceCat
On Sun, Jan 06, 2019 at 15:09:51 -0500, Joshua Branson wrote: > Now, when you start icecat, you may have to click on the tor plugin to > activate it, but it normally autostarts for me. > > Also, at least for me, that doesn't configure my browser to access tor > hidden services. But it does run all of your http traffic through the > tor network, which is pretty cool. That's concerning to me: it seems to imply that DNS requests are _not_ being proxied through Tor, which could leak very sensitive information to your ISP and other parties. I use FoxyProxy Standard[0] (just by habit over the many years I've used Tor with Firefox), so I hadn't tried the Addon distributed with Icecat. FoxyProxy has an option to proxy DNS requests through Tor (and does so by default IIRC). [0]: https://directory.fsf.org/wiki/FoxyProxy_Standard -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: GNU Icecat crashed tab
On Sun, Sep 30, 2018 at 04:27:11 +0200, nightowl wrote: > Thanks all for the help and advice on handling package upgrades and memory > management. I have been able to update my system now and use icecat version > 60. I can verify that the tab crash appears to be resolved with this new > version of icecat on my PC, however I also now notice that scrolling is not > as smooth as it used to be. I don't experience issues, but try disabling "smooth scrolling" in preferences. In past versions of IceCat/Firefox, I've had to disable it on older hardware for performance reasons. -- Mike Gerwitz signature.asc Description: PGP signature
Re: GNU Icecat crashed tab
On Thu, Sep 27, 2018 at 03:36:40 +0200, nightowl wrote: > I am currently using version 52.6.0 (64bit). That looks like the latest > released version. The guix package command also reports this as the latest > version. How do you get to version 60? Run `guix pull' before `guix package -u`. The latest version is 60.2.0-gnu1. -- Mike Gerwitz signature.asc Description: PGP signature
Re: GNU Icecat crashed tab
On Wed, Sep 26, 2018 at 04:38:33 +0200, nightowl wrote: > I am running GuixSD on a 2008 model Dell Inspiron with I believe to be an > Intel T5300 core 2 CPU. I have only just started using GuixSD for less than > a year now, and still on the learning curve. So, do you think the tab crash > I see with Icecat could be related to the hardware on my PC? I had experienced tab crashes with IceCat for certain sites that used JavaScript, like meet.jit.si. I just upgraded to IceCat 60 and it now appears that I have no issues with that site. Can you try upgrading and see if that fixes your problems? -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Anyone having troubles with GRUB full disk decryption sometimes not decrypting?
On Sat, Sep 22, 2018 at 10:27:14 -0400, Christopher Lemmer Webber wrote: > Unfortunately, I have to sometimes try up to 30 times before it will > boot, because it either freezes at: > - right after "Slot 0 unlocked" > - right after the menu selection on the Grub menu is made, before >booting into the OS proper. I don't have this problem with my X200. Did you use full disk encryption with your X200? > But, before I ship my laptop in, figure I'd check...! Please let us know what you find. I'm sorry to hear you're having such a severe issue. -- Mike Gerwitz signature.asc Description: PGP signature
Re: Error: system: command not found.
On Wed, Jun 27, 2018 at 14:53:50 +, Jone wrote: > I have a problem: can not run system reconfigure. > root@guix ~# guix system --help > guix: system: command not found I had the same problem last night and I found (via strace) that it was looking for an sqlite3 guile library. Installing guile-sqlite3 into root's profile fixed the problem for me. I just didn't have the chance to report the issue yet. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Recovering from broken Guix due to GC'd derivations
On Mon, Jun 11, 2018 at 13:08:52 +0200, Ludovic Courtès wrote: > Hmm weird. Did you try running ‘guix gc --verify’? I don’t see how one > could end up in such a state, unless there’s some hard disk corruption > or something. That did it. It removed 83 packages, and pulling now works. Thank you! I'm sorry that I can't provide more information. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Recovering from broken Guix due to GC'd derivations
Hey, Ludo: On Sun, Jun 10, 2018 at 18:45:19 +0200, Ludovic Courtès wrote: > Hello Mike, > > Mike Gerwitz skribis: > >> Any pull or package install operations that I attempt give me an error >> like this (the exact derivation varies between my user and root, but >> they're both Perl): >> >> guix pull: error: open-file: No such file or directory: >> "/gnu/store/fq9583a3w3is0r1yrjxg1znfz2qkvg78-perl-5.26.2.tar.xz.drv" > > This cannot happen under normal circumstances, as we say. Could it be > that you run a Guix configured with a different ‘localstatedir’ than the > original one that populated /gnu/store? I've never done anything other than a normal `guix pull`. When I was working on the `guix environment` changes for containers months ago, I was using `pre-inst-env', but nothing other than that. I didn't provide any options to `configure' or anything change any other env vars. Since before March, I've just been using a vanilla guix (rather than my local git checkout). -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Recovering from broken Guix due to GC'd derivations
Hello, everyone: I'm running into a bit of trouble and I'd like to know the best/proper way to recover: Any pull or package install operations that I attempt give me an error like this (the exact derivation varies between my user and root, but they're both Perl): guix pull: error: open-file: No such file or directory: "/gnu/store/fq9583a3w3is0r1yrjxg1znfz2qkvg78-perl-5.26.2.tar.xz.drv" Or, if I try to pull using a local git repo: guix pull: error: build failed: opening file `/gnu/store/4417linxb223padiqavsf6xah7nvjwrh-perl-5.26.1.drv': No such file or directory I had an old ~/.guix/config/latest symlink that I tried restoring (I don't have ~/.guix/config/current yet), but no luck. This seems to have happened after running a `guix gc`, after having aborted a `guix pull`. I forget the reason that I aborted---it's been about a week since, but it was a kernel-related issue requiring a hard reset. perl-5.26.2.tar.xz, or a similar version, was one of the packages downloaded during that pull. I'm not familiar enough with guix to know how to recover from this. Any suggestions? Thanks. -- Mike Gerwitz signature.asc Description: PGP signature
Re: Nitrokey and udev rules
On Fri, May 25, 2018 at 16:46:57 +0200, Pierre Neidhardt wrote: > 1. I can't seem to be able to change the PIN with any pinentry but > pinentry-gtk-2: I have this in my ~/.gnupg/gpg-agent.conf: pinentry-program /run/current-system/profile/bin/pinentry Maybe you can try something like that? > 2. After transfering my encryption key and my authentication key, `gpg > --card-edit` segfauls: I haven't experienced segfaults so I can't provide any insight there. Maybe attaching a debugger can provide some insight. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Nitrokey and udev rules
On Fri, May 25, 2018 at 07:22:57 +0200, Ricardo Wurmus wrote: > This sounds like you’ve installed the package into the system profile. > If this works we should probably add a system service that takes care of > setting up this directory. I'd love to have a service; I just haven't had the time to look into how to write it yet. I'm sure it's pretty easy to do, but I forget if there are any caveats to consider with pcscd. There may not be. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Nitrokey and udev rules
Pierre: On Thu, May 24, 2018 at 16:04:31 +0200, Pierre Neidhardt wrote: > Mike Gerwitz <m...@gnu.org> writes: [...] > I did: > >> sudo pcscd >> gpg --card-status > gpg: selecting openpgp failed: No such device > gpg: OpenPGP card not available: No such device > > Can you share your udev rules? I don't have any udev rules that weren't included by default with GuixSD. The packages I installed are: gnupg, pcsc-lite, ccid, and pinentry. I used to know how to debug this problem very well back when I contributed the pcsc-lite package, but it's been a couple years, but I can try to help you through this. Looking through my notes, it looks like I symlinked `/run/current-system/profile/pcsc/drivers/' to `/var/lib/pcsc/drivers'. See Marius Bakke's message on ccid here: <87vawczpb2.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me>: https://lists.gnu.org/archive/html/guix-devel/2016-10/msg01433.html Can you see if that solves your problem? While we're at it, here's my dmesg output for the Nitrokey Pro: --8<---cut here---start->8--- [17145.084169] usb 6-2: new full-speed USB device number 9 using uhci_hcd [17145.269203] usb 6-2: New USB device found, idVendor=20a0, idProduct=4108 [17145.269211] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [17145.269215] usb 6-2: Product: Nitrokey Pro [17145.269219] usb 6-2: Manufacturer: Nitrokey [17145.269223] usb 6-2: SerialNumber: 3C75 [17145.276690] input: Nitrokey Nitrokey Pro as /devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/0003:20A0:4108.0009/input/input21 [17145.336410] hid-generic 0003:20A0:4108.0009: input,hidraw0: USB HID v1.10 Keyboard [Nitrokey Nitrokey Pro] on usb-:00:1d.0-2/input0 --8<---cut here---end--->8--- And `pcscd -f' output (which looks bad, but `gpg --card-status' does work): --8<---cut here---start->8--- ifdhandler.c:150:CreateChannelByNameOrChannel() failed 0023 readerfactory.c:1106:RFInitializeReader() Open Port 0x20 Failed (usb:20a0/4108:libudev:0:/dev/bus/usb/006/009) 0006 readerfactory.c:376:RFAddReader() Nitrokey Nitrokey Pro (3C75) init failed. --8<---cut here---end--->8--- If you're still having a problem then we can continue from that point. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Nitrokey and udev rules
On Tue, May 22, 2018 at 12:53:43 +0200, Pierre Neidhardt wrote: > I'm trying to use my nitrokey on GuixSD. I use a Nitrokey Pro on GuixSD. >> gpg --card-status > gpg: selecting openpgp failed: No such device > gpg: OpenPGP card not available: No such device Have you started pcscd? We don't yet have a service for it, so that needs to be done manually. When I first log in, I run it as root (just `sudo pcscd'), and then `gpg --card-status` works as expected. Can you give that a try? -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Librem
On Fri, May 04, 2018 at 10:15:56 -0500, Christopher Lemmer Webber wrote: > Pierre Neidhardt writes: > >> Chris Marusich <cmmarus...@gmail.com> writes: >> Any Librem user out there? > > I'm running a LibreM 13. GuixSD worked perfectly out of the box. It's > nice to run GNOME again (after not having working OpenGL for ages on my > x200). The hardware kill switches for wifi / camera / microphone are > also nice. It's only been a week, but my impression so far is: if you > can afford to fork over the cash for it, it's worth it. Awesome to hear; thanks for sharing. You mentioned a more thorough review in the future on the fediverse; do CC it here! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Running IceCat in a container
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. :-)
Oh, this is interesting. I won't get a chance to try this out until
tomorrow, but I think it's a good start.
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.
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.
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.
I think this gives us a lot to move forward with, and some good
discussion to have. A lot of subtle details will have to be worked out,
like what default behavior should be.
Anyway, here's what I have so far. I still have to get sound working; I
took a pause on that, not having spent more than a few minutes on it;
I'll get back to it hopefully in the next few days. If anyone else
knows exactly what needs to be done, please lmk.
#+BEGIN_SRC sh
~/guix/pre-inst-env guix environment \
--container \
--link-profile \
--no-cwd \
--user=user \
--network \
-r "$gc_root" \
--expose=/etc/machine-id \
--expose=/tmp/.X11-unix/ \
--expose=$HOME/.Xauthority \
--share=/dev/snd \
--share=$HOME/.mozilla/ \
--share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \
--ad-hoc mtg-icecat-containerized \
-- \
icecat --display=:0.0 "$@" \
#+END_SRC
#+BEGIN_SRC scheme
(define-module (mtg personal)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix packages)
#:use-module (gnu packages)
#:use-module (guix build-system trivial)
#:use-module (gnu packages gnome)
#:use-module (gnu packages gnuzilla)
#:use-module (gnu packages fonts)
#:use-module (gnu packages fontutils)
#:use-module (gnu packages pulseaudio))
(define-public mtg-icecat-containerized
(package
(name "mtg-icecat-containerized")
(version "1.0")
(home-page "https://mikegerwitz.com/;)
(build-system trivial-build-system)
(source #f)
(native-inputs
`(("fontconfig" ,fontconfig)))
(build-system trivial-build-system)
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let* ((share-dir (string-append %output "/share"))
(cache-dir (string-append %output "/var/cache"))
(bin-dir (string-append %output "/bin"))
(fc-dir(string-append share-dir "/fontconfig/conf.avail"))
(fc-mtg(string-append fc-dir "/52-mtg-container.conf"))
(fc-cache-dir (string-append cache-dir "/fontconfig"))
(fonts-dir (string-append share-dir "/fonts")))
;; 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 "
" (string-append (assoc-ref %build-inputs "font-dejavu")
"/share/fonts") "
" fc-cache-dir "
\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")
(propagated-inputs
`(("icecat" ,icecat)
("zenity" ,zenity)
("font-dejavu" ,font-dejavu)
("pulseaudio" ,pulseaudio)
;;("font-adobe-source-han-sans", font-adobe-source-han-sans)
))
(synopsis "GNU IceCat packaged for running within a container")
(description
"GNU IceCat packaged with various fonts (including multi-lingual).
Suitable for use within a container.")
(license license:gpl3+)))
#+END_SRC
--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com
signature.asc
Description: PGP signature
Re: Running IceCat in a container
On Wed, Jan 17, 2018 at 15:20:44 -0800, Leo Famulari wrote: > You can use (source #f) with the trivial build system for metapackages. > > Check out the package definitions of 'gnome' and > 'gnome-default-applications' in gnu/packages/gnome.scm for some > examples. Ah, great, thank you! I tried looking for examples, but it looks like I never expected #f and inadvertently filtered the line out of my grep results. Those will be very helpful. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Running IceCat in a container
On Tue, Jan 16, 2018 at 21:25:19 -0500, Mike Gerwitz wrote: > On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote: >> Perhaps you could define a package that simply runs “fc-cache” with the >> fonts it has as inputs, and then pass that to ‘guix environment’. > > Oh, interesting; I wouldn't have thought of that. Actually, I could use a little bit of help. After hours of fontconf research and related stuff (more than I ever cared to know), I think I'll be able to get away with running fc-cache as you suggested using a package. My ultimate goal I think is to still use the user's fonts, but I still don't know a way to do that, since the /gnu symlinks are unavailable within the container.[0] It _does_ work if the links are identical between the host and cointainer---e.g. copying the font files into ~/.local/share/fonts, but that's obviously undesirable. Unless you happen to know a good way to selectively expose those to a container. With that said, I'm having trouble creating a package: it wants a `source' field, but this is a metapackage of sorts, and I didn't intend on having any source files; I can generate them using the builder and trivial-build-system. How can I work around this? Thanks. [0]: What seems to be the case---which is probably obvious to anyone who knows about this stuff---is that X11 on the host (since we're sharing the socket) needs access to the font in addition to the software running in the container. I don't think this is the case for traditional X11 fonts (not using fontconf), but I'm not dealing with those. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Running IceCat in a container
On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote: > “guix environment -C” makes $PWD shared; if you do (cd /tmp; guix > environment -C …), then /tmp is shared but not $HOME. I am doing that (I made a ~/.empty so as not to expose /tmp contents), but that still creates the home dir (as documented): $ pwd && guix environment -C coreutils -- ls /home /tmp mikegerwitz >> Is there a reasonable solution here? Should I create a separate user >> entirely and then just share the entire home directory? I'm not sure >> how that might impact X11 socket sharing, though. Can I maybe >> pre-create an image, already having run fc-cache, and run that image as >> a container (like one would with Docker?)? But that wouldn't solve my >> user privacy issue. > > Perhaps you could define a package that simply runs “fc-cache” with the > fonts it has as inputs, and then pass that to ‘guix environment’. Oh, interesting; I wouldn't have thought of that. If there is a general solution/script, I think this needs to be considered---automatically including system fonts; any program that displays text needs a broad range of UTF-8/multi-lingual font support. If I were to containerize my shell, I'd have the same problem. > But really, we should make a specific tool for this. > > Thoughts? Yes, though I'd be curious how you'd approach it---each package requires certain paths be shared, and those paths would further depend on user privacy preferences, so need to be able to be overridden. Perhaps it'd be useful for those paths to be part of a package definition---the paths that a program creates/uses at runtime, and perhaps additional metadata associated with them, such as whether the path is necessary for its operation (will it break the program if it's ephemeral or read-only?). Something extensible for the future. Those directory metadata may have other uses that may make it worth adding, but I haven't given it much thought. For example, if a user wishes to purge a package from her system, she could opt to purge those paths from her home directory. Or maybe Guix could create a backup of user preferences such that a restoration would involve only a list of packages and a tarball of those directories. Might be useful for provisioning as well. Just some thoughts. I'm too new to Guix to provide much. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Running IceCat in a container
Hello, everyone: I'm running IceCat in a container, with the goal of isolating it form the rest of my system as much as possible without running a full VM. Here's what I have so far: #+BEGIN_SRC sh guix environment \ --container \ --network \ -r "$gc_root" \ --share=/tmp/.X11-unix/ \ --expose=/etc/machine-id \ --share=$HOME/.mozilla/ \ --share=$HOME/.cache/mozilla/ \ --share=$HOME/.Xauthority \ --share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \ --ad-hoc icecat coreutils -- \ env DISPLAY="$DISPLAY" icecat "$@" #+END_SRC The most difficult problem I'm having is dealing with fonts. Specifically, I want to share the system fonts (/run/current-system/profile/share/fonts). The problem is, I can't just expose that directory, because it symlinks into the store, and those derivations don't exist within the container. - I do not want to expose all of /gnu. - I can provide the fonts as inputs to the environment, but I do not want to have to run fc-cache every time I start the container, because that is very slow. Exposing the cache directory doesn't help since the derivation used in the container ($GUIX_ENVIRONMENT) always appears to be different than the font derivation used on my system, and also by my user. - I don't want to expose my user's entire ~/.guix-profile/. I'm making things difficult for myself because I want as little shared/exposed with the container as possible. To complicate things further, for privacy, I don't want my user exposed to the container via the name of my home directory; Guix creates that automatically. I haven't yet looked at the code to see what exactly it does. Is there a reasonable solution here? Should I create a separate user entirely and then just share the entire home directory? I'm not sure how that might impact X11 socket sharing, though. Can I maybe pre-create an image, already having run fc-cache, and run that image as a container (like one would with Docker?)? But that wouldn't solve my user privacy issue. Thanks, -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: "guix-latest" differs when two users run "guix pull" from same commit
On Thu, Dec 07, 2017 at 22:57:17 -0800, Chris Marusich wrote: > Chris Marusich <cmmarus...@gmail.com> writes: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Chris Marusich <cmmarus...@gmail.com> skribis: >>> >>>> When two users run "guix pull" using the same commit, two different >>>> versions of "guix-latest" get built. This surprised me, and in any case >>>> it seems inefficient to build the same version of Guix two times. Why >>>> do two different derivations get built? >>> >>> That’s a bug! :-) >> >> I see! Nice to know my suspicions were correct. > > Ludo, did you fix this recently? Anecdotally, I noticed that the > problem no longer occurs using a recent version of Guix. I still seem to have this issue. My workaround is to just manually symlink ~/.config/guix/latest to the same derivation as root's. Since Ludo said this behavior seems to be a bug, can I assume that it is safe to do so? -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Introducing GNUPaste
Key, Kristofer: On Thu, Dec 14, 2017 at 13:37:30 -0500, Kristofer Buffington wrote: > I am excited to share GNUPaste! This is a really simple web app > similar to paste.lisp.org built with Guile. I have a linode running it > from git on GuixSD. Please reconsider the use of "GNU" in the program name, since this isn't in any way affiliated with the GNU Project. I did notice one of your commits is titled "Initial commit prepped for being part of the GNU project". If you do wish to offer your software to GNU, please see: https://www.gnu.org/help/evaluation.html We'd be happy to review it. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: Skipping tests during install/build
On Sun, Feb 12, 2017 at 14:30:01 +0100, Ludovic Courtès wrote: > The short answer is “no”. The Boolean that determines whether tests are > run is an “input” of the build process, and thus it contributes to that > /gnu/store hash. Changing it leads to a different hash. I was hoping for a `guix package -i --dont-do-this` kind of flag, not changing the inputs. > I think it’s a feature, though. :-) It is. I'm just looking to selfishly subvert your good intentions. :) > The intent is to have as much as possible available as substitutes. > However, while this works well for x86_64, the other platforms are not > in as good a state. Oh, I want to be clear that I don't have a problem with the state of ARM substitutes in itself; like I said, I'm surprised there are as many as there are. > So I think it’s a chicken-and-egg problem. Reporting the problems that > you have on ARM (test suite failures, build failures, etc.) can help > raise awareness and get people to fix things more quickly. Yep, will do. Thanks. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
Skipping tests during install/build
Hello, everyone: Is there a way (without screwing anything up) to skip tests during a build? I understand that this is generally unwise---I don't want to debate those merits. My immediate problem is that I'm on a dinky little ARM C201 Chromebook and any sort of building is quite time-consuming, and often prohibitively so: I can deal with the compilation times, but the tests are simply too much; I don't have time to wait potentially hours for software to build if they aren't available from hydra. GnuTLS is one particularly intense dependency test-wise, for example. And then if a test fails for whatever reason, I'm completely out of luck. I'd rather install and then run tests later at my leisure, accepting the risks. But I don't know if any test output is taken into account in any Guix hashes. There are a few situations where I've had no choice but to fall back to installing the respective Debian package(s). But I've been very impressed with how many ARM packages _are_ available from hydra---many more than I had expected! Anyway: any suggestions? :/ -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 Old: 2217 5B02 E626 BC98 D7C0 C2E5 F22B B815 8EE3 0EAB https://mikegerwitz.com signature.asc Description: PGP signature
