Status of https://debian-python.readthedocs.io/en/latest/

[Sandro Tosi]

Hello,
it looks like Barry (correct me if i'm wrong) set up
https://debian-python.readthedocs.io/en/latest/ but it has not been
updated in a while.

Do we know what's the status of this website, if we want to continue
to maintain it, or instead we should just consolidate onto
https://www.debian.org/doc/packaging-manuals/python-policy/ ?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#977936: ITP: python-multipart -- streaming multipart parser for Python

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: python-multipart
  Version : 0.0.5
  Upstream Author : Andrew Dunham <>
* URL : http://github.com/andrew-d/python-multipart
* License : Apache
  Programming Lang: Python
  Description : streaming multipart parser for Python

Binary package names: python3-python-multipart

this is a dependency for fastapi (and its tests)

Re: Joining the team

[Sandro Tosi]

On Mon, Nov 23, 2020 at 6:50 PM Thomas Goirand  wrote:
>
> On 11/23/20 10:10 PM, Sandro Tosi wrote:
> >>> First, an apology: it seems I misremembered being in the team, and 
> >>> uploaded to
> >>> NEW a bunch of packages with the team in `Uploaders`.
> >>
> >> Please put the team as Maintainer, and yourself as Uploaders.
> >
> > why? that's not a requirement:
> > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership
>
> Because joining a team, putting packages in them, and enforcing strong
> ownership, is not logic at all.

that's your opinion, and the policy disagrees with you. this team
welcomes everyone that is willing to follow our policies and its
rules.

> I know you like to do this way, but this
> shouldn't be what we advise for new comers.

that's also what nicoo prefers, given he chose exactly that way for
maintaining his packages.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Joining the team

[Sandro Tosi]

> > First, an apology: it seems I misremembered being in the team, and uploaded 
> > to
> > NEW a bunch of packages with the team in `Uploaders`.
>
> Please put the team as Maintainer, and yourself as Uploaders.

why? that's not a requirement:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-modules-team] Bug#954381: marked as done (python3-kubernetes: New upstream version available)

[Sandro Tosi]

>* Use git to generate upstream tarball, as the PyPi module doesn't include
>  the test folder. Using the gen-orig-xz in debian/rules, as using the
>  repack function of debian/watch doesn't make sense (why downloading a
>  tarball that would be later on discarded? I'm open to a better solution
>  which would be uscan compatible though...). Switch d/watch to the github
>  tag therefore.

you can track the github project instead of pypi (man uscan has the
details); this is was i'm doing recently, as most of the time PyPI
releases dont have all the files we need (tests, or test data, or
documentation, or a combination of that)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Looking for information about the Python Team

[Sandro Tosi]

> I'm looking for information about the work done by the Python Team for a
> talk to encourage the Cuban python community to collaborate in Debian.

why do you want to encourage people to contribute to a team you're not
part of, to which you never contributed to (at least that i could
quickly find), and of which you virtually know nothing about?

> Where can I find information about:
> - When the Python Team was created
> - Number of active members (approximately)
> - Number of packages under the responsibility of Python Team (approximately)
> - Requirements to be a member of the Python Team
> - Any other information of interest

you can start from ttps://wiki.debian.org/Python

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Newcomers project: DPMT/PAPT pristine-tar verification

[Sandro Tosi]

attached the dd-list of the packages missing the pristine-tar branch (some
may have been moved/removed, but these are actual repos in DPT)

On Fri, Jul 10, 2020 at 12:38 AM Sandro Tosi  wrote:

> 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
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Alastair McKinstry 
   fparser
   jpy (U)
   usagestats

Ana Custura 
   python-offtrac

Andrej Shadura 
   pydenticon (U)
   pyrsistent (U)
   pyte
   python-ewmh (U)
   python-h2 (U)
   python-libguess (U)
   python-minimock (U)
   python-phonenumbers (U)
   python-urlobject (U)
   txacme (U)
   txsni (U)
   waitress (U)

Andrej Shadura 
   gtimelog (U)

Andrew Shadura 
   python-wheezy.template (U)

Antoine Beaupré 
   pymeeus (U)
   python-internetarchive
   python-spake2

Balasankar C 
   vim-autopep8

Bastian Venthur 
   pipenv (U)

Benjamin Drung 
   pyrundeck (U)

Brian May 
   factory-boy (U)

Corey Bryant 
   python-requests-mock (U)

Daniel Kahn Gillmor 
   py-postgresql (U)
   python-xdo (U)

David da Silva Polverari 
   pem

Debian OpenStack 
   python-etcd3
   python-requests-mock
   python-sphinxcontrib.apidoc

Debian Python Apps Team 
   s3ql (U)

Debian Python Modules Team 
   aiowsgi
   autopep8 (U)
   black
   codespell
   derpconf
   django-session-security
   django-stronghold
   factory-boy
   fail2ban
   flask-assets
   flask-caching
   jpy
   milksnake
   netifaces
   patiencediff
   pikepdf
   power
   pydenticon
   pydle
   pykwalify
   pymeeus
   pyrsistent
   python-altair
   python-distutils-extra
   python-ewmh
   python-h2
   python-injector
   python-libguess
   python-lz4 (U)
   python-lzo
   python-minimock
   python-offtrac (U)
   python-pathtools
   python-pcl
   python-phonenumbers
   python-plaster
   python-plaster-pastedeploy
   python-requests-ntlm
   python-urlobject
   python-wheezy.template
   python-xdo
   sireader (U)
   stardicter
   subvertpy
   txacme
   txsni
   vim-autopep8 (U)
   waitress
   wsgiproxy2

Debian Python Modules Team 
   aiohttp-wsgi
   gevent-websocket
   py-postgresql

Debian Python Team 
   black
   pyrundeck

Denis Danilov 
   fortran-language-server (U)

Dmitry Smirnov 
   python-lz4
   python-lzo (U)

Federico Ceratto 
   django-stronghold (U)

Gaudenz Steinlin 
   sireader

Georg Faerber 
   codespell (U)

Gilles Dubuc 
   derpconf (U)

gustavo panizzo 
   python-pathtools (U)

Harlan Lieberman-Berg 
   python-requests-ntlm (U)

Jean-Michel Vourgère 
   django-session-security (U)

Jelmer Vernooij 
   aiowsgi (U)
   flask-assets (U)
   flask-caching (U)
   milksnake (U)
   patiencediff (U)
   pydle (U)
   subvertpy (U)
   wsgiproxy2 (U)

Jochen Sprickerhof 
   python-pcl (U)

Johan Fleury 
   pykwalify (U)

Johannes Tiefenbacher 
   discodos (U)

Jonathan Carter 
   feed2toot
   flask-caching (U)
   power (U)
   s-tui
   toot

Marcelo Jorge Vieira 
   derpconf (U)
   yanc

Mario Izquierdo (mariodebian) 
   netifaces (U)

Martin Pitt 
   python-distutils-extra (U)

Martin Wimpress 
   python-injector (U)

Maximiliano Curia 
   python-intbitset

Mehdi Abaakouk 
   python-lzo (U)

Michal Čihař 
   stardicter (U)

Mike Gabriel 
   python-injector (U)

Neil Williams 
   black (U)

Nicolas Dandrimont 
   python-plaster (U)
   python-plaster-pastedeploy (U)

Nikolaus Rath 
   s3ql

Peter Spiess-Knafl 
   codespell (U)

Python Applications Pack

Re: What is the new maintainer address for Python team?

[Sandro Tosi]

> New/correct address is:
> Maintainer: Debian Python Team 

Was this discussed somewhere? i cant find references in the ml -- thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: can we disable the bounce kicker? Re: confirm

[Sandro Tosi]

To these days, this is still happening! can we finally get rid of
this? Piotr, it looks like you're the admin of the mailing list, can
you take care of it please? thanks!

On Mon, Jun 11, 2018 at 5:44 AM Ondrej Novy  wrote:
>
> Hi,
>
> 2018-06-10 1:35 GMT+02:00 Sandro Tosi :
>>
>> this is still happening, and it looks like more frequently than before
>> - can we please disable this option once and for all?
>
>
> +1. Please.
>
>>
>>
>> On Sat, Sep 10, 2016 at 9:46 AM Sandro Tosi  wrote:
>> > I'm sure i'm not the only member using gmail, which bounces spam
>
>
> me too.
>
> --
> Best regards
>  Ondřej Nový
>
> Email: n...@ondrej.org
> PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable

[Sandro Tosi]

argggh removed the wrong address, adding Nick

On Fri, Jul 31, 2020 at 1:27 PM Sandro Tosi  wrote:
>
> >* d/control:
> >  - Mark package python3-uflash-doc as M-A: foreign
>
> This -doc package doesnt follow the policy, of having a python- prefix
> and not a python3- prefix -- please fix

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable

[Sandro Tosi]

>* d/control:
>  - Mark package python3-uflash-doc as M-A: foreign

This -doc package doesnt follow the policy, of having a python- prefix
and not a python3- prefix -- please fix

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Granting `Janitor` direct access to our teams repos

[Sandro Tosi]

Hello,
I don't know the technicalities required to do that (nor i have
permissions to do it myself anyway), but I'm wondering if we should
grant direct access to our repos to the Janitor user.

I don't think any of us checks those PRs in depth, and most of the
time Jelmer comes in and bulk-merges them straight away (no complaints
on that).

So: let's just make that automatic? Thoughts?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Newcomers project: DPMT/PAPT pristine-tar verification

[Sandro Tosi]

On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog  wrote:
>
> Hi,
>
> On Fri, 10 Jul 2020, Sandro Tosi wrote:
> > 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 would suggest that this would be a nice job for the janitor bot.
> https://janitor.debian.net/

How would you suggest implementing this?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: RFH: Problemas with test process on python-jsonrpc-server

[Sandro Tosi]

did you run the -v option, as suggested by the error? it may lead to
what the problem is

On Sat, Jul 18, 2020 at 7:03 PM Pablo Mestre  wrote:
>
> Hi,
>
> Im trying to packages python-jsonrpc-server to solve the dependencies
> for upgrade Python IDE Spyder.
>
> I get this issue with the test process and I dont find any solution at
> the moment:
>
> https://github.com/palantir/python-jsonrpc-server/issues/43
>
> The problem is only with python version 3.8
>
> Any idea how i can solve this issue
>
> The salsa repo is
> https://salsa.debian.org/elMor3no-guest/python-jsonrpc-server
>
> Thanks in advance
>
> Pablo
>
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Request to join DPMT

[Sandro Tosi]

Luca,

> I have read and accept the policy.rst - if accepted, I will update the
> branch policy of my modules to match the policy (mainly
> s|debian/sid|debian/master|) and update the Maintainer field,
> everything else already matches.

