Your message dated Sat, 7 Dec 2024 11:38:22 +0000 with message-id <[email protected]> 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 [email protected] immediately.) -- 1087712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087712 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: glib2.0 Version: 2.82.2-2 Severity: serious Justification: rc_policy.txt 6a X-Debbugs-Cc: [email protected] 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 ---
