Re: Discussing next steps for the Python2 removal
> i have a semi-working script that produced ~400 package depending on > py2 packages with missing py2removal bugs, i'll try to finalize it in > the coming days and submit those bugs when done here's the list: https://people.debian.org/~morph/mass-bug-py2removal_take2.txt in format all of these sources didnt not have a py2removal filed against them (and i'm not even checking if there are sources that still depends on py2 packages but had their py2removal bugs closed, it may be a further enhancement). I'm gonna file bugs soon -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: dh-python now generates dependencies on python2 instead of python
> The py2removal bugs have a section > > """ > - 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 (not replacing the py2remove tag), >using the debian-python@lists.debian.org user. Also any >dependencies on an unversioned python package (python, python-dev) >must not be used, same with the python shebang. These have to be >replaced by python2/python2.7 dependencies and shebang. > """ i think the bug text should have been a lot simpler, and mostly just be a small introduction of the problem and refer to the wiki page for further details, so that we can keep the wiki up to date even if we change the plans (as we cannot edit the bug text) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
dh-python now generates dependencies on python2 instead of python
For Python2 packages, dh-python 4.20191017 now rewrites any python shebang to /usr/bin/python2 and generates dependencies on python2 instead of python. The py2removal bugs have a section """ - 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 (not replacing the py2remove tag), using the debian-python@lists.debian.org user. Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. """ As seen with the recent python-crypto upload, the package now has no dependency on python anymore in the binary packages, and it doesn't have any python, python-dev build-dependencies anymore. Also seen in python-crypto, the python2 autopkg test calls python, and fails because python is not a dependency of python-crypto anymore. This needs fixing. If we need to ship Python2 in bullseye, then the python, python-dev, python-dbg, python-doc, libpython-stdlib, libpython-dev binary packages will be removed before the release. With that change, python-crypto is in a form to ship with bullseye (if python-crypto is still needed for some application that we want to keep). Application packages are likely to need a change in the build dependencies to ship with bullseye, if needed.
Re: Discussing next steps for the Python2 removal
Dear all, On 22-10-2019 17:04, Matthias Klose wrote: > He suggested to make the removal plan more > concrete and having a timeline. To be more precise on what I meant, I'm talking here about *every* package that wants to drop a Python 2 binary package, discuss (and ideally agree on, but I understand that that can be hard) the time line with their reverse dependencies. If this is done globally, fine, but please, give reverse dependencies time to adapt. I'm already seeing quite some annoyance on the fact that in several cases the ground is pulled away under one's package. Yes, there's a bug in britney somewhere that allows the migration, we're trying to find it. Paul For those that are curious, the britney output [1] shows at the end binary packages in testing that are not build from source anymore but are left in testing due to dependencies. Those that aren't in libs/oldlibs shouldn't be there and are make their reverse dependencies RC buggy. On top of that, Dose [2] shows packages that can't be build from source in testing. There's quite some python2 packages listing as causing that. Again, all those packages are RC buggy (often the bug hasn't been filed yet). [1] https://release.debian.org/britney/update_output.txt.gz [2] https://qa.debian.org/dose/debcheck/src_testing_main/ (pick the latest amd64 log, it should be empty except for cmucl) signature.asc Description: OpenPGP digital signature
Re: Discussing next steps for the Python2 removal
On Tue, Oct 22, 2019 at 11:05 AM Matthias Klose wrote: > > Paul Gevers from the release team pointed out that the Python2 removal is > causing some uninstall-ability issues in testing because some packages > apparently are removed too early, but never the less are migrating to testing. in a hope to help preventing this from happening, i've extend the script that generates the webpage to also send control@ mails to mark what bugs are blocked by others, and it went live yesterday evening. i have a semi-working script that produced ~400 package depending on py2 packages with missing py2removal bugs, i'll try to finalize it in the coming days and submit those bugs when done Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Discussing next steps for the Python2 removal
Paul Gevers from the release team pointed out that the Python2 removal is causing some uninstall-ability issues in testing because some packages apparently are removed too early, but never the less are migrating to testing. He suggested to make the removal plan more concrete and having a timeline. So maybe people interested in joining the discussion and wanting to help could come to #debian-python on this Thu, Oct 24, 18:00 UTC. If needed, with a follow-up on Sat, Oct 27, 18:00 UTC. Topics could be: - filing removal bugs for packages which don't have a bug report yet. - when to raise bug severity for which bugs, even now for leaf packages? - bumping lintian info to warn, warn to error, ask ftp-master to autoreject packages for some errors? If you cannot join, please leave some comments in the "Discussions/Proposals" section at https://wiki.debian.org/Python/2Removal
Re: [packaging] wurlitzer
On 2019-10-21 18:00, Dmitry Shachnev wrote: > A downside of this debian/watch is that it only sees the latest tarball, > but not the historic releases. > > I think using one of these two pages will be better: > > - https://pypi.org/simple/wurlitzer/ > - https://pypi.debian.net/wurlitzer/ Right, these addresses should be used instead. I wasn't aware of that, thanks for pointing out. Best, Andrius
[Request]
Hello, I woud like to join debian-python team in order to maintain and package a bunch of modules : - wurlitzer - jupyter_sphinx Wich are dependecies of scientific softwares. My username is : alexandre.marie-guest. I read the python policy [0] and I accept it. Thanks, Alexandre Marie [0] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
