| Summary: | Big Python 3.6 cleanup | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aklhfex, gotterdammerung, hlein, jruohonen, newchief, quentin, sping, thomas.bettler, treecleaner |
| Priority: | Normal | Keywords: | PMASKED, PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=704136 https://github.com/gentoo/gentoo/pull/14968 https://bugs.gentoo.org/show_bug.cgi?id=713096 https://github.com/gentoo/gentoo/pull/15180 https://bugs.gentoo.org/show_bug.cgi?id=829598 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Deadline: | 2020-04-06 | ||
| Attachments: |
dev-python/pyopencl-2019.1.2.ebuild
dev-python/jpype: updated, added PYTHON_COMPAT=python3_7, added USE=test dev-python/cgroup-utils-0.8.ebuild: Bump version and update for python3_7 |
||
|
Description
Michał Górny
2020-03-07 16:27:17 UTC
dev-python/CacheControl dev-python/ImageHash dev-python/ReParser dev-python/aadict dev-python/abstract_rendering dev-python/aioeventlet dev-python/aiotest dev-python/amqplib dev-python/anyjson dev-python/asciimatics dev-python/asset dev-python/atom dev-python/batinfo dev-python/bcolz dev-python/beaker dev-python/biplist dev-python/blaze dev-python/bpython dev-python/cgroup-utils dev-python/chameleon dev-python/colander dev-python/colorful dev-python/columnize dev-python/common dev-python/crumbs dev-python/cssselect2 dev-python/curtsies dev-python/cx_Freeze dev-python/d2to1 dev-python/datashape dev-python/deform dev-python/distlib dev-python/django-appconf dev-python/django-baker dev-python/django-crispy-forms dev-python/django-discover-runner dev-python/django-grappelli dev-python/django-haystack dev-python/django-nose dev-python/django-picklefield dev-python/django-recaptcha dev-python/django-select2 dev-python/django-tinymce dev-python/dogpile-core dev-python/dynd-python dev-python/embedly dev-python/envoy dev-python/fedmsg dev-python/flask-admin dev-python/flask-peewee dev-python/flask-pymongo dev-python/flask-socketio dev-python/flask-uploads dev-python/flipflop dev-python/formencode dev-python/fudge dev-python/geoalchemy2 dev-python/geopy dev-python/gevent-socketio dev-python/gitlabform dev-python/globre dev-python/glymur dev-python/hiredis dev-python/hiro dev-python/httreplay dev-python/husl dev-python/hvac dev-python/influxdb dev-python/intelhex dev-python/into dev-python/ipcalc dev-python/iso3166 dev-python/iso_639 dev-python/jog dev-python/jpype dev-python/jsmin dev-python/json-rpc dev-python/json-tools dev-python/keepassx dev-python/kitchen dev-python/libzilla dev-python/locustio dev-python/mailmanclient dev-python/meteor-ejson dev-python/mimerender dev-python/mmh3 dev-python/mockldap dev-python/multipledispatch dev-python/netmiko dev-python/nltk dev-python/nosehtmloutput dev-python/odo dev-python/passwordmeter dev-python/pdb-clone dev-python/pdoc dev-python/peppercorn dev-python/pgpdump dev-python/pillowfight dev-python/placefinder dev-python/prettyprinter dev-python/prometheus_flask_exporter dev-python/pxml dev-python/py-lz4framed dev-python/py2neo dev-python/pycanberra dev-python/pycipher dev-python/pycmd dev-python/pycobertura dev-python/pydot-ng dev-python/pyee dev-python/pyev dev-python/pyfeyn dev-python/pyfiglet dev-python/pygcrypt dev-python/pygeocoder dev-python/pyhcl dev-python/pykka dev-python/pymtp dev-python/pynzb dev-python/pyopencl dev-python/pyphen dev-python/pyprof2calltree dev-python/pyshark dev-python/pysnmp-apps dev-python/pysnmp-mibs dev-python/pysolr dev-python/pystache dev-python/pytest-arraydiff dev-python/pytest-cython dev-python/pytest-isort dev-python/pytest-mpl dev-python/python-afl dev-python/python-cluster dev-python/python-ddp dev-python/python-discid dev-python/python-ebtables dev-python/python-engineio dev-python/python-hpilo dev-python/python-meteor dev-python/python-otrs dev-python/python-scsi dev-python/python-socketio dev-python/python-twitter dev-python/python-uinput dev-python/pythonmagick dev-python/pyx dev-python/pyzor dev-python/rackspace-monitoring dev-python/readlike dev-python/redis-py-cluster dev-python/regendoc dev-python/ropemode dev-python/schedule dev-python/schema dev-python/scp dev-python/seaborn dev-python/setuptools_hg dev-python/simplekv dev-python/slackclient dev-python/spark-parser dev-python/sphinx-better-theme dev-python/sphinxcontrib-googleanalytics dev-python/sphinxcontrib-programoutput dev-python/tempest-lib dev-python/testify dev-python/tinycss2 dev-python/tlslite dev-python/tpg dev-python/translationstring dev-python/trollius dev-python/twitter dev-python/twython dev-python/uhashring dev-python/uncompyle6 dev-python/venusian dev-python/versiontools dev-python/vulture dev-python/weasyprint dev-python/ws4py dev-python/wsgiintercept dev-python/wtf-peewee dev-python/xdis dev-python/zc-buildout www-apps/nikola I have taken care of dev-python/bpython now. I would like to get off the list: - (dev-python/vulture) - www-apps/nikola Getting nikola on >=3.7 is not a five minute job and I appreciate help with it. I have packages on crocket-overlay that use dev-python/d2to1 and dev-python/pyfiglet. pyfiglet works with python 3.7. I am also using d2to1 with python 3.7 on my system. dev-python/colour is needed by i3pystatus, but colour is sadly not compatible with python 3.7 Correction. dev-python/colour belongs to my overlay. I enabled python 3.7 in dev-python/colour::crocket-overlay. dev-python/i3pystatus::crocket-overlay depends on dev-python/colour::crocket-overlay which in turn depends on dev-python/d2to1::gentoo. dev-python/termdown::crocket-overlay optionally depends on dev-python/pyfiglet::gentoo. dev-python/pyzor is an end-user program worth having to help fighting against e-mail spam. (In reply to crocket from comment #6) > dev-python/i3pystatus::crocket-overlay depends on > dev-python/colour::crocket-overlay which in turn depends on > dev-python/d2to1::gentoo. > > dev-python/termdown::crocket-overlay optionally depends on > dev-python/pyfiglet::gentoo. Sounds like you could move them to ::crocket-overlay, if people already need to use that overlay for the other packages. (In reply to Tomáš Mózes from comment #7) > dev-python/pyzor is an end-user program worth having to help fighting > against e-mail spam. Ok, thanks. I'll unmask it and move it to the correct category. (In reply to Sebastian Pipping from comment #2) > I have taken care of dev-python/bpython now. By the way, does that package have any advantage over IPython? From the description, it seems similar. dev-python/seaborn has a couple new versions out which don't have ebuilds yet (0.9.1 and 0.10.0, see https://seaborn.pydata.org/whatsnew.html). The latest version, at least, is reportedly compatible with Python 3.6+. Would a version bump be enough to get this off the list for removal? Of course if there's nothing else in Portage that depends on Seaborn and you'd rather just make people install it through pip, I find that reasonable as well. > (In reply to Tomáš Mózes from comment #7)
> > dev-python/pyzor is an end-user program worth having to help fighting
> > against e-mail spam.
>
> Ok, thanks. I'll unmask it and move it to the correct category.
Thanks
(In reply to Tomáš Mózes from comment #11) > > (In reply to Tomáš Mózes from comment #7) > > > dev-python/pyzor is an end-user program worth having to help fighting > > > against e-mail spam. > > > > Ok, thanks. I'll unmask it and move it to the correct category. > > Thanks It's now mail-filter/pyzor. (In reply to David Zaslavsky from comment #10) > dev-python/seaborn has a couple new versions out which don't have ebuilds > yet (0.9.1 and 0.10.0, see https://seaborn.pydata.org/whatsnew.html). The > latest version, at least, is reportedly compatible with Python 3.6+. Would a > version bump be enough to get this off the list for removal? > > Of course if there's nothing else in Portage that depends on Seaborn and > you'd rather just make people install it through pip, I find that reasonable > as well. Yes, version bump + py3.[78] testing would be sufficient. (In reply to Michał Górny from comment #9) > (In reply to Sebastian Pipping from comment #2) > > I have taken care of dev-python/bpython now. > > By the way, does that package have any advantage over IPython? From the > description, it seems similar. I'm using bpython and would very much like to have it remain available in the tree. An advantage I find over IPython is the much lower amount of packages it pulls in when emerged. With IPython I need a web server, a message queue, possibly Qt5… Although the in-tree package is still based on Python 3.6, bpython works fine with Python 3.{7,8} as far as I can tell. I even have an ebuild that's PYTHON_COMPAT-bumped: https://github.com/laomaiweng/laomaiweng-overlay/blob/master/dev-python/bpython/bpython-0.18-r1.ebuild Also, upstream still looks alive: https://github.com/bpython/bpython/ and https://github.com/bpython/curtsies both have recent (< 2 months) changes. I'm willing to proxy-maintain this package if needed. :) Just let me tell you that the following packages install just fine under Python3.8 (from my local overlay) I think that PYTHON_TARGET should be rethought. For recent versions of Python (3.7 and 3.8) only very very few packages which are working under a previous Python3.x version fail under the new version. Thus, PYTHON_TARGET should be interpreted as minimum version under which the package is working. Here packages from my local overlay dev-python/aadict dev-python/bcolz dev-python/CacheControl dev-python/colorful dev-python/columnize dev-python/cssselect2 dev-python/cx_Freeze dev-python/datashape dev-python/dynd-python dev-python/envoy dev-python/formencode dev-python/geopy dev-python/globre dev-python/ImageHash dev-python/into dev-python/jog dev-python/keepassx dev-python/mmh3 dev-python/multipledispatch dev-python/nltk dev-python/pdb-clone dev-python/prettyprinter dev-python/pycipher dev-python/pycmd dev-python/pygcrypt dev-python/pykka dev-python/py-lz4framed dev-python/pymtp dev-python/pyopencl dev-python/pyphen dev-python/pyprof2calltree dev-python/python-cluster dev-python/pythonmagick dev-python/python-scsi dev-python/pyx dev-python/readlike dev-python/ReParser dev-python/schedule dev-python/schema dev-python/seaborn dev-python/spark-parser dev-python/tinycss2 dev-python/tpg dev-python/translationstring dev-python/uncompyle6 dev-python/vulture dev-python/weasyprint dev-python/xdis (In reply to Helmut Jarausch from comment #14) > Just let me tell you that the following packages install just fine under > Python3.8 > (from my local overlay) > I think that PYTHON_TARGET should be rethought. > For recent versions of Python (3.7 and 3.8) only very very few packages > which are working under a previous Python3.x version fail under the new > version. > Thus, PYTHON_TARGET should be interpreted as minimum version under which the > package is working. > > Here packages from my local overlay > dev-python/aadict > [...] > dev-python/xdis That is definitely an exaggeration: 3.6 -> 3.7 caused tons of fallout with the StopIteration change. I've had to fix countless packages to make them work on 3.7. This is *exactly* why we need PYTHON_COMPAT, because python changes are too insidious for implicit impl targetting. (In reply to Helmut Jarausch from comment #14) > Just let me tell you that the following packages install just fine under > Python3.8 'Install just fine' flashes the warning light in my head. So, how did you *exactly* test them? What is the resulting code coverage? I would like to remind you that Python is a language that changes *runtime* behavior, and you can't know whether something really works unless you actually test it, and I mean test every single line of code, in every single branch, including error handling. The problem with pip being that only pip --user is supported afaict. Where all the current python modules can be installed as generic available modules. Created attachment 617490 [details] dev-python/pyopencl-2019.1.2.ebuild dev-python/pyopencl is still actively developed and in use for GPGPU tasks. upstream supports python3.7+ see https://pypi.org/project/pyopencl/#files I propose to - bump to dev-python/pyopencl-2019.1.2 (attached) - depends on >=pytools-2017.5 => thus bump to dev-python/pytools-2020.1 - depends on pybind11 => unmask dev-python/pybind11 > (In reply to David Zaslavsky from comment #10)
> > dev-python/seaborn has a couple new versions out which don't have ebuilds
I also use dev-python/seaborn as well as dev-python/nltk. While I didn't look deep, NLTK's maintainers seem to announce 3.7 (and 3.8) support. They just made a new release in March (version 3.5)
In general, I'd like to see these two maintained in Gentoo already because they are often used in science/education/etc.
Without dev-python/python-discid some functionality (Lookup CD) is not available in media-sound/picard. (In reply to Thomas Lachmann from comment #20) > Without dev-python/python-discid some functionality (Lookup CD) is not > available in media-sound/picard. I second that: We should get dev-python/python-discid off the list. I still use py2neo. There is now a version 4.3.0 that is 3.6+-compatible: https://pypi.org/project/py2neo/ https://py2neo.org/v4/ I do not know how difficult it would be to update the ebuild. It seems that new dependencies not in Gentoo are present: https://pypi.org/project/neotime/ https://pypi.org/project/neobolt/ (In reply to Thomas Lachmann from comment #20) > Without dev-python/python-discid some functionality (Lookup CD) is not > available in media-sound/picard. This one looks trivial, I'll rescue it today. Please don't remove dev-python/seaborn, I'm still using it for visualization of benchmark results. dev-python/geopy v1.21.0 According to https://pypi.org/project/geopy/ it supports newer python that just v3.6: "geopy is tested against CPython (versions 2.7, 3.4, 3.5, 3.6, 3.7, 3.8), PyPy, and PyPy3. geopy does not and will not support CPython 2.6." Should i open a separate version bump request? I would prefer leaving dev-python/pykka in portage as I use it. The current upstream version 2.0.2 is working with python 3.7 and the official website says "Pykka works with CPython 3.6+ and PyPy 3.6+" which would indicate support for 3.7 if I interpret it correctly. I can provide modified ebuild for this version - which is only a crudely changed original ebuild. > (In reply to David Zaslavsky from comment #10)
> > dev-python/seaborn has a couple new versions out which don't have ebuilds
> > yet (0.9.1 and 0.10.0, see https://seaborn.pydata.org/whatsnew.html). The
> > latest version, at least, is reportedly compatible with Python 3.6+. Would a
> > version bump be enough to get this off the list for removal?
> >
> > Of course if there's nothing else in Portage that depends on Seaborn and
> > you'd rather just make people install it through pip, I find that reasonable
> > as well.
>
> Yes, version bump + py3.[78] testing would be sufficient.
For the record, I'm trying to bump dev-python/seaborn to 0.10.0 with python 3.7 support at the moment.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=350859e63ea65fe812e1d677ff65f89699bdabb4 commit 350859e63ea65fe812e1d677ff65f89699bdabb4 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2020-03-09 18:23:41 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2020-03-09 18:27:09 +0000 dev-python/seaborn: 0.10.0 + EAPI 7 + py37 Bug: https://bugs.gentoo.org/704136 Bug: https://bugs.gentoo.org/711808 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-2.3.92, Repoman-2.3.20 dev-python/seaborn/Manifest | 1 + dev-python/seaborn/seaborn-0.10.0.ebuild | 39 ++++++++++++++++++++++++++++++++ profiles/package.mask | 1 - 3 files changed, 40 insertions(+), 1 deletion(-) As previously mentioned geopy does support v3.7. A separate ticket for this already exists. https://bugs.gentoo.org/697436 (In reply to ota from comment #26) > I would prefer leaving dev-python/pykka in portage as I use it. Rescued. I've also started fixing dependencies of www-apps/nikola. However, I'm going to need help with that. dev-python/PyRSS2Gen's test suite is entirely broken on py3. app-doc/ghp-import doesn't seem to have tests in the first place. dev-python/chameleon is used for OpenTTD GRF (mods) development. It's reported to work with Python 2.7. See also https://www.tt-forums.net/viewtopic.php?f=31&t=70989&p=1229766#p1229766 (In reply to Leif Biberg Kristensen from comment #31) > dev-python/chameleon is used for OpenTTD GRF (mods) development. It's > reported to work with Python 2.7. > > See also > https://www.tt-forums.net/viewtopic.php?f=31&t=70989&p=1229766#p1229766 It's reported to work with Python 3.7 as well as 3.8. The Chameleon project page at https://pypi.org/project/Chameleon/ reports that support for Python 3,8 was added in 2018. (In reply to Leif Biberg Kristensen from comment #32) > (In reply to Leif Biberg Kristensen from comment #31) > > dev-python/chameleon is used for OpenTTD GRF (mods) development. It's > > reported to work with Python 2.7. > > > > See also > > https://www.tt-forums.net/viewtopic.php?f=31&t=70989&p=1229766#p1229766 > > It's reported to work with Python 3.7 as well as 3.8. > > The Chameleon project page at https://pypi.org/project/Chameleon/ reports > that support for Python 3,8 was added in 2018. Please bump package to current version 3.6.2. Version 2.25 is ancient. I also find dev-python/nltk useful. As other comments have said, it appears to still be active upstream. If it was in need of a maintainer I could probably proxy-maintain it, since the alternative would be keeping it alive in my internal overlay. I do not yet have any boxes with >=python3.7, but I will have to change that soon anyway. (In reply to Hank Leininger from comment #34) > I also find dev-python/nltk useful. As other comments have said, it appears > to still be active upstream. > > If it was in need of a maintainer I could probably proxy-maintain it, since > the alternative would be keeping it alive in my internal overlay. I do not > yet have any boxes with >=python3.7, but I will have to change that soon > anyway. I'm working on updating NLTK but it's going to take a while to get the tests working. For dev-python/cgroup-utils - I've filed an upstream bug report at: https://github.com/peo3/cgroup-utils/issues/11 I find this package useful as it emulates some of what systemd does on an OpenRC system. e.g. # cgutil tree or # cgutil stats However there is some broken functionality with 'pgrep' and 'top' If anyone could suggest an alternative, it would be appreciated. The schedule package has been useful on a couple of recent projects (enough for me to maintain an extended fork even) so work and bugs collided and I took care of that one: commit ec21af3c3b05fb4b9a8b9191e956a737d05714d8 (HEAD -> master, origin/master, origin/HEAD) Author: Stephen Arnold <nerdboy@gentoo.org> Date: Thu Mar 12 20:10:16 2020 -0700 dev-python/schedule: update to latest upstream release * all python versions through nightly tested in travis * used extensively on current keywords (both glibc and musl) Package-Manager: Portage-2.3.67, Repoman-2.3.17 sorry my bug etiquette does suck lately :/ I wold like to keep the dot language python bindings (pydot) and the twitter bindings (In reply to Alessandro Barbieri from comment #38) > I wold like to keep the dot language python bindings (pydot) and the twitter > bindings dev-python/twitter or dev-python/tweepy? ..or twython? (In reply to Alessandro Barbieri from comment #38) > I wold like to keep the dot language python bindings (pydot) and the twitter > bindings You seems to refer to dev-python/pydot-ng. The upstream repository at https://github.com/pydot/pydot-ng/ has been archive and had the latest commit on master on Nov 19, 2018: It's dead. I find these five Python graphviz packages in Gentoo: dev-python/pydot -- dead(?) 2018-12-12 dev-python/pydot-ng -- dead 2019-11-19 dev-python/pydotplus -- dead 2014-12-09 dev-python/graphviz -- alive dev-python/pygraphviz -- dead(?) 2019-04-12 Why do you want to keep using dev-python/pydot-ng in 2020? Created attachment 618680 [details]
dev-python/jpype: updated, added PYTHON_COMPAT=python3_7, added USE=test
I find dev-python/jpype very useful for reverse engineering android applications.
Here is an updated ebuild for python3_7 with added USE=test.
Tests pass here on amd64.
dev-python/intelhex is a dependency of sci-electronics/tinyprog (in my overlay), a tool for programming TinyFPGA boards. I've tried tweaking the ebuild to say that it should allow building on Python 3.7, but with no luck so far (builds for 2.7 & 3.6). I think dev-python/flask-admin is worth having. It allows you to create good quality web interfaces for managing data relatively easily. I've submitted a PR with an updated ebuild: https://github.com/gentoo/gentoo/pull/14968 I'll bump anyjson https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=437ad4be1cb7309c1f4c54edd5fd0b3381e1016a removed dev-python/sphinxcontrib-programoutput from the list with https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db423c41092fd9b0995ea6357b7ea5a120b29bad +1 for keeping dev-python/intelhex if at all possible because I also need it, as a dependency of the tools for the SoloKeys FIDO2 security keys (https://solokeys.com/, https://github.com/solokeys/solo). Updating it to work with python3.7 doesn't look like a huge job and I'll add it to my massive long todo list... (don't hold your breath though!) dev-python/jsmin is useful to me in some internal projects. It looks like upstream is not very active, but have marked python 3.7 as supported (in their .travis.yml file but not their setup.py?). As with dev-python/nltk, I volunteer to proxy-maintain jsmin (badly?) if needed. I find dev-python/pyprof2calltree very useful personally. In addition it looks like there is a newer version of that package published with python 3.7, although I haven't tested it myself. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b7194c01559ce4f7c1052cfe01d23570cc0825b2 commit b7194c01559ce4f7c1052cfe01d23570cc0825b2 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2020-03-19 03:20:37 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2020-03-19 03:22:37 +0000 dev-python/pyprof2calltree: 1.4.4 + EAPI 7 + py3[78] Bug: https://bugs.gentoo.org/711808 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-2.3.92, Repoman-2.3.20 dev-python/pyprof2calltree/Manifest | 1 + .../pyprof2calltree/pyprof2calltree-1.4.4.ebuild | 19 +++++++++++++++++++ profiles/package.mask | 1 - 3 files changed, 20 insertions(+), 1 deletion(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=be8e7594c4887aae23be3790e13423bb242acf44 commit be8e7594c4887aae23be3790e13423bb242acf44 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-03-19 06:37:13 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-03-19 06:40:40 +0000 dev-python/jsmin: Modernize, py3.{7,8} Bug: https://bugs.gentoo.org/711808 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-python/jsmin/jsmin-2.2.2.ebuild | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) dev-python/scp has a significantly newer upstream version which includes Python 3.7 in it's .travis.yml file (but not setup.py). Unfortunately neither Github nor PyPy seem to have the results of running the tests (with any Python version). Should a new version ebuild go here or on a new bug? This package is still the most widely documented way of automating SCP file transfers (including embedded systems which don't support sftp) in python scripts (and much nicer than shelling out to the scp binary!). +1 for keeping dev-python/intelhex. I use it in a tool that flashes firmware to microcontrollers. Please keep hiredis. It's a preferred requirement of aioredis, which I use for my own projects. The version in the tree is old though, newer versions support newer python versions. dev-python/zc-buildout is useful as a build tool. I have an ebuild zc-buildout-2.13.3.ebuild that works with python-3.7 and re-enables tests (previously restricted). I'd like to keep dev-python/pyopencl in portage - is there anything restraining to update & drop p.mask? (https://github.com/gentoo/gentoo/pull/15040) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=39da6a6d940c8caf8673042506a97d01d8508df6 commit 39da6a6d940c8caf8673042506a97d01d8508df6 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-03-25 07:05:06 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-03-25 07:10:47 +0000 Unmask dev-python/pysnmp-apps dev-python/pysnmp-mibs Signed-off-by: Jeroen Roovers <jer@gentoo.org> Bug: https://bugs.gentoo.org/711808 Signed-off-by: Jeroen Roovers <jer@gentoo.org> profiles/package.mask | 2 -- 1 file changed, 2 deletions(-) Created attachment 626400 [details] dev-python/cgroup-utils-0.8.ebuild: Bump version and update for python3_7 Received response from upstream at: https://github.com/peo3/cgroup-utils/issues/11 ================== At least cgroup-utils 0.8 can work with python 3.7. So I guess updating the package in the Gentoo package repository to 0.8 with modifying the ebuild file as PYTHON_COMPAT=( python3_7 ) resolve the issue? ================== It builds and functions properly. I'll have a closer look at dev-python/cgroup-utils now. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10233b368e888c075f84dd3b673c70dd009e7cff commit 10233b368e888c075f84dd3b673c70dd009e7cff Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2020-03-27 14:58:23 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2020-03-27 15:02:40 +0000 dev-python/cgroup-utils: 0.8 + EAPI 7 + tests + py3[78] Bug: https://bugs.gentoo.org/711808 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-2.3.92, Repoman-2.3.20 dev-python/cgroup-utils/Manifest | 1 + dev-python/cgroup-utils/cgroup-utils-0.8.ebuild | 29 ++++++++++++++++++++++ .../files/cgroup-utils-0.8-tests-builddir.patch | 25 +++++++++++++++++++ .../files/cgroup-utils-0.8-tests-mountpoint.patch | 25 +++++++++++++++++++ profiles/package.mask | 1 - 5 files changed, 80 insertions(+), 1 deletion(-) If I were to submit a PR for an up-to-date version of dev-python/influxdb, would that be enough to save it from the chopping block? Upstream claims that 3.7 is a supported and tested Python version. It should be, provided that it turns out to work ;-). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1f07b48e5fceba9caa11ac5b8fd9b4da96033e5 commit e1f07b48e5fceba9caa11ac5b8fd9b4da96033e5 Author: t0b3 <thomas.bettler@gmail.com> AuthorDate: 2020-03-22 08:06:45 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-03-30 17:43:59 +0000 dev-python/pyopencl: bump to 2019.1.2 Bug: https://bugs.gentoo.org/712672 Bug: https://bugs.gentoo.org/711808 Closes: https://bugs.gentoo.org/712680 Signed-off-by: t0b3 <thomas.bettler@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/15040 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-python/pyopencl/Manifest | 1 + dev-python/pyopencl/pyopencl-2019.1.2.ebuild | 56 ++++++++++++++++++++++++++++ profiles/package.mask | 1 - 3 files changed, 57 insertions(+), 1 deletion(-) (In reply to Michał Górny from comment #64) > It should be, provided that it turns out to work ;-). https://github.com/gentoo/gentoo/pull/15180 then. Please don't remove dev-python/pyee. The Pentoo overlay still uses it for their own ebuilds. gnome-extra/evolution-data-server-3.34.4 is only python3_6 but would compile with python3_7 I tested (not tested functionality with python3_7) Also, please don't remove the following few packages: dev-python/biplist dev-python/d2to1 dev-python/django-appconf dev-python/django-picklefield dev-python/ipcalc dev-python/mimerender dev-python/mockldap dev-python/py2neo dev-python/pystache dev-python/pyx dev-python/simplekv dev-python/tlslite The Pentoo overlay still depend on them. Then Pentoo should take them and maintain them themselves. You're requesting a lot of work from us to maintain a Gentoo fork. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f15a526591bfd4870dfa71ccc12869606d0ffda9 commit f15a526591bfd4870dfa71ccc12869606d0ffda9 Author: Mikle Kolyada <zlogene@gentoo.org> AuthorDate: 2020-04-06 05:45:13 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2020-04-06 05:45:13 +0000 dev-python/uncompyle6: remove last-rited pkg Closes: https://bugs.gentoo.org/711808 Signed-off-by: Mikle Kolyada <zlogene@gentoo.org> dev-python/uncompyle6/Manifest | 1 - dev-python/uncompyle6/metadata.xml | 16 ---------- dev-python/uncompyle6/uncompyle6-2.10.1.ebuild | 43 -------------------------- 3 files changed, 60 deletions(-) |