In your request to join email, you agreed to accept and follow our
policy, and adapt your packages to it. sadly that did not happen: all
your packages lack both `upstream` and `pristine-tar` branches, and
they still have `debian/sid` as main branch (which would be fine, but
you said you'd change it).

Please rectify the situation.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: mercurial switch to python3 in debian unstable - July 16th, 2020

[Sandro Tosi]

> I guess a lot of things are unlocked now. I wonder how we can help
> fixing what's remaining.

I think i already took care of all the packages that got (recursively)
freed up by switching mercurial to python3.

> Please do share your thoughts on that.

I guess one can always look at
http://sandrotosi.me/debian/py2removal/index.html for some work
regarding the py2removal effort

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: mercurial switch to python3 in debian unstable - July 16th, 2020

[Sandro Tosi]

> If we dont hear otherwise, we plan to upload the python3 version of
> mercurial in unstable on or around next Thursday, July 16th.

mercurial/5.4.1-2 has just been uploaded to unstable, switching it to
use python3.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: The python command in Debian

[Sandro Tosi]

> 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.

can you explain this point? i think if a new developer starts with
python3 now (and i have plenty of examples at my company) they just
use `python3` on the commandline, shebangs, venv, etc. I dont see the
confusion we would create.

> So yes, in the long term, Debian should have a python command
> again.

I dont think that's the right decision. PEP 0394
(https://www.python.org/dev/peps/pep-0394/) allows distribution not to
ship `python` at all:

https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors

* If the python command is installed, it is expected to invoke either
the same version of Python as the python3 command or as the python2
command.
* Distributors may choose to set the behavior of the python command as follows:
** python2,
** python3,
** not provide python command,
** allow python to be configurable by an end user or a system administrator.

> One solution could be not to ship the python command in bullseye, forcing 
> users
> to adjust their local installations.

it is my opinion that that's what we should do: not ship `python` at
all and have users/packagers/developers use either python2 or python3
as needed, and not to reintroduce `python` at a later time.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00

[Sandro Tosi]

> src:dbus-python cannot drop its Python 2 support until all of the reverse
> dependencies of python-dbus have done so (or been removed from testing, but
> that's unlikely to happen while they include key packages like avahi,
> jackd2 and pyqt5).

this is now the case: bin:python-dbus has no more reverse dependencies
(that are not RC and/or being removed from testing), see dak output:

Checking reverse dependencies...
# Broken Depends:
dbus-python: python-dbus-dbg  **Internal deps
python-dbus-tests
ladish: ladish   ** removed from testing in May 2020
neard: neard-tools   ** removed from testing in Dec 2019
wicd: wicd-daemon   ** removed from testing in Oct 2019

So please proceed with drooping python-dbus as soon as possible.
Currently python-dbus is the sole rdep of python-gi, which then could
be dropped when python-dbus is gone.

Let me know if you need help with this activity: i'm available to NMU
or team upload src:dbus-python if that's preferred

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Request to join Python Modules Team

[Sandro Tosi]

>   Imaging you are the person that wants to join this cool project.
>   You made some effort to apply for membership and sent in the request.
>   Then you wait humblely. Humble as you are, you wait another day.
>   On third day you start wondering "Is asking again expressing
>   that you care or is it pushing the people you want to join?"

I did not see a single MR from all the people that requested to join
the team in recent times (and i'm subscribed to MR notifications for
both DPMT and PAPT), and i do know that you cannot submit an MR for
new packages.

Almost all those introductory mails mentioned "I want to maintain this
new package *AND* [emphasis added] help with general maintenance" but
those maintenance contributions never really came (neither before or
after membership was granted, at least not at the level a person that
cares so much would lead to expect).

If they really want to contribute they can always submit MRs or
patches to the bts, and/or prepare a NEW package in a temporary
location if access is still not granted; but that didnt really happen.

We dont really have a good process to accept new contributions (it
mostly boils down to single individuals to review, merge, upload), but
we also dont really that many to begin with.

Geert, I personally find your approach towards the current
members/admins pushy, so speaking exclusively for myself l I would
suggest you to be mindful that, while I may believe you're trying to
be helpful, you may come across differently than how you intended.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-modules-team] pychromecast_7.1.1-1_source.changes ACCEPTED into unstable

[Sandro Tosi]

Andrej, the pristine-tar branch has not been updated (not sure if you
didnt push it or it was not imported with the --pristine-tar option)


On Sat, Jul 11, 2020 at 1:04 PM Debian FTP Masters
 wrote:
>
>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Sat, 11 Jul 2020 18:45:04 +0200
> Source: pychromecast
> Architecture: source
> Version: 7.1.1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Modules Team 
> 
> Changed-By: Andrej Shadura 
> Changes:
>  pychromecast (7.1.1-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream release.
> Checksums-Sha1:
>  c890d7a377ea7484823065ac404870ec73d909c8 1897 pychromecast_7.1.1-1.dsc
>  0bce73ca78cfa25e585c28b56cc4cdd5b647f5ac 57075 pychromecast_7.1.1.orig.tar.gz
>  76f6076ac34b247501301e587018f392b48b0fb7 3516 
> pychromecast_7.1.1-1.debian.tar.xz
> Checksums-Sha256:
>  783fbdd898819cbccedece2f6055879c3b96005dfe0c0454cdf4f2261b4f9f9a 1897 
> pychromecast_7.1.1-1.dsc
>  e0113bca3323546b9affc0b9187afceb224682a4db66280017a469476b244631 57075 
> pychromecast_7.1.1.orig.tar.gz
>  2856c17018180eed9f7f5767c900100349a3cc7550b7785d3cecf59a7d49804a 3516 
> pychromecast_7.1.1-1.debian.tar.xz
> Files:
>  97c18b1be74e9b6d7c86cf605a51bb3b 1897 python optional 
> pychromecast_7.1.1-1.dsc
>  32726da37759a15deb4e199a31c6fb54 57075 python optional 
> pychromecast_7.1.1.orig.tar.gz
>  3b55122a623accf5d90d79724d0e22ad 3516 python optional 
> pychromecast_7.1.1-1.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl8J7NUACgkQXkCM2RzY
> OdLbCQf9HjNvz/dB4itbedQutgeeEEmgStSZdnWuqyiSP6tnd8qqu4wKRvDTEdZM
> AAseqradRlL3cZpnbLeUMkuffOvcZf+rxSh1H+rhfjWPkGn1+rE8mRdB5A+lOAtK
> MKlWiBs2VGuLrrF1phRkTIJxzBLdmBT1JGmfFWqTcEA66kOeCDtHAJJG4Y99lUMV
> I5nL6J2odl6sN4BDhrkyCd7or6yP4ahG+9SiACp+Fw8nhHk2v3728S+HUTOSsbxh
> 1boiiwEbt1T3MQ1MM0e+xMAGbL56EfTmpZsXwaBXjgFjQhSk/iH5j3F8pDNFEaVF
> /d/BM61VF43XFu00s25lF+cCP8Ypqw==
> =pYDM
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

--
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 git repos verification

[Sandro Tosi]

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

[Sandro Tosi]

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

[Sandro Tosi]

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: py2removal - make all leaf applications RC

[Sandro Tosi]

> I propose to raise the severity of all leaf applications in 3 days, if
> i dont hear any objections.

This is now enabled and at the next run (in ~50 minutes) it will take effect.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

py2removal - make all leaf applications RC

[Sandro Tosi]

Hello,
Currently only leaf applications (ie something that doesnt start with
`python-`) with popcon <= 1000 get their py2removal bug bumped to RC.

I propose to raise the severity of all leaf applications in 3 days, if
i dont hear any objections.

The current list of applications, and their popcon, impacted by this is:

gnumeric-plugins-extra, popcon = 1072
xchat, popcon = 1437
getmail, popcon = 1285
libapache2-mod-python, popcon = 3626
mysql-workbench, popcon = 1355

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

[Sandro Tosi]

> > > Do you need any help in coordinating with the packaged extensions,
> > > testing changes, preparing patches? a lot of time has passed since we
> > > started asking about mercurial and python3 and it is becoming the only
> > > reverse-dependency of several packages that could be removed if
> > > mercurial switched to py3k.
> > >
> > Getting an uptodate list of extensions and their status wrt porting both
> > upstream and in Debian would be useful.  I've spent some time looking at
> > hgsubversion a few weeks ago but there's a ton of work and I don't
> > actually use it so I've kind of given up on that; I forget what the
> > status is on others.
>
> will look into the rdeps of mercurial once 5.4.1-1+exp1 hits the archive

I've rebuilt all rdeps of mercurial against the python3 version
uploaded to unstable; results are:

2020/07/05 00:28:22 Build results:
2020/07/05 00:28:22 PASSED: salt
2020/07/05 00:28:22 PASSED: golang-github-masterminds-vcs-dev
2020/07/05 00:28:22 PASSED: pepper
2020/07/05 00:28:22 PASSED: python-hglib
2020/07/05 00:28:22 PASSED: git-remote-hg
2020/07/05 00:28:22 PASSED: haskell-filestore
2020/07/05 00:28:22 PASSED: composer
2020/07/05 00:28:22 PASSED: yotta
2020/07/05 00:28:22 PASSED: ros-rosinstall
2020/07/05 00:28:22 PASSED: check-manifest
2020/07/05 00:28:22 PASSED: jags
2020/07/05 00:28:22 PASSED: setuptools-scm
2020/07/05 00:28:22 PASSED: reposurgeon
2020/07/05 00:28:22 PASSED: devpi-common
2020/07/05 00:28:22 PASSED: firmware-microbit-micropython
2020/07/05 00:28:22 PASSED: python-hgapi
2020/07/05 00:28:22 PASSED: hgsubversion
2020/07/05 00:28:22 PASSED: ros-wstool
2020/07/05 00:28:22 PASSED: ros-vcstools
2020/07/05 00:28:22 FAILED: hg-git (see buildlogs/hg-git_0.8.12-1.2)
2020/07/05 00:28:22 FAILED: meson (see buildlogs/meson_0.54.3-1)

(build logs and artifacts are at
https://people.debian.org/~morph/mercurial_python3/ )

hg-git is RC and not in testing since mid-December, and meson is i
think a real error, since without mercurial depending on python2 now
the build fails to find that executable

Tbh, i think it's time to just rip the bandaid and upload mercurial
python3 to unstable, and deal with the consequences there (i volunteer
to do so); you mentioned hgsubversion as a potential blocker: that
package are popcon on 56, i dont believe such a minor package should
hold progress with the py2removal effort (I've added debian-python@ to
gather their input on this).

I do understand the rebuild results are not conclusive on the python3
migration (after all hgsubversion rebuilds fine with py3k mercurial,
which also raises the questions of why it b-d on it since it clearly
doesnt use it, but i'm digressing), but i think it's better to just go
ahead and upload the experimental version to unstable and see what's
the impact there

What do people think about this?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Maintaining all of the testing-cabal packages under the OpenStack team

[Sandro Tosi]

> Running the script shows that 279 reverse (build?) dependencies are
> affected by mock. This clearly isn't something one wants to run on a
> personal computer, and even less a test which one wants to run sequentially.
>
> Has any thought went into having some kind of runners running on a cloud
> to run these tests, and maybe plug this into Salsa's CI to run it
> automatically?
>
> I'd very much would love to set this up, at least as a first
> experimentation on a bunch of package of the DPMT.

i sent this some time ago do d-devel

https://lists.debian.org/debian-devel/2020/03/msg00342.html

it didnt get much traction

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Maintaining all of the testing-cabal packages under the OpenStack team

[Sandro Tosi]

> Is anyone from the team opposing to this?

Yes, i'm against your proposal.

> If so, please explain the
> drawbacks if the OpenStack team takes over.

1. you're personally attacking Ondrej, who is one of the very few
members of this team doing team-wide work, and that should be enough
to reject it
2. this is clearly an hostile take-over (even if you frame it as a
proposal), and that should be enough to reject it
3. you propose to only update those packages every 6 months, i dont
find it appropriate: OS is *just* another software we package for
Debian; is it complex? sure, but it's not special, and it doesnt
warrant any special treatment.
4. you clearly want to have sole and absolute control of the packages
in the openstack-team, because what would happen if a os-team member
will upgrade one of those packages (in good faith) and things will
break? will they get another "well done! :( " email from you?
4.1. You wonder why Ondrey "stopped caring" about OS, if that's the
case, i could see why
5. consolidating packages *into* the DPMT/PAPT gives a lot of
benefits, f.e. people basically got "free" handling of the py2removal
process; moving packages out is actually detrimental for the python
ecosystem (at least that's my opinion).

Thomas, this is not the first time your temperament and aggressive
behavior is causing some troubles, please reassess how you interact
and work with other fellow contributors.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Future of PyPy (not PyPy3) in Debian

[Sandro Tosi]

Hello all,
it looks like i started a process that would require the removal of
several PyPy (as in pypy-* depending on the `pypy` package) packages
from the archive.

I'm now wondering: what should we do with the entire pypy ecosystem?
should we treat pypy-* packages like python-* ones and remove then as
part of py2removal? do we need/want to track this effort with the same
usertag? is there a (even if only hypothetical for now) programmed
transition from pypy- to pypy3-?

PS: if i made mistakes, just call me out, and i'll do my best to fix
them or revert them; i have no problem in being told i did something
wrong (let's keep the discussion in this thread on topic, so pypy etc)

Cheers,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#962024: RFP: cppy -- collection of C++ headers which make it easier to write Python C extension modules

[Sandro Tosi]

Package: wnpp
Severity: wishlist

* Package name: cppy
  Version : 1.1.0
  Upstream Author : The Nucleic Development Team
* URL : https://github.com/nucleic/cppy
* License : BSD 3-Clause
  Programming Lang: Python
  Description : collection of C++ headers which make it easier to write 
Python C extension modules

this is a new dependency for kiwisolver/1.2.0

Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

[Sandro Tosi]

> Any trick to avoid those errors in general?

when i push i always do

$ git push --all ; git push --tags

i also have these in ~/.gitconfig

[push]
   default = current
   followTags = true

with should make the `git push --tags` unnecessary after `git push
--all` (as tags will "follow" the diffs you're pushing) but it's stuck
in my bash history so there it is

> Anyways, it should be there now!

indeed it's there -- thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

[Sandro Tosi]

Antoine, you did not push the upstream branch. please do so, in order
to keep the repo consistent


On Mon, May 11, 2020 at 10:15 PM Debian FTP Masters
 wrote:
>
> paramiko_2.7.1-1_source.changes uploaded successfully to localhost
> along with the files:
>   paramiko_2.7.1-1.dsc
>   paramiko_2.7.1.orig.tar.gz
>   paramiko_2.7.1-1.debian.tar.xz
>   paramiko_2.7.1-1_amd64.buildinfo
>
> Greetings,
>
> Your Debian queue daemon (running on host usper.debian.org)
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#960148: RFP: hstspreload -- Chromium HSTS Preload list as a Python package

[Sandro Tosi]

Package: wnpp
Severity: wishlist

* Package name: hstspreload
  Version : 2020.5.5
  Upstream Author : Seth Michael Larson
* URL : https://github.com/sethmlarson/hstspreload
* License : BSD-3
  Programming Lang: Python
  Description : Chromium HSTS Preload list as a Python package

It is used by httpx (althought it's not a hard requirement, but nice-to-have)

Please consider package this under DPMT

Re: issues installing psutil with pip in virtual environment

[Sandro Tosi]

> I am running into an issue installing psutil: pip3 install psutil, in a
> virtual environment. I have upgraded my pip and setuptools with no
> avail. I am getting this error: https://pastebin.com/2Xb7UN9g

psutil is not pure python, and contains some extensions that need to
be compiled, so your system needs to have a compiler, gcc, installed;
since it's not you get "unable to execute 'x86_64-linux-gnu-gcc': No
such file or directory"

> Some have suggested installing the python3-dev package. Saying that I
> require "header" files (don't know what those are). So this means
> installing that package and creating a new venv, where those files are
> available. Is there a way to make this install work without installing
> that package? Is that package really necessary? Does this mean my

you will necessarily need to install python3-dev

> virtual environments are somehow subject to what libraries are
> available in my system python installation?

yes, in a similar way as they are dependent on the system interpreter
to create and run the venv

> Is there some pip
> installabel package that provides these files?

some packages on PyPI provide binary releases, but psutil looks like
it doesnt for linux, so you need to compile it.

alternatively you can install python3-psutil on your host and then
"virtualenv --system-site-packages" to use the system-available
modules.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: khard_0.16.1-1_source.changes ACCEPTED into unstable

[Sandro Tosi]

On Thu, Apr 23, 2020 at 12:51 PM Debian FTP Masters
 wrote:
>
>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Thu, 23 Apr 2020 10:05:57 +0200
> Source: khard
> Architecture: source
> Version: 0.16.1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Team 

this is not the right team and/or email address

since it's in PAPT you need to use :"Python Applications Packaging
Team "

please fix this package and todoman (and any other you may be working
on that had the same issue)
> Changed-By: Félix Sipma 
> Closes: 942416
> Changes:
>  khard (0.16.1-1) unstable; urgency=medium
>  .
>* New upstream version 0.16.1 (Closes: #942416)
>* move the package to Debian Python Team
>* update B-D, add:
>  - python3-sphinx-autodoc-typehints
>  - python3-sphinx-autoapi
>  - python3-astroids
>* docs: remove AUTHORS file
>* khard.examples: remove misc/khard
>* khard.doc-base: update index path
>* update patches
>* bump Standards-Version to 4.5.0
> Checksums-Sha1:
>  5d118c0de53fbf531bb6c64e945afc9aa2ff5479 1680 khard_0.16.1-1.dsc
>  236c06ad9c4ef2629617772cdccf4dd55546b86b 577538 khard_0.16.1.orig.tar.gz
>  4da10c05179540344d6a55d0b03d877cc7ae008f 4964 khard_0.16.1-1.debian.tar.xz
> Checksums-Sha256:
>  99436155dda2dcb5b00e3eedac729f9c2bbaa5b27a181f05a7b303dfa1849d81 1680 
> khard_0.16.1-1.dsc
>  9a50273bc827da99afc4dc8840be02dc37a22c2bfc88a04ed348f60389f14f2e 577538 
> khard_0.16.1.orig.tar.gz
>  b2b8d00529cf4affcf74433b02728d25496802f65e3f4c0dc7ac0eaa7d26ad38 4964 
> khard_0.16.1-1.debian.tar.xz
> Files:
>  b2f4d2430201b15533daef4ccaded2e8 1680 utils optional khard_0.16.1-1.dsc
>  2d17f791b46ae6fb26ee820495084363 577538 utils optional 
> khard_0.16.1.orig.tar.gz
>  513a09f3e14f73b8d8e72a35876e216d 4964 utils optional 
> khard_0.16.1-1.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iHUEARYKAB0WIQR6zeIsS8L0XLQfqiQBpfxHUdFE8AUCXqG/4QAKCRABpfxHUdFE
> 8Kz0AP9bV/BlefuTLkF/Voj+lPLTxFJkfDszr0No/UCfmle7HAEAvAmbhESrLtCS
> t1WtFBITZJmYC0m7BMGC2i4Mc3+H+QY=
> =nBwe
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-modules-team] python-xlib_0.26-1_source.changes ACCEPTED into unstable

[Sandro Tosi]

Andrej,
can you please clarify why you're keep using pristine-lfs even when
prompted not to? this is just from 2 packages uploaded in the last
hour (ftr, pyopenssl is broken now..)

https://salsa.debian.org/python-team/modules/pyopenssl/-/tree/pristine-lfs
https://salsa.debian.org/python-team/modules/urwid/-/tree/pristine-lfs

On Sat, Mar 21, 2020 at 3:31 PM Scott Kitterman  wrote:
>
> On Saturday, March 21, 2020 3:02:27 PM EDT Andrej Shadura wrote:
> > Hi,
> >
> > On Sat, 21 Mar 2020 at 19:39, Sandro Tosi  wrote:
> > > > On Sat, 21 Mar 2020 at 18:01, Sandro Tosi  wrote:
> > > > > Andrej,
> > > > > why the pristine-tar information are now in a `pristine-lfs` branch?
> > > > > where did the other pristine-tar deltas go?
> > > >
> > > > Because it’s simpler and better as it guarantees the tarballs are bit
> > > > to bit identical, which pristine-tar so often fails to do. There was
> > > > no pristine-tar or pristine-lfs information for earlier uploads.
> > >
> > > but our team policy requires to use pristine-tar:
> > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/poli
> > > cy.rst
> > >
> > > please adjust, so that we can all use the same tools and procedures.
> >
> > I suggest we rather change the policy since at the moment this point
> > lacks any rationale and isn’t providing any benefit since the
> > pristine-tar data are only useful for minor updates of the package
> > (e.g. when the upstream source hasn’t changed) and pristine-tar is
> > known to be a huge hack and fail to provide correct tarballs,
> > especially when xz is used.
>
> When you joined the team, you agreed to follow the team policies.  Please do
> so.
>
> The way to get the policy changed is not to ignore it and then get aggressive
> when called on it.
>
> Personally, I use the pristine-tar branch routinely (I used it multiple times
> just yesterday) and I've never had a problem with it.  Personally, while I
> know it's a hack, it's a working hack.
>
> Please do as you've been asked and then we can have a nice conversation about
> if we should change the way the team works.
>
> Scott K
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

[Sandro Tosi]

wait a second: i dont like this idea that DPMT/PAPT are a dumping
ground you can throw away your packages you dont care about that much
so that someone will take care of then. we still require a human
maintainer behind the team name (either they be in Maintainer or
Uploaders, with the different meaning they have in our teams).

if nobody of the current human maintainers has time for properly
maintaining logbook, please do orphan it, instead of moving it to DPMT


On Wed, Apr 15, 2020 at 9:01 AM Andreas Tille  wrote:
>
> Hi Salsa admins,
>
> please be so kind to transfer
>
>  https://salsa.debian.org/debian/logbook
>
> to
>
>  https://salsa.debian.org/python-team/modules/logbook
>
> Thanks a lot
>
>  Andreas.
>
> On Wed, Apr 15, 2020 at 11:33:21AM +0200, Agustin Henze wrote:
> > Hi Andreas, please go ahead and thank you :).
> >
> > Cheers,
> >
> > On 4/14/20 11:16 AM, Inaki Malerba wrote:
> > > El 14/4/20 a las 10:43, Andreas Tille escribió:
> > >> Hi Agustin and Iñaki,
> > >>
> > >> I wonder whether you would like to maintain the logbook package in
> > >> Debian Python Modules team (by setting the mailing list as Maintainer
> > >> and you two serve as Uploaders.)  This would possibly enhance the number
> > >> of people who are watching this package and would simplify doing a team
> > >> upload for the package.
> > >>
> > >> Kind regards
> > >>
> > >>   Andreas.
> > >>
> > > Hi Andreas,
> > >
> > > I'm having troubles to find time to maintain my packages lately, so I
> > > think that's the best way to go.
> > >
> > > I'll wait for Agustin's opinion, but it's ok for me!
> > >
> > > Thanks!
> > >
> > >
> > --
> > TiN
> >
> >
>
>
>
>
> --
> http://fam-tille.de
>


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: py2removal: drop python-pytest by not running tests for python2 packages

[Sandro Tosi]

> so i was playing with the idea of tackling python-pytest removal by
> updating all its rdeps and not run unittests for the python2 binary
> (so dropping pytest and the other b-d* only used for tests).

this is completed, and i've just uploaded pytest removing python-pytest

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

py2removal: drop python-pytest by not running tests for python2 packages

[Sandro Tosi]

Hello,
python-pytest is blocking 18 packages from removal, most of them would
be leaves once python-pytest is gone.

so i was playing with the idea of tackling python-pytest removal by
updating all its rdeps and not run unittests for the python2 binary
(so dropping pytest and the other b-d* only used for tests).

I know it's suboptimal (some python2 packages can still see updates
until we're ready to drop them and running tests can still have
value), but i think the cost/benefit ratio points towards removing
python-pytest soon rather than wait.

There are only 25 packages that would need updating, and most of them
are in DPMT/PAPT.

What do people think?

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Help] Re: Bug#953052: psychopy: python2 dependencies

[Sandro Tosi]

On Wed, Apr 8, 2020 at 12:09 PM Andreas Tille  wrote:
>
> Control: tags -1 help
>
> Hi DPMT,
>
> I need to admit I'm currentl overwhelmed with COVID-19 hackathon.
> A quick view does not really show any suspicious things to me.
> Any help (including team upload / NMU) would be appreciated.

didnt take much to figure it out..

$ aptitude why psychopy python2.7
p   psychopyRecommends python3-pyo
p   python3-pyo Recommends jackd2
p   jackd2  Dependspython-dbus
p   python-dbus Dependspython2 (>= 2.7~)
p   python2 Dependspython2.7 (>= 2.7.17~rc1-1~)


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Telepathy-gabble and python2-rm

[Sandro Tosi]

On Fri, Apr 3, 2020 at 5:04 PM Scott Kitterman  wrote:
>
> There was a telepathy-gabble upload this week that took out a bunch of python2
> build-deps, but it looks like telepathy-gabble-tests retained many of them as
> depends:
>
> https://packages.debian.org/unstable/telepathy-gabble-tests
>
> In particular, this is the last package in Testing that depends on python-
> twisted.  If this could go away, then a bunch of stuff could get decrufted.

that's just been taken care of, sorry it took so long

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: py2removal: proposal to increase apps popcon limit

[Sandro Tosi]

> I propose to raise the popcon threshold to 1000.

this is now enabled (and will start working from the next run, in ~30 mins)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: py2removal: proposal to increase apps popcon limit

[Sandro Tosi]

>> Maybe you can paste the list of 20 affected apps, though?
> I'm more interested in the 18 that are above 1000.  Could you please just 
> list them all 38, sorted by popocon?

here's the list:

cvs2svn - popcon = 303,
chirp - popcon = 350,
gnat-gps - popcon = 354,
cfv - popcon = 387,
fretsonfire-game - popcon = 394,
neopi - popcon = 398,
kcachegrind-converters - popcon = 414,
virt-goodies - popcon = 430,
freeorion - popcon = 433,
syncthing-gtk - popcon = 435,
postnews - popcon = 557,
pssh - popcon = 562,
displaycal - popcon = 562,
archivemail - popcon = 674,
syslog-summary - popcon = 692,
xboxdrv - popcon = 696,
trash-cli - popcon = 753,
fsl-5.0-core - popcon = 822,
denyhosts - popcon = 852,
geda-utils - popcon = 938,
mirage - popcon = 1006,
gnumeric-plugins-extra - popcon = 1110,
getmail - popcon = 1191,
mailman - popcon = 1344,
smart-notifier - popcon = 1362,
xchat - popcon = 1606,
mysql-workbench - popcon = 1688,
calligra-libs - popcon = 2296,
mysql-utilities - popcon = 2448,
lokalize - popcon = 2598,
libboost-mpi-python1.67.0 - popcon = 2691,
bleachbit - popcon = 2773,
qbittorrent - popcon = 3402,
libapache2-mod-python - popcon = 3778,
nagios-plugins-contrib - popcon = 4059,
playonlinux - popcon = 4781,
sugar-browse-activity - popcon = 6421,
ipython - popcon = 8296,

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

py2removal: proposal to increase apps popcon limit

[Sandro Tosi]

Hello,
as part of the py2removal process, we're not raising the bug priority
to serious if it's associated with an application and popcon is bigger
than 300

There are currently:

* 38 apps that are leaf packages and popcon > 300;
** 13 out of 38 have popcon < 600
** 20 out of 38 have popcon < 1000

I propose to raise the popcon threshold to 1000.

What are your thoughts? I will move forward with this change in 3 days
if i dont hear any opposition.

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: When should I drop python2 support for python-linecache2 & python-traceback2 (therefore, unittest2, mock, sphinx, pytest... and the rest of the Python 2 world if I pull this string until end...)

[Sandro Tosi]

> python-fixture (the binary) is gone, therefore we have #952130 and
> #952127. I've been reluctant to remove Py2 support from these, because
> unittest2 needs it, and this would break a lot of packages (including,
> indirectly, stuff like sphinx, pytest, etc.).

you can remove them when

http://sandrotosi.me/debian/py2removal/python-traceback2_1.svg
http://sandrotosi.me/debian/py2removal/python-linecache2_1.svg

show no nodes with a red border.

> What is it that the team suggests at this point? Should I reintroduce
> Py2 support in fixtures

yes, it should have not been dropped since it still had reverse dependencies.

> or should we go ahead and do a missive Py2 RM
> of what's left in the archive?

that's just too much breakage.

> We're down to only 366 packages with Py2 in testing. We can either
> postpone forever, or just go hardly on it (but there will be inevitable
> collaterals...).

bullseye freeze is 9 months away
(https://lists.debian.org/debian-devel-announce/2020/03/msg2.html)
so it's not acceptable to break reverse dependencies recklessly at
this time. let's take the slow and careful road, and work from leaf
packages backwards, as it has happened since now. we can re-evaluate
when we're closer to the freeze.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Questions about including tests/ directory into package

[Sandro Tosi]

> packages=find_packages("src"),
>
> Setuptools will only find "tinyalign" under the "src" folder, as a
> python module to package, which is why that's the only thing that is
> going to be packaged.
>
> IMO, the best approach to this problem is to convince upstream to move
> their tests folder into the Python package folder. Best is even to make
> upstream get rid of the "src" folder, rename that one "tinyalign" and
> put the tests folder in it. In other words, make upstream do:

that's not correct: the "src" directory is a very well know
best-practice (you can google for it, if you need references),
intended to avoid situations where "import mymodule" will have
inconsistent results depending on where you run that command and easy
of testing.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#954115: RFP: capturer -- Easily capture stdout/stderr of the current process and subprocesses

[Sandro Tosi]

Package: wnpp
Severity: wishlist

https://capturer.readthedocs.io/en/latest/
https://pypi.org/project/capturer/

this is a dependency of the test suite of humanfriendly.

Thanks,
Sandro

Re: 2Removal: handling circular dependencies

[Sandro Tosi]

Hey Rebecca, do you have an updated list of these cycles?

On Wed, Oct 23, 2019 at 6:39 PM Rebecca N. Palmer
 wrote:
>
> [Summary of previous messages: I noted that packages with circular
> dependencies can't be removed one at a time without breakage.  Replies
> were to remove multiple packages at once if necessary, but ask first if
> other maintainers' packages are involved.]
>
> I have now checked what cycles we have:
>
> - 13 small sets (one of 13, others 2-4 each): small enough that "remove
> the whole set at once" is manageable.
>
> - One big tangle (159 packages).  This probably needs breaking up:
> --- Some of it involves documentation tools (e.g. sphinx).  These cycles
> can be broken by using the Python 3 version of the tool.
> --- Some of it is "A Suggests (or Recommends) A-extension, A-extension
> Depends on A" cycles (e.g. pandas<->statsmodels).  If A-extension is
> otherwise ready to remove but A is not, these can be broken by removing
> the Suggests from A.  (Assuming we're still using "broken Suggests are
> not allowed": this has previously been discussed, I forget where.)
>
> Full listing:
>
> 159 pyrex lxml html5lib sphinx mako python-scipy pandas patsy
> statsmodels seaborn sphinx-gallery matplotlib2 mpmath sympy
> texlive-extra nbconvert jupyter-notebook ipywidgets texlive-base dot2tex
> matplotlib numpydoc python-cycler ipykernel python-numpy mayavi2
> python-chaco python-envisage python-enable joblib pyzmq jupyter-client
> python-hypothesis chardet pygments python-pyface python-traitsui
> python-apptools python-traits ipython jupyter-core nbformat
> prompt-toolkit mercurial setuptools-scm python-py pytest-xdist pytest
> python-packaging python-importlib-metadata python-pluggy pyopenssl
> python-urllib3 python-future pyglet python-lz4 fdb sqlalchemy
> sphinxcontrib-websupport requests python-click incremental twisted
> automat python-service-identity python-gevent entrypoints python-flake8
> xcffib cairocffi python-keyring wheel python-pip keyrings.alt execnet
> sphinx-rtd-theme python-prometheus-client pytest-expect pytest-forked
> pytest-runner python-bleach python-mccabe python-atomicwrites
> python-attrs python-babel tap.py dbus-python python-qt4 pyqt5
> python-characteristic apipkg python-cryptography python-dateutil
> freezegun traitlets python-typing openpyxl python-tz python-et-xmlfile
> python-whoosh python-flaky wcwidth pexpect pillow python-docutils pymacs
> ropemacs python-mode enum34 sip4 configobj python-iso8601 pycairo
> pygobject-2 pygobject send2trash pygtk simplejson six unittest2
> python-mock python-psutil contextlib2 python-zipp python-traceback2
> python-debian python-apt python-linecache2 python-funcsigs
> python-concurrent.futures python-pathlib2 pickleshare testpath
> python-genty xlwt more-itertools backports.functools-lru-cache rope
> ropemode colorspacious cython pyyaml cvxopt sphinx-paramlinks
> python-pysqlite2 alabaster python-setupdocs nose mistune terminado
> python-webencodings ipython-genutils pep8 autopep8 pyxdg
> python-nose-exclude pyflakes python-greenlet xapian-bindings
>
> 2 rdflib sparql-wrapper-python
> 2 mgltools-pmv autodocktools
> 2 salutatoi sat-templates
> 2 cclib cclib-data
> 3 pastescript paste pastedeploy
> 2 sugar sugar-pippy-activity
> 13 trac-mercurial trac trac-customfieldadmin trac-graphviz
> trac-mastertickets trac-spamfilter trac-wikiprint trac-wysiwyg
> trac-xmlrpc email2trac trac-accountmanager trac-authopenid trac-bitten
> 4 hachoir-urwid hachoir-core hachoir-parser hachoir-metadata
> 4 python-pysnmp4 python-pysnmp4-mibs python-pysnmp4-apps pysmi
> 3 laditools ladish laditools # two 2Removal bugs on the same package
> 2 rpmlint rpm
> 2 crossfire crossfire-maps
> 3 python2.7 python-defaults python-stdlib-extensions
>
> (Based on recent cont...@bugs.debian.org messages; packages not listed
> are not in a cycle)
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: ITS: pssh

[Sandro Tosi]

On Thu, 20 Jun 2019 06:24:13 -0700 Mo Zhou  wrote:
> Source: pssh
> Version: 2.3.1-1
>
> I plan to salvage pssh and fix at least the following bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891340

Not sure if Mo is still interested in salvaging this package, other
wise this could be a nice project for someone willing to improve their
packaging skills. this would translate to:

* bring it under PAPT maintenance
* update to the latest upstream release (check #891340 or even
https://github.com/ParallelSSH/parallel-ssh ?)
* drop python2 support, add python3 support
* upload to debian.

Regards,
Sandro

Re: Bug#937177: obitools: Python2 removal in sid/bullseye

[Sandro Tosi]

> > This
> > package is blocking several others.  Would it be best to remove it?  It can
> > always be re-introduced if a python3 port appears.
>
> Since some time I've pushed a 2to3 based port to Git.  I've now fixed
> some issues of this and I wonder whether we might give it a try to do
> the port inside Debian.

It looks like Olivier committed a py3k port on debmed almost a month
ago: Olivier, do you have any plan to complete (if necessary) and
upload this package soon? it would help with the py2removal effort.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Bug#952952: RM: src:ipykernel-py2 -- RoM for Python 2 removal

[Sandro Tosi]

> The src:ipykernel-py2 package provides python-ipykernel, which is to be
> removed for the Python 2 removal transition.

Cc-ing Gordon explicitly: the last time we spoke, Gordon wanted to
keep the python2 stack of ipython/ikernel/jupyther for people to still
have a py2 infrastructure to run their notebooks. Is this changed? are
we ready to remove them all?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#951348: RFP: scalene -- high-performance, high-precision CPU and memory profiler for Python

[Sandro Tosi]

Package: wnpp
Severity: wishlist

* Package name: scalene
  Version : 0.7.5
  Upstream Author : Emery Berger
* URL : https://github.com/emeryberger/scalene
* License : Apache
  Programming Lang: Python
  Description : high-performance, high-precision CPU and memory profiler 
for Python

Scalene is a high-performance CPU and memory profiler for Python that does a few
things that other Python profilers do not and cannot do. It runs orders of
magnitude faster than other profilers while delivering far more detailed
information

 * Scalene is fast. It uses sampling instead of instrumentation or relying on
   Python's tracing facilities. Its overhead is typically no more than 10-20%
   (and often less).
 * Scalene is precise. Unlike most other Python profilers, Scalene performs CPU
   profiling at the line level, pointing to the specific lines of code that are
   responsible for the execution time in your program. This level of detail can
   be much more useful than the function-level profiles returned by most
   profilers.
 * Scalene separates out time spent running in Python from time spent in native
   code (including libraries). Most Python programmers aren't going to optimize
   the performance of native code (which is usually either in the Python
   implementation or external libraries), so this helps developers focus their
   optimization efforts on the code they can actually improve.
 * Scalene profiles memory usage. In addition to tracking CPU usage, Scalene
   also points to the specific lines of code responsible for memory growth. It
   accomplishes this via an included specialized memory allocator.

Re: Where can I find packages that need a maintainer?

[Sandro Tosi]

> I recently started as a maintainer of a package for Debian which is
> currently awaiting approval to be reintroduced into the repositories. [1]
>
> With the desire to continue contributing I would like to know where I
> can find other packages that need a maintainer.

you can start from here: https://www.debian.org/devel/wnpp/

there are some python packages there (i imagine you want to focus on
those given you write to d-python@ )

General rule of thumb is: dont maintain packages just because of it,
maintain something you use and find useful; you'll be able to do a
better job, benefit from your maintenance work and provide a better
package to Debian's user

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: python-babel

[Sandro Tosi]

> In such case, could you provide me with the source package, rather than
> just letting me try with Git? Maybe this is going to work then...

whatever turns out to be, please ensure the package is buildable from
the git repo. and matches what's going to be uploaded. We have already
enough packages with missing pristine-tar deltas, with orig tarballs
that dont match what's in the upstream+pristine-tar output, let's not
increase that number.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Proposal on how to proceed with Python 2 removal from bullseye

[Sandro Tosi]

On Sun, Dec 22, 2019 at 5:58 AM Simon McVittie  wrote:
>
> On Wed, 18 Dec 2019 at 01:08:11 -0500, Sandro Tosi wrote:
> > let me know if this makes sense or additional changes are required.
>
> #942941 in src:dbus-python was bumped to serious because:
> > python-dbus-tests is a module and has 0 external rdeps or not in testing
>
> Please could you give python-dbus-tests or *-tests an exception to the
> RC severity bumps, or only bump the severity if *every* Python 2 binary
> package in a source package is eligible for removal, or something?
> python-dbus still has a significant number of rdeps, and I don't want to
> support python-dbus without keeping its automated tests available.

i just implement what asked here, with also a "rollback" functionality
that will downgrade any RC bug for a source with not-leaf packages.
there's a chance some bugs which severity was raised by hand (f.e.
because a dependency package was removed) will get reverted to normal,
we'll see how it goes. the change will go live in a few minutes.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: [Python-apps-team] Bug#938682: Future of Trac in Debian

[Sandro Tosi]

> > if i dont hear anything back withing a week, i'll most likely opening
> > those RM bugs, so that we can work on their transitive dependencies.
>
> Just go ahead. I hope, we can reintroduce Trac in one or two
> years, maybe in time for Debian 12 (bookworm), but probably not
> for Debian 11 (bullseye).

thanks, just filed all those RM bugs.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Future of Trac in Debian

[Sandro Tosi]

Hello Martin,

On Fri, Nov 29, 2019 at 6:55 PM Martin  wrote:
>
> On 2019-11-29 18:13, Nicholas D Steeves wrote:
> > IMHO one of the Debian Trac uploaders should post to the #12130 Trac
> > ticket informing them of our plan.
>
> I linked to the email of 2019-10-14:
> https://trac.edgewall.org/ticket/12130#comment:63

So Jan 1 arrived, what do you think we should do? i didnt see any
progress on the port to python3 upstream; should we start filing RM
for trac extensions/plugins and once they are gone, RM src:trac?

an initial list of packages for the first pass of RM could be:

$ apt-cache search trac-
libnet-trac-perl - Perl client library for Trac
libtext-trac-perl - module for formatting text with Trac Wiki Style
trac-accountmanager - account management plugin for Trac
trac-announcer - enhanced e-mail notification system for Trac
trac-authopenid - OpenID authentication plugin for Trac
trac-customfieldadmin - panel for administrating custom ticket fields in Trac
trac-datefield - Add custom date fields to Trac tickets
trac-diavisview - Renders dia and vdx files in Trac
trac-graphviz - Graphs printing plugin for Trac
trac-httpauth - Force HTTP authentication from within Trac
trac-icalview - Provides iCalendar feeds for ticket queries
trac-includemacro - Include external resources in a Trac wiki page
trac-jsgantt - displays Trac tickets as a Gantt chart in a wiki page
trac-mastertickets - adds inter-ticket dependencies to Trac
trac-mercurial - Mercurial version control backend for Trac
trac-navadd - add custom items to main and meta navigation bar in Trac webapp
trac-odtexport - Export Trac wiki pages as OpenDocument (ODT) files
trac-privatetickets - Allows Trac users to only see tickets they are
associated with
trac-privateticketsplugin - transitional dummy package for trac-privatetickets
trac-privatewiki - add private wiki ability to Trac
trac-roadmap - enhances the Trac roadmap with sorting and filtering
trac-sensitivetickets - Plugin for Trac ticketing system to hide
tickets marked as sensitive
trac-subcomponents - use multiple layers of components in Trac
trac-subtickets - sub-ticket feature for Trac tickets
trac-tags - Tagging plugin for Trac wiki and issue tracking system
trac-translatedpages - Show translated versions of wiki page in the
Trac web application
trac-virtualticketpermissions - Extended permissions plugin for Trac
ticketing system
trac-wikiprint - Make Trac wiki pages printable, exporting to PDF or
printable HTML
trac-wikitablemacro - SQL Table in Wiki Page for Trac
trac-wysiwyg - WYSIWYG style editor for the Trac issue tracking system
trac-xmlrpc - XML-RPC interface to the Trac wiki and issue tracking system

if i dont hear anything back withing a week, i'll most likely opening
those RM bugs, so that we can work on their transitive dependencies.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Proposal on how to proceed with Python 2 removal from bullseye

[Sandro Tosi]

> 1) all Python 2 removal bugs *can* be raised to RC level by the
> maintainers of the packages they belong to, but:
>
> 2) maintainers of non-key packages should carefully consider the
> backslash for their transitive reverse (normal, build and test)
> dependencies before raising the bug severity level and in my opinion
> should hold off doing that if there are many that need adaption for the
> Python 2 support removal. To be absolutely clear of my intent, if there
> is only a *very* limited set that needs adaption but they have a large
> set of reverse dependencies that is not what I mean here. The
> maintainers of the large set of reverse dependencies have a joint
> incentive to fix the issue if the maintainer of the to-be-adapted
> package(s) doesn't step up to fix the situation.
>
> 3) packages with unfixed reverse (normal, build or test) dependencies,
> that want to drop Python 2 support should first make sure their unfixed
> reverse dependencies have RC bugs themselves (but please take the
> consideration of 2 into account), stating at least something like
> "source package $foo is soon going to remove the binary $bar package on
> which the $baz package (build) depends, please fix that".
>
> To avoid problems with bug fixes that need to migrate to testing soon,
> please don't upload the Python 2 support drop immediately, but wait
> until either the reverse dependencies are fixed or the date for the
> autoremoval is near.
>
> 4) leaf packages (i.e. without normal, build or test reverse
> dependencies) that need to be adapted themselves for the Python 2
> removal can be marked as RC.
>
> 5) Please continue to use the approach used so far as well, but please
> also add checks on build dependencies.

i've modified the py2removal script as follow:

- extended the "real rdeps" concept as follow: while processing pkgA,
pkgB is a "real" reverse dependency of pkgA iff
-- pkgB is from another source package than pkgA (so python-foo-dbg
will not longer be marked as a rdep of python-foo, as ideally they
will get removed at the same time, as part of the same src:foo pkg)
-- if the pkgB is in testing (there are several packages in unstable
broken beyond repair, so even if we remove pkgA, it will still remain
broken but we can make progress on the py2removal front)
- added the check "real rdeps" == 0 both for modules and applications
(previously it was only for modules).

a test run shows only 3 additional severity bumps will happen when
re-enable, which i plan on doing with the next run (in 8~10 hours).

let me know if this makes sense or additional changes are required.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: RFS [RC] jsonpickle, python-serverfiles

[Sandro Tosi]

both sponsored, thanks for your contribution to Debian!

On Sat, Dec 14, 2019 at 3:10 AM Håvard Flaget Aasen
 wrote:
>
> Hello,
>
> Can someone please do an upload of jsonpickle? It is marked for
> autoremoval on 19 January. This update fixes the issue, it also updates
> to the latest upstream release.
> https://salsa.debian.org/python-team/modules/jsonpickle
>
> I did the same on python-serverfiles, removed an rc bug and updated it
> to the latest upstream release. Though this has never gone all the way
> to testing, blocked for over a year because of a missing dependency.
> https://salsa.debian.org/python-team/modules/python-serverfiles
>
> Thanks,
> Håvard
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

there seems to be disagreement on how to proceed, so for the time
being i suspended the severity bump part of the py2removal tracking
script. let me know when everybody agrees on a solution, and what that
solution is, and i'll code it and re-enable.

regards,
Sandro

On Thu, Dec 5, 2019 at 6:07 AM Paul Gevers  wrote:
>
> Hi,
>
> On 03-12-2019 13:19, Matthias Klose wrote:
> > It's unfortunate that issues for some packages only get attention when the
> > severity of an issue is raised.  Following your proposal means that the 
> > issue is
> > probably ignored forever, and you don't propose a better way going forward, 
> > just
> > saying we should stop earlier.  I don't think that's the correct choice.  
> > For
> > now these seem to be single packages, so please could you name those, and 
> > we can
> > look at those with a priority?  That's at least a path that is forward 
> > looking,
> > or feel free to propose another approach better than your current proposal 
> > for
> > not getting the attention of maintainers.
>
> I guess what I'm asking for could be fulfilled by an announcement to
> d-d-a with a package list (including via which package(s) they are
> affected) attached including the standard grouping by DD. And then some
> time to react.
>
> Paul
>
> PS, my original typed reply below. After having writing it, the idea
> above emerged.
>
> My problem with the current approach is that the way that developers
> learn that they (potentially transitively) (build) depend on a Python 2
> package is by the autoremoval message. I don't think that is acceptable
> socially in the project. My proposal is to give the maintainers about
> those packages a heads up. Via a bug report may be a bit weird in cases,
> but in some cases may be the appropriate thing as the package could work
> around the (build) dependency. At least adding "affects" helps a tiny
> bit and direct e-mails to the maintainers (e.g. via the
> @packages.debian.org address will at least give them a heads
> up. Even if the RM bug is coming eventually.
>
> Again, I don't have a problem with Python 2 removal, even at the price
> of packages that don't care that their dependency is written in Python.
> I do care about proper communication. Using RC severity to trigger
> autoremoval for non-leaf packages just yet is not appropriate in the
> opinion of the release team. Even though I am well aware of the Python 2
> removal effort I can tell from personal experience (cacti) that
> receiving an autoremoval e-mail as the first sign of such a dependency
> isn't nice, that's the problem I'm having and that needs solving in my
> opinion.
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

> You'll fix that, right? Because why would the tree stop at Python? A
> leaf package is a package without Depends/Build-Depends in Debian. (I
> appreciate it very much that you consider Recommends and
> autopkgtest-triggers as well).

so the revised logic should be:

* it's an app (package name doesnt start with 'python-' or end with -'doc')
* it has low popcorn (< 300)
* (NEW) it has "real" rdep = 0 (so the number of dependencies from
packages not from the same source pkg are 0)

is that correct or should it be something else?


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

> > huh? We are not bumping any "blocked" bugs.
> > Depends/Build-Depends/Recommends/autopkgtests usage marks bug as
> > blocked. Any example of "wrong definition" please?
>
> #942999 and #936537

the blocks are only between py2removal packages, so if a package
un-related to the py2removal effort
depend/recomments/b-deps/autotest-triggers a py2removal *application*, that
is still considered a leaf package and will get its severity
raised (cfr 
https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L544-L546
); it doesnt happen with modules are we check the "real" rdeps for
those


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

Paul, this is the thread i was talking about.

you were copied in the original email:
https://lists.debian.org/debian-python/2019/10/msg00098.html

if there is something the RT wants to discuss about this effort,
please do so here, not directly to me (i may be the mail address
sending those control commands, but the decision was taken here).

Thanks,
Sandro

On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy  wrote:
>
> Hi Sandro,
>
> -- Forwarded message -
> > We are going to raise the severity of the py2removal bugs to "serious" in 
> > several steps.  In the
> > first phase we are going to raise severity of the py2removal bugs for
> > all leaf module packages and low popcon (< 300) application packages.
> > Bugs marked with the "py2keep" user tag will not have their severity
> > raised.
>
> is there any progress with script from your site please? First we need list 
> to check. Thanks a lot.
>
> --
> Best regards
>  Ondřej Nový
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: RFS: spyne/2.13.11a0-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Sandro Tosi]

> I am looking for a sponsor for the package "spyne" which has a
> py2removal RC bug and will be autoremoved on December 13th. The package
> is Python 2 only but the current alpha version has Python 3 support. I
> uploaded a Python 3 compatible package in January and referenced it in
> #877783 but did not get any response from the maintainer.
>
> Now that the bug is RC I think that it is time for a NMU and hope to
> find a sponsor for the package.

I've reviewed and uploaded the package to DELAYED-5 (since it's a NMU
for a new alpha version in unstable), so that the maintainer may have
a chance to voice their concerns/opinions. Thanks for your
contribution to Debian!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Future of Trac in Debian

[Sandro Tosi]

Hello everyone,
i'd like to discuss the future of Trac in Debian. as we all know, Trac
is still python2, and while there are plans to port it to python3
(https://trac.edgewall.org/ticket/12130) that port is not there yet,
and it may take quite some time to reach a state it can be tested, let
alone released.

What should we do in the meantime? bin:trac has 30 reverse
dependencies (its plugins/addons) and all of them collectively are
likely forceing several other python2 packages to stay in Debian
because they depend on them.

I know it may sound hard, but is it now time to remove trac from
Debian, and ideally re-introduce it back when it's being ported to
py3k?

thanks,
sandro

Re: Severity bump script

[Sandro Tosi]

> I think we should use something simple/short like this:
>
> --cut--
> Raising severity of Python 2 removal bugs, for details see: 
> https://lists.debian.org/debian-devel-announce/2019/11/msg0.html
> --cut--

this is live now, with the following header:

# Part of the effort for the removal of python from bullseye
#  * https://wiki.debian.org/Python/2Removal
#  * http://sandrotosi.me/debian/py2removal/index.html
# See https://lists.debian.org/debian-devel-announce/2019/11/msg0.html
# for more details on this severity bump

# python-apns-client is a module and has 0 external rdeps
severity 935212 serious
.


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

[Sandro Tosi]

On Thu, Nov 28, 2019 at 11:11 AM Andreas Tille  wrote:
>
> On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote:
> >
> > > Is there any trick to enable autopkgtest-pkg-python detecting the correct
> > > module name?
> > >
> >
> > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6
> > )
>
> Hmmm, what are the chances to get this applied?  I've added
>
>X-Python-Module-Name: pubsub
>
> in Git - but this will not reall fix the test.  The only solution I'd see
> otherwise is to deactivate the test.

if you install `pubsub` as top-level module, your package must be
named pythonN-pubsub, if not it violates the policy and it's RC buggy.
please rename the package.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

On Wed, Nov 27, 2019 at 2:16 PM Ondrej Novy  wrote:
>
> Hi,
>
> pá 22. 11. 2019 v 22:22 odesílatel Sandro Tosi  napsal:
>>
>> I've removed bugs that are marked as blocked by; we're now down to 487
>> unique severity raies
>
>
> cool. Checked and imho it works fine now. So I guess we can run it.

i'm not sure we can: in
https://lists.debian.org/debian-python/2019/10/msg00096.html you say
"We need to prepare draft of RC-bumper email", is this draft ready?
how do we wanna use it: should we email each bug individually or just
add the description to the header (as comment) of a mail to control@?

it's probably not a good idea to mail each bug individually as it will
produce a lot of emails (at least in the first batch) that will result
in my laptop being blacklisted by bugs.d.o MTA.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Discussing next steps for the Python2 removal

[Sandro Tosi]

> 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

i found approximately 140 more packages that depends on python/cython
and dont have a py2removal bug; i'll spot check that list soon and
will report the missing bugs in the coming days.

I'll also start looking into packages that closed a py2removal bug but
still have py2 dependencies (and probably i'll reopen said bug).

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

On Fri, Nov 22, 2019 at 3:23 AM Ondrej Novy  wrote:
>
> Hi Sandro,
>
> thanks for first version. I randomly checked few lines and found this:
>
> # libufo0 is an application and has low popcon (25 < 300)
> severity 938743 serious
> # libufo-bin is an application and has low popcon (4 < 300)
> severity 938743 serious
> # libufo-dev is an application and has low popcon (5 < 300)
> severity 938743 serious
> # python-ufw is a module and has 0 external rdeps
>
> But in bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938743
>
> is
>
> Fix blocked by 938744: ufo-filters: Python2 removal in sid/bullseye
>
> So because 938743 is blocked by 938744, we should not raise severity of 
> 938743, right?

i've removed bugs that are marked as blocked by; we're now down to 487
unique severity raies

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Bug#937657: Issue with numpy under Python 3.8

[Sandro Tosi]

On Sun, Nov 17, 2019 at 10:58 AM Andrey Rahmatullin  wrote:
>
> On Sun, Nov 17, 2019 at 04:29:56PM +0100, Andreas Tille wrote:
> > > If you look on the numpy tracker page [1], you'll see there is a note:
> > >
> > > "This package is part of the ongoing testing transition known as
> > > python3.8. Please avoid uploads unrelated to this transition, they
> > > would likely delay it and require supplementary work from the release
> > > managers."
> >
> > I wonder in how far this is relevant to simply *build* a package.
> It's very relevant to running its tests.

i've re-uploaded src:numpy last night, and it was built for 3.8 too;
so whenever your mirror will get an archive push, you should be able
to test with both supported python3 versions.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

> I see that the script considers some -doc packages as modules.

good point; fixed, but that only brings down the unique severity bumps to 688

> I can’t tell if we should remove them, but maybe the description could
> be updated? Like “python-foo-doc is a documentation package has 0 external
> rdeps”.

naah we shouldnt remote them

> Also, in other lines I would also change “have” to “has”.

fixed that too

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy  wrote:
>
> Hi Sandro,
>
> -- Forwarded message -
> > We are going to raise the severity of the py2removal bugs to "serious" in 
> > several steps.  In the
> > first phase we are going to raise severity of the py2removal bugs for
> > all leaf module packages and low popcon (< 300) application packages.
> > Bugs marked with the "py2keep" user tag will not have their severity
> > raised.
>
> is there any progress with script from your site please? First we need list 
> to check. Thanks a lot.

where is the first draft:
http://sandrotosi.me/debian/py2removal/would_raise_to_rc.txt (it will
be updated every time the script runs)

there are 703 unique severity bumps roughly half of the pending bugs.
please note there are duplicates in the list as data is per binary
package, while bugs are on a source package basis.

you can read the heuristic to determine if it's a module
(https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L472)
or and app 
(https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L475)
in the links, they are pretty weak, is there a better way?

all in all i think this is not the effect people were expecting: there
are too many packages that would become RC-buggy; also the severity
bump is done at the source package level, even if only a single binary
in the pkg set matches the criteria (which, if you read the request
above, it is what's wanted).

Let me know what you think,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: reducing matplotlib2 build-depends.

[Sandro Tosi]

On Tue, Nov 12, 2019 at 9:24 AM peter green  wrote:
> I am guessing that many of these are to get testsuite coverage for optional 
> features and are not strictly needed for the build, while testing stuff is 
> nice I don't think it's vital for software that is on it's way out. I tried 
> removing all of the aforementioned packages except python-setuptools and 
> python-kiwisolver from the build-depends (and I uninstalled all python 2 
> packages from the chroot where I was doing my test builds before I installed 
> the remaining build-depends).

well, i dont think it's a good reason to just stop testing complex
software tho. some of those dependencies are required so that mpl can
build extensions (in particular for the GUI backends) so if you remove
them, the mpl build system is smart enough to disable those
extensions, resulting in a graphic library without any GUI bindings to
work with. that doesnt sound ideal.

I'm gonna go thru some of the dependencies and will see if i can
remove some, in particular now that i've remored the -doc package from
the git repo, but i'm not gonna get rid the whole unittest suite.

thanks for your work on this, and to nudge me into looking deeper at mpl2 deps

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

[Sandro Tosi]

that policy is well written down, at
https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin - give it a
look and see if it clarifies your doubt about team maintenance and why
someone would prefer to have the ultimate responsibility for the
quality of a package.

you already created the openstack team (which is great!) with exactly
and only the rules you like, where you're free to do what you feel is
best; that's great but please also realize not everyone shares the
same ideas as yours and you should try sometimes to respect those
people decisions too.

On Mon, Nov 11, 2019 at 6:14 PM Thomas Goirand  wrote:
>
> On 11/11/19 9:17 PM, Scott Kitterman wrote:
> > Personally, I've been judicious in putting myself as Maintainer in DPMT and 
> > PAPT packages.  If we were to ditch the current policy, my immediate 
> > response would be to remove DPMT/PAPT from uploaders and maintain them 
> > outside the team.  It's about 1/4 of my DPMT/PAPT packages.
> >
> > I suspect I'm not the only one.
> >
> > Your proposal is not cost free for the teams.
> >
> > Scott K
>
> Hi Scott,
>
> Exactly what difference would it make? Just that your package would
> really appear as not team-maintained, which is already the current plain
> reality (as the "unwritten policy" tells nobody else but you can touch
> the package). So I don't see why anyone in the team would mind.
>
> Cheers,
>
> Thomas Goirand (zigo)
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Severity bump script

[Sandro Tosi]

On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy  wrote:
>
> Hi Sandro,
>
> -- Forwarded message -
> > We are going to raise the severity of the py2removal bugs to "serious" in 
> > several steps.  In the
> > first phase we are going to raise severity of the py2removal bugs for
> > all leaf module packages and low popcon (< 300) application packages.
> > Bugs marked with the "py2keep" user tag will not have their severity
> > raised.
>
> is there any progress with script from your site please? First we need list 
> to check. Thanks a lot.

no progress on this yet.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

[Sandro Tosi]

> On 11/8/19 8:54 AM, intrigeri wrote:
> >  - In https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin,
> >the "Policy About Maintainer and Uploaders Fields" section
> >mentions an "unwritten policy". Said policy seems to have been
> >written since:
> >
> > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>
> It's probably time to revisit this policy. I've heard many voices
> telling that a package should either be in the team, or just not, and I
> very much agree with this. This middle-ground makes no sense.

is there any public trace of these "many voices"? i, for one, very
much like this policy, and would like to continue having it; and btw,
it is still in place so everyone should adhere to it (since they
promised to so when joining the team).

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Discussing next steps for the Python2 removal

[Sandro Tosi]

> notes from this meeting 
> (https://gobby.debian.org/export/Teams/Python/Py2Removal):

small additional note: the py2removal tracker script now ignores
Suggests and wont mark them as rdeps

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: Discussing next steps for the Python2 removal

[Sandro Tosi]

On Thu, Oct 24, 2019 at 4:09 PM Ondrej Novy  wrote:
> We want to bump all bugs to RC bugs, if they are:

Was there anyone from the RT that ack'd this? Paul is here and i guess
he can do that now: there could be hundreds of new RC bugs in a blink.

> * leaf package
> * with py2 binary

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?

> * 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).

> If package will be removed from testing (auto-rm), we are going to remove 
> them from unstable. We are going to run this process semi-automatically 
> (after more packages gets leaf). First version of list should be checked 
> (emailed to this ML). We need to prepare draft of RC-bumper email.

mailing an explanation can be tricky: currently the script simply
generates a mail to control@ and that's usually accepted within
seconds of it sending it. but the BTS mail server do implement
greylisting and throttling so generating a huge number of individual
emails could just result in them being queued on my machine until
accepted, and make the script generate duplicate emails (possibly
confusing the end users and definitely un-necessary).

we could go with multi-recipients emails, but first we need to
identify how many recipients is acceptable for the BTS mail severs
(there are usually rules in place to prevent spam), and that also
means there will be a rather long "control header" (for the control
commands) in the email, rendering rather ineffective the text of the
explanation, which will be at the bottom.

> We will send email to d-d-a with current state, our next steps, etc.
>
> We are going to bump Lintian tags severity:
> * python-foo-but-no-python3-foo: warning->error
> * dependency-on-python-version-marked-for-end-of-life: pedantic->warning
> * new-package-should-not-package-python2-module: warning->error
> * build-depends-on-python-sphinx-only: warning->error
> * depends-on-python2-and-python3: info->warning
> * script-uses-unversioned-python-in-shebang: info->warning

is there any plan to make some of this tags an upload-rejecting one?

thanks everyone on working to get rid of python2 from debian!

-- 
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: Discussing next steps for the Python2 removal

[Sandro Tosi]

> 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

[Sandro Tosi]

> 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

Re: Discussing next steps for the Python2 removal

[Sandro Tosi]

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

Re: [Python-apps-team] pylint3 reverse dependencies.

[Sandro Tosi]

> A team Upload is accepted, isn't? :-)

the package is not maintained by a formal team (but there are 2 people
registered in Maintainers/Uploaders) so that wont be possible.

-- 
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: [Python-apps-team] pylint3 reverse dependencies.

[Sandro Tosi]

Piotr,
how much more should we wait for a dh-python upload to address this?
it's now more than a month i opened the MR about it; if you're busy,
just let us know and i'll NMU, but we really need this fixed so that
we can start properly migrate rdpes to `pylint`.

Thanks,
Sandro

On Fri, Oct 4, 2019 at 10:15 AM Sandro Tosi  wrote:
>
> Piotr, please do not hold onto the upload - the reason is still there
> it's because it's a cruft package, which will be removed once we fix
> dh-python and make pylint conflict with pylint3 (instead of just
> provide it), which we currently cant do due to dh-python still
> producing the pylint3 dependency.
>
> On Fri, Oct 4, 2019 at 5:42 AM Piotr Ożarowski  wrote:
> >
> > > Yes this is a known issue and we are currently waiting for an upload
> > > of dh-python to avoid automatic replacement of pylint by pylint3 when
> > > on python3 before pushing those changes further.
> >
> > http://ftp.debian.org/debian/dists/unstable/main/Contents-amd64.gz
> > still contains pylint3 so I'm waiting with an dh-python upload for now
> > --
> > GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
> >
> > ___
> > Python-apps-team mailing list
> > python-apps-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-apps-team
>
>
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi



-- 
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: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Sandro Tosi]

On Tue, Oct 15, 2019 at 12:55 PM Thomas Goirand  wrote:
>
> On 10/15/19 5:00 AM, Craig Small wrote:
> >
> >
> > On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand,  > > wrote:
> >
> > Please re-read the excellent contribution from Neil Williams
> > in this thread, and explain again why we have a special case... :)
> >
> > I just did re-read it; especially about it's RC bugs not a total removal
> > RM so these packages will sit in unstable and not move into testing.
> >
> > That works for me.
>
> Hi Craing,
>
> I'm not sure if that helps, but here's a patch... :)

did you test your patch?

+-print "v1 snmpset result: ", res, "\n"
++print9"v1 snmpset result: ", res, "\n")


-- 
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: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Sandro Tosi]

On Mon, Oct 14, 2019 at 10:14 PM Thomas Goirand  wrote:
>
> On 10/14/19 3:54 PM, Sandro Tosi wrote:
> >>> But in both cases, it's going to take a very long time. Do we really
> >>> want to get stuck on these packages for like forever, or would it feel
> >>> ok to raise the severity to serious, so that the package gets
> >>> auto-removed and then we can work on removing Python 2 from its
> >>> dependencies?
> >>
> >> for me it's perfectly fine to rise severity to serious of all leaf 
> >> packages with py2remove bug as soon as possible. And let's do it 
> >> "automatically" everytime any package gets leaf state.
> >
> > i think it's a bit premature to raise severity to RC (we should also
> > check with the release team): these bugs have been opened since just 2
> > months and a half, and the development cycle for bullseye started not
> > longer before. there's still a lot of time.
>
> It's not as if it has been 10 years we know about this transition, right? :)

definitely 10 years ago we did not know python2 upstream maintenance
would terminate on jan 1, 2020; nor that debian will push to remove
python2 from bullseye.

> How many months do you want to add? Do you seriously think it's going to
> significantly change something about an eventual situation where
> upstream hasn't done the work? If upstream did the work, then what's
> blocking us?
>
> If we see a package where upstream has Py3 support, we don't need to
> raise the severity, we can just do the work instead.

you are trying to generalize the situation of ~3000 packages, it just
doesnt work; every situation is different. There are cases where
upstream release a py3k compatible version and it's not packaged in
debian, or someone forked a py3k version, which is now incompatible
with the py2 version, and so many other different variations.

put the work in, and when we are close to a stall situation and/or
close to the freeze we can evaluate what to do, with drastic decisions
too.

> > (and removing a py2
> > package from a leaf pkg takes 5 minutes, usually, so if everyone in
> > this thread had done that instead of writing an email, we'd be down 5
> > bugs already :D )
>
> I probably have done hundreds of them already. And I do not agree that

lol including
https://tracker.debian.org/news/1065995/accepted-cherrypy3-891-3-source-all-into-unstable/
which broke calibre

you're approach is sometimes reckless and you should re-evaluate it.

Sadly many others did the same, and reverse dependencies broke because
maintainers dropped packages without verify if they were leaf pkgs
first.

Debian is not about speed, is about quality, if you cannot see that,
there's no amount of emails that will change it.

> it takes just 5 minutes. For a trivial leaf package, probably, but when
> you're trying to fix a long chain of dependencies, it can sometimes be a
> non-trivial work. Going from the leaf package and rewinding can
> sometimes lead to mistakes.

even a long chain starts from a leaf package. you fix that and then
you move one step closer. it does not add complexity (as it's the same
set of actions, generally) just time.

> > I think it's also extremely premature (and just a bad idea in general)
> > to consider breakage of reverse dependencies but just dropping py2
> > packages. the Release Team is extremely unhappy with this approach for
> > dealing with the py2removal bugs, so let's not even consider that
> > option.
>
> Yes. Which is why we should raise severity of bugs to RC, and probably
> even remove packages if we need to. Otherwise, this process will take
> forever (ie: longer than a Debian release cycle).

you're missing the point. what is and is not RC is the release team
decision. there is no release goal for the removal of python2 so how
can it be release critical? what belongs or doesnt belong in testing
is again the release team decision. so what would it give us to remove
those packages from testing?

as of now, there are still 1800+ bugs opened tagged py2removal, do you
think it's sane to mark them as RC? please also note there are several
bugs missing too (i'm working on figuring them out, and current count
is ~400 still to report, i'll do so when i finished verifying they are
accurate).

I believe it's unthinkable to raise so many bugs to RC at this stage.
remember also there's always a chance we're gonna release python2 with
bullseye, we'll see when we're close to the release.

if we need more visibility, i can extend some of the tools i already
have (f.e. to create the tracking webpage) to tags bugs, add/update
blocks, and/or any other kind of bugs management.

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

Re: [Python-apps-team] pylint3 reverse dependencies.

