<zacts>I got guix installed and everything. but when I invoke 'guix pull' I get the above error.
<mark_weaver>fwiw, if you get the 'guix' source directly from the git repository, then you needn't ever use 'guix pull'. I myself have never used 'guix pull'.
<mark_weaver>it seems that there are some problems with 'guix pull' that need to be fixed.
<mark_weaver>however, if you decide to build guix from its git repo, then I'd recommend first installing 'autoconf', 'automake', and 'libtool' using guix, to make sure you have new enough versions of those packages to bootstrap guix from git.
*gzg has been considering just going the git route, since he's hoping start contributing relatively often.
<mark_weaver>the other advantage of using git is that if you decide to make local changes to your recipes (or add new ones), that can be handled very gracefully with git. you can just make your own branch of guix and then periodically merge the upstream changes into your local branch.
<zacts>I was going to then use v0.4 guix to install the needed dependencies for guix HEAD
<mark_weaver>zacts: ah, good! then just checkout the 'master' branch, and then run 'make' in the top-level build directory.
<gzg>Do I need to just run the bootstrap, to get the git pull working then -- or?
<mark_weaver>and then you can either 'make install' again, or alternatively, just prefix every guix command with ./pre-inst-env guix ...
<viric>damn it, this conkeror thing is too emacs. Why does it mention "emacs and vi" in the main page? I don't see any 'vi' :)
<a_e>Steap: With the new patch system, cmake does not patch any more. I suppose that the #:patch-flags '("-p0") line is not used any more. Could you maybe update your patches to work with the normal flag, which is -p1, I think?
<a_e>We indeed have 64 bit word size for GNU multiprecision.
<mark_weaver>right, N32 is somewhat analogous to the x32 ABI for Intel: it uses 64-bit registers and assumes a 64-bit processor, but to save memory (and cache) it makes pointers, ints, and longs 32-bit.
<mark_weaver>a_e: which thread should I be looking at? You've posted quite a bit, but some of the threads I'm behind on.
<roelj>I'm wondering how I can integrate debian with guix. For example, I installed emacs with guix, and I'd like to run it without looking up the path its stored in in "the store". Now I'm making symbolic links to do this, but then I have to update all symbolic links every time I upgrade with guix.
<zacts>I generally prefer binary packages, unless I want to fine tune them, or use them on an ssh server.
<mark_weaver>once we've purged all the "impurities" from all of our package builds, then builds should be reproducable in the sense that anyone who does them will get precisely the same output, bit-for-bit identical.
<zacts>I would like to see pure user installs, without needing root, so I can use guix to download and build packages on ssh servers..
<mark_weaver>so that means that our binary builds will be independently verifiable by anyone who cares to check them.
<mark_weaver>yeah, that would be nice. it's certainly doable on the hurd. the problem on linux is that only root can mount filesystems. and setting up the pristine build environments free from impurities requires setting up a chroot with bind mounts, a private namespace, etc.
<a_e>davexunit: Not necessarily. For instance, pari-gp depends on readline. But the guix build system sets the runpath, so if you do ldd on the gp binary, it points to something explicit in /nix/store/...readline...
<a_e>So it looks like my previous explanation was wrong...
<a_e>Another example where propagated-inputs are needed: mpfr.h includes gmp.h. So a user who wants to develop with mpfr necessarily needs the header files of gmp, so gmp is a propagated input of mpfr.
<mark_weaver>gzg: you could try building 'zsh' outside of guix, and doing 'make install' as an unprivileged user, and try to get it to install everything in some directory in your home dir, say ~/my-test-install/