[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#27284: closed (Memory leak in 'guix pull' or 'make

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#27284: closed (Memory leak in 'guix pull' or 'make' in guix source)
Date: Sun, 08 Apr 2018 16:38:02 +0000

Your message dated Sun, 08 Apr 2018 18:37:07 +0200
with message-id <address@hidden>
and subject line Re: bug#27284: ‘guix pull’ builds using multiple derivations
has caused the debbugs.gnu.org bug report #27284,
regarding Memory leak in 'guix pull' or 'make' in guix source
to be marked as done.

(If you believe you have received this mail in error, please contact

27284: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27284
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Memory leak in 'guix pull' or 'make' in guix source Date: Thu, 8 Jun 2017 08:39:35 +0000
This has been discussed on IRC and on guix-devel mailinglist
but so far I haven't seen a formal bug report to make this

I can't find the right threads or timestamps for this
bug, so take it as is and extend with facts.

At the moment of writing, guix pull has the minimum
requirement of 3 GB RAM.

Before this started, I was able to run Guix on as
little as 512MB RAM.

People are currently finding out about this bug
the hard way, so we should point this out. Didn't
really happen so I guess someone is working on this
OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588

Attachment: signature.asc
Description: PGP signature

--- End Message ---
--- Begin Message --- Subject: Re: bug#27284: ‘guix pull’ builds using multiple derivations Date: Sun, 08 Apr 2018 18:37:07 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

address@hidden (Ludovic Courtès) skribis:

> The code in ‘wip-pull-multiple-derivations’ works like this:
>   1. Assume we have Guile and Guix already installed, but not
>      necessarily the latest versions thereof.
>   2. Using the (guix …) modules that we have, build a program—a
>      “trampoline”—that will use the modules of the target Guix (the
>      commit we want to pull) to compute the derivation of that Guix.
>   3. Run that trampoline, which returns /gnu/store/…-guix.drv.  The
>      result should be the same regardless of the initial Guix because
>      the trampoline uses exclusively modules from the target Guix.
>   4. ‘guix pull’ builds that derivation (actually the branch does not
>      modify (guix scripts pull) at all; everything is in
>      build-aux/build-self.scm.)

After quite a bit of tweaking I’ve finally pushed this patch series to
master.  So if you run ‘guix pull’ now, you’ll get the new
multiple-derivation build.

There’s still room for improvement, in particular:

  • The initial ‘compute-guix-derivation’ program depends on quite a few
    modules, so the first time you ‘guix pull’ you build a
    module-import-compiled.drv that takes a while and does not produce
    any output (I’ve made it verbose in core-updates commit
    d32922759bfeffa03ee189158ea00b1a0ddbe8c6 though).  Perhaps we could
    avoid that by using a double trampoline, which would allow us to get
    substitutes for all the non-trivial bits.

  • The “guix-packages” derivation is coarse-grain.  We could perhaps
    automatically split it in clusters of modules by analyzing the (gnu
    packages …) module graph.

  • The compiler (and interpreter) in Guile 2.2 is still not as fast as
    we’d like.  I think it should be possible to make it as fast as in
    2.0, at least when optimizations are turned off.  Andy made
    significant improvements in 2.2.3, but hopefully we can still
    improve on that.  The thread at
    contains some info.

Normally berlin.guixsd.org will start providing substitutes for all this
but note that, as things are, it’ll compute substitutes for Guile 2.2.2
or 2.2.3, and that’s it.  hydra.gnu.org currently doesn’t, for obscure
reasons (‘hydra-eval-guile-jobs’ systematically adds “.” to the load
path, which is not what we want for build-aux/hydra/guix-modular.scm.)

This works unlocks some of the stuff in <https://bugs.gnu.org/22629>, so
I’ll try to focus on that now.

Feedback and bug reports welcome!


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]