<lfam>Is there a recommended way to prevent compilation of Guix packages from leaving a remote system completely unresponsive? Like, could I tell systemd to adjust the nice-level of guix-daemon.service?
<lfam>Does all the compilation stay within that process hierarchy?
<lfam>Ideally, I could get binary substitutes from hydra, but it would also be good to able to run Guix on these dinky little ARM boards
<antiatom>If I wanted to mirror all of GuixSD, how much space would this take?
<lfam>Looks like yes, so I'm going to try to limit the CPU usage with cgroups
<davexunit>antiatom: I don't know even a good estimate because things get added all the time, but on our donation page we are asking for 1TiB of disk for each build machine
<antiatom>Okay but not for mirror, for a build machine
<davexunit>so, here's the thing: we're not like debian in that someone can just mirror some files on a web server.
<adhoc>davexunit: the main issue with that is the source packages are on servers that aren't reliable
<adhoc>guix will pull the source package from hyrda ?
<davexunit>it's unlikely that this particular scenario would happen, because if guix has the source tarball, it likely already has the binary. so if you say 'guix package -iguile' it will just download the pre-built guile
***y is now known as init
***davi_ is now known as Guest76721
<rekado->How can I fix this dbus error? "The name ca.desrt.dconf was not provided by any .service files"
<davexunit>Guix can create the relevant Heat configs to pass to OpenStack and it will create the stuff you asked for.
<ifur>every major contributor have their own fork of openstack, and has largely given up on getting "their" improvements into openstack proper. Instead they makre sure its the crappiest eimplemention that wins