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.
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.
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?
Again, given the scale, Debian can not expect that the packageWe are not paid for anything at all, to be fair...
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 GCCIn my case, 4 of the bugs that I received were for retrocomputing-level packages which has not had releases in years or decades.
15 them after we upgrade them to newer upstream versions. But who will
If we want to have stats and know what is the percentage of our pakcagesI think that adding a GCC 15 build to the standard Salsa CI pipeline
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
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.
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?
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.
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" ?
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?
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
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"
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 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.
I have one. Should I add a usertag: gcc-15_fault_of_qt6 ?
On 2025-02-18, Michael Biebl <email@michaelbiebl.de> wrote:
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.
that looks useful:
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple definition of \`QtPrivate::IsFloatType_v<_Float16>'"
On Tue, Feb 18, 2025 at 06:19:45PM +0100, Lucas Nussbaum wrote:
that looks useful:
$ 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 :)
El 19/2/25 a las 12:42, Holger Levsen escribi:
On Tue, Feb 18, 2025 at 06:19:45PM +0100, Lucas Nussbaum wrote:
that looks useful:qa-logs.debian.net! never heard of this before! what is it? seems to be very
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple definition of \`QtPrivate::IsFloatType_v<_Float16>'"
nice!?! just http://qa-logs.debian.net/ doesn't explain :)
It's just the machine where Lucas puts the build logs of his archive rebuilds.
You can see it in every bug report he sends ("see this url for the full build log").
Yes. At some point it would be nice to design a real service that
exposes all build logs with their context, similar to what is done on ci.debian.net.
But for now that's just a storage space for logs. I used
to use people.d.o for that but the disk space requirements were a
problem.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 38:33:15 |
| Calls: | 10,392 |
| Files: | 14,064 |
| Messages: | 6,417,176 |