<aeva>I'm having trouble booting the live install usb... I downloaded the 0.9 x86_84 xz file, verified the signature (would be great if the docs included info on how to get the public key - that is not obvious information), extracted it, dd'd to a usb stick, and attempted to boot to it. In libreboot's grub prompt, I hit "search for grub configuration outside of CBFS", and then selected "Load Config from (usb0,1).
<mark_weaver>aeva, francis7: as I (vaguely) recall, when trying to boot a USB stick from Libreboot, I found that sometimes GRUB was unable to see the USB stick. it seemed to be sensitive to which USB port I used, when I plugged in the stick, which stick I used, and/or some amount of luck. I don't remember the details, but I remember it being somewhat flaky.
<mark_weaver>once I got GuixSD installed, I never had to boot from USB again, so it's been a long time since I tried it.
<aeva>I got the install got the install to finish, but upon reboot it does "failed to resolve partition 'root'" :/ and having trouble getting it to boot back into the usb >_>
<aeva>debating tearing the drive out and putting it into an enclosure and plugging it into another machine
<aeva>vs pulling the dock out and trying to make a live CD
<aeva>is there a way to set capslock as a ctrl key from the system config?
<lfam>I want to clarify the installation instructions but I don't want to make them too specific while glossing over the interaction between 'device' and 'title'. But I think that most users who need the step-by-step instructions will start by copying an example configuration. And once they are ready to use GuixSD with more complicated partition layouts, they will be more familiar with the options available.
<mark_weaver>aeva: in my OS config, I created a hacky 'anti-caps-lock-service' to do that job for the text consoles.
<aeva>I'm a fan of having "beginner" and "advanced" tutorials
<mark_weaver>but some files within /etc are actually (via symlinks) files in /gnu/store, and it's important that you don't edit those. in fact, it's mounted read-only on GuixSD to prevent accidental edits.
<lfam>I was thinking about this difference between GuixSD and NixOS earlier. On NixOS, the service changes take effect immediately, and the need for a reboot on GuixSD is annoying. But on the other hand, you never know what state there may be in services that NixOS doesn't think needs to be restarted. For example, if services foo and bar interact, and you edit foo.nix and then reconfigure, who knows what might happen with bar?
<davexunit>lfam: this isn't a deliberate decision, it's a known limitation
<lfam>Do you need a reservation? Maybe you should just give the restaurant's host or hostess $20 (or whatever amount is appropriate). Or just be courteous and hope for the best.
<mark_weaver>but, as usual, services can get away with this BS because almost no one reads the agreements, they just click the button that says "I've read and understood the agreement" without even looking.
<lfam>aeva: Writing documentation is tricky :P My order of operations was to start following the step-by-step instructions, referring to other parts of the manual as I needed them. I'm writing this patch for people doing their first installation because I figure that experienced users will know how to configure their file-systems in GuixSD. But if we can make something better, we should.
<lfam>And my rule-of-thumb is that for every person that complains, 10 people hit the same problem and don't say anything. So for 2 people to hit the problem in the same day, there must be a lot of us!
<aeva>I scanned the document, saw that there was a system config thing (I was looking for it because I heard about it from a friend who got me interested in trying guixsd), went and found some friends to share their configs, and then went through the steps in the document without looking at the configs in detail until a step called for it
<aeva>so, first was download the image and sig file
<aeva>second was waste half an hour trying to figure out how to verify the download, since I had to install someone's public key (that would be really good to include in the doc)
<aeva>third was spend about an hour getting the usb thing to boot
<aeva>fourth was quickly partitioning with cf - just deleted everything on the computer, made a partition for everything, and a partition for swap, set the first to be bootable, wrote changes and formatted
<aeva>then mounted under mnt, called the "cow store" thing, mkdir'd /mnt/etc, copied over the config....
<lfam>mark_weaver: Okay, on the GuixSD system I cloned the Guix source tree, applied the patch, reconfigured with ./pre-inst-env, and rebooted. The confusing thing is that all my generations seem to refer to the new grub. Of course, I didn't record the name of the old grub. Maybe I did something stupid when I was tired last night like initialize with the patch but I don't think so. Thoughts?
<lfam>aeva: Have you read about OpenBSD's `signify` program? It's basically just the features of gpg that are used for code signing, without anything else. An interesting middle ground.
<aeva>so `guix system reconfigure config.scm` seems to be recompiling everything when I thought it would install like three new programs and a few dependencies :/ - is there something I need to do to get it to just pull down the missing binaries?
<aeva>(and if so, if I killed this and did that thing instead, would that screw anything up?)
<aeva>like, its rebuilding the kernel right now I think o.o
<aeva>added rhythmbox, which is probably the most extreme
<aeva>other than that I think it was just xset and whatever I need for wpa
<lfam>I looked at the dependency graph of windowmaker. I'm sure that at least one of those changed between now and the 0.9.0 release (2015-11-04). So when you updated your package definitions with `guix pull`, the next reconfigure would want to get all the new packages.
<lfam>So, even if windowmaker itself didn't get updated, if one its dependencies did, you get a new windowmaker package. All packages are named for the hash of their dependencies, so a single change in the graph creates a new package. But duplicates are deduplicated in the store with hard links
<aeva>can't set the desktop background is the one I recall off hand
<aeva>a number of things if you tried to do them it would throw up a error that didn't say anything useful
<mark_weaver>aeva: there's another issue that might have bitten you: if you run "guix pull" as your normal user, that only affects "guix" commands run by that user. when you run "guix system reconfigure" as root, that will not use the new packages unless you also ran "guix pull" as root.
<lfam>But if you do then run `guix pull` as root, any duplicate work from your user's `guix pull` is re-used.
<mark_weaver>there's a hack to make this a bit nicer: "guix pull" makes ~/.config/guix/latest a symlink to the latest version of guix as compiled by "guix pull"
<mark_weaver>so, if you always want root to use the same version of guix as your normal user, you can make ~root/.config/guix/latest a symlink to ~aeva/.config/guix/latest
<mark_weaver>actually, what I do is this: I make both ~root/.config/guix/latest and ~mhw/.config/guix/latest symlinks pointing to my git checkout of 'guix', so all of my guix commands always use the version from my git repo.
<aeva>this is so different than what I am used to :)
<mark_weaver>lfam: on a GuixSD, the 'guix-daemon' used is the one from the "guix" package, and that only gets updated when our 'guix' package gets updated. so, my daemon is generally quite a bit older than my 'guix' command.
<mark_weaver>aeva: however, it should be noted that when you ask guix to build something, your 'guix' command (running as your normal user) asks 'guix-daemon' to perform the build. 'guix-daemon' is the only thing that's allowed to modify the store. when it performs builds, the builds themselves run within an isolated container and are run as an unprivileged user.
<lfam>mark_weaver: I don't understand — can you rephrase that?
<mark_weaver>unprivileged users can specify arbitrary package descriptions and ask guix-daemon to build them. if multiple users ask for the same package description to be built, it will only be built once.
<lfam>I meant your message about guix-daemon and living in the git checkout
<mark_weaver>lfam: it's a bit confusing, but 'guix' includes a package description for 'guix' itself.
<lfam>Wow, I didn't expect it to be in gnu/packages.
<mark_weaver>so, although the 'guix' command that I run (as a client to guix-daemon) is usually very close to the latest commit on our 'master' branch, the 'guix' package within 'guix' is at an older commit: 5c36edc
<mark_weaver>the 'guix-daemon' that is used by GuixSD is that older version.
<mark_weaver>so, my 'guix-daemon' only gets updated when we update the version of our 'guix' package within 'guix'.
<mark_weaver>but that rarely matters, because the package descriptions come from the client, not from the daemon.
<mark_weaver>any user can connect to 'guix-daemon' and send it a package description to build, and it will build it.
<mark_weaver>(within an isolated container as an unprivileged user)
<mark_weaver>and 'guix-daemon' provides the mechanism to allow multiple users who ask for the same package to avoid building it more than once, without allowing users to interfere with each other or compromise the security of the other users.
<mark_weaver>so, every user on a Guix system has the freedom to use their own customized packages. they are not tied to the set of packages chosen by the sysadmin.
<jlicht>Is there any place where progress of the fsf-suported donation drive is being reported?
<mark_weaver>jlicht: unfortunately not. even we don't have access to such a thing. we need to ask them periodically.
<jlicht>mark_weaver: any non-up-to-date updates in already?
<fps>then we have subsitutes that max out my downstream :)
<fps>too bad it's not possible per user it seems. had to sudo it since it wants to write /etc/guix/acl
<fps>iyzsong: or maybe also output a line in the guix package output a la "updated [...]/etc/profile"
<iyzsong>fps: yes, we can display a message when build the file, but I don't know how to detect the search-paths update or not.
<roelj>Somehow I have very poor network connectivity with the 'guix' command. Downloading the master.tar.gz takes a day, while downloading with a web browser (IceCat) takes a couple of seconds. (This is all on the same machine, with GuixSD)
<fps>roelj: weird.. it's downloaded from savannah, right? maybe it treats different clients differently?
<iyzsong>so many strange things happened on GuixSD :o
<efraim>ok, that passed on my machine, both with 5GB of /tmp and with 6GB of /tmp
<efraim>that test specifically tests for the cve, but it was commented out before the gtk-pixbuf security update
<efraim>I enabled it, but I'll go ahead and re-disable it with an updated message
<efraim>after I test that it still builds, should I rebase it on master?
<swedebugia>Regarding xfce4 does anybody know how to make the shutdown-buttons i the menu work? (They are greyed out)
<efraim>I have an old P4 machine that I'm thinking of setting up with i686 guix for secondary development, having seen how much space some builds take I'm thinking of splitting the original IDE drive 10G /tmp 10G swap and my 2.5" spinning rust drive my / drive
<efraim>swedebugia: there are people who know, unfortunately I'm not one of them
<anonymiss_>you need a specific group, forgot which one.. one sec
<efraim>mark_weaver: it works fine on all the other architectures, and when I was playing with building it before I got some weird errors with tests being skipped due to lack of ram or other reasons, and then it's group failing because not all of them were run
<stack>hello, I'm researching a way to encapsulate configuration for some daemons alongside the package dependencies to ship different vms, something like docker does, but using what guix or guixsd provides, is there something I can look at or should I use puppet or similar to ship services configuration in containers/vms?
<davexunit>stack: you want too look into guixsd's service API
<vmb>Can GuixSD use a proxy server for /gnu/store downloads?
<fps>vmb: it's a http service, so i think it could
<vmb>I don't have transparent proxying so have to configure proxy to use port 3128 - where?
<vmb>I have setup my first Guix install in the DMZ for now but would like to find the config item for allowing use of a proxy
<fps>vmb, oh, i misunderstood then.. i thought you would reverse proxy hydra.gnu.org
<lfam>I actually think it's worth keeping 0.9.0 if people are using your server. It helps new users, and they have the most "fragile" expectations. The rest of us are accustomed to waiting ;) Of course, that means they'd have to know about it and choose to authorize it.
<fps>lfam: well, at least until the next release..
<fps>i wondered about gc'ing everything that's _not_ 0.9.0 :)
<fps>it shouldn't be too hard to find out all derivation output paths for all packages in 0.9.0 and then try and gc everything else
<lfam>Or, we could make it so that if Guix detects that a system's first profile is being created, it would print a reminder to run `guix pull`. I feel like we get A LOT of people wondering why they are downloading / building everything, and it's always because they didn't `guix pull`
<lfam>Or, a user's first profile. That may be more effective