IRC channel logs


back to list of logs

<sriharsha>Hello Guixers, I am having a problem of low disk space on / as guix daemon tried to populate /nix/store. I then tried to make /nix a symlink to another directory, but now the build fails to run with the symlinked /nix
<sriharsha>Is there any option to pass to guix-builder to use a different directory instead of the default /nix ?
<jmd>Not that I am aware of.
<jmd>Presumable you have run gc ?
<sriharsha>Oh; I haven't run gc yet. I have only built the hello and it seems to have occupied 1.5g space on / where I only have 2g
<jmd>My advice would be to use lvm so that you can shuffle space around (relatively) easily.
<sriharsha>ok, I use it. I now have to shuffle. Thanks
<civodul>Hello Guix!
<zerwas>civodul: currently, if guix-builder users are created according to the documentation, they show up in the login screen etc. If we assign a UID less than 500 and without a home directory, they would not show up.
<zerwas>We just need to use the -r parameter for the useradd command in the documentation. Anything that speaks against this?
<civodul>zerwas: no you're right; this was reported and fixed not long ago:
<civodul>that was an easy one ;-)
<ggrant>Hm. I have a wip directory in packages -- with all my uncompletete modules, but when I try to load it via "./pre-inst-env guile -c (use-modules (gnu packages wip module.scm))' " it always says, code not found.
<ggrant>Or rather, ERROR: no code for module (gnu packages wip network.scm)
<ggrant>For example. *
<sriharsha>Hi zerwas!
<sriharsha>jmd, there is --with-store-dir option for configuring with a different store directory..
<civodul>ggrant: the module name should be (gnu packages wip network), without .scm
<civodul>that maps to the gnu/packages/wip/network.scm file
<civodul>hello sriharsha
<civodul>sriharsha: did you eventually manage to download substitutes?
<sriharsha>no, I am trying on a different system now
<civodul>i don't remember seeing that error you reported, but it does look like a genuine bug
<sriharsha>civodul, isn't the default operation to download the substitutes from hydra server?
<sriharsha>on my new installation, it is downloading the source packages
<sriharsha>when I try to install hello
<zerwas>Hi sriharsha :-)
<sriharsha>zerwas, I am now experimenting with guix
<sriharsha>zerwas, did you make a recipe for gnunet?
<zerwas>sriharsha: nice! No, I didn't. I wanted to try some easier packages first. (And I have no idea about scheme)
<zerwas>And if noone else will do it I still need to have a deeper look at RPM packaging to get Guix itself packaged for the big distributions
<sriharsha>ok, were you able to use substitutes? Its is kinda drag to build from sources which seems to take like about an hour for 'hello'
<zerwas>Yes, worked fine for me on Ubuntu 13.10 with Guix 0.5.
<sriharsha>I don't think big distributions would want to use guix; especially when they have their own ones.
<zerwas>If you can find packages in the Guix repo that you don't find in the repo of the distribution itself it's a strong incentive to install Guix :D
<sriharsha>i have a question: while building a package I see a lot of output from the `guix` command. Is it this command running make, make install on the downloaded sources? or is the output being redirected by guix-daemon?
<civodul>sriharsha: yes, the default is to download from
<civodul>Hydra wasn't building over the last few days
<civodul>so it could be that there was no binary available
<civodul>i'd love to have the latest GNUnet packaged, BTW :-)
<civodul>i know Andreas looked at it before, but i don't remember what the exact status was
<sriharsha>ok, is there any documentation on how to run a hydra like server for distributing the substitutes?
<civodul>there's some documentation at
<civodul>but the real thing of interest would be p2p distribution
<civodul>and that's where you come in ;-)
<jmd>I'm not sure how distributed builds are going to work, but I assume there will be some kind of cryptographic signature involved too?
<sriharsha>jmd, yes either cryptographic signatures or social graph based trust (you download packages from your friends) or if we can achieve build determinism on binaries we can combine both: you friend tells you a hash you can trust and you verify it when you download the binary package
<sriharsha>civodul, yes, i want to get there..
<civodul>if there's anything you'd like to discuss, i'm happy to chime in
<jmd>Don't we already have build determinism?
<sriharsha>civodul, thanks. I am still trying out guix as a newbie. My immediate goal is to be able to setup a hydra like system locally. We want to use guix to be able to deploy gnunet across wide variety of machines and get done with the deployment hell.
<civodul>ah ok
<civodul>jmd: we do our best to that end, but that really depends on packages themselves
<civodul>sriharsha: do you want continuous build, or would publishing a store that contains GNUnet and its deps be enough?
<sriharsha>publishing a store containing gnunet and its deps is enough
<jmd>Well I suppose if a package had a random number generator in its build process ...
<jmd>Actually, one thing occurs to me: Is there anything preventing a package accessing the network during build/configure/test ? If not, there should be.
<civodul>sriharsha: then great, because it'd be quite easy to implement an HTTP server that talks the same "protocol" as Hydra
<civodul>jmd: builds proceses leave in a separate network "name space" with only 'lo', and they can't access the network
<civodul>*build processes live
<jmd>ok. That's good then.
<civodul>wonderful, even!
<jmd>Yes, it's wonderful. I wonder how it does that.
<sriharsha>civodul, is guix-daemon inter-operable with the hydra server from
<civodul>jmd: with clone(2) flags, like CLONE_NEWNET
<sriharsha>so, if I install nixos and setup hydra on it, can the guix-daemon get substitutes from it?
<civodul>sriharsha: yes it acn
<civodul>(there must be something wrong with my keyboard)
<civodul>to be precise, guix-daemon invokes 'guix substitute-binary', which then talks to the Hydra instance
<sriharsha>ok, thanks
<civodul>sriharsha: note that the Hydra host will need to run guix-daemon, not nix-daemon, because there are different settings
<civodul>for instance, guix-daemon is doesn't have /bin in the chroot, which improves reproducibility
<sriharsha>civodul, so, there is not much need for installing nixos if I have to anyway install guix. Can I just install hydra on top of guix installation?
<sriharsha>In this case, I will just install guix on debian and then install hydra
<civodul>sriharsha: installing Hydra on a system other than NixOS is a little involved
<civodul>we have it on Trisquel on
<civodul>but that means you have to install all its Perl dependencies etc.
<civodul>and PGSQL
<civodul>well, nothing insurmountable, but a little annoying
<sriharsha>ok; i am worried that if I install nixos and then install guix for having guix-daemon, won't the exiting nix conflict with guix?
<civodul>no, you just won't be able to build Nix packages when the Guix daemon is running (because they expect /bin/sh, among other things)
<civodul>and also, nix-daemon and guix-daemon can share the same store
<civodul>the manual explains how
<civodul>that said we'll probably move away from "/nix/store" within a couple of months :-)
<sriharsha>ok, i shall try it with nixos then. thanks!
<zerwas>Is there a packaging tutorial somewhere? The reference manual covers how to define packages but not exactly how to test them
<c107>Trying to run the Guix image with `qemu gnu-system-demo-0.5.qcow2`.
<civodul>zerwas: gives the user's viewpoint
<civodul>basically 'guix package' is the entry point for the user, like 'apt-get' etc.
<zerwas>By "test them" i mean how to test a self-created .scm file
<civodul>aah, sorry
<civodul>yes, that should be added
<civodul>HACKING has some info
<zerwas>ah, thanks!
<civodul>but basically you have to run ./pre-inst-env guix build foo