<alezost>jin: in any way you need to use a config file (with operating-system declaration), and you probably need to set 'initrd' field to exclude that module. Wait a minute I'll show how it should look like
<lfam>calher: I think that page is very liberal in its use of HTML, and also w3m is not actively developed for several years now.
<alezost>jin: 'base-initrd' procedure does not provide a way to exclude modules, so I can think only of putting a modified version of 'base-initrd' into your config. Maybe there is a more elegant variant, but I think it's ok for testing purposes. So config.scm should look like this: <http://paste.debian.net/366224>. Then you can "guix system reconfigure config.scm" and check your keyboard
<alezost>jin: I wish you luck with this horrible keyboard issue. it's time to sleep for me, so I'm out
<calher>i installed Guix from the documentation's guide
<calher>how do i get the guix info pages in my documenation system...
<davexunit>set INFOPATH to point to the directory the info manuals live in
<Jookia>I'm compiling coreutils on my T400 and a test to do with sparse copying is failing- is there a way for me to step through the build process until I get to the tests then fiddle a bit?
<lfam>Jookia: If the coreutils Guix package is failing that definitely deserves a bug report. As far as your question, I don't know the absolute best way. Something like `guix environment --pure coreutils` will make your environment match that of Guix's coreutils build process. Then, you can manually try building coreutils in that environment until you get to the failing test, and play around from there.
<lfam>Okay, I don't know if that will make your environment match that of the Guix builders. But it will unset all your other environment variables, and give you the environment you need to build coreutils. It may be a pain without your normal $PATH, so you can add stuff with --ad-hoc, like this: `guix environment coreutils --pure --ad-hoc coreutils`. That way you have a working coreutils at your disposal. You could repeat --ad-hoc to bring in
<Jookia>Is there a way I can Guix to use my own set of packages?
<lfam>Jookia: Yes, you can create package modules anywhere on your filesystem as long you point the environment variable GUIX_PACKAGE_PATH at them. But you should also consider contributing new packages to Guix!
<Jookia>Maybe I will, I'm currently sizing it up against NixOS if you can tell
<Jookia>I wonder if the 'right' way to do this is to load the builder in to a REPL and hit breakpoints somehow
<Jookia>lfam: The reason I ask is that I'm bootstrapping from a Trisquel live USB and having a Guix package set in RAM isn't useful
<lfam>You'll probably get better help on this channel in a few hours, if people come around on Sunday. Otherwise, on Monday.
<Jookia>That'd be great, though I have to learn on my own if I'm going to become the best there ever was at bootstrapping Guix
<lfam>Lol, you have to stand on the shoulders of giants to get there
<Jookia>I wrote the bootstrapping guide for NixOS which is coming in handy
<lfam>So far I've mostly focused on packaging so I really can't offer much help with bootstrapping GuixSD. But there are quite a few wizards here
<Jookia>I'm up for writing documentation (the best part)
<lfam>I have also helped with that :) The manual can always be improved
<Jookia>Can you run a Guix container as a system service?
<civodul>davexunit: re PDF of your talk: looks good!
<civodul>davexunit: the intro is very nice, makes the case against Docker and status quo, i like it
<calher>"Usually, you will want to specify the default locale for the machine using the locale field of the operating-system declaration (see locale)." Well, I don't have an OS decl. because I'm on Trisquel.
<paron_remote>davexunit: I had a few people who are non-programmers listen to my "warehouse full of black box containers vs warehouse full of containers built and rebuilt by robots with lists of instructions" metaphor and say it was quite compelling