guix-devel
[Top][All Lists]
Advanced

[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 <andreas@enge.fr> 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?

-- 
Thanks,
Maxim



reply via email to

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