Mailing List Archive

>>>>> On Sat, 20 Jun 2020, Aaron Bauman wrote:

>> # Aaron Bauman <bman@gentoo.org> (2020-06-20)
>> # Py2 only
>> # Removal in 14 days

I see these short deadlines quite often recently. Any reason why this
can't be the usual 30 days?

>> [...]

>> games-board/scid

I wonder about scid appearing in the list. IIRC, it is written in C++,
not Python.

Ulrich

>>>>> On Sat, 20 Jun 2020, Ulrich Mueller wrote:

>>> games-board/scid

> I wonder about scid appearing in the list. IIRC, it is written in C++,
> not Python.

It turns out that the ebuild installs a small Python script, which isn't
needed for normal functioning of the program. Bug 728876 now.

Ulrich

On 2020.06.20 05:58, Aaron Bauman wrote:
> > # Aaron Bauman <bman@gentoo.org> (2020-06-20)
> > # Py2 only
> > # Removal in 14 days

[list of stuff]

>
> --
> Cheers,
> Aaron
>

Aaron,

If everything that needs python2 is being removed,
why not python2 itself?

Al least, python2 is not on your list.

Be first into the future by masking this stuff and
Last out of the past by leaving up to users to decide.
It could stay in the tree, masked, as long as python2.

--
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

On Sat, 2020-06-20 at 10:36 +0100, Roy Bamford wrote:
> On 2020.06.20 05:58, Aaron Bauman wrote:
> > > # Aaron Bauman <bman@gentoo.org> (2020-06-20)
> > > # Py2 only
> > > # Removal in 14 days
>
> [list of stuff]
>
> > --
> > Cheers,
> > Aaron
> >
>
> Aaron,
>
> If everything that needs python2 is being removed,
> why not python2 itself?
>
> Al least, python2 is not on your list.
>
> Be first into the future by masking this stuff and
> Last out of the past by leaving up to users to decide.
> It could stay in the tree, masked, as long as python2.
>

Do you really think it'd be better to last rite a 1000 packages
simultaneously?

--
Best regards,
Micha? Górny

On 2020-06-20 12:07, Micha? Górny wrote:
>> Al least, python2 is not on your list.
>>
>> Be first into the future by masking this stuff and
>> Last out of the past by leaving up to users to decide.
>> It could stay in the tree, masked, as long as python2.
>>
>
> Do you really think it'd be better to last rite a 1000 packages
> simultaneously?

What's the purpose of this at all?

dev-lang/python:2.7 won't go away that soon.

Removing perfectly working and up-to-date software which is in
maintenance-only mode like net-mail/offlineimap is just not user-friendly.

It doesn't even has deps on other Python packages blocking your cleanup
delusion.


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

> games-emulation/openmsx

git version migrated to meson and python3

On Sat, Jun 20, 2020 at 12:58:20AM -0400, Aaron Bauman wrote:
> > # Aaron Bauman <bman@gentoo.org> (2020-06-20)
> > # Py2 only
> > # Removal in 14 days
> > dev-util/uftrace

This is a function tracer written in C. I don't know why it's on this
list. If a package has only optional support for python like this,
just drop python support rather than the whole package, please. In this
case it's just a matter of adding --without-libpython to the call to econf.

In any case, the release notes for the latest version says that it now does
support python3, even though the configuration for python3 seems a bit broken
after I've had a look at it. I will take it and fix nevertheless.

Cheers,
-Guilherme

On Sat, 2020-06-20 at 13:29 +0200, Thomas Deutschmann wrote:
> On 2020-06-20 12:07, Micha? Górny wrote:
> > > Al least, python2 is not on your list.
> > >
> > > Be first into the future by masking this stuff and
> > > Last out of the past by leaving up to users to decide.
> > > It could stay in the tree, masked, as long as python2.
> > >
> >
> > Do you really think it'd be better to last rite a 1000 packages
> > simultaneously?
>
> What's the purpose of this at all?
>
> dev-lang/python:2.7 won't go away that soon.

