glibc release process

glibc release process

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

Hi all, 

after taking care of the release process twice, I would like to suggest
and put up for discussion some changes... The intention is to provide more
time for the slow, old, and/or unusual architectures to do machine testing.
Here we go.

1) Nominal freeze: not 1 month but 6 weeks before release
Mostly to accommodate the later changes, see below.
Decision on what goes still in and what goes not, review and addition 
of final patches.

2) Machine testing: 1 month before release 
Not, as currently, effectively 2 weeks before release (after waiting for
the last important patches to go in)

3) Branch: 2 weeks before release
Master is opened for development
Release branch only accepts obvious and simple bugfixes and/or fixes for
issues found during machine testing

4) Release: from release branch, not master

What do you think?

Cheers -a

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: glibc release process

[Adhemerval Zanella Netto]

On 30/05/24 09:17, Andreas K. Huettel wrote:
> Hi all, 
> 
> after taking care of the release process twice, I would like to suggest
> and put up for discussion some changes... The intention is to provide more
> time for the slow, old, and/or unusual architectures to do machine testing.
> Here we go.
> 
> 1) Nominal freeze: not 1 month but 6 weeks before release
> Mostly to accommodate the later changes, see below.
> Decision on what goes still in and what goes not, review and addition 
> of final patches.
> 
> 2) Machine testing: 1 month before release 
> Not, as currently, effectively 2 weeks before release (after waiting for
> the last important patches to go in)
> 
> 3) Branch: 2 weeks before release
> Master is opened for development
> Release branch only accepts obvious and simple bugfixes and/or fixes for
> issues found during machine testing
> 
> 4) Release: from release branch, not master
> 
> What do you think?

The new timeline sounds reasonable, thanks. 

Re: glibc release process

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Any more comments, objections, ideas, ...?

(In particular, for our rather manual QA in Gentoo the two-week phase
between branch and release is no problem, but can everyone else with their
fancy autobuilders handle this?)

If no objections I'd call for the soft/nominal freeze on 15/June.

Cheers -a

> Hi all, 
> 
> after taking care of the release process twice, I would like to suggest
> and put up for discussion some changes... The intention is to provide more
> time for the slow, old, and/or unusual architectures to do machine testing.
> Here we go.
> 
> 1) Nominal freeze: not 1 month but 6 weeks before release
> Mostly to accommodate the later changes, see below.
> Decision on what goes still in and what goes not, review and addition 
> of final patches.
> 
> 2) Machine testing: 1 month before release 
> Not, as currently, effectively 2 weeks before release (after waiting for
> the last important patches to go in)
> 
> 3) Branch: 2 weeks before release
> Master is opened for development
> Release branch only accepts obvious and simple bugfixes and/or fixes for
> issues found during machine testing
> 
> 4) Release: from release branch, not master
> 
> What do you think?
> 
> Cheers -a


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: glibc release process

[Carlos O'Donell]

On 5/30/24 8:17 AM, Andreas K. Huettel wrote:
> Hi all, 
> 
> after taking care of the release process twice, I would like to suggest
> and put up for discussion some changes... The intention is to provide more
> time for the slow, old, and/or unusual architectures to do machine testing.
> Here we go.

What is not explicit here is the goal.

If more time is given over to additional testing, and that testing reveals defects, then
we would have the time to correct the defects before release.

So the goal is: Make a singular release tarball that includes *more* fixes for slower
targets?

> 1) Nominal freeze: not 1 month but 6 weeks before release
> Mostly to accommodate the later changes, see below.
> Decision on what goes still in and what goes not, review and addition 
> of final patches.

I agree with (1).

We should start this review ahead of the harder freeze at the 1 month mark.
 
> 2) Machine testing: 1 month before release 
> Not, as currently, effectively 2 weeks before release (after waiting for
> the last important patches to go in)

I agree with (2).

> 3) Branch: 2 weeks before release
> Master is opened for development
> Release branch only accepts obvious and simple bugfixes and/or fixes for
> issues found during machine testing

