Your message dated Sat, 7 Dec 2024 11:38:22 +0000
with message-id <z1qzrhbas3dee...@remnant.pseudorandom.co.uk>
and subject line Re: Bug#1087712: glib2.0: autopkgtest regression on amd64:
gsubprocess.test timed out after 300 seconds
has caused the Debian Bug report #1087712,
regarding glib2.0: autopkgtest regression on amd64: gsubprocess.test timed out
after 300 seconds
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 ow...@bugs.debian.org
immediately.)
--
1087712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087712
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: glib2.0
Version: 2.82.2-2
Severity: serious
Justification: rc_policy.txt 6a
X-Debbugs-Cc: debian...@lists.debian.org
GLib is failing its autopkgtests on amd64 since about 2024-11-12
(the most recent successful test was 2024-11-09, the first failed test
I see was 2024-11-12). I think the important part of the log is this:
> 519s ok 10 /gsubprocess/echo-merged
> 519s ok 11 /gsubprocess/cat-utf8
> 520s ok 12 /gsubprocess/cat-eof
> 520s # slow test /gsubprocess/cat-eof executed in 1.01 secs
> 524s # Executing: glib/gsubprocess.test
> 529s # Executing: glib/gsubprocess.test
...
> 789s # Executing: glib/gsubprocess.test
> 791s not ok - Test timed out after 300 seconds
> 794s # Executing: glib/gsubprocess.test
> 799s # Executing: glib/gsubprocess.test
> 804s # Executing: glib/gsubprocess.test
> 809s # Executing: glib/gsubprocess.test
> 814s # Executing: glib/gsubprocess.test
> 816s not ok - Test timed out after 300 seconds
> 816s # FAIL: glib/gsubprocess.test (Child process killed by signal 9)
> 816s not ok - glib/gsubprocess.test
2.82.2-2 previously passed tests, so I think this is a regression triggered
by some external factor rather than being caused by a GLib change. Perhaps
the testbed container had an upgrade to an important package like glibc, or
perhaps there was an upgrade on the host system that touched something like
the kernel or systemd? (Maybe Debian 12.8?)
One possible root cause for timeouts during subprocess-launching is if
there was an increase to rlimits that causes iteration over all possible
fds to take a long time (dbus had a similar issue recently).
I think this should not block migration of 2.82.2-3, which is no worse in
this respect than the 2.82.2-2 currently in testing.
smcv
--- End Message ---
--- Begin Message ---
On Sun, 17 Nov 2024 at 15:22:10 +0000, Simon McVittie wrote:
> GLib is failing its autopkgtests on amd64 since about 2024-11-12
> (the most recent successful test was 2024-11-09, the first failed test
> I see was 2024-11-12).
...
> 2.82.2-2 previously passed tests, so I think this is a regression triggered
> by some external factor rather than being caused by a GLib change.
This seems to be passing again since 2024-12-01, and I wasn't able
to reproduce the issue locally. Let's assume this was a bug in some
system component (kernel? glibc? systemd? lxc? etc.) and ignore it,
unless it recurs.
smcv
--- End Message ---
