[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
- State of core-updates, Andreas Enge, 2023/03/10
- Re: State of core-updates, Josselin Poiret, 2023/03/10
- Re: State of core-updates, Christopher Baines, 2023/03/10
- Re: State of core-updates, Simon Tournier, 2023/03/13
- Re: State of core-updates, Roman Scherer, 2023/03/14
- Re: State of core-updates,
Maxim Cournoyer <=
- Re: State of core-updates, Andreas Enge, 2023/03/14
- Re: State of core-updates, Maxim Cournoyer, 2023/03/14
- Re: State of core-updates, Andreas Enge, 2023/03/15
- Re: State of core-updates, Efraim Flashner, 2023/03/15
- Re: State of core-updates, Andreas Enge, 2023/03/15
- Re: State of core-updates, Maxim Cournoyer, 2023/03/15
- Re: State of core-updates, Maxim Cournoyer, 2023/03/15
- Notes from the Guix Days, Ludovic Courtès, 2023/03/15
- Re: Notes from the Guix Days, Pjotr Prins, 2023/03/15
- Re: Notes from the Guix Days, Maxim Cournoyer, 2023/03/17