Source: gtk4
Version: 4.15.6+ds-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el
Control: block 1079548 by -1
After upgrading some lower-level component (my guess would be Mesa
24.1.x -> 24.2.x but I could be wrong), I'm seeing one test-case failing
in the memorytexture executable, in a gtk4 version where it previously
passed.
In different builds with different GTK4 versions, I'm variously seeing
# (0 0): 0.600098 1.000000 0.199951 != 89920.000000 89920.000000 89920.000000
# (1 0): 0.600098 1.000000 0.199951 != 89920.000000 89920.000000 89920.000000
# (2 0): 0.600098 1.000000 0.199951 != 89920.000000 89920.000000 89920.000000
...
# (109 271): 0.600098 1.000000 0.199951 != 89920.000000 89920.000000
89920.000000
# (110 271): 0.600098 1.000000 0.199951 != 89920.000000 89920.000000
89920.000000
# (111 271): 0.600098 1.000000 0.199951 != 89920.000000 89920.000000
89920.000000
not ok 455 /memorytexture/download_random/r16g16b16-float/ngl
or
# (0 0): 0.000000 1.000000 0.199951 != -71104.000000 1.000000 0.199951
not ok 125 /memorytexture/download_1x1/r16g16b16-float/ngl
or
# r16g16b16-float (0 0): 0.533203 0.133301 0.533203 != 98240.000000 -137.875000
87.125000
not ok 125 /memorytexture/download_1x1/r16g16b16-float/ngl
In each case the left side of the "!=" is the pixel we expected to see,
and the right side is what we got.
The common factors are that this is using a 16 bits per channel half-float
texture format in conjunction with the NGL ("new" OpenGL) renderer. The
same test-case with the GL ("old" OpenGL) renderer is still working.
Unlike other bugs that have been seen on architectures where we use the
softpipe Mesa driver, this one seems to be specific to mips64el and does
not affect riscv64.
4.14.x in testing/unstable does not seem to be affected, but we are overdue
for uploading 4.15.x/4.16.x to unstable, which is blocking a lot of GNOME
libraries and applications.
I do not have any mips hardware or much remaining patience for
architecture-specific issues, so I'm going to mark the 16-bit half-float
tests to be skipped on mips64el and downgrade the severity of this bug to
important. Anyone else is very welcome to investigate further.
We could potentially mitigate any user-visible impact of this by forcing
use of GTK's "old" OpenGL renderer on mips64el, although that might
cause brokenness elsewhere (the "new" renderer is the default if Vulkan
is not available, and I suspect that the "old" renderer is essentially
unmaintained upstream).
smcv
