Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

2023-08-23 Thread Simon McVittie
Control: tags -1 - pending

On Sat, 19 Aug 2023 at 12:34:31 +0100, Simon McVittie wrote:
> 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.

The mis-rendering doesn't seem likely to cause RC-severity bugs for end
users, so yes I'm going to ignore them.
https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/16

smcv



Processed: Re: Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

2023-08-23 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 - pending
Bug #1050077 [src:gtk4] gtk4: 4.12 regression: FTBFS on mips(64)el: multiple 
test failures
Ignoring request to alter tags of bug #1050077 to the same tags previously set

-- 
1050077: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050077
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

2023-08-19 Thread Simon McVittie
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-m...@lists.debian.org
User: debian-m...@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
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iRklEQVRIie3WMQ4AIAxCUWo8uDev
B7BjYwc+I8tLmAgpjwayJlDgr9lVmYpWJJRP5zc1MDAwMDAwsDFcfq7qI3XHb2o/+AJ0lQS/vZJx
GQBJRU5ErkJggg==


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.out.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iS0lEQVRIie3WMQ4AIAhD0aIe3Isb
vACDA5GB35HlJWWpSb5VkFGBAn/Nio5HlopM+Rv8o4Z+PwYGBgYGBgauh8PpY8FGyk6/qvvBF6Er
BMOKG8HLAElFTkSuQmCC


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.diff.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iKklEQVRIie3NoQEAIAzEwGdvZPeG
BUBR3J2MSQKfjFOsZHVO5uUDAAC82WlIAgJv9eZaAElFTkSuQmCC


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