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
