[gentoo-dev] unsanctioned python 2.7 crusade

[gentoo-dev] unsanctioned python 2.7 crusade

[Jason A. Donenfeld]

Hi,

Aaron has marked tons of important and useful Python 2.7 packages for removal:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb57aaaa68cc6f38ac

There are quite a few useful packages in here.

Can we not do this prematurely? I've revered this commit until such a
thing an be appropriately agreed upon. Many of those packages are
actively maintained upstream packages. abcde, beets, and tahoe-lafs
immediately jump out.

Thanks,
Jason

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Rich Freeman]

On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld <zx2c4@gentoo.org> wrote:
>
> Hi,
>
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
>
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon.

Might make sense to wait to mask them at the same time as masking
python 2.7 itself?  Maybe file a bug if not already done to make
maintainers aware that this is coming?

I assume the python team is the one deciding when python 2.7 has to go
(after all, who else is going to maintain it?).  The fact that this is
about a month off did come up in another recent thread but I don't
think it was intended as a formal announcement.

-- 
Rich

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Jason A. Donenfeld]

On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman <rich0@gentoo.org> wrote:
>
> On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld <zx2c4@gentoo.org> wrote:
> >
> > Hi,
> >
> > Aaron has marked tons of important and useful Python 2.7 packages for removal:
> >
> > Can we not do this prematurely? I've revered this commit until such a
> > thing an be appropriately agreed upon.
>
> Might make sense to wait to mask them at the same time as masking
> python 2.7 itself?  Maybe file a bug if not already done to make
> maintainers aware that this is coming?
>
> I assume the python team is the one deciding when python 2.7 has to go
> (after all, who else is going to maintain it?).  The fact that this is
> about a month off did come up in another recent thread but I don't
> think it was intended as a formal announcement.

It's one thing to mask python libraries in general. If gentoo isn't
going to support 2.7, then those libraries don't make sense to  keep
around.

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.

On another topic, I'd prefer for python 2.7 not to be removed from
gentoo. Tons of code still uses it.

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Rich Freeman]

On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx2c4@gentoo.org> 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.

-- 
Rich

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[William Breathitt Gray]

On Thu, Dec 05, 2019 at 09:24:26AM -0500, Rich Freeman wrote:
> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx2c4@gentoo.org> 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.
> 
> -- 
> Rich

If Python 2.7 is EOL upstream then it sounds like upstream will not be
maintaining it any longer; i.e. no more bug fixes nor support. That
means Gentoo would have to maintain its own Python 2.7 fork if it's to
remain in the repository. Naturally, maintaining a Python fork is not
something the Gentoo team is ready to do, so it makes sense to remove
Python 2.7 now that the EOL date is approaching.

Besides, the Python 2.7 EOL date has been known since 2015, so those
python 2-only packages will have had at least 5 years to migrate to
Python 3.

William Breathitt Gray

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

On Thu, Dec 05, 2019 at 09:34:16AM -0500, William Breathitt Gray wrote:
> On Thu, Dec 05, 2019 at 09:24:26AM -0500, Rich Freeman wrote:
> > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx2c4@gentoo.org> 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.
> > 
> > -- 
> > Rich
> 
> If Python 2.7 is EOL upstream then it sounds like upstream will not be
> maintaining it any longer; i.e. no more bug fixes nor support. That
> means Gentoo would have to maintain its own Python 2.7 fork if it's to
> remain in the repository. Naturally, maintaining a Python fork is not
> something the Gentoo team is ready to do, so it makes sense to remove
> Python 2.7 now that the EOL date is approaching.
> 
> Besides, the Python 2.7 EOL date has been known since 2015, so those
> python 2-only packages will have had at least 5 years to migrate to
> Python 3.
> 
> William Breathitt Gray
> 

Wonderful response, William.

For the others who are seeking a quick "why? how? when? what?" there are these
links:

https://pythonclock.org/

https://python3statement.org/ <--- This is a fun one. All the naysayers need to
go yell at the projects too!

-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Thu, 5 Dec 2019 09:40:50 -0500
Aaron Bauman <bman@gentoo.org> wrote:

> Wonderful response, William.

Just because its EOL, doesn't mean it stops working.

It just means *support* for defects and security problems is dropped.

It doesn't prevent us from:

a) vendor patching bugs 
b) vendor patching security issues

So as much as I'm fervently annoyed by needing python 2 on my system
and want to get rid of it post-haste, I too think this move is too
aggressive.

It seems more sensible to me to remove things on the basis of a
*credible problem*, not on the basis of a conjecture that one could
appear in the future.

I'm not averse to change, I just understand for change to be executed
successfully, gradual and careful adjustments have to be made.

Though I deeply suspect once package.deprecated becomes a thing we can use,
we can relegate py2-only stuff there.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Joshua Kinard]

On 12/5/2019 09:24, Rich Freeman wrote:
> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <zx2c4@gentoo.org> 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
kumba@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

[David Seifert]

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 <zx2c4@gentoo.org
> > > 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

[Joshua Kinard]

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 <zx2c4@gentoo.org
>>>> 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
kumba@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

[Andreas Sturmlechner]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

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?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Joshua Kinard]

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

[David Seifert]

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

[Joshua Kinard]

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

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

[David Seifert]

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

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Joshua Kinard]

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 </smirk>
>>>
>>> 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
kumba@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

[Andreas Sturmlechner]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3022 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Joshua Kinard]

On 1/13/2020 01:52, Michał Górny wrote:
> On Sun, 2020-01-12 at 17:07 -0500, Joshua Kinard wrote:

[snip]

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

Actually, I've done a lot of general Python development over the last few
years outside of Gentoo on work-related stuff.  And I've had to convert
those projects from Py2 to Py3, as well.  In fact when faced with the
decision of maintaining Py2 support alongside Py3, I cut my losses and ran,
and dropped Py2 support in a new version.  Wasn't worth the effort to
maintain both with the limited development time I had.

