Mailing List Archive

Last rites: dev-python/* leaf packages
Fellow devs,

* These packages are (mostly) leaf dev-python/* packages which have no py3 impl
in the ebuild

* Packages not from dev-python/* are preceded by the relevevant dev-python/* pkg
which caused the package to be masked.

* This is just the "tip of the iceberg" of py2 only packages. As such, due to
the sheer number of packages, it is nearly impossible for any one person or
project to address them all.

* Many of these packages are likely not needed, but some will be. If you find a
package that is needed please update/port/fix the ebuild/src to support py3

* This is not a "go fix it or it dies" stance. If you can please assist in
identifying which packages have upstream supported py3 impls please feel free
to ping me to support porting the ebuild.

* There may be false positives. Sorry about that. Feel free to adjust the mask
and remove any py2 only ebuilds (e.g. multiple versions/revisions of ebuilds
and one of them only supports py2)

* Removal in 30 days

Always happy to help/assist in keeping things moving along within Gentoo.

-----

net-misc/trackma
dev-python/inotifyx
dev-python/disqus-python
dev-python/figleaf
dev-python/pysvg
dev-python/sphinxcontrib-ditaa
dev-python/pyrax
dev-python/tgmochikit
dev-python/pyndex
dev-python/nototools
media-fonts/noto-emoji
dev-python/python-mhash
dev-python/guppy
dev-python/dib-utils
dev-python/py-notify
x11-misc/magick-rotation
dev-python/superlance
dev-python/rlcompleter2
dev-python/pylibpcap
dev-python/libextractor-python
dev-python/happydoc
dev-python/irman-python
dev-python/python-recaptcha
dev-python/dirq
dev-python/ropemacs
dev-python/lp_solve
dev-python/stapler
dev-python/flask-dashed
dev-python/buzhug
dev-python/pyao
dev-python/libiscsi-python
dev-python/ushlex
dev-python/hcluster
dev-python/lupy
dev-python/snakefood
dev-python/sqlitecachec
dev-python/supervisor-quick
dev-python/python-cdb
dev-python/fabric
dev-python/foolscap
net-fs/tahoe-lafs
dev-python/pyvtk
dev-python/pycdio
media-sound/whipper
dev-python/hachoir-regex
app-misc/hachoir-subfile
dev-python/pymad
dev-python/audioread
dev-python/pyacoustid
media-sound/beets
dev-python/numdisplay
dev-python/python-fastcgi
dev-python/workerpool
dev-python/eyeD3
media-sound/abcde
media-sound/gpodder
dev-python/py-smbpasswd
dev-python/cherrytemplate
dev-python/python-catcher
dev-python/pystatgrab
dev-python/pp
dev-python/keyczar
dev-python/keyrings_alt
dev-util/Orange
dev-python/python-exconsole
dev-python/ttfquery
dev-python/pyoembed
www-apps/blohg-tumblelog
dev-python/webhelpers
dev-python/optcomplete
dev-python/hcs-utils
dev-python/python-prctl
net-p2p/pybitmessage
dev-python/asciitree
net-misc/irrtree
dev-python/python-pluginloader
dev-vcs/hg-fast-export
dev-python/pychef
dev-python/mwlib-ext
dev-python/vatnumber
dev-python/pyml
dev-python/bicyclerepair
dev-python/cement
app-misc/yworklog
net-misc/pycnb
dev-python/turbolift
dev-python/PyZilla
dev-python/pydvdread
dev-python/m2secret
dev-python/pyPdf
app-text/pdfshuffler
dev-python/hp3parclient
dev-python/clientcookie
dev-python/python-pam
dev-python/python-caja
dev-vcs/rabbitvcs
dev-python/louie
dev-python/graphy
net-analyzer/namebench
dev-python/gdmodule
dev-python/pythonutils
net-nntp/sabnzbd
dev-python/qserve
dev-python/pyifp
dev-python/telarchive
dev-python/XenAPI
dev-python/sudsds
dev-python/webpy
dev-python/slowaes
dev-python/beanstalkc
dev-python/PySensors
dev-python/RecSQL
dev-python/pyclamav
dev-python/pycdf
dev-python/libnatpmp
dev-python/sabyenc
dev-python/weberror
dev-python/sancho
dev-python/jonpy
dev-python/pyelemental
dev-python/sclapp
dev-python/pynag
dev-python/newt_syrup
dev-python/stripogram
dev-python/anyvc
dev-python/simplesettings
dev-python/pykota
net-print/pykota
dev-python/ropeide
dev-python/pycryptopp
net-fs/tahoe-lafs
dev-python/piddle
dev-python/python-oembed
dev-python/log4py
dev-python/htmlgen
dev-python/pyamf

--
Cheers,
Aaron
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On 05/12/19 00:15, Aaron Bauman wrote:
> Fellow devs,
<snip>
> dev-python/sqlitecachec
> dev-python/supervisor-quick
> dev-python/python-cdb
> dev-python/fabric
^ https://github.com/mathiasertl/fabric/ is a fork of fabric for py3.4+
FYI. Also on PyPi at https://pypi.org/project/Fabric3/.
> dev-python/foolscap
> net-fs/tahoe-lafs
> dev-python/pyvtk
<snip>

HTH,
veremitz/Michael.
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On Thu, Dec 05, 2019 at 12:28:04AM +0000, Michael 'veremitz' Everitt wrote:
> On 05/12/19 00:15, Aaron Bauman wrote:
> > Fellow devs,
> <snip>
> > dev-python/sqlitecachec
> > dev-python/supervisor-quick
> > dev-python/python-cdb
> > dev-python/fabric
> ^ https://github.com/mathiasertl/fabric/ is a fork of fabric for py3.4+
> FYI. Also on PyPi at https://pypi.org/project/Fabric3/.
> > dev-python/foolscap
> > net-fs/tahoe-lafs
> > dev-python/pyvtk
> <snip>
>
> HTH,
> veremitz/Michael.
>

Ah, you found a false positive as well. Fixing it up now.

--
Cheers,
Aaron
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On 05.12.2019 01:15, Aaron Bauman wrote:
> dev-python/nototools
> media-fonts/noto-emoji

^ these two recent-ish gained python3 support upstream in a new released
version
Re: Last rites: dev-python/* leaf packages [ In reply to ]
Hi,

On 2019-12-05 01:15, Aaron Bauman wrote:
> * Removal in 30 days

Why? I understand that Py2 will reach EOL upstream status but we all
know that Py2 will *not* disappear and stop working in 26 days...

There's no reason to mask/remove currently known working software.

net-nntp/sabnzbd is a perfect example. Up to date in repository and working.


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On Thu, Dec 05, 2019 at 03:56:05AM +0100, Thomas Deutschmann wrote:
> Hi,
>
> On 2019-12-05 01:15, Aaron Bauman wrote:
> > * Removal in 30 days
>
> Why? I understand that Py2 will reach EOL upstream status but we all
> know that Py2 will *not* disappear and stop working in 26 days...
>
> There's no reason to mask/remove currently known working software.
>
> net-nntp/sabnzbd is a perfect example. Up to date in repository and working.

Are you volunteering to maintain it or open an upstream bug and askthem
to move to py3?

I tend to think that we should either get py2 only software to move to
py3 or remove it.

William
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On 2019-12-05 04:06, William Hubbs wrote:
> On Thu, Dec 05, 2019 at 03:56:05AM +0100, Thomas Deutschmann wrote:
>> On 2019-12-05 01:15, Aaron Bauman wrote:
>>> * Removal in 30 days
>>
>> Why? I understand that Py2 will reach EOL upstream status but we all
>> know that Py2 will *not* disappear and stop working in 26 days...
>>
>> There's no reason to mask/remove currently known working software.
>>
>> net-nntp/sabnzbd is a perfect example. Up to date in repository and working.

First, this was just an example.

For sabnzbd I know that upstream is working on Py3 support. It will
happen somewhere in 2020...

I expect this for most software still in use.

My point was a general note: I don't understand why we should rush and
kick out software without Py3 support *yet* when Py2 is still a thing.
Sure, we will reach the point when Py2 is only needed by 1-2 packages
and at this point we can start discussing to drop them including entire
Py2 support. But this will take 1-2 years...

I mean: OpenSSL-1.0.2x will go EOL on 2019-12-31... I don't see us
masking <openssl-1.1.x before that date or even months later. It will
still be around for quite some time...

And I think same is true for Py2.

There's also an important difference: Thanks to our Python
implementation, you can set your system to use Py3 by default for
everything but still keep a slotted Py2 around for stuff which wasn't
ported yet. That's not possible for OpenSSL-1.0.2x for example...


> Are you volunteering to maintain it or open an upstream bug and askthem
> to move to py3?

...and sometimes I am also just a user. I cannot maintain all software I
use :-)


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On 05.12.19 01:15, Aaron Bauman wrote:
> Fellow devs,

[...]

> net-misc/trackma
> dev-python/inotifyx
> dev-python/disqus-python
> dev-python/figleaf
> dev-python/pysvg

a python-3 version is available at:
https://github.com/alorence/pysvg-py3
https://pypi.org/project/pysvg-py3/

> dev-python/sphinxcontrib-ditaa
> dev-python/pyrax
> dev-python/tgmochikit

[...]

Best regards,
Poncho
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On Thu, 2019-12-05 at 03:56 +0100, Thomas Deutschmann wrote:
> Hi,
>
> On 2019-12-05 01:15, Aaron Bauman wrote:
> > * Removal in 30 days
>
> Why? I understand that Py2 will reach EOL upstream status but we all
> know that Py2 will *not* disappear and stop working in 26 days...
>
> There's no reason to mask/remove currently known working software.
>

Yes, there is. Not saying about any particular package out there but
the Python team is *overwhelmed*. We can't reasonably be expected to
maintain 1200+ packages, many of them requiring a lot of work.

It's easy to claim everything is all right without actually working
on it. Many of those packages may not pose problems in the next weeks.
Some of them probably already take part in the big 'target mishap' when
their dependencies dropped py2 support, and more will in the coming
weeks, months.

Now imagine that 500+ packages are depending on pytest that doesn't
support py2 anymore. And that number is probably far smaller than
reality because a lot of packages are bad quality and don't run tests
at all.

You people need to start thinking of terms of real benefit to users.
Keeping old, unmaintained, semi-broken packages has little benefit to
users. Quadruplicating maintenance burden effectively harms *active*
packages, and that is much more painful to users.

Do you think we'd be stuck with unmaintained Python 3.6 in stable if
people actively kicked stuff we can't maintain? Do you think we'd be
stuck with Python 3.7 packages being *unkeyworded* on almost all arches?

--
Best regards,
Micha? Górny
Re: Last rites: dev-python/* leaf packages [ In reply to ]
Hi!

On Wed, 04 Dec 2019, Aaron Bauman wrote:
> dev-python/eyeD3
> media-sound/abcde
> media-sound/gpodder

FWIW, eyeD3 has a Py3 (only!) version available. Since abcde is a
shell script that just calls the eyeD3 binary, the API changes
don't matter. And gpodder is Py3 only itself, so it can't have
used eyeD3 as a library. Also, this comment in
gpodder-3.10.5.ebuild:

# As in Fedora: re-enable
# >=dev-python/eyeD3-0.7[${PYTHON_USEDEP}] and
# ipod? ( media-libs/libgpod[python,${PYTHON_USEDEP}] ) once they
# support python3

I don't have an iPod, so I can't really test gpodder. But as it
is, it doesn't *actually* need eyeD3, and thus can be unmasked.

I'll see if I can bump eyeD3 to Py3 on the weekend, and clean it
up as well (it now has different deps etc). It do it now, but
properly testing abcde requires access to a CD drive and I don't
have that 'til the weekend.

Best,
Tobias



--
Sent from aboard the Culture ship
GOU (Abominator class) Falling Outside The Normal Moral Constraints
Re: Last rites: dev-python/* leaf packages [ In reply to ]
Am Donnerstag, 5. Dezember 2019, 01:15:48 CET schrieb Aaron Bauman:
> dev-python/pycdio

Has Python 3 support since 2.1 (released in August this year). Developed by libcdio itself.

> app-text/pdfshuffler

Was last rited a few day ago. As I said, pdfarranger (https://github.com/jeromerobert/pdfarranger) seems to be the modern follow up project.

Gerion
Re: Last rites: dev-python/* leaf packages [ In reply to ]
On Wed, 2019-12-04 at 19:15 -0500, Aaron Bauman wrote:
> * Removal in 30 days
>


IMHO masking with unfixed, or much later, removal date will better help
achieve your goal: You are making your point by having them masked so
that it will make enough noise for interested people to understand py2
only is not a thing anymore.

We already see a lot of "false positives", there are probably packages
that just work but are lacking attention. If after a longer time those
packages are still not fixed, you can probably safely remove them with
the "meh, nobody cares anyway" reason and not even bother having to
check hundreds (?) of packages yourself. The 30 days is usually a
guideline for packages that have known issues but seems a bit short for
checking if someone cares about a package using a deprecated but
working python.


Also, your list is missing dev-ros/* which is py2 only. I hope I'll be
able to update them soon, last time I tried I failed miserably though
since the whole stack is really python-single style so that one broken
package with py3 causes the whole stack to be py2...


Alexis.