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
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
> 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
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
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
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
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
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
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
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
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
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
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
> 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
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
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.
>
>
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
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,
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
> 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
>
> => 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.
--
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
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
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
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
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
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
27 matches
Mail list logo
