Source: gtk4
Version: 4.8.2+ds-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-s...@lists.debian.org, debian-powerpc@lists.debian.org
Control: clone -1 -2
Control: retitle -2 gtk+3.0: FTBFS on big-endian: some dependency made
border-image-excess-size reftest regress
Control: reassign -2 src:gtk+3.0 3.24.34-3
gtk4 4.8.2+ds-2 failed to build from source on s390x and ppc64. This is
*not* a regression caused by the changes in 4.8.2+ds-2: I built 4.8.2+ds-1
on the s390x porterbox zelenka, and it failed in the same way in either
bookworm or sid.
gtk+3.0 3.24.34-3 has the equivalent issue, originally seen in 3.24.34-4.
I suspect this is not a GTK bug, but was instead caused by some library
that GTK depends on and that has changed since 2022-10-29.
Unfortunately, a lot of dependencies have changed in that time,
porterboxes can't run debbisect with an unprivileged container because
/proc/sys/kernel/unprivileged_userns_clone is disabled, and I don't
have root on a big-endian machine to be able to bisect this. Possible
candidates include mesa, pixman and tiff.
To reproduce: build gtk+3.0 or gtk4 from source. For a quicker re-test,
after compiling GTK once, you can run this (in gtk4):
dbus-run-session -- debian/tests/run-with-display x11 meson test -C
debian/build/deb --setup=x11 --print-errorlogs "reftest
border-image-excess-size.ui"
or this (in gtk+3.0):
dbus-run-session -- xvfb-run -a
debian/build/deb/testsuite/reftests/gtk-reftest -o
debian/build/deb/testsuite/reftests/output -d
debian/build/deb/testsuite/reftests
testsuite/reftests/border-image-excess-size.ui
Expected result: tests pass
Actual result: the "border-image-excess-size" test fails. Images are
written to
debian/build/deb/testsuite/reftests/output/x11/border-image-excess-size.{ref,out,diff}.png
(in gtk4) or to
debian/build/deb/testsuite/reftests/output/border-image-excess-size.{ref,out,diff}.png
(in gtk+3.0).
The .ref.png file is the result of rendering a simpler scene that should
produce the same pixels as the test.
The .out.png file is the result of rendering the actual feature under test.
In this case, the expected rendering is a 10x10 pixel square with green
corners and black everywhere else, and the actual rendering is a 10x10
pixel square with magenta corners and black everywhere else. This makes me
suspect that colour channels might be in the wrong order or something.
I'll ignore this test failure for now and downgrade these bugs to non-RC.
smcv
