[Top][All Lists]

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

Re: State of core-updates

From: Maxim Cournoyer
Subject: Re: State of core-updates
Date: Tue, 14 Mar 2023 11:50:12 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Andreas,

Andreas Enge <> writes:

> Hello all,
> let me start with a call for help! I realise that it takes me about one
> week and something close to 100GB on my poor 2-core laptop to rebuild
> the bulk of core-updates up to the packages in my profile, and that is not
> sustainable. It also forces me to do a "guix gc" between two runs, with
> the danger of either doing it too late and having to restart the builds
> (lived experience, one week lost), or losing and having to recompile
> store items that effectively have not changed.

Some things that may help that I use:

- Offloading
- Btrfs file system with zstd compression (to make that 100 GiB appear
  as 50 GiB or less on your drive)


> Since the bootstrapping seems to have stabilised, that would allow more
> people to work on packages closer to the leaves, since most of what
> currently builds would be available as substitutes from the build farm
> without everybody needing to go through a one-week compilation project.
> Here is my eclectic selection of packages I would add to the job:
> - guix (builds)
> - icecat (builds)
> - ungoogled-chromium (probably also builds)
> - openjdk (pulls in rust!, and builds)
> - unison (pulls in ocaml, and builds)
> - calibre (pulls in qt@5 and python; the former builds, the latter still
>   has some problems, among which the python bindings to qt, and packages
>   failing their tests even when updating to the latest release)
> - pandoc (pulls in ghc, which currently fails its tests @9.2.5)
> Please suggest more leaf packages that exercise your favourite missing
> language or application domain!

That looks promising.  Should we spun a differently named branch to
avoid people sending core-updates change?  This was discussed in the
past and agreed to (main branches do not *freeze* themselves), instead
we use git to branch to our will.

We could perhaps then add a 'core-updates-fixes-only' branch to the CI,
in which we'd try to restrict core changes as much as possible, keeping
the rebuild stress low for Berlin.

How does that sound?


reply via email to

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