Source: glib2.0
Version: 2.86.0-3
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-s390 at lists.debian.org
User: debian-s390 at lists.debian.org
Usertags: s390x
Control: block 1115340 by -1
After uploading glib2.0_2.86.0-3 I'm seeing a test regression on s390x,
which appears to be reproducible:
>328/405 glib:gio / gdbus-connection-slow RUNNING
>>>> G_ENABLE_DIAGNOSTIC=1 MALLOC_CHECK_=2 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 LD_LIBRARY_PATH=/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gmodule:/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gobject:/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/glib:/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio G_DEBUG=gc-friendly G_TEST_BUILDDIR=/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio/tests MESON_TEST_ITERATION=1 GIO_MODULE_DIR='' G_TEST_SRCDIR=/build/reproducible-path/glib2.0-2.86.0/gio/tests UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=225 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 GIO_LAUNCH_DESKTOP=/build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio/gio-launch-desktop /build/reproducible-path/glib2.0-2.86.0/debian/build/deb/gio/tests/gdbus-connection-slow
>▶ 325/405 /gdbus/close-pending OK
>▶ 328/405 /gdbus/connection/flush - GLib-GIO:ERROR:../../../gio/tests/gdbus-connection-slow.c:53:test_connection_flush_on_timeout: code should not be reached FAIL
>▶ 328/405 ERROR
>328/405 glib:gio / gdbus-connection-slow ERROR 1.04s killed by signal 6 SIGABRT
>――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
>stderr:
>Timeout waiting 1000 msec on iteration 0
>**
>GLib-GIO:ERROR:../../../gio/tests/gdbus-connection-slow.c:53:test_connection_flush_on_timeout: code should not be reached
>cleaning up pid 51567
This is asserting that when a subprocess sends a D-Bus signal, calls
g_dbus_connection_flush_sync(), and immediately exits, the parent
process receives the signal within 1 second. Presumably this arbitrary
timeout is too short for a mainframe designed for batch processing, or
something.
I don't know why 2.86.0-3 fails this when 2.86.0-2 succeeded.
smcv