So I'm not walking into this conversation a happy idiot just saying random
things to see what kind of fun I can cause.  There are things I will
absolutely miss in Python2 (goodbye, ASCII strings).  But there are also
things that I like about Python 3 (hello, lru_cache).  So I've been there,
in the proverbial trenches, and know of the pain fellow pythonistas have
gone through over the last few years.

That said, strictly on the ebuild-side of things, yes, I have not dabbled in
that too much.  But I do have some understanding of what you are going through.


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

Actually, I wouldn't feel any of those at all.  I'd probably laugh at it, in
fact.  Why laugh?  Because in that context, I would have knowledge and
understanding of the wider issue, while the poor sod who just proposed that
crazy idea would not.  And my laughter would be more at myself, because
knowing the terrible truth kindles in me a desire to return to that time
when I, too, was ignorant and happy and free.  But the chains of knowledge
bind me to a much more grim fate.


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

FWIW, I was just making a suggestion, not directing an inviolable course of
action.  So calm down, calm down.  If anything, perhaps we should at least
put out an eselect news release that reads like an "under construction"
notice to let users (and other devs) know that there's going to be some
rough spots ahead while Py2 support is excised from the tree.  If there's a
tracker bug, then directing them to that as well so there's a way for people
to follow the process of the removal and even help chase down loose ends.

Again, that's just a suggestion, so please put the pitchforks down if ya'll
don't like it.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

[David Seifert]

On Thu, 2019-12-05 at 14:59 +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman <rich0@gentoo.org> wrote:
> > On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld <zx2c4@gentoo.org
> > > wrote:
> > > Hi,
> > > 
> > > Aaron has marked tons of important and useful Python 2.7 packages
> > > for removal:
> > > 
> > > Can we not do this prematurely? I've revered this commit until
> > > such a
> > > thing an be appropriately agreed upon.
> > 
> > Might make sense to wait to mask them at the same time as masking
> > python 2.7 itself?  Maybe file a bug if not already done to make
> > maintainers aware that this is coming?
> > 
> > I assume the python team is the one deciding when python 2.7 has to
> > go
> > (after all, who else is going to maintain it?).  The fact that this
> > is
> > about a month off did come up in another recent thread but I don't
> > think it was intended as a formal announcement.
> 
> It's one thing to mask python libraries in general. If gentoo isn't
> going to support 2.7, then those libraries don't make sense to  keep
> around.
> 
> 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.
> 
> On another topic, I'd prefer for python 2.7 not to be removed from
> gentoo. Tons of code still uses it.
> 

Sorry, but I'll have to disagree with you on this.

We're removing Java too from Gentoo (more implicitly than explicitly),
because the Maven/Gradle ecosystem doesn't seem to scale. There's tons
of code that uses java and java binaries too, and yet we're removing
it. Python 2 is EOL in a few weeks. We have also removed Qt4 and lost a
number of useful applications with it. At some point, we're not going
to maintain a dead interpreter anymore.

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1957 bytes --]

On 2019-12-05 21:31, David Seifert wrote:
>> On another topic, I'd prefer for python 2.7 not to be removed from
>> gentoo. Tons of code still uses it.
>>
> Sorry, but I'll have to disagree with you on this.
> 
> We're removing Java too from Gentoo (more implicitly than explicitly),
> because the Maven/Gradle ecosystem doesn't seem to scale. There's tons
> of code that uses java and java binaries too, and yet we're removing
> it. Python 2 is EOL in a few weeks. We have also removed Qt4 and lost a
> number of useful applications with it. At some point, we're not going
> to maintain a dead interpreter anymore.

For the records: Nobody in this discussion or IRC chat said

> Keep Python 2 forever.

It's about timing. From my POV and I read

> Tons of code still uses it.
               ^^^^^

the same,  there is no need to mask any Python 2 stuff _today_.

Especially when new Python project lead sent a mail [1] to this list few
weeks ago stating that there will be a _new_ last Python 2 release in
April 2020 (120 days away!).

Now please explain to me and any Gentoo user depending on Py2-only
software why you are taking actions 120(!) days in advance.

Again, nobody wants to keep Python 2 forever but starting to kill
*working* software 120 days in *advance* deserves at least an honest
justification.


PS: And given that a release in April won't break the next day, we are
actually talking about more than 120 days in advance. Security argument
is not valid because if there will be any serious vulnerability in Py2
found after this release (which will be surprising after so many years)
you can expect backports because other distributions still have to
support Py2 two more years at minimum.


[1]
https://archives.gentoo.org/gentoo-dev/message/d00a956180ab7df980ac5642e3abc179


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[David Seifert]

On Thu, 2019-12-05 at 21:56 +0100, Thomas Deutschmann wrote:
> On 2019-12-05 21:31, David Seifert wrote:
> > > On another topic, I'd prefer for python 2.7 not to be removed
> > > from
> > > gentoo. Tons of code still uses it.
> > > 
> > Sorry, but I'll have to disagree with you on this.
> > 
> > We're removing Java too from Gentoo (more implicitly than
> > explicitly),
> > because the Maven/Gradle ecosystem doesn't seem to scale. There's
> > tons
> > of code that uses java and java binaries too, and yet we're
> > removing
> > it. Python 2 is EOL in a few weeks. We have also removed Qt4 and
> > lost a
> > number of useful applications with it. At some point, we're not
> > going
> > to maintain a dead interpreter anymore.
> 
> For the records: Nobody in this discussion or IRC chat said
> 
> > Keep Python 2 forever.

Again, disagree. You'll hear lots of voices that are along the lines of

  "So much enterprise code won't get ported to py3, and RedHat will be
  maintaining RHEL 7 and 8 for the next 10 years, so we'll always have
  security patches to rely on. Let's just keep Python 2 for the
  foreseeable future."

many Gentoo devs have voiced that opinion, so asserting that noone says
"Keep Python 2 forever" is false, and not by a negligible margin.

> 
> It's about timing. From my POV and I read
> 
> > Tons of code still uses it.
>                ^^^^^
> the same,  there is no need to mask any Python 2 stuff _today_.

When we started removing Qt4, tons of code still used it. To put things
in perspective:

grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5-
cache/ | wc -l

gives me 7070 ebuilds currently. 7070 is easily more than one and
closer to two orders of magnitude more ebuilds using python 2 than Qt4
back in the days. Removing python2 will turn into a multi-year,
monumental effort of epic proportions, and I'm willing to bet
€1000 that we'll still be stuck with it in 3 years. It will be one of
the largest undertakings of Gentoo, probably more involved than getting
rid of EAPI=5 ebuilds. Removing maintainer-needed and other semi-dead
packages is part of a proactive strategy in continuously removing and
treecleaning stale stuff from the tree. Tons of java stuff also still
works, yet we're removing it because the ebuilds are ancient and
unmaintained.

> 
> Especially when new Python project lead sent a mail [1] to this list
> few
> weeks ago stating that there will be a _new_ last Python 2 release in
> April 2020 (120 days away!).
> 
> Now please explain to me and any Gentoo user depending on Py2-only
> software why you are taking actions 120(!) days in advance.
> 
> Again, nobody wants to keep Python 2 forever but starting to kill
> *working* software 120 days in *advance* deserves at least an honest
> justification.

So what do you propose? Starting to remove/fix 7070 ebuilds after April
2020 then? Why start in April 2020? Let's just wait till May 2029, when
RHEL 8 goes into end of maintenance support. That's a good time point
then? It doesn't matter what time point you think is suitable, *any*
time point will be arbitrary to someone. Every change breaks somebody's
workflow.

> 
> PS: And given that a release in April won't break the next day, we
> are
> actually talking about more than 120 days in advance. Security
> argument
> is not valid because if there will be any serious vulnerability in
> Py2
> found after this release (which will be surprising after so many
> years)
> you can expect backports because other distributions still have to
> support Py2 two more years at minimum.

And that's exactly the straw-man argument I've been making. You can
always come up with an excuse to delay action on python 2, because
"someone, somewhere, will maintain it". Heck, if RHEL 8 abandons python
2 in 2029, let's just swap in Tauthon then, then we can use python 2
packages till 2100!

> 
> 
> [1]
> https://archives.gentoo.org/gentoo-dev/message/d00a956180ab7df980ac5642e3abc179
> 
> 

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Rich Freeman]

On Thu, Dec 5, 2019 at 5:23 PM David Seifert <soap@gentoo.org> wrote:
>
> And that's exactly the straw-man argument I've been making. You can
> always come up with an excuse to delay action on python 2, because
> "someone, somewhere, will maintain it".

Hey, if somebody actually does want to maintain it I don't see any
reason it can't stick around forever.  Of course maintain means
maintain, not just ignore bugs/etc if it causes grief for other
packages and so on, or allow security issues to fester.

So far I'm getting the impression that everybody wants somebody else
to maintain it, and that is when it becomes an issue.  "WE ought to do
this" - where "WE" usually means "not me."  There is no nebulous
"Gentoo" out there who will maintain ebuilds.  If they are to stay in
the repo then somebody has to actually tend them.

If somebody wants to keep around 2.7 for a long time IMO the most
straightforward thing to do is announce a desire to do it with a plan.
I really doubt that anybody is likely to interfere, and if they do it
can always be escalated to Council.  But, again, it has to be done
right and not cause issues for other packages (at least at the start
that shouldn't be a huge problem).

Personally I've always admired the Wikipedia policy:
https://en.wikipedia.org/wiki/WP:BOLD

If you want to see a change, go about it in a positive way.  If such a
change bothers you, assume good faith, but point out the issues.
Don't over-react in either direction.  This is how 99% of everything
positive that has ever happened in Gentoo has come about.  Most of our
improvements are the result of "unsanctioned crusades."  That doesn't
mean that you should go around breaking systems left and right, but in
this case we're just talking about a mask, or announcing an intent to
do a project.

But, such a thing will certainly involve work.  IMO it is work for
diminishing returns.  If it is an itch that bothers you, though, you
can always scratch it...

-- 
Rich

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert:
> When we started removing Qt4, tons of code still used it. To put
> things
> in perspective:
> 
> grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5-
> cache/ | wc -l
> 
> gives me 7070 ebuilds currently. 7070 is easily more than one and
> closer to two orders of magnitude more ebuilds using python 2 than
> Qt4
> back in the days.

You are dramatizing things too much on purpose here. That gives you a
list of almost all PYTHON_COMPAT packages, the majority of which
support python3 already, and will happily continue working after the
user drops python2_7 from PYTHON_TARGETS or it gets dropped from the
_PYTHON_ALL_IMPLS list in python-utils-r1.eclass.

> Removing maintainer-needed and other semi-dead
> packages is part of a proactive strategy in continuously removing and
> treecleaning stale stuff from the tree.

That's the problem right here. The mask included packages that are not
maintainer-needed, nor maintained by python@ or other projects you or
Aaron are active members of. And it was a careless mask, masking even
some things that aren't even affected, merely had python2 mentioned in
some commented out stuff, afaiu.

I don't think there would be such a huge outcry if this was done right
- involving the actual maintainers of these packages, not just going
ahead and package.masking them from under them 150+ days ahead of time
of actual upstream python2 last release. Presumably most of these
maintainers would already know whether the package is in the progress
of being ported upstream (and just needs probably less than 120 days to
complete that work and make a release), or know that it's dead and go
away. Or they don't respond, and you can p.mask them on a maintainer
honoring timeout.

As this was done is completely unacceptable. Honor your fellow
maintainers and don't trample over them like this. We already are in a
lack of manpower, don't chase more away by trying to take the easy
route and doing stuff like this without involving them via a tracker
bug or other proper ways.
If you don't maintain a package, you get to work with the maintainer,
not do as you please without involving them at all. I am not aware of
QA having such blanket authority either for such a case.


I don't think anyone can have a valid problem with package.mask of some
of the things mentioned (sabnzbd, abcde, etc), because they were indeed
maintainer-needed or sound@ (which David is part of, and is known
crickets territory) or whatnot. It seems to have found interested
maintainers, as is normal with last-rite type of package.masks.
But by including things that are actually maintained, without any
apparent involvement of those maintainers, you allow for such outcry
even for things that shouldn't be a problem, because you display ill
intent and dishonoring towards your fellow maintainers.

Honor your fellow Gentoo maintainers. Period.


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[David Seifert]

On Fri, 2019-12-06 at 10:11 +0200, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert:
> > When we started removing Qt4, tons of code still used it. To put
> > things
> > in perspective:
> > 
> > grep -rl 'IUSE.*python_targets_python2_7'
> > /usr/portage/metadata/md5-
> > cache/ | wc -l
> > 
> > gives me 7070 ebuilds currently. 7070 is easily more than one and
> > closer to two orders of magnitude more ebuilds using python 2 than
> > Qt4
> > back in the days.
> 
> You are dramatizing things too much on purpose here. That gives you a
> list of almost all PYTHON_COMPAT packages, the majority of which
> support python3 already, and will happily continue working after the
> user drops python2_7 from PYTHON_TARGETS or it gets dropped from the
> _PYTHON_ALL_IMPLS list in python-utils-r1.eclass.

Dramatizing that a significant portion of those need to be checked? Are
you going to be doing that work? Are you going to check that the
depgraph is valid? This is unlike py3.6 -> py3.7, where you just
disable the impl in python-utils and stuff keeps working. This is going
to trigger an avalanche.

> 
> > Removing maintainer-needed and other semi-dead
> > packages is part of a proactive strategy in continuously removing
> > and
> > treecleaning stale stuff from the tree.
> 
> That's the problem right here. The mask included packages that are
> not
> maintainer-needed, nor maintained by python@ or other projects you or
> Aaron are active members of. And it was a careless mask, masking even
> some things that aren't even affected, merely had python2 mentioned
> in
> some commented out stuff, afaiu.
> 
> I don't think there would be such a huge outcry if this was done
> right
> - involving the actual maintainers of these packages, not just going
> ahead and package.masking them from under them 150+ days ahead of
> time
> of actual upstream python2 last release. Presumably most of these
> maintainers would already know whether the package is in the progress
> of being ported upstream (and just needs probably less than 120 days
> to
> complete that work and make a release), or know that it's dead and go
> away. Or they don't respond, and you can p.mask them on a maintainer
> honoring timeout.

All the examples people name (abcde, eyeD3) are either maintained by
sound, for which I gave Aaron an explicit sign-off, or they're m-n.
This really boils down to what Rich called "somebody should maintain
it, but it's not going to be me". The best example is probably sabnzbd,
which people want, but don't want to maintain.

> 
> As this was done is completely unacceptable. Honor your fellow
> maintainers and don't trample over them like this. We already are in
> a
> lack of manpower, don't chase more away by trying to take the easy
> route and doing stuff like this without involving them via a tracker
> bug or other proper ways.
> If you don't maintain a package, you get to work with the maintainer,
> not do as you please without involving them at all. I am not aware of
> QA having such blanket authority either for such a case.
> 
> 
> I don't think anyone can have a valid problem with package.mask of
> some
> of the things mentioned (sabnzbd, abcde, etc), because they were
> indeed
> maintainer-needed or sound@ (which David is part of, and is known
> crickets territory) or whatnot. It seems to have found interested
> maintainers, as is normal with last-rite type of package.masks.
> But by including things that are actually maintained, without any
> apparent involvement of those maintainers, you allow for such outcry
> even for things that shouldn't be a problem, because you display ill
> intent and dishonoring towards your fellow maintainers.
> 
> Honor your fellow Gentoo maintainers. Period.
> 
> 
> Mart

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2298 bytes --]

Hi,

On 2019-12-06 09:11, Mart Raudsepp wrote:
> I don't think anyone can have a valid problem with package.mask of some
> of the things mentioned (sabnzbd, abcde, etc), because they were indeed
> maintainer-needed or sound@ (which David is part of, and is known
> crickets territory) or whatnot.

I agree with your mail in general but I don't understand this part:

Since when is it acceptable for anyone to remove packages (the
package.mask entry clearly says that this package is scheduled for
removal and suspecting that any *user* will step and contact p-m for
example is naive) without any need?

Sure, if packages don't work anymore or are blocking something, we will
start last-rite process. But for the sabnzbd example (I haven't looked
closely on any other package from that list) there isn't anything
blocking and it's a working piece of software. The only thing which
stands out is: It's a Py2-only package.

I am also curious about the maintainer-needed aspect: I understand that
Python project doesn't *want* and is also *unable* to maintain all
packages dumped to their project just because like everything in Gentoo,
the project is understaffed for the amount of work. But what's the
solution here? The message everyone saying this is acceptable sends out
can be summarized as: In future, when you see a package which you are
just using will lose its maintainer, take it before anyone decides 'I
have not *any* reason and there is no need but I'll remove it just
because I can'. Face it, no single maintainer can keep up with
maintaining 30+ packages in good quality. So there's a high chance that
package will rot the same way like they are already rotting in former
herds (projects).

Therefore I appreciate packages *without* set maintainer. Because these
packages are sending an important signal: Because they are
maintainer-needed, it's OK for anyone to touch them. Assuming we still
have the rule "If you touch it and it will break, you have to fix it"
that's at least something which *can* work because we still have no
system to declare "Yes, I am the maintainer of this package but I am
fine with you touching it".


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Rich Freeman]

On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> Sure, if packages don't work anymore or are blocking something, we will
> start last-rite process. But for the sabnzbd example (I haven't looked
> closely on any other package from that list) there isn't anything
> blocking and it's a working piece of software. The only thing which
> stands out is: It's a Py2-only package.
>