This seems to contradict implementing fixes that are issues for slower targets?

> 4) Release: from release branch, not master

What benefit does this bring?

Conceptually I think I understand what we want to adopt here.

That the main development branch is always development, and that we cut and then
make the required changes for release.


> What do you think?
> 
> Cheers -a
> 

-- 
Cheers,
Carlos.

Re: glibc release process

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

Hi Carlos, 

> What is not explicit here is the goal.
> If more time is given over to additional testing, and that testing reveals defects, then
> we would have the time to correct the defects before release.
> 
> So the goal is: Make a singular release tarball that includes *more* fixes for slower
> targets?

Yes. I'm trying to combine two objectives here:

We've run a few times into a situation where for some not-so-important
and not-so-modern target there was breakage at the moment of the release tag.
That was usually fixed very quickly, and arguably could have been fixed before
the tag, given a bit more time to look at build and runtime results. So, 

Objective A: Try to make the (exact) release better for the obscure targets.

However, I also want to avoid that we freeze for too long. One month every
half year is already a lot. So, 

Objective B: Keep the total freeze time as is.

If you think B is unnecessary, that's fine with me.

> > 1) Nominal freeze: not 1 month but 6 weeks before release
> > Mostly to accommodate the later changes, see below.
> > Decision on what goes still in and what goes not, review and addition 
> > of final patches.
> 
> I agree with (1).
> 
> We should start this review ahead of the harder freeze at the 1 month mark.

> > 2) Machine testing: 1 month before release 
> > Not, as currently, effectively 2 weeks before release (after waiting for
> > the last important patches to go in)
> 
> I agree with (2).

> > 3) Branch: 2 weeks before release
> > Master is opened for development
> > Release branch only accepts obvious and simple bugfixes and/or fixes for
> > issues found during machine testing
> 
> This seems to contradict implementing fixes that are issues for slower 
> targets?

Maybe I expressed myself wrong here. The main idea is, let's keep the
release branch running for two more weeks under bugfix only rules.
We have a chance to still address problems that are found during additional
machine testing.

[One could even think of cutting x.y_rc tarballs at this time
to promote further testing.]

> > 4) Release: from release branch, not master
> 
> What benefit does this bring?

The only real benefit is that we have master open for new code again
after 4 weeks of freeze, as before.

If everyone is fine with waiting two more weeks, why not. Then we can 
do the bugfix period on master and tag the release on master.
I'm not the best person to judge how bad the extra freeze time is.

That's all.


> Conceptually I think I understand what we want to adopt here.
> 
> That the main development branch is always development, and that we cut and then
> make the required changes for release.
> 
> 
> > What do you think?
> > 
> > Cheers -a
> > 
> 
> 


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: glibc release process

[Carlos O'Donell]

On 6/10/24 4:49 PM, Andreas K. Huettel wrote:
> Hi Carlos, 
> 
>> What is not explicit here is the goal.
>> If more time is given over to additional testing, and that testing reveals defects, then
>> we would have the time to correct the defects before release.
>>
>> So the goal is: Make a singular release tarball that includes *more* fixes for slower
>> targets?
> 
> Yes. I'm trying to combine two objectives here:
> 
> We've run a few times into a situation where for some not-so-important
> and not-so-modern target there was breakage at the moment of the release tag.
> That was usually fixed very quickly, and arguably could have been fixed before
> the tag, given a bit more time to look at build and runtime results. So, 
> 
> Objective A: Try to make the (exact) release better for the obscure targets.

Thank you for clarifying the goals.

I can support objective A.

> However, I also want to avoid that we freeze for too long. One month every
> half year is already a lot. So, 
> 
> Objective B: Keep the total freeze time as is.
> 
> If you think B is unnecessary, that's fine with me.

We should not *need* to freeze for a full month if we can reasonably complete machine
testing in shorter time. The problem is that machine testing takes a lot of wall time.

I want to decouple machine testing from the freeze cycle, but this is hard without
having build bots for all of the arches that we can check on a weekly basis at least
as we lead up to the release. In this ideal future we cross the line, copy the results
from the buildbots and see if we're clean?

We have some builders on Sourceware, https://builder.sourceware.org/buildbot/#/builders?tags=glibc
but we have not done the work to keep them green, and that's the hard part. We have to
commit to monitor and maintain them and if we did that then I think we could close the
gap on the release?

In summary:

- My opinion is that we cannot meet A and B simultaneously until we implement
  process for post-commit CI/CD for glibc.

- My position is that we increase the freeze time to 6 weeks, and that we explore
  post-commit CI/CD for glibc for as many arches as we can.

>>> 1) Nominal freeze: not 1 month but 6 weeks before release
>>> Mostly to accommodate the later changes, see below.
>>> Decision on what goes still in and what goes not, review and addition 
>>> of final patches.
>>
>> I agree with (1).
>>
>> We should start this review ahead of the harder freeze at the 1 month mark.
> 
>>> 2) Machine testing: 1 month before release 
>>> Not, as currently, effectively 2 weeks before release (after waiting for
>>> the last important patches to go in)
>>
>> I agree with (2).
> 
>>> 3) Branch: 2 weeks before release
>>> Master is opened for development
>>> Release branch only accepts obvious and simple bugfixes and/or fixes for
>>> issues found during machine testing
>>
>> This seems to contradict implementing fixes that are issues for slower 
>> targets?
> 
> Maybe I expressed myself wrong here. The main idea is, let's keep the
> release branch running for two more weeks under bugfix only rules.
> We have a chance to still address problems that are found during additional
> machine testing.
> 
> [One could even think of cutting x.y_rc tarballs at this time
> to promote further testing.]

I do not agree with (3) because it doesn't support objective A.

I think we can branch *any time* we want if testing is complete for the long
running arches.

We should try quickly identify defects, fix them, and then branch and cut the
release.

>>> 4) Release: from release branch, not master
>>
>> What benefit does this bring?
> 
> The only real benefit is that we have master open for new code again
> after 4 weeks of freeze, as before.
> 
> If everyone is fine with waiting two more weeks, why not. Then we can 
> do the bugfix period on master and tag the release on master.
> I'm not the best person to judge how bad the extra freeze time is.

Lets try it out.

Lets do 2 weeks of extra freeze time, but focus on getting all machine results
and see if we can cut and release EARLY. :-)

> That's all.
> 
> 
>> Conceptually I think I understand what we want to adopt here.
>>
>> That the main development branch is always development, and that we cut and then
>> make the required changes for release.
>>
>>
>>> What do you think?
>>>
>>> Cheers -a
>>>
>>
>>
> 
> 

-- 
Cheers,
Carlos.

Re: glibc release process

[Mark Wielaard]

Hi,

On Tue, 2024-06-18 at 08:38 -0400, Carlos O'Donell wrote:
> I want to decouple machine testing from the freeze cycle, but this is hard without
> having build bots for all of the arches that we can check on a weekly basis at least
> as we lead up to the release. In this ideal future we cross the line, copy the results
> from the buildbots and see if we're clean?
> 
> We have some builders on Sourceware, https://builder.sourceware.org/buildbot/#/builders?tags=glibc
> but we have not done the work to keep them green, and that's the hard part. We have to
> commit to monitor and maintain them and if we did that then I think we could close the
> gap on the release?

The results are actually pretty good. There used to be various tests
that didn't work correctly inside a container, but those have all been
fixed in the last 2 years. Also there are some tests that would time
out with the default, but the builds now use TIMEOUTFACTOR=4 which
works around that.

arm64 is now fully green again after Adhemerval's ulp update.
riscv used to be fully green, but hasn't seen an ulp update yet.

The x86_64 build is almost always green, but does have a flaky test
elf/tst-audit10 which occasionally fails.

I believe only sparc has never been fully green. It has 42 FAIL, most
math tests because of outdated ulps, but also various elf, nptl, posix,
socket and stdlib tests fail [*].

