[gentoo-portage-dev] pylint progress
Hi, Recently I've begun to run pylint on the portage codebase. You can see some recent PRs on this[0][1][2]. Most of the linter errors I've fixed are what I consider 'fairly trivial'. In general I'm happy to disable errors (or instances of errors) in addition to resolving them. You can see some of this in https://github.com/gentoo/portage/pull/593/files where we just blanket disable a bunch of very numerous messages (either because I don't expect to ever fix them, or because they are more work that I think we should do at the moment.) So I see essentially a few choices: - (a) Do we fix errors in certain classes and run the linter as part of CI. This means that once we resolve errors of a certain class, we can enable that class of check and prevent new occurrences. - (b) Do we just avoid running the linter as part of CI (perhaps because we are not far enough along on this journey) and focus our efforts to get to a point where we can do (a) without spamming CI? - (c) What messages should we bother not fixing at all so we can just not work on those classes of error? As an example of (c); I believe 'protected-access' is likely intrusive to fix and pointless for portage (cat is out of the bag) where as a message like W0612(unused-variable) is plausibly something we should fix throughout the codebase. Similarly I think "E0602(undefined-variable)" is often a bug in how pylint treats our lazy initialized variables, so most of these are false positives. I think getting these messages recorded will also enable other people besides me to fix them (I know b-man said he was interested.) Curious to hear thought on this. -A [0] https://gitweb.gentoo.org/proj/portage.git/commit/?id=49794e185350f0f9c8099ff84507873685b2b0f1 [1] https://gitweb.gentoo.org/proj/portage.git/commit/?id=550727af87d5f646617e0c19a3f3300c8117e7f5 [2] https://gitweb.gentoo.org/proj/portage.git/commit/?id=be20b37180f709ab0e451e4e07b6e82ac3a87b56
[gentoo-dev] Last-rites: app-admin/conkyforecast, app-arch/cfv, app-cdr/cdcover
# Andreas Sturmlechner (2020-07-29) # Py2-only, unmaintained, last release in 2008, dead upstream. # Removal in 30 days. app-cdr/cdcover # Andreas Sturmlechner (2020-07-29) # Py2-only, unmaintained, last release in 2009, dead upstream. # Removal in 30 days. app-arch/cfv # Andreas Sturmlechner (2020-07-29) # Py2-only, unmaintained, last release in 2012, dead upstream. # Ancient unresolved bugs #453918, #505076. Removal in 30 days. app-admin/conkyforecast signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
Aaron Bauman : > > How do you disagree with users keywording that package *not* running the > latest version? > Further, if they are on a stable system running it as keyworded... They know > how to unmask <3 if they want to use the Py2 only version. I don't have any insight on policy and won't venture any opinion, but perhaps I can showcase my user experience: I run -python2_7 and use stable sys-boot/refind -- it was quite the surprise to see a mask and 30-days-to-removal on my boot manager for a (unused) optional dep. thanks, Christian
[gentoo-dev] Last-rites: media-sound/edna
# Andreas Sturmlechner (2020-07-29) # Py2-only, last release in 2006, no one else is packaging this. # Removal in 30 days. media-sound/edna signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: media-sound/positron
# Andreas Sturmlechner (2020-07-29) # Py2-only, last release in 2004, no one else is packaging this. # Removal in 30 days. media-sound/positron signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: media-sound/moosic
# Andreas Sturmlechner (2020-07-29) # Py2-only, last release in 2011, we have shortage of music players. # Removal in 30 days. media-sound/moosic signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] eclass/sword-module.eclass: update SRC_URI, expand a bit, clean up
On 2020-07-29 12:10, Michał Górny wrote: > LGTM. Thanks! Okay then, merged! -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 16:22, Alexis Ballier wrote: > I think you've been told several times already, but impacting users > with a mask (that can't do anything useful about it) and not bothering > to file bugs for developers (that *can* do something about it) is not > the proper way to achieve anything here. This. Very much this. Especially the part about communicating with other Gentoo developers by last-rite messages. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On July 29, 2020 10:18:10 AM EDT, Thomas Deutschmann wrote: >On 2020-07-29 16:07, Andreas Sturmlechner wrote: >> Package is ~arch exclusively so everyone using it was already >upgraded. >> Masking <3.0.0_rc1 is perfectly fine if you want to keep old while >not >> blocking py2-masks of dependencies. > >While I even disagree with that, this is not even what happened. > >And yes, I probably wouldn't have notice this and wouldn't care if only ><3 were masked. > >But again, that's not what has happened. So, there we have it. You "wouldn't care" if it didn't touch *your* package. Then, you couldn't simply fix it as another has suggested. Typical. You will fight it vice saying, "yea, that was an option I could have taken". How do you disagree with users keywording that package *not* running the latest version? Further, if they are on a stable system running it as keyworded... They know how to unmask <3 if they want to use the Py2 only version. Silliness... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Wed, 29 Jul 2020 10:03:47 -0400 Aaron Bauman wrote: > Adjust the mask, drop the ebuild, or simply remove the mask. I would > happily apologize for a mistake, but reverting something that is > largely not in error seems silly. > > Again, this is a massive commit, but it should be the last time. Look > at the previous sets of masks... impact vs inconvenience was pretty > low. I think you've been told several times already, but impacting users with a mask (that can't do anything useful about it) and not bothering to file bugs for developers (that *can* do something about it) is not the proper way to achieve anything here. I believe there are a few quiz questions that closely relate to that kind of impact.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Mittwoch, 29. Juli 2020 16:18:10 CEST Thomas Deutschmann wrote: > But again, that's not what has happened. But that's what you can do. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 16:07, Andreas Sturmlechner wrote: > Package is ~arch exclusively so everyone using it was already upgraded. > Masking <3.0.0_rc1 is perfectly fine if you want to keep old while not > blocking py2-masks of dependencies. While I even disagree with that, this is not even what happened. And yes, I probably wouldn't have notice this and wouldn't care if only <3 were masked. But again, that's not what has happened. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Mittwoch, 29. Juli 2020 15:59:17 CEST Thomas Deutschmann wrote: > On 2020-07-29 15:46, Aaron Bauman wrote: > > Yes, net-nntp/sabnzbd is valid as it still has an ebuild with only > > py2.7. So fix it instead of bitching and being lazy about it. You > > could have done that vice revert the commit. > > Like you can see, it's currently in RC state. No cleanup of previous > stable version will happen before this version was declared stable. Package is ~arch exclusively so everyone using it was already upgraded. Masking <3.0.0_rc1 is perfectly fine if you want to keep old while not blocking py2-masks of dependencies. Regards, Andreas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On July 29, 2020 9:59:17 AM EDT, Thomas Deutschmann wrote: >On 2020-07-29 15:46, Aaron Bauman wrote: >> Yes, net-nntp/sabnzbd is valid as it still has an ebuild with only >> py2.7. So fix it instead of bitching and being lazy about it. You >> could have done that vice revert the commit. > >What are you talking about?! > >When upstream released first version supporting Py3, it was added to >repository. So don't call me lazy! > >Like you can see, it's currently in RC state. No cleanup of previous >stable version will happen before this version was declared stable. > >So no, your list was wrong. > > >> I will revert your revert when I return to my laptop. Thanks for >> nothing. > >...and not just because of net-nntp/sabnzbd like this thread has shown. > >I followed Gentoo policy when I reverted a broken commit. > >If can only urge you to revise pkg list and pay more attention for your >next commit. None of it is stable. So, what's your point? The commit is not broken. It just masks a package you care about which has Py2.7. Adjust the mask, drop the ebuild, or simply remove the mask. I would happily apologize for a mistake, but reverting something that is largely not in error seems silly. Again, this is a massive commit, but it should be the last time. Look at the previous sets of masks... impact vs inconvenience was pretty low. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 15:46, Aaron Bauman wrote: > Yes, net-nntp/sabnzbd is valid as it still has an ebuild with only > py2.7. So fix it instead of bitching and being lazy about it. You > could have done that vice revert the commit. What are you talking about?! When upstream released first version supporting Py3, it was added to repository. So don't call me lazy! Like you can see, it's currently in RC state. No cleanup of previous stable version will happen before this version was declared stable. So no, your list was wrong. > I will revert your revert when I return to my laptop. Thanks for > nothing. ...and not just because of net-nntp/sabnzbd like this thread has shown. I followed Gentoo policy when I reverted a broken commit. If can only urge you to revise pkg list and pay more attention for your next commit. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On July 29, 2020 9:16:31 AM EDT, Thomas Deutschmann wrote: >On 2020-07-29 09:38, Aaron Bauman wrote: >> This is exactly how it went before. No one is saying "it's your >> fault". Fix whatever the issue is and remove it from the list. > >No. You can't drop the bomb and let other fix the damage you created. >That's not how Gentoo is supposed to work. > >C'mon. You even added net-nntp/sabnzbd to that list again which created >a lot of drama beginning of this year. Please don't try to say you >reviewed anything... Yes, net-nntp/sabnzbd is valid as it still has an ebuild with only py2.7. So fix it instead of bitching and being lazy about it. You could have done that vice revert the commit. Surely, I had a mistake or two in the 108 package list, but other devs have already started fixing issues and now have reverted their changes because you want to revert something vice fixing it. The discussions on -dev outlined all of this before. Further, this is the last *big* set for Py2. Of which, most packages will go away. Again, save the few and move on. I will revert your revert when I return to my laptop. Thanks for nothing. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 09:38, Aaron Bauman wrote: > This is exactly how it went before. No one is saying "it's your > fault". Fix whatever the issue is and remove it from the list. No. You can't drop the bomb and let other fix the damage you created. That's not how Gentoo is supposed to work. C'mon. You even added net-nntp/sabnzbd to that list again which created a lot of drama beginning of this year. Please don't try to say you reviewed anything... -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
FYI: I reverted the entire commit like this thread and bugs clearly show that this list wasn't even reviewed/checked: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b76ee2f3e20b55d268ec291a1a1328cc047f5a04 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Wed, Jul 29, 2020 at 4:09 AM Ulrich Mueller wrote: > > > On Wed, 29 Jul 2020, Aaron Bauman wrote: > > > # Aaron Bauman (2020-07-28) > > # More Py2 only stuff. Plz see -dev ML for discussions > > # Remove bindings, port to Py3, etc > > # Removal in 30 days > > [...] > > app-office/lyx > > I have unmasked this one again: > > "All python scripts distributed with LyX should now be compatible with > both python 2.x and python 3.x." > https://www.lyx.org/announce/2_3_1.txt Using package.mask in this way creates a TERRIBLE user experience. It causes users to look for alternatives and go through a lot of churn expecting the package to be removed, when it turns out there is nothing wrong and the package doesn't need to be removed. Bugs are a much more appropriate way to handle these situations. To start with, they ensure the maintainer even gets notified at all. A package mask doesn't actually notify the maintainer at all - it notifies anybody who has the package installed, and only when the host it is installed on is updated. It is possible (albeit less likely) that the maintainer might not have it installed, and more likely that they could have it installed in some container that they don't update daily. When the maintainer is able to fix the problem then users don't get the churn of a package mask. Obviously we're going to have packages that can't be migrated or which aren't maintained, and these should be treecleaned as with any other issue. If for some reason bugs are just THAT difficult to create, why not at least post the list on -dev-announce a few days before actually implementing the mask? You obviously have the list of packages if you're masking them, and you're even posting it on the list. So just post it on the list ahead of time so that people can react before they actually get masked. It seems like we're creating a terrible user experience simply because we can. This seems to be going back to how things were 10+ years ago when stuff broke for users often simply because nobody cared to even bother with communication and QA. -- Rich
Re: [gentoo-dev] [PATCH] eclass/sword-module.eclass: update SRC_URI, expand a bit, clean up
On Mon, 2020-07-27 at 17:44 +0200, Marek Szuba wrote:
> 1. The old version expected versioned source archives to have been
>manually uploaded to the Gentoo mirror network by package
>maintainers. This is no longer allowed, or indeed possible for most
>Gentoo developers. Instead, use the SRC_URI arrow mechanism to
>version archives fetched directly from upstream. SWORD Project
>updates their modules quite infrequently so it isn't really necessary
>to worry the file having changed between looking the version number
>up on the module page and fetching the archive for digest generation,
>and while users who do not use Gentoo mirrors will see digest
>conflicts when an update does occur, this would effectively encourage
>them to notify maintainers whenever a new version is released;
> 2. If SWORD_MODULE is not set, attempt to generate it from PN by
>stripping the prefix 'sword-'. This will allow explicit declarations
>of SWORD_MODULE from all app-dicts/sword-* ebuilds currently in the
>tree;
> 3. Add the optional variable SWORD_MINIMUM_VERSION to specify the lowest
>version of app-text/sword supported by the module at hand;
> 4. Remove redundant declarations of HOMEPAGE and IUSE;
> 5. app-arch/unzip is now in BDEPEND rather than DEPEND;
> 6. As a consequence of the above, enforce the use of EAPI-7 in ebuilds
>inheriting this eclass. Those in the tree have all already been
>updated to that EAPI version;
> 7. Remove redundant references to ${S} from doins() calls;
> 8. Add eclassdoc blocks.
>
> No revision change in the end because all the changes should be
> backwards-compatible.
>
> Closes: https://bugs.gentoo.org/637882
> Signed-off-by: Marek Szuba
> ---
> eclass/sword-module.eclass | 92 +++---
> 1 file changed, 77 insertions(+), 15 deletions(-)
>
> diff --git a/eclass/sword-module.eclass b/eclass/sword-module.eclass
> index c66c9987e9f..2ae58d1e51b 100644
> --- a/eclass/sword-module.eclass
> +++ b/eclass/sword-module.eclass
> @@ -1,33 +1,95 @@
> # Copyright 1999-2020 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> +# @ECLASS: sword-module.eclass
> +# @MAINTAINER:
> +# Marek Szuba
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: Simplify installation of SWORD modules
> +# @DESCRIPTION:
> +# This eclass provides dependencies, ebuild environment and the src_install
> +# function common to all app-text/sword modules published by the SWORD
> Project.
> #
> -# eclass to simplify installation of Sword modules
> -# Bugs to mare...@gentoo.org
> +# Note that as of 2020-07-26 module archives published by SWORD are still
> +# not versioned and it is necessary to look at respective module pages in
> +# order to see what versions the currently available files are. Once
> +# a module file has been replicated to the Gentoo mirror network it will be
> +# versioned and remain available even after upstream has changed their
> +# version, however users not using mirrors will encounter hash conflicts
> +# on updated modules. Should that happen, please notify the relevant
> +# package maintainers that a new version is available.
> #
> +# @EXAMPLE:
> +# sword-Personal-1.0.ebuild, a typical ebuild using sword-module.eclass:
> +#
> +# @CODE
> +# EAPI=7
> +#
> +# SWORD_MINIMUM_VERSION="1.5.1a"
> +#
> +# inherit sword-module
> +#
> +# DESCRIPTION="SWORD module for storing one's own commentary"
> +# HOMEPAGE="https://crosswire.org/sword/modules/ModInfo.jsp?modName=Personal;
> +# LICENSE="public-domain"
> +# KEYWORDS="~amd64 ~ppc ~x86"
> +#
> +# @CODE
>
> -HOMEPAGE="http://www.crosswire.org/sword/modules/;
> +case ${EAPI:-0} in
> + 0|1|2|3|4|5|6)
> + die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
> + ;;
> + 7)
> + ;;
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac
>
> -# Sword packages are generally released as FooBar.zip in their 'rawzip' form
> -# The files are also unversioned, so the packager will need to rename the
> -# original file to something else and host it somewhere to avoid breaking
> -# the digest when new versions are released.
> +# @ECLASS-VARIABLE: SWORD_MINIMUM_VERSION
> +# @DEFAULT_UNSET
> +# @PRE_INHERIT
> +# @DESCRIPTION:
> +# If set to a non-null value, specifies the minimum version of app-text/sword
> +# the module requires. This will be included in RDEPEND. If null or unset,
> +# the dependency will be unversioned.
> +# Needs to be set before the inherit line.
>
> -SRC_URI="mirror://gentoo/${SWORD_MODULE}-${PV}.zip"
> +# @ECLASS-VARIABLE: SWORD_MODULE
> +# @PRE_INHERIT
> +# @DESCRIPTION:
> +# Case-sensitive name of the SWORD-Project module to install. If unset
> +# or null, use the name produced by removing the prefix 'sword-' from PN.
> +# Needs to be set before the inherit line.
> +: ${SWORD_MODULE:=${PN#sword-}}
> +
> +EXPORT_FUNCTIONS src_install
> +
> +#
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Tue, 28 Jul 2020 19:17:04 -0400 Aaron Bauman wrote: > net-irc/quasselgrep Uh, what? [I] net-irc/quasselgrep Installed versions: 0_p20190211(13:18:43 18/07/20)(PYTHON_TARGETS="python3_7 -python3_6") Maybe just the older version? pgpZibCoYPFgd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
> It has a dependency on sys-boot/udk which was masked due to > using py2.7 only. Hope that helps. Perhaps just the dependency can be removed? Building with gnu-efi still works fine, the TianoCore UDK is just an alternative. s.a. https://sourceforge.net/p/refind/code/ci/master/tree/BUILDING.txt#l67 thanks, Christian
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
> On Wed, 29 Jul 2020, Aaron Bauman wrote: > # Aaron Bauman (2020-07-28) > # More Py2 only stuff. Plz see -dev ML for discussions > # Remove bindings, port to Py3, etc > # Removal in 30 days > [...] > app-office/lyx I have unmasked this one again: "All python scripts distributed with LyX should now be compatible with both python 2.x and python 3.x." https://www.lyx.org/announce/2_3_1.txt signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On July 29, 2020 3:28:50 AM EDT, "Michał Górny" wrote: >On Wed, 2020-07-29 at 03:25 -0400, Aaron Bauman wrote: >> >> On July 29, 2020 2:49:14 AM EDT, Matt Turner >wrote: >> > On Tue, Jul 28, 2020 at 7:32 PM Aaron Bauman >wrote: >> > > On July 28, 2020 9:57:44 PM EDT, Gordon Pettey > >> > wrote: >> > > > That dependency is only if USE="-gnuefi". sys-boot/gnu-efi has >no >> > > > Python >> > > > dependency. Instead of masking/removing refind, remove the USE >flag >> > and >> > > > force the gnu-efi dependency, or reverse the condition, add >> > > > IUSE="tianocore", and mask that USE flag. >> > > > >> > > > On Tue, Jul 28, 2020 at 7:06 PM Aaron Bauman >> > wrote: >> > > > > On Tue, Jul 28, 2020 at 04:55:57PM -0700, Matt Turner wrote: >> > > > > > On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman > >> > > > wrote: >> > > > > > > sys-boot/refind >> > > > > > >> > > > > > How did you conclude that this package depends on Python at >all? >> > > > > > >> > > > > >> > > > > Hi, Matt. It has a dependency on sys-boot/udk which was >masked due >> > to >> > > > > using py2.7 only. Hope that helps. >> > > > > >> > > > > -- >> > > > > Cheers, >> > > > > Aaron >> > > > > >> > > >> > > That is for the maintainer to decide. Hence, all the previous >> > discussions surrounding this topic. It is a massive undertaking to >> > remove py2.7 from the tree. >> > >> > You've made a very strong case for filing bugs and asking >maintainers >> > to figure out what to do before masking packages for removal. >> >> Haven't we had this discussion before? Further, hasn't the community >been made aware through multiple channels of the impending removal of >Py2? >> > >Sure, and I don't mind removing packages that clearly don't support py3 >and whose maintainers have done nothing about that. However, I do mind >removing packages that do support py3 and that ended up on the list >probably because some deep indirect dep had some kind of py2 usage >problem (that I had no reason to know about), maybe because it's any-r1 >or had optional USE=python... This is exactly how it went before. No one is saying "it's your fault". Fix whatever the issue is and remove it from the list. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Wed, 2020-07-29 at 03:25 -0400, Aaron Bauman wrote: > > On July 29, 2020 2:49:14 AM EDT, Matt Turner wrote: > > On Tue, Jul 28, 2020 at 7:32 PM Aaron Bauman wrote: > > > On July 28, 2020 9:57:44 PM EDT, Gordon Pettey > > wrote: > > > > That dependency is only if USE="-gnuefi". sys-boot/gnu-efi has no > > > > Python > > > > dependency. Instead of masking/removing refind, remove the USE flag > > and > > > > force the gnu-efi dependency, or reverse the condition, add > > > > IUSE="tianocore", and mask that USE flag. > > > > > > > > On Tue, Jul 28, 2020 at 7:06 PM Aaron Bauman > > wrote: > > > > > On Tue, Jul 28, 2020 at 04:55:57PM -0700, Matt Turner wrote: > > > > > > On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman > > > > wrote: > > > > > > > sys-boot/refind > > > > > > > > > > > > How did you conclude that this package depends on Python at all? > > > > > > > > > > > > > > > > Hi, Matt. It has a dependency on sys-boot/udk which was masked due > > to > > > > > using py2.7 only. Hope that helps. > > > > > > > > > > -- > > > > > Cheers, > > > > > Aaron > > > > > > > > > > > That is for the maintainer to decide. Hence, all the previous > > discussions surrounding this topic. It is a massive undertaking to > > remove py2.7 from the tree. > > > > You've made a very strong case for filing bugs and asking maintainers > > to figure out what to do before masking packages for removal. > > Haven't we had this discussion before? Further, hasn't the community been > made aware through multiple channels of the impending removal of Py2? > Sure, and I don't mind removing packages that clearly don't support py3 and whose maintainers have done nothing about that. However, I do mind removing packages that do support py3 and that ended up on the list probably because some deep indirect dep had some kind of py2 usage problem (that I had no reason to know about), maybe because it's any-r1 or had optional USE=python... -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On July 29, 2020 2:49:14 AM EDT, Matt Turner wrote: >On Tue, Jul 28, 2020 at 7:32 PM Aaron Bauman wrote: >> On July 28, 2020 9:57:44 PM EDT, Gordon Pettey >wrote: >> >That dependency is only if USE="-gnuefi". sys-boot/gnu-efi has no >> >Python >> >dependency. Instead of masking/removing refind, remove the USE flag >and >> >force the gnu-efi dependency, or reverse the condition, add >> >IUSE="tianocore", and mask that USE flag. >> > >> >On Tue, Jul 28, 2020 at 7:06 PM Aaron Bauman >wrote: >> > >> >> On Tue, Jul 28, 2020 at 04:55:57PM -0700, Matt Turner wrote: >> >> > On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman >> >wrote: >> >> > > sys-boot/refind >> >> > >> >> > How did you conclude that this package depends on Python at all? >> >> > >> >> >> >> Hi, Matt. It has a dependency on sys-boot/udk which was masked due >to >> >> using py2.7 only. Hope that helps. >> >> >> >> -- >> >> Cheers, >> >> Aaron >> >> >> >> That is for the maintainer to decide. Hence, all the previous >discussions surrounding this topic. It is a massive undertaking to >remove py2.7 from the tree. > >You've made a very strong case for filing bugs and asking maintainers >to figure out what to do before masking packages for removal. Haven't we had this discussion before? Further, hasn't the community been made aware through multiple channels of the impending removal of Py2? In the end, a few packages get saved and a *lot* go away. Let's just save the few and move on please... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Tue, Jul 28, 2020 at 7:32 PM Aaron Bauman wrote: > On July 28, 2020 9:57:44 PM EDT, Gordon Pettey wrote: > >That dependency is only if USE="-gnuefi". sys-boot/gnu-efi has no > >Python > >dependency. Instead of masking/removing refind, remove the USE flag and > >force the gnu-efi dependency, or reverse the condition, add > >IUSE="tianocore", and mask that USE flag. > > > >On Tue, Jul 28, 2020 at 7:06 PM Aaron Bauman wrote: > > > >> On Tue, Jul 28, 2020 at 04:55:57PM -0700, Matt Turner wrote: > >> > On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman > >wrote: > >> > > sys-boot/refind > >> > > >> > How did you conclude that this package depends on Python at all? > >> > > >> > >> Hi, Matt. It has a dependency on sys-boot/udk which was masked due to > >> using py2.7 only. Hope that helps. > >> > >> -- > >> Cheers, > >> Aaron > >> > > That is for the maintainer to decide. Hence, all the previous discussions > surrounding this topic. It is a massive undertaking to remove py2.7 from the > tree. You've made a very strong case for filing bugs and asking maintainers to figure out what to do before masking packages for removal.
