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

[Bo YU]

Hi!

On Fri, Dec 15, 2023 at 7:11 PM Simon McVittie <smcv at debian.org> wrote:
>
> 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.

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

I have not had a look at this but I will in the next days.
>
> 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.

In fact, that's what I think I'm going to do.
>
> > 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.)

Thanks for the positive feedback and constructive suggestions and I
will look at this issue cooperating with upstream because I have a
little knowledge about this. Also I vaguely remember a similar
discussion in other distro communities which may help with this. But I
am confident that this problem can be solved before the release team
gets involved in evaluating this(Debian Trixie release?):-).

BR,
Bo
>
>     smcv