Cheers,

Mark

[*] latest glibc sparc results in bunsen:
https://builder.sourceware.org/testrun/5443a0ae3f9b3cfffb69b9a9338015f3ca07b0c8?focus=glibc&sortColumn=2&sortDirection=desc

Re: glibc release process

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

Hi Carlos, 

> >>> 3) Branch: 2 weeks before release
> >>> Master is opened for development
> >>> Release branch only accepts obvious and simple bugfixes and/or fixes for
> >>> issues found during machine testing
> >>
> >> This seems to contradict implementing fixes that are issues for slower 
> >> targets?
> > 
> > Maybe I expressed myself wrong here. The main idea is, let's keep the
> > release branch running for two more weeks under bugfix only rules.
> > We have a chance to still address problems that are found during additional
> > machine testing.
> > 
> > [One could even think of cutting x.y_rc tarballs at this time
> > to promote further testing.]
> 
> I do not agree with (3) because it doesn't support objective A.
> 
> I think we can branch *any time* we want if testing is complete for the long
> running arches.

When is "testing complete"?

It's not as if we are working against a well-defined list of configurations
here. We can't really say, here's a 100-item list of supported hardware, supported
compiler flags, and supported configuration option combinations, we go through this
list with autobuilders and regression tests and if nothing pops up we're good.

I'm trying to address the issues that fall outside such a grid and can't be caught
by brute-force (i.e. throwing money and CI at it).

> 
> Lets try it out.
> 
> Lets do 2 weeks of extra freeze time, but focus on getting all machine results
> and see if we can cut and release EARLY. :-)
> 

We have this semi-strict rule in Gentoo that a package version can't enter "Gentoo
stable" unless it's been around without significant changes for 4 weeks. One point
of it is that no amount of automated testing will catch all bugs in all combinations,
but our hordes of happy-go-lucky experimenting users using "Gentoo testing" will very
likely stumble on some of them. Just waiting helps to make sure we're good.

This is why I'm against the speed focus.

And even if we re-open master for development, the release branch and the master code
will most likely be tried and tested by different people (distributions and packagers on
one side, glibc developers on the other).

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: glibc release process

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

> 
> The results are actually pretty good. There used to be various tests
> that didn't work correctly inside a container, but those have all been
> fixed in the last 2 years. Also there are some tests that would time
> out with the default, but the builds now use TIMEOUTFACTOR=4 which
> works around that.
> 
> arm64 is now fully green again after Adhemerval's ulp update.
> riscv used to be fully green, but hasn't seen an ulp update yet.
> 
> The x86_64 build is almost always green, but does have a flaky test
> elf/tst-audit10 which occasionally fails.

That sounds actually great. 

(I'm not at all against the automated testing, just very much convinced
that brains eventually find more bugs.)

> I believe only sparc has never been fully green. It has 42 FAIL, most
> math tests because of outdated ulps, but also various elf, nptl, posix,
> socket and stdlib tests fail [*].

I'll take care of the ULPS.

Cheers -a

> 
> Cheers,
> 
> Mark
> 
> [*] latest glibc sparc results in bunsen:
> https://builder.sourceware.org/testrun/5443a0ae3f9b3cfffb69b9a9338015f3ca07b0c8?focus=glibc&sortColumn=2&sortDirection=desc


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

sparc tests (catbus)

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

> 
> I believe only sparc has never been fully green. It has 42 FAIL, most
> math tests because of outdated ulps, but also various elf, nptl, posix,
> socket and stdlib tests fail [*].
> 

I ran the testsuite manually on the sparc machine, and it's actually quite good
(after pushing the new ULPs).

Will pick out the details later on. We should probably update the
system on the machine, it's still using gcc-12 and binutils-2.40... soon.