Well, that's simple enough.  If the python maintainers intend to
remove python2 then they need to remove anything that depends on it at
the same time.  Otherwise all those packages are going to break anyway
and users just end up with a mess of error messages due to a broken
depgraph.

That said, as I've already commented I think it makes more sense to
mask the reverse dependencies at the same time as masking python2
itself.

And of course for something this big it wouldn't have hurt to announce
the plans and what was going to get masked so that mistakes could get
caught.  Even though it is just a mask it is still a bit disruptive to
have packages masked/unmasked because of incorrect identification of
reverse/optional deps.

Ultimately though it is up to the python2 maintainers to decide when
they want to remove it.  If others want to step up and replace them as
python2 maintainers and they have a reasonable plan for keeping it
working that would seem like the approach that would make the most
people happy.  We can't force people to maintain python2 if they don't
want to.

-- 
Rich

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Mike Gilbert]

On Fri, Dec 6, 2019 at 8:52 AM Rich Freeman <rich0@gentoo.org> wrote:
>
> On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
> >
> > Sure, if packages don't work anymore or are blocking something, we will
> > start last-rite process. But for the sabnzbd example (I haven't looked
> > closely on any other package from that list) there isn't anything
> > blocking and it's a working piece of software. The only thing which
> > stands out is: It's a Py2-only package.
> >
>
> Well, that's simple enough.  If the python maintainers intend to
> remove python2 then they need to remove anything that depends on it at
> the same time.  Otherwise all those packages are going to break anyway
> and users just end up with a mess of error messages due to a broken
> depgraph.
>
> That said, as I've already commented I think it makes more sense to
> mask the reverse dependencies at the same time as masking python2
> itself.

It's not quite so simple as you make it sound. There really isn't a
viable way to defer removal of python2-only packages until we remove
dev-lang/python:2.7.

An increasing number of python packages are dropping support for
python2 when upstream releases new versions. When this happens, we
really need to drop python2 support from all reverse dependencies as
well. Alternative strategies like slotting or compatibility packages
are a stopgap at best, and become a problem as soon as bugs are
reported or security issues pop up.

Ripping out python2 support for all reverse dependencies of a core
package is rather daunting, and is likely to cause much more of an
uproar than the recent mask. Aaron is really tackling the low-hanging
fruit at this point: leaves on the depgraph.

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

On 2019-12-06 16:48, Mike Gilbert wrote:
> It's not quite so simple as you make it sound. There really isn't a
> viable way to defer removal of python2-only packages until we remove
> dev-lang/python:2.7.
> 
> An increasing number of python packages are dropping support for
> python2 when upstream releases new versions. When this happens, we
> really need to drop python2 support from all reverse dependencies as
> well. Alternative strategies like slotting or compatibility packages
> are a stopgap at best, and become a problem as soon as bugs are
> reported or security issues pop up.
> 
> Ripping out python2 support for all reverse dependencies of a core
> package is rather daunting, and is likely to cause much more of an
> uproar than the recent mask. Aaron is really tackling the low-hanging
> fruit at this point: leaves on the depgraph.

But what's the problem here? Why do you need to rip out Py2 support? PHP
project is facing a similar situation with PHP 5.6, 7.0 and now 7.1
becoming EOL. Sure, there are way more Python packages but could you
explain why you can't do the same like we did? I.e. new versions of PHP
PECL extension also dropped support for PHP versions which are EOL. When
we bump these packages we just drop PHP versions which are no longer
able to run these extensions. But we keep at least last version still
supporting PHP version which is/become EOL until we finally get rid of
this PHP version as a whole. For example, a lot of packages are now
masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of
PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users
by starting to remove PECL extension for this version while
dev-lang/php:5.6 was still a thing...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Mike Gilbert]

On Fri, Dec 6, 2019 at 11:12 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2019-12-06 16:48, Mike Gilbert wrote:
> > It's not quite so simple as you make it sound. There really isn't a
> > viable way to defer removal of python2-only packages until we remove
> > dev-lang/python:2.7.
> >
> > An increasing number of python packages are dropping support for
> > python2 when upstream releases new versions. When this happens, we
> > really need to drop python2 support from all reverse dependencies as
> > well. Alternative strategies like slotting or compatibility packages
> > are a stopgap at best, and become a problem as soon as bugs are
> > reported or security issues pop up.
> >
> > Ripping out python2 support for all reverse dependencies of a core
> > package is rather daunting, and is likely to cause much more of an
> > uproar than the recent mask. Aaron is really tackling the low-hanging
> > fruit at this point: leaves on the depgraph.
>
> But what's the problem here? Why do you need to rip out Py2 support? PHP
> project is facing a similar situation with PHP 5.6, 7.0 and now 7.1
> becoming EOL. Sure, there are way more Python packages but could you
> explain why you can't do the same like we did? I.e. new versions of PHP
> PECL extension also dropped support for PHP versions which are EOL. When
> we bump these packages we just drop PHP versions which are no longer
> able to run these extensions. But we keep at least last version still
> supporting PHP version which is/become EOL until we finally get rid of
> this PHP version as a whole. For example, a lot of packages are now
> masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of
> PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users
> by starting to remove PECL extension for this version while
> dev-lang/php:5.6 was still a thing...

That's going to cause a very confusing user-experience due to
conflicting PYTHON_TARGETS values on the various packages. It's also
going to cause users to have old/unsupported/buggy versions of various
random python packages depending on what set of reverse dependencies
they happen to have installed.

For example, lets say the next release of dev-python/example drops
support for python2, and also adds some new features and fixes some
bugs.

If the user has python2_7 enabled for any reverse dependency of
dev-python/example, Portage will be forced to do one of two things:

1. Keep the old version installed.
2. Emit a confusing error message to the user since the use-dependency
on dev-python/example[python_targets_python2_7] cannot be resolved
with the latest visible version.

