Re: Bug#1058687: gnome-shell: ftbfs on riscv64 due to tests failed
Hi,
On 2023-12-15 11:11, Simon McVittie 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.
>
> I notice from the Mesa changelog that recent uploads of Mesa enabled
> LLVM JIT on riscv64. Does that solve this bug?
No it doesn't, and actually made things worse, many packages like gtk4
will now FTBFS. I reported the issue as #1058759.
While LLVM supports JIT, it only supports the orcjit interface as mcjit
is deprecated and does not accept new architectures. Support for the new
interface, orcjit, in mesa is being worked on, but it will take time
bringing it to the same level as mcjit [1]. Work to support orcjit in
mesa is be done by the riscv community [2] and will eventually benefit
all architectures when mcjit support gets removed from LLVM.
[1] https://lists.riscv.org/g/sig-graphics/topic/minutes_for_risc_v_graphics/97648261
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26018
> 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.
As said above, work on llvmpipe has already started, but it will take
time to get it merged upstream. Maybe the mesa maintainer in debian
should use the patch from the MR? Alternatively it softpipe should be
improved to provide an exact same rendering as llvmpipe.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: