Dear Maintainer,

The package always has fbtfs issue since 44.3-5(sid) on riscv64 due to
test failed:

```
Summary of Failures:

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

```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=gnome-shell&arch=riscv64&ver=44.7-1&stamp=1702467594&raw=0

It looks to be the same case as mips64el[1]. It will be built if on
my local Unmatched with graphic card and it would be not crash when
built with the attached debdiff.

The right way to fix the issue should from root cause but this may take
some time for me. In addition to the package never be built since
riscv64 official rebootstrap. So the workaround allows Dedebia users to
use the package(if so) ASAP.

I will track the issue until upstream fix it. In the meantime, I'll report
this issue to upstream also.


[1]: https://salsa.debian.org/gnome-team/gnome-shell/-/blame/debian/latest/debian/rules#L49

...

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.

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

Hi!

Yeah, I agree with that.

I have not had a look at this but I will in the next days.

In fact, that's what I think I'm going to do.

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

Hi,

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

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

(cc -= release team, += Mesa)
...

That's unfortunate, and I hope that can be resolved soon.

That's great to hear, and sounds like a much more sustainable thing for
the longer term.

Some of the bugs I've seen involving mips64el have been "this reftest is
misrendered by softpipe", and I'm willing to disable those on softpipe
architectures, especially if a porter for the relevant architecture can
confirm that on real hardware, everything is fine.

The ones I'm more concerned about are the bugs of the form "this test-case
crashes when using softpipe", and as far as I can tell, the gnome-shell
test failures under discussion in this particular bug report are in
that category: with softpipe, the Shell doesn't render the wrong pixels
successfully, it just doesn't work at all. But maybe I'm reading the
log wrong?

    smcv

Hi,
...

The good news is that llvmpipe support riscv64 with orcjit has been
merged[0]!

[0]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26018
https://buildd.debian.org/status/logs.php?pkg=gnome-shell&arch=riscv64

I have saw some Debian users to run gnome on vf2 but I am failed to
login in gnome on my Unmatched due to others reason.

Please feel free to reopen this if any issue.

Close the reportbug, thanks!

That's great news. I hope that this can be extended to other problematic
architectures like mips64el in future.

No, the new upstream release works around the issue, allowing it to be
downgraded from RC. The test suite is run with `--no-suite shell`,
first on mips* and then on all architectures.

The fact that a package does not FTBFS does not necessarily imply that
its tests pass: sometimes we are forced to disable failing tests because
Debian's policy around release architectures means that the alternative
would be removing GNOME from Debian, which would be a disservice to
our users.

    smcv

Hi,
...
Thanks for sharing this. I thought these test cases had passed.:(
Indeed.

I will reopen the issue with a non-RC severity. Sorry for the noise.

BR,
Bo