Option 1 is bad because the user will be missing out on bug fixes and
new features. Option 2 will probably generate some bug reports that we
will have to close as CANTFIX.

It's also a giant pain in the butt for python maintainers since it
makes cleaning up old versions very error-prone. This may also be a
problem if the security team demands we remove it.

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 3040 bytes --]

On 2019-12-06 17:44, Mike Gilbert wrote:
> That's going to cause a very confusing user-experience due to
> conflicting PYTHON_TARGETS values on the various packages. It's also
> going to cause users to have old/unsupported/buggy versions of various
> random python packages depending on what set of reverse dependencies
> they happen to have installed.
> 
> For example, lets say the next release of dev-python/example drops
> support for python2, and also adds some new features and fixes some
> bugs.
> 
> If the user has python2_7 enabled for any reverse dependency of
> dev-python/example, Portage will be forced to do one of two things:
> 
> 1. Keep the old version installed.
> 2. Emit a confusing error message to the user since the use-dependency
> on dev-python/example[python_targets_python2_7] cannot be resolved
> with the latest visible version.

I don't fully understand #2 to be honest but yes, you will be cut off
from latest version at some point. Same in PHP.

But from my POV you are trying to find a solution for a non-existent
problem: Keep in mind that *user* is in control of PYTHON_TARGETS
(PHP_TARGETS).

If we expect that our users should simply remove that mask locally
("OMG! It's just a package.mask!") we can assume that same user
understand consequences when sticking to targets not supported by newer
versions anymore.

Also, problem will automatically go away when time passes assuming more
and more packages will no longer have python_targets_python2_7. I.e.
user will automatically migrate to Py3 over time.

I still have no words for this decision breaking working Py 2 *only*
packages 150+ days in advance which don't cause any problems (and aside
USE=test case will never cause problems -- if pytest for example will
become a problem, dropping tests but keeping the package itself is also
an option, just saying).

Especially now that I adopted that package, no problem was really solved
and at some point we will have to discuss test dependencies for example.

So yeah, even after 24h I still think this was a bad decision which
wasn't thought through to the end. An easy solution for a not yet
existing problem. Purely activism in a bad way. :/


> It's also a giant pain in the butt for python maintainers since it
> makes cleaning up old versions very error-prone. This may also be a
> problem if the security team demands we remove it.

We would never do that and you know that. The only thing we would ask
you to do is masking to inform user in case user isn't aware that
package is vulnerable. But more important: In that case you would have
your reason to mask affected dependencies (like PHP project did with PHP
5.6 and consumers).

Maybe someday one of those responsible will admit that this step was not
a thoughtful and good decision and promise not to do it that way again
and I'll get over it. Who knows. :)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Andreas Sturmlechner]

On Friday, 6 December 2019 20:47:31 CET Thomas Deutschmann wrote:
> On 2019-12-06 17:44, Mike Gilbert wrote:
> > 1. Keep the old version installed.
> > 2. Emit a confusing error message to the user since the use-dependency
> > on dev-python/example[python_targets_python2_7] cannot be resolved
> > with the latest visible version.
> 
> I don't fully understand #2 to be honest but yes, you will be cut off
> from latest version at some point. Same in PHP.

Considering that above statement, I would expect a bit more humility than the 
following:

> Maybe someday one of those responsible will admit that this step was not
> a thoughtful and good decision and promise not to do it that way again
> and I'll get over it. Who knows. :)

Just so we're on the same page, a recent example of what some people 
suggesting to keep py27 ad nauseam are asking users to deal with:



# emerge -uDpv @world

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

WARNING: One or more updates/rebuilds have been skipped due to a dependency 
conflict:

dev-python/sphinx:0

  (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge) conflicts 
with
    >=dev-python/
sphinx-1.5.3[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/sphinxcontrib-websupport-1.1.0:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                               
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/cython-0.29.4:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/flask-babelex-0.9.3:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/testtools-2.3.0:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/pytest-runner-4.2:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/flask-babel-0.11.2-r2:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    >=dev-python/
sphinx-1.3.1[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/recommonmark-0.5.0_pre20181012-r1:0/0::gentoo, installed)
                                                                                                                                                                                                                                 
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/testpath-0.3.1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/sphinx[python_targets_python2_7(-),-
python_single_target_pypy(-),-python_single_target_python2_7(-)] required by 
(dev-python/backports-functools-lru-cache-1.4-r1:0/0::gentoo, installed)
                                                                                                                   
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/Babel-2.6.0:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/greenlet-0.4.15:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_python2_7(-),-
python_single_target_python3_5(-),-python_single_target_python3_6(-),-
python_single_target_python3_7(-)] required by (dev-python/flask-wtf-0.14.2-
r1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-)] required by (dev-python/
pexpect-4.2.1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                   
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_python2_7(-),-
python_single_target_python3_5(-),-python_single_target_python3_6(-),-
python_single_target_python3_7(-)] required by (dev-python/python-
sqlparse-0.2.4:0/0::gentoo, installed)
                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/pyopenssl-19.0.0:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/pyasn1-0.4.2:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/flask-login-0.4.1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/future-0.17.0:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    >=dev-python/
