On Sat, 04 Jan 2020 19:41:21 +0100
Michał Górny wrote:
> On Sat, 2020-01-04 at 08:38 +0100, Hanno Böck wrote:
> > On Fri, 3 Jan 2020 15:48:54 +0100
> > Toralf Förster wrote:
> >
> > > # Restrict potential illegal access via links
> > > #
> > > fs.protected_hardlinks = 1
> > > fs.protec
On 1/4/20 2:13 PM, Rolf Eike Beer wrote:
>
> Bad idea. If you wonder why: eshowkw dev-lang/rust.
>
Or consider that every rust package in Gentoo bundles hundreds of
libraries. We'd be fixing one security issue by introducing 10x more.
Not that rewriting it in rust would fix anything; writing it
On 2020.01.04 13:43, Thomas Deutschmann wrote:
> On 2020-01-04 14:08, Roy Bamford wrote:
> > emerge -1 vanilla-sources
> > eselect kernel ...
> > genkernel all
> > ...
>
> Please tell user to do
>
> genkernel --kernel-config=/proc/config.gz all
>
> by default which will give them a better experi
On Sat, Jan 4, 2020 at 3:13 PM Christopher Head wrote:
>
>
> Of course this would be a bad argument if V-S were lagging behind upstream
> significantly, and it’s a much better argument for packages that come with
> expectations of security team support than those that don’t, but it is
> somethi
On January 4, 2020 4:54:07 AM PST, Rich Freeman wrote:
>
>Uh, all it does is install kernel sources. They're useless unless you
>build a kernel using them.
>
>Apparently git and tar are too complicated for Gentoo users, but
>managing symlinks, using make, managing a bootloader, dealing with the
>
Am Samstag, 4. Januar 2020, 19:41:05 CET schrieb William Hubbs:
> On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky wrote:
> > On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> > > But here we are. Do we make OpenRC Linux-only and steal the fix from
> > > systemd? Or pretend to support other op
On Sat, 2020-01-04 at 12:41 -0600, William Hubbs wrote:
> On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky wrote:
> > On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> > > But here we are. Do we make OpenRC Linux-only and steal the fix from
> > > systemd? Or pretend to support other operating
On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky wrote:
> On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> >
> > But here we are. Do we make OpenRC Linux-only and steal the fix from
> > systemd? Or pretend to support other operating systems, but leave them
> > insecure?
> >
>
> Or the grip
On Sat, 2020-01-04 at 08:38 +0100, Hanno Böck wrote:
> On Fri, 3 Jan 2020 15:48:54 +0100
> Toralf Förster wrote:
>
> > # Restrict potential illegal access via links
> > #
> > fs.protected_hardlinks = 1
> > fs.protected_symlinks = 1
>
> Given the issues with openrc:
> Wouldn't it be a goo
On Sat, Jan 04, 2020 at 08:38:59AM +0100, Hanno Böck wrote:
> On Fri, 3 Jan 2020 15:48:54 +0100
> Toralf Förster wrote:
>
> > # Restrict potential illegal access via links
> > #
> > fs.protected_hardlinks = 1
> > fs.protected_symlinks = 1
>
> Given the issues with openrc:
> Wouldn't it b
On 2020-01-04 12:01, Rich Freeman wrote:
> Packages without security support should be masked. Really I don't
> see the point of even having this in the repo.
THIS! +infinite
And arches without security support in general can't have stable keywords.
But this is a dream. :-/
--
Regards,
Thoma
On 2020-01-04 14:08, Roy Bamford wrote:
> emerge -1 vanilla-sources
> eselect kernel ...
> genkernel all
> ...
Please tell user to do
genkernel --kernel-config=/proc/config.gz all
by default which will give them a better experience because new kernel
will be build based on kernel configuration f
On 2020.01.04 12:54, Rich Freeman wrote:
> On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford
> wrote:
[snip]
>
> Apparently git and tar are too complicated for Gentoo users, but
> managing symlinks, using make, managing a bootloader, dealing with the
> kernel's configuration system, and so on are just
On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford wrote:
>
> On 2020.01.04 11:01, Rich Freeman wrote:
> >
> > Is there some reason that we should keep vanilla sources despite not
> > getting security handling?
> >
>
> Gentoo had this discussion before. The outcome was that
> vanilla-sources is just as Li
On 2020.01.04 11:01, Rich Freeman wrote:
>
> Is there some reason that we should keep vanilla sources despite not
> getting security handling?
>
> --
> Rich
>
Rich,
Gentoo had this discussion before. The outcome was that
vanilla-sources is just as Linus intended.
If Gentoo did anything to it,
On Fri, Jan 3, 2020 at 11:28 AM Aaron Bauman wrote:
> On January 3, 2020 9:55:31 AM EST, Michael Orlitzky wrote:
> >On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> >>
> >> But here we are. Do we make OpenRC Linux-only and steal the fix from
> >> systemd? Or pretend to support other operating systems
On Fri, 3 Jan 2020 15:48:54 +0100
Toralf Förster wrote:
> # Restrict potential illegal access via links
> #
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1
Given the issues with openrc:
Wouldn't it be a good idea to add these by default to Gentoo's
sysctl.conf in baselayout?
As
On 03/01/20 14:48, Toralf Förster wrote:
> On 1/3/20 3:46 PM, Rich Freeman wrote:
>> If OpenRC contains a vulnerability wouldn't it make more sense to set
>> this as part of OpenRC,
> Indeed.
>
> Furthermore there's a nifty page
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/R
On January 3, 2020 9:55:31 AM EST, Michael Orlitzky wrote:
>On 1/3/20 9:52 AM, Michael Orlitzky wrote:
>>
>> But here we are. Do we make OpenRC Linux-only and steal the fix from
>> systemd? Or pretend to support other operating systems, but leave
>them
>> insecure?
>>
>
>Or the gripping hand:
On 1/3/20 9:52 AM, Michael Orlitzky wrote:
>
> But here we are. Do we make OpenRC Linux-only and steal the fix from
> systemd? Or pretend to support other operating systems, but leave them
> insecure?
>
Or the gripping hand: rewrite opentmpfiles in C, so that it's only as
insecure as checkpath.
On 1/3/20 9:46 AM, Rich Freeman wrote:
>
> ...
>
> In any case this seems more like an OpenRC issue than a Gentoo issue.
>
It's a specification issue. There's no way to implement tmpfiles safely
on a POSIX system, and opentmpfiles shouldn't exist if OpenRC wants to
work on anything other than L
On 1/3/20 3:46 PM, Rich Freeman wrote:
> If OpenRC contains a vulnerability wouldn't it make more sense to set
> this as part of OpenRC,
Indeed.
Furthermore there's a nifty page
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
which yields for me to this /etc
On Fri, Jan 3, 2020 at 9:41 AM Michael Orlitzky wrote:
>
> On 1/3/20 9:40 AM, Toralf Förster wrote:
> > On 1/3/20 3:37 PM, Michael Orlitzky wrote:
> >> The gentoo-sources aren't 100% safe either, but the exploitable scenario
> >> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
> >
>
On 1/3/20 9:40 AM, Toralf Förster wrote:
> On 1/3/20 3:37 PM, Michael Orlitzky wrote:
>> The gentoo-sources aren't 100% safe either, but the exploitable scenario
>> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
>
> But this can be easily achieved w/o installing gentoo-sources, or?
On 1/3/20 3:37 PM, Michael Orlitzky wrote:
> The gentoo-sources aren't 100% safe either, but the exploitable scenario
> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
But this can be easily achieved w/o installing gentoo-sources, or?
--
Toralf
PGP 23217DA7 9B888F45
signature.as
On 1/2/20 6:35 PM, Rolf Eike Beer wrote:
>
> I only run vanilla-sources since there are still lot of cache corruption
> problems in hppa kernels, or whatever makes them flaky.
The vanilla-sources are unsafe to use on Gentoo. Many services have
stupid-easy root exploits, since we install tmpfiles
On Fri, Jan 05, 2018 at 11:47:51PM +0900, Alice Ferrazzi wrote:
On Fri, Jan 5, 2018 at 11:08 PM, Nicolas Bock wrote:
Hi,
currently vanilla-sources are broken, but there is an upstream patch that
fixes it (appended at the end). I know that vanilla-sources are supposed to
be vanilla, but it woul
On Fri, Jan 5, 2018 at 11:08 PM, Nicolas Bock wrote:
> Hi,
>
> currently vanilla-sources are broken, but there is an upstream patch that
> fixes it (appended at the end). I know that vanilla-sources are supposed to
> be vanilla, but it would help if we added this patch until upstream
> backports i
Hi,
currently vanilla-sources are broken, but there is an upstream patch that fixes
it (appended at the end). I know that vanilla-sources are supposed to be
vanilla, but it would help if we added this patch until upstream backports it.
Any thoughts?
Best,
Nick
From 9d641b18db295b9ded33df0
On Fri, Aug 09, 2013 at 09:46:43PM +0200, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 12:30:42 -0700
> Greg KH wrote:
>
> > ... Just read the commits to find out what is resolved, ...
> >
> > ... Because it's extra work that is pointless. ...
> >
> > > No classification is done if there is no sing
On Fri, 9 Aug 2013 12:30:42 -0700
Greg KH wrote:
> ... Just read the commits to find out what is resolved, ...
>
> ... Because it's extra work that is pointless. ...
>
> > No classification is done if there is no single command to obtain
> > them.
>
> I don't understand what you mean by this.
On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote:
> On Thu, 8 Aug 2013 15:32:45 -0700
> Greg KH wrote:
>
> > On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> > > On Wed, 7 Aug 2013 15:44:34 -0700
> > > Greg KH wrote:
> > >
> > > > I am not going to impose an additional
On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 06:38:56 -0400
> Rich Freeman wrote:
>
> > My sense is that Greg is using the term security bugs to refer to
> > implementation errors that could be exploited to obtain unintended
> > access to a system. Using this
On Fri, 9 Aug 2013 06:38:56 -0400
Rich Freeman wrote:
> My sense is that Greg is using the term security bugs to refer to
> implementation errors that could be exploited to obtain unintended
> access to a system. Using this definition, any bug could be a
> security bug, and figuring this out is
On Fri, Aug 9, 2013 at 4:34 AM, Tom Wijsman wrote:
> On Thu, 8 Aug 2013 15:32:45 -0700
> Greg KH wrote:
>> On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
>> > > And what about all of the fixes I merge in, that _are_ really
>> > > security fixes, yet we do not want to shout it out to
On Thu, 8 Aug 2013 15:32:45 -0700
Greg KH wrote:
> On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> > On Wed, 7 Aug 2013 15:44:34 -0700
> > Greg KH wrote:
> >
> > > I am not going to impose an additional burden on developers to get
> > > their patches into the stable kernel releas
On Fri, 9 Aug 2013 01:44:12 +0200
Peter Stuge wrote:
> > > I think this supports the argument that the better kernel is
> > > always the one with the most fixes.
> >
> > That's what us kernel developers have been saying for 10+ years,
> > nice to see it's finally getting some traction :)
>
> It
On Thu, 8 Aug 2013 15:29:06 -0700
Greg KH wrote:
> On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
> >
> > > On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> > > > I think this supports the argument that the better kernel is
> > > > always the one with the most fixes.
Greg KH wrote:
> > > See above for why it is not easy at all, and, why even if we do know
> > > some fixes are security ones, we would not tag them as such anyway.
> >
> > I think this supports the argument that the better kernel is always
> > the one with the most fixes.
>
> That's what us kerne
On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> On Wed, 7 Aug 2013 15:44:34 -0700
> Greg KH wrote:
>
> > On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
> >
> > > Some kind of annotation with tags would make this kind of thing
> > > easy; I'm not saying it is your task
On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
> On Wed, 7 Aug 2013 16:19:43 -0700
> Greg KH wrote:
>
> > On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> > > Greg KH wrote:
> > > > See above for why it is not easy at all, and, why even if we do
> > > > know some fixes
On Wed, 7 Aug 2013 16:19:43 -0700
Greg KH wrote:
> On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> > Greg KH wrote:
> > > See above for why it is not easy at all, and, why even if we do
> > > know some fixes are security ones, we would not tag them as such
> > > anyway.
> >
> > I
On Wed, 7 Aug 2013 15:44:34 -0700
Greg KH wrote:
> On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
>
> > Some kind of annotation with tags would make this kind of thing
> > easy; I'm not saying it is your task to apply such annotations to
> > commits, but it would rather be the task
On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> Greg KH wrote:
> > See above for why it is not easy at all, and, why even if we do know
> > some fixes are security ones, we would not tag them as such anyway.
>
> I think this supports the argument that the better kernel is always
> t
Greg KH wrote:
> See above for why it is not easy at all, and, why even if we do know
> some fixes are security ones, we would not tag them as such anyway.
I think this supports the argument that the better kernel is always
the one with the most fixes.
Rather than separating "bug fixes" from "sec
On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
> On Wed, 24 Jul 2013 16:09:11 -0700
> Greg KH wrote:
>
> > Please
> > tell me exactly how you are going to evaluate which fixes I make are
> > security fixes, and you know which to pick and choose from.
>
> Some kind of annotation wit
On Sat, 27 Jul 2013 15:32:39 +0200
Manuel Rüger wrote:
> On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
> > On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
> >> How about dropping vanilla-sources and adding a "vanilla" USE flag
> >> to gentoo-sources?
> > Then we might as well just hav
On Wed, 24 Jul 2013 23:17:36 +0100
Markos Chandras wrote:
> This thread derailed as usual. The kernel team made a decision.
Perhaps it did, perhaps it didn't; I do not intend to discuss this but
to rather clarify the decision that was made, as a matter of support.
The reason the reply was on the
On Wed, 24 Jul 2013 16:09:11 -0700
Greg KH wrote:
> Please
> tell me exactly how you are going to evaluate which fixes I make are
> security fixes, and you know which to pick and choose from.
Some kind of annotation with tags would make this kind of thing easy;
I'm not saying it is your task to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/07/13 15:32, Manuel Rüger wrote:
> On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
>> Then we might as well just have a Linux package with a bunch of
>> USE flags -- gentoo, hardened, libre, tuxonice, ck, etc.
> This is not a good idea, I'd
On Saturday, July 27, 2013 09:58:08 AM Rich Freeman wrote:
>
> Unless it were stable-masked it would create the exact same problem.
>
^^ This
--
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3
Publi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Berntsen schrieb:
> On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
>> How about dropping vanilla-sources and adding a "vanilla" USE flag to
>> gentoo-sources?
> Then we might as well just have a Linux package with a bunch of USE
> fl
On Sat, Jul 27, 2013 at 4:56 AM, Chí-Thanh Christopher Nguyễn
wrote:
> Mike Pagano schrieb:
>> Team members working alongside upstream (and downstream) developer Greg k-h
>> have decided to no longer request stabilization of the vanilla sources
>> kernel.
>
> How about dropping vanilla-sources an
On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
> On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
>> How about dropping vanilla-sources and adding a "vanilla" USE flag
>> to gentoo-sources?
> Then we might as well just have a Linux package with a bunch of USE
> flags -- gentoo, hardened,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
> How about dropping vanilla-sources and adding a "vanilla" USE flag
> to gentoo-sources?
Then we might as well just have a Linux package with a bunch of USE
flags -- gentoo, hardened, libre, tu
Mike Pagano schrieb:
> Team members working alongside upstream (and downstream) developer Greg k-h
> have decided to no longer request stabilization of the vanilla sources
> kernel.
How about dropping vanilla-sources and adding a "vanilla" USE flag to
gentoo-sources?
Best regards,
Chí-Thanh
24.07.2013 22:16, Peter Stuge пишет:
> It seems that for this package Gentoo QA can not realistically add
> any value to this package, hence my suggestion not to pretend that
> they can, and just remove the distinction between ~arch and arch for
> v-s, and make the latest version available to users
On Wed, Jul 24, 2013 at 7:09 PM, Greg KH wrote:
> On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
>> It just seems like we should be able to get by without a semiweekly
>> kernel upgrade on our "stable" branch.
>
> You want me to slow down and do releases in larger chunks then? Hah,
On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
> Also, not all fixes are equal. The ones that are the biggest concern
> are security fixes.
How do you _know_ which fixes are security fixes?
> If you tell me that the kernel has a new exploit
> 2x/week then I'll start to wonder when
On 24 July 2013 21:59, Tom Wijsman wrote:
> On Wed, 24 Jul 2013 20:16:59 +0200
> Peter Stuge wrote:
>
>> Alex Xu wrote:
>> > >>> Maybe it would make sense to automatically stabilize every v-s
>> > >>> kernel right away?
>> > >>
>> > >> As has been stated, this implies that Gentoo QA has tested th
On Wed, 24 Jul 2013 20:16:59 +0200
Peter Stuge wrote:
> Alex Xu wrote:
> > >>> Maybe it would make sense to automatically stabilize every v-s
> > >>> kernel right away?
> > >>
> > >> As has been stated, this implies that Gentoo QA has tested the
> > >> packages and found them to be reasonably saf
On Wed, 24 Jul 2013 16:40:38 -0400
Rich Freeman wrote:
> Also, not all fixes are equal. The ones that are the biggest concern
> are security fixes.
Why? Which is worse: a local denial of service attack when every user
on your box has sudo access anyway, or a random data corruption bug
that can't
On Wed, 24 Jul 2013 21:15:15 +0200
Peter Stuge wrote:
> Ben Kohler wrote:
> > > I am suggesting that the latest available upstream kernel should
> > > perhaps be the default for Gentoo users.
> >
> > You seem to be ignoring the regressions that often come with new
> > kernel releases, the very c
On Wed, Jul 24, 2013 at 3:15 PM, Peter Stuge wrote:
> Ben Kohler wrote:
>> > I am suggesting that the latest available upstream kernel should
>> > perhaps be the default for Gentoo users.
>>
>> You seem to be ignoring the regressions that often come with new kernel
>> releases, the very common bre
On Wed, 24 Jul 2013 21:01:30 +0200
Peter Stuge wrote:
> I am suggesting that the latest available upstream kernel should
> perhaps be the default for Gentoo users.
See my previous e-mail; if you're willing to go through with this
suggestion, then please back that up with sufficient reasoning. Th
On Wed, 24 Jul 2013 19:54:10 +0200
Peter Stuge wrote:
> Rich Freeman wrote:
> > > As has been stated, this implies that Gentoo QA has tested the
> > > packages and found them to be reasonably safe for use.
> >
> > ++
>
> While good in theory, it seems that newer v-s are actually more
> "reasona
Ben Kohler wrote:
> > I am suggesting that the latest available upstream kernel should
> > perhaps be the default for Gentoo users.
>
> You seem to be ignoring the regressions that often come with new kernel
> releases, the very common breakage caused in stable "genkernel all", and
> other various
On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge wrote:
>
>
> To be clear: I am not suggesting to change the meaning of stable,
> I am suggesting that the latest available upstream kernel should
> perhaps be the default for Gentoo users. How to make that happen
> is less important, the idea to automat
Rich Freeman wrote:
> >> Stable should mean something
> >
> > For users, stable means "older" in practice. Always did, always will.
>
> Don't change the meaning of stable, however, for those who find it useful.
This is a good point, but the original post suggested to me that
actually every new re
On Wed, Jul 24, 2013 at 1:54 PM, Peter Stuge wrote:
> Rich Freeman wrote:
>
>> Stable should mean something
>
> For users, stable means "older" in practice. Always did, always will.
If you don't like stable, then don't run stable. Don't change the
meaning of stable, however, for those who find i
Alex Xu wrote:
> >>> Maybe it would make sense to automatically stabilize every v-s kernel
> >>> right away?
> >>
> >> As has been stated, this implies that Gentoo QA has tested the packages
> >> and found them to be reasonably safe for use.
> > ..
> >> Although stable kernels *have* been tested by
On 24/07/13 01:49 PM, Peter Stuge wrote:
> Alex Xu wrote:
>>> Maybe it would make sense to automatically stabilize every v-s kernel
>>> right away?
>>
>> As has been stated, this implies that Gentoo QA has tested the packages
>> and found them to be reasonably safe for use.
> ..
>> Although stable
Rich Freeman wrote:
> > As has been stated, this implies that Gentoo QA has tested the packages
> > and found them to be reasonably safe for use.
>
> ++
While good in theory, it seems that newer v-s are actually more
"reasonably safe" than any g-s.
> Stable should mean something
For users, sta
Alex Xu wrote:
> > Maybe it would make sense to automatically stabilize every v-s kernel
> > right away?
>
> As has been stated, this implies that Gentoo QA has tested the packages
> and found them to be reasonably safe for use.
..
> Although stable kernels *have* been tested by many people before
Mike Pagano wrote:
> Team members working alongside upstream (and downstream) developer Greg k-h
> have decided to no longer request stabilization of the vanilla sources
> kernel.
> Team members and arch teams (understandably) are unable to keep up with the
> 1-2 weekly kernel releases, and th
On Wed, Jul 24, 2013 at 1:43 PM, Alex Xu wrote:
> As has been stated, this implies that Gentoo QA has tested the packages
> and found them to be reasonably safe for use.
++
Stable should mean something, and those who understand the tradeoffs
can accept unstable packages where needed (far more ea
On 24/07/13 01:37 PM, Peter Stuge wrote:
> Mike Pagano wrote:
>> Team members working alongside upstream (and downstream) developer Greg k-h
>> have decided to no longer request stabilization of the vanilla sources
>> kernel.
>> Team members and arch teams (understandably) are unable to keep up
tl;dr
Summary
Team members working alongside upstream (and downstream) developer Greg k-h
have decided to no longer request stabilization of the vanilla sources kernel.
Team members and arch teams (understandably) are unable to keep up with the
1-2 weekly kernel releases, and therefore will
78 matches
Mail list logo
