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 <
emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/0, please excuse my verbosity
`-
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmY1VCsACgkQeTz2fo8N Edp76w/7BuEPOEy+P/i+asRECU++5L47RfjatutIb4+V37JZx5kfmHOTublbXjxj 9+zhQQWRra1VNcyPOd+fWwKzR46u/QMMLa3ffnTUrVgzLmW9k0hbDb3YuPdAP+cw 9hP7017jIjS9B1jKxtT+bv6OPOhSFZFgCD9AqzqKLyI7ZpZyVPey6A8Q26RrnXKa w2P/ih4PVXIsLMopiq0sAgywtszUnX9szTdk/rLsz5eXE9UiVmM4esx3MDyjV4oq r5joRq+tevT1m0noOPZ7nrFjlcfzSA86areuVsYUkyZWdZ0uykUBUrB0bXbS6Fao AGLk3bwpTudKitfOzC7KpH4eezALnh04gjEyCTOtqUVxBkrTN0/XnvXH0ha0jkFM kZRHuZEojfdUmluW543aToIAw2E9g/aH4YrbHmhI8YK8x9wpA0NCESZ/JzslVdYI g1A87eiql7dvbDUX06cIKtvXHRXKOeULPq+NEl+7anvWfV25Igesf+VPWphu3wAB dAzOSSUNsAnTQPGxvqYHT+EIubJD1u7xbBpTrmVIirOHizX/vOJjJi3QzKMT4KtX C47owAVcBRCIqA12x7Kwj4u7azbrv3H+ssQ1tZMU0DP9yVPY7OrNDyViQhCZS787 1Tv3CyiqpPxGYmJfRPicTghTtW9W134Anmbbd4Cvfr8O6WHow3Y=
=CBBU
-----END PGP SIG