Bug#1058687: gnome-shell: ftbfs on riscv64 due to tests failed

[Simon McVittie]

On Thu, 14 Dec 2023 at 21:59:19 +0800, Bo YU wrote:
> 10/12 gnome-shell:shell / perf-basic                  FAIL           189.57s   exit status 1
> 11/12 gnome-shell:shell / perf-closeWithActiveWindows FAIL            76.88s   exit status 1
> 12/12 gnome-shell:shell / perf-headlessStart          FAIL           100.23s   exit status 1
...
> It looks to be the same case as mips64el[1]. It will be built if on
> my local Unmatched with graphic card

It seems likely that this is a bug in Mesa or LLVM (specifically, Mesa's
software rendering drivers) rather than a bug in GNOME Shell.

On mips* architectures, there are several reported bugs against mesa
- https://bugs.debian.org/868745, https://bugs.debian.org/935884,
https://bugs.debian.org/1010838, https://bugs.debian.org/1049404 - which
do not seem to have had any response from mips* porters. This is not
really sustainable: desktop environment maintainers can't afford to spend
a large amount of time on learning how to fix bugs that are specific to
architectures with relatively few users, because that prevents us from
spending that time on fixing bugs that affect everyone.

If there is a similar issue for llvmpipe on riscv64, I would recommend
that the riscv64 community look into fixing that bug and making llvmpipe
work correctly, so that individual packages don't have to work around it.

I notice from the Mesa changelog that recent uploads of Mesa enabled
LLVM JIT on riscv64. Does that solve this bug?

Or, if that change *caused* this bug, please work with the mesa
maintainers to test llvmpipe on riscv64 and enable/disable/fix as
appropriate, so that only features that work are enabled.

> So the workaround allows Dedebia users to use the package(if so) ASAP.

I am reluctant to disable test coverage on new architectures if there is
any alternative, because the automated tests are usually the only evidence
we have that a new version of the package still works correctly on all
the architectures that Debian supports. Having a release architecture
where we can't expect automated tests to work correctly is not really
sustainable. I am not in a position to fix that for mips64el, but I can at
least try to avoid making the problem worse by doing the same on riscv64.

These tests being disabled on mips64el is a workaround that should be
avoided if possible. Unfortunately, they were only added relatively
recently (August 2023), so before that, nobody knew that GNOME Shell
didn't work on mips64el + llvmpipe; and based on past experience, doing
architecture-specific removals of GNOME components isn't practical,
because nobody knows what will happen in debian-installer if a desktop
task becomes uninstallable.

If GNOME is missing from riscv64 for now, as far as I know that isn't
a regression (it has never been available on riscv64 within official
Debian), and it gives riscv64 porters an incentive to get this fixed
properly.

(But I've cc'd the release team, to give them the opportunity to overrule
me on this, if they want to say that making GNOME available on riscv64
is more important than having test coverage that gives us some confidence
that it still works.)

    smcv