<dvn>new to guix. using it on a foreign os. I installed glibc locales, and set the path but I'm still getting this error: warning: failed to install locale: Invalid argument
<Digit>sat looking at my unupdated gentoo, realising it's only going to get scarier to update the longer i leave it... and gets me thinking of guix again... and how safe one feels when performing system upgrades with the knowledge of clean roll-back.
<jmarciano>dvn: if you as user get the error, you can put this in environment: export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
<jmarciano>if one of guixbuilderXX get the error, you can ignore. I had the same problem.
<dptd>I have downloaded USB installation image. Converted it to the VirtualBox VDI. Mounted and booted. I follow the official instructions (started ethernet, started cow-store, modified sample system config and run guix system init). However tests/store tests keeps failing. I cannot find logs anywhere. :\\
<dptd>wingo: Thanks. Actually when I will be done I will probably post somewhere step-by-step instructions how to install GuixSD in VirtualBox.
<davexunit>you must run 'guix pull' beforehand, otherwise you *will not* receive pre-built binaries
<davexunit>because 0.9.0's binaries have long since been garbage collected.
<davexunit>our next release will make it more clear that you need to run 'guix pull' immediately
<dptd>I have done everything according to the official instructions. I am trying to install GuixSD in VirtualBox. I downloaded newest usb installation image, converted it to the VirtualBox VDI and mounted. I successfuly booted this image. Created partitions (boot and root) and labeled root. Mounted it, started cow-store and copied sample desktop config to /mnt/etc. Edited the sdX in the config. After that I actually have
<dptd>run guix pull and after that guix init /mnt/etc/config.scm /mnt --fallback.
<dptd>And - as I wrote before - it failed. Last prints in buffor were tests run summary (2 skipped, 1 failed).
<dptd>davexunit: Okay, I am done. This time it failed on "guix substitute: error: host name look up error Name or service not known". It is the result of running system init with --substitute-urls set to mirror.
<davexunit>dptd: did this failure happen immediately or did it successfully download some things?
<ajgrf>if i'm packaging something from git instead of a tarball, how do i know which hash to put in the package definition?
<Jookia>ajgrf: usually i just build then get the new hash from the failure
<davexunit>dptd: if it was a spontaneous error, all I can recommend is to try again. our servers are simply overloaded, unfortunately, and it sucks. we're actively working on getting new servers but it's going to us some time.
<davexunit>ajgrf: the correct way to calculate the hash of a git repo is to create a clone of that repo that you can safely throw away, checkout the commit you are interested in, *delete* the .git directory, and run 'guix hash -r .'
<rain1>is there a reason to do it that harder more complex way?
<dptd>davexunit: Yeah, I can see that. People are writing that here all the time. Not a problem though, thanks for the help. Answering your question - it is spontaneous error. Some staff is being successfully downloaded.
<dptd>Strange. I am during the guix system init and after transferring python from hydra it is stuck with such message. "killing process 20719" and the line below "killing process 20719: no such process".
<dptd>I am waiting more than 10 minutes now - nothing changes. Anyone have seen something like that before?
<efraim>I've seen it occasionally in a terminal window where I _wasnt_ building software
<efraim>I ignored it and waited to see if anything broke but it seemed ok
<rain1>and if its a keyfile rather that password entry it cant ask you twice :)
<mark_weaver>normally with that setup, you need to type in your disk password twice: once for grub and once for linux
<mark_weaver>hmm, libotr-4.1.1 is consistently failing one of its tests on my yeeloong
<tg>fbut why would anyone put their encryption keys in grubcfg?
<mark_weaver>tg: actually, I think it was probably the initramfs, not the grub.cfg
<mark_weaver>but there is one reason: if the purpose of the encryption is to protect against a compromised HDD firmware
<mark_weaver>but setting that aside: on a Libreboot/GuixSD fully-encrypted disk setup, since the initramfs is stored on the encrypted root partition, in theory it could contain the disk key to avoid typing the password a second time.
<mark_weaver>however, on GuixSD the initramfs is in /gnu/store, and everything there is world-readable
<mark_weaver>Guix does not currently have any provision for secret data within the stuff that it builds.
<jmarciano>secret data could be on the USB, or it should be left to user how and from where to slurp secret data.
<jmarciano>it would be insecure to fix it in GuixSD configurations.
<jmarciano>my password is sha256 password from a plain text password... I like it that way.
<NiAsterisk>jmarciano: one option later could be to ask users in a non-specified graphical setup assistant dialogue to set encryption options, like some *buntu do now or whatever distros these days do.. I haven't looked outside of Tails, Gentoo and others the last years on desktop systems. some started including encryption I heard.
<jmarciano>GuixSD will give more control to the user. I can create system.scm or something, and always get what I want and nobody else.
<suitsmeveryfine>Hmm, is there a delay before emails are delivered to the devel-list?
<civodul>suitsmeveryfine: the first message can take an hour or two; subsequent messages directly get in
<suitsmeveryfine>Thanks civodul. I'll then just send this warning to any MacBook2,1 users here that might be thinking of building from master: DO NOT try to suspend to ram in Gnome 3. It just corrupted my file system.
<lfam>I'm still having trouble with https substitutes on my "foreign distro" system. I think that I must have done something to root's copy of guix (used by all users) that is preventing it from upgrading
<mark_weaver>closing the lid hasn't worked for me on the Libreboot X60, but choosing "logout" from the Xfce menu and then clicking on "suspend" works for me now
<mark_weaver>test_auth_clear in test_auth.c never initializes the context. there's a missing call to otrl_auth_new(&ctx);
<mark_weaver>it works by accident on some platforms, presumably because of the way those static test functions get inlined together into the same parent function
<lfam>civodul: I confirmed with strace that `guix substitute` is using the same code as that of the current master branch. However, I find that when I run the daemon from a root shell, I can fetch over https! It's only when running the daemon with systemd that things go awry. But, the systemd service file executes this file: /root/.guix-profile/bin/guix-daemon, which is what I am running in that root shell.
<lfam>Also, when running the daemon from root's shell, if my regular user does not ask for an https substitutes-url, I fetch from http://hydra.gnu.org, rather than some https URL. I'm not sure if that is expected or not.