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 `-
Attachment:
signature.asc
Description: PGP signature