Newcomers project: DPMT/PAPT git repos verification
Hello, i would like to propose a project to make sure our teams (DPMT/PAPT) repos are being used correctly; it has a broader set of requirements than the pristine-tar one (and so it's more complex), thus a separate message. The checks i have in mind for now, are: * packages in DPMT/PAPT need to have a repo in our teams, if not -> move them in our salsa team if somewhere else or remove DPMT/PAPT from M/U * packages no longer in our team (moved, orphaned, etc) needs to get their repo removed from our team * is the repo up-to-date with the archive? f.e. is the version in unstable the latest one released from this repo? * does the repo contain all the versions uploaded to the archive? * are tags up to date with the package releases? * is the content of debian/gbp.conf against our policies? * bonus point: make this into a service that runs regularly (not strictly necessary to be limited to us) i guess we should have a brief discussion about additional checks and/or procedures before "assigning" it to a volunteer. let's say up to 2 weeks of discussion, and during the same period volunteers can nominate themselves. I marked this project as newcomers as it doesn't require to be a DD/DM to work on it, you just need a salsa account and access to our teams. a handy tool to retrieve all our repos is at https://salsa.debian.org/python-team/tools/python-modules https://salsa.debian.org/python-team/tools/python-apps that contains a config file for `mr` and a `checkout` script to fetch the repos registered in that config file. Please feel free to discuss this project now :) Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Newcomers project: DPMT/PAPT pristine-tar verification
Hello, i would like to propose a project to make sure our teams (DPMT/PAPT) repos are using pristine-tar properly. The checks i have in mind for now, are: * pristine-tar branch must exist, if not -> it's a bug * pristine-tar + upstream branch must produce the same tarball as downloaded from the archive, if not -> it's a bug * bonus point: fix the repo if it doesn't generate the right tarball and or the branch is missing. * bonus point: make this into a service that runs regularly (not strictly necessary to be limited to us) i guess we should have a brief discussion about additional checks and/or procedures before "assigning" it to a volunteer. let's say up to 2 weeks of discussion, and during the same period volunteers can nominate themselves. I marked this project as newcomers as it doesn't require to be a DD/DM to work on it, you just need a salsa account and access to our teams. a handy tool to retrieve all our repos is at https://salsa.debian.org/python-team/tools/python-modules https://salsa.debian.org/python-team/tools/python-apps that contains a config file for `mr` and a `checkout` script to fetch the repos registered in that config file. Please feel free to discuss this project now :) Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
mercurial switch to python3 in debian unstable - July 16th, 2020
Hello, this email is to inform the maintainers of the reverse dependencies of mercurial of the plan to upload to unstable the python3 version next Thursday. We want to be extra-safe with the switch, hence this email. In To: to this email the maintainers mailing list + key other MLs and addresses, in Bcc: the real people listed in Maintainer/Uploaders of the involved packages, apologies if you received more than 1 copy of it. The full list of the packages, as produced by dak, is available at the bottom of this email. There has been a test rebuilt, via ratt, as part of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937009#142 and it doesnt look like there's any failure in the build process due to the switch (except for meson, which indirectly build-depends on python2 without listing it). Mercurial is also used as part of the normal operation of a program, and that cannot be tested automatically, nor via a rebuild. The python3 version of mercurial is available in experimental (5.4.1-1+exp1); if you could test it against your package to make sure it works as you intended, that would help the transition. Mercurial has an extensive test suite, which passes 100% with python3, so we dont expect any failure while using the `mercurial` command, but some interfaces/operations may have changed. If we dont hear otherwise, we plan to upload the python3 version of mercurial in unstable on or around next Thursday, July 16th. This effort will greatly benefit the broader effort of py2removal, by allowing the chain removal of several other packages. Regards, Sandro $ dak rm -Rn mercurial Will remove the following packages from unstable: mercurial |5.4.1-1 | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x mercurial-common |5.4.1-1 | all Maintainer: Python Applications Packaging Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: git-remote-hg: git-remote-hg hg-git: mercurial-git hgsubversion: hgsubversion mercurial-buildpackage: mercurial-buildpackage mercurial-crecord: mercurial-crecord mercurial-extension-utils: mercurial-extension-utils mercurial-keyring: mercurial-keyring python-hgapi: python3-hgapi python-hglib: python3-hglib sphinx-patchqueue: python-sphinx-patchqueue # Broken Build-Depends: check-manifest: mercurial composer: mercurial devpi-common: mercurial git-remote-hg: mercurial golang-github-masterminds-vcs-dev: mercurial haskell-filestore: mercurial hg-git: mercurial (>= 4.8~) hgsubversion: mercurial (>= 5.2-1~) jags: mercurial meson: mercurial pepper: mercurial python-hgapi: mercurial python-hglib: mercurial (>= 1.9) reposurgeon: mercurial ros-rosinstall: mercurial ros-vcstools: mercurial ros-wstool: mercurial setuptools-scm: mercurial Dependency problem found.
Re: Bug#962574: ITP: dephell -- project management for Python
Hi Scott, devel, and Python team, Nicholas D Steeves writes: > Control: block -1 by 962574 > > Tomlkit seems to be required for self-tests. > Thank you for taking care of tomlkit so quickly! I wish I had more time and energy to make faster progress with DepHell. Today I discovered it appears to require packaging 14 dephell-.* modules, listed here: https://pypi.org/search/?q=dephell so it's going to be a while (months) before I complete this ITP (which blocks my solution for converting pyproject.toml to setup.py for fissix and thus Bowler). If anyone would like to help out with the dephell-.* dependencies to speed this process along, please go ahead, and let me know if you'd like a comaintainer/second Uploader. Failing that, I'll get to it as soon as I can :-) Best, Nicholas signature.asc Description: PGP signature
Joining the DPMT
Hello, I was in the DPMT back when it was on Alioth and I would like to join it again to backport python-flasgger and help with other packages as the need arises. My Salsa login is "federico". I have read the policy and I accept it: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thank you! -- Federico
Re: Is it time to remove python-numpy from testing?
Hi On 09-07-2020 21:16, peter green wrote: > All of the reverse dependencies of python-numpy have already been > removed from testing. So IMO > it makes sense to remove python-numpy from testing at this point, do > other people agree? I think it makes sense, so I added a removal hint. Paul signature.asc Description: OpenPGP digital signature
Re: Is it time to remove python-numpy from testing?
Hi, čt 9. 7. 2020 v 21:25 odesílatel peter green napsal: > python-numpy* is no longer buildable in testing due to the removal of the > "cython" binary package. > The maintainer has requested removal of python-numpy from unstable but the > ftpmasters have not yet > actioned it, presumably because there are still reverse-dependencies in > unstable. A rc bug is > present but will not cause autoremoval because python-numpy is on the "key > packages" list. > > All of the reverse dependencies of python-numpy have already been removed > from testing. So IMO > it makes sense to remove python-numpy from testing at this point, do other > people agree? > if all reverse dependencies of python-numpy were already removed from testing and we are not going to reintroduce python-numpy into testing I think it's good idea to remove python-numpy from "key packages" list and thus allow autoremoval. -- Best regards Ondřej Nový
Re: The python command in Debian
Hi, čt 9. 7. 2020 v 15:27 odesílatel Matthias Klose napsal: > Describing here a solution which is implemented for Ubuntu focal (20.04 > LTS). A > new source package what-is-python (-perl-dont-hurt-me) ships binary > packages > python-is-python2, python-dev-is-python2, python-is-python3 and > python-dev-is-python3. The python-is-python2 package provides the python > package, such that packages that still depend on python are not removed on > a > distro upgrade. On new installs, python-is-python3 is not installed by > default, > but the user gets a hint from command-not-found to install the package if > he > tries to run python. Package dependencies on the new four binary packages > have > to be disallowed in the Python policy. Note that such a package including > the > Provides should only be uploaded once all dependencies on the unversioned > python > packages are gone. > I like this solution in Ubuntu and I have: onovy@jupiter:~$ dpkg -l | grep python-is-python3 ii python-is-python3 3.8.2-4 all symlinks /usr/bin/python to python3 What I think is good idea: * keep "python" command pointing to python2.7 if I'm upgrading buster->bullseye with python2.7 installed. We are going to keep python2.7 interpreter for bullseye, so don't break old "python" command for third-parties apps/scripts/etc. (install python-is-python2 during buster->bullseye upgrade) * allow users to choose if they want python=python3 (apt install python-is-python3) * (maybe?) python=python3 in new installs, because why not? (install python-is-python3 by default in clean install) -- Best regards Ondřej Nový
Is it time to remove python-numpy from testing?
python-numpy* is no longer buildable in testing due to the removal of the "cython" binary package. The maintainer has requested removal of python-numpy from unstable but the ftpmasters have not yet actioned it, presumably because there are still reverse-dependencies in unstable. A rc bug is present but will not cause autoremoval because python-numpy is on the "key packages" list. All of the reverse dependencies of python-numpy have already been removed from testing. So IMO it makes sense to remove python-numpy from testing at this point, do other people agree? * Note: since buster the python-numpy source package only builds python 2 related binary packages, the python3 numpy binary packages are now built from the numpy source package.
Re: The python command in Debian
On Thu, Jul 09, 2020 at 04:55:33PM +, Jeremy Stanley wrote: > I don't follow your logic there. Why is it hard to explain? Python > was a programming language, and its last interpreter (2.7) is no > longer developed or supported. Python3 (formerly Python3000) is also > a programming language, similar to Python and developed by the same > community, but not directly compatible with Python. Debian provides > an interpreter for Python3, but has (or will have by then) ceased > distributing a Python interpreter. counterpoint: It is normal and expected to have `python` be the same as `python3` in a virtualenv, the idiomatic way to maintain the Python environment. I love the idea of eventually migrating `$(which python)` to be Python 3 as soon as that doesn't induce nasty breakage -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 `- http://people.debian.org/~paultag signature.asc Description: PGP signature
Re: The python command in Debian
On 2020-07-09 15:26:47 +0200 (+0200), Matthias Klose wrote: > As written in [1], bullseye will not see unversioned python > packages and the unversioned python command being built from the > python-defaults package. > > It seems to be a little bit more controversial what should happen > to the python command in the long term. Some people argue that > python should never point to python3, because it's incompatible, > however Debian will have difficulties to explain that decision to > users who start with Python3 and are not aware of the 2 to 3 > transition. So yes, in the long term, Debian should have a python > command again. [...] I don't follow your logic there. Why is it hard to explain? Python was a programming language, and its last interpreter (2.7) is no longer developed or supported. Python3 (formerly Python3000) is also a programming language, similar to Python and developed by the same community, but not directly compatible with Python. Debian provides an interpreter for Python3, but has (or will have by then) ceased distributing a Python interpreter. -- Jeremy Stanley signature.asc Description: PGP signature
The python command in Debian
As written in [1], bullseye will not see unversioned python packages and the unversioned python command being built from the python-defaults package. It seems to be a little bit more controversial what should happen to the python command in the long term. Some people argue that python should never point to python3, because it's incompatible, however Debian will have difficulties to explain that decision to users who start with Python3 and are not aware of the 2 to 3 transition. So yes, in the long term, Debian should have a python command again. One solution could be not to ship the python command in bullseye, forcing users to adjust their local installations. This has the advantage that the error of an unknown interpreter should be pretty clear. But leaves users without a python command for the next two years until bullseye+1. Describing here a solution which is implemented for Ubuntu focal (20.04 LTS). A new source package what-is-python (-perl-dont-hurt-me) ships binary packages python-is-python2, python-dev-is-python2, python-is-python3 and python-dev-is-python3. The python-is-python2 package provides the python package, such that packages that still depend on python are not removed on a distro upgrade. On new installs, python-is-python3 is not installed by default, but the user gets a hint from command-not-found to install the package if he tries to run python. Package dependencies on the new four binary packages have to be disallowed in the Python policy. Note that such a package including the Provides should only be uploaded once all dependencies on the unversioned python packages are gone. Matthias [1] https://lists.debian.org/debian-python/2020/07/msg00039.html [2] https://launchpad.net/ubuntu/+source/what-is-python
Re: Python2 packages for bullseye
On 7/9/20 1:45 PM, Scott Kitterman wrote: > On Thursday, July 9, 2020 7:21:45 AM EDT Matthias Klose wrote: >> The removal of packages still depending on Python2 looks good [1], however >> we have a bunch of packages that still require Python2, and where >> maintainers explicitly asked to keep those in the distro [2]. Among those >> are pypy and pypy3 which need Python2 for bootstrapping. I'm going to keep >> the Python2 packages for bullseye, and having those just as build >> dependencies shouldn't really effect any end-user. A different thing might >> be the Python2 usage at runtime, however I'm not very passionate to remove >> all of those packages. >> >> What still should be done for bullseye is the removal of the unversioned >> python. I'm removing the packages python-minimal, python, python-dev, >> python-dbg, python-doc, and stop shipping the /usr/bin/python symlink, so >> that packages are required to either use python2 or python3 explicitly. >> Planning that change for late August / early September. That should give >> plenty of time to address any unversioned python usage before the release >> freeze. > > Are you going to keep python-setuptools? If you do, it seems likely we'll be > able to keep pip and virtualenv so they support running python2 in a > virtualenv in bullseye, which seems the best way to do it for those that need > to. yes, that would be a sensible thing to do.
Re: Python2 packages for bullseye
On Thursday, July 9, 2020 7:21:45 AM EDT Matthias Klose wrote: > The removal of packages still depending on Python2 looks good [1], however > we have a bunch of packages that still require Python2, and where > maintainers explicitly asked to keep those in the distro [2]. Among those > are pypy and pypy3 which need Python2 for bootstrapping. I'm going to keep > the Python2 packages for bullseye, and having those just as build > dependencies shouldn't really effect any end-user. A different thing might > be the Python2 usage at runtime, however I'm not very passionate to remove > all of those packages. > > What still should be done for bullseye is the removal of the unversioned > python. I'm removing the packages python-minimal, python, python-dev, > python-dbg, python-doc, and stop shipping the /usr/bin/python symlink, so > that packages are required to either use python2 or python3 explicitly. > Planning that change for late August / early September. That should give > plenty of time to address any unversioned python usage before the release > freeze. Are you going to keep python-setuptools? If you do, it seems likely we'll be able to keep pip and virtualenv so they support running python2 in a virtualenv in bullseye, which seems the best way to do it for those that need to. Scott K signature.asc Description: This is a digitally signed message part.
Python2 packages for bullseye
The removal of packages still depending on Python2 looks good [1], however we have a bunch of packages that still require Python2, and where maintainers explicitly asked to keep those in the distro [2]. Among those are pypy and pypy3 which need Python2 for bootstrapping. I'm going to keep the Python2 packages for bullseye, and having those just as build dependencies shouldn't really effect any end-user. A different thing might be the Python2 usage at runtime, however I'm not very passionate to remove all of those packages. What still should be done for bullseye is the removal of the unversioned python. I'm removing the packages python-minimal, python, python-dev, python-dbg, python-doc, and stop shipping the /usr/bin/python symlink, so that packages are required to either use python2 or python3 explicitly. Planning that change for late August / early September. That should give plenty of time to address any unversioned python usage before the release freeze. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-python@lists.debian.org [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2keep;users=debian-python@lists.debian.org
