Re: core-updates-frozen on powerpc64le-linux

[Thiago Jung Bauermann]

Hi Ludo’!

Em quarta-feira, 4 de agosto de 2021, às 17:48:59 -03, Ludovic Courtès 
escreveu:
> Thiago Jung Bauermann  skribis:
> > Em quarta-feira, 28 de julho de 2021, às 08:50:16 -03, Mathieu Othacehe
> 
> > escreveu:
> [...]
> 
> >> Cuirass has started evaluating this branch here:
> >> https://ci.guix.gnu.org/jobset/core-updates-frozen. According to the
> >> related dashboard, there's still a bit of work required to stabilize
> >> this branch: https://ci.guix.gnu.org/eval/68124/dashboard.
> > 
> > There are no results for powerpc64le-linux. Does anyone know why?
> 
> It was turned off in the config at
> .  I’ve
> added it now (though maybe it won’t actually build until someone has
> pushed.)

Thanks for the explanation. And thanks for re-adding it!

> Note that currently ci.guix only does emulated powerpc64le-linux because
> the only POWER9 machine we currently have access to (lent by OSUOSL) is
> not running ‘cuirass-remote-worker’.

Ah, I didn’t realise that. I started out my investigations of powerpc64le-
linux CI failures using emulation on my laptop (both with qemu-user and 
qemu-system), and found it to be a bit unreliable. I saw some failures in 
packages’ testsuite results which don’t happen on real hardware. There was 
one in the glib package in particular which happened on the master branch 
and prevented a `guix pull` command from succeeding. This is what prompted 
me to request the Minicloud VM instance.

> It’s a foreign distro (Debian) so
> setting up these things can be a bit tedious.  If you or anyone would
> like to help with this, we can discuss it!

I’d be glad to help set that up and maintain the OSUOSL machine!

> (bordeaux.guix does have a POWER9 build machine behind, but it’s not
> building ‘core-updates-frozen’ currently.)

Nice! I’d be glad to help with that machine as well if there’s anything to 
do on that front.

> > The last Cuirass evaluation of core-updates with powerpc64le-linux
> > results is https://ci.guix.gnu.org/eval/67285 so I tried to run the
> > failed builds on my VM to see what the current state is. My
> > core-updates-frozen branch was at commit f8458a228224
> > (”build-system/python: Handle missing metadata on Python 2.”) when I
> > did these builds.
> > 
> > At first, I didn’t try the “*tarball*” builds because I didn’t want to
> > focus on the bootstrap binaries. Apart from those, I was glad to see
> > that all failed powerpc64le-linux builds from that evaluation built
> > fine on my VM, except for the ones below:
> > 
> > • gcc-toolchain@4.8
> > • gcc-toolchain@5.5
> > • gmp@4.3.2 aka `(@@ (gnu packages commencement) gmp-boot)`
> > • mpfr@2.4.2 aka `(@@ (gnu packages commencement) mpfr-boot)`
> > • mpc@1.0.3 aka `(@@ (gnu packages commencement) mpc-boot)`
> > 
> > I later tried building ‘bootstrap-tarballs’, but it failed during the
> > build of the static gawk binary.
> > 
> > I also did a `guix pull --branch=core-updates-frozen`, which built a
> > ton of stuff and completed successfully. At the time,
> > core-updates-frozen was at commit 5e4cdb5b3b1d (”gnu: python-django:
> > Fix test failure.”)
> 
> Woow, that’s fairly intense testing!

:-)

I was glad to see that powerpc64le-linux was in better shape than I had 
thought.

> Does the Coreutils test failure at 
> happen on real hardware?

Thanks for point it out. I just tested and it doesn’t! I’ll close that 
issue.

> > So next step for me is to look into the build failures above. I’ll
> > semi-randomly start with ‘gmp-boot’ and see what I can find out.
> 
> Neat, thank you!

You’re welcome. Patches on issues 49880, 49881 and 49882. :-)

-- 
Thanks,
Thiago

Re: Guix co-maintainers rotation

[Thiago Jung Bauermann]

