Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures
Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-mips@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el mipsel
gtk4 4.12.0 in experimental has test failures on multiple buildds.
Of those, mips64el and mipsel seem to have the same failure mode:
failure mode:
72/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl border-one-rounded flipped FAIL 5.47s exit status 1
315/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl opacity-overdraw FAIL 4.89s exit status 1
316/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl opacity-overdraw flipped FAIL 4.94s exit status 1
317/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-repeated-gl / gl opacity-overdraw repeated FAIL 5.05s exit status 1
318/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-rotated-gl / gl opacity-overdraw rotated FAIL 4.95s exit status 1
319/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-masked-gl / gl opacity-overdraw masked FAIL 5.02s exit status 1
1406/1464 gtk:reftest / reftest label-sizing.ui FAIL 19.29s 0/1 subtests passed
1422/1464 gtk:reftest / reftest opacity.ui FAIL 6.79s 0/1 subtests passed
These are "reftests", which work by rendering the same image in two
different ways and then doing a pixel-by-pixel comparison. Because
Debian buildds do not give us a way to capture test artifacts, the images
are output into the log with uuencode, for example these:
begin-base64 644 testsuite/gsk/compare/opacity-overdraw.png
iVBORw0KGgoAAAANSUhEUgAAAB4AAAAeCAYAAAA7MK6iAAAARklEQVRIie3WMQ4AIAxCUWo8uDev
B7BjYwc+I8tLmAgpjwayJlDgr9lVmYpWJJRP5zc1MDAwMDAwsDFcfq7qI3XHb2o/+AJ0lQS/vZJx
GQAAAABJRU5ErkJggg==
====
begin-base64 644 debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.out.png
iVBORw0KGgoAAAANSUhEUgAAAB4AAAAeCAYAAAA7MK6iAAAAS0lEQVRIie3WMQ4AIAhD0aIe3Isb
vACDA5GB35HlJWWpSb5VkFGBAn/Nio5HlopM+Rv8o4Z+PwYGBgYGBgauh8PpY8FGyk6/qvvBF6Er
BMOKG8HLAAAAAElFTkSuQmCC
====
begin-base64 644 debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.diff.png
iVBORw0KGgoAAAANSUhEUgAAAB4AAAAeCAYAAAA7MK6iAAAAKklEQVRIie3NoQEAIAzEwGdvZPeG
BUBR3J2MSQKfjFOsZHVO5uUDAAC82WlIAgJv9eZaAAAAAElFTkSuQmCC
====
The way these work is that they are output in sets of three: a reference
image, an actual output, and an artifically-enhanced diff image to
highlight what the difference is. See #1024391, #993550, #1003348 for
previous examples of architecture-specific rendering differences (#1024391
was not on mips*, but has details of how to run individual tests which
might be useful, while the other two were on mips*el).
I haven't reconstructed the actual images for a visual comparison yet.
If the mis-rendering doesn't seem release-critically bad then we'll work
around this by ignoring those particular test failures on mips*el.
mips*el are the only architectures where we are using the softpipe GL
driver (because llvmpipe appears to be otherwise broken there) so that is a
possible root cause.
Having to investigate and work around failing tests in GL-dependent
packages on mips*el is becoming a significant time sink for the GNOME team,
so I would appreciate it if mips porters could fix its llvmpipe so that it
can be back in the same situation as every other release architecture.
smcv
Reply to: