Re: python-opentracing
Dmitry Shachnev writes: > That happens because you are overriding dh_installdocs and running it only > for one package. > > Either remove the -ppython-opentracing-doc argument, or add another call > with --remaining-packages option. Thanks a lot, this has unblocked me. I'll continue working on it now... -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#943496: RM: python-adns -- RoM; ancient; dead upstream; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-python@lists.debian.org Usertags: py2removal https://pypi.org/project/adns-python/ no new releases since 2007. Popcon 544, because of transmission-remote-cli which was recently removed from the archive. Reverse deps checked with dak rm -Rnb python-adns -- WBR, wRAR signature.asc Description: PGP signature
Re: Discussing next steps for the Python2 removal
Hi, pá 25. 10. 2019 v 9:09 odesílatel Rebecca N. Palmer napsal: > Not the whole source package, but we do want to remove the py2 binary. > Maybe there should be two versions of the email, with the one for py2/3 > packages saying 'NMU' instead of 'removal'? > this is not how autorm works. You can't remove from testing only one of two binary package from same source package. You are removing package as a whole. But maintainer can anytime fix that bug by removing py2 binary from source package, which is few minutes work. -- Best regards Ondřej Nový
Re: Discussing next steps for the Python2 removal
Hi, pá 25. 10. 2019 v 3:30 odesílatel Sandro Tosi napsal: > do we really want to remove from testing (and subsequently from > debian, as mentioned below) if it both has a py2 and a py3k package? > should we limit this to py2-ONLY packages? > yes and no. If maintainer wants to keep package in Debian, fix is simple: Just remove one binary package. If nobody cares (no team upload, no NMU) we want to move forward and remove that package. > * bug is not marked as py2keep > > * all modules and low popcon apps (< 300) > > JFYI for now i was steering clear of removing py2 support even of > modules with high popcon (while it's true they may not have any rdeps > in the archive, there could be plenty of 3rd party code using them). > we want to remove Python 2 in bullseye ideally. So no 3rd party code will be using them, because there will be no Py2 :) > is there any plan to make some of this tags an upload-rejecting one? > maybe later? -- Best regards Ondřej Nový
Re: Discussing next steps for the Python2 removal
Sandro Tosi wrote: do we really want to remove from testing (and subsequently from debian, as mentioned below) if it both has a py2 and a py3k package? should we limit this to py2-ONLY packages? Not the whole source package, but we do want to remove the py2 binary. Maybe there should be two versions of the email, with the one for py2/3 packages saying 'NMU' instead of 'removal'?
