[gentoo-dev] Mentor
Hi, all, Recently, I retired due to lack of time for Gentoo [1] I am able to dedicate more time now and the foreseeable future. Anyone interested in mentoring me? :) [1]: https://bugs.gentoo.org/show_bug.cgi?id=463162
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 10:32:34PM +0100, Ulrich Mueller wrote: > >>>>> On Wed, 03 Nov 2021, Aaron Bauman wrote: > > > I love digging through old council logs to find "policy" > > > Not sure why others don't feel the same way. > > Patches for the devmanual are welcome. Is that where the policy belongs? If so, shouldn't the council update it based on their decisions? "patches are welcome" doesn't fit every scenario. -Aaron
Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system
On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote: > > On Wed, 03 Nov 2021, Rich Freeman wrote: > > > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann > > wrote: > >> > >> This is not about finding solution to upgrade the system (in this case > >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is > >> about raising awareness that Gentoo is a rolling distribution and that > >> we guarantee users to be able to upgrade their system when they do world > >> upgrades just once a year (remember: in my case the last world upgrade > >> is just 4 months old!). If they cannot upgrade their system without > >> manual intervention, we failed to do our job. > > > Do we have this "guarantee" documented somewhere? I thought I've > > heard six months tossed around. You say one year. It seems > > reasonable to have some sort of guideline like this and try to stick > > with it, at least for @system. > > We do. Summary of 2009-11-09 Council meeting: > I love digging through old council logs to find "policy" Not sure why others don't feel the same way. > | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt > | > | Upgrade path for old systems > | > | Vote (unanimous): The ebuild tree must provide an upgrade path to a > | stable system that hasn't been updated for one year. > | > | Action: leio will start a discussion on gentoo-dev on if and how to > | support upgrading systems that are outdated more than a year.
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On Thu, Oct 21, 2021 at 10:05:20AM +0200, Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > Splitting from the discussion in [1] (moving more arhitectures to > ~arch), I'd like to propose that we remove the "security supported" > architecture list from [2] and instead level security support with > the general architecture support in Gentoo, e.g. by having all > architectures with stable profiles be "security supported". > I fully support this approach and have long advocated for it. Overall, all stables arches should be security supported and if they begin lagging behind they should be dropped to unstable. I am sure there are some nuances, but this is a great start. Let's do it! -Aaron
[gentoo-dev] Package up for grab
Hi, all. The following package is up for grabs. It has 2 open bugs [1] [2]. I am no longer interested in maintaining packages within the Ruby ecosystem. -Aaron [1]: https://bugs.gentoo.org/736414 [2]: https://bugs.gentoo.org/767343
Re: [gentoo-dev] News Item for uClibc-ng deprecation
On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote: > On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile wrote: > > > > Hi everyone, > > > > Can I get feedback on the following news item? (BTW, thanks soap) > > > > Title: uClibc-ng retirement on 2023/01/01 > > Author: Anthony G. Basile > > Posted: 2021-08-15 > > Revision: 1 > > News-Item-Format: 2.0 > > Display-If-Profile: default/linux/uclibc/* > > > > uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021, > > noone has volunteered to step up maintenance or expressed interest in > > the uClibc-ng profiles. With this announcement we last-rite the "uclibc" > > profiles, which will be removed on 2023/01/01. For parties interested in > > an alternative libc, consider moving to musl, which is supported. > > 2023? That seems like a pretty long time to wait to remove something > that isn't very well supported right now. +1 While I have no involvement with uClibc-ng, it does seem awfully long before removal. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote: > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote: > > > To do that, I think we'd want to change what's required for the "clean > up" step. Since today the "clean up" step is dropping the vulnerable > package versions from the tree, it is dependent on > non-security-supported architectures completing the stabilization bug. > I think we'd like to break that dependence. > Yes, please. Thank you for bringing this up. This has been a hotly debated item in the past with former security leads dictating that "clean up" is not relevant to the security process, but it remained codified in documentation that it needs to occur. It is indeed important, as leaving vulnerable versions is the tree is not good for anyone and impacts many other areas (e.g. promoting tree cleanliness). Further, as mgorny mentioned in a follow-up email to this, we need to understand what is a "security supported" architecture. This has also been an issue in the past with council intervention needed to declare dropping specific arches to exp profiles and allowing security to drop support and subsequently move bugs forward. And to continue on my soap box, we have a small blurb on the security page [1] which states what architectures are considered security supported. This is less than ideal. We also generally state that stable arches are supported and must be dealt with during the vulnerability process. So, all in all, it is highly conflated IMHO and is *not* ideal for anyone to have to determine that a particular arch is stable but not security supported. As such, I advocate for any stable arch to be security supported by default. If the arch lags or is dropped then it goes to unstable (process TBD). [1]: https://www.gentoo.org/support/security/vulnerability-treatment-policy.html -Aaron signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] Decoupling stabilization from security bugs
On Thu, Aug 12, 2021 at 02:53:33PM +0200, Michał Górny wrote: > Hello, everyone. > > TL;DR: I'd like to propose that stabilizations are done via blockers of > security bugs instead of security bugs themselves, i.e. as any other > stabilizations. > > > Right now we're often performing security-related stabilizations via > security bugs. This has a few problems, that are: > > WDYT? I welcome this change. Let's do it. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
On Thu, Aug 05, 2021 at 02:44:40PM -0700, Georgy Yakovlev wrote: > Hi, > > We've been collecting more and more container related packages in > app-emulation/* > > What do you think about finally moving those packages to separate category? > This would be a more accurate categorization of the packages and I am in favor of it. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Wed, Jul 14, 2021 at 10:49:34AM +0200, Andreas K. Huettel wrote: > > > > > > 1) either the severity assignment of this bug by the Security project as > > > B1 wrong (i.e. it should have been classified "harmless") > Well, over the last year or so every 2-3 months the (uninformed) discussion > came up, "don't use openrc stages because you are automatically rooted". That > leaves a rather bad impression of Gentoo, independent of whether it is true > or not. If noone from sec team noticed the discussions... Absolutely, that would leave a bad impression. Where were these discussions taking place? > > > > 2) or the entire classification of severity levels according to the > > > Security project pointless (i.e. you can't base any actions on them > > > because a mystery onion needs to be taken into account). > > > > > > > I am not sure if this is sarcasm, but every bug must be considered > > through the correct aperture. That is, based on your environment, > > protections in place, defense in depth, and other buzzwords... hence the > > onion analogy. > > It's not sarcasm. The point of the classification is to give clear rules (why > else would you list, e.g., required response times on the vulnerability > treatment page (no matter how illusory they are)). > > If you don't take all factors into account when *making* the classification, > then all gain you have from the classification is lost. > Let me explain differently. Gentoo has a vulnerability rating system that is indepedent of any other system. This system is used to classify bugs from a distro perspective and common usage of various applications. However, one cannot consider all possible attack vectors, impacts, and configuration scenarios being used by our users. So, it is not lost... we just can't possibly account for all the things. Yes, the response times are utter crap and as I mentioned the Gentoo system needs to be overhauled/adapted. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Wed, Jul 14, 2021 at 12:04:34AM +0200, Andreas K. Huettel wrote: > > > The package was masked due to a miscommunication with the Gentoo > > Security project. > > > > While it is true that the way opentmpfiles is currently implemented > > allows for certain races, from the security point of view, you always > > have to classify the vulnerability in context of your threat model > > because security depends on multiple layers (onion model). > > > I would like to respectfully point out that this makes > > 1) either the severity assignment of this bug by the Security project as B1 > wrong (i.e. it should have been classified "harmless") > The Gentoo model is not perfect and should be overhauled. However, it works for most things and sometimes bugs fall between the cracks. The package shouldn't have been masked either based on a bug that was purposely ignored for many years simply because they want to disband the package now and found a "security reason" to add to the mask. > 2) or the entire classification of severity levels according to the Security > project pointless (i.e. you can't base any actions on them because a mystery > onion needs to be taken into account). > I am not sure if this is sarcasm, but every bug must be considered through the correct aperture. That is, based on your environment, protections in place, defense in depth, and other buzzwords... hence the onion analogy. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, Jul 12, 2021 at 04:59:06PM +0200, Michał Górny wrote: > On Mon, 2021-07-12 at 09:33 -0400, Aaron Bauman wrote: > > On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote: > > > On 2021-07-11 21:54, Michał Górny wrote: > > > > > > > My gut feeling is that having this distinction is useful. However, it > > > > has been pointed out that we've probably never really had to use it > > > > (i.e. use the "banned" argument to stop someone from using old EAPI) > > > > and that the switch from "deprecated" to "banned" state did not really > > > > affect porting away from old EAPI. > > > > > > For the benefit of those not interested in sifting through the logs of > > > Council meetings, here is a quick reiteration of my take on this: > > > > > > 1. Maybe it's my professional bend speaking but it feels to me like we > > > really should establish a clear, GLEP-documented EAPI life cycle with > > > well-defined meaning of individual stages. I will work on preparing a > > > suitable proposal; > > > > > > 2. Until the above has introduced a (hopefully) better system, I am all > > > for > > > removing step 2 because it makes the procedure less bureaucratic. > > > > > > > > > On 2021-07-12 02:11, Aaron Bauman wrote: > > > > > > > Just officially ban it, send out a message, and use the best judgement > > > > when enforcing it (should it even need to be enforced). > > > > > > And the point of establishing a policy doomed from start to be enforced > > > weakly or not at all is? Other than making the Council look like we care > > > more about theatrics than actual governance, that is. > > > > > > -- > > > Marecki > > > > > > > It is not theatrics. It is a policy that was effective in the past and > > is used in lieu of a technical measure. Albeit, it is unlikely to be > > enforced because most people abide by the deprecation warnings. > > > > That's the whole point. Do we need a two-step deprecation/ban if 'most' > people abide by deprecation warnings? > > I'm wondering if the two-step deprecation/ban isn't a symptom of a wider > problem. After all, we want people to stop using old EAPIs after > they're deprecated, not after they're explicitly forbidden to use them. > > Maybe the whole point is that we should stop trying to draw explicit > lines everywhere and instead assume -- per common sense -- that > deprecating is enough for people to eventually stop using them. > As said, in lieu of that we have a fail safe. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, Jul 12, 2021 at 04:21:02PM +0200, Thomas Deutschmann wrote: > Hi, > > it's not clear to me what will be the consequences of this change. > > I am expecting good faith and that nobody will add an ebuild with deprecated > EAPI just for fun or because maintainer prefers retro stuff. > > So looking at the reasons to bump without touching EAPI: > > a) Because of a changing dep/add slot operator > > b) Because of a security vulnerability. > > c) Other critical fixes which should reach users ASAP. > > In addition, all of this could happen by non-primary maintainer of the > package. > Like a lot of policies and rules in Gentoo there are exceptions. This is why we have various projects and teams that enforce said policies and rules. Finally, we have escalation procedures with various independent bodies to handle it should common sense prove to be an uncommon virtue. We cannot legislate common sense. So many people spending so much time to arrive at an imperfect policy, as usual. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Mon, Jul 12, 2021 at 11:38:18AM +0100, Marek Szuba wrote: > On 2021-07-11 21:54, Michał Górny wrote: > > > My gut feeling is that having this distinction is useful. However, it > > has been pointed out that we've probably never really had to use it > > (i.e. use the "banned" argument to stop someone from using old EAPI) > > and that the switch from "deprecated" to "banned" state did not really > > affect porting away from old EAPI. > > For the benefit of those not interested in sifting through the logs of > Council meetings, here is a quick reiteration of my take on this: > > 1. Maybe it's my professional bend speaking but it feels to me like we > really should establish a clear, GLEP-documented EAPI life cycle with > well-defined meaning of individual stages. I will work on preparing a > suitable proposal; > > 2. Until the above has introduced a (hopefully) better system, I am all for > removing step 2 because it makes the procedure less bureaucratic. > > > On 2021-07-12 02:11, Aaron Bauman wrote: > > > Just officially ban it, send out a message, and use the best judgement > > when enforcing it (should it even need to be enforced). > > And the point of establishing a policy doomed from start to be enforced > weakly or not at all is? Other than making the Council look like we care > more about theatrics than actual governance, that is. > > -- > Marecki > It is not theatrics. It is a policy that was effective in the past and is used in lieu of a technical measure. Albeit, it is unlikely to be enforced because most people abide by the deprecation warnings. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Sun, Jul 11, 2021 at 10:54:45PM +0200, Michał Górny wrote:
> Hi, everyone.
>
> The Council has eventually decided that the proposed agenda item
> changing the EAPI workflow has not received sufficient public
> discussion, so I'd like to restart it.
>
>
> 3. When all ebuilds are removed, the EAPI is added to eapis-banned
> and the tools now explicitly forbid adding ebuilds with that EAPI.
>
>
> The change proposed in [1] eliminates step 2. The EAPI remains
> in 'deprecated' policy-state until all ebuilds using it are removed.
> There is no distinction between 'weak' deprecation ("please don't use
> it") and 'strong' ban ("you mustn't use it unless you have a very good
> reason to").
>
There seems to be a lot of time spent on whether to take 1 minute
to officialy ban an EAPI in a meeting. Plots are cool, but nothing
statistically significant is going to show given the small issues we had
in the past. The formality is simply to keep those small issues from
being a headache to other devs.
Just officially ban it, send out a message, and use the best judgement
when enforcing it (should it even need to be enforced).
-Aaron
signature.asc
Description: PGP signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, Feb 08, 2021 at 10:02:43AM -0800, Alec Warner wrote: > On Mon, Feb 8, 2021 at 9:56 AM Alessandro Barbieri > wrote: > > > > Il Lun 8 Feb 2021, 12:19 Michał Górny ha scritto: > >> > > > > Should we shed tears for those legacy architectures or move forward? Does > > anyone really use them in production? > > Many users don't use gentoo in 'production' so I'm not sure how that > matters in our decision making. I'm not sure the trade off here > (taking rust as a core dep) is reasonable and it looks like we can > avoid it. > Do we have anything to support this claim? -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [News review v2] LibreSSL support discontinued
On Mon, Jan 04, 2021 at 10:21:58AM +0100, Michał Górny wrote: > v2, with additional 'emerge --deselect': > --- > Title: LibreSSL support discontinued > Author: Michał Górny > Posted: 202x-xx-xx > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: dev-libs/libressl > > Starting 2021-02-01, Gentoo will no longer actively pursue supporting s/no longer actively pursue/discontinue -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On December 29, 2020 4:39:06 AM EST, "Michał Górny" wrote: >On Mon, 2020-12-28 at 23:18 +, Peter Stuge wrote: >> Michał Górny wrote: >> > > A. It is a distinct implementation with probably /quite some/ >> > > stable >> > > compatibility, meaning that it will work perfectly fine as an >> > > alternative in many cases. >> > >> > Except that it doesn't, as has been proven numerous times. >> >> I'm sure that there are numerous cases where libressl doesn't work, >> but that's no reason to dismiss cases where it *does*. > >Are you asking people to put an effort into maintaining something that >can't be practically installed? 'I don't use a single Qt application >(yet!), so I demand you support LibreSSL for me!' > I don't see Peter demanding anything here. He has an opinion as a user and he has offered it. Just as others have offered theirs. >A side effect of this approach is that users will be tricked into using >LibreSSL, only to discover that they eventually have to transition >their systems back. We have been there with LibAV. However, unlike >LibAV, transition between SSL providers is non-trivial. > No one is tricking anyone into using LibreSSL. >> Did anyone gather actual numbers? > >$ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l >61 > >That's just the tip of the iceberg. Nobody's going to be able to even >guess how many upstream have accepted *bad* patches. How many packages >are forcing obsolete algorithms because someone added '!libressl' >conditions because LibreSSL keeps pretending to be a newer OpenSSL >version without actually implementing its API. > That's quite an assumption to assume all of these patches are "bad." >> > > B. It brings its own TLS API, a unique feature which by itself >> > > warrants the package. >> > >> > ...which by itself has no future >> >> That's arrogant and silly coming from anywhere but upstream. >> >> You can argue that you will never use the API in your TLS programs, >> but even then that says really nothing about the API provider itself. > >That's my opinion and I have a right to have it without being insulted. > Yes, you do. Just as others have a right to theirs without being spoken to as you have done so here. It is clear you have a problem with the LibreSSL implementation, but portraying that as a user being ignorant, demanding, or anythimg else is uncalled for to get your point across. Quit saying people are insulting you when you have clearly done so in the very same email response. >I don't dispute whether it's good. I dispute whether tightly binding >it to a problematic LibreSSL is a good idea. Sure, this means that >some people will be forced to use LibreSSL because of libtls. > >But in practice, this means that any upstream starting to use libtls >does a huge disservice to their users by preventing them from using >their preferred SSL provider. So in the end, you either don't use >libtls or your users are in pain. > >Actually, I see that someone has apparently forked libtls into libretls >(the irony!) that works against OpenSSL [1]. > >[1] https://git.causal.agency/libretls/about/ Anyway, +1 for LibreSSL removal. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Last rites: dev-python/pytest-catchlog
# Aaron Bauman (2020-12-02) # Deprecated. Functionality is native to dev-python/pytest now # Removal in 14 days dev-python/pytest-catchlog -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-analyzer/dosdetector
# Aaron Bauman (2020-11-30) # EAPI=5. Multiple open bugs #603866 #713620 # Dead upstream. Removal in 30 days. net-analyzer/dosdetector -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Debian Tools Project packages up for grabs
Hi, all. The following packages are up for grabs as the Debian Tools Project has no active members. All packages have been dropped to maintainer-needed. Enjoy. app-crypt/libmd dev-util/debhelper net-misc/apt-cacher-ng -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On November 9, 2020 6:54:33 AM EST, Peter Stuge wrote: >Andreas K. Hüttel wrote: >> it's probably time to deprecate the amd64 17.0 profiles! > >I for one am not so excited about the amd64 17.1 profiles. On the >surface >it appeared to me that one developer has "taken over" just about >everything, >which (regardless of the individual) can't be a good thing.. > What does this even mean? > >Jaco Kroon wrote: >> ...just wondering where the lib32 => lib symlink comes from now. > >baselayout contains a conversion to/from lib symlink(s). > > >Kind regards > >//Peter -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] A feedback about the CI bug reporting system
On Fri, Nov 06, 2020 at 10:14:30AM +0100, Michał Górny wrote: > On Fri, 2020-11-06 at 08:21 +0100, Agostino Sarubbo wrote: > > Hello all, > > > > 6 months have been passed after the CI system started to file bug reports. > > ~ 4700 bugs have been submitted > > > > We _know_ that atm is not possible to set a specific summary, instead a > > generic summary is used in case of compile failures and test failures. > > There are also some documented limitations. > > I do disagree with your presumption that this needs to be automated. > The whole point behind providing a service is that you should be ready > to dedicate *your* time into the service. However, we keep feeling that > you assume that your time is too precious, and it is better to waste > a little bit of everybody else's time. This is why Toralf's effort is > much more appreciated. > ACK. This is the same level of coordination the security team received when a multitude of bugs were filed once ago discovered fuzzing. It was lots of bugs, little information, inabilities to reproduce various crashes, invalid ratings/severity levels, and often a blog that simply regurgitated the same inaccuracies. Any attempt to ask/coordinate was met with lack of information or simply "see my blog" responses. The only time interaction occured was when bugs were closed due to invalidity, lack of information, or severity/ratings downgraded. All this to say, I concur his actions seem to show that he believes his time is more precious than others and that "numbers matter" when it comes to opening bugs and CVE's. > To summarize, what your tinderboxing effort lacks is really a human > touch. You seem to have set the goal to file as many bugs as possible > automatically. I disagree with that, as I would like this effort to > focus on helping developers, not pursuing them. This requires a human > touch, not a machine lord. > This right here. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] A feedback about the CI bug reporting system
On Fri, Nov 06, 2020 at 09:39:35AM +0100, Agostino Sarubbo wrote: > On venerdì 6 novembre 2020 09:18:50 CET Joonas Niilola wrote: > > Would it be possible for "someone" to figure it out, if you made your > > tinderbox scripts/code public? ;) Hate to say it, but toralf does pretty > > good job here, so it could be better. > > As stated multiple times, toralf said that the way he's filing bugs expect a > copy-paste action for the summary, this is not possible if you want to do > that > in a more automatic way. > Is this coming from the same individual who would complain when security bugs were not filled out properly in the summary? So, take a dose of your own medicine here. People prefer usable reports that allow them to solve problems. > > > Yes, I do find your tinderbox work useful most of the time. Thanks! > > However the latest, ehh, show with DISTUTILS_USE_SETUPTOOLS has made > > people do *hundreds* of commits that now apparently need a fixing > > anyway, or reverting back, and that doesn't feel nice. Sure maybe the > > eclass could do some fixing too, but maybe this notice wasn't meant to > > be full-tree scanned (at least _yet_). > > This class of bugs comes from a request. Months ago I also asked if I had > report these bugs during the stabilization and I got a positive feedback. > Where was this positive feedback? As you stated on #gentoo-dev today you don't really participate in the ML... so, I presume the positive feedback came on IRC. Most of us don't scan those logs to "prove" such things. Keep it on the ML and people will have record. > > > From my point of view your work is, and has been, appreciated, but you > > could coordinate better with other people. Hate to say it again, but > > toralf does seems to do a better job here too in that regard. Unless > > you're fine with comparing tinderboxers. > > With toralf's logs it's easy to reproduce the whole environment leading > > to a build failure, while with yours it's just build.log, thay may or > > may not be enough to find the build-breaking issue. > > This is something already discussed (maybe privately?) and clearly state by > me. > If you say that with my logs you are unable to reproduce the issue, since I'm > providing emerge --info and build log, you are saying that those info are not > enough. > So, I'd suggest to fix this issue upstream by clearly defining what is needed > in a bug report, because AFAIK atm for a bug report is needed a build log and > emerge --info > +1 to coordinate with others. Keep it here on the ML. This shouldn't be "ago v toralf"... it should be about the impact of your automation efforts on the rest of the community. Right now, it looks like that is mostly negative given the ML feedback. Frankly, if this is anything like your security efforts (re: fuzzing) then I can understand the concerns people have expressed. Please, stop with the "automate everything, open many bugs, and move on" philosophy. It didn't work well in security and it won't work here. Build a quality solution that makes an impact for the distro. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-wireless/gr-*
# Aaron Bauman (2020-09-22) # Fails to build with new Python or at all. # QA issues (byte compiling etc). All live ebuilds. # Removal in 14 days net-wireless/gr-baz net-wireless/gr-doa net-wireless/gr-foo net-wireless/gr-ntsc net-wireless/gr-ntsc-rc net-wireless/gr-ppm-wiegand net-wireless/gr-rftap net-wireless/gr-specest -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-embedded/ftdi_eeprom
# Aaron Bauman (2020-08-29) # EAPI=4, use dev-embedded/libftd[tools] instead # Removal in 30 days dev-embedded/ftdi_eeprom -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-cdr/pburn
# Aaron Bauman (2020-08-29) # EAPI=4, latest release 4.3.19 in 2019. # Unmaintained. Removal in 30 days. app-cdr/pburn -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-admin/passook
# Aaron Bauman (2020-08-29) # EAPI=4, simple script, relies on hardcoded # /usr/dict/words for generation. Removal in 30 days. app-admin/passook -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-mail/maildirtree
# Aaron Bauman (2020-08-28) # EAPI=4 and fails to compile # Dead upstream. Removal in 30 days net-mail/maildirtree -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] News item: Multiple root kernel command-line arguments
On Thu, Aug 06, 2020 at 05:59:14PM +0200, Thomas Deutschmann wrote: > On 2020-08-06 17:44, Michał Górny wrote: > > I'm not sure if you've noticed but there are people actively working > > towards removing stale news items and trying not to dump everything > > on once on a user freshly installing the system. Don't you consider > > this a worthwhile goal? > > I don't see how this is conflicting. > > This news item can probably go away after 1-2 years. > > But for now, people who were just lucky will probably trigger this when > upgrading to genkernel-4.1 on their first reboot due to switched device > manager. > > But again: It's not a genkernel issue, so displaying that only for > people who have genkernel installed would miss a bunch of users. > Wait, changes were made to genkernel to switch from mdev to (e)udev which causes breakage, but it is *not* an issue with genkernel? Aside from this, do we have any evidence or bugs validating that users experience breakage with randomly named boot devices in kexec? It is great that you found an issue, but why try and be agnostic as to which one caused the issue? It looks worse that we cannot simply say: "genkernel changed for the better and things *may* break now... please read this!" Instead, we are pushing a news item to a lot of people simply because we *assume* it may be an issue for others with no evidence. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-vcs/rapidsvn
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #735340 # Removal in 30 days dev-vcs/rapidsvn -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-gfx/cptutils
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #735364 # Removal in 30 days media-gfx/cptutils -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-wireless/{cpyrit-cuda,cpyrit-opencl,pyrit}
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #709932 # Removal in 30 days net-wireless/cpyrit-cuda net-wireless/cpyrit-opencl net-wireless/pyrit -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-apps/biosdisk
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #735466 # Removal in 30 days sys-apps/biosdisk -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-fs/ecryptfs-utils
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #735486 # Removal in 30 days sys-fs/ecryptfs-utils -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-metrics/collectd sys-fs/owfs
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #735502. rdep. # Removal in 30 days app-metrics/collectd sys-fs/owfs -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-misc/nx_util
# Aaron Bauman (2020-08-02) # Py2 only. m-n. Bug #735524 # Removal in 30 days www-misc/nx_util -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: sci-biology/HTSeq
# Aaron Bauman (2020-08-02) # Unmaintained. New release upstream. Py3.6 only. # Removal in 30 days. Bug #696484,#718466 sci-biology/HTSeq -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-mobilephone/obexftp
# Aaron Bauman (2020-08-02) # Dead upstream. Py3.6 only. Build issues. # Removal in 30 days. Bug #677900,#716384 # #722408,723344 app-mobilephone/obexftp -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-backup/cachedir
# Aaron Bauman (2020-08-02) # Needs bump. Py3 tests fail. Last release 2yrs. # Removal in 30 days. Bug #718196 app-backup/cachedir -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Re: xorg-3.eclass update
On August 2, 2020 1:49:37 PM EDT, Henrik Pihl wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > >Hello once again, >and of course I get to apologize some more due to forgetting to attach >the >new patch. > >Henrik > >On 2020-08-02 at 17:15, ahve...@gmail.com wrote: >> I'm sorry for my lack of testing but I didn't notice that it was >doing >> everything except updating the fontconfig cache when dealing with the >fonts >> packages. So, here should be hopefully the complete version, as >originally >> intented. >> >> Henrik >> >> On 2020-08-02 at 13:54, ahve...@gmail.com wrote: >> > Hi, >> > According to the bug[1] it should be all right to restore the font >parts >> in >> > the xorg-3 eclass. Matt didn't object either. Currently upgrading >the >> > font-* packages to EAPI 7 and seemed to work the same way as with >5. >> > >> > [1] https://bugs.gentoo.org/712064 >> > >> > Henrik Pihl >-BEGIN PGP SIGNATURE- >Version: FlowCrypt Email Encryption 7.8.8 >Comment: Seamlessly send and receive encrypted email > >wsFzBAEBCgAGBQJfJvyxACEJELLeoy9dd+JHFiEEZ+1cZjaUPp4qaEdxst6j >L1134kfMZBAAuOppKJ+HT73gj/Fug7ZDlGY9+uH/RyokDU5jDD+A3eSqLtK0 >462767d/Of9kjmkJxJv55OGB/XVkZGZTbWpsdwS6GnsG5cj9KsblbBQU5a0g >lRcxbzJuHoNRdhVwz48Z9vC0g41mm3Plj03TmkaM2ys1CVyDlZDylAQOTSPP >a3YSkIj4VfzoSClnwH8sXNAZyqobIU9Av+wIQt0dYkve7Z6LH1OcRJgk8jFQ >siOp6mnqJMb5rvioZyuBUZwOdNL5GD3qbFXJn10Ek+fYZzcE/1pqySbfoLtl >IhtqGp9v4lYz7Yv9MLwEl+XjabJOZbZBRceHIXRJbjLCZEUpDmwFO9NObc8e >KhsFlI3DjM8nz/EyEFIw3/51zENcJPpwlSbDPus6N5nIOjKzGCEOJNpigG5P >uD5Es1s5QCgHf77lB8eRDQoa+u+UwiTbLWUlDIVM3IyYc6crpIM4eAM9mKVA >Jge6EKiRG62IuIAMcPYWNzVxa+TfJWJgpy5Jdu5frxV1Vh8LplTQYIWh5U7G >Jtq1WiGC1u2Jwyk/M8LOqtaymekeG6BSTvYf4Me1FK4+vRL7G4YeYg6LZj36 >RmJz0IeVXfRC+BAit7ctBD4AOfAlNQ9UJIpHnEKNXTGLqtDVuHeF+VEOuJWL >GHsyorcfdpJjtbIKmCvuraysWo/I34u3Qgg= >=XKvL >-END PGP SIGNATURE- Henrik, please send the patch inline so folks can review it. Likely, 'git send-email'. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Last rites: dev-python/dataclasses
# Aaron Bauman (2020-08-02) # Py3.6 backport for dataclasses. No rdeps left. # Removal in 30 days dev-python/dataclasses -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/cloudlib
# Aaron Bauman (2020-08-01) # Py3.6 only. Dead upstream. # Removal in 30 days. Bug #718898 dev-python/cloudlib -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-arch/{cfv,ipkg-utils}
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days. Bug #722060 app-arch/cfv app-arch/ipkg-utils -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-accessibility/{SphinxTrain,sphinx3,sphinxbase}
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days # Bug #568602,#340164,#560840,#716420,#560254 # #476424,#643982 app-accessibility/SphinxTrain app-accessibility/sphinx3 app-accessibility/sphinxbase -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-apps/scgi www-apache/mod_scgi
# Aaron Bauman (2020-08-01) # Py2 only. Upstream has py3 versions # m-n. Removal in 30 days. www-apps/scgi www-apache/mod_scgi -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-crypt/{openssl-blacklist,ssh-multiadd}
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days app-crypt/openssl-blacklist app-crypt/ssh-multiadd -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-gfx/printrun
# Aaron Bauman (2020-08-01) # Py2 only. Upstream has py3 version # Removal in 30 days. Bug #709278 media-gfx/printrun -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/pyvorbis
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days dev-python/pyvorbis -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/pyrex
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days dev-python/pyrex -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] last rites: dev-python/pyode
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. Fails to build # Removal in 30 days. Bug #662572,#730328 dev-python/pyode -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/pylzma
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days dev-python/pylzma -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/pyid3lib
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream # Removal in 30 days dev-python/pyid3lib -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/pupynere
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream # Removal in 30 days dev-python/pupynere -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/id3-py
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream # Removal in 30 days dev-python/id3-py -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/flup
# Aaron Bauman (2020-08-01) # Py2 only. Dead upstream. # Removal in 30 days. Bug #706238 dev-python/flup -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/elementtree
# Aaron Bauman (2020-08-01) # Py2 only. Use dev-python/lxml instead. # Removal in 30 days dev-python/elementtree -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: dev-python/cddb-py
On Sat, Aug 01, 2020 at 03:37:22PM -0400, Aaron Bauman wrote: > # Aaron Bauman (2020-08-01) > # Py2 only. Last upstream release 2013. > # Removal in 30 days > dev-python/cddb-py > > -- > Cheers, > Aaron add in which have deps on dev-python/cddb-py media-sound/exaile media-sound/jack [2] [1]: https://bugs.gentoo.org/708966 (and many other bugs) [2]: https://bugs.gentoo.org/734572 -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-pda/{jpilot,pilot-link}
On Sat, Aug 01, 2020 at 03:23:58PM -0400, Aaron Bauman wrote:
> # Aaron Bauman (2020-08-01)
>
> # Multiple build failure bugs. Py2 only
>
> # Removal in 30 days
>
> # Bug #709790, #672872, #714828
>
> app-pda/jpilot
>
> app-pda/pilot-link
>
> --
> Cheers,
> Aaron
Reverted.
mail-client/{claws-mail,sylpheed} have USE conditionals for 'pda' which
pulls in jpilot.
--
Cheers,
Aaron
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-python/cddb-py
# Aaron Bauman (2020-08-01) # Py2 only. Last upstream release 2013. # Removal in 30 days dev-python/cddb-py -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-pda/{jpilot,pilot-link}
# Aaron Bauman (2020-08-01) # Multiple build failure bugs. Py2 only # Removal in 30 days # Bug #709790, #672872, #714828 app-pda/jpilot app-pda/pilot-link -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] IPython 7.17 drops Python 3.6 support AKA upgrade reminder
On Sat, Aug 01, 2020 at 02:07:59PM -0400, Rich Freeman wrote: > On Sat, Aug 1, 2020 at 11:36 AM Aaron Bauman wrote: > > > > On August 1, 2020 6:25:09 AM EDT, Lars Wendler > > wrote: > > > > > >Honestly... seeing such replies from you or knowing that you do not > > >hesitate to hit other devs with your full QA deputy power once they > > >dare to touch python packages is not motivating in any way to even > > >consider helping you. > > > > > Lars, do you not recall the previous threads on this? The very same > > questions were answered about tooling. > > I'm sure everybody is tired of reading these threads over and over. > Simply saying that you answered these questions doesn't mean that > people will be satisfied with your answers. > > Well, not if you don't advertise the tooling, and the tools don't > output maintainer info so that maintainers can quickly determine if > they're impacted. > Then people should be more explicit or contribute changes. These are global issues not just one projects problem. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] IPython 7.17 drops Python 3.6 support AKA upgrade reminder
On August 1, 2020 6:25:09 AM EDT, Lars Wendler wrote: >On Sat, 01 Aug 2020 12:19:13 +0200 Michał Górny wrote: > >>On Sat, 2020-08-01 at 06:15 -0400, Rich Freeman wrote: >>> On Sat, Aug 1, 2020 at 3:29 AM Michał Górny >>> wrote: >>> > I would like to take this as an opportunity to remind you to port >>> > your packages to Python 3.7 and 3.8. According to our timeline >>> > [1], packages that are not ported by the end of the year are going >>> > to be last rited. We would also like to switch to 3.8 in December. >>> > >>> > [1] >>> > >https://wiki.gentoo.org/wiki/Project:Python/Implementations#Implementation_support_timeline >>> >>> So, has anybody given thought to publishing a list of packages that >>> still need to be updated, including their maintainers? >>> >>> Or perhaps filing bugs? >>> >>> Or is the plan to go ahead and watching nothing happen for the next >>> few months, then start masking hundreds of packages, and then watch >>> devs scramble to fix problems they didn't realize existed? >>> >> >>Or perhaps you'd like to help out instead of wasting your own >>and everybody else's time on talking? >> > >Honestly... seeing such replies from you or knowing that you do not >hesitate to hit other devs with your full QA deputy power once they >dare to touch python packages is not motivating in any way to even >consider helping you. > >Have a nice day... Lars, do you not recall the previous threads on this? The very same questions were answered about tooling. The very same requests were made and now Michal is providing a reasonable timeline that he would like other devs to help the Python team meet. I see plenty of other devs and contributors touch Python packages with no problems... Is it just you maybe? It doesn't seem *anything* will work with a few "high profile" devs in the community. Provide tooling? Not good enough. Provide a reasonable timeline? Not good enough. Open bugs? We ignore them. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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 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 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 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 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 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. -- 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 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 signature.asc Description: PGP signature
[gentoo-dev] Last rites: */*: More Py2 stuff
# 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-accessibility/epos app-admin/conkyforecast app-admin/github-backup-utils app-admin/syslog-summary app-arch/cfv app-arch/ipkg-utils app-backup/bareos app-backup/genbackupdata app-cdr/cdcover app-crypt/openssl-blacklist app-crypt/ssh-multiadd app-misc/mswinurl_launcher app-misc/mtail app-mobilephone/wammu app-office/kexi app-office/lyx app-text/fbless app-text/sgmltools-lite dev-cpp/icnc dev-lang/ispc dev-lang/spark dev-libs/qrosspython dev-python/cddb-py dev-python/flup dev-python/google-apputils dev-python/id3-py dev-python/mox dev-python/pmw dev-python/pyid3lib dev-python/pylzma dev-python/pyode dev-python/pyogg dev-python/pyrex dev-python/python-fchksum dev-python/pythonutils dev-python/pyvorbis dev-python/sphinxtogithub dev-tex/abntex dev-tex/crosstex dev-util/bam dev-util/doxy-coverage dev-util/tailor dev-vcs/cvs2svn dev-vcs/git-bz dev-vcs/gitinspector dev-vcs/gitstats dev-vcs/svnmailer games-action/openclonk games-emulation/fceux games-emulation/m64py games-emulation/mupen64plus games-strategy/0ad media-gfx/alembic media-gfx/cptutils media-gfx/uniconvertor media-libs/ganv media-libs/slv2 media-plugins/vamp-aubio-plugins media-sound/codecgraph media-sound/edna media-sound/exaile media-sound/jack media-sound/moosic media-sound/patchage media-sound/positron net-analyzer/linkchecker net-analyzer/pbgpp net-fs/nfstest net-im/spectrum2 net-irc/quasselgrep net-misc/pssh net-misc/putty net-misc/ris-linux net-nntp/sabnzbd net-print/pkpgcounter net-proxy/hatop net-wireless/gr-baz net-wireless/gr-doa net-wireless/gr-foo net-wireless/gr-ntsc net-wireless/gr-ntsc-rc net-wireless/gr-ppm-wiegand net-wireless/gr-rds net-wireless/gr-rftap net-wireless/gr-specest net-wireless/mousejack net-wireless/rfcat sci-biology/seqan sci-biology/shrimp sci-chemistry/eden sci-chemistry/pymol-plugins-caver sci-chemistry/numbat sci-chemistry/pymol sci-chemistry/sparky sci-libs/dealii sci-libs/gmsh sci-misc/gato sys-boot/refind sys-boot/udk sys-cluster/pbs-python sys-fs/rarfs sys-fs/traydevice www-apache/mod_scgi www-apps/scgi www-misc/nx_util x11-libs/flowcanvas x11-misc/dsx x11-misc/pypanel -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites/Up for grabs: net-misc/{gns3-gui,gns3-server}
# Aaron Bauman (2020-07-20) # continuous version constraints causing issues # Cisco images are rare to find that are supported # dropping to p-m. Removal in 30 days net-misc/gns3-gui net-misc/gns3-server net-misc/ubridge Feel free to take over these packages. Warning: upstream continuously has version contstraints on deps which causes issues elsewhere in the tree! -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/numb-0.40.1.ebuild
On July 2, 2020 9:59:40 AM EDT, "Xianwen Chen (陈贤文)" wrote: >Honestly, I find it counter productive to remove a package from the >main >repository, when there are active efforts to fix the package's >problems. > > >Xianwen These things happen. If it is being ported properly then let's add it back. Aisha, please adjust your PR for adding the package back and taking maintainership. Your work is not lost. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Last rites: */* More Py2 stuff
# Aaron Bauman (2020-06-29) # More Py2 only stuff. Plz see -dev ML for discussions # Remove bindings, port to Py3, etc # Removal in 30 days app-dicts/opendict app-editors/editra app-office/taskcoach app-backup/holland app-backup/holland-backup-example app-backup/holland-backup-pgdump app-backup/holland-backup-random app-backup/holland-backup-sqlite app-backup/holland-lib-common app-backup/holland-lib-lvm app-cdr/burn-cd app-editors/leo app-emulation/playonlinux app-text/bibus dev-db/SchemaSync dev-python/squaremap dev-util/wxglade media-gfx/fontypython media-gfx/fr0st sci-chemistry/apbs sci-chemistry/autodock sci-chemistry/eden sci-chemistry/p3d sci-chemistry/pdb2pqr sci-chemistry/pdb-tools sci-chemistry/prodecomp sci-chemistry/pymol-plugins-caver sci-chemistry/pymol-plugins-dssp sci-chemistry/pymol-plugins-promol sci-chemistry/relax sci-chemistry/sparky sci-chemistry/vmd www-apps/roundup www-apps/viewvc x11-misc/nts -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode
On June 29, 2020 6:28:30 PM EDT, Max Magorsch wrote: >Hi, > >Some time ago, the idea of integrating packages.g.o with pkgcheck and >repology.org came up. There have already been some discussions in bug >725702 and 725704 regarding this. > >The tl;dr is that the packages.g.o backend does now parse both the >pkgcheck results as well as the repology.org data. Currently, it's >possible to access them: > - either by using the new GraphQL API [0] > - or by using the 'developer mode' in the web interface >You can enable the developer mode by clicking onto 'Switch to >Developer Mode' in the footer [1]. Afterwards, you will see pkgcheck >warnings in the version table as well as warnings in case a new >version of a package is available according to repology.org (as, e.g. >currently for x11-wm/xmonad-contrib). > >I think, more generally speaking, there is some information that is of >interest for developers but might not be of interest for regular >users. This leads to some questions: > >1. Would you prefer this information to be displayed in packages.g.o >using a 'developer mode' or would you prefer a separate application >similar to the idea of project Grumpy? > >2. Is there any further information apart from pkgcheck and repology >that you would consider useful here for the development workflow? > >3. What else would you like to see here? For instance, I could think >of a configurable dashboard that shows all pkgcheck warnings, new >versions and open pull requests for packages that a developer >maintains. Would that be useful? What else could you think of? > >I look forward to your opinion. > >-M > >[0] you can use https://packages.gentoo.org/api/explore/ to get started >[1] if that's not working, that's likely a caching issue, and the >javascript assets have to be refreshed Hi, Max. A couple thoughts... Just let me know if they are too crazy. 1. Could you enable the backend to ping devs/projects via email when a new release is available for their respective package(s)? Maybe make it optional for the dev/project to enroll? 2. What about a setting to allow the Python team to deprecate a particular interpreter then notify respective pkg owners that their ebuild needs updated? This would possibly workaround the issues mgorny brought up regarding package.deprecated and noise for CI checks. Also, not sure if this is best implemented somewhere else first (e.g. pkgcheck) then leveraged by your work. Just a few quick thoughts... -Aaron -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: */* More Py2 only items
On June 29, 2020 4:57:49 PM EDT, Piotr Karbowski wrote: >On 29/06/2020 02.35, Aaron Bauman wrote: >> [...] >> net-dns/maradns > >There's single python script that can work with Python3 (at least in >new >version) that does that can just use any Python version. > >I see that it did not got update for over a year, will take it over now >and push >update tomorrow, then drop your mask on this package. > >-- Piotr. Piotr, perfect. Thanks for helping out! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Last rites: */* More Py2 only items
On Mon, Jun 29, 2020 at 09:48:34PM +0300, Azamat Hackimov wrote: > > dev-python/misaka > I've created MR for it: https://github.com/gentoo/gentoo/pull/15984 > Azamat, merged! Thank you. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: */* More Py2 only items
On Sun, Jun 28, 2020 at 08:35:02PM -0400, Aaron Bauman wrote: > # Aaron Bauman (2020-06-28) > # More Py2 only stuff. Plz see -dev ML for discussions > # Remove bindings, port to Py3, etc > # Removal in 30 days > app-arch/deltarpm > app-crypt/virtualsmartcard > app-text/duali Add app-text/duali-data which is an rdep of app-text/duali -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: */* More Py2 only items
# Aaron Bauman (2020-06-28) # More Py2 only stuff. Plz see -dev ML for discussions # Remove bindings, port to Py3, etc # Removal in 30 days app-arch/deltarpm app-crypt/virtualsmartcard app-text/duali app-text/mftrace app-text/queequeg app-text/referencer dev-libs/libmacaroons dev-libs/tut dev-python/elib-intl dev-python/eunuchs dev-python/medusa dev-python/misaka dev-python/python-iwscan dev-util/confix dev-util/qmtest dev-util/unrpyc games-engines/gemrb media-sound/lilycomp media-video/tovid net-dns/maradns net-irc/irker net-mail/archivemail net-mail/getmai net-nds/nsscache net-wireless/airpwn sci-chemistry/bkchem sci-chemistry/propka sci-chemistry/pymol-plugins-bni-tools sci-chemistry/pymol-plugins-emovie sci-chemistry/viewmol sci-libs/chemkit sys-apps/x86info www-misc/surl x11-wm/plwm -- Cheers, Aaron signature.asc Description: PGP signature
[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] [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] */*: 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 h
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] */*: 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 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] */*: Mask Py2 only packages
On Wed, Jun 24, 2020 at 11:52:28AM +0200, Thomas Deutschmann wrote: > On 2020-06-20 21:24, Aaron Bauman wrote: > > Thomas, unfortunately, I am shocked at your choice of words here. I > > think it is reasonable that any developer would understand a lack > > of forward momentum in removing Py2 only packages only drives > > stagnation. > > > > If you have a more effective method to doing so, I am open to > > suggestions. > > Like I am shocked about your recent actions: > > Remember what you did in January. I thought it became clear that next > time you will share your list before just masking stuff to avoid things > which happened then. > Developers have many tools and *hopefully* the organic ability to determine which packages are impacted. Especially given previous threads on this very ML with pleas from other Python team members to assist in cleaning things up in a deliberate manner. This is why the QA team interceded... because a couple of individuals screamed loudly for no reason. Fix it and move on. > In the beginning of this month you just decided to disband graphics > project. On your own. Please tell me what gave you the authority to just > do that? You didn't even share your plan before executing it on any > mailing list. Something that should be common sense, if not even necessary. > The whole action was so destructive that you couldn't evenb just undo it > because you also deleted stuff on Wiki. > I will not apologize for doing something that others have lacked the intestinal fortitude to do. > Like multiple people have already shown you, many packages from that > list are not even blocking Py3 transition. > This isn't about transitioning to Py3... it is about removing Py2. > Let me tell you what a mask will cause: > A mask is destructive and requires user interaction. Therefore a mask > isn't something to play with, "Oh, let's test if someone will > complain... it's just a mask, we can just unmask in case...". > Is that why you assume I masked these things? > No, imagine there are people out there using Gentoo in production and > not as playground. These people maybe have automated build systems which > are creating systems/images (do you know Dockers for example?). Whenever > you mask something and that package is referenced in configuration, you > will break that build. > > That's not funny if this is happening for no real reason. > I know you use Gentoo in production, but does this mean we (Gentoo) can't move forward because *you* want to use something that is EOL and dying? What if you used a major distro that removed Py2 support already? Why complain here? There are other ways to safely run your tooling with Py2 if you so choose. > > > re: net-mail/offlineimap... there are alternatives. > > I think you don't really know that tool. It's an industry standard. > Sure, there are already successors (however, not in Gentoo). But the > package itself is still working and actively maintained and when you > will use it in production you usually have extended/adjusted the tool > for your environment using the plugin system the tool provides. That's > not something you will be able to replace with something new in 5 minutes. > You continuously speak condescendingly to me. I am truly starting to regret my nomination for you on both the security project and for council. Do you speak to others this way simply because you don't agree with them? Yes, I use net-mail/offlineimap... I know how it works. No, I really hope that a tool which has not been maintained in many years is an "industry standard" Yes, there are successors in Gentoo. > And I repeat myself: Especially not when there is no need to do that > because because the package itself is working fine and there is absolute > no reason to get rid of it. > Take Patrick's approach and move it to an overlay if you want it that badly. > Last but not least: Gentoo is about choices. It's not your job to decide > what people should use. Sure, if you maintained a package and will stop > using it so it will become maintainer-needed and masked for removal at > some point because it's outdated, vulnerable and/or not working anymore, > that's OK. But if someone else will pick up this package... and > offlineimap in Gentoo is working and up-to-date. > Are you implying that because "Gentoo is about choice" that we never remove an ebuild, interpreter, compiler, etc? Let ::gentoo grow in size forever to appease the few? -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On Wed, Jun 24, 2020 at 10:12:18AM -0700, Matt Turner wrote: > offlineimap is widely used and blocks no further work. It can easily > remain in the tree after all other python2_7 support is gone. > > This is not a hill worth dying on. > I am confused here... are you saying that due to usage of the package that it should stay until dev-lang/python:2 is gone? More importantly, I simply responded to Thomas' mention that the package has alternatives, but apparently, I don't understand how the package is used :) -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On Wed, Jun 24, 2020 at 04:21:14PM -0400, Rich Freeman wrote: > On Wed, Jun 24, 2020 at 4:08 PM Michał Górny wrote: > > > > $ git grep -l mgo...@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 | > > xargs gpy-py2 2>/dev/null > > > > I have no idea what gpy-py2 is, but I'll take your word for it. > > In any case, the solution in this case is to send a nice email to > -dev-announce saying: > > 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'm not saying anybody has to do it a particular way - it just seems > obvious that the way we're doing it is more successful at getting > people upset than actually getting results. > > Ideally you would just open a tracker bug and then per-package bugs > for every impacted package. That would be the cleanest solution. If > that is too painful then by all means do some email announcements, but > make it easy for devs to realize when they're missing something. > > Having a package mask be the first time a maintainer finds out that > they have a problem isn't good. Now, you can blame that on the > maintainer, or you can blame that on the python team, but either way > the users end up getting exposed to breakage unnecessarily. > > -- > Rich > I am thoroughly confused here. Some how you have completely changed your opinion from previous posts. Furthermore, this has turned into a debate of how to find packages that are Py2 only which is just absurd. 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. 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? Can we stop finding excuses and let folks fix 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. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On Sat, Jun 20, 2020 at 01:29:46PM +0200, Thomas Deutschmann wrote: > On 2020-06-20 12:07, Michał Górny wrote: > >> Al least, python2 is not on your list. > >> > >> Be first into the future by masking this stuff and > >> Last out of the past by leaving up to users to decide. > >> It could stay in the tree, masked, as long as python2. > >> > > > > Do you really think it'd be better to last rite a 1000 packages > > simultaneously? > > What's the purpose of this at all? > > dev-lang/python:2.7 won't go away that soon. > > Removing perfectly working and up-to-date software which is in > maintenance-only mode like net-mail/offlineimap is just not user-friendly. > > It doesn't even has deps on other Python packages blocking your cleanup > delusion. > Thomas, unfortunately, I am shocked at your choice of words here. I think it is reasonable that any developer would understand a lack of forward momentum in removing Py2 only packages only drives stagnation. If you have a more effective method to doing so, I am open to suggestions. re: net-mail/offlineimap... there are alternatives. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] */*: Mask Py2 only packages
On Sat, Jun 20, 2020 at 10:32:28AM +0200, Ulrich Mueller wrote: > >>>>> On Sat, 20 Jun 2020, Aaron Bauman wrote: > > >> # Aaron Bauman (2020-06-20) > >> # Py2 only > >> # Removal in 14 days > > I see these short deadlines quite often recently. Any reason why this > can't be the usual 30 days? > > >> [...] > > >> games-board/scid > > I wonder about scid appearing in the list. IIRC, it is written in C++, > not Python. > > Ulrich Hi, Ulrich. Yes, the deadlines are meant to speed up the process as we have *roughly* 1000+ pkgs which must be converted to py3 or removed before we can drop the interpreter. As such, doing this in bulk with delays in between masks helps others find and fix up these packages if they can stay. Some have ports to Py3, others simply don't need the bindings, etc. So, thank you to all who have taken a few minutes to help us keep packages that can still be supported. Unfortunately, we have a bad ratio of devs to # of packages. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] */*: Mask Py2 only packages
> # Aaron Bauman (2020-06-20) > # Py2 only > # Removal in 14 days > app-admin/clustershell > app-crypt/openvpn-blacklist > app-forensics/volatility > app-misc/golly > app-misc/yagtd > app-text/pylize > app-text/rpl > app-vim/easytags > app-vim/notes > dev-db/metakit > dev-python/backports-ssl-match-hostname > dev-python/backports-shutil_get_terminal_size > dev-python/backports-shutil_which > dev-python/python-wpactrl > dev-util/bakefile > dev-util/uftrace > dev-vcs/git-deps > dev-vcs/git-remote-hg > games-board/scid > games-emulation/openmsx > games-kids/childsplay > games-mud/lyntin > games-sports/ski > mail-filter/tmda > media-video/subdl > media-sound/cplay > media-sound/tunapie > net-firewall/dshieldpy > net-mail/offlineimap > net-misc/switzerland > net-wireless/multimode > sci-biology/last > sci-chemistry/hollow > sci-chemistry/modeller > sci-chemistry/pymol-plugins-msms > sci-geosciences/tilecache > sci-libs/deap > sci-libs/pycifrw > sys-cluster/zookeeper-bin > www-apps/curator > x11-apps/whyteboard > x11-plugins/purple-plugin_pack -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Codec project
On Thu, Jun 11, 2020 at 07:11:33AM -0500, Dale wrote: > As a user, how about media? Multimedia? Or would those interfere with > other packages? > > I might add, regardless of name, will it be active enough to keep it > alive or will it go the same as the last? > > Dale > > :-) :-) Please see the replies in the previous thread this was forked from. Ultimately, this just "officially" gave other devs the right to touch the impacted packages. Nothing has really changed... -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Codec project
On Wed, Jun 10, 2020 at 08:25:20PM +0200, Michał Górny wrote: > Hi, > > Let's split this from [1] as I suppose having it in middle of high-noise > 'up for grabs' might prevent some interested people from seeing it. > > The general purpose of codec project [2] is to maintain core libraries > for various multimedia format encoder/decoder libraries. It's like > gfx+sound+video except only for core packages and not every possible > single viewer, player, editor, frontend... I believe that this specific > focus make more sense than the wider projects, i.e. it is more likely > than N people will actually co-maintain libraries used by many tools vs > N people co-maintain 20 alternative sound players (when they are > unlikely to use more than one at a time). > > The main questions are: > > 1. Should the project be focused on reference/most common > implementations, or maybe more of them? Say, giflib vs libnsgif. > I think the latter library is specific to a few programs right now but > if it gets more popular, it would fit. > I am not really sure that we *need* a project. I have seen many devs takeover several packages... of those individuals, they are active and I don't believe they would complain if others touched former @graphics packages. > 3. What about libraries implementing media-specific streaming protocols? As stated above, I am not sure we need a project to maintain these. Of course, it *would* be nice. Attempting to define something out of such disparity seems frivolous, but I understand the intention. Additionally, I am not advocating for the disbandment of all projects, but simply those that lack impact. It was more an effort to show that *most* individuals in said project were slacking, but would complain when others attempted to assist. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-cluster/polysh
# Aaron Bauman (2020-06-07) # py2 only. dead upstream. m-n. rdep. # Masked for removal in 15 days sys-cluster/polysh -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: net-misc/charm
# Aaron Bauman (2020-06-07) # py2 only. dead upstream. m-n. rdep. # Masked for removal in 15 days net-misc/charm -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > Hi, > > our concept of "Projects" (Herds in the past) maintaining packages has > several problems. [snip] Overall, projects work if the members are active. Of course, they don't if not. So, whether a package is assigned to a project, a sole-maintainer, or co-maintainers means others will *unlikely* attempt to fix or bump the package. Of course, we know that some devs will inevitably bump the package when it get's in their way or they use it directly. However, if the package is assigned to maintainer-needed then proxy-maintainers, random contributors, and other Gentoo devs will feel more comfortable touching it. I believe the system works... I will happily revert my change on the graphics project Wiki as you may want to remove the other inactive members or recruit some folks to join the project. Then possibly pick up the stray packages that others haven't taken. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sat, Jun 06, 2020 at 02:50:31PM -0400, Aaron Bauman wrote: > All, the graphics project has now been disbanded. > > All packages have been reassigned to maintainer-needed. Bugs will be > reassigned soon. > > Here are a list of the packages that are now up for grabs: > > dev-cpp/pngpp To expound on this, the graphics project has a quite a few bugs assigned to them (169). A few packages have co-maintainers, but these are still reflected in the metadata as required. If anyone else has time to address the bugs or wants to take the package over please do. If you hit a package with a co-maintainer then my apologies. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sat, Jun 06, 2020 at 08:55:38PM +0200, Pacho Ramos wrote: > El sáb, 06-06-2020 a las 14:50 -0400, Aaron Bauman escribió: > > All, the graphics project has now been disbanded. > > > > All packages have been reassigned to maintainer-needed. Bugs will be > > reassigned soon. > > > > Here are a list of the packages that are now up for grabs: > > > [...] > > I have seen that many of them already have maintainers or co-maintainers, > maybe > listing only those that are going to maintainer-needed would be more useful to > catch packages needing attention > > Thanks Pacho, thanks. I did not remove those packages from the email, but the metadata still reflects properly. A cursory look at the packages with more than 1 maintainer seems rather small. -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
All, the graphics project has now been disbanded. All packages have been reassigned to maintainer-needed. Bugs will be reassigned soon. Here are a list of the packages that are now up for grabs: dev-cpp/pngpp media-gfx/album media-gfx/apng2gif media-gfx/apngasm media-gfx/apngdis media-gfx/apngopt media-gfx/autopano-sift-C media-gfx/blender media-gfx/cellwriter media-gfx/chafa media-gfx/cptutils media-gfx/darktable media-gfx/dcraw media-gfx/duhdraw media-gfx/enblend media-gfx/exact-image media-gfx/exif media-gfx/exiv2 media-gfx/feh media-gfx/fim media-gfx/fontypython media-gfx/fr0st media-gfx/gif2apng media-gfx/gif2png media-gfx/gifsicle media-gfx/gimageview media-gfx/gmic media-gfx/gnofract4d media-gfx/gphoto2 media-gfx/gphotofs media-gfx/gpicview media-gfx/gqview media-gfx/graphicsmagick media-gfx/grub-splashes media-gfx/gtkam media-gfx/gtkimageview media-gfx/hugin media-gfx/icon-slicer media-gfx/igal media-gfx/imagemagick media-gfx/jhead media-gfx/jigl media-gfx/jpeg2ps media-gfx/jpeginfo media-gfx/jpegoptim media-gfx/jpegpixi media-gfx/jpegtoavi media-gfx/libimagequant media-gfx/llgal media-gfx/luminance-hdr media-gfx/mandelbulber media-gfx/mcomix media-gfx/metapixel media-gfx/mscgen media-gfx/nvidia-cg-toolkit media-gfx/openclipart media-gfx/panini media-gfx/pdf2svg media-gfx/png2ico media-gfx/pngcheck media-gfx/pngcrush media-gfx/pngquant media-gfx/pngrewrite media-gfx/pngtools media-gfx/potrace media-gfx/povtree media-gfx/pqiv media-gfx/pqstego media-gfx/qiv media-gfx/qvv media-gfx/raw-thumbnailer media-gfx/rawtherapee media-gfx/rotoscope media-gfx/scantailor-advanced media-gfx/scour media-gfx/scrot media-gfx/sfftobmp media-gfx/shotwell media-gfx/sxiv media-gfx/tintii media-gfx/tuxpaint-stamps media-gfx/tuxpaint media-gfx/ufraw media-gfx/uniconvertor media-gfx/wings media-gfx/wkhtmltopdf media-gfx/xli media-gfx/xloadimage media-gfx/xsane media-gfx/xzgv media-libs/cimg media-libs/esdl media-libs/exiftool media-libs/flickcurl media-libs/gd media-libs/giblib media-libs/giflib media-libs/icclib media-libs/imlib media-libs/jbig2dec media-libs/jbigkit media-libs/jpeg media-libs/lasi media-libs/lensfun media-libs/libexif-gtk media-libs/libexif media-libs/libfpx media-libs/libgphoto2 media-libs/libharu media-libs/libheif media-libs/libicns media-libs/libjpeg-turbo media-libs/libmng media-libs/libpano13 media-libs/libpgf media-libs/libpqstego media-libs/libraw media-libs/libwebp media-libs/netpbm media-libs/opencolorio media-libs/openimageio media-libs/openjpeg media-libs/pnglite media-libs/stimg media-libs/tiff media-libs/urt sci-visualization/grace virtual/imagemagick-tools virtual/jpeg-compat virtual/jpeg x11-libs/gdk-pixbuf-loader-webp x11-misc/gromit x11-misc/shutter -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, Jun 05, 2020 at 06:27:51PM -0700, Christopher Head wrote: > On Fri, 5 Jun 2020 12:40:17 -0700 > Matt Turner wrote: > > > With that in mind, I don't expect it to gain Python 3 support, nor do > > I expect an additional 15 days of waiting time to change that fact. 15 > > vs 30 days doesn't seem worth squabbling over. > > Not that I care about this specific case, but isn’t the 30-day time > period also meant as a nice long warning time for people *using* the > package to give them time to migrate to something else before it starts > to be unsupported, potentially break the depgraph, no longer be > installable on additional systems, and so on? > -- > Christopher Head That perspective opens a new potential bikeshed. I doubt anyone wants to have anotehr Py2 removal debate... Of course, the depgraph is not an issue. If a package is masked, it will break immediately. Hence, required checks are run then the package is masked. -- Cheers, Aaron signature.asc Description: PGP signature