> Removing perfectly working and up-to-date software which is in
> maintenance-only mode like net-mail/offlineimap is just not user-friendly.
>
> It doesn't even has deps on other Python packages blocking your cleanup
> delusion.
>

Don't you think that accussing others publicly of being delusional is
not appropriate? Just because someone doesn't agree with your vision is
no reason to insult your fellow developers.

--
Best regards,
Micha? Górny

On Sat, 20 Jun 2020 14:58:22 +0300
Azamat Hackimov <azamat.hackimov@gmail.com> wrote:

> > games-emulation/openmsx
>
> git version migrated to meson and python3

Yeah, don't worry, this has been on my TODO for a while and I'll step
it up the list. I was hoping they'd do a release but no such luck.

--
James Le Cuirot (chewi)
Gentoo Linux Developer

On Sat, Jun 20, 2020 at 10:32:28AM +0200, Ulrich Mueller wrote:
> >>>>> On Sat, 20 Jun 2020, Aaron Bauman wrote:
>
> >> # Aaron Bauman <bman@gentoo.org> (2020-06-20)
> >> # Py2 only
> >> # Removal in 14 days
>
> I see these short deadlines quite often recently. Any reason why this
> can't be the usual 30 days?
>
> >> [...]
>
> >> games-board/scid
>
> I wonder about scid appearing in the list. IIRC, it is written in C++,
> not Python.
>
> Ulrich

Hi, Ulrich. Yes, the deadlines are meant to speed up the process as we
have *roughly* 1000+ pkgs which must be converted to py3 or removed
before we can drop the interpreter.

As such, doing this in bulk with delays in between masks helps others
find and fix up these packages if they can stay. Some have ports to Py3,
others simply don't need the bindings, etc.

So, thank you to all who have taken a few minutes to help us keep
packages that can still be supported. Unfortunately, we have a bad ratio
of devs to # of packages.

--
Cheers,
Aaron

On Sat, Jun 20, 2020 at 01:29:46PM +0200, Thomas Deutschmann wrote:
> On 2020-06-20 12:07, Micha? Górny wrote:
> >> Al least, python2 is not on your list.
> >>
> >> Be first into the future by masking this stuff and
> >> Last out of the past by leaving up to users to decide.
> >> It could stay in the tree, masked, as long as python2.
> >>
> >
> > Do you really think it'd be better to last rite a 1000 packages
> > simultaneously?
>
> What's the purpose of this at all?
>
> dev-lang/python:2.7 won't go away that soon.
>
> Removing perfectly working and up-to-date software which is in
> maintenance-only mode like net-mail/offlineimap is just not user-friendly.
>
> It doesn't even has deps on other Python packages blocking your cleanup
> delusion.
>

Thomas, unfortunately, I am shocked at your choice of words here. I
think it is reasonable that any developer would understand a lack
of forward momentum in removing Py2 only packages only drives
stagnation.

If you have a more effective method to doing so, I am open to
suggestions.

re: net-mail/offlineimap... there are alternatives.

--
Cheers,
Aaron

On 2020-06-20 21:24, Aaron Bauman wrote:
> Thomas, unfortunately, I am shocked at your choice of words here. I
> think it is reasonable that any developer would understand a lack
> of forward momentum in removing Py2 only packages only drives
> stagnation.
>
> If you have a more effective method to doing so, I am open to
> suggestions.

Like I am shocked about your recent actions:

Remember what you did in January. I thought it became clear that next
time you will share your list before just masking stuff to avoid things
which happened then.

In the beginning of this month you just decided to disband graphics
project. On your own. Please tell me what gave you the authority to just
do that? You didn't even share your plan before executing it on any
mailing list. Something that should be common sense, if not even necessary.
The whole action was so destructive that you couldn't evenb just undo it
because you also deleted stuff on Wiki.

And now you did it again with Py2-only packages.

And again for no good reason.

Like multiple people have already shown you, many packages from that
list are not even blocking Py3 transition.

Let me tell you what a mask will cause:
A mask is destructive and requires user interaction. Therefore a mask
isn't something to play with, "Oh, let's test if someone will
complain... it's just a mask, we can just unmask in case...".

No, imagine there are people out there using Gentoo in production and
not as playground. These people maybe have automated build systems which
are creating systems/images (do you know Dockers for example?). Whenever
you mask something and that package is referenced in configuration, you
will break that build.

That's not funny if this is happening for no real reason.


> re: net-mail/offlineimap... there are alternatives.

I think you don't really know that tool. It's an industry standard.
Sure, there are already successors (however, not in Gentoo). But the
package itself is still working and actively maintained and when you
will use it in production you usually have extended/adjusted the tool
for your environment using the plugin system the tool provides. That's
not something you will be able to replace with something new in 5 minutes.

And I repeat myself: Especially not when there is no need to do that
because because the package itself is working fine and there is absolute
no reason to get rid of it.

Last but not least: Gentoo is about choices. It's not your job to decide
what people should use. Sure, if you maintained a package and will stop
using it so it will become maintainer-needed and masked for removal at
some point because it's outdated, vulnerable and/or not working anymore,
that's OK. But if someone else will pick up this package... and
offlineimap in Gentoo is working and up-to-date.

Heck, we could even talk about how rude it is to force a maintainer to
drop its package. And yes, even p-m should be treated like real devs. So
you can't just kill their packages because you want to.


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

On Sat, Jun 20, 2020 at 1:36 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> On Sat, Jun 20, 2020 at 10:32:28AM +0200, Ulrich Mueller wrote:
> > >>>>> On Sat, 20 Jun 2020, Aaron Bauman wrote:
> >
> > >> # Aaron Bauman <bman@gentoo.org> (2020-06-20)
> > >> # Py2 only
> > >> # Removal in 14 days
> >
> > I see these short deadlines quite often recently. Any reason why this
> > can't be the usual 30 days?
> >
>
> Hi, Ulrich. Yes, the deadlines are meant to speed up the process as we
> have *roughly* 1000+ pkgs which must be converted to py3 or removed
> before we can drop the interpreter.
>

Wouldn't it make more sense to just file bugs on ALL the impacted
packages, wait a few weeks, and then makes ALL of them at once, with
the regular 30d deadline?

Or if filing bugs is administratively difficult then just post a list
with packages and maintainers on -dev - this has been done for changes
in the past.

Right now it seems like some maintainers are finding out that their
packages are impacted for the first time by having their packages
masked. That means that end-users get a package mask notice and start
taking action. Then a few days later the package is unmasked. Of
course, by then half the users have probably started migrating to
other packages - perhaps ones that are less suitable for them.

You seem to think that maintainers should know if they're maintaining
a v2-only package. I suspect that most maintainers don't pay that
close attention to what versions of python are supported by their
various packages, and neither do most users. If it runs then it runs,
and most don't care which interpreter is being used. I get that it
impacts the python team but we need to make these issues more visible
to maintainers.

Maintainers often have an assortment of packages, and probably don't
realize when any particular one has a particular python compatibility
issue.

If it is difficult for you to identify all the impacted packages, why
would it be any easier for a maintainer who has probably spent less
time than you hunting down v2-only packages?

It seems like we really need a better solution here. And just masking
a package without filing any bug beforehand doesn't really seem
in-line with policy. We don't even do that for serious security
vulnerabilities.

--
Rich

On Wed, 2020-06-24 at 11:52 +0200, Thomas Deutschmann wrote:
>
In the beginning of this month you just decided to disband graphics
> project. On your own. Please tell me what gave you the authority to just
> do that? You didn't even share your plan before executing it on any
> mailing list. Something that should be common sense, if not even necessary.