[Sandro Tosi]

Piotr, please do not hold onto the upload - the reason is still there
it's because it's a cruft package, which will be removed once we fix
dh-python and make pylint conflict with pylint3 (instead of just
provide it), which we currently cant do due to dh-python still
producing the pylint3 dependency.

On Fri, Oct 4, 2019 at 5:42 AM Piotr Ożarowski  wrote:
>
> > Yes this is a known issue and we are currently waiting for an upload
> > of dh-python to avoid automatic replacement of pylint by pylint3 when
> > on python3 before pushing those changes further.
>
> http://ftp.debian.org/debian/dists/unstable/main/Contents-amd64.gz
> still contains pylint3 so I'm waiting with an dh-python upload for now
> --
> GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
>
> ___
> Python-apps-team mailing list
> python-apps-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-apps-team



-- 
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: 2Removal: handling circular dependencies / dropping tests before the binary?

[Sandro Tosi]

> Note that having an unbuildable package in sid for several days, until
> it's updated to a no-py2 version, is perfectly acceptable.

please note that may not be fine with every maintainer. dont just drop
packages without checking rdeps and/or if you know that will make
packages uninstallable/unbuildable (unless you check with the people
taking care of such packages first).

btw sphinx-gallery d-b on pyhton-seaborh has been removed.