Hello,

Em quarta-feira, 4 de agosto de 2021, às 12:06:25 -03, Maxim Cournoyer 
escreveu:
> Let's all take a moment to share our gratitude to both Marius and
> Ludovic, who have done so much to make GNU Guix the enjoyable project
> (both as a technical project and community) that it is today.
> 
> Thank you!

Thank you so much Marius and Ludo’ for your dedication as maintainers!

I found the Guix community to be very welcoming, and have been impressed 
with the responsiveness and helpfulness of the maintainers. 
Congratulations!

-- 
Thanks,
Thiago

Re: Project direction with testing changes (branches and patches)

[Ludovic Courtès]

Hello!

Christopher Baines  skribis:

> So, I think I've recently switched to thinking about the problem as one
> of testing changes, rather than just testing patches. Since both patch
> series, and branches are used to propose changes, I think this makes
> sense.
>
> In abstract, when testing a change, I would break down the problem as
> follows:
>
>   - You need to work out what's affected by the change, so that you can
> assess the impact
>
>   - Once you know what's effected, you can then build those
> packages/system tests/... and compare the build statuses and outputs
> against some baseline
>
>   - Then there's the general UI component, ideally a first time
> contributor would be able to take advantage of automatic feedback
> about a patch they submit. There's multiple other groups of users
> though, like patch reviewers, and committers for example.

Makes sense to me.

I agree that the first problem, seeing what’s affected by a change, is
solved, but it’s still hard to get that info.  I think we could have a
special “skin” for the Guix Data Service to make it easier for people to
view specifically this information.  IMO the current UI has the upside
that it’s generic and exposes all the available information, but it has
the downside that it’s generic and exposes all the available
information.  :-)

Or we could extend Julien’s Gitile¹ to include links from commits to
lists of changed packages.

The UI doesn’t have to be a web UI actually; we could use the Data
Service client interface at

and write a new CLI, Emacs mode (similar to ‘M-x build-farm’), or
something.

¹ https://git.lepiller.eu/gitile

> I think the first two sub-problems are effectively solved. The Guix Data
> Service is able to determine the changes between two revisions (assuming
> it's processed them). The Guix Build Coordinator can then be used to
> build the relevant packages/system tests, and report that information
> back to the Guix Data Service.
>
> The UI part is much less certain, I've done some work with Patchwork,
> and I do have some ideas in mind, but there's still more thinking and
> work to do in this area.
>
> Before pressing on though, I think it would be good to know if this is a
> viable direction?

I think we desperately need more automation, even more than when you
started working on this!

I think a first step could be to make info from the Guix Data Service
more readily available, as suggested above.  And from there we could
address #2 and #3.

The Patchwork instance you maintain at

does a large part of what we want, though the UI is not my favorite I
must say.  ;-)  I wonder if we could again make minimal changes to Mumi
so that it includes links to the relevant bits at the Data Service.
That’d make it more readily available.  WDYT?

> Currently, there's no automated testing of patches, and testing of
> branches is limited to the information that Cuirass provides on failed
> builds. What I'm proposing for the future is: using the Guix Data
> Service together with the Guix Build Coordinator to analyse the effects
> of changes, whether that be from a patch series or a branch. I realise
> that I've already been experimenting with this, what I'm mostly
> referring to here is moving towards this being the documented approach,
> maintained by the project, not just me.

>From an administrative standpoint, I very much agree that this sort of
infrastructure should be financially supported by the project rather
than by an individual, and documented so we can maintain it
collectively.  Of course that involves a bit of overhead, and sometimes
we’re not all responsive when it comes to paperwork or sysadmin (perhaps
these are not our preferred activities?), but still, it makes sense to
build that collectively.

That’s my take.  Thanks for the update!

Ludo’.

Re: core-updates-frozen on powerpc64le-linux

[Ludovic Courtès]

Hi!

Thiago Jung Bauermann  skribis:

> Em quarta-feira, 28 de julho de 2021, às 08:50:16 -03, Mathieu Othacehe 
> escreveu:

[...]

