[gentoo-dev] Last rites: dev-util/kdevelop-clang-tidy
# Andreas Sturmlechner (2020-01-12) # Merged into dev-util/kdevelop months ago, unusable standalone # Removal in 10 days. dev-util/kdevelop-clang-tidy signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: kde-misc/plasma-redshift-control
# Andreas Sturmlechner (2020-01-12) # Unmaintained upstream and redundant. Use Night Color functionality built # into Plasma 5.17 instead, without needing x11-misc/redshift. # Removal in 30 days. kde-misc/plasma-redshift-control signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: media-sound/kaudiocreator
# Andreas Sturmlechner (2020-01-12) # Unmaintained upstream and redundant. Use media-sound/audex instead. # Removal in 30 days. media-sound/kaudiocreator signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-python/ordereddict
# Michał Górny (2020-01-12) # Backport to Python 2.4 - 2.6. Not needed by anything. # Removal in 30 days. Bug #705256. dev-python/ordereddict -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-libs/libcxxrt
# Michał Górny (2020-01-12) # libcxxrt is no longer maintained upstream. It used to be needed to # maintain ABI in Gentoo/FreeBSD but that is no longer supported. Plus, # FreeBSD maintains their own fork anyway. sys-libs/libcxxabi (from # LLVM upstream) is the suggested replacement (but it's not ABI # compatible!). # Removal in 30 days. Bug #705268. sys-libs/libcxxrt -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lexicographical bash comparison mistakes: things to fix
A few ebuilds use bash '[[ ${foo} < ${bar} ]]' comparison to compare
numbers and package versions.
In bash '<' is for lexicographical string comparison (see man bash
'CONDITIONAL EXPRESSIONS' section). It's almost never what
you want:
$ [[ 1.2.3 < 1.2.3 ]] && echo yes || echo no
no # ok
$ [[ 1.2.9 < 1.2.3 ]] && echo yes || echo no
no # ok
$ [[ 1.2.9 < 1.2.10 ]] && echo yes || echo no
no # whoops
A very crude grep shows many affected packages:
$ git grep -E '\[\[.*[<>]\s*[0-9]+.*\]\]' | cat
app-misc/unfoo/unfoo-1.0.8.ebuild: elif [[ ${REPLACING_VERSIONS} < 1.0.7
]]; then
dev-db/libzdb/libzdb-3.1-r1.ebuild: if [[ $(gcc-version) < 4.1 ]];then
dev-db/libzdb/libzdb-3.1.ebuild:if [[ $(gcc-version) < 4.1 ]];then
eclass/kernel-2.eclass: if [[ ${K_SYMLINK} > 0 ]]; then
eclass/kernel-2.eclass: if [[ ${KV_MAJOR} -ge 3 ||
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.24 ]] ; then
eclass/kernel-2.eclass: if [[ ${KV_MAJOR} -ge 3 ||
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.28 ]]; then
eclass/kernel-2.eclass: if [[ -n ${KV_MINOR} &&
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27 ]] ; then
... ...
Some of them are benign like '[[ ${foo} > 0 ]]': I think it's still worth
fixing them.
Some of them are worse like [[ $(gcc-version) < 4.1 ]]: gcc-version=10 will
break here.
I've created a tracker and dumped a few suspects there:
https://bugs.gentoo.org/705240
I'm sure there are more creative ways to hide version (or just number)
compare behind lexicographical string comparison. If you have an idea how
grep those out please do report and fix them :)
Thank you!
--
Sergei
[gentoo-dev] Last rites: dev-cpp/gtkglextmm, sci-misc/repsnapper
# Andreas Sturmlechner (2020-01-12) # Ancient, blocks x11-libs/gtkglext cleanup, open bug #649066 # Masked for removal in 30 days. dev-cpp/gtkglextmm sci-misc/repsnapper signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: media-video/kamerka, media-libs/qimageblitz
# Andreas Sturmlechner (2020-01-12) # Unmaintained upstream and redundant. Use kde-apps/kamera instead. # Only revdep of ancient media-libs/qimageblitz. Removal in 30 days. media-video/kamerka media-libs/qimageblitz signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: media-plugins/vdr-mailbox
upstream has give up this project, upstream is not interressted on any patches to fix this If you really would like to stay on this plugin, add a comment in this bug wrt bug 704004 pmasked for removal ~12 Feb 2020 -- Joerg Bornkessel GnuPG Key: 0x93EB5F4DAA5832A1 Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: games-board/cgoban2
# Ulrich Müller (2020-01-12) # Runtime errors. Last upstream release in 2003. No license. # Masked for removal in 30 days. Bug #703548. games-board/cgoban2 signature.asc Description: PGP signature
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 12/5/2019 09:24, Rich Freeman wrote: > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld wrote: >> >> It's quite another to mask random packages that have USE flags to >> optionally support whatever python 2.7 library. If you're going to >> last rites these, talk with the maintainer first, and only then, send >> emails one at a time. Doing that en masse isn't appropriate. > > ++ - I have no idea if that happened. For anything USE-controlled it > would make more sense to file a bug or mask the package-flag combo > itself. > >> >> On another topic, I'd prefer for python 2.7 not to be removed from >> gentoo. Tons of code still uses it. >> > > I'm sure a million people would share that preference. I'm not sure > what the upstream/security status is of 2.7. Obviously to keep it > around it would need to be reasonably secure, and somebody within > Gentoo would have to want to maintain it. That's basically the > criteria for keeping anything like this around. If somebody stepped > up and said "I'm maintaining 2.7 and here is why it will remain > secure..." I doubt they'd get a lot of resistance. > I'm late to the party as usual. Seems upstream plans a final 2.7.18 security update in April of 2020, then they will consider the 2.7 branch EOL. They say most of these updates were done in 2019, and so are still technically sticking to their mantra of no more updates after 01/01/2020. PEP 373 covers this: https://www.python.org/dev/peps/pep-0373/#release-schedule """ Planned future release dates: 2.7.18 code freeze January, 2020 2.7.18 release candidate early April, 2020 2.7.18 mid-April, 2020 """ IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER the release of 2.7.18. This provides some time for people to transition systems off of 2.7-dependent packages. It might be worthwhile to treat the removal of Python-2.7 from the tree in the same manner as an EAPI deprecation and removal, given how ingrained it is due to its longevity. That will minimize the whiplash-effect of emerge complaining about slot conflicts and dependency conflicts. Like I just ran into w/ setuptools-45.0.0.0's release. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote: > On 12/5/2019 09:24, Rich Freeman wrote: > > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld > > wrote: > > > It's quite another to mask random packages that have USE flags to > > > optionally support whatever python 2.7 library. If you're going > > > to > > > last rites these, talk with the maintainer first, and only then, > > > send > > > emails one at a time. Doing that en masse isn't appropriate. > > > > ++ - I have no idea if that happened. For anything USE-controlled > > it > > would make more sense to file a bug or mask the package-flag combo > > itself. > > > > > On another topic, I'd prefer for python 2.7 not to be removed > > > from > > > gentoo. Tons of code still uses it. > > > > > > > I'm sure a million people would share that preference. I'm not > > sure > > what the upstream/security status is of 2.7. Obviously to keep it > > around it would need to be reasonably secure, and somebody within > > Gentoo would have to want to maintain it. That's basically the > > criteria for keeping anything like this around. If somebody > > stepped > > up and said "I'm maintaining 2.7 and here is why it will remain > > secure..." I doubt they'd get a lot of resistance. > > > > I'm late to the party as usual. Seems upstream plans a final 2.7.18 > security update in April of 2020, then they will consider the 2.7 > branch > EOL. They say most of these updates were done in 2019, and so are > still > technically sticking to their mantra of no more updates after > 01/01/2020. > > PEP 373 covers this: > https://www.python.org/dev/peps/pep-0373/#release-schedule > > """ > Planned future release dates: > > 2.7.18 code freeze January, 2020 > 2.7.18 release candidate early April, 2020 > 2.7.18 mid-April, 2020 > """ > > IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER > the > release of 2.7.18. This provides some time for people to transition > systems > off of 2.7-dependent packages. > > It might be worthwhile to treat the removal of Python-2.7 from the > tree in > the same manner as an EAPI deprecation and removal, given how > ingrained it > is due to its longevity. That will minimize the whiplash-effect of > emerge > complaining about slot conflicts and dependency conflicts. Like I > just ran > into w/ setuptools-45.0.0.0's release. > Thanks for volunteering to help us manage the ton of packages that have dropped py2 in the mean time. I wasn't aware you were part of the python team, but I must have been mistaken!
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 1/12/2020 17:17, David Seifert wrote: > On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote: >> On 12/5/2019 09:24, Rich Freeman wrote: >>> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld >>> wrote: It's quite another to mask random packages that have USE flags to optionally support whatever python 2.7 library. If you're going to last rites these, talk with the maintainer first, and only then, send emails one at a time. Doing that en masse isn't appropriate. >>> >>> ++ - I have no idea if that happened. For anything USE-controlled >>> it >>> would make more sense to file a bug or mask the package-flag combo >>> itself. >>> On another topic, I'd prefer for python 2.7 not to be removed from gentoo. Tons of code still uses it. >>> >>> I'm sure a million people would share that preference. I'm not >>> sure >>> what the upstream/security status is of 2.7. Obviously to keep it >>> around it would need to be reasonably secure, and somebody within >>> Gentoo would have to want to maintain it. That's basically the >>> criteria for keeping anything like this around. If somebody >>> stepped >>> up and said "I'm maintaining 2.7 and here is why it will remain >>> secure..." I doubt they'd get a lot of resistance. >>> >> >> I'm late to the party as usual. Seems upstream plans a final 2.7.18 >> security update in April of 2020, then they will consider the 2.7 >> branch >> EOL. They say most of these updates were done in 2019, and so are >> still >> technically sticking to their mantra of no more updates after >> 01/01/2020. >> >> PEP 373 covers this: >> https://www.python.org/dev/peps/pep-0373/#release-schedule >> >> """ >> Planned future release dates: >> >> 2.7.18 code freeze January, 2020 >> 2.7.18 release candidate early April, 2020 >> 2.7.18 mid-April, 2020 >> """ >> >> IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER >> the >> release of 2.7.18. This provides some time for people to transition >> systems >> off of 2.7-dependent packages. >> >> It might be worthwhile to treat the removal of Python-2.7 from the >> tree in >> the same manner as an EAPI deprecation and removal, given how >> ingrained it >> is due to its longevity. That will minimize the whiplash-effect of >> emerge >> complaining about slot conflicts and dependency conflicts. Like I >> just ran >> into w/ setuptools-45.0.0.0's release. >> > > Thanks for volunteering to help us manage the ton of packages that have > dropped py2 in the mean time. I wasn't aware you were part of the > python team, but I must have been mistaken! I'm not, heh. But I have noticed the increasing difficulty of getting emerge to do clean updates recently because of these removals, especially when you go several weeks between --sync updates on a machine. The status of py2 removal does not seem to have been communicated really well, nor any kind of plan agreed upon, like we've done w/ the EAPI removal. If I had more time outside of work, I'd love to help. But it's a struggle enough right now to keep my systems ~arch updated, especially since my MIPS boxes aren't exactly speed demons. Right now, I'm just suggesting that maybe we should apply the brakes a little bit and try to coordinate how to remove py2 completely, rather than the way it's being done now. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: > It might be worthwhile to treat the removal of Python-2.7 from the tree in > the same manner as an EAPI deprecation and removal, given how ingrained it > is due to its longevity. That will minimize the whiplash-effect of emerge > complaining about slot conflicts and dependency conflicts. Like I just ran > into w/ setuptools-45.0.0.0's release. So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do you want to freeze all python libs that upstreams are dropping py27 support from? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 1/12/2020 17:32, Andreas Sturmlechner wrote: > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: >> It might be worthwhile to treat the removal of Python-2.7 from the tree in >> the same manner as an EAPI deprecation and removal, given how ingrained it >> is due to its longevity. That will minimize the whiplash-effect of emerge >> complaining about slot conflicts and dependency conflicts. Like I just ran >> into w/ setuptools-45.0.0.0's release. > > So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do you want to > freeze all python libs that upstreams are dropping py27 support from? > Not saying not to package it. Right now, the issue seems to be it causes dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS includes python2_7 support. Remove that and stick with python3_* only, then other packages that need python2_7 will whine. Did setuptools-45.0.0 remove all python2 support? I looked at the commit log, and it's only the title that any meaningful hint that it may have, "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, then that change is the right change, but anyone with a userland that has a mix of python2 and python3 is going to have difficulty getting that update to merge in, so I really can't go higher than setuptools-44.0.0 for the time being. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: > On 1/12/2020 17:32, Andreas Sturmlechner wrote: > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: > > > It might be worthwhile to treat the removal of Python-2.7 from > > > the tree in > > > the same manner as an EAPI deprecation and removal, given how > > > ingrained it > > > is due to its longevity. That will minimize the whiplash-effect > > > of emerge > > > complaining about slot conflicts and dependency conflicts. Like > > > I just ran > > > into w/ setuptools-45.0.0.0's release. > > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do > > you want to > > freeze all python libs that upstreams are dropping py27 support > > from? > > > > Not saying not to package it. Right now, the issue seems to be it > causes > dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS > includes python2_7 support. Remove that and stick with python3_* > only, then > other packages that need python2_7 will whine. > > Did setuptools-45.0.0 remove all python2 support? I looked at the > commit > log, and it's only the title that any meaningful hint that it may > have, > "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, then > that > change is the right change, but anyone with a userland that has a mix > of > python2 and python3 is going to have difficulty getting that update > to merge > in, so I really can't go higher than setuptools-44.0.0 for the time > being. > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 1/12/2020 17:46, David Seifert wrote: > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: >> On 1/12/2020 17:32, Andreas Sturmlechner wrote: >>> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: It might be worthwhile to treat the removal of Python-2.7 from the tree in the same manner as an EAPI deprecation and removal, given how ingrained it is due to its longevity. That will minimize the whiplash-effect of emerge complaining about slot conflicts and dependency conflicts. Like I just ran into w/ setuptools-45.0.0.0's release. >>> >>> So, no packaging of >=setuptools-45.0.0 until the end of 2020? Do >>> you want to >>> freeze all python libs that upstreams are dropping py27 support >>> from? >>> >> >> Not saying not to package it. Right now, the issue seems to be it >> causes >> dependency conflicts in emerge's depgraph parsing when PYTHON_TARGETS >> includes python2_7 support. Remove that and stick with python3_* >> only, then >> other packages that need python2_7 will whine. >> >> Did setuptools-45.0.0 remove all python2 support? I looked at the >> commit >> log, and it's only the title that any meaningful hint that it may >> have, >> "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, then >> that >> change is the right change, but anyone with a userland that has a mix >> of >> python2 and python3 is going to have difficulty getting that update >> to merge >> in, so I really can't go higher than setuptools-44.0.0 for the time >> being. >> > > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 At least you didn't squirrel that behind a lmgtfy link In any event, it's clear the tree does not seem set up real well to handle the random removal or deprecation of python2 support. And considering python2.7 isn't dead //yet//, I have to question the wisdom of removing packages that still support 2.7, and also wonder if there's a way to be more graceful in handling updates to packages whose upstream decides to remove python2 support. Or we can just continue down the current Mad Max methodology and leave it to every developer for themselves. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
[gentoo-dev] Last rites: dev-python/transmissionrpc
# Mike Gilbert (2020-01-12) # No upstream activity since 2014, no reverse deps. # Remove in 30 days. dev-python/transmissionrpc
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote: > On 1/12/2020 17:46, David Seifert wrote: > > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: > > > On 1/12/2020 17:32, Andreas Sturmlechner wrote: > > > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: > > > > > It might be worthwhile to treat the removal of Python-2.7 > > > > > from > > > > > the tree in > > > > > the same manner as an EAPI deprecation and removal, given how > > > > > ingrained it > > > > > is due to its longevity. That will minimize the whiplash- > > > > > effect > > > > > of emerge > > > > > complaining about slot conflicts and dependency > > > > > conflicts. Like > > > > > I just ran > > > > > into w/ setuptools-45.0.0.0's release. > > > > > > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020? > > > > Do > > > > you want to > > > > freeze all python libs that upstreams are dropping py27 support > > > > from? > > > > > > > > > > Not saying not to package it. Right now, the issue seems to be > > > it > > > causes > > > dependency conflicts in emerge's depgraph parsing when > > > PYTHON_TARGETS > > > includes python2_7 support. Remove that and stick with python3_* > > > only, then > > > other packages that need python2_7 will whine. > > > > > > Did setuptools-45.0.0 remove all python2 support? I looked at > > > the > > > commit > > > log, and it's only the title that any meaningful hint that it may > > > have, > > > "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, > > > then > > > that > > > change is the right change, but anyone with a userland that has a > > > mix > > > of > > > python2 and python3 is going to have difficulty getting that > > > update > > > to merge > > > in, so I really can't go higher than setuptools-44.0.0 for the > > > time > > > being. > > > > > > > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 > > At least you didn't squirrel that behind a lmgtfy link > > In any event, it's clear the tree does not seem set up real well to > handle > the random removal or deprecation of python2 support. And > considering > python2.7 isn't dead //yet//, I have to question the wisdom of > removing > packages that still support 2.7, and also wonder if there's a way to > be more > graceful in handling updates to packages whose upstream decides to > remove > python2 support. > > Or we can just continue down the current Mad Max methodology and > leave it to > every developer for themselves. > Or - you know - you could help? Talk is cheap, gracefully removing py2 from the tree is the hard part. A quick grep tells me we have 4388 ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun devising a plan (and then doing the actual work). Pro-tip: "Don't remove py2" is not an actual plan when many important core dependencies have started removing py2 already.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-01-12 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-01-12 23:59 UTC. Removals: app-i18n/man-pages-da 20200108-17:41 ulm d14e33ef313 app-laptop/nvidiabl 20200112-17:35 zlogene da980880462 dev-db/clickhouse 20200112-18:00 zlogene 9d5b201c76a dev-python/arrayterator 20200112-09:59 zlogene 485413c48e6 dev-python/bjoern 20200112-09:59 zlogene 485413c48e6 dev-python/carrot 20200112-09:59 zlogene 485413c48e6 dev-python/cfgparse 20200112-09:59 zlogene 485413c48e6 dev-python/dbutils 20200112-09:59 zlogene 485413c48e6 dev-python/dingus 20200112-09:59 zlogene 485413c48e6 dev-python/ed25519ll20200112-09:59 zlogene 485413c48e6 dev-python/flask-evolution 20200112-09:59 zlogene 485413c48e6 dev-python/fpconst 20200112-09:59 zlogene 485413c48e6 dev-python/functest 20200112-09:59 zlogene 485413c48e6 dev-python/librharris 20200112-09:59 zlogene 485413c48e6 dev-python/mocker 20200112-09:59 zlogene 485413c48e6 dev-python/pyamazon 20200112-09:59 zlogene 485413c48e6 dev-python/pychart 20200112-09:59 zlogene 485413c48e6 dev-python/pychecker20200112-09:59 zlogene 485413c48e6 dev-python/pyosd20200112-09:59 zlogene 485413c48e6 dev-python/pyptlib 20200112-09:59 zlogene 485413c48e6 dev-python/pysctp 20200112-09:59 zlogene 485413c48e6 dev-python/python-biggles 20200112-09:59 zlogene 485413c48e6 dev-python/python-daap 20200112-09:59 zlogene 485413c48e6 dev-python/python-digest20200112-09:59 zlogene 485413c48e6 dev-python/pyutmp 20200112-09:59 zlogene 485413c48e6 dev-python/pyxenstore 20200112-09:59 zlogene 485413c48e6 dev-python/py-xmlrpc20200112-09:59 zlogene 485413c48e6 dev-python/rackspace-monitoring-cli 20200112-09:59 zlogene 485413c48e6 dev-python/reconfigure 20200112-09:59 zlogene 485413c48e6 dev-python/sampy20200112-09:59 zlogene 485413c48e6 dev-python/shm 20200112-09:59 zlogene 485413c48e6 dev-python/simples3 20200112-09:59 zlogene 485413c48e6 dev-python/yolk 20200112-09:59 zlogene 485413c48e6 dev-python/yolk-portage 20200112-09:59 zlogene 485413c48e6 net-wireless/bcm43xx-fwcutter 20200112-17:32 zlogene ec04ef7645c sci-astronomy/casacore 20200106-13:55 asturm 66a8bfef713 sci-mathematics/factmsieve 20200112-17:38 zlogene 50ad243e861 sci-mathematics/lybniz 20200112-17:52 zlogene 112e50cbbea sci-mathematics/Macaulay2 20200112-17:42 zlogene 74bee801698 sci-mathematics/mlpy20200112-17:51 zlogene 25c70122b1f sci-mathematics/nusmv 20200112-17:48 zlogene f2f5341aedb sci-mathematics/p9m420200112-17:47 zlogene 10a3c68f623 sci-mathematics/pymc20200112-17:54 zlogene e103d6b7937 sci-mathematics/snns20200112-17:41 zlogene 0b6d861d173 sci-mathematics/xmds20200112-17:37 zlogene dddb4501242 sys-apps/guix 20200107-07:38 slyfox a0391ae8961 sys-apps/nix20200107-07:38 slyfox a0391ae8961 sys-devel/byfl 20200112-17:57 zlogene be2c0df6d15 x11-misc/calise 20200106-13:56 asturm e59c3150cc7 Additions: acct-group/quassel 20200105-16:40 johu f7d678423b8 acct-group/rstudio-server 20200110-01:30 gienah 14bdef4ecba acct-group/sqlgrey 20191020-11:47 mgorny 688d13bfb96 acct-group/usb 20200110-21:13 zlogene 3c38b81acc9 acct-user/quassel 20200105-16:55 johu 4d0c26608c8 acct-user/rstudio-server20200110-01:32 gienah 7baded146b4 acct-user/sqlgrey 20191020-11:47 mgorny 688d13bfb96 app-doc/mathjax-docs20200110-02:58 gienah d18700aaccc app-emulation/protontricks 20200108-13:34 marecki 8732d3ecff0 app-text/pdfarranger20200108-11:17 grozin 5cc323c219e dev-db/clickhouse 20200112-18:02 zlogene 1f5341d6d8e dev-java/gin20200110-03:28 gienah 9d0b4cad015 dev-java/gwt20200110-03:25 gienah f21a55f93e0 dev-ml/num 20200107-20:54 zx2c40849f2d4192 dev-perl/Locale-Codes 20200108-11:29
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Mon, Jan 13, 2020 at 12:17:36AM +0100, David Seifert wrote: > On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote: > > On 1/12/2020 17:46, David Seifert wrote: > > > On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: > > > > On 1/12/2020 17:32, Andreas Sturmlechner wrote: > > > > > On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: > > > > > > It might be worthwhile to treat the removal of Python-2.7 > > > > > > from > > > > > > the tree in > > > > > > the same manner as an EAPI deprecation and removal, given how > > > > > > ingrained it > > > > > > is due to its longevity. That will minimize the whiplash- > > > > > > effect > > > > > > of emerge > > > > > > complaining about slot conflicts and dependency > > > > > > conflicts. Like > > > > > > I just ran > > > > > > into w/ setuptools-45.0.0.0's release. > > > > > > > > > > So, no packaging of >=setuptools-45.0.0 until the end of 2020? > > > > > Do > > > > > you want to > > > > > freeze all python libs that upstreams are dropping py27 support > > > > > from? > > > > > > > > > > > > > Not saying not to package it. Right now, the issue seems to be > > > > it > > > > causes > > > > dependency conflicts in emerge's depgraph parsing when > > > > PYTHON_TARGETS > > > > includes python2_7 support. Remove that and stick with python3_* > > > > only, then > > > > other packages that need python2_7 will whine. > > > > > > > > Did setuptools-45.0.0 remove all python2 support? I looked at > > > > the > > > > commit > > > > log, and it's only the title that any meaningful hint that it may > > > > have, > > > > "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, > > > > then > > > > that > > > > change is the right change, but anyone with a userland that has a > > > > mix > > > > of > > > > python2 and python3 is going to have difficulty getting that > > > > update > > > > to merge > > > > in, so I really can't go higher than setuptools-44.0.0 for the > > > > time > > > > being. > > > > > > > > > > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 > > > > At least you didn't squirrel that behind a lmgtfy link > > > > In any event, it's clear the tree does not seem set up real well to > > handle > > the random removal or deprecation of python2 support. And > > considering > > python2.7 isn't dead //yet//, I have to question the wisdom of > > removing > > packages that still support 2.7, and also wonder if there's a way to > > be more > > graceful in handling updates to packages whose upstream decides to > > remove > > python2 support. > > > > Or we can just continue down the current Mad Max methodology and > > leave it to > > every developer for themselves. > > > > Or - you know - you could help? Talk is cheap, gracefully removing py2 > from the tree is the hard part. A quick grep tells me we have 4388 > ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun > devising a plan (and then doing the actual work). Pro-tip: "Don't > remove py2" is not an actual plan when many important core dependencies > have started removing py2 already. Joshua and all, I am not on the python team either, but I want to drop this link here for reference in case you haven't seen it. https://python3statement.org tl;dr: python 2.7 was actually deprecated in 2015 with support extended to 2020-01-01 so folks would have time to transition off of it. All of the upstreams on that list will be dropping support for python 2.7 this year if they haven't already done so. Given that, I think it is going to be extremely difficult to keep py 2.7 in the main tree. William signature.asc Description: Digital signature
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On 1/12/2020 19:21, William Hubbs wrote: > On Mon, Jan 13, 2020 at 12:17:36AM +0100, David Seifert wrote: >> On Sun, 2020-01-12 at 17:55 -0500, Joshua Kinard wrote: >>> On 1/12/2020 17:46, David Seifert wrote: On Sun, 2020-01-12 at 17:43 -0500, Joshua Kinard wrote: > On 1/12/2020 17:32, Andreas Sturmlechner wrote: >> On Sonntag, 12. Januar 2020 23:07:24 CET Joshua Kinard wrote: >>> It might be worthwhile to treat the removal of Python-2.7 >>> from >>> the tree in >>> the same manner as an EAPI deprecation and removal, given how >>> ingrained it >>> is due to its longevity. That will minimize the whiplash- >>> effect >>> of emerge >>> complaining about slot conflicts and dependency >>> conflicts. Like >>> I just ran >>> into w/ setuptools-45.0.0.0's release. >> >> So, no packaging of >=setuptools-45.0.0 until the end of 2020? >> Do >> you want to >> freeze all python libs that upstreams are dropping py27 support >> from? >> > > Not saying not to package it. Right now, the issue seems to be > it > causes > dependency conflicts in emerge's depgraph parsing when > PYTHON_TARGETS > includes python2_7 support. Remove that and stick with python3_* > only, then > other packages that need python2_7 will whine. > > Did setuptools-45.0.0 remove all python2 support? I looked at > the > commit > log, and it's only the title that any meaningful hint that it may > have, > "dev-python/setuptools: Bump to 45.0.0 (py3 only)". If it did, > then > that > change is the right change, but anyone with a userland that has a > mix > of > python2 and python3 is going to have difficulty getting that > update > to merge > in, so I really can't go higher than setuptools-44.0.0 for the > time > being. > https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 >>> >>> At least you didn't squirrel that behind a lmgtfy link >>> >>> In any event, it's clear the tree does not seem set up real well to >>> handle >>> the random removal or deprecation of python2 support. And >>> considering >>> python2.7 isn't dead //yet//, I have to question the wisdom of >>> removing >>> packages that still support 2.7, and also wonder if there's a way to >>> be more >>> graceful in handling updates to packages whose upstream decides to >>> remove >>> python2 support. >>> >>> Or we can just continue down the current Mad Max methodology and >>> leave it to >>> every developer for themselves. >>> >> >> Or - you know - you could help? Talk is cheap, gracefully removing py2 >> from the tree is the hard part. A quick grep tells me we have 4388 >> ebuilds in the tree with python_targets_python2_7 in IUSE. Have fun >> devising a plan (and then doing the actual work). Pro-tip: "Don't >> remove py2" is not an actual plan when many important core dependencies >> have started removing py2 already. > > Joshua and all, I am not on the python team either, but I want to drop > this link here for reference in case you haven't seen it. > > https://python3statement.org > > tl;dr: python 2.7 was actually deprecated in 2015 with support extended > to 2020-01-01 so folks would have time to transition off of it. All of > the upstreams on that list will be dropping support for python 2.7 this > year if they haven't already done so. > > Given that, I think it is going to be extremely difficult to keep py 2.7 > in the main tree. > > William That as it may be, I'm generally of the opinion that as long as there are still new releases, we should support it. Once the upstream releases stop, then remove it. For a normal package, this would be a complete non-issue, but Python is hardly a normal package. That said, if we don't have the manpower or the desire to maintain it, then I don't see a problem with removing it. I just wish emerge was better at handling the resulting slot/dependency conflicts that are arising as some packages get pulled and others updated with py3-only support. I am working now to remove the remaining py2 packages from my systems and then rebuild the python packages to only handle py3. The MIPS box is going to take its sweet time on that, though, but cest la vie... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote: > I'm late to the party as usual. Seems upstream plans a final 2.7.18 > security update in April of 2020, then they will consider the 2.7 branch > EOL. They say most of these updates were done in 2019, and so are still > technically sticking to their mantra of no more updates after 01/01/2020. > > PEP 373 covers this: > https://www.python.org/dev/peps/pep-0373/#release-schedule > > """ > Planned future release dates: > > 2.7.18 code freeze January, 2020 > 2.7.18 release candidate early April, 2020 > 2.7.18 mid-April, 2020 > """ > > IMHO, I think we should retain 2.7.x compatibility for 1 year AFTER the > release of 2.7.18. This provides some time for people to transition systems > off of 2.7-dependent packages. > > It might be worthwhile to treat the removal of Python-2.7 from the tree in > the same manner as an EAPI deprecation and removal, given how ingrained it > is due to its longevity. That will minimize the whiplash-effect of emerge > complaining about slot conflicts and dependency conflicts. Like I just ran > into w/ setuptools-45.0.0.0's release. Joshua, I understand that you don't do much Python ebuild work, or probably Python development in general. I understand that you may feel like you need more time with Python 2. But before sending such mails, please try to put yourself in our skin. Imagine I've spend a few hours yesterday merely trying to find a reasonable subset of OpenStack packages that can have Python 2 removed (OpenStack has done Python 3 releases for quite a while already). Believe me, it's not interesting satisfactory work. It's a struggle against neverending conflicts with revdeps, stale stable packages, more indirect revdeps... All that to move a few dozen packages forward and have less pain for end users in the end. Now imagine someone who doesn't really know much about maintaining Python in Gentoo and problems related to Python 2 sunrising, grabs one site about Python releases and tells me what to do without knowing the wider context. Wouldn't you feel angry? Demotivated? Depressed even? I mean, forgive my expression but we're deep in shit. As you've noticed yourself, emerge spews few pages of 'I can't upgrade setuptools' because of humongous number of packages that still need Python 2-capable version. Sure, we could put some effort into making it still work with Python 2, then start collecting more and more patches to various packages just to keep things working. But then, 3-6-12 months from now it will no longer be feasible, the cesspool will overflow and we'll be even deeper in shit that we're today. If people started removing Python 2 from Gentoo years ago, like upstream suggested, today things would be much better. But we waited till last minute. And now you're telling us to wait more because there will be a new release of the *interpreter*? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] unsanctioned python 2.7 crusade
On Montag, 13. Januar 2020 01:44:55 CET Joshua Kinard wrote: > I am working now to remove the remaining py2 packages > from my systems and then rebuild the python packages to only handle py3. Here's a suggestion: Skim through the packages on your system that are py27- only and look them up upstream for a potential version bump with py3 support. Then make that version bump, I'm sure python team will appreciate the help. Regards, Andreas signature.asc Description: This is a digitally signed message part.
