<xentrac>Hmm, so after 18'41" it failed again in the same place as before, specifically
<xentrac>starting download of `/gnu/store/5fsl6azm1imi4x69ajhl1yvb7n5frhf0-openldap-2.4.33.tgz' from `ftp://sunsite.cnlab-switch.ch/mirror/OpenLDAP/openldap-release/openldap-2.4.33.tgz'...
<xentrac>ERROR: In procedure getaddrinfo: Name or service not known
<xentrac>failed to download "/gnu/store/5fsl6azm1imi4x69ajhl1yvb7n5frhf0-openldap-2.4.33.tgz" from "ftp://sunsite.cnlab-switch.ch/mirror/OpenLDAP/openldap-release/openldap-2.4.33.tgz"
<xentrac>now it could totally be that sunsite.cnlab-switch.ch is no longer a working host
<xentrac>but I don't understand why that leads guix to rebuild GCC and Bison over and over again
<xentrac>I'm pretty sure that past Guix build failures I've experienced were able to immediately fail where they failed before instead of computing for 19 minutes first. But maybe those were actually `guix pull` failures and I'm just confused.
<xentrac>It's definitely compiling GCC again. This is so sad, you guys.
<mark_weaver>xentrac: when a build succeeds, it is committed to the store and will remain there unless deleted by 'guix gc'.
<xentrac>mark_weaver: Thanks! sorry I haven't gotten to that part of the manual yet
<mark_weaver>however, if you have enabled multiple separate builds to happen in parallel, then if one fails then the others are immediately aborted (if started by the same 'guix' command)
<xentrac>now it's building ATLAS from source. this is awesome!
<xentrac>Hmm, it seems to have been stuck on this part for quite a while: starting download of `/gnu/store/96fy8dgs9p818zi63ypqw83xp10myi5a-psutils.tar.gz' from `ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz'...
<xentrac>Hmm, well, it still hasn't made any visible progress on psutils
<xentrac>it's... blocked trying to read from a UDP socket connected to ip233.usw186.dsl-acs2.sea.iinet.com:fsp
<xentrac>that's the weirdest way to do "FTP" that I've ever seen
<xentrac>At this point it's been running for 43 minutes trying to fetch that file
<mark_weaver>wgreenhouse: I'm not sure what's the best approach, but for now I would start with something similar to 'configuration-template-service' and we can always change it later if we find a better idea.
<wgreenhouse>`user-skeleton-service' perhaps--a guixy counterpart to the traditional /etc/skel/ :)
<mark_weaver>so, we currently have something to do that, in 'copy-account-skeletons' in gnu/build/activation.scm
<davexunit>mark_weaver: yeah, well maybe for this particular case it's not a good idea, but it certainly seems to be the way to go for things like making sure a db cluster is created in /var/lib/postgresql and other such things
<codemac>yenda-: hi! it's going well, it builds and everything, but mark_weaver (rightly) wanted me to tease some stuff apart into build steps with gnu-build-system. I'm also developing a go-build-system, but I should probably hold off on that.
<mark_weaver>yenda-: why do you need to know the architecture to install CA certificates?
<mark_weaver>uname -m is best avoided, since it's not deterministic (depends on the particular machine details)
<mark_weaver>(%current-system) returns a nix system string, e.g. something like "x86_64-linux", but I don't see why you'd need it for this.
<yenda>mark_weaver: it's the debian script to build certificates
<xentrac>if this were a regular, non-guix build I think I would know what to do next: go into the build directory and rerun the test from the command line, possibly stracing and otherwise instrumenting various components until I figure out why the cookies aren't going into the cookie jar
<xentrac>but I can't go into the build directory because it isn't there any more
<xentrac>I should probably already know what that option is, shouldn't I? :)
<mark_weaver>wgreenhouse: at present, we lack the logic in our initrd (gnu/build/linux-boot.scm) to handle mounting an encrypted partition, so we do not yet support an encrypted root partition.
<xentrac>I don't know where to start looking. (and I still haven't finished reading the manual! shame)
<mark_weaver>xentrac: pass -K (--keep-failed) to any guix command that builds packages, and when a build fails the builx directory will be left in /tmp/nix-build-*
<xentrac>there's also the meta-question of how this situation could arise. presumably this version of curl has compiled successfully from these exact sources with these exact dependencies and compilers on many other guix users' machines
<xentrac>I suppose being able to re-execute curl's `make test` in a little isolated compartment, like the guix builder does, has to wait on davexunit to finish making those containers more generally usable?
<mark_weaver>even then, things might be somewhat different because now it's not in a build container, it can find things in /usr if it looks, etc.