>> This means that the core-updates branch remains open, while the
>> core-updates-frozen branch will only accept bug fixes.
>> 
>> This branch contains exciting new features, such as:
>> 
>> * Switch to GCC 10.
>> * Update to TexLive 2021.
>> * Simplified package inputs[1].
>> * Build system Gexp support[2].
>> * Meson cross-compilation support[3].
>> 
>> between lots of other things.
>
> Really nice refresh indeed.

Woohoo!

>> Cuirass has started evaluating this branch here:
>> https://ci.guix.gnu.org/jobset/core-updates-frozen. According to the
>> related dashboard, there's still a bit of work required to stabilize
>> this branch: https://ci.guix.gnu.org/eval/68124/dashboard.
>
> There are no results for powerpc64le-linux. Does anyone know why?

It was turned off in the config at
.  I’ve
added it now (though maybe it won’t actually build until someone has
pushed.)

Note that currently ci.guix only does emulated powerpc64le-linux because
the only POWER9 machine we currently have access to (lent by OSUOSL) is
not running ‘cuirass-remote-worker’.  It’s a foreign distro (Debian) so
setting up these things can be a bit tedious.  If you or anyone would
like to help with this, we can discuss it!

(bordeaux.guix does have a POWER9 build machine behind, but it’s not
building ‘core-updates-frozen’ currently.)

> A few days ago I requested access to a VM on the Unicamp/IBM Minicloud, and 
> had it granted a couple of hours later so now now I have a POWER VM to play 
> with. :-)  I was a bit surprised to see it’s actually a POWER8 system 
> rather than POWER9, but I don’t think it matters for Guix development and 
> tests.
>
> I’m using a guest with 8 vCPUs and Debian testing installed. Guix is 
> working fine on it, installed from Debian’s experimental ‘guix’ package 
> (thanks vagrant!) and then updated from v1.3 to master with `guix pull`. 
> The Minicloud allows use for 30 days, and can extend it to 30 more days. 
> Hopefuly, that should be enough to help get core-updates in shape on 
> powerpc64le-linux.
>
> The last Cuirass evaluation of core-updates with powerpc64le-linux results 
> is https://ci.guix.gnu.org/eval/67285 so I tried to run the failed builds 
> on my VM to see what the current state is. My core-updates-frozen branch 
> was at commit f8458a228224 (”build-system/python: Handle missing metadata 
> on Python 2.”) when I did these builds.
>
> At first, I didn’t try the “*tarball*” builds because I didn’t want to 
> focus on the bootstrap binaries. Apart from those, I was glad to see that 
> all failed powerpc64le-linux builds from that evaluation built fine on my 
> VM, except for the ones below:
>
> • gcc-toolchain@4.8
> • gcc-toolchain@5.5
> • gmp@4.3.2 aka `(@@ (gnu packages commencement) gmp-boot)`
> • mpfr@2.4.2 aka `(@@ (gnu packages commencement) mpfr-boot)`
> • mpc@1.0.3 aka `(@@ (gnu packages commencement) mpc-boot)`
>
> I later tried building ‘bootstrap-tarballs’, but it failed during the build 
> of the static gawk binary.
>
> I also did a `guix pull --branch=core-updates-frozen`, which built a ton of 
> stuff and completed successfully. At the time, core-updates-frozen was at 
> commit 5e4cdb5b3b1d (”gnu: python-django: Fix test failure.”)

Woow, that’s fairly intense testing!

Does the Coreutils test failure at 
happen on real hardware?

> So next step for me is to look into the build failures above. I’ll semi-
> randomly start with ‘gmp-boot’ and see what I can find out.

Neat, thank you!

Ludo’.

Re: Guix co-maintainers rotation

[Luis Felipe]

On Wednesday, August 4th, 2021 at 3:06 PM, Maxim Cournoyer 
 wrote:

> Dear Guix community,
>
> For some time already, two current Guix co-maintainers have expressed
>
> the wish to withdraw themselves from their current duties: Ludovic
>
> Courtès and Marius Bakke. This would reduce the current co-maintainers
>
> collective to the following remaining individuals: Tobias
>
> Geerinckx-Rice, Mathieu Othacehe and myself, Maxim Cournoyer.
>
> While this may come as sad news, I like to think that this will free
>
> their hands from the administrative work, and hopefully allow them to
>
> continue delivering neat and clever Guix-related hacks, as they see fit
>
> and as time permits, of course :-).

Hey, Ludo and Marius! I really appreciate all the work you've done over the 
years.

Enjoy your "retirement"!

Re: Guix co-maintainers rotation

[Anadon]

I'll second for Ludo and Marius!  You two have been great and when I worked
on helping out Ludo was always there.  You'll be missed!


On Wed, Aug 4, 2021, 14:32 Jack Hill  wrote:

> On Wed, 4 Aug 2021, Maxim Cournoyer wrote:
>
> > Dear Guix community,
> >
> > For some time already, two current Guix co-maintainers have expressed
> > the wish to withdraw themselves from their current duties: Ludovic
> > Courtès and Marius Bakke.  This would reduce the current co-maintainers
> > collective to the following remaining individuals: Tobias
> > Geerinckx-Rice, Mathieu Othacehe and myself, Maxim Cournoyer.
>
> Thanks you Ludo’ and Marius for service to Guix leadership! I am extremely
> happy when I'm interacting with the Guix community.
>
> I also think leadership change is a great thing for organizations, and I
> hope to be able to support the other maintainers, new and old, as best I
> can.
>
> Thanks!
> Jack

Re: Guix co-maintainers rotation

[Jack Hill]

On Wed, 4 Aug 2021, Maxim Cournoyer wrote:


Dear Guix community,

For some time already, two current Guix co-maintainers have expressed
the wish to withdraw themselves from their current duties: Ludovic
Courtès and Marius Bakke.  This would reduce the current co-maintainers
collective to the following remaining individuals: Tobias
Geerinckx-Rice, Mathieu Othacehe and myself, Maxim Cournoyer.


Thanks you Ludo’ and Marius for service to Guix leadership! I am extremely 
happy when I'm interacting with the Guix community.


I also think leadership change is a great thing for organizations, and I 
hope to be able to support the other maintainers, new and old, as best I 
can.


Thanks!
Jack

Guix co-maintainers rotation

[Maxim Cournoyer]

Dear Guix community,

For some time already, two current Guix co-maintainers have expressed
the wish to withdraw themselves from their current duties: Ludovic
Courtès and Marius Bakke.  This would reduce the current co-maintainers
collective to the following remaining individuals: Tobias
Geerinckx-Rice, Mathieu Othacehe and myself, Maxim Cournoyer.

While this may come as sad news, I like to think that this will free
their hands from the administrative work, and hopefully allow them to
continue delivering neat and clever Guix-related hacks, as they see fit
and as time permits, of course :-).  It will also be an opportunity to
test if the co-maintainers collective that formed back in 2019 [0] has
sufficiently matured to take on the various challenges involved in
keeping the project and the community thriving, independently of
Ludovic, which created and nurtured GNU Guix from its beginning in 2012
and played key roles in various aspects of the project.

As a reminder, the core duties of Guix co-maintainers are:

1. Enforcing GNU and Guix policies, such as the project’s commitment to
be released under a copyleft free software license (GPLv3+) and to
follow the Free System Distribution Guideline (FSDG).

2. Enforcing our code of conduct: maintainers are the contact point for
anyone who wants to report abuse.

3. Making decisions, about code or anything, when consensus cannot be
reached.

We'd like to use this opportunity to send a new call for volunteers who
would be interested in becoming co-maintainers and helping out with the
above, and more!  We are looking for people with a time-proven track
record of GNU Guix contributions, with good communication and mediation
skills.

Let's all take a moment to share our gratitude to both Marius and
Ludovic, who have done so much to make GNU Guix the enjoyable project
(both as a technical project and community) that it is today.

Thank you!

Maxim
On behalf of the Guix co-maintainers

[0]  https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/