Re: [gentoo-portage-dev] [PATCH] depgraph: respect

2020-04-11 Thread Zac Medico
On 4/11/20 6:10 PM, Brian Dolbec wrote: > On Sat, 11 Apr 2020 17:39:53 -0700 > Zac Medico wrote: > >> When searching for slot operator rebuilds, respect non slot-operator >> components of parent dependencies, so that a > like the > not be completely ignored. This will prevent erroneous attempts

Re: [gentoo-portage-dev] [PATCH] depgraph: respect

2020-04-11 Thread Brian Dolbec
On Sat, 11 Apr 2020 17:39:53 -0700 Zac Medico wrote: > When searching for slot operator rebuilds, respect non slot-operator > components of parent dependencies, so that a like the not be completely ignored. This will prevent erroneous attempts to > trigger slot operator rebuilds for upgrades

[gentoo-portage-dev] [PATCH] depgraph: respect

2020-04-11 Thread Zac Medico
When searching for slot operator rebuilds, respect non slot-operator components of parent dependencies, so that a https://bugs.gentoo.org/717140 Signed-off-by: Zac Medico --- lib/_emerge/depgraph.py | 12 +--- .../resolver/test_slot_operator_reverse_deps.py

Re: [gentoo-dev] [PATCH 03/10] glep-0072: Rename bad depgraph state to 'degraded'

2020-04-11 Thread Andreas K . Hüttel
Am Samstag, 11. April 2020, 14:23:48 EEST schrieb Michał Górny: > On Sat, 2020-04-11 at 12:08 +0200, Ulrich Mueller wrote: > > > > > > > On Sat, 11 Apr 2020, Michał Górny wrote: > > > Thinking about it, all these terms seem too generic. Would be nice to > > > find one that clearly suggests it's

Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival

2020-04-11 Thread Andreas K . Hüttel
> > => Keep it simple: Stable should mean the same across all architectures OK, this is a definite statement, so stable remains stable, and we introduce no additionally different status. I'd recommend that you drop the "security-supported arches" list from the security team web page too. --

[gentoo-dev] News item v2: potential file collisions during OpenCL upgrade

2020-04-11 Thread Marek Szuba
All the comments made so far have been considered. Regarding the possibility of automating the process, I think I would rather not bother... It feels hacky indeed, it would likely have to persist in loader ebuilds until eselect-opencl has been removed, and it would either require an eclass or have

Re: [gentoo-dev] ebuild life cycle review

2020-04-11 Thread Samuel Bernardo
Hi, Thank you very much for your experience and information sharing. I learnt very much with your answers. --- The goal of my suggestions was related to ebuilds that become unattended more than one year or being left behind even further. Anyway the right timescale depends on each project and so

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Ulrich Mueller
> On Sat, 11 Apr 2020, Marek Szuba wrote: > I have tried doing this in pkg_preinst but alas, I have found out > collision checks are performed before that function is invoked. I have > also tried setting COLLISION_IGNORE in the replacing package but it > seems that variable only works in

[gentoo-dev] forthcoming app-admin/sudo-1.9.0 - time to place your feature requests now!

2020-04-11 Thread Lars Wendler
Hi list, sudo-1.9.0 is around the corner. Right now 1.9.0_rc2 is available and provides new python bindings as well as a sudo_logsrvd. If you are interested in the latter feature, add =app-admin/sudo-1.9.0_rc* ** to your /etc/portage/package.accept_keywords and give the release candidate a

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Michał Górny
On Sat, 2020-04-11 at 18:28 +0200, Thomas Deutschmann wrote: > On 2020-04-11 17:33, Michał Górny wrote: > > 1. We kill both keywords, and just rely on components, or > > > > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where > > appropriate. > > I think you cannot kill it. > >

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Marek Szuba
On 2020-04-11 14:54, Brian Evans wrote: > I would mention that FEATURES='-collision-protect protect-owned' is > the default so most people won't have any action to take at all. I've been wondering what the default is these days. Good point, in fact I'll swap the case around so that the flow of

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Mike Gilbert
On Sat, Apr 11, 2020 at 12:28 PM Thomas Deutschmann wrote: > > On 2020-04-11 17:33, Michał Górny wrote: > > 1. We kill both keywords, and just rely on components, or > > > > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where > > appropriate. > > I think you cannot kill it. > > Yes,

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Thomas Deutschmann
On 2020-04-11 17:33, Michał Górny wrote: > 1. We kill both keywords, and just rely on components, or > > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where > appropriate. I think you cannot kill it. Yes, we have a component for stabilization/keywording, but we also do

Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival

2020-04-11 Thread Thomas Deutschmann
Hi, regarding "security supported architectures" a few words from security project: We don't like the differentiation. And in practice, it doesn't even matter nor does it work: In theory, "security supported architectures" would allow us to ignore bugs only affecting specific architectures. But

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Ulrich Mueller
> On Sat, 11 Apr 2020, Marek Szuba wrote: > Title: Manual steps required during upgrade to an eselect-free OpenCL set-up Title is too long. > Author: Marek Szuba > Posted: 2020-05-01 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: app-eselect/eselect-opencl > We are now in

Re: [gentoo-dev] ebuild life cycle review

2020-04-11 Thread James Le Cuirot
On Fri, 10 Apr 2020 18:21:00 +0200 Jonas Stein wrote: > > I would like to leave a suggestion for Gentoo portage ebuild review. > > Since there are some ebuilds in portage that become outdated for more > > than one year when there are new versions available, maybe could be > > possible to add a

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Kent Fredric
On Sat, 11 Apr 2020 11:39:21 -0400 Michael Orlitzky wrote: > I've been setting them just in case someone has a workflow/automation > involving the keywords that hasn't been updated in ten years. If you > kill the keywords, I wouldn't have to worry about that, so +1. And that's pretty much the

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread James Le Cuirot
On Sat, 11 Apr 2020 18:38:27 +0300 Joonas Niilola wrote: > On 4/11/20 6:33 PM, Michał Górny wrote: > > Hi, > > > > Now that we have proper components for keywording and stabilization, > > the old keywords are redundant. Nevertheless, some people still set > > them. I would like to propose two

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Michael Orlitzky
On 4/11/20 11:33 AM, Michał Górny wrote: > Hi, > > Now that we have proper components for keywording and stabilization, > the old keywords are redundant. Nevertheless, some people still set > them. I would like to propose two solutions going forward. Either: > > 1. We kill both keywords, and

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Joonas Niilola
On 4/11/20 6:33 PM, Michał Górny wrote: > Hi, > > Now that we have proper components for keywording and stabilization, > the old keywords are redundant. Nevertheless, some people still set > them. I would like to propose two solutions going forward. Either: > > 1. We kill both keywords, and

[gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Michał Górny
Hi, Now that we have proper components for keywording and stabilization, the old keywords are redundant. Nevertheless, some people still set them. I would like to propose two solutions going forward. Either: 1. We kill both keywords, and just rely on components, or 2. I make NATTkA

Re: [gentoo-dev] ebuild life cycle review

2020-04-11 Thread Kent Fredric
On Fri, 10 Apr 2020 12:31:19 +0100 Samuel Bernardo wrote: > - if there is more then X new versions in upstream, get from a release > feed associated with ebuild (X value defined by project leader with > threshold set by CI) This is probably the biggest difficult part really. There's lots of

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Brian Evans
On 4/11/20 9:37 AM, Marek Szuba wrote: > Does this look okay to you, guys? The date is preliminary and dependent > on how quickly we can get nvidia-drivers migrated to the new approach, > hopefully we can get this to happen sooner. > > * * * > > Title: Manual steps required during upgrade to an

[gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Marek Szuba
Does this look okay to you, guys? The date is preliminary and dependent on how quickly we can get nvidia-drivers migrated to the new approach, hopefully we can get this to happen sooner. * * * Title: Manual steps required during upgrade to an eselect-free OpenCL set-up Author: Marek Szuba

Re: [gentoo-dev] [PATCH 03/10] glep-0072: Rename bad depgraph state to 'degraded'

2020-04-11 Thread Michał Górny
On Sat, 2020-04-11 at 12:08 +0200, Ulrich Mueller wrote: > > > > > > On Sat, 11 Apr 2020, Michał Górny wrote: > > Thinking about it, all these terms seem too generic. Would be nice to > > find one that clearly suggests it's between testing and stable, and not > > 'lenient' in ~arch. How about

[gentoo-dev] OpenCL refactoring: status report, 2020-04-11

2020-04-11 Thread Marek Szuba
Dear everyone, I am happy to say that we are now almost ready for switching to eselect-opencl-free handling of OpenCL in Gentoo. Both ocl-icd and opencl-icd-loader have now got (masked) versions in the tree which install directly into /usr, the switching between the two works seamlessly, and I

Re: [gentoo-dev] [PATCH 03/10] glep-0072: Rename bad depgraph state to 'degraded'

2020-04-11 Thread Ulrich Mueller
> On Sat, 11 Apr 2020, Michał Górny wrote: > Thinking about it, all these terms seem too generic. Would be nice to > find one that clearly suggests it's between testing and stable, and not > 'lenient' in ~arch. How about 'transitional' or 'incomplete-stable'? "interim"? signature.asc