Streamlining the use of Salsa CI on team packages
Hello folks! I'd like to propose we start using Salsa CI for all the team packages. I think using a good CI for all our packages will help us find packaging bugs and fix errors before uploads :) I also think that when possible, we should be using the same CI jobs for our packages. The Salsa CI Team's default pipeline [1] is a good common ground, as currently it: * builds the package * runs piuparts * runs autopkgtest * runs lintian * runs reprotest * and does more! I don't think a failing CI should be a blocker for an upload, but I think it's a good red flag and should be taken in account. I know the Ruby team also decided to use debian/salsa-ci.yml instead of debian/gitlab-ci.yml [2]. I guess we should also do the same. Thoughts? If we decide to go ahead with this, I guess we should modify the policy accordingly and contact the Salsa Team to see if adding this additional load is OK with them. [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Re: Python 3 transition question
On 9/2/19 1:18 PM, Martin Kelly wrote: On 9/1/19 10:07 PM, Scott Kitterman wrote: On September 2, 2019 4:00:53 AM UTC, Sandro Tosi wrote: I would just stop building these. And if the reverse dependencies have a py2removal bug itself, then comment in these issues that the suggested/recommended package gets removed. If they don't have a py2removal bug, please file the bugs for these packages. i dont believe this is a sensible approach; for example i maintain python-mpmath, that would be rendered uninstallable the moment python-gmp2 is removed. Now, python-mpmath has 3 external reverse-dependencies (just to name a couple, sagemath and simpy) that would be then uninstallable, and so on and so forth for all their rdeps. Martin, i think for now the only option is to keep the py2 packages around until we're ready to drop them (ie they have 0 rdeps). I just checked on packages.d.o and according to it, python-gmp2 is a Suggests. Suggests aren't installed with packages. Unless I'm missing something, python-mpmath wouldn't become uninstallable. IIRC, policy doesn't even require Suggests packages to exist. I agree about keeping packages as long as they have reverse Recommends, but I think Suggests is going too far (although AIUI, missing Recommends don't make the package uninstallable either). Scott K If I'm summarizing correctly, it sounds like there is no policy on exactly what to do here. I think removing the package would be pretty bad, because gmpy is designed to speed up numerical libraries, and the performance hit without it would make many libraries really painful to use. Given this, perhaps the dependencies should be Recommends instead of Suggests. The guidelines I saw in the bugs filed on my packages (e.g. bug #937791) say to "document" the reverse dependency. Where do I document this? (ping). I'd like to resolve the bugs I have on my packages and am not sure yet how best to proceed.
Re: Bug#938836: xapian-bindings: Python2 removal in sid/bullseye
On Wed, Sep 04, 2019 at 11:43:10AM +0200, Matthias Klose wrote: > > popcon is 15747. > > I think that's too easy. There is a python3-xapian module which can be used > by the rdeps. The py2keep tag isn't meant for "I don't care to investigate" > issues. I was merely following the instructions you gave: | If the package has still many users (popcon >= 300), or is needed to | build another package which cannot be removed, document that by | adding the "py2keep" user tag > So the preference still would be to get the other packages ported or > removed, if possible. Sure, happy to drop it once nothing's using it. Cheers, Olly
pybuild mysteriously does not copy all files
Hi, I am not sure whether this is a bug in dh-python or if something is wrong with my package (python-asdf). The package has an (almost) standard setup, so dh_build is not overridden. However, when I try to package, some subdirectories are not copied; namely `asdf/external`: 8<-- dh_auto_build -O--buildsystem=pybuild I: pybuild base:217: /usr/bin/python3 setup.py build running build running build_py creating /build/python-asdf-2.4.2/.pybuild/cpython3_3.7_asdf/build/asdf [...] 8<-- The subdir `asdf/external` which is in the source is not created and not filled during this process. However, when I run `python3 setup.py build` or `pybuild --build` manually, everything is correct: 8<-- $ python3 setup.py build -vvv running build running build_py creating build creating build/lib creating build/lib/asdf copying asdf/yamlutil.py -> build/lib/asdf [...] creating build/lib/asdf/extern copying asdf/extern/RangeHTTPServer.py -> build/lib/asdf/extern copying asdf/extern/__init__.py -> build/lib/asdf/extern copying asdf/extern/atomicfile.py -> build/lib/asdf/extern copying asdf/extern/decorators.py -> build/lib/asdf/extern [...] 8<-- Is there any idea what happens here? Why does pybuild (or setup.py) behave differently when called from dh_python than directly? How can I ensure that all files are copied during dh_auto_build? Best regards Ole