Surely, that could have been done better (and I don't like that bman
didn't contact me) but the repeated claims that it came out of nowhere
are plain bs. The bug for discussing what to do [1] was open for a year
and 3 months. The only person replying on the bug was maekke, and I
think I've talked with some other member on IRC but don't recall whom
exactly.

Now, I'm sorry if you feel like people didn't ask for your opinion.
However, if you really cared about graphics project then you should've
either joined the team or at least monitored the alias, and replied to
the bug. Attacking people because they executed the action nobody
objected to is not nice.

Again, I would like to remind you the golden rule: if you want something
to be the way you want it to be, do the work or convince somebody to do
it. Making unjustified demands of others, ignoring problems and then
complaining is not helping anyone. This applies to everyone, regular
developers and Council members alike.

[1] https://bugs.gentoo.org/681938

>
> The whole action was so destructive that you couldn't evenb just undo it
> because you also deleted stuff on Wiki.

He's not the first and not the last person to use wiki wrong. I'd argue
the problem is that MW is retarded and it's easy to get it wrong.

However, instead of using this as an excuse to strengthen your attack
you could've just pinged wiki admins to restore the page (hey, we don't
monitor everything that happens on the wiki!). This is done now, enjoy.

> A mask is destructive and requires user interaction. Therefore a mask
> isn't something to play with, "Oh, let's test if someone will
> complain... it's just a mask, we can just unmask in case...".

Didn't you just argue against using any information to drive decisions
on package removal? Then indeed masks are the only tool we have.

--
Best regards,
Micha? Górny

On Sat, Jun 20, 2020 at 12:24 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> On Sat, Jun 20, 2020 at 01:29:46PM +0200, Thomas Deutschmann wrote:
> > On 2020-06-20 12:07, Micha? Górny wrote:
> > >> Al least, python2 is not on your list.
> > >>
> > >> Be first into the future by masking this stuff and
> > >> Last out of the past by leaving up to users to decide.
> > >> It could stay in the tree, masked, as long as python2.
> > >>
> > >
> > > Do you really think it'd be better to last rite a 1000 packages
> > > simultaneously?
> >
> > What's the purpose of this at all?
> >
> > dev-lang/python:2.7 won't go away that soon.
> >
> > Removing perfectly working and up-to-date software which is in
> > maintenance-only mode like net-mail/offlineimap is just not user-friendly.
> >
> > It doesn't even has deps on other Python packages blocking your cleanup
> > delusion.
> >
>
> Thomas, unfortunately, I am shocked at your choice of words here. I
> think it is reasonable that any developer would understand a lack
> of forward momentum in removing Py2 only packages only drives
> stagnation.
>
> If you have a more effective method to doing so, I am open to
> suggestions.

Between the disagreements about whether a package should be masked,
the length of time the last rites period should be, and the steps
required to disband a project, I think there's been enough pushback
that it's necessary to change how you approach these projects.

Please start by using the standard 30-day last rites period. It's a
simple thing and whether the packages are in tree for an additional 16
days should not affect any of your work.

> re: net-mail/offlineimap... there are alternatives.

Removing python2_7 support from the tree is a valuable goal, but
offlineimap is widely used and blocks no further work. It can easily
remain in the tree after all other python2_7 support is gone.

This is not a hill worth dying on.

On Wed, Jun 24, 2020 at 2:52 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
> On 2020-06-20 21:24, Aaron Bauman wrote:
> > Thomas, unfortunately, I am shocked at your choice of words here. I
> > think it is reasonable that any developer would understand a lack
> > of forward momentum in removing Py2 only packages only drives
> > stagnation.
> >
> > If you have a more effective method to doing so, I am open to
> > suggestions.
>
> Like I am shocked about your recent actions:

I'm shocked that you're shocked that he's shocked!

Let's stop the theatrics.

On Wednesday, 24 June 2020 13:19:08 CEST Rich Freeman wrote:
> You seem to think that maintainers should know if they're maintaining
> a v2-only package. I suspect that most maintainers don't pay that
> close attention to what versions of python are supported by their
> various packages, and neither do most users.

I would expect exactly that of maintainers. By now, there has been py27-EOL
mail on this list aplenty for everyone to get the message.

