* Notes from the Guix Days
@ 2020-02-14 16:11 Ludovic Courtès
2020-02-17 11:00 ` Pierre Neidhardt
0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2020-02-14 16:11 UTC (permalink / raw)
To: Guix-devel
Hello Guix!
I’ve pushed the notes from the Guix Days to the maintenance repository:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2020
The notes are very raw so don’t hesitate to start discussions on the
topics you’re the most interested in!
Enjoy. :-)
Ludo’.
^ permalink raw reply [flat|nested] 5+ messages in thread
* State of core-updates
@ 2023-03-10 14:58 Andreas Enge
2023-03-14 15:50 ` Maxim Cournoyer
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Enge @ 2023-03-10 14:58 UTC (permalink / raw)
To: guix-devel
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.
So it would be nice if someone could set up a more complete job for
core-updates on cuirass or QA, and maybe write up a how-to to see which
packages work and which ones need more love, preferably by architecture.
(Without offense, I honestly do not see what
https://ci.guix.gnu.org/jobset/core-updates
tells me. There is one evaluation with 290 succeeding and 300 failing
builds, and another one with 7 succeeding and 4 failing builds. Or are
these only the newly succeeding or failing builds? There is the dashboard
which gives visual clues, but can it be used to extract a list of
"originally failing" packages, in the sense that the compilation fails
itself instead of just a dependency - otherwise said, the failures highest
up in the package graph, which need to be worked on? On QA I think so far
there is nothing for core-updates, and the bordeaux build farm probably
could not keep up while also working on issues from the tracker. Generally
speaking, I think we need more tooling and documentation of the tooling if
feature branches are to become a thing.)
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!
Andreas
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: State of core-updates
2023-03-10 14:58 State of core-updates Andreas Enge
@ 2023-03-14 15:50 ` Maxim Cournoyer
2023-03-14 18:02 ` Andreas Enge
0 siblings, 1 reply; 5+ messages in thread
From: Maxim Cournoyer @ 2023-03-14 15:50 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: State of core-updates
2023-03-14 15:50 ` Maxim Cournoyer
@ 2023-03-14 18:02 ` Andreas Enge
2023-03-15 0:56 ` Maxim Cournoyer
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Enge @ 2023-03-14 18:02 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: guix-devel
Hello Maxim,
Am Tue, Mar 14, 2023 at 11:50:12AM -0400 schrieb Maxim Cournoyer:
> 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.
well, I consider core-updates to be frozen, people should not send any
more patches there unless they repair things that are currently broken
(and, one may add, a regression to master). I do not expect this to
include any world rebuilding changes any more.
And then the goal will be to not have a core-updates branch in the future,
but separate feature branches as discussed at the Guix days. So the aim
is to merge core-updates to master, and then to delete this branch once
and for all. (Of course, there can then be a new feature branch "core-team"
or something like this, for changes concerning the core of the system.)
So I think there is no need to branch from the branch!
(And just as a reminder, let us not forget the staging branch that needs
a similar treatment.)
Andreas
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: State of core-updates
2023-03-14 18:02 ` Andreas Enge
@ 2023-03-15 0:56 ` Maxim Cournoyer
2023-03-15 16:34 ` Notes from the Guix Days Ludovic Courtès
0 siblings, 1 reply; 5+ messages in thread
From: Maxim Cournoyer @ 2023-03-15 0:56 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
Hi Andreas,
Andreas Enge <andreas@enge.fr> writes:
> Hello Maxim,
>
> Am Tue, Mar 14, 2023 at 11:50:12AM -0400 schrieb Maxim Cournoyer:
>> 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.
>
> well, I consider core-updates to be frozen, people should not send any
> more patches there unless they repair things that are currently broken
> (and, one may add, a regression to master). I do not expect this to
> include any world rebuilding changes any more.
>
> And then the goal will be to not have a core-updates branch in the future,
> but separate feature branches as discussed at the Guix days.
>
> So the aim is to merge core-updates to master, and then to delete this
> branch once and for all. (Of course, there can then be a new feature
> branch "core-team" or something like this, for changes concerning the
> core of the system.)
Thanks for the explanations. I'm out of the loop, not having been able
to attend physically the last Guix Days event. Was there a recap of the
discussions posted somewhere? Was the freeze announce somewhere? I
wholly missed that, and I try to pay attention.
> So I think there is no need to branch from the branch!
> (And just as a reminder, let us not forget the staging branch that needs
> a similar treatment.)
OK! We could probably merge staging into master and be done already.
--
Thanks,
Maxim
^ permalink raw reply [flat|nested] 5+ messages in thread
* Notes from the Guix Days
2023-03-15 0:56 ` Maxim Cournoyer
@ 2023-03-15 16:34 ` Ludovic Courtès
2023-03-15 18:21 ` Pjotr Prins
2023-03-17 15:07 ` Maxim Cournoyer
0 siblings, 2 replies; 5+ messages in thread
From: Ludovic Courtès @ 2023-03-15 16:34 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Andreas Enge, guix-devel, Pjotr Prins
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> Thanks for the explanations. I'm out of the loop, not having been able
> to attend physically the last Guix Days event. Was there a recap of the
> discussions posted somewhere? Was the freeze announce somewhere? I
> wholly missed that, and I try to pay attention.
Notes on the release and branching discussions are here:
https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html
Pjotr stored additional notes here (thanks!):
https://gitlab.com/pjotrp/guix-days-fosdem-2023/-/tree/main/
Pjotr, can you add Andreas’ notes linked above? Does anyone else have
notes to share?
Ludo’.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Notes from the Guix Days
2023-03-15 16:34 ` Notes from the Guix Days Ludovic Courtès
@ 2023-03-15 18:21 ` Pjotr Prins
2023-03-17 15:07 ` Maxim Cournoyer
1 sibling, 0 replies; 5+ messages in thread
From: Pjotr Prins @ 2023-03-15 18:21 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Maxim Cournoyer, Andreas Enge, guix-devel
On Wed, Mar 15, 2023 at 05:34:24PM +0100, Ludovic Courtès wrote:
> Pjotr, can you add Andreas’ notes linked above? Does anyone else have
> notes to share?
Added.
https://gitlab.com/pjotrp/guix-days-fosdem-2023
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Notes from the Guix Days
2023-03-15 16:34 ` Notes from the Guix Days Ludovic Courtès
2023-03-15 18:21 ` Pjotr Prins
@ 2023-03-17 15:07 ` Maxim Cournoyer
1 sibling, 0 replies; 5+ messages in thread
From: Maxim Cournoyer @ 2023-03-17 15:07 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Andreas Enge, guix-devel, Pjotr Prins
Hello!
Ludovic Courtès <ludo@gnu.org> writes:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Thanks for the explanations. I'm out of the loop, not having been able
>> to attend physically the last Guix Days event. Was there a recap of the
>> discussions posted somewhere? Was the freeze announce somewhere? I
>> wholly missed that, and I try to pay attention.
>
> Notes on the release and branching discussions are here:
>
> https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html
All caught up now!
> Pjotr stored additional notes here (thanks!):
>
> https://gitlab.com/pjotrp/guix-days-fosdem-2023/-/tree/main/
This is nice, I just peeked at "Debugging Guix beyond pk". I'll
bookmark and read more of it, thank you!
--
Maxim
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-17 15:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 16:11 Notes from the Guix Days Ludovic Courtès
2020-02-17 11:00 ` Pierre Neidhardt
-- strict thread matches above, loose matches on Subject: below --
2023-03-10 14:58 State of core-updates Andreas Enge
2023-03-14 15:50 ` Maxim Cournoyer
2023-03-14 18:02 ` Andreas Enge
2023-03-15 0:56 ` Maxim Cournoyer
2023-03-15 16:34 ` Notes from the Guix Days Ludovic Courtès
2023-03-15 18:21 ` Pjotr Prins
2023-03-17 15:07 ` Maxim Cournoyer
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.