FAIL: debug/tst-fortify-c-default-3-def
FAIL: debug/tst-fortify-c-lfs-3-def
FAIL: debug/tst-fortify-c-nongnu-3-def
FAIL: debug/tst-fortify-cc-default-3-def
FAIL: debug/tst-fortify-cc-lfs-3-def
FAIL: debug/tst-fortify-cc-nongnu-3-def
FAIL: elf/tst-pldd
FAIL: math/test-float64x-float128-mul
FAIL: nptl/tst-mutexpi9
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/tst-arc4random-thread
FAIL: stdlib/tst-setcontext2
                === Summary of results ===
     12 FAIL
   4796 PASS
     23 UNSUPPORTED
     17 XFAIL
      2 XPASS


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: sparc tests (catbus)

[Adhemerval Zanella Netto]

On 19/06/24 11:44, Andreas K. Huettel wrote:
>>
>> I believe only sparc has never been fully green. It has 42 FAIL, most
>> math tests because of outdated ulps, but also various elf, nptl, posix,
>> socket and stdlib tests fail [*].
>>
> 
> I ran the testsuite manually on the sparc machine, and it's actually quite good
> (after pushing the new ULPs).
> 
> Will pick out the details later on. We should probably update the
> system on the machine, it's still using gcc-12 and binutils-2.40... soon.
> 
> 
> FAIL: debug/tst-fortify-c-default-3-def
> FAIL: debug/tst-fortify-c-lfs-3-def
> FAIL: debug/tst-fortify-c-nongnu-3-def
> FAIL: debug/tst-fortify-cc-default-3-def
> FAIL: debug/tst-fortify-cc-lfs-3-def
> FAIL: debug/tst-fortify-cc-nongnu-3-def

These seems suspicious and I not seeing with gcc-13 built with build-many-glibcs.py
on the same machine.

> FAIL: elf/tst-pldd
> FAIL: math/test-float64x-float128-mul
> FAIL: nptl/tst-mutexpi9
> FAIL: socket/tst-socket-timestamp
> FAIL: stdlib/tst-arc4random-thread
> FAIL: stdlib/tst-setcontext2
>                 === Summary of results ===
>      12 FAIL
>    4796 PASS
>      23 UNSUPPORTED
>      17 XFAIL
>       2 XPASS
> 
> 

Re: glibc release process

[Carlos O'Donell]

On 6/19/24 7:27 AM, Andreas K. Huettel wrote:
> Hi Carlos, 
> 
>>>>> 3) Branch: 2 weeks before release
>>>>> Master is opened for development
>>>>> Release branch only accepts obvious and simple bugfixes and/or fixes for
>>>>> issues found during machine testing
>>>>
>>>> This seems to contradict implementing fixes that are issues for slower 
>>>> targets?
>>>
>>> Maybe I expressed myself wrong here. The main idea is, let's keep the
>>> release branch running for two more weeks under bugfix only rules.
>>> We have a chance to still address problems that are found during additional
>>> machine testing.
>>>
>>> [One could even think of cutting x.y_rc tarballs at this time
>>> to promote further testing.]
>>
>> I do not agree with (3) because it doesn't support objective A.
>>
>> I think we can branch *any time* we want if testing is complete for the long
>> running arches.
> 
> When is "testing complete"?

A member of the community reports testing results for the target to the release page on the wiki.

That triggers completion of testing IMO for the given target for that release.

Then the RM can decide if we're ready to release using this data.

> It's not as if we are working against a well-defined list of configurations
> here. We can't really say, here's a 100-item list of supported hardware, supported
> compiler flags, and supported configuration option combinations, we go through this
> list with autobuilders and regression tests and if nothing pops up we're good.

I agree that we do not have a well-defined list of configurations.

Loosely speaking I would like to see at least one set of results per target in any configuration.

The goal is to reduce risk by gathering data and evaluating the state of the targets.