-- 
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: Webpage to track py2removal bugs & packages

[Sandro Tosi]

On Sat, Aug 31, 2019 at 2:31 AM Sandro Tosi  wrote:
> i've prepared a small website,
> http://sandrotosi.me/debian/py2removal/index.html, to keep track of
> the bugs user-tagged `py2removal`.

the website will now (from the next push) also check
Testsuite-Triggers field content when producing the rdeps graph.

-- 
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: Re: Bug#920127: Removed package(s) from unstable

[Sandro Tosi]

On Sun, Sep 8, 2019 at 11:26 PM Paul Wise  wrote:
>
> On Mon, Sep 9, 2019 at 4:11 AM Scott Kitterman wrote:
>
> > This was sent to the FTP Team, but it seems like someone with some bandwidth
> > to assist from DPMT/PAPT would be a better audience.  Note that the 
> > removal's
> > already been done, but if someone wants to sponsor a python3 update to the
> > package, they can ping me for a quick trip through New to bring it back.
>
> It seems like a little bit more due diligence is needed before filing 
> removals.

Nope. This package did not see an upload since Aug 2013. it was
orphaned since Jan 2019. Nobody stepped up. It ended up removed.

If the upstream author or a debian packager wants it in debian, it's
easy enough to re-introduce it.

-- 
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: Webpage to track py2removal bugs & packages

