[gentoo-dev] Tools and stuff
Hello everyone, Several developers have loudly complained about the recent Py2 masks and the subsequent timeline for removal. As such, I want to *inform* you of some tools to help and why the timeline was chosen. First, there is some awesome tooling, hosted by infra, that can aid you in identifying Py2 only packages. Currently, it does not list each package along with a maintainer, but it does identify packages which are Py2 only [1]. Additionally, Michal even generates a sweet graphic for those wishing to see the tree view of RDEPS/DEPS/BDEPS/etc [2]... it isn't perfect... so please do double check, but it helps in identifying potential candidates. Second, the reason for choosing 14 day removal periods was simply to speed up the process of removal. Given the latest filing of a QA bug, these will now default to the mandated 30+ day removal period. However, I would offer that all developers should review the below references and understand that removing Py2 is a very long process. As such, the current masks are an attempt to abide by the the security and deprecation timeline of Py2. Please assist the Python team and the larger Gentoo community in making an effort to rid ::gentoo (mainline tree) of dev-lang/python:2.7. Also, please understand the deprecation of subsequent dev-lang/python:3* interpreters which have bugs being filed against them now. The breadth of such an understaking is understated with the continual move upstream to new versions. As a "rolling distribution" it becomes much more difficult for us to make such "muscle movements" without interruption. Finally, please check out the infra hosted tooling at https://qa-reports.gentoo.org which has many other sections that run various QA checks for Gentoo. [1]: https://qa-reports.gentoo.org/output/gpyutils/py2.txt [2]: https://qa-reports.gentoo.org/output/gpyutils/py2.svg -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On Fri, Jun 26, 2020 at 01:48:31PM -0400, Aaron Bauman wrote: > So, thanks for proving my point that all the tooling changes, notices, > ML posts, etc don't matter. Someone *will* find something to complain > about. They will also complain about the status quo, you won't win there! > >2. The report does not list maintainers, which means nobody is likely > >to know they have a package on the list. > > > > Do you argue just to argue? Sad. If someone like Robin (who at one > point had like 5% of the tree under his maintainer ship) complained > about that I may see it worthwhile. Some of the packages shown on the py27 list I had LONG forgotten that I maintained: I'll try and get to fixing them now. I did q-text-as-data this week, because I actually needed it for a quick project and I haven't used it since I changed my default python away from py27 last month. > Just another red herring... I'm mostly speaking to the QA team here, and Python team indirectly: Indirectly because the Python team is one of the few teams to step up and provide QA checks outside of the QA team directly. This thread however has shown that output of those checks however needs to become easier to consume. TL;DR: Please make it easier to search on the QA reports site for issues, and only show things directly relevant to the search. A long time ago, there was blizzy's site that listed packages that were stabilization candidates, and you could filter by developer. It really helped making it easier to detect and progress. At a bare minimum, having an on-site way that already expands the data and makes it searchable by developer. Have files like https://qa-reports.gentoo.org/output/gpyutils/py2.txt directly loaded into qa-reports and expanded out (which is cachable) and then let devs search w/ their browser. cat/package:slot (reason) (all-direct-maintainers),(expanded-projects) get-git-file.sh tries very hard to get there for the gentoo-ci output, needs performance and usability improvements, but it's vastly better than the py2.txt file already. Some issues: - Make it more visible! Right now you have to have a link to it from somewhere else, and it doesn't accept a branch name (https://qa-reports.gentoo.org/output/gentoo-ci/HEAD/output.html returns 404) - Why does it take 15 seconds to load? - Add filter by developers (by direct maintainer OR membership in alias) - Add filter by package/cat - Add filter by check name - Machine-readable format should be the same data as human-readable (I can't just take the .xml and grep it, it doesn't have maintainers at all) > >> See above. Qa-reports will output a very nice list (even a graphic!) > >of such things. Anyway, yes, I do expect devs to understand their > >packages state if they maintain it. Don't be so myopic. > > > >Well, you can expect whatever you want, and then you can be frustrated > >out of your mind when 95% of devs fail to meet your expectations. > > > I am not frustrated. I will continue to perform the same in intervals to > drive the removal of Py2. Can we have that graphic in a searchable text format? <3. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, Jun 26, 2020 at 10:02:34PM +0100, Sergei Trofimovich wrote: > A few points: > > 1. "only supports Py2" does not seem to warrant to mask leaf packages >and contradicts to Michał's explanation of cleanup effort: > See > https://archives.gentoo.org/gentoo-dev/message/04d419ebef01e80a43fc3b301e11afb6 >Please reconcile the goals within the python@ team. Ask team lead >if not sure and provide clear guidance for others. "only supports Py2" >is not good enough explanation. > >Leaf packages should be able to stay up to 2021-01-01, no? I'd suggest >adding them to packages.deprecated instead. > Yes, it does warrant it. As we must remove/convert all leaf packages before the interpreter can be safely removed. I believe Michal clarified this in another email. It is a continuous effort... > 2. I decided to drop python support in a hurry to unbreak world upgrade >for users and myself. If I had some time I would prefer to do that in >higher confidence and have a chance to look at python3 support in the >package. >But now I chucked python2 scripting entirely probably breaking a few >users. I don't see it as a good thing. > >After Michał's explanation I am considering to restore python2 support >while I investigate python3 support feasibility. > > Thus no. Not "All done". We will probably have exactly the same conversation > next month if nothing changes in the process. > Restore the py2 support then and convert it to py3 as required. We have a long ways to go... sorry your package got caught up in the mix... > > There is no discrimination of which packages get masked and when. > > I fail to interpret this phrase. Does it mean you are about to mask all > python2-only packages ~now-ish? > Sorry for the misunderstanding/language barrier. Yes, the intent is to rid the tree if py2 dependent packages. We have been doing this in incremental stages in order to allow developers time to "save" packages as needed. Generally, most packages go away, but occasionally packages such as this wind up in the fold... This is because there are a myriad of packages out there... it would take *years* to rid the tree of them any other way. > > Additionally, masking seems to drive the attention vice all the other > > discussions, bugs, etc. > > I am not a native English speaker. I don't know what exactly this phrase > means. > It simply means that masking packages gains the attention of developers to drop Python support, convert their packages to py3, or let it go away. Opening a bug for the 1k+ packages would be time consuming and mostly meaningless. Again, the numbers from every "round" of masks have shown that the *vast* majority of packages simply get removed. > It's not hard to get an attention by filing a bug against maintainer. > I personally read my bugs and try to act on them. I believe devs are still > required to have Bugzilla account. > Yes, you may respond along with a few other devs. Again, pure numbers here... most packages just get tree cleaned. Few get "saved." > > As we can see, folks will complain no matter what method is used. I could > > spend my days opening bugs and hoping for a response, yelling loudly on the > > ML for others to "pitch in" etc. > > I totally understand where the frustration comes from. If you > decided to do everything an your own it's challenging. > > Moreover, I'm actively willing to fix whatever problems packages > I maintain have. I just need to know about them. Preferably slightly > before the change impacts users. > Thank you. Yes, please check your Py2 packages and convert/rid of them as required. > Support for what you are doing? I'm sure if devs agree > on the ultimate goals you want to achieve you will get all the support. > There are a few *loud* voices that don't agree. Most others are very quiet. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 2020-06-26 at 22:02 +0100, Sergei Trofimovich wrote: > On Fri, 26 Jun 2020 13:41:13 -0400 > Aaron Bauman wrote: > > > On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich > > wrote: > > > On Fri, 26 Jun 2020 11:38:58 +0200 > > > Michał Górny wrote: > > > > > > > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > > > > On Fri, 26 Jun 2020 07:29:45 + > > > > > Michał Górny wrote: > > > > > > > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > napisał(a): > > > > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > > > > Sergei Trofimovich wrote: > > > > > > > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > > > > Michał Górny wrote: > > > > > > > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich > > > wrote: > > > > > > > > > > Give maintainers the chance to act and flag packages that > > > pull in > > > > > > > python:2.7. > > > > > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > > > > > --- > > > > > > > > > > profiles/package.deprecated | 4 > > > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > > > > b/profiles/package.deprecated > > > > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > > > > --- a/profiles/package.deprecated > > > > > > > > > > +++ b/profiles/package.deprecated > > > > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > > > > > +# Deprecated. Consider poring to python 3 and drop > > > support for > > > > > > > python2. > > > > > > > > > > +dev-lang/python:2.7 > > > > > > > > > > + > > > > > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > > > provider. > > > > > > > > > > # Use that instead. Or even better use none of them. > > > It's a > > > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > > > > Python 2.7, as well as these that support 2.7 in addition > > > to 3 > > > > > > > because > > > > > > > > > they have 2.7 deps. > > > > > > > > > > > > > > > > If we expect actions by developers on both cases I don't see > > > a > > > > > > > problem with that. > > > > > > > > > > > > > > Pushed as: > > > > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > > > > > > > with full text being: > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-26) > > > > > > > +# Deprecated. > > > > > > > +# - optional python:2.7 dependency should be dropped if no > > > reverse > > > > > > > +# dependencies are using it. > > > > > > > +# - mandatory python:2.7 depepndency will require package > > > porting > > > > > > > +# or package removal if no reverse dependencies are using > > > it. > > > > > > > +dev-lang/python:2.7 > > > > > > > > > > > > You've just introduced 829 CI warnings > > > > > > > > > > That's the intention. > > > > > > > > > > > effectively disabling the ability to distinguish *new* problems > > > in these packages. > > > > > Correct. Citing above: > > > > > > > > > > "If we expect actions by developers on both cases I don't see a > > > problem with that." > > > > > I assume we still do. > > > > > > > > Not exactly. You've pinpointed the wrong target. > > > > > > > > First of all, we want people to support Python 3. Removing support > > > for > > > > Python 2 is a secondary goal. > > > > > > What is the desired end state here? All packages that depend on > > > python should support python3? > > > > > > > Flagging packages that support Python 2 in addition to Python 3 > > > > and cause no trouble in py2 cleanup is doubtful. > > > > > > What is "py2 cleanup"? I still struggle to understand what packages > > > require change and which do not. Is there one pager doc that explains > > > a few things for me: > > > - How packages are picked for masking? Maybe we can deprecate them > > > instead? Or we (I) can write a bit of code that flags packages > > > requiring > > > maintainers' attention. > > > - What is the expected end state for the "py2 cleanup"? > > > > > > The doc would also be a good link to add to recently added "# Py2 only" > > > masks as well. > > > > > > > Flagging packages that support 2+3 because of their revdeps is not > > > > helpful at all. It's just noise to the maintainer who can't remove > > > py2 > > > > because of revdeps. > > > > > > I agree it can be spammy if we expect to have many packages with > > > python2 support for an extended period of time (3+ months). If it's > > > seen by others as too noisy I can re
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 13:41:13 -0400 Aaron Bauman wrote: > On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich > wrote: > >On Fri, 26 Jun 2020 11:38:58 +0200 > >Michał Górny wrote: > > > >> On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > >> > On Fri, 26 Jun 2020 07:29:45 + > >> > Michał Górny wrote: > >> > > >> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > napisał(a): > >> > > > On Sat, 20 Jun 2020 16:29:53 +0100 > >> > > > Sergei Trofimovich wrote: > >> > > > > >> > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > >> > > > > Michał Górny wrote: > >> > > > > > >> > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich > >wrote: > >> > > > > > > Give maintainers the chance to act and flag packages that > >pull in > >> > > > python:2.7. > >> > > > > > > Signed-off-by: Sergei Trofimovich > >> > > > > > > --- > >> > > > > > > profiles/package.deprecated | 4 > >> > > > > > > 1 file changed, 4 insertions(+) > >> > > > > > > > >> > > > > > > diff --git a/profiles/package.deprecated > >> > > > b/profiles/package.deprecated > >> > > > > > > index a756e845f47..bb661571962 100644 > >> > > > > > > --- a/profiles/package.deprecated > >> > > > > > > +++ b/profiles/package.deprecated > >> > > > > > > @@ -17,6 +17,10 @@ > >> > > > > > > > >> > > > > > > #--- END OF EXAMPLES --- > >> > > > > > > > >> > > > > > > +# Sergei Trofimovich (2020-06-20) > >> > > > > > > +# Deprecated. Consider poring to python 3 and drop > >support for > >> > > > python2. > >> > > > > > > +dev-lang/python:2.7 > >> > > > > > > + > >> > > > > > > # Sergei Trofimovich (2020-02-22) > >> > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > >provider. > >> > > > > > > # Use that instead. Or even better use none of them. > >It's a > >> > > > > > > >> > > > > > >> > > > > > It will trigger the same for packages that support *only* > >> > > > > > Python 2.7, as well as these that support 2.7 in addition > >to 3 > >> > > > because > >> > > > > > they have 2.7 deps. > >> > > > > > >> > > > > If we expect actions by developers on both cases I don't see > >a > >> > > > problem with that. > >> > > > > >> > > > Pushed as: > >> > > > > >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > >> > > > with full text being: > >> > > > > >> > > > +# Sergei Trofimovich (2020-06-26) > >> > > > +# Deprecated. > >> > > > +# - optional python:2.7 dependency should be dropped if no > >reverse > >> > > > +# dependencies are using it. > >> > > > +# - mandatory python:2.7 depepndency will require package > >porting > >> > > > +# or package removal if no reverse dependencies are using > >it. > >> > > > +dev-lang/python:2.7 > >> > > > >> > > You've just introduced 829 CI warnings > >> > > >> > That's the intention. > >> > > >> > > effectively disabling the ability to distinguish *new* problems > >in these packages. > >> > > >> > Correct. Citing above: > >> > > >> > "If we expect actions by developers on both cases I don't see a > >problem with that." > >> > > >> > I assume we still do. > >> > >> Not exactly. You've pinpointed the wrong target. > >> > >> First of all, we want people to support Python 3. Removing support > >for > >> Python 2 is a secondary goal. > > > >What is the desired end state here? All packages that depend on > >python should support python3? > > > >> Flagging packages that support Python 2 in addition to Python 3 > >> and cause no trouble in py2 cleanup is doubtful. > > > >What is "py2 cleanup"? I still struggle to understand what packages > >require change and which do not. Is there one pager doc that explains > >a few things for me: > >- How packages are picked for masking? Maybe we can deprecate them > >instead? Or we (I) can write a bit of code that flags packages > >requiring > > maintainers' attention. > >- What is the expected end state for the "py2 cleanup"? > > > >The doc would also be a good link to add to recently added "# Py2 only" > >masks as well. > > > >> Flagging packages that support 2+3 because of their revdeps is not > >> helpful at all. It's just noise to the maintainer who can't remove > >py2 > >> because of revdeps. > > > >I agree it can be spammy if we expect to have many packages with > >python2 support for an extended period of time (3+ months). If it's > >seen by others as too noisy I can revert the commit now. > > > >> Flagging dev-python/pypy* which needs py2 but is entirely outside > >> the eclass system is not helpful at all. > > > >To pick a concrete example: from what I read above I don't see why > >app-misc/golly was masked for removal. > > It was masked because it only supports Py2. The maintainer (you) decided to > drop Python script support. Problem solved. Easy day. All
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 19:17:50 +0200 Michał Górny wrote: > On Fri, 2020-06-26 at 17:47 +0100, Sergei Trofimovich wrote: > > On Fri, 26 Jun 2020 11:38:58 +0200 > > Michał Górny wrote: > > > > > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > > > On Fri, 26 Jun 2020 07:29:45 + > > > > Michał Górny wrote: > > > > > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > > > napisał(a): > > > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > > > Sergei Trofimovich wrote: > > > > > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > > > Michał Górny wrote: > > > > > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > > > > > > > > > > > > > > > Give maintainers the chance to act and flag packages that > > > > > > > > > pull in > > > > > > python:2.7. > > > > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > > > > --- > > > > > > > > > profiles/package.deprecated | 4 > > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > > > b/profiles/package.deprecated > > > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > > > --- a/profiles/package.deprecated > > > > > > > > > +++ b/profiles/package.deprecated > > > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > > > > +# Deprecated. Consider poring to python 3 and drop support > > > > > > > > > for > > > > > > python2. > > > > > > > > > +dev-lang/python:2.7 > > > > > > > > > + > > > > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > > > > > > > > > provider. > > > > > > > > > # Use that instead. Or even better use none of them. It's a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > > > Python 2.7, as well as these that support 2.7 in addition to 3 > > > > > > > > > > > > > > because > > > > > > > > they have 2.7 deps. > > > > > > > > > > > > > > If we expect actions by developers on both cases I don't see a > > > > > > > > > > > > > problem with that. > > > > > > > > > > > > Pushed as: > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > > > with full text being: > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-26) > > > > > > +# Deprecated. > > > > > > +# - optional python:2.7 dependency should be dropped if no reverse > > > > > > +# dependencies are using it. > > > > > > +# - mandatory python:2.7 depepndency will require package porting > > > > > > +# or package removal if no reverse dependencies are using it. > > > > > > +dev-lang/python:2.7 > > > > > > > > > > You've just introduced 829 CI warnings > > > > > > > > That's the intention. > > > > > > > > > effectively disabling the ability to distinguish *new* problems in > > > > > these packages. > > > > > > > > Correct. Citing above: > > > > > > > > "If we expect actions by developers on both cases I don't see a > > > > problem with that." > > > > > > > > I assume we still do. > > > > > > Not exactly. You've pinpointed the wrong target. > > > > > > First of all, we want people to support Python 3. Removing support for > > > Python 2 is a secondary goal. > > > > What is the desired end state here? All packages that depend on > > python should support python3? > > Yes, or be masked for removal. The desired result is that at some point > in time we can disable py2 target in eclass without anything breaking. That helps. Thanks. > > > Flagging packages that support Python 2 in addition to Python 3 > > > and cause no trouble in py2 cleanup is doubtful. > > > > What is "py2 cleanup"? I still struggle to understand what packages > > require change and which do not. Is there one pager doc that explains > > a few things for me: > > Some of this is mentioned in Python Guide [1]. > > [1] > https://dev.gentoo.org/~mgorny/python-guide/package-maintenance.html#support-for-python-2 > > > - How packages are picked for masking? Maybe we can deprecate them > > instead? Or we (I) can write a bit of code that flags packages requiring > > maintainers' attention. > > This is really decided by humans, and I don't think it can be trivially > automated. So far we've focused on masking packages that are either > a. unlikely to be ported (e.g. dead upstream), b. have no Gentoo > maintainers. I see. That will probably mean package masking confusion will be brought up again and again. Well, so be it. It least I'll hopefully be aware of it next time :) > > - What is the expected end state for the "py2 cleanup"?
Re: [gentoo-dev] */*: Mask Py2 only packages
On June 26, 2020 11:08:35 AM EDT, Rich Freeman wrote: >On Fri, Jun 26, 2020 at 10:36 AM Aaron Bauman wrote: >> >> On June 26, 2020 7:13:07 AM EDT, Rich Freeman >wrote: >> >> Of all the methods listed in the previous posts, the QA reports, >etc. >> >> there is no excuse individuals can't find out if their package is >py2 >> >> only. >> > >> >None of those methods were posted until a day or two ago, and the >> >python team has done nothing to actually ensure all the impacted >> >maintainers are aware of them. Perhaps a communication to >> >-dev-announce with the preferred approach would be better? >> > >> >> You should also look at qa-reports. Do we really need to *teach* >others "how to fish" here? Why can't folks just ask for assistance? > >Just looked at it: > >1. I had no idea that a list of py2-only packages was listed there. >I don't think I've ever actually looked at that page. > Perfect, so you have just shown that you either didn't see the ML posts about QA tools, didn't care to ask other devs what tools are available etc. If history serves me right, qa-reports has existed for many years (of which I have used it) and mgorny often let's folks know about changes to it (e.g. pkgcore). So, thanks for proving my point that all the tooling changes, notices, ML posts, etc don't matter. Someone *will* find something to complain about. >2. The report does not list maintainers, which means nobody is likely >to know they have a package on the list. > Do you argue just to argue? Sad. If someone like Robin (who at one point had like 5% of the tree under his maintainer ship) complained about that I may see it worthwhile. Just another red herring... >> >> See above. Qa-reports will output a very nice list (even a graphic!) >of such things. Anyway, yes, I do expect devs to understand their >packages state if they maintain it. Don't be so myopic. > >Well, you can expect whatever you want, and then you can be frustrated >out of your mind when 95% of devs fail to meet your expectations. > I am not frustrated. I will continue to perform the same in intervals to drive the removal of Py2. >Or you could just work with them where they're at and maybe get your >project completed more quickly and with less effort... > ::yawn:: see above remarks showing how folks will find a way to complain. >If you want people to look at a qa-report, maybe post on -dev-announce >and ask everybody to do it? Most people aren't going to be following >all the tools used by the python team if they aren't python devs. > >> >At least some devs here seemed surprised about the masks. Did you >try >> >filing a bug? >> >> Have you looked for said bugs? > >Of course. Do you think I'd invite such an obvious reply without >actually checking. > >I just went to the first complaint on this list about there not being >a bug, and verified that there wasn't a bug. > >As far as I can tell there is no bug for app-misc/golly. If I missed >one feel free to cite it. > >> >> > >> >Masking something for all users is basically like torturing a kitten >> >to get the attention of its owner. It is a necessary step if the >> >package is actually to be removed. I don't think it is even >allowable >> >under our policies if no bug was filed. >> > >> >> Do tell where said policy is? > >https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html > >Granted, a mask isn't a package commit, but I think the spirit of the >policy covers it. > >In any case, there is no reason not to communicate with a maintainer >before touching a package. That should involve something more than a >generic notice that everybody should become a detective to figure out >if they are covered by an upcoming change. If you have a list of >impacted packages, then just file bugs against them. > >> >> Nothing is really hard about masking packages for removal... >honestly. > >The complaint isn't that masks are hard on you. The complaint is that >it bombards users with unnecessary warnings. > Sadly, many users have contributed more than some devs to fix packages. I often get emails directly from users wanting to fix things. I will start forwarding them to you. >> The work comes in defending the position here for the few that >complain. > >And how are you enjoying doing all that extra work? Would you prefer >if devs started opening up QA/Comrel bugs that you then have to >formally respond to? > There is one open now. Seems QA hasn't spoken up yet... >Or maybe you could try notifying devs before masking their packages? > >> If I filed a bug... they would complain or not respond... If I sent >out a dev-announce they would complain or not respond. > >Sometimes, sure. But at least you would have gone through due >process, and you're unlikely to get much push back. > >And I suspect a number of those packages would actually get fixed. > >> >> You see the fun here? Which method is effective? Mask a 100 packages >for removal... Someone complains... A f
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich wrote: >On Fri, 26 Jun 2020 11:38:58 +0200 >Michał Górny wrote: > >> On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: >> > On Fri, 26 Jun 2020 07:29:45 + >> > Michał Górny wrote: >> > >> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > napisał(a): >> > > > On Sat, 20 Jun 2020 16:29:53 +0100 >> > > > Sergei Trofimovich wrote: >> > > > >> > > > > On Sat, 20 Jun 2020 16:05:38 +0200 >> > > > > Michał Górny wrote: >> > > > > >> > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich >wrote: >> > > > > > > Give maintainers the chance to act and flag packages that >pull in >> > > > python:2.7. >> > > > > > > Signed-off-by: Sergei Trofimovich >> > > > > > > --- >> > > > > > > profiles/package.deprecated | 4 >> > > > > > > 1 file changed, 4 insertions(+) >> > > > > > > >> > > > > > > diff --git a/profiles/package.deprecated >> > > > b/profiles/package.deprecated >> > > > > > > index a756e845f47..bb661571962 100644 >> > > > > > > --- a/profiles/package.deprecated >> > > > > > > +++ b/profiles/package.deprecated >> > > > > > > @@ -17,6 +17,10 @@ >> > > > > > > >> > > > > > > #--- END OF EXAMPLES --- >> > > > > > > >> > > > > > > +# Sergei Trofimovich (2020-06-20) >> > > > > > > +# Deprecated. Consider poring to python 3 and drop >support for >> > > > python2. >> > > > > > > +dev-lang/python:2.7 >> > > > > > > + >> > > > > > > # Sergei Trofimovich (2020-02-22) >> > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 >provider. >> > > > > > > # Use that instead. Or even better use none of them. >It's a >> > > > > > >> > > > > >> > > > > > It will trigger the same for packages that support *only* >> > > > > > Python 2.7, as well as these that support 2.7 in addition >to 3 >> > > > because >> > > > > > they have 2.7 deps. >> > > > > >> > > > > If we expect actions by developers on both cases I don't see >a >> > > > problem with that. >> > > > >> > > > Pushed as: >> > > > >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 >> > > > with full text being: >> > > > >> > > > +# Sergei Trofimovich (2020-06-26) >> > > > +# Deprecated. >> > > > +# - optional python:2.7 dependency should be dropped if no >reverse >> > > > +# dependencies are using it. >> > > > +# - mandatory python:2.7 depepndency will require package >porting >> > > > +# or package removal if no reverse dependencies are using >it. >> > > > +dev-lang/python:2.7 >> > > >> > > You've just introduced 829 CI warnings >> > >> > That's the intention. >> > >> > > effectively disabling the ability to distinguish *new* problems >in these packages. >> > >> > Correct. Citing above: >> > >> > "If we expect actions by developers on both cases I don't see a >problem with that." >> > >> > I assume we still do. >> >> Not exactly. You've pinpointed the wrong target. >> >> First of all, we want people to support Python 3. Removing support >for >> Python 2 is a secondary goal. > >What is the desired end state here? All packages that depend on >python should support python3? > >> Flagging packages that support Python 2 in addition to Python 3 >> and cause no trouble in py2 cleanup is doubtful. > >What is "py2 cleanup"? I still struggle to understand what packages >require change and which do not. Is there one pager doc that explains >a few things for me: >- How packages are picked for masking? Maybe we can deprecate them >instead? Or we (I) can write a bit of code that flags packages >requiring > maintainers' attention. >- What is the expected end state for the "py2 cleanup"? > >The doc would also be a good link to add to recently added "# Py2 only" >masks as well. > >> Flagging packages that support 2+3 because of their revdeps is not >> helpful at all. It's just noise to the maintainer who can't remove >py2 >> because of revdeps. > >I agree it can be spammy if we expect to have many packages with >python2 support for an extended period of time (3+ months). If it's >seen by others as too noisy I can revert the commit now. > >> Flagging dev-python/pypy* which needs py2 but is entirely outside >> the eclass system is not helpful at all. > >To pick a concrete example: from what I read above I don't see why >app-misc/golly was masked for removal. It was masked because it only supports Py2. The maintainer (you) decided to drop Python script support. Problem solved. Easy day. All done. As discussed elsewhere, there are tools to show which packages only support Py2 etc. There is no discrimination of which packages get masked and when. Additionally, masking seems to drive the attention vice all the other discussions, bugs, etc. As we can see, folks will complain no matter what method is used. I could spend my days opening bugs and hoping for a response, yelling loudly on the ML for others to "pit
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 2020-06-26 at 17:47 +0100, Sergei Trofimovich wrote: > On Fri, 26 Jun 2020 11:38:58 +0200 > Michał Górny wrote: > > > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > > On Fri, 26 Jun 2020 07:29:45 + > > > Michał Górny wrote: > > > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > > napisał(a): > > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > > Sergei Trofimovich wrote: > > > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > > Michał Górny wrote: > > > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > > > > > > Give maintainers the chance to act and flag packages that pull > > > > > > > > in > > > > > python:2.7. > > > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > > > --- > > > > > > > > profiles/package.deprecated | 4 > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > > b/profiles/package.deprecated > > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > > --- a/profiles/package.deprecated > > > > > > > > +++ b/profiles/package.deprecated > > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > > > +# Deprecated. Consider poring to python 3 and drop support for > > > > > > > > > > > > > python2. > > > > > > > > +dev-lang/python:2.7 > > > > > > > > + > > > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > > > > > > > > provider. > > > > > > > > # Use that instead. Or even better use none of them. It's a > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > > Python 2.7, as well as these that support 2.7 in addition to 3 > > > > > because > > > > > > > they have 2.7 deps. > > > > > > > > > > > > If we expect actions by developers on both cases I don't see a > > > > > problem with that. > > > > > > > > > > Pushed as: > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > > with full text being: > > > > > > > > > > +# Sergei Trofimovich (2020-06-26) > > > > > +# Deprecated. > > > > > +# - optional python:2.7 dependency should be dropped if no reverse > > > > > +# dependencies are using it. > > > > > +# - mandatory python:2.7 depepndency will require package porting > > > > > +# or package removal if no reverse dependencies are using it. > > > > > +dev-lang/python:2.7 > > > > > > > > You've just introduced 829 CI warnings > > > > > > That's the intention. > > > > > > > effectively disabling the ability to distinguish *new* problems in > > > > these packages. > > > > > > Correct. Citing above: > > > > > > "If we expect actions by developers on both cases I don't see a problem > > > with that." > > > > > > I assume we still do. > > > > Not exactly. You've pinpointed the wrong target. > > > > First of all, we want people to support Python 3. Removing support for > > Python 2 is a secondary goal. > > What is the desired end state here? All packages that depend on > python should support python3? Yes, or be masked for removal. The desired result is that at some point in time we can disable py2 target in eclass without anything breaking. > > Flagging packages that support Python 2 in addition to Python 3 > > and cause no trouble in py2 cleanup is doubtful. > > What is "py2 cleanup"? I still struggle to understand what packages > require change and which do not. Is there one pager doc that explains > a few things for me: Some of this is mentioned in Python Guide [1]. [1] https://dev.gentoo.org/~mgorny/python-guide/package-maintenance.html#support-for-python-2 > - How packages are picked for masking? Maybe we can deprecate them > instead? Or we (I) can write a bit of code that flags packages requiring > maintainers' attention. This is really decided by humans, and I don't think it can be trivially automated. So far we've focused on masking packages that are either a. unlikely to be ported (e.g. dead upstream), b. have no Gentoo maintainers. > - What is the expected end state for the "py2 cleanup"? Not sure if I understand right but I think the answer is: we can disable py2 support via eclass and nothing breaks. > The doc would also be a good link to add to recently added "# Py2 only" > masks as well. > > > Flagging packages that support 2+3 because of their revdeps is not > > helpful at all. It's just noise to the maintainer who can't remove py2 > > because of revdeps. > > I agree it can be spammy if we expect to have many packages with > python2 support for an extended period of time (3+ months). If it's > seen by others as too noisy I can revert the comm
[gentoo-dev] Package up for grabs: sys-apps/biosdisk
Hello, since the proxy maintainer stopped using it and can't test anymore, the following package is looking for a new maintainer: sys-apps/biosdisk It's currently the newest version and doesn't have any open bugs. Maintenance is fairly low. Cheers Conrad
[gentoo-dev] Last rites: dev-tex/circuit_macros
# Mikle Kolyada (2020-06-26) # Has been a part of dev-texlive/texlive-pictures # for a lonmg time. Removal in 30 days. dev-tex/circuit_macros signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 11:38:58 +0200 Michał Górny wrote: > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > On Fri, 26 Jun 2020 07:29:45 + > > Michał Górny wrote: > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > napisał(a): > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > Sergei Trofimovich wrote: > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > Michał Górny wrote: > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > > > > > Give maintainers the chance to act and flag packages that pull in > > > > > > > > > > > python:2.7. > > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > > --- > > > > > > > profiles/package.deprecated | 4 > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > b/profiles/package.deprecated > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > --- a/profiles/package.deprecated > > > > > > > +++ b/profiles/package.deprecated > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > > +# Deprecated. Consider poring to python 3 and drop support for > > > > > > > > > > > python2. > > > > > > > +dev-lang/python:2.7 > > > > > > > + > > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > > > > > > > # Use that instead. Or even better use none of them. It's a > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > Python 2.7, as well as these that support 2.7 in addition to 3 > > > > because > > > > > > they have 2.7 deps. > > > > > > > > > > If we expect actions by developers on both cases I don't see a > > > > problem with that. > > > > > > > > Pushed as: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > with full text being: > > > > > > > > +# Sergei Trofimovich (2020-06-26) > > > > +# Deprecated. > > > > +# - optional python:2.7 dependency should be dropped if no reverse > > > > +# dependencies are using it. > > > > +# - mandatory python:2.7 depepndency will require package porting > > > > +# or package removal if no reverse dependencies are using it. > > > > +dev-lang/python:2.7 > > > > > > You've just introduced 829 CI warnings > > > > That's the intention. > > > > > effectively disabling the ability to distinguish *new* problems in these > > > packages. > > > > Correct. Citing above: > > > > "If we expect actions by developers on both cases I don't see a problem > > with that." > > > > I assume we still do. > > Not exactly. You've pinpointed the wrong target. > > First of all, we want people to support Python 3. Removing support for > Python 2 is a secondary goal. What is the desired end state here? All packages that depend on python should support python3? > Flagging packages that support Python 2 in addition to Python 3 > and cause no trouble in py2 cleanup is doubtful. What is "py2 cleanup"? I still struggle to understand what packages require change and which do not. Is there one pager doc that explains a few things for me: - How packages are picked for masking? Maybe we can deprecate them instead? Or we (I) can write a bit of code that flags packages requiring maintainers' attention. - What is the expected end state for the "py2 cleanup"? The doc would also be a good link to add to recently added "# Py2 only" masks as well. > Flagging packages that support 2+3 because of their revdeps is not > helpful at all. It's just noise to the maintainer who can't remove py2 > because of revdeps. I agree it can be spammy if we expect to have many packages with python2 support for an extended period of time (3+ months). If it's seen by others as too noisy I can revert the commit now. > Flagging dev-python/pypy* which needs py2 but is entirely outside > the eclass system is not helpful at all. To pick a concrete example: from what I read above I don't see why app-misc/golly was masked for removal. -- Sergei
Re: [gentoo-dev] Packages up for grabs: dev-python/pyopencl, dev-python/pytools
On 2020-05-17 15:46, Michał Górny wrote: > Hello, > > The following packages are looking for a new maintainer: > > dev-python/pyopencl > dev-python/pytools I'll take them. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On Fri, Jun 26, 2020 at 10:36 AM Aaron Bauman wrote: > > On June 26, 2020 7:13:07 AM EDT, Rich Freeman wrote: > >> Of all the methods listed in the previous posts, the QA reports, etc. > >> there is no excuse individuals can't find out if their package is py2 > >> only. > > > >None of those methods were posted until a day or two ago, and the > >python team has done nothing to actually ensure all the impacted > >maintainers are aware of them. Perhaps a communication to > >-dev-announce with the preferred approach would be better? > > > > You should also look at qa-reports. Do we really need to *teach* others "how > to fish" here? Why can't folks just ask for assistance? Just looked at it: 1. I had no idea that a list of py2-only packages was listed there. I don't think I've ever actually looked at that page. 2. The report does not list maintainers, which means nobody is likely to know they have a package on the list. > > See above. Qa-reports will output a very nice list (even a graphic!) of such > things. Anyway, yes, I do expect devs to understand their packages state if > they maintain it. Don't be so myopic. Well, you can expect whatever you want, and then you can be frustrated out of your mind when 95% of devs fail to meet your expectations. Or you could just work with them where they're at and maybe get your project completed more quickly and with less effort... If you want people to look at a qa-report, maybe post on -dev-announce and ask everybody to do it? Most people aren't going to be following all the tools used by the python team if they aren't python devs. > >At least some devs here seemed surprised about the masks. Did you try > >filing a bug? > > Have you looked for said bugs? Of course. Do you think I'd invite such an obvious reply without actually checking. I just went to the first complaint on this list about there not being a bug, and verified that there wasn't a bug. As far as I can tell there is no bug for app-misc/golly. If I missed one feel free to cite it. > > > > >Masking something for all users is basically like torturing a kitten > >to get the attention of its owner. It is a necessary step if the > >package is actually to be removed. I don't think it is even allowable > >under our policies if no bug was filed. > > > > Do tell where said policy is? https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html Granted, a mask isn't a package commit, but I think the spirit of the policy covers it. In any case, there is no reason not to communicate with a maintainer before touching a package. That should involve something more than a generic notice that everybody should become a detective to figure out if they are covered by an upcoming change. If you have a list of impacted packages, then just file bugs against them. > > Nothing is really hard about masking packages for removal... honestly. The complaint isn't that masks are hard on you. The complaint is that it bombards users with unnecessary warnings. > The work comes in defending the position here for the few that complain. And how are you enjoying doing all that extra work? Would you prefer if devs started opening up QA/Comrel bugs that you then have to formally respond to? Or maybe you could try notifying devs before masking their packages? > If I filed a bug... they would complain or not respond... If I sent out a > dev-announce they would complain or not respond. Sometimes, sure. But at least you would have gone through due process, and you're unlikely to get much push back. And I suspect a number of those packages would actually get fixed. > > You see the fun here? Which method is effective? Mask a 100 packages for > removal... Someone complains... A few packages get saved and 90 get > removed... Life goes on. Would you want a dev to just mask one of your packages if they saw a bug in it, without bothering to open a bug? -- Rich
Re: [gentoo-dev] */*: Mask Py2 only packages
On June 26, 2020 7:13:07 AM EDT, Rich Freeman wrote: >On Thu, Jun 25, 2020 at 11:07 PM Aaron Bauman wrote: >> >> On Wed, Jun 24, 2020 at 04:21:14PM -0400, Rich Freeman wrote: >> > >> > We're removing python2 around . You can help us out by >updating >> > any packages you have that use python2. If you want to easily >> > identify these packages just do . >> > >> > I think the problem here is that we're basically telling >maintainers >> > that the beatings will continue until morale improves. Then we're >> > wondering why nothing is getting done. >> > >> >> I am thoroughly confused here. Some how you have completely changed >your >> opinion from previous posts. > >Perhaps we failed to communicate then. My opinion has always been >this: > >I support letting the python team manage the versions of python >available - if people want legacy versions to stick around they need >to do something to make it happen. > >HOWEVER, the python team would also find its job much easier if they >partnered with the myriad of package maintainers to accomplish their >goals, instead of just throwing them over the fence and then breaking >things for users to try to get everybody's attention periodically. > How have we *not* partnered with the community of devs? Michal's mails to the list? Previous discussions based on masks... >> >> Of all the methods listed in the previous posts, the QA reports, etc. >> there is no excuse individuals can't find out if their package is py2 >> only. > >None of those methods were posted until a day or two ago, and the >python team has done nothing to actually ensure all the impacted >maintainers are aware of them. Perhaps a communication to >-dev-announce with the preferred approach would be better? > You should also look at qa-reports. Do we really need to *teach* others "how to fish" here? Why can't folks just ask for assistance? All of it has been there and widely available for quite some time. Stop finding excuses. >You can't expect every Gentoo dev to independently cobble together a >bunch of scripts to go hunting for py2 reverse deps. > See above. Qa-reports will output a very nice list (even a graphic!) of such things. Anyway, yes, I do expect devs to understand their packages state if they maintain it. Don't be so myopic. >> Ironically, it would be a very sad state if an individual doesn't >know >> what Python interpreter their package is compatible with. This is the >> essence of "maintainer" status, correct? > >Maintainers generally care about what the package does, and how it >does it is a means to an end. Sure, some care more about the build >system and dependencies than others, and when working on a package you >need to pay more attention to such things. However, I suspect most >package maintainers do not know off the top of their head the >dependency list of all their packages. > >> Obviously, the myriad of tools, ML threads, and all the other >"avenues" >> individual developers have taken to alert others simply doesn't >work... >> until something is p.masked... people don't budge. > >At least some devs here seemed surprised about the masks. Did you try >filing a bug? Have you looked for said bugs? > >Masking something for all users is basically like torturing a kitten >to get the attention of its owner. It is a necessary step if the >package is actually to be removed. I don't think it is even allowable >under our policies if no bug was filed. > Do tell where said policy is? >But if filing bugs is painful at least make things easier on >maintainers. Post a list of packages and owners, for example. > >It just seems like you're making things harder on yourself. Gentoo >has done countless migrations like this and for whatever reason in the >past creating a tracker and blocker bugs hasn't been a problem. > Nothing is really hard about masking packages for removal... honestly. The work comes in defending the position here for the few that complain. If I filed a bug... they would complain or not respond... If I sent out a dev-announce they would complain or not respond. You see the fun here? Which method is effective? Mask a 100 packages for removal... Someone complains... A few packages get saved and 90 get removed... Life goes on. -Aaron -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] */*: Mask Py2 only packages
On Thu, Jun 25, 2020 at 11:07 PM Aaron Bauman wrote: > > On Wed, Jun 24, 2020 at 04:21:14PM -0400, Rich Freeman wrote: > > > > We're removing python2 around . You can help us out by updating > > any packages you have that use python2. If you want to easily > > identify these packages just do . > > > > I think the problem here is that we're basically telling maintainers > > that the beatings will continue until morale improves. Then we're > > wondering why nothing is getting done. > > > > I am thoroughly confused here. Some how you have completely changed your > opinion from previous posts. Perhaps we failed to communicate then. My opinion has always been this: I support letting the python team manage the versions of python available - if people want legacy versions to stick around they need to do something to make it happen. HOWEVER, the python team would also find its job much easier if they partnered with the myriad of package maintainers to accomplish their goals, instead of just throwing them over the fence and then breaking things for users to try to get everybody's attention periodically. > > Of all the methods listed in the previous posts, the QA reports, etc. > there is no excuse individuals can't find out if their package is py2 > only. None of those methods were posted until a day or two ago, and the python team has done nothing to actually ensure all the impacted maintainers are aware of them. Perhaps a communication to -dev-announce with the preferred approach would be better? You can't expect every Gentoo dev to independently cobble together a bunch of scripts to go hunting for py2 reverse deps. > Ironically, it would be a very sad state if an individual doesn't know > what Python interpreter their package is compatible with. This is the > essence of "maintainer" status, correct? Maintainers generally care about what the package does, and how it does it is a means to an end. Sure, some care more about the build system and dependencies than others, and when working on a package you need to pay more attention to such things. However, I suspect most package maintainers do not know off the top of their head the dependency list of all their packages. > Obviously, the myriad of tools, ML threads, and all the other "avenues" > individual developers have taken to alert others simply doesn't work... > until something is p.masked... people don't budge. At least some devs here seemed surprised about the masks. Did you try filing a bug? Masking something for all users is basically like torturing a kitten to get the attention of its owner. It is a necessary step if the package is actually to be removed. I don't think it is even allowable under our policies if no bug was filed. But if filing bugs is painful at least make things easier on maintainers. Post a list of packages and owners, for example. It just seems like you're making things harder on yourself. Gentoo has done countless migrations like this and for whatever reason in the past creating a tracker and blocker bugs hasn't been a problem. I don't think the community will be served by having the python team work itself into a frenzy until they ragequit. Just give in, send out a -announce post, and maybe cut your workload in half at least. I get that you seem to want to stand on some kind of principle that everybody in Gentoo should care about the py2 migration as much as you do, but it probably isn't going to happen. Help everybody else help you... -- Rich
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > On Fri, 26 Jun 2020 07:29:45 + > Michał Górny wrote: > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > napisał(a): > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > Sergei Trofimovich wrote: > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > Michał Górny wrote: > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > > > > Give maintainers the chance to act and flag packages that pull in > > > python:2.7. > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > --- > > > > > > profiles/package.deprecated | 4 > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > b/profiles/package.deprecated > > > > > > index a756e845f47..bb661571962 100644 > > > > > > --- a/profiles/package.deprecated > > > > > > +++ b/profiles/package.deprecated > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > +# Deprecated. Consider poring to python 3 and drop support for > > > python2. > > > > > > +dev-lang/python:2.7 > > > > > > + > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > > > > > > # Use that instead. Or even better use none of them. It's a > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > Python 2.7, as well as these that support 2.7 in addition to 3 > > > because > > > > > they have 2.7 deps. > > > > > > > > If we expect actions by developers on both cases I don't see a > > > problem with that. > > > > > > Pushed as: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > with full text being: > > > > > > +# Sergei Trofimovich (2020-06-26) > > > +# Deprecated. > > > +# - optional python:2.7 dependency should be dropped if no reverse > > > +# dependencies are using it. > > > +# - mandatory python:2.7 depepndency will require package porting > > > +# or package removal if no reverse dependencies are using it. > > > +dev-lang/python:2.7 > > > > You've just introduced 829 CI warnings > > That's the intention. > > > effectively disabling the ability to distinguish *new* problems in these > > packages. > > Correct. Citing above: > > "If we expect actions by developers on both cases I don't see a problem with > that." > > I assume we still do. Not exactly. You've pinpointed the wrong target. First of all, we want people to support Python 3. Removing support for Python 2 is a secondary goal. Flagging packages that support Python 2 in addition to Python 3 and cause no trouble in py2 cleanup is doubtful. Flagging packages that support 2+3 because of their revdeps is not helpful at all. It's just noise to the maintainer who can't remove py2 because of revdeps. Flagging dev-python/pypy* which needs py2 but is entirely outside the eclass system is not helpful at all. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dev-python/rstcheck-3.3.1: Add rstcheck python package (#16399)
On 6/25/20 11:28 PM, Brian Dolbec wrote: > yes, you do not need to add a Gentoo maintainer unless asked to. Even without maintainer Gentoo CI fails the check for maintainer[1]. Maybe this could be not expected, and so I give you this feedback for Gentoo infrastructure review. [1] https://qa-reports.gentoo.org/output/gentoo-ci/2ce9c57f0d/output.html#dev-python/rstcheck -- Joonas Niilola: Sorry that I miss understood the purpose of this mailing list and the policy to accept contributions from community. I will not send any other email to this list not directly related to the context you mentioned. I interpret that as answering only to open topics. Keep the good work! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On June 26, 2020 2:45:07 AM EDT, Mart Raudsepp wrote: >Ühel kenal päeval, N, 25.06.2020 kell 23:47, kirjutas Aaron Bauman: >> Yes, there are successors in Gentoo. > >Traditionally p.mask entries point these out. Feel free to find and report all possible alternatives for all the packages that must go or be ported to remove Py2. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 07:29:45 + Michał Górny wrote: > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > napisał(a): > >On Sat, 20 Jun 2020 16:29:53 +0100 > >Sergei Trofimovich wrote: > > > >> On Sat, 20 Jun 2020 16:05:38 +0200 > >> Michał Górny wrote: > >> > >> > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > >> > > Give maintainers the chance to act and flag packages that pull in > >python:2.7. > >> > > > >> > > Signed-off-by: Sergei Trofimovich > >> > > --- > >> > > profiles/package.deprecated | 4 > >> > > 1 file changed, 4 insertions(+) > >> > > > >> > > diff --git a/profiles/package.deprecated > >b/profiles/package.deprecated > >> > > index a756e845f47..bb661571962 100644 > >> > > --- a/profiles/package.deprecated > >> > > +++ b/profiles/package.deprecated > >> > > @@ -17,6 +17,10 @@ > >> > > > >> > > #--- END OF EXAMPLES --- > >> > > > >> > > +# Sergei Trofimovich (2020-06-20) > >> > > +# Deprecated. Consider poring to python 3 and drop support for > >python2. > >> > > +dev-lang/python:2.7 > >> > > + > >> > > # Sergei Trofimovich (2020-02-22) > >> > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > >> > > # Use that instead. Or even better use none of them. It's a > >> > > >> > >> > It will trigger the same for packages that support *only* > >> > Python 2.7, as well as these that support 2.7 in addition to 3 > >because > >> > they have 2.7 deps. > >> > >> If we expect actions by developers on both cases I don't see a > >problem with that. > > > >Pushed as: > >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > >with full text being: > > > >+# Sergei Trofimovich (2020-06-26) > >+# Deprecated. > >+# - optional python:2.7 dependency should be dropped if no reverse > >+# dependencies are using it. > >+# - mandatory python:2.7 depepndency will require package porting > >+# or package removal if no reverse dependencies are using it. > >+dev-lang/python:2.7 > > You've just introduced 829 CI warnings That's the intention. > effectively disabling the ability to distinguish *new* problems in these > packages. Correct. Citing above: "If we expect actions by developers on both cases I don't see a problem with that." I assume we still do. -- Sergei
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On 6/26/20 10:29 AM, Michał Górny wrote: > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > napisał(a): > > Pushed as: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > with full text being: > > +# Sergei Trofimovich (2020-06-26) > +# Deprecated. > +# - optional python:2.7 dependency should be dropped if no reverse > +# dependencies are using it. > +# - mandatory python:2.7 depepndency will require package porting > +# or package removal if no reverse dependencies are using it. > +dev-lang/python:2.7 > You've just introduced 829 CI warnings, effectively disabling the ability to > distinguish *new* problems in these packages. > > > -- > Best regards, > Michał Górny > Hi, Overall can we let the python project handle large-scale python-2.7 removal, please? Everyone can help updating their own packages, or m-n packages. -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich napisał(a): >On Sat, 20 Jun 2020 16:29:53 +0100 >Sergei Trofimovich wrote: > >> On Sat, 20 Jun 2020 16:05:38 +0200 >> Michał Górny wrote: >> >> > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: >> > > Give maintainers the chance to act and flag packages that pull in >python:2.7. >> > > >> > > Signed-off-by: Sergei Trofimovich >> > > --- >> > > profiles/package.deprecated | 4 >> > > 1 file changed, 4 insertions(+) >> > > >> > > diff --git a/profiles/package.deprecated >b/profiles/package.deprecated >> > > index a756e845f47..bb661571962 100644 >> > > --- a/profiles/package.deprecated >> > > +++ b/profiles/package.deprecated >> > > @@ -17,6 +17,10 @@ >> > > >> > > #--- END OF EXAMPLES --- >> > > >> > > +# Sergei Trofimovich (2020-06-20) >> > > +# Deprecated. Consider poring to python 3 and drop support for >python2. >> > > +dev-lang/python:2.7 >> > > + >> > > # Sergei Trofimovich (2020-02-22) >> > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. >> > > # Use that instead. Or even better use none of them. It's a >> > >> >> > It will trigger the same for packages that support *only* >> > Python 2.7, as well as these that support 2.7 in addition to 3 >because >> > they have 2.7 deps. >> >> If we expect actions by developers on both cases I don't see a >problem with that. > >Pushed as: >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 >with full text being: > >+# Sergei Trofimovich (2020-06-26) >+# Deprecated. >+# - optional python:2.7 dependency should be dropped if no reverse >+# dependencies are using it. >+# - mandatory python:2.7 depepndency will require package porting >+# or package removal if no reverse dependencies are using it. >+dev-lang/python:2.7 You've just introduced 829 CI warnings, effectively disabling the ability to distinguish *new* problems in these packages. -- Best regards, Michał Górny