sphinx-1.3.1[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_python2_7(-),-
python_single_target_python3_5(-),-python_single_target_python3_6(-),-
python_single_target_python3_7(-)] required by (dev-python/pyxattr-0.6.0-
r1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                               
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/more-itertools-4.2.0-r1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/utidylib-0.3-r2:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/traitlets-4.3.2:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    >=dev-python/
sphinx-0.6[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/wtforms-2.2.1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                             
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/numpydoc-0.9.1:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/virtualenv-16.0.0:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/rst-linker-1.11:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/nbformat-4.4.0:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_python2_7(-),-
python_single_target_python3_5(-),-python_single_target_python3_6(-),-
python_single_target_python3_7(-)] required by (dev-python/
cairocffi-0.8.0:0/0::gentoo, installed)
                                                                                                                                                                                                                                                       
    >=dev-python/sphinx-1.3.1-
r1[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/qtconsole-4.3.1:0/0::gentoo, installed)
                                                                                                                                                                                                                                     
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/ipyparallel-6.0.2-r1:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/jupyter_core-4.4.0:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/atomicwrites-1.1.5-r3:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/sphinxcontrib-github-alt-1.0:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/paramiko-2.4.2:0/0::gentoo, installed)
                                                                                                                                                                                                                         
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/pallets-sphinx-themes-1.1.2:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/
sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
python_single_target_pypy(-),-python_single_target_pypy3(-),-
python_single_target_python2_7(-),-python_single_target_python3_5(-),-
python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
by (dev-python/py-1.5.4:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                       
    dev-python/sphinx[python_targets_python2_7(-),-
python_single_target_pypy(-),-python_single_target_python2_7(-)] required by 
(dev-python/futures-3.1.1:0/0::gentoo, installed)

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1289 bytes --]

On 2019-12-06 21:10, Andreas Sturmlechner wrote:
> Just so we're on the same page, a recent example of what some people 
> suggesting to keep py27 ad nauseam are asking users to deal with:
> [...]
> WARNING: One or more updates/rebuilds have been skipped due to a dependency 
> conflict:

Yes, like said, at some point you cannot prevent that. Remember when I
bumped libvpx to v1.8.0 and people yelled at me because they are now
seeing that message all the time (If you are using gnome you probably
know the same msg which triggers for unicode stuff which I am also
responsible for) because I bumped that package but not everything
supports that version yet?

It's just a hint. Not a problem. If you don't understand that hint I
can't help. It doesn't force user interaction like a mask do.

If you understand the problem, you will locally mask >=libvpx-1.8 and
message will go away.

And again: If this will really solve problems, why is anyone allowed to
take over those package like I did for sabnzbd? If you are right and
this is really a problem for Gentoo I shouldn't be allowed to do that.
And *then* we would also have a reason to mask :-)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Alexis Ballier]

On Fri, 2019-12-06 at 21:28 +0100, Thomas Deutschmann wrote:
> On 2019-12-06 21:10, Andreas Sturmlechner wrote:
> > Just so we're on the same page, a recent example of what some
> > people 
> > suggesting to keep py27 ad nauseam are asking users to deal with:
> > [...]
> > WARNING: One or more updates/rebuilds have been skipped due to a
> > dependency 
> > conflict:
> 
> Yes, like said, at some point you cannot prevent that. Remember when
> I
> bumped libvpx to v1.8.0 and people yelled at me because they are now
> seeing that message all the time (If you are using gnome you probably
> know the same msg which triggers for unicode stuff which I am also
> responsible for) because I bumped that package but not everything
> supports that version yet?


For having maintained packages that often have this issue for years, I
must say this is a very bad idea: You are asking (or doing yourself)
consumer packages to have < deps on your package. This falsely gives
the impression that the non-latest version is still maintained. This
also makes removing this old version very error prone (we do have tools
to check for that but those are not in the standard workflow). Not sure
how portage handles this, but negative deps (<, =, ! & co) are much
harder to solve than purely positive ones -- PM probably uses some
heuristics but then this has some limitations and if the number of such
deps grows too much it may fail to solve them or do the right thing.

I think it is a much better way to package.mask the newest version of
your lib until all consumers work with it, or those that don't are
masked. This is how we handled such transitions before portage improved
its handling of negative deps and is IMHO still better.


Alexis.

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Michael 'veremitz' Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 23414 bytes --]

