<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi maintianer,<br>
</p>
<p>Many cases can run pass in loong64, the result is following:</p>
<p>Summary of Failures:<br>
<br>
35/180 mutter:cogl+cogl/conform /
cogl-test-journal-gl3
FAIL 2.53s (exit status 250 or signal 122
SIGinvalid)<br>
36/180 mutter:cogl+cogl/conform /
cogl-test-journal-gles2
FAIL 2.53s (exit status 250 or signal 122
SIGinvalid)<br>
126/180 mutter:core+mutter/compositor /
stage-views
FAIL 39.84s (exit status 250 or signal 122
SIGinvalid)<br>
127/180 mutter:core+mutter/unit /
anonymous-file
FAIL 1.76s (exit status 250 or signal 122
SIGinvalid)<br>
178/180 mutter:core+mutter/x11 /
x11
FAIL 1.63s exit status 1<br>
<br>
Ok: 170 <br>
Expected Fail: 5 <br>
Fail: 5 <br>
Unexpected Pass: 0 <br>
Skipped: 0 <br>
Timeout: 0 <br>
</p>
<p>Only five cases failed, so I want disabled the case failed
firstly.</p>
<p>The detail test log in attachment.<br>
</p>
<p><br>
</p>
<p>On Wed, 17 Jan 2024 20:03:26 +0000 Simon McVittie <smcv@debian.org>
wrote:</smcv@debian.org></p>
<p><smcv@debian.org></smcv@debian.org></p>
<smcv@debian.org>> Control: tags -1 + moreinfo<br>
> <br>
> On Tue, 19 Dec 2023 at 16:07:18 +0800, yalingfang wrote:<br>
> > Attach the mutter's patch for loong64.<br>
> <br>
> The attached patch just disables some tests. On most
architectures,<br>
> especially "ports" architectures, successful tests are the
only evidence<br>
> we have that the package is functional.<br>
> <br>
> Does this mean that mutter compiles successfully on loong64,
but does<br>
> not actually work? If it doesn't work yet, then we shouldn't
be making<br>
> it available to loong64 users yet.<br>
> <br>
> Or is there other evidence that mutter works correctly on
loong64, and<br>
> a justification for why it's OK to ignore these failing
tests?<br>
> <br>
> I know we already ignore test failures on several
architectures, but<br>
> that's already a bad thing (technical debt), and expanding
that workaround<br>
> to new architectures seems like the wrong direction to be
going in.<br>
> <br>
> One common reason why tests in OpenGL-based packages fail on
mips64el and<br>
> riscv64 is that the Mesa llvmpipe driver is broken on those
architectures<br>
> (see #1058687). If this also affects loong64, then I would
recommend<br>
> that the loong64 community should look into fixing or
disabling the<br>
> llvmpipe driver so that individual packages don't have to
work around<br>
> it - from the discussion on #1058687, it seems that the work
on that<br>
> bug that is being done by the riscv64 community is going to
benefit<br>
> other architectures as well. Perhaps that includes loong64?
If yes,<br>
> perhaps you can help them to get that work finished and
merged?<br>
> <br>
> > When I compiled the mutter in Loongarch platform,
the mutter and <br>
> > gnome-settings-daemon depend each other.<br>
> <br>
> As far as I can see, the only mutter dependency in
gnome-settings-daemon<br>
> is for the tests. The standard way to bootstrap this is:<br>
> <br>
> - build gnome-settings-daemon with the nocheck build profile<br>
> (DEB_BUILD_PROFILES=nocheck);<br>
> <br>
> - use that to build mutter;<br>
> <br>
> - use that mutter to build gnome-settings-daemon again, this
time with<br>
> tests enabled<br>
> <br>
> Breaking circular dependencies with build profiles is a
standard thing<br>
> to do while bootstrapping a new architecture:<br>
> <a class="moz-txt-link-freetext" href="https://wiki.debian.org/DebianBootstrap">https://wiki.debian.org/DebianBootstrap</a><br>
> <br>
> Thanks,<br>
> smcv<br>
> <br>
> <br>
</smcv@debian.org><br>
</body>
</html>