With my downstream hat on I care about Fedora and RHEL for i686, x86_64, aarch64, ppc64le, s390x,
and now riscv64 (http://fedora.riscv.rocks/koji/buildinfo?buildID=308535).

> I'm trying to address the issues that fall outside such a grid and can't be caught
> by brute-force (i.e. throwing money and CI at it).

That helps reduce the risk that the release has defects, thank you.

The question we have to answer is how much time do we need and the value that provides.

>>
>> Lets try it out.
>>
>> Lets do 2 weeks of extra freeze time, but focus on getting all machine results
>> and see if we can cut and release EARLY. :-)
>>
> 
> We have this semi-strict rule in Gentoo that a package version can't enter "Gentoo
> stable" unless it's been around without significant changes for 4 weeks. One point
> of it is that no amount of automated testing will catch all bugs in all combinations,
> but our hordes of happy-go-lucky experimenting users using "Gentoo testing" will very
> likely stumble on some of them. Just waiting helps to make sure we're good.

I agree with this, but I took the opposite approach.

We are integrating glibc master into Fedora Rawhide on a weekly basis to find such
issues *rather than* at the end of the release cycle.

> This is why I'm against the speed focus.

If the time buys additional risk reduction then that's OK.

But if all targets report back they are good? Then we cut the branch early?

> And even if we re-open master for development, the release branch and the master code
> will most likely be tried and tested by different people (distributions and packagers on
> one side, glibc developers on the other).

My concern is that this takes developer focus away from fixing release critical
bugs and they instead look towards new work.

-- 
Cheers,
Carlos.

Re: glibc release process

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

> > We have this semi-strict rule in Gentoo that a package version can't enter "Gentoo
> > stable" unless it's been around without significant changes for 4 weeks. One point
> > of it is that no amount of automated testing will catch all bugs in all combinations,
> > but our hordes of happy-go-lucky experimenting users using "Gentoo testing" will very
> > likely stumble on some of them. Just waiting helps to make sure we're good.
> 
> I agree with this, but I took the opposite approach.
> 
> We are integrating glibc master into Fedora Rawhide on a weekly basis to find such
> issues *rather than* at the end of the release cycle.
> 
> > This is why I'm against the speed focus.
> 
> If the time buys additional risk reduction then that's OK.
> 
> But if all targets report back they are good? Then we cut the branch early?
> 

Let's try it.

I mean, we've done it recently too, releasing a bit earlier because everything 
looked good.

Also, in a way we're debating the cake before the eggs are laid... :)

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: sparc tests (catbus)

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

> > 
> > I ran the testsuite manually on the sparc machine, and it's actually quite good
> > (after pushing the new ULPs).
> > 
> > Will pick out the details later on. We should probably update the
> > system on the machine, it's still using gcc-12 and binutils-2.40... soon.
> > 
> > 
> > FAIL: debug/tst-fortify-c-default-3-def
> > FAIL: debug/tst-fortify-c-lfs-3-def
> > FAIL: debug/tst-fortify-c-nongnu-3-def
> > FAIL: debug/tst-fortify-cc-default-3-def
> > FAIL: debug/tst-fortify-cc-lfs-3-def
> > FAIL: debug/tst-fortify-cc-nongnu-3-def
> 
> These seems suspicious and I not seeing with gcc-13 built with build-many-glibcs.py
> on the same machine.

Well, the test program segfaults at end [1]. But, you're right, this goes away with gcc-13.
Then it looks even better (for a historic arch):

FAIL: elf/tst-pldd
FAIL: math/test-float64x-float128-mul
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/tst-arc4random-thread
FAIL: stdlib/tst-setcontext2
                === Summary of results ===
      5 FAIL
   4803 PASS
     23 UNSUPPORTED
     17 XFAIL
      2 XPASS

stdlib/tst-arc4random-thread is a timeout, stdlib/tst-setcontext2 failure is new in 2.40, 
the rest are the same as in 2.39. [2]

[1] https://sourceware.org/glibc/wiki/Testing/Tests/debug/tst-fortify-c-default-3-def
[2] https://sourceware.org/glibc/wiki/Release/2.40#SPARC_.2864-bit.29

The machine is updated by now (which should not affect test containers much though).

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]