GCC-15 mass bug filing.

[Charles Plessy]

Hello everybody,

pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.

Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance), I want to question if the MBF is
premature. What other information do we get apart from "most upstreams
are not ready" ?

Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch. We are
not paid for that.

On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions. But who will
close the hundreds of bugs? I mean, query the BTS, get a bug number,
paste it in a changelog, etc, just to convey information about a change
that did not happen in Debian ? We are not paid for that.

If we want to have stats and know what is the percentage of our pakcages
that adopted GCC 15 compatibility at a given point of time, mass
rebuilds are enough. Salsa CI also comes to the mind. But before we
reach the point that we start to track release blockers, I question if
mass bug filings are a tool that makes the best use of our volunteer
time?

Have a nice day,

Charles

[Chris Hofstaedtler]

Post by Charles Plessy
On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions. But who will
close the hundreds of bugs? I mean, query the BTS, get a bug number,
paste it in a changelog, etc, just to convey information about a change
that did not happen in Debian ? We are not paid for that.

So you are saying you are not checking the BTS for bugs that
upstream fixed in new upstream version, before uploading a new
upstream version?

Chris

[Aurélien COUDERC]

Post by Charles Plessy
Hello everybody,
pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.
Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance), I want to question if the MBF is
premature. What other information do we get apart from "most upstreams
are not ready" ?

Same for the Qt/KDE stack. Every package in our perimeter got a bug report due to a Qt-related failure.

And it should all be fixed in the upcoming Qt upload as far as we know.

Post by Charles Plessy
Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch. We are
not paid for that.

At this scale even managing the Debian bugs seems like a waste of time. I don't think I'll touch mine.


Happy hacking,
--
Aurélien

[Matthias Klose]

Post by Charles Plessy
Hello everybody,
pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.

This is nothing new. See https://wiki.debian.org/ToolChain for all bugs
filed since GCC 4.9. Do you really want to have a yearly discussion to
file these bugs? The difference this year is having more than double of
the bug reports compared to GCC 14 last year.

I am usually filing these bug reports once the GCC upstream is in it's
final development phase, and the packages are available in experimental.

Post by Charles Plessy
Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance), I want to question if the MBF is
premature. What other information do we get apart from "most upstreams
are not ready" ?

Just looking at yesterday's replies to bug reports, there are also
upstreams listening on the Debian packages, and providing either fixes
or notes, which upstream versions fix these issues.

Debian also carries packages which are abandoned upstream, or where
Debian is the upstream.

Post by Charles Plessy
Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch. We are
not paid for that.
On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions. But who will
close the hundreds of bugs? I mean, query the BTS, get a bug number,
paste it in a changelog, etc, just to convey information about a change
that did not happen in Debian ? We are not paid for that.

If that would work, then why do we have still bug reports open filed
against GCC 14? I also was fixing GCC 14 issue when working on the
Python 3.13 transition? And yes, it's also the Debian Med team which has
these kind of bug reports open.

Post by Charles Plessy
If we want to have stats and know what is the percentage of our pakcages
that adopted GCC 15 compatibility at a given point of time, mass
rebuilds are enough. Salsa CI also comes to the mind. But before we
reach the point that we start to track release blockers, I question if
mass bug filings are a tool that makes the best use of our volunteer
time?

stats don't fix bugs, and in the end, these need to be addressed for the
forky release. I don't know how much Salsa CI would scale, and how
packagers would be notified about these issues.

Matthias

[Sune Vuorela]

Post by Matthias Klose
This is nothing new. See https://wiki.debian.org/ToolChain for all bugs
filed since GCC 4.9. Do you really want to have a yearly discussion to
file these bugs? The difference this year is having more than double of
the bug reports compared to GCC 14 last year.

What's the good way of dealing with multiple hundred bugs that can be
fixed with 1 change in another package ?

(a fix in a c++ header file in a popular library)

/Sune

[Michael Biebl]

Hi

Post by Sune Vuorela

Post by Matthias Klose
This is nothing new. See https://wiki.debian.org/ToolChain for all bugs
filed since GCC 4.9. Do you really want to have a yearly discussion to
file these bugs? The difference this year is having more than double of
the bug reports compared to GCC 14 last year.

What's the good way of dealing with multiple hundred bugs that can be
fixed with 1 change in another package ?
(a fix in a c++ header file in a popular library)

I guess a bit of shell scripting around `bts close` would suffice?
That assumes of course you can somehow (automatically) determine the
list of packages that are fixed by that one popular library.

Michael

[Sune Vuorela]

Post by Michael Biebl
I guess a bit of shell scripting around `bts close` would suffice?
That assumes of course you can somehow (automatically) determine the
list of packages that are fixed by that one popular library.

I'm not sure I'm up to scripting it, but all sources where a binary ends up
depending on libqt6core6 and has a bug report with the text
multiple definition of `QtPrivate::IsFloatType_v<_Float16>'
in it should be a good start if anyone wants to give it a go.

/Sune

[Sune Vuorela]

I have one. Should I add a usertag: gcc-15_fault_of_qt6 ?

I suggest just closing it. It does not bring any value at all.

/Sune

[Lucas Nussbaum]

Post by Sune Vuorela

Post by Michael Biebl
I guess a bit of shell scripting around `bts close` would suffice?
That assumes of course you can somehow (automatically) determine the
list of packages that are fixed by that one popular library.

I'm not sure I'm up to scripting it, but all sources where a binary ends up
depending on libqt6core6 and has a bug report with the text
multiple definition of `QtPrivate::IsFloatType_v<_Float16>'
in it should be a good start if anyone wants to give it a go.