Instead, every single maintainer should already have removed py27 from
defaults and be actively cutting down the resulting package.use list of those
packages they maintain and if necessary also their dependencies.

On Wed, 2020-06-24 at 19:48 +0200, Andreas Sturmlechner wrote:
> On Wednesday, 24 June 2020 13:19:08 CEST Rich Freeman wrote:
> > You seem to think that maintainers should know if they're maintaining
> > a v2-only package. I suspect that most maintainers don't pay that
> > close attention to what versions of python are supported by their
> > various packages, and neither do most users.
>
> I would expect exactly that of maintainers. By now, there has been py27-EOL
> mail on this list aplenty for everyone to get the message.
>
> Instead, every single maintainer should already have removed py27 from
> defaults and be actively cutting down the resulting package.use list of those
> packages they maintain and if necessary also their dependencies.

I think you're making the wrong assumption that Gentoo developers run
bleeding edge systems. Instead, many of them prefer running stable
and avoiding anything even remotely problematic.

--
Best regards,
Micha? Górny

On Wednesday, 24 June 2020 20:03:57 CEST Micha? Górny wrote:
> I think you're making the wrong assumption that Gentoo developers run
> bleeding edge systems. Instead, many of them prefer running stable
> and avoiding anything even remotely problematic.

That's not a contradiction for stable systems where I am using py38 as default
today already, and if it leads to more stable requests (without me ending up
having to do it) then even better.

The lack of curiosity for one's own packages' python compatibility is not just
a py27 isolated issue, it was a big problem with py36 -> py37 with so many
devs simply not filing that necessary stabilisation.

On Wed, Jun 24, 2020 at 2:18 PM Andreas Sturmlechner <asturm@gentoo.org> wrote:
>
> The lack of curiosity for one's own packages' python compatibility is not just
> a py27 isolated issue, it was a big problem with py36 -> py37 with so many
> devs simply not filing that necessary stabilisation.

That suggests that if you keep doing what you're doing, you're going
to keep hitting your head against the wall.

Right now in Gentoo there isn't really even a straightforward way for
a maintainer to cleanly obtain a list of all the packages they
maintain, let alone whether they use python v2.

Sure, you can use the portage API to find this info. However, that is
as easy to do for a list of all impacted packages in the tree with
their maintainers as for any individual maintainer to obtain this info
for their own packages.

I think that if you give the maintainers a bit more info, you'll find
them being more proactive about helping you out. Basically you would
be helping them help you.

Otherwise you're going to mask a bunch of packages and run into a
bunch of upset devs, and as a byproduct we create a bunch of upset
users.

There is no reason to mask a package only to unmask it a few days
later. Masks are a mechanism for deprecating packages so that users
take action. They're not a substitute for devs talking to each other.

--
Rich

On Wed, Jun 24, 2020 at 11:29 AM Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, Jun 24, 2020 at 2:18 PM Andreas Sturmlechner <asturm@gentoo.org>
> wrote:
> >
> > The lack of curiosity for one's own packages' python compatibility is
> not just
> > a py27 isolated issue, it was a big problem with py36 -> py37 with so
> many
> > devs simply not filing that necessary stabilisation.
>
> That suggests that if you keep doing what you're doing, you're going
> to keep hitting your head against the wall.
>
> Right now in Gentoo there isn't really even a straightforward way for
> a maintainer to cleanly obtain a list of all the packages they
> maintain, let alone whether they use python v2.
>

> Sure, you can use the portage API to find this info. However, that is
> as easy to do for a list of all impacted packages in the tree with
> their maintainers as for any individual maintainer to obtain this info
> for their own packages.
>

You say there is not a straightforward way, but then you say there is an
api? :p


>
> I think that if you give the maintainers a bit more info, you'll find
> them being more proactive about helping you out. Basically you would
> be helping them help you.
>
> Otherwise you're going to mask a bunch of packages and run into a
> bunch of upset devs, and as a byproduct we create a bunch of upset
> users.
>

