Source: gtk4
Version: 4.14.4+ds-8
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-po...@lists.debian.org
Until recently, gtk4 was not buildable on any -ports architectures because
its build-dependency, weston, was uninstallable. Now it's installable, and
building and testing can be attempted.
gtk4's test suite is failing on all -ports architectures that have buildds,
except for m68k (which I believe builds with nocheck and therefore does not
run the test suite at all).
The GNOME team is busy with GNOME 47 on release architectures and
unlikely to have time to look into this in detail any time soon, but if
porting teams would like to have GTK 4 available (it will be increasingly
important for desktop architectures in trixie), it would be useful if
someone from -ports could investigate.
The gtk4 test suite is run in two phases:
1. with --setup=x11, wrapped by "debian/tests/run-with-display x11" which
is basically xvfb-run
2. with --setup=wayland, wrapped by "debian/tests/run-with-display wayland"
which is intended to be a Wayland equivalent of xvfb-run, using weston
in headless mode as the compositor
Taking powerpc as my arbitrary example, most tests are passing during the
x11 phase. On powerpc, I see a failure in "gtk:gtk / sorter" (unstable
and experimental) and in "gtk:gdk / memorytexture" (experimental only)
which can be investigated separately; please treat those isolated failures
as out-of-scope for the purposes of this bug.
However, in the wayland phase, most tests are failing with (fatal) warnings
like:
(/<<PKGBUILDDIR>>/debian/build/deb/testsuite/gtk/spinbutton:12693): Gtk-WARNING
**: 17:54:18.469: Failed to open display
weston might be broken on all -ports architectures and functional on
all release architectures, but that level of coincidence seems a little
far-fetched. So my next theory for this is that something is consistently
different about the -ports buildds - perhaps their XDG_RUNTIME_DIR is
set up differently? - and that is causing
"debian/tests/run-with-display wayland" (or the copy of weston that it
runs) to fail?
After the failure mode discussed in this bug report has been addressed,
it will become more useful to look at individual/isolated test
failures (as separate bug reports, please). Based on the status of the
less-production-ready release architectures like mips64el and riscv64, I
suspect that the most common root cause for individual test failures will
be the software OpenGL stack: implementation issues in Mesa's llvmpipe
and softpipe, implementation issues in LLVM's old MCJIT and new ORCJIT,
and the GTK packaging's choice of whether to mitigate llvmpipe bugs by
forcing softpipe (currently done on mips*, riscv*, powerpc, sparc*)
or test with llvmpipe (as we do on x86, ARM, etc.).
Thanks,
smcv
