Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

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: [email protected], [email protected], [email protected], [email protected]
User: [email protected]
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