Re: py7zr-related python packages was updated
Hi Yokota, Étienne Mollier, on 2024-05-05: > yokota, on 2024-05-05: > > I was drop s390x from python-pyppmd build architecture list to pass > > testing migration. > > I see you ajusted the Architecture field to include all > currently supported Debian architectures except s390x. While > this would avoid building attempts on s390x, this is actually > not ideal, because future architectures will have to be added by > hand. Besides, if s390x were to be supported by upstream, then > it would be necessary to actively bring back s390x architecture > to the list, assuming we notice the added support in the first > place. If you were to want to signify the package does not > support other than little-endian architectures, then the current > recommended practice is for the source package to build depend > on the package architecture-is-little-endian, and bring > Architecture field back to the value "any". > > All that being said, I don't believe declaring any form of > architecture limitation is needed, because the test failure at > build time prevents the production of packages for unsupported > architectures. Please revert Architecture field change; you may > add the architecture-is-little-endian as build dependency if you > feel better about not trying to build on other systems, but it's > not entirely needed in my opinion. Thanks, I saw you reverted the change about architecture list. > In any case, the package would not migrate to testing, because > despite the architecture restrictions, Debian infrastructure[1] > will continue expecting s390x packages to be built; the > following migration excuses will continue to appear: > > * missing build on s390x > * arch:s390x not built yet, autopkgtest delayed there > > I opened the package removal bug #1070469 for python-pyppmd on > s390x[2]. This will resolve the problem on the infrastructure > side, but requires human intervention from the ftpmaster team, > so it may take a little time. I used `reportbug ftp.debian.org` > to get a template email with all the metainformation needed, and > filled the blanks with our observations. > > [1]: https://tracker.debian.org/pkg/python-pyppmd > [2]: https://bugs.debian.org/1070469 The ftpmaster team removed the package from s390x. As the package was now suitable for upload, I proceeded (with a minor change to fix a typo in the changelog). python-pyppmd should be able to migrate to testing in a couple of days. Thank you for your contribution! Have a nice day, :) -- .''`. Étienne Mollier : :' : 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
Re: py7zr-related python packages was updated
Hi Yokota, yokota, on 2024-05-05: > I was drop s390x from python-pyppmd build architecture list to pass > testing migration. I see you ajusted the Architecture field to include all currently supported Debian architectures except s390x. While this would avoid building attempts on s390x, this is actually not ideal, because future architectures will have to be added by hand. Besides, if s390x were to be supported by upstream, then it would be necessary to actively bring back s390x architecture to the list, assuming we notice the added support in the first place. If you were to want to signify the package does not support other than little-endian architectures, then the current recommended practice is for the source package to build depend on the package architecture-is-little-endian, and bring Architecture field back to the value "any". All that being said, I don't believe declaring any form of architecture limitation is needed, because the test failure at build time prevents the production of packages for unsupported architectures. Please revert Architecture field change; you may add the architecture-is-little-endian as build dependency if you feel better about not trying to build on other systems, but it's not entirely needed in my opinion. In any case, the package would not migrate to testing, because despite the architecture restrictions, Debian infrastructure[1] will continue expecting s390x packages to be built; the following migration excuses will continue to appear: * missing build on s390x * arch:s390x not built yet, autopkgtest delayed there I opened the package removal bug #1070469 for python-pyppmd on s390x[2]. This will resolve the problem on the infrastructure side, but requires human intervention from the ftpmaster team, so it may take a little time. I used `reportbug ftp.debian.org` to get a template email with all the metainformation needed, and filled the blanks with our observations. [1]: https://tracker.debian.org/pkg/python-pyppmd [2]: https://bugs.debian.org/1070469 In hope this clarifies things, Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: TCP - Impetus signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hello Étienne, I was drop s390x from python-pyppmd build architecture list to pass testing migration. Please upload pyppmd package. -- YOKOTA Hiroshi
Re: py7zr-related python packages was updated
Hi Étienne, > 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? I was sent our patches to upstream. And ask about pyppmd for big-endian systems. -- YOKOTA Hiroshi
Re: py7zr-related python packages was updated
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 : :' : 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
Re: py7zr-related python packages was updated
Hello Étienne, > 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. 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. -- YOKOTA Hiroshi
Re: py7zr-related python packages was updated
Hi Yokota, Étienne Mollier, on 2024-05-01: > Étienne Mollier, on 2024-04-30: > > yokota, on 2024-04-30: > > > * https://salsa.debian.org/python-team/packages/python-pyppmd > > I uploaded python-inflate64 and python-pyppmd after a few > changes to the debian/changelog file. I don't have much to add > that I hadn't mentioned yesterday about the previous upload. About python-pyppmd, the fuzzer test looks to be flaky. Among the multiple runs I did, I experienced a long test time once, which I aborted and retried. This looks to have led Salsa CI to run into timeout[1]. Is it something you ran into? 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. [1]: https://salsa.debian.org/python-team/packages/python-pyppmd/-/jobs/5667204 [2]: https://buildd.debian.org/status/package.php?p=python-pyppmd=sid [3]: https://ci.debian.net/packages/-/search?query=python-pyppmd Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Jonas Lindberg & The Other Side - Peace Of Mind signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hi Yokota, Étienne Mollier, on 2024-04-30: > yokota, on 2024-04-30: > > I was uploaded fixes as you suggested. > > Please upload them. […] > > * https://salsa.debian.org/python-team/packages/python-brotlicffi I proceeded to a couple of minor changes to debian/changelog. Good catch with the MIT/Expat licensing terms that weren't well attributed initially! The change was missing from the changelog though. If that helps, I found it beneficial in my workflow to template my d/changelog file using my git messages with the command: $ gbp dch --full Documentation is available in the gbp-dch(1) manual page. Note that it may require some getting used to, as the new entries get appended starting from the oldest commit that did not touch the d/changelog file, and may behave unexpectedly if mixed with other tools like routine-update or lintian-brush, that write changelog entries on a per-commit basis. The package looked otherwise in good shape in my opinion, I thus proceeded to an upload. For your next uploads, I see the MIT/Expat license is written twice in the d/copyright file. I thought you might want to deduplicate it, see abpoa's[1] for an example. [1]: https://salsa.debian.org/med-team/abpoa/-/blob/master/debian/copyright?ref_type=heads > > * https://salsa.debian.org/python-team/packages/python-inflate64 > > * https://salsa.debian.org/python-team/packages/python-pyppmd I uploaded python-inflate64 and python-pyppmd after a few changes to the debian/changelog file. I don't have much to add that I hadn't mentioned yesterday about the previous upload. I kind of question whether I should have mentioned Source-only upload entries in my previous email. This entry is generally not needed. It is useful only when a source package upload is required without any changes to the packaging; the idea is thus to pad the changelog entry with something as it would be otherwise empty. I'm sorry I may not have been very clear introducing this concept in my early message, you probably won't have to worry about it. > > I also uploads other py7zr-related packages to add your suggested fixes. > > Please also upload them. > > > > * https://salsa.debian.org/python-team/packages/python-multivolumefile > > * https://salsa.debian.org/python-team/packages/python-pyzstd Both uploaded, checkout the d/changelog fixup, there is not much to add otherwise. Both packages were already in good shape. Thank you for your contributions! Have a nice day, :) -- .''`. Étienne Mollier : :' : 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
Re: py7zr-related python packages was updated
Hi Yokota, yokota, on 2024-04-30: > I was uploaded fixes as you suggested. > Please upload them. > > * https://salsa.debian.org/python-team/packages/python-bcj I reviewed python-bcj and only had a few minor modifications to bring to the debian/changelog. They were mainly a matter of rereading and maybe style, but please do have a look at these changes in case you want to bring them to the other packages too. Otherwise the package was fit for upload, so I proceeded. Thank you for your contribution! :) I will continue tomorrow morning utc with the other packages, unless someone else beats me at it. > * https://salsa.debian.org/python-team/packages/python-brotlicffi > * https://salsa.debian.org/python-team/packages/python-inflate64 > * https://salsa.debian.org/python-team/packages/python-pyppmd > > > I also uploads other py7zr-related packages to add your suggested fixes. > Please also upload them. > > * https://salsa.debian.org/python-team/packages/python-multivolumefile > * https://salsa.debian.org/python-team/packages/python-pyzstd Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Gracious! - Hold Me Down signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hello Étienne, I was uploaded fixes as you suggested. Please upload them. * https://salsa.debian.org/python-team/packages/python-bcj * https://salsa.debian.org/python-team/packages/python-brotlicffi * https://salsa.debian.org/python-team/packages/python-inflate64 * https://salsa.debian.org/python-team/packages/python-pyppmd I also uploads other py7zr-related packages to add your suggested fixes. Please also upload them. * https://salsa.debian.org/python-team/packages/python-multivolumefile * https://salsa.debian.org/python-team/packages/python-pyzstd If something wrong, please tell me. thanks, -- YOKOTA Hiroshi
Re: py7zr-related python packages was updated
Hi Yokota, yokota, on 2024-04-28: > > * https://salsa.debian.org/python-team/packages/python-pyppmd I reviewed through python-pyppmd and my remark are somewhat similar to packages I previously saw. 1. The debian/changelog misses the introduction of the patch to fix build failures on non-amd64 CPU architectures. 2. Introduction of autopkgtest-pkg-pybuild instead of -python would render the Testsuite non-superficial. This is not mandatory, but it is a low hanging fruit that would bring substancial quality to the package. I note the test is running at build time for this one, which is good. :) 3. I suggest again dh-sequence-python3 instead of dh-python. All that being said, the package looks to me in good shape, and I will have no objections to upload it once the changelog matches all the changes since 1.1.0+ds-1. I'll have a look at python-brotlicffi next, but I don't expect to have anything new to say. Don't hesitate to apply my existing feedback and suggestions on this package if I don't follow up explicitly on it, and to ping again once you think it is ready for upload. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Future Crew - Second Reality (part II) signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hi again Yokota, yokota, on 2024-04-28: > > * https://salsa.debian.org/python-team/packages/python-bcj I went through python-bcj this time, my observations follow. 1. Comparing to 1.0.2+ds-1, 1.0.2+ds-2, there are a few more changes than the ones documented in the debian/changelog. Please also document introduction of the quilt patch 0001-Avoid-to-use-sparc-keyword.patch, and introduction of the file debian/python3-bcj.docs. This has to be done before upload. 2. I would also recommend to enable build time tests and then replace the Testsuite by autopkgtest-pkg-pybuild, similarly to what I explained for python-inflate64. 3. I would also suggest the migration to dh-sequence-python3, similarly to what I explained for python-inflate64. The package looks in otherwise good shape, and I will be happy to upload once at least the content of the debian/changelog is matching the actual packaging changes since version 1.0.2+ds-1. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Malcolm Smith - Monkey Signature signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hi Yokota, yokota, on 2024-04-28: > Hello Debian Python Team, > > > My py7zr-related Python packages are updated to fix some issues. […] > > * https://salsa.debian.org/python-team/packages/python-inflate64 Thanks for your work on the py7zr stack, I reviewed through python-inflate64 and noticed the following documented changes were already part of the package in version 1.0.0+ds-1, so they should not appear in the changelog of version 1.0.0+ds-2: * Standards-Version: 4.7.0 (routine-update) * Testsuite: autopkgtest-pkg-python (routine-update) If you want to upload the package as-is without further changes for it to migrate to testing, the only entry would be: * Source-only upload. I would proceed to a source-only upload if you like, but I though it would be a good time for two recommendations with relation to the test suite (plus one recommendation relative to Python packaging). 1. Upstream source code embeds a pytest test suite below the tests/ directory. I think it would be well worth running them at build time through pybuild infrastructure. In the present case, this can be done easily by appending the build dependency python3-pytest to the package (the nocheck marker is to indicate the build dependency is only needed for running the test suite). 2. Once the test suite is up and running through pybuild, you may have noticed that routine-update added a Testsuite field to your debian/control. This enables somewhat automated autopkgtest to your package with little to no effort. The Testsuite automatically appended by routine-update is autopkgtest-pkg-python, but it is a bit limited as it only runs superficial checks: loading the Python module and check whether its version can be fetched. If you replace the Testsuite by autopkgtest-pkg-pybuild, the superficial test will be replaced by the test caught by pybuild, which in turn will have much more coverage. Standard migration time from unstable to testing is five days, but with non- superficial autopkgtest, this can be reduced as low as two days. 3. I would also suggest moving from dh-python to dh-sequence-python3, this will allow you to remove the --with=python3 argumen from your debian/rules file. Let me know when you have pushed commits for a source-only upload, or integrated the test suite to the packaging, and I will proceed to another review and hopefully upload. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Cosmosquad - Jam For Jason PS: I'm under the impression these changes didn't make it to the VCS initially, hence the confusion with changelog entries, but I may guess wrong; the debian/1.0.0+ds-1 tag is missing though. Andreas, do you per chance still have the tag on your hard drive? signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hello Debian Python Team, > My py7zr-related Python packages are updated to fix some issues. > Please upload new packages to Debian because I don't have upload rights yet. > > * https://salsa.debian.org/python-team/packages/python-bcj > * https://salsa.debian.org/python-team/packages/python-brotlicffi > * https://salsa.debian.org/python-team/packages/python-inflate64 > * https://salsa.debian.org/python-team/packages/python-pyppmd I heard Andreas is busy now to upload my packages. So I want other one to sponsor me to upload my packages. -- YOKOTA Hiroshi
py7zr-related python packages was updated
Hello, My py7zr-related Python packages are updated to fix some issues. Please upload new packages to Debian because I don't have upload rights yet. * https://salsa.debian.org/python-team/packages/python-bcj * https://salsa.debian.org/python-team/packages/python-brotlicffi * https://salsa.debian.org/python-team/packages/python-inflate64 * https://salsa.debian.org/python-team/packages/python-pyppmd -- YOKOTA Hiroshi
