Source: gtk4
Version: 4.14.4+ds-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-mips@lists.debian.org,
debian-powe...@lists.debian.org, debian-sp...@lists.debian.org
User: debian-mips@lists.debian.org
Usertags: mips64el
src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
around #1010838. Mesa 24.2.x is no longer built with softpipe enabled,
so this makes the softpipe driver fail to load and as a result makes (E)GL
initialization fail, breaking the test suite on these architectures, for
example:
> test: gtk:gsk / normalize
> ...
> not ok /node/normalize/color -
> ERROR:../../../testsuite/gsk/normalize.c:18:test_normalize: assertion failed
> (error == NULL): Could not initialize EGL display (gdk-gl-error-quark, 0)
Affected tests are
* gtk:gsk / normalize (run twice, for X11 and Wayland)
* gtk:gsk / misc (run twice, ditto)
* gtk:tools / validate (only run once, for Wayland)
I have only verified this on mips64el, but it probably affects the powerpc
and sparc64 -ports architectures equally.
My preferred solution for this would be for Mesa to re-enable softpipe,
at least on the affected architectures (I've opened a src:mesa bug #1080475
requesting that). If we stop using softpipe in gtk4 before Mesa 24.2.x
migrates to testing, then we will likely get a different failure mode
with the Mesa from testing: #1010838.
I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether
we can use the new ORCJIT llvmpipe and remove the workaround for #1010838,
but it's taking a while (mips64el machines are not fast). So far it's
looking as though we will still get quite a lot of test failures.
smcv
