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
