<bavier>otherwise, you'll want to pass --keep-failed to `guix system reconfigure`
<bavier>apa512: also, have you considered upgrading to guix-0.9.0 ;)
<apa512>erik@guix ~$ guix --version guix (GNU Guix) 0.9.0 Copyright (C) 2015 the Guix authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
<civodul>is there anything we can do to fix this issue if the sysadmins don't help?
<alezost>fps: apparently running Guix commands in several Emacs instances at the same time is not a common practice, as you are the first who asked about it, but I agree that the error message is not useful at all. I'll look at improving the situation, thanks!
<fps>While this program runs, listen on a local port or a path for REPL clients. If p starts with a number, it is assumed to be a local port on which to listen. If it starts with a forward slash, it is assumed to be a path to a UNIX domain socket on which to listen.
<noname>I just tried running guix system init /config-without-mounts-of-trisquel-and-storage.scm /mnt and it took 45 min to sync the substitutes and 34 min to download them (again) despite every one of them already being in the store from the previous installation to the same partition.
<noname>Now booting to see if it made a difference. (I installed twice to the same partition)
<mark_weaver>noname: you can only use 'guix system reconfigure' from within an already-installed GuixSD system.
<mark_weaver>noname: iiuc, if you reboot the USB installer, then you are basically starting from scratch again and cannot benefit from the things you downloaded on the previous attempt.
<mark_weaver>once you get a working system that you can boot from, then mistakes in the future do not cause such problems, because you can always boot into an earlier generation of your system that works. but mistakes during the initial install are expensive to recover from I'm afraid.
<noname>I know. Could we change guix system init to make it possible to tell it to check the contents of /gnu/store and the db on the target BEFORE dancing with hydra etc
<mark_weaver>I don't know, I never tried doing that right after an install
<noname>Is it possible that I found a bug in the guix system init: it does not create the dirs that dmd needs to mount the filesystems at boot?
<mark_weaver>noname: there's an optional 'create-mount-point?' field in 'file-system' specifications, which defaults to #f. I guess maybe you need it to be #t if you didn't arrange to create those mount points yourself on the root partition.
<civodul>fps: /gnu/store/*guix*/bin/guix-daemon is another solution
<fps>civodul: that one doesn't have the new option to test though. hmm. then in the checkout with the patched daemon, this should work: sudo ./pre-inst-env ./guix-daemon --build-users-group=guixbuild --cache-failures --cache-timeout-failures ?
<fps>yep, stuff happens. ok. now i can go to sleep safely and see how it turns out :)
<fps>hmm. i meant i just did for n in `./pre-inst-env guix package -A | cut -f1`; do ./pre-inst-env guix build .... || true; done from the git clone where i have 0.9.0 checked out and some things build.. but not all
<pirfle>Now I'm here again. Have sb got an idea about my problem (^21:44)?
<fps>and started the guix-daemon from the git clone which i have on the branch with the patch for --cache-timout-failures
<codemac>I'd rather not fix this and have it break people that do have stack size limits, etc
<codemac>the problem here is that the apply-test never exits, and my suspicion is that the test is trying to hit the upperlimit of how many (apply it can call in a row.. but now that I'm looking at the code it's not as clear to me.