On Wed, Feb 19, 2025 at 05:05:49PM +0100, Lucas Nussbaum wrote:
> 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.
ah, nice! thanks for clarifying!
> But for now that's just a storage space
On 19/02/25 at 13:55 +0100, Santiago Vila wrote:
> 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:
> > > $ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep
> > > "multiple definition of \`Qt
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:
$ 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
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
On 18/02/25 at 13:21 -, Sune Vuorela wrote:
> On 2025-02-18, Michael Biebl 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.
>
On Tue, Feb 18, 2025 at 12:32:08PM +, Colin Watson wrote:
> 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
On 18.02.2025 14:32, Sune Vuorela wrote:
On 2025-02-18, Preuße Hilmar wrote:
Hello,
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.
What is the bug number in QT? Thanks!
H.
--
sigfault
OpenPGP_signature.asc
De
On 2025-02-18, Preuße Hilmar wrote:
> 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
On 18.02.2025 14:21, Sune Vuorela wrote:
On 2025-02-18, Michael Biebl wrote:
Hi
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
On 2025-02-18, Michael Biebl 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 wher
Hi
Am 18.02.25 um 13:34 schrieb Sune Vuorela:
On 2025-02-18, Matthias Klose wrote:
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 doub
Antonio Terceiro, le mar. 18 févr. 2025 10:00:18 -0300, a ecrit:
> 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 ne
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> 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 instanc
On 2025-02-18, Matthias Klose wrote:
> 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 1
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> 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
Am 18.02.25 um 11:05 schrieb Andrey Rakhmatullin:
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
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
On 18.02.25 10:21, Marco d'Itri wrote:
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
On Tue, Feb 18, 2025 at 09:06:53AM +0900, Charles Plessy wrote:
> 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
On Feb 18, Charles Plessy wrote:
> 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
On 18.02.25 01:06, Charles Plessy wrote:
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 di
Le 18 février 2025 01:06:53 GMT+01:00, Charles Plessy a
écrit :
>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)
* Charles Plessy [250218 01:07]:
> 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 t
22 matches
Mail list logo
