Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> on a newly installed Overdrive 1000 machine with 8 GB of memory, I am trying
>    guix pull -n
>
> This results in
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix      https://git.savannah.gnu.org/git/guix.git	d0d207c
> The following derivations will be built:
>    /gnu/store/qvljgqnsynw113h1062nws9i2zfcz15y-compute-guix-derivation.drv
>    /gnu/store/rj824ibc8nhhl1j2h25sgw4lyxkxjggc-gdb-8.2.drv
> ...
>    /gnu/store/w1jw283cdf6n03qnccsrvxgzy41z0hps-guile-gcrypt-0.1.0.drv
> building /gnu/store/wy37294j2rb6fg5fgpybki28vq60jz94-python-minimal-3.6.5.drv...
> starting phase `set-SOURCE-DATE-EPOCH'
> ...
>
> That a build of something starts although the "-n" flag is specified seems
> to be a first bug.
>
> Then, during the test phase, the build is killed since the machine runs out
> of memory. I also tried to pass "--cores=1" to "guix build", but this
> parameter is not honoured: "top" shows that all four cores are running.
> This might be a second bug.
>
> In any case, it becomes impossible to upgrade with the usual mechanism,
> which is a rather serious bug.
>
> My guix version:
>    $ guix --version
> guix (GNU Guix) 0.15.0-8.71a78ba

The Python contained within this Guix snapshot has a known bug that
makes it leak memory on newer kernels.  The Guix commit that works
around it is 589aca1c183ef1dfdef54d40fdd6a258bbcd39d0.

One thing you could try is bootstrap a Guix checkout through the usual
mechanisms (./bootstrap; ./configure; etc), using packages from the host
system if necessary.

From there you should be able to "./pre-inst-env guix pull".

A dirtier workaround is to delete
"/tmp/guix-build-python-minimal-3.6.5.drv-0/Lib/test/test_socket.py" at
some point during the build process, but you may have to do that a
couple of times.

Finally, installing 0.16.0 "from scratch" should also work.

HTH!