there are some list of failures in
http://qa-logs.debian.net/2025/02/16/

that looks useful:
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple definition of \`QtPrivate::IsFloatType_v<_Float16>'"

Lucas

[Holger Levsen]

Post by Lucas Nussbaum
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple definition of \`QtPrivate::IsFloatType_v<_Float16>'"

qa-logs.debian.net! never heard of this before! what is it? seems to be very
nice!?! just http://qa-logs.debian.net/ doesn't explain :)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

It's the end of the world as we know it - and I feel fine.

[Marco d'Itri]

Post by Charles Plessy
Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch. We are
not paid for that.

We are not paid for anything at all, to be fair...
I think that we are expected to forward most bugs to upstreams.

Post by Charles Plessy
On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions. But who will

In my case, 4 of the bugs that I received were for retrocomputing-level
packages which has not had releases in years or decades.
The other 4 are all related to Varnish, and indeed if I procrastinate
enough then I expect that they will be solved upstream without any
involvement on my part.

Post by Charles Plessy
If we want to have stats and know what is the percentage of our pakcages
that adopted GCC 15 compatibility at a given point of time, mass
rebuilds are enough. Salsa CI also comes to the mind. But before we

I think that adding a GCC 15 build to the standard Salsa CI pipeline
would have been a nicer early warning than a MBF.
Maybe this could be considered by the time GCC 16 will start getting
ready to be useful?

[Matthias Klose]

Post by Marco d'Itri
I think that adding a GCC 15 build to the standard Salsa CI pipeline
would have been a nicer early warning than a MBF.
Maybe this could be considered by the time GCC 16 will start getting
ready to be useful?

are you volunteering? You could even do that now with GCC 15 to look for
bugs getting fixed upstream without touching the bug report.

[Andrey Rakhmatullin]

Post by Charles Plessy
Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch. We are
not paid for that.

Yes, Debian only expects that such bugs are forwarded upstream, not
that you also write a patch (unless it's a key package, anyway) and not
that you submit it upstream (though it makes sense if you wrote it).

Post by Charles Plessy
On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions.

Do we?

In my experience there are several classes of a package state in every
such transition (not just to a new GCC but e.g. to a new Python version or
to a new major dep version with API changes and deprecation removals), and
each class always contains a significant number of packages and can't be
ignored, ranging from good quality upstreams that already did the work and
maybe even have CI jobs with unreleased versions of deps, to long dead
upstreams, with many in-between states including ones where somebody needs
to notify the upstream about the problem, and in many cases it's either we
or other distro maintainer. I don't see that "the ecosystem" solves the
majority of bugs in advance without some help of some distro maintainer.

[Colin Watson]

Post by Charles Plessy
pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.
Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance), I want to question if the MBF is
premature. What other information do we get apart from "most upstreams
are not ready" ?

I for one appreciate this sort of early warning. It's much easier to
deal with failures like this promptly before they become a serious
problem, rather than having to disentangle things later when several
different failures have all piled up into a big ball of mud.

[Holger Levsen]

Post by Colin Watson
I for one appreciate this sort of early warning. It's much easier to
deal with failures like this promptly before they become a serious
problem, rather than having to disentangle things later when several
different failures have all piled up into a big ball of mud.

absolutly.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

When truth hurts, many prefer ignorance.

[Antonio Terceiro]

Post by Charles Plessy
Hello everybody,
pardon me but I do not see the GCC mass bug filing being discussed on
this list before it was started.
Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance), I want to question if the MBF is
premature. What other information do we get apart from "most upstreams
are not ready" ?
Again, given the scale, Debian can not expect that the package
maintainers are going to contact each upstream and send a patch. We are
not paid for that.
On the other hand, we also rely on "the ecosystem" to do the work by
themselves so that the packages eventually start to build fine with GCC
15 them after we upgrade them to newer upstream versions. But who will
close the hundreds of bugs? I mean, query the BTS, get a bug number,
paste it in a changelog, etc, just to convey information about a change
that did not happen in Debian ? We are not paid for that.
If we want to have stats and know what is the percentage of our pakcages
that adopted GCC 15 compatibility at a given point of time, mass
rebuilds are enough. Salsa CI also comes to the mind. But before we
reach the point that we start to track release blockers, I question if
mass bug filings are a tool that makes the best use of our volunteer
time?

I don't understand the reason for alarm, given that:

1) the bugs were not filed as release-critical, so it has no impact on
the release state of your package.

2) The bugs reports explicitly mention that the bugs are not targeted at
trixie.

I don't think that "OMG my packages have bugs and I need to fix them all
NOW" is a useful attitude, and nobody in their right mind should expect
this of any maintainer. Take it easy.

[Samuel Thibault]

Post by Antonio Terceiro

Post by Charles Plessy
Give the scale if build failure (hundreds of failures for the Debian Med
packaging team for instance),

I don't think that "OMG my packages have bugs and I need to fix them all
NOW"

He didn't write "NOW", but "hundreds of failures".

Please consider his position, receiving hundreds of bug reports that
will now need to be triaged.

Samuel