***DusXMT_ is now known as DusXMT
***svetlana is now known as gry
<mark_weaver>sneek: tell civodul how much free disk space is typically needed on build machines? <sneek>civodul, mark_weaver says: how much free disk space is typically needed on build machines? <mark_weaver>sneek: later tell civodul how much free disk space is typically needed on build machines? <jmd>mark_weaver: And more importantly on which device? <mark_weaver>(although on this particular machine I just use one big filesystem) <jmd>Doesn't sneek have an "ask" command? <mark_weaver>indeed, it does, though I didn't know that until a few minutes ago :) <jmd>I have a /tmp with 5GB <jmd>and a /gnu with 64GB <mark_weaver>the machine in question has more than enough space to build the packages that I have in my personal profile, but I suspect that a hydra build slave needs much more. <jxself>I seem to recall it was hundreds of gigabytes needed. <jxself>But perhaps I'm not remembering correctly. It's been a while since seeing the numbers. <mark_weaver>currently the machine has about 128G free, after building all of the packages in my personal profile. it may be that I'll need a larger disk. <mark_weaver>there are a lot of builds on the machine that could be removed, but I don't like the way "guix gc" currently works, because if I did, the next time I built something it would have to build a lot of prerequisites first. <mark_weaver>(I need a "guix gc" that protects anything that would need to be needed to build anything in current master) <jmd>install all packages ? <mark_weaver>well, that would almost work, but a few problems: (1) especially in the early bootstrap, not all of the needed derivations are easily specified on the command line, (2) I don't actually want to build everything yet; I just don't want to delete anything that would be useful for building something I might want to install or upgrade later. <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, mark_weaver says: how much free disk space is typically needed on build machines? <civodul>mark_weaver: i think roughly 100G per architecture <mark_weaver>so all you need is the ability to ssh in and run guix? <civodul>actually even less because currently it's only using part of it <mark_weaver>what's the status of the current MIPS build machine? is it working at al? <mark_weaver>civodul: when running a newly installed copy of guix, after "make install", I get a warning about source file /share/guile/site/2.0/guix/config.scm being newer than config.go. <mark_weaver>the difference in the modification times of those two files is less than 1/10 second. <mark_weaver>but indeed, the .scm file is slightly newer than the .go <mark_weaver>presumably the files were installed in the wrong order? <mark_weaver>civodul: okay, I set up a "hydra" account on the Loongson 3A machine. I just need to get an ssh public key from you and then you can log in. <Steap>So, I did "rm -rf /gnu" and tried reinstalling Guix using the 0.6 tarball <Steap>$ ./pre-inst-env guix package -i hello <Steap>guix package: error: open-file: No such file or directory: "/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv" <Steap>any idea of what's happening ? <davexunit>Steap: I don't think removing /gnu is enough. there's stuff in /usr/var/guix, too <Steap>davexunit: thanks, looks good! <DusXMT>Steap: I recommend installing from git, as I've had problems with `guix pull' on guix from the 0.6 tarball <Steap>DusXMT: yes, but you need libgcrypt to install from git, iirc <Steap>and it's in a weird location on Debian <Steap>so I wanted to try to install libgcrypt using guix 0.6 <Steap>and then go back to guix-git :) <Steap>Not sure whether we should tweak the build system of Guix to handle this case <mark_weaver>Steap: fwiw, the last time I built guix from git on wheezy, I didn't need to specify --with-libgcrypt-prefix= <mark_weaver>I only have to specify it when building within a guix environment. <Steap>mark_weaver: right, it seems to work <jmd>When is guix going to be able to handle https in urls ? <mark_weaver>I'm looking at a recent log of downloading the tor source code on my machine, and it successfully downloads from an https URL. <mark_weaver>I'm using a guix that was built within a guix environment. <mark_weaver>I guess it has to do with your gnutls, or perhaps your certificate configuration. <civodul>mark_weaver: ok, will send you the public key <mark_weaver>jmd: I should mention that I'm carrying a local patch for guix's gnutls package that allows it to use my system trust store. <mark_weaver>not sure if that's affecting the outcome here or not. <mark_weaver>also, I have: export SSL_CERT_FILE="/etc/ssl/certs/ca-certificates.crt" <jmd>But it doesn't work in guix build either <jmd>;;; Failed to autoload make-session in (gnutls): <jmd>;;; ERROR: missing interface for module (gnutls) <jmd>ERROR: In procedure module-lookup: Unbound variable: make-session <mark_weaver>I don't know how downloading works in Guix. it seems to me that downloads can't be run within the usual build environment, because that environment has no net access. <mark_weaver>jmd: looks like the guile gnutls bindings are not in your guile load path. <civodul>jmd: that'll work if you use an https URL directly <civodul>here you're using an http URL, which gets redirected to https <civodul>and download.scm decides to add GnuTLS support iff the URL is https <civodul>mark_weaver: the build environment for downloads is lightweight, no chroot or anything <civodul>yes, it's a derivation, but of the "fixed-output" kind <civodul>meaning that the hash of its result is known <civodul>these are run in that lightweight environment with network access <mark_weaver>civodul: why do the build slaves have to be configured to trust the central server? <civodul>because they receive inputs from there <mark_weaver>hmm, so it means that is hydra.gnu.org is compromised, then all of the build hosts could be compromised as a result. <civodul>it's a build farm, not a set of isolated hosts <mark_weaver>well, okay. I don't need to trust this machine anyway. <mark_weaver>I do think that the security design of the build farm could be improved though. <mark_weaver>so "guix archive --authorize" is to be run as root, presumably? and I just pipe in the s-exp you sent me from your ../etc/guix/signing-key.pub ? <mark_weaver>civodul: okay, I think it's all set up. I just emailed you the info. <mark_weaver>civodul: okay, I think it's all set up. I just emailed you the info. <mark_weaver>civodul: do you think it's a problem that I pass --no-substitutes to the guix-daemon running on that build slave? <mark_weaver>also, it's a quad core machine, in case that matters on your end. <civodul>mark_weaver: it's actually necessary to do it <civodul>the number of cores is automatically used as the number of jobs <mark_weaver>okay, I add --cores=4 to the guix-daemon line, because the cores are hotplugged on demand somehow (strange kernel config that lemote uses for it)