Hi Yokota, yokota, on 2024-05-02: > > If so, it may be needed to bring the case upstream; maybe the > > nature of the fuzzing test makes it long or flaky, in which case > > it may be better to skip it, otherwise it may cause issues on > > buildds[2] and autopkgtest Debian CI[3] (once the package is > > built and starts being tested). If not, then let's keep an eye > > on the QA infrastructure and see what happens. > > I add another fixups to pyppmd as your suggest. Please upload it.
Thanks for bringing the modification, it is important that test
suites do not hang build and CI infrastructure. In addition to
CPU cycles burnt, this also draws attention of developers who
might have better spent their time on other issues. I have not
uploaded yet though: I am still pondering whether getting the
big endian test failures would be easily doable or not.
> I think it's better than previous one, but I can't test it on non-X86
> platforms.
> If you have more better fixups, please add your one.
As you seem to have noticed, the test suite is raising a couple
of test errors on big endian systems, namely s390x and ppc64
builds go through down test suites, but the following items are
failing:
FAILED tests/test_ppmd8.py::test_ppmd8_encode_decode[8388608-0] -
assert 1237259 == 1237262
FAILED tests/test_ppmd8.py::test_ppmd8_encode_decode[8388608-1] -
assert 1237259 == 1237262
FAILED tests/test_ppmd8.py::test_ppmd8_encode_decode[1048576-1] -
assert 1237261 == 1237262
This suggests the ppmd encode and decode cycle may have problems
preserving the integrity of user data on big endian systems.
The ideal course of action would be to liaise with upstream and
see whether they could have an idea what could have gone wrong
in such configuration, devise on a fix, apply it to the package
(via a new upstream version, or a patch if newer upstream is not
available for a while). Overall, it is a good thing this issue
went on our radar, otherwise it could result in corruption of
user data on big endian systems. Good job! :}
If you feel confident about bringing corrections to big endian
systems, the package qemu-system-misc provides among other
systems an s390x emulator. I'm using this when I need to
investigate architecture specific bugs, almost always in
combination with the package qemu-user-static, so that I can
chroot straight in a foreign architecture container without the
overhead of having to deploy and maintain an entire virtual
machine. I could use that method to reproduce the test failures
on my personnal (little-endian) computer.
Otherwise, I'm afraid I don't really have any fixup to propose
myself. If fixing the package on big endian systems is going to
be a problem, an option would be to liaise with the ftpmaster
team using a Package removal - Request Of Maintainer template
bug; you can get one by running reportbug ftp.debian.org. In
the report, justify that following introduction of the test
suite, it has been discovered the package was not suitable for
big endian systems in its current state, due to concerns with
user data integrity. This would then buy us some time for
properly investigating the correction, while allowing the
package to migrate to testing, and disallowing the package from
being available on s390x and putting sid users data at risk.
Speaking of upstream, I see you have been accumulating a good
wealth of patches. I believe several of them would be of
interest to improve upstream code. This would ultimately
benefit everyone, and not just Debian users. Have you
considered proposing your changes upstream?
Have a nice day, :)
--
.''`. Étienne Mollier <emoll...@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/0, please excuse my verbosity
`-
signature.asc
Description: PGP signature