On 06/12/19 20:10, Andreas Sturmlechner wrote:
> On Friday, 6 December 2019 20:47:31 CET Thomas Deutschmann wrote:
>> On 2019-12-06 17:44, Mike Gilbert wrote:
>>> 1. Keep the old version installed.
>>> 2. Emit a confusing error message to the user since the use-dependency
>>> on dev-python/example[python_targets_python2_7] cannot be resolved
>>> with the latest visible version.
>> I don't fully understand #2 to be honest but yes, you will be cut off
>> from latest version at some point. Same in PHP.
> Considering that above statement, I would expect a bit more humility than the 
> following:
>
>> Maybe someday one of those responsible will admit that this step was not
>> a thoughtful and good decision and promise not to do it that way again
>> and I'll get over it. Who knows. :)
> Just so we're on the same page, a recent example of what some people 
> suggesting to keep py27 ad nauseam are asking users to deal with:
>
>
>
> # emerge -uDpv @world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> Total: 0 packages, Size of downloads: 0 KiB
>
> WARNING: One or more updates/rebuilds have been skipped due to a dependency 
> conflict:
>
> dev-python/sphinx:0
>
>   (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge) conflicts 
> with
>     >=dev-python/
> sphinx-1.5.3[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/sphinxcontrib-websupport-1.1.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                                
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/cython-0.29.4:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/flask-babelex-0.9.3:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/testtools-2.3.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/pytest-runner-4.2:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/flask-babel-0.11.2-r2:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     >=dev-python/
> sphinx-1.3.1[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/recommonmark-0.5.0_pre20181012-r1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                  
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/testpath-0.3.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/sphinx[python_targets_python2_7(-),-
> python_single_target_pypy(-),-python_single_target_python2_7(-)] required by 
> (dev-python/backports-functools-lru-cache-1.4-r1:0/0::gentoo, installed)
>                                                                                                                    
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/Babel-2.6.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/greenlet-0.4.15:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_python2_7(-),-
> python_single_target_python3_5(-),-python_single_target_python3_6(-),-
> python_single_target_python3_7(-)] required by (dev-python/flask-wtf-0.14.2-
> r1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-)] required by (dev-python/
> pexpect-4.2.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                    
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_python2_7(-),-
> python_single_target_python3_5(-),-python_single_target_python3_6(-),-
> python_single_target_python3_7(-)] required by (dev-python/python-
> sqlparse-0.2.4:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/pyopenssl-19.0.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/pyasn1-0.4.2:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/flask-login-0.4.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/future-0.17.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     >=dev-python/
> sphinx-1.3.1[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_python2_7(-),-
> python_single_target_python3_5(-),-python_single_target_python3_6(-),-
> python_single_target_python3_7(-)] required by (dev-python/pyxattr-0.6.0-
> r1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/more-itertools-4.2.0-r1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/utidylib-0.3-r2:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/traitlets-4.3.2:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     >=dev-python/
> sphinx-0.6[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/wtforms-2.2.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                              
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/numpydoc-0.9.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/virtualenv-16.0.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/rst-linker-1.11:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/nbformat-4.4.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_python2_7(-),-
> python_single_target_python3_5(-),-python_single_target_python3_6(-),-
> python_single_target_python3_7(-)] required by (dev-python/
> cairocffi-0.8.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                        
>     >=dev-python/sphinx-1.3.1-
> r1[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/qtconsole-4.3.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                      
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/ipyparallel-6.0.2-r1:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/jupyter_core-4.4.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/atomicwrites-1.1.5-r3:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/sphinxcontrib-github-alt-1.0:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/paramiko-2.4.2:0/0::gentoo, installed)
>                                                                                                                                                                                                                          
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/pallets-sphinx-themes-1.1.2:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] required 
> by (dev-python/py-1.5.4:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                        
>     dev-python/sphinx[python_targets_python2_7(-),-
> python_single_target_pypy(-),-python_single_target_python2_7(-)] required by 
> (dev-python/futures-3.1.1:0/0::gentoo, installed)
>
>
>
You write like this is some unknown/undesirable failure mode of portage,
when, in fact, just like any change of PYTHON_TARGETS or
PYTHON_SINGLE_TARGET throws portage into a complete frenzy of confusion
because of the tight knitting caused by the python eclasses.

Now, some proposals have been made to better tie-down of the latter
situation here on this same list .. but let's just get over the fact that
python interpreters and libraries are just going to be a bit messier for a
few years, and we'll have to be a bit more careful when specifying
dependencies whilst this transition period washes out.

I really don't understand from anyone's point of view, the level of
hysteria being whipped up over this.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Fri, 06 Dec 2019 21:10:12 +0100
Andreas Sturmlechner <asturm@gentoo.org> wrote:

> Calculating dependencies... done!
> 
> Total: 0 packages, Size of downloads: 0 KiB
> 
> WARNING: One or more updates/rebuilds have been skipped due to a
> dependency conflict:
> 
> dev-python/sphinx:0
> 
>   (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge)
> conflicts with


This IME is more an argument that "portage is shit", not so much an
argument that "we need to nuke old pythons"

If this problem was a valid impetus for this removal, we'd have banned
PYTHON_TARGETS entirely a long time ago, and we'd have culled literally
everything that doesn't work on the latest python.

But I don't favour that outcome at all.

I'd rather favour an outcome where portage responds to this scenario in
a useful way that makes coherent sense to users.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Ühel kenal päeval, R, 06.12.2019 kell 14:06, kirjutas Thomas
Deutschmann:
> Since when is it acceptable for anyone to remove packages (the
> package.mask entry clearly says that this package is scheduled for
> removal and suspecting that any *user* will step and contact p-m for
> example is naive) without any need?

I assume the p.mask entry text wasn't optimal then.
For this specific case, sabnzbd had been in maintainer-needed for 3
months already. Unfortunately no "package up for grabs" had been sent
for this one when it was dropped to that (previous maintainer dropped
maintenance himself).

I don't see anything wrong with the idea of p.masking it in case it
could be causing problems for others (such as py2). Of course the
p.mask entry could apparently have been better, it's sad that no
"package up for grabs" happened back then months ago, and it's not nice
it was all in a big lump of maintainer-needed packages, python@
packages and packages maintained by completely unaware maintainers with
no notification period.


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 432 bytes --]

On 2019-12-06 17:35, Mart Raudsepp wrote:
> I don't see anything wrong with the idea of p.masking it in case it
> could be causing problems for others (such as py2).

Sure, in *case* it *is* causing problems. ACK.

But so far nobody was able to provide any reasons. That's the thing
which drives me nuts...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Thu, Dec 05, 2019 at 02:42:59PM +0100, Jason A. Donenfeld wrote:
> Hi,
> 
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb57aaaa68cc6f38ac
> 
> There are quite a few useful packages in here.
> 
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
> 
> Thanks,
> Jason
> 

You have obviously not read the relevant commit msg, reviewed the already
existing thread on -dev, or attempted to ask (and await a response) relevant
questions.

Jumping to conclusions does not help anyone.

<@zx2c4> that was supposed to be a || ( ... )
<@zx2c4> but for whatever reason the maintainer forgot that
<@zx2c4> so im going to correct that and remove eyeD3 from the list<@zx2c4> and unmask it
<@zx2c4> b-man: sound good?
<@zx2c4> slashbeast: woah look at d85e166dd999c354a5346fbb57aaaa68cc6f38ac
<@zx2c4> it's ... a lot of packages
<@zx2c4> hey removing beets too? thats not cool
<@zx2c4> and pp?
<@zx2c4> um
<@zx2c4> actually, this is ridiculous

So, clearly, you did not read the commit msg or review the thread. Magically,
you were actually going to *fix* a package and then got overwhelmed with how
many of your favorite pkgs were on the list.

Don't be lazy. Others are working to fix them and keep them around.

-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] unsanctioned python 2.7 crusade

[Andreas K. Huettel]

How about adding yourself as maintainer then? :)

Am Donnerstag, 5. Dezember 2019, 14:42:59 CET schrieb Jason A. Donenfeld:
> Hi,
> 
> Aaron has marked tons of important and useful Python 2.7 packages for
> removal:
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fb
> b57aaaa68cc6f38ac
> 
> There are quite a few useful packages in here.
> 
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
> 
> Thanks,
> Jason


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)