Your message dated Thu, 10 Apr 2025 11:20:06 +0200
with message-id <[email protected]>
and subject line Re: Bug#1102538: unblock: glib2.0 blocked by openjdk-25
autopkgtest on riscv64
has caused the Debian Bug report #1102538,
regarding unblock: glib2.0 blocked by openjdk-25 autopkgtest on riscv64
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1102538: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102538
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: [email protected], [email protected],
[email protected], [email protected]
Control: affects -1 + src:glib2.0 src:openjdk-25
User: [email protected]
Usertags: unblock
glib2.0_2.84.1-1 is currently not migrating, and if I'm reading the
excuses correctly, it's waiting for a successful autopkgtest run on
<https://ci.debian.net/packages/o/openjdk-25/testing/riscv64/> with the
proposed glib2.0. However, most testing attempts since 2025-03-25 (and
several before that) have timed out on riscv64.
This is preventing a CVE fix in glib2.0 from migrating (although
admittedly it is a rather tenous CVE, involving parsing a text date/time
that is more than 2GB of text).
Would it be possible to stop waiting for this particular test, or
alternatively apply a longer timeout on riscv64 for openjdk-25, until
riscv64 gets some faster CI workers?
(glib2.0's excuses entry cites a piuparts regression as the reason for
not migrating, but I think that might not really be true, because
https://piuparts.debian.org/sid/source/g/glib2.0.html doesn't list any
unsuccessful tests. Perhaps the machinery is confused by the existence
of a udeb, which can't be piuparts-tested?)
smcv
--- End Message ---
--- Begin Message ---
Hi,
On 10-04-2025 10:49, Simon McVittie wrote:
glib2.0_2.84.1-1 is currently not migrating, and if I'm reading the
excuses correctly, it's waiting for a successful autopkgtest run on
<https://ci.debian.net/packages/o/openjdk-25/testing/riscv64/> with the
proposed glib2.0. However, most testing attempts since 2025-03-25 (and
several before that) have timed out on riscv64.
I think the biggest problem is that autopkgtest fails to fail properly
(either bug #1084944 or similar) and tmpfails instead.
Would it be possible to stop waiting for this particular test,
Done.
alternatively apply a longer timeout on riscv64 for openjdk-25, until
riscv64 gets some faster CI workers?
Unfortunately debci currently doesn't have the knobs to do this on a
per-package basis. The timeout for riscv64 is twice that of other
architectures already.
(glib2.0's excuses entry cites a piuparts regression as the reason for
not migrating, but I think that might not really be true, because
https://piuparts.debian.org/sid/source/g/glib2.0.html doesn't list any
unsuccessful tests. Perhaps the machinery is confused by the existence
of a udeb, which can't be piuparts-tested?)
Might be, but I don't recall anything changed in this area recently, so
it's a bit of a surprise to see it now. So ignored for now. I've added
an ignore hint for this too.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