[Sandro Tosi]

On Sat, Aug 31, 2019 at 2:31 AM Sandro Tosi  wrote:
> i've prepared a small website,
> http://sandrotosi.me/debian/py2removal/index.html, to keep track of
> the bugs user-tagged `py2removal`.

there was a bug in the script populating that page that's now been
fixed: if a source package had only build-dep on python* packages, but
none of its binary packages did, then the src pkg was missing from the
list.

Now even source packages (with b-deps on python*) are there; there's
currently no reverse-(build-)depends graphs for them; they may be
available one day.

-- 
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: Webpage to track py2removal bugs & packages

[Sandro Tosi]

On Tue, Sep 3, 2019 at 10:11 AM PICCA Frederic-Emmanuel
 wrote:
> I can not find python-pyqtgraph in your list.
>
> It seems to me that this package has reverse dependencies, but the python2 
> binaries where remove..., but this is another problem.

the script that produces that page only checks for open bugs
(usertagged properly); since
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938088 was closed,
it wont appear in the list


--
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: Webpage to track py2removal bugs & packages

[Sandro Tosi]

> Within a given rdeps count it currently has secondary sorting made on
> Bug No. It would polish off the forward deps if they could be used for
> secondary sorting instead (highest number to lowest).  Bonus points for
> making the headers clickable so the reader can choose which secondary
> sorting is most useful (Bug No. vs Binary Pkg vs Maintainer vs # deps)

with the latest update the table is initially sorted by (# rdeps, #
fdeps); i've also made the header clickable, so that you can sort the
table on that column, but it doesnt preserve sorting between clicks
(ie if you click columnA and then columnB, the sorting on cB will
loose entirely the sorting that previously was set on cA, so you cant
click on # fdeps and then #rdeps and expect to return to he initial
sorting).

since i've already all the information there, i was thinking if we
should start posting a status of the rdepends in each bug, would it be
worth the effort? i'm not sure i want to spam too frequently the BTS,
so what would be an acceptable frequency: once a week?  if we want to
pile on this, all the blocks/blockedby bts massaging could be done by
this script i guess?

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

Re: Webpage to track py2removal bugs & packages

[Sandro Tosi]

On Sun, Sep 1, 2019 at 9:54 PM Drew Parsons  wrote:
> Yes, your script counts the dependencies along one direction (rdeps),
> identifying which packages are ready to be de-python2-ised next.
>
> I'm talking about dependencies in the opposite direction, deps not
> rdeps.  Upstream vs downstream.
>
> My question is, of the 844 packages now currently on rdeps=0 and ready
> for processing, which one should be processed first?  Which one will
> free up the largest number of upstream packages?  Which one gives the
> biggest bang for buck?

gothca, i hope.

I've added the number of forward dependencies in the last update to
the webpage; it's not super-accurate (f.e. python dep is counted
twice, due to the nature of how it's produced, > 2.7 < 2.8) but it
should give a general idea of what you asked for

-- 
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: Python 3 transition question

[Sandro Tosi]

> 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).

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

Re: dh-python and pylint

[Sandro Tosi]

On Sat, Aug 31, 2019 at 9:21 AM PICCA Frederic-Emmanuel
 wrote:
>
> Hello,
>
> I am preparing the new spyder package.
> since the removal of pylint3 from the src:pylint.
>
> I need to remove the Build-Depends: pylint3.
>
> Now dh_python3 still produce a pylint3 dependency for the binary packages.
>
> It seems that thsi is hard coded here[0]
>
> Is it a bug of dh-python ?

I've just submitted
https://salsa.debian.org/python-team/tools/dh-python/merge_requests/9
to address this; not sure how quickly it will get merged & released

>
> Cheers
>
> Frederic
>
> [0] 
> https://salsa.debian.org/python-team/tools/dh-python/blob/master/pydist/cpython3_fallback#L2047



-- 
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: Webpage to track py2removal bugs & packages

[Sandro Tosi]

On Sun, Sep 1, 2019 at 1:15 PM Drew Parsons  wrote:
> It could be useful to add another column counting the Dependencies in
> the other direction.
>
> i.e. for all the leaf packages ready for processing, which one should be
> given priority?  Which one has the most impact on Dependencies further
> down the tree?

I'm afraid i dont understand the question, or maybe it's just a
different process than the one i use.

the main idea (behind the webpage) is that you cant remove a package
unless it doesnt have any reverse-dependency: so if the count it's 0,
you can go ahead and remove it.

if it has rdeps, then you need to address them _first-, and that's
where the rdeps graph comes handy, as it tells you the actual
packages.

but what i personally use is a level 4 graph (so up to 4 levels of
reverse depends): say you want to work on pkgA, but it turns out it
has some rdeps, pkg0..8; now, how many rdeps does each of these
packages have? hard to say with only a level=1 graph, as you dont see
further in the deps tree

(the risk it get crazy pretty quickly, in particular with sci
packages, as currently all debian-science tasks packages depend on the
py2 pkgs, if one of them gets pulled in it's hard to read).

Let me know if i can make the webpage more useful for you, i just dont
know how to address your request

-- 
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: Webpage to track py2removal bugs & packages

[Sandro Tosi]

> I definitely think it will be helpful.  Thanks for putting it together.  It's
> the best thing I've seen yet for answering the question of what can we try to
> kill off now.
>
> Please keep it updated.

i set a cron every 2 hours (when the laptop is on)

also added a new column for the Maintainer (not uploaders), it may
help checking "your" packages and/or the one for dpmt/papt

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Webpage to track py2removal bugs & packages

[Sandro Tosi]

Hello,
i've prepared a small website,
http://sandrotosi.me/debian/py2removal/index.html, to keep track of
the bugs user-tagged `py2removal`.

* i'm sure there are bugs
* it's pretty brutal html, but should provide useful information
* it tries to account for crufted binary packages
* it ignores the package if the py2removal bug is closed (that means
you can remove a pkg with rdeps and not be identified by this page)
* since py2removal bugs are against src pkg, the script gets the
binary package and work only on the ones depending on python2 packages
* it's sorted with packages with 0 or few r-deps at the top, which
ideally are packages "easy" to get py2 removed from
* there's a graph too, which gives a more visual representation of the
rdeps; it's currently at level=1 (ie only the target package + the
direct reverse-dependencies are shown), i'll consider expand it to
level=3/4
* for now it's juts a single snapshot; if considered useful i'll to to
keep it updated regularly (but my laptop is not always on anyway)

let me know if you consider it helpful and/or it should include more
information to make it more interesting.

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