Extend the existing QA report?

https://qa-reports.gentoo.org/output/gpyutils/py2.txt

There is a list of py2 only packages. We just need to add the maintainer
metadata?


>
> There is no reason to mask a package only to unmask it a few days
> later. Masks are a mechanism for deprecating packages so that users
> take action. They're not a substitute for devs talking to each other.
>

> --
> Rich
>
>

On Wed, Jun 24, 2020 at 2:40 PM Alec Warner <antarus@gentoo.org> wrote:
>
> On Wed, Jun 24, 2020 at 11:29 AM Rich Freeman <rich0@gentoo.org> wrote:
>>
>> Sure, you can use the portage API to find this info. However, that is
>> as easy to do for a list of all impacted packages in the tree with
>> their maintainers as for any individual maintainer to obtain this info
>> for their own packages.
>
>
> You say there is not a straightforward way, but then you say there is an api? :p
>

Yeah - the number of people around here who have used it is pretty
small. My point though is that if you've done that work it is easiest
to just do it once for everybody.

> Extend the existing QA report?
>
> https://qa-reports.gentoo.org/output/gpyutils/py2.txt
>
> There is a list of py2 only packages. We just need to add the maintainer metadata?

Exactly.

I decided to get off my rear end and try to contribute a bit. See the
attachments. Script adapted from my ancient (ironically v2-only)
script to find missing slot op deps. Contents are meant to inform,
and not to shame (mostly)...

--
Rich

> On Wed, Jun 24, 2020 at 11:29 AM Rich Freeman <rich0@gentoo.org> wrote:
> > Sure, you can use the portage API to find this info. However, that is
> > as easy to do for a list of all impacted packages in the tree with
> > their maintainers as for any individual maintainer to obtain this info
> > for their own packages.

I'm appealing to a more proactive maintenance, not in search for excuses why
it is not like that. And ftr I don't mean trying to be "first!" on every
upstream version bump; it is just that the python topic has come up often
enough that it should have sparked individual head scratching at one point or
another.

> On Wednesday, 24 June 2020 20:40:58 CEST Alec Warner wrote:
> You say there is not a straightforward way, but then you say there is an
> api? :p

grep all the things! But hey, there's even external tools to help you get an
overview:

https://repology.org/maintainer/rich0%40gentoo.org

You're welcome.

On Wed, Jun 24, 2020 at 3:04 PM Andreas Sturmlechner <asturm@gentoo.org> wrote:
>
> > On Wed, Jun 24, 2020 at 11:29 AM Rich Freeman <rich0@gentoo.org> wrote:
> > > Sure, you can use the portage API to find this info. However, that is
> > > as easy to do for a list of all impacted packages in the tree with
> > > their maintainers as for any individual maintainer to obtain this info
> > > for their own packages.
>
> I'm appealing to a more proactive maintenance, not in search for excuses why
> it is not like that. And ftr I don't mean trying to be "first!" on every
> upstream version bump; it is just that the python topic has come up often
> enough that it should have sparked individual head scratching at one point or
> another.
>
> > On Wednesday, 24 June 2020 20:40:58 CEST Alec Warner wrote:
> > You say there is not a straightforward way, but then you say there is an
> > api? :p
>
> grep all the things! But hey, there's even external tools to help you get an
> overview:
>
> https://repology.org/maintainer/rich0%40gentoo.org
>
> You're welcome.

I'm well aware of that. That will get you a list of what you
maintain, but not which of those things use python2. It is also
completely external. (I do love that tool though - great for finding
bumps.)

grep is really not a reliable tool for parsing ebuilds. The API is
really the right way to do it.

What I was getting at though is that just posting a big list up-front
will probably get more results than just telling everybody to try to
figure out if they're impacted.

(Also, I noticed that the list I sent out earlier contained some
overlay-only packages - probably best to re-run it on a clean
repository. Since it uses the API it sees everything portage sees,
including overlays.)

--
Rich