IRC channel logs


back to list of logs

***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>jmd: indeed!
<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.
<mark_weaver>(with an emphasis on "upgrade")
<civodul>Hello Guix!
<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>hello mark_weaver! :-)
*civodul checks
<mark_weaver>greetings civodul :)
<civodul>mark_weaver: i think roughly 100G per architecture
<civodul>that's what Andreas' machine has
<mark_weaver>ah, so I might not need to upgrade the disk. good!
<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
<civodul>yes, plus set up SSH and Guix keys
<mark_weaver>okay, I should be able to set that up soonish.
<mark_weaver>what's the status of the current MIPS build machine? is it working at al?
<civodul>it's been restarted recently...
<civodul>but it's unstable
<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>and I get
<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 :)
<DusXMT>Oh, that works then
<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>I'll try from Sid
<Steap>mark_weaver: right, it seems to work
<mark_weaver>that's good!
<jmd>When is guix going to be able to handle https in urls ?
<mark_weaver>it does
<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.
<jmd>Never has for me.
<mark_weaver>so "guix build -S tor" fails for you?
<jmd>try doing: ./pre-inst-env guix download
<mark_weaver>works for me.
<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>civodul: okay!
<civodul>jmd: "https URIs (HTTP over TLS) are supported provided the Guile bindings for GnuTLS are available in the user’s environment; when they are not available, an error is raised." <-
<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"
<mark_weaver>(which is appropriate on a Debian system)
<jmd>But it doesn't work in guix build either
<jmd>following redirection to `'...
<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
<jmd>Ahh. I see.
<civodul>mark_weaver: the build environment for downloads is lightweight, no chroot or anything
<civodul>so it can access the network
<mark_weaver>civodul: okay. it is run within guix-daemon?
<mark_weaver>(the download process, that is)
<mark_weaver>well, I can look into it myself...
<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 is compromised, then all of the build hosts could be compromised as a result.
<civodul>yes, and vice versa
<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.
<civodul>surely :-)
<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/ ?
<mark_weaver>civodul: okay, I think it's all set up. I just emailed you the info.
<civodul>argh emacs crash grmbl
<civodul>somebody talked to me before no?
<mark_weaver>civodul: okay, I think it's all set up. I just emailed you the info.
<mark_weaver>(I sent that just before you left)
<civodul>ah, perfect thanks!
<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>I could remove it if necessary.
<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>on build slaves
<civodul>the number of cores is automatically used as the number of jobs
<civodul>that should be fine
<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)
<civodul>oh, ok
<civodul>for now, good night/day!
<mark_weaver>okay, good night!