[gentoo-kernel] Which Kernel?

[gentoo-kernel] Which Kernel?

[Gino!]

So, it seems like gentoo-sources loves EOL kernels..
can anybody tell me why this is, it seems like that would be a bad thing...
I always move up to the latest amd64 stable, but 3.7.9 is super buggy
(nvidia and aufs3 complain among others) so I'm staying at 3.6.11...
although I would feel allot more comfortable with something like
3.4.33!! but its at 3.4.9...


Do you gentoo-sources folks recommend a particular release for Long Term
Stable ongoing support??? Thats the one i want to use.

Thanks!!

Gino

Re: [gentoo-kernel] Which Kernel?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Mon, 25 Feb 2013 01:05:01 -0500
"Gino!" <ginolovesyou@gmail.com> wrote:

> So, it seems like gentoo-sources loves EOL kernels..

Well, if they EOL both 3.5 and 3.6 there isn't much we can do
about that. Although, since we're now with at least two we try to
provide everything in 3.x. So the only thing we don't do for the moment
is the 2.x kernels, there is one in the vanilla sources if needed.

> I always move up to the latest amd64 stable, but 3.7.9 is
> super buggy (nvidia and aufs3 complain among others)

The problem here is those external drivers are not following along the
kernel changes in a timely matter, not the other way around. If needed,
you can find patches for them by now; there is even a patch to run
NVIDIA on 3.8, it's just that NVIDIA takes their time to apply them.

> so I'm staying at 3.6.11... although I would feel allot more
> comfortable with something like 3.4.33!! but its at 3.4.9...

What's wrong with 3.6.11 then?

And yes, I'll try to check up with mpagano if it is possible to
stabilize one or two kernels from those gaps.

> Do you gentoo-sources folks recommend a particular release for Long
> Term Stable ongoing support??? Thats the one i want to use.

You've named them, if you want to go for "stable" versions you can take
your pick between 3.4.9, 3.5.7, 3.6.11 or 3.7.9. I assume you will want
to avoid the EOL kernels, so you might end up deciding between 3.4.9
(where we might stabilize ~3.4.33) or 3.7.9 (for which NVIDIA and
other external drivers will eventually work, you can patch them).


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Peter Gantner (nephros)]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1618 bytes --]

2013-02-25 quidam/quædam/quoddam 'Tom Wijsman' inquit:

> On Mon, 25 Feb 2013 01:05:01 -0500
> "Gino!" <ginolovesyou@gmail.com> wrote:
>
>> So, it seems like gentoo-sources loves EOL kernels..
>
> Well, if they EOL both 3.5 and 3.6 there isn't much we can do
> about that. Although, since we're now with at least two we try to
> provide everything in 3.x. So the only thing we don't do for the moment
> is the 2.x kernels, there is one in the vanilla sources if needed.
>
>
>> so I'm staying at 3.6.11... although I would feel allot more
>> comfortable with something like 3.4.33!! but its at 3.4.9...

Personally for those machines I have decided to keep super stable (in 
terms of updating software, at least as far as that is reasonably 
possible with Gentoo) I have had good results with choosing whatever 
Greg KH dubs his Long Term kernel (currenlty 3.4) and then simply 
package.keyword that whole series:

=sys-kernel/gentoo-sources-3.0* # GKH stable
=sys-kernel/gentoo-sources-3.1* -*
=sys-kernel/gentoo-sources-3.2* -*
=sys-kernel/gentoo-sources-3.3* -*
=sys-kernel/gentoo-sources-3.5* -* # EOL
=sys-kernel/gentoo-sources-3.4* # GKH stable
=sys-kernel/gentoo-sources-3.6* -* # EOL
=sys-kernel/gentoo-sources-3.7* -* # not supported by NVidia 310.xx

I don't mind keywording the minor-minor release from Gentoo, I find it 
unlikely much will break in such a release.

Much less in any case than jumping up two minor releases for example.


HTH
   Peter

-- 
Gentoo is like IKEA -- only stable.
                                                 © P. Gantner 2003-2013

Re: [gentoo-kernel] Which Kernel?

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

Am Montag, 25. Februar 2013, 18:35:21 schrieb Peter Gantner:
> 2013-02-25 quidam/quædam/quoddam 'Tom Wijsman' inquit:
> > On Mon, 25 Feb 2013 01:05:01 -0500
> > 
> > "Gino!" <ginolovesyou@gmail.com> wrote:
> >> So, it seems like gentoo-sources loves EOL kernels..
> > 
> > Well, if they EOL both 3.5 and 3.6 there isn't much we can do
> > about that. Although, since we're now with at least two we try to
> > provide everything in 3.x. So the only thing we don't do for the moment
> > is the 2.x kernels, there is one in the vanilla sources if needed.
> > 
> >> so I'm staying at 3.6.11... although I would feel allot more
> >> comfortable with something like 3.4.33!! but its at 3.4.9...
> 
> Personally for those machines I have decided to keep super stable (in
> terms of updating software, at least as far as that is reasonably
> possible with Gentoo) I have had good results with choosing whatever
> Greg KH dubs his Long Term kernel (currenlty 3.4) and then simply
> package.keyword that whole series:
> 
> =sys-kernel/gentoo-sources-3.0* # GKH stable
> =sys-kernel/gentoo-sources-3.1* -*
> =sys-kernel/gentoo-sources-3.2* -*
> =sys-kernel/gentoo-sources-3.3* -*
> =sys-kernel/gentoo-sources-3.5* -* # EOL
> =sys-kernel/gentoo-sources-3.4* # GKH stable
> =sys-kernel/gentoo-sources-3.6* -* # EOL
> =sys-kernel/gentoo-sources-3.7* -* # not supported by NVidia 310.xx
> 
> I don't mind keywording the minor-minor release from Gentoo, I find it
> unlikely much will break in such a release.


I like this idea. But are there any plans in always stabilizing the latest 
long term kernel within a short timewindow?

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Peter Gantner (nephros)]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1342 bytes --]

2013-02-26 quidam/quædam/quoddam 'Marc Schiffbauer' inquit:

> Am Montag, 25. Februar 2013, 18:35:21 schrieb Peter Gantner:
>> 2013-02-25 quidam/quædam/quoddam 'Tom Wijsman' inquit:
>>> On Mon, 25 Feb 2013 01:05:01 -0500
>>>
>> I have had good results with choosing whatever
>> Greg KH dubs his Long Term kernel (currenlty 3.4) and then simply
>> package.keyword that whole series:
>>
>> =sys-kernel/gentoo-sources-3.5* -* # EOL
>> =sys-kernel/gentoo-sources-3.4* # GKH stable
>>
>> I don't mind keywording the minor-minor release from Gentoo, I find it
>> unlikely much will break in such a release.
>
>
> I like this idea. But are there any plans in always stabilizing the latest
> long term kernel within a short timewindow?

Actually I have always wondered why the kernels are SLOTted by complete 
version and not just series. I imagine many peoples lives would be 
easier if they could just unmask xxx-sources:3.4 and therefore always 
get the current "upstream-stable" version of their preferred kernel.

But then there are probably good reasons for the way it is done. (Or, 
maybe, it is a holdover from 2.6.xx days where the two dots made more 
sense for SLOTs?)

Greets,
   Peter G.

  -- 
Gentoo is like IKEA -- only stable.
                                                 © P. Gantner 2003-2012

Re: [gentoo-kernel] Which Kernel?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

On Tue, 26 Feb 2013 18:37:16 +0100 (CET)
"Peter Gantner \(nephros\)" <gentoo@nephros.org> wrote:

> Actually I have always wondered why the kernels are SLOTted by
> complete version and not just series. I imagine many peoples lives
> would be easier if they could just unmask xxx-sources:3.4 and
> therefore always get the current "upstream-stable" version of their
> preferred kernel.
> 
> But then there are probably good reasons for the way it is done. (Or, 
> maybe, it is a holdover from 2.6.xx days where the two dots made more 
> sense for SLOTs?)

As an easy way to keep a single kernel version from being unmerged by
a kernel upgrade in Portage, I think.

    emerge gentoo-sources:3.7.9

If you then also have a plain gentoo-sources and a mask on anything
non-3.4 it becomes simple to pick which version you want to stay on as
well as to have the latest sources always available for when you decide
to spent some time upgrading to the latest version on your branch.

    # I want the 3.4 branch! I compile and install 3.4.32.
    echo ">=sys-kernel/gentoo-sources-3.4" >> /etc/portage/package.mask
    emerge gentoo-sources
    emerge --noreplace gentoo-sources:3.4.32

    # After a world update I decide I want to upgrade it, I do 3.4.33.
    emerge -uDN @world
    emerge --noreplace gentoo-sources:3.4.33

    # Ah, 3.4.33 works fine, I can get rid of the old version now.
    emerge -C gentoo-sources:3.4.32
    rm /usr/src/*3.4.32*

If you were to make the SLOTS branch based you would get rid of the
mask line in above example; but its side effect is that it would also
get rid of the easy SLOT syntax which will require you to specify
the full ATOM specification whenever you want to keep a version
around, or unmerge another. This is not worth the change...

Of course, this is just one approach to it; feel free to share a
different work flow if your approach differs from the above one. 


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

Am Dienstag, 26. Februar 2013, 19:13:18 schrieb Tom Wijsman:
> On Tue, 26 Feb 2013 18:37:16 +0100 (CET)
> 
> "Peter Gantner \(nephros\)" <gentoo@nephros.org> wrote:
> > Actually I have always wondered why the kernels are SLOTted by
> > complete version and not just series. I imagine many peoples lives
> > would be easier if they could just unmask xxx-sources:3.4 and
> > therefore always get the current "upstream-stable" version of their
> > preferred kernel.
> > 
> > But then there are probably good reasons for the way it is done. (Or,
> > maybe, it is a holdover from 2.6.xx days where the two dots made more
> > sense for SLOTs?)
> 
> As an easy way to keep a single kernel version from being unmerged by
> a kernel upgrade in Portage, I think.
> 
>     emerge gentoo-sources:3.7.9

But why would you want that? I think normally its more likely that a user 
wants to stick to the seriens (e.g. :3.7) so that he/she receives security 
updates as well as minor fixes.

If you really wanted to stick to a particular version you can always mask any 
version greater than that similar to what you wrote yourself below:

echo ">=sys-kernel/gentoo-sources-3.7" >> /etc/portage/package.mask

[snip]
 
> If you were to make the SLOTS branch based you would get rid of the
> mask line in above example;

right


> but its side effect is that it would also
> get rid of the easy SLOT syntax which will require you to specify
> the full ATOM specification whenever you want to keep a version
> around, or unmerge another. This is not worth the change...
> 
> Of course, this is just one approach to it; feel free to share a
> different work flow if your approach differs from the above one.
> 

First, if you remove any gentoo-sources package it will never remove the 
kernel or modules that have been built from it. So you will always keep the 
kernel that may be important if a newer one has problems for example. 
Regardless of removing the sources or not.

Then, I think using SLOTs for single versions is not really what SLOTs are 
made for. From what I understand, for a *single* *particular* version of any 
package you have ATOMs in portage and for a branch or a group of versions that 
belong together somehow you have SLOTs.

I personally would like to see this scheme for kernels too. Be it gentoo-
sources or hardened-sources.

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

On Wed, 27 Feb 2013 13:07:38 +0100
Marc Schiffbauer <mschiff@gentoo.org> wrote:

> Am Dienstag, 26. Februar 2013, 19:13:18 schrieb Tom Wijsman:
> > On Tue, 26 Feb 2013 18:37:16 +0100 (CET)
> > 
> > As an easy way to keep a single kernel version from being unmerged
> > by a kernel upgrade in Portage, I think.
> > 
> >     emerge gentoo-sources:3.7.9
> 
> But why would you want that? I think normally its more likely that a
> user wants to stick to the seriens (e.g. :3.7) so that he/she
> receives security updates as well as minor fixes.

Because when sources unmerge, nothing can build against them and you
also can't do a quick recompile if you do not want to do an upgrade.
The majority of users doesn't upgrade on every single release, it is
better to support them in their upgrade schedule instead of forcing
them to upgrade or use more complex approaches to do what they want.

> If you really wanted to stick to a particular version you can always
> mask any version greater than that similar to what you wrote yourself
> below:
> 
> echo ">=sys-kernel/gentoo-sources-3.7" >> /etc/portage/package.mask

Doing this once per branch or for each version is a big difference.
 
> First, if you remove any gentoo-sources package it will never remove
> the kernel or modules that have been built from it. So you will
> always keep the kernel that may be important if a newer one has
> problems for example. Regardless of removing the sources or not.

As stated above, that doesn't allow you to reproduce them quickly.

> Then, I think using SLOTs for single versions is not really what
> SLOTs are made for. From what I understand, for a *single*
> *particular* version of any package you have ATOMs in portage and for
> a branch or a group of versions that belong together somehow you have
> SLOTs.

Quoting `man 5 ebuild`:

    SLOT   This sets the SLOT for packages that may need to have
           versions co-exist.

It does not say anything about branches or groups, it actually states
versions. There are use cases where people want 3.7.8 and 3.7.9 to
co-exist, the thread root gives such an example (pending nvidia patch).

For small packages, it doesn't really matter how you do it; but
setting up the kernel (copy config, make oldconfig) and compiling it
make explicit (un)masking much more annoying than just keeping
multiple versions within a branch around.

> I personally would like to see this scheme for kernels too. Be it
> gentoo- sources or hardened-sources.

All kernels share this SLOT syntax, it is implemented in the eclass.

This is for the eclass maintainers to decide, but they will likely
depend their decision on what all the eclass users think about that;
the other option is moving it to the ebuild but that approach leads to
inconsistency which is probably not a good idea.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 3819 bytes --]

Am Mittwoch, 27. Februar 2013, 13:49:52 schrieb Tom Wijsman:
> On Wed, 27 Feb 2013 13:07:38 +0100
> 
> Marc Schiffbauer <mschiff@gentoo.org> wrote:
> > Am Dienstag, 26. Februar 2013, 19:13:18 schrieb Tom Wijsman:
> > > On Tue, 26 Feb 2013 18:37:16 +0100 (CET)
> > > 
> > > As an easy way to keep a single kernel version from being unmerged
> > > by a kernel upgrade in Portage, I think.
> > > 
> > >     emerge gentoo-sources:3.7.9
> > 
> > But why would you want that? I think normally its more likely that a
> > user wants to stick to the seriens (e.g. :3.7) so that he/she
> > receives security updates as well as minor fixes.
> 
> Because when sources unmerge, nothing can build against them and you
> also can't do a quick recompile if you do not want to do an upgrade.

Indeed. But I thought of it only as a backup so that you can boot your system 
in case a newer kernel won't.

Why would you want to continue to use an outdated/insecure kernel *from the 
same series* like 3.7*?

> The majority of users doesn't upgrade on every single release, it is
> better to support them in their upgrade schedule instead of forcing
> them to upgrade or use more complex approaches to do what they want.

Where would be the force? Uninstall of old sources would happen while they are 
upgrading.

I guess you are referring to a use case where user just upgrade packages but 
would not like to restart the system. This is indeed a use case for exact 
version slots.

Maybe both things yould coexist? Why not have both kinds of SLOTs then?


> > If you really wanted to stick to a particular version you can always
> > mask any version greater than that similar to what you wrote yourself
> > below:
> > 
> > echo ">=sys-kernel/gentoo-sources-3.7" >> /etc/portage/package.mask
> 
> Doing this once per branch or for each version is a big difference.

Indeed. The above mask would allow all 3.6* kernels rigtht?

> 
> > First, if you remove any gentoo-sources package it will never remove
> > the kernel or modules that have been built from it. So you will
> > always keep the kernel that may be important if a newer one has
> > problems for example. Regardless of removing the sources or not.
> 
> As stated above, that doesn't allow you to reproduce them quickly.

That was not my intention. Please see above.

> 
> Quoting `man 5 ebuild`:
> 
>     SLOT   This sets the SLOT for packages that may need to have
>            versions co-exist.
> 
> It does not say anything about branches or groups, it actually states
> versions. There are use cases where people want 3.7.8 and 3.7.9 to
> co-exist, the thread root gives such an example (pending nvidia patch).

Ok. Your point. Was just my "feeling" ;)

> 
> For small packages, it doesn't really matter how you do it; but
> setting up the kernel (copy config, make oldconfig) and compiling it
> make explicit (un)masking much more annoying than just keeping
> multiple versions within a branch around.

Sorry I do not get it. What is your point here? Getting minor kernel updates 
automatically without having to fiddle with masks/unmaks each time is the goal 
here IMO.

> 
> > I personally would like to see this scheme for kernels too. Be it
> > gentoo- sources or hardened-sources.
> 
> All kernels share this SLOT syntax, it is implemented in the eclass.

Sure. Which is good! ;-)

> 
> This is for the eclass maintainers to decide, but they will likely
> depend their decision on what all the eclass users think about that;
> the other option is moving it to the ebuild but that approach leads to
> inconsistency which is probably not a good idea.

full ack!

So how about just add a new SLOTs for every stable long term kernel release 
series like "3.4" and leaving current SLOTs as they are?

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 5553 bytes --]

On Wed, 27 Feb 2013 16:39:22 +0100
Marc Schiffbauer <mschiff@gentoo.org> wrote:

> Am Mittwoch, 27. Februar 2013, 13:49:52 schrieb Tom Wijsman:
> > On Wed, 27 Feb 2013 13:07:38 +0100
> > 
> > Marc Schiffbauer <mschiff@gentoo.org> wrote:
> > > Am Dienstag, 26. Februar 2013, 19:13:18 schrieb Tom Wijsman:
> > > > On Tue, 26 Feb 2013 18:37:16 +0100 (CET)
> > > > 
> > > > As an easy way to keep a single kernel version from being
> > > > unmerged by a kernel upgrade in Portage, I think.
> > > > 
> > > >     emerge gentoo-sources:3.7.9
> > > 
> > > But why would you want that? I think normally its more likely
> > > that a user wants to stick to the seriens (e.g. :3.7) so that
> > > he/she receives security updates as well as minor fixes.
> > 
> > Because when sources unmerge, nothing can build against them and you
> > also can't do a quick recompile if you do not want to do an upgrade.
> 
> Indeed. But I thought of it only as a backup so that you can boot
> your system in case a newer kernel won't.
> 
> Why would you want to continue to use an outdated/insecure kernel
> *from the same series* like 3.7*?

No time yet to recompile a new kernel, a temporarily broken newer kernel
(eg. nvidia-drivers doesn't work with it yet), and so on... Just one
version off doesn't make that much of a difference in date and security.

> > The majority of users doesn't upgrade on every single release, it is
> > better to support them in their upgrade schedule instead of forcing
> > them to upgrade or use more complex approaches to do what they want.
> 
> Where would be the force? Uninstall of old sources would happen while
> they are upgrading.

It doesn't copy the sources, rebuild and install the kernel though.

> I guess you are referring to a use case where user just upgrade
> packages but would not like to restart the system. This is indeed a
> use case for exact version slots.

More is needed than to just restart their system, see my previous
sentence.

> Maybe both things yould coexist? Why not have both kinds of SLOTs
> then?

Hmm, subslots definitely sound interesting to use; only needs to
figure out if that fits the case and whether users will understand them.

> > > If you really wanted to stick to a particular version you can
> > > always mask any version greater than that similar to what you
> > > wrote yourself below:
> > > 
> > > echo ">=sys-kernel/gentoo-sources-3.7"
> > > >> /etc/portage/package.mask
> > 
> > Doing this once per branch or for each version is a big difference.
> 
> Indeed. The above mask would allow all 3.6* kernels rigtht?

Assuming the version syntax doesn't get an extension that would
undermine the version number, that masks everything in 3.7 and newer.

> > 
> > > First, if you remove any gentoo-sources package it will never
> > > remove the kernel or modules that have been built from it. So you
> > > will always keep the kernel that may be important if a newer one
> > > has problems for example. Regardless of removing the sources or
> > > not.
> > 
> > As stated above, that doesn't allow you to reproduce them quickly.
> 
> That was not my intention. Please see above.

But it can be the intention of other users.

> > 
> > For small packages, it doesn't really matter how you do it; but
> > setting up the kernel (copy config, make oldconfig) and compiling it
> > make explicit (un)masking much more annoying than just keeping
> > multiple versions within a branch around.
> 
> Sorry I do not get it. What is your point here? Getting minor kernel
> updates automatically without having to fiddle with masks/unmaks each
> time is the goal here IMO.

I'm not sure which part you didn't get, but be aware that the
suggested SLOT approach does not keep multiple versions within a branch
around; which forces the user to upgrade and therefore requires the
user to do all that I said.

Kernels release way too often for that, and it is not guaranteed that
newer versions work so users will have to try them first; if one breaks
for them, the new SLOT approach would have removed their old sources
and therefore they would have to start all over with them if they have
the need to rebuild their kernel or compile something against them.

There is more than a single goal when talking about changing the SLOT
syntax, especially for a bigger package like the kernel; users use it
differently, yielding different reasons for different approaches to
specify which version are selected and which versions are masked.

Changing the SLOT syntax makes you need to consider what else changes,
because it's not really worth pulling off something for a few users
when it breaks the work flow for the majority of users. And note, we're
pitting of only two or three use cases here, there are possibly more of
them; I would love to see some regulars join the discussion.
 
> So how about just add a new SLOTs for every stable long term kernel
> release series like "3.4" and leaving current SLOTs as they are?

Hmm, since stable kernel releases break less often, this might be
reasonable. This introduces some inconsistency though, although that
could be abused to make it clear to users that they are LTS series.

I'll try to hear, I need to bug them about 3.4.3x stabilization too.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] Which Kernel?

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 5859 bytes --]

Am Mittwoch, 27. Februar 2013, 17:24:39 schrieb Tom Wijsman:
> On Wed, 27 Feb 2013 16:39:22 +0100 Marc Schiffbauer <mschiff@gentoo.org> 
wrote:
> > Why would you want to continue to use an outdated/insecure kernel
> > *from the same series* like 3.7*?
> 
> No time yet to recompile a new kernel, a temporarily broken newer kernel
> (eg. nvidia-drivers doesn't work with it yet), and so on... Just one
> version off doesn't make that much of a difference in date and security.

I agree with that. But in case of nvidia-drivers: I use them myself and never 
saw a case where a minor version upgrade (e.g. 3.7.x -> 3.7.y) was a problem 
here. Upgrading from 3.x to 3.y sure is often a problem for some time.

> 
> > > The majority of users doesn't upgrade on every single release, it is
> > > better to support them in their upgrade schedule instead of forcing
> > > them to upgrade or use more complex approaches to do what they want.
> > 
> > Where would be the force? Uninstall of old sources would happen while
> > they are upgrading.
> 
> It doesn't copy the sources, rebuild and install the kernel though.

Ok. It heavily depends on how one upgrades and gets things done. I for example 
would love to see older releases wihtin the same series disappear on its own 
so I would not have to unmerge them manually.

Tools like eclean-kernel are a great help here of course...

> 
> > I guess you are referring to a use case where user just upgrade
> > packages but would not like to restart the system. This is indeed a
> > use case for exact version slots.
> 
> More is needed than to just restart their system, see my previous
> sentence.

Maybe genkernel could be extended so that it will do minor kernel upgrades 
semi-automatically.

The ebuild might emmit an ewarn like "Please run 'genkernel update'" to build 
updated kernel.

It then would do things like:

* get current kernel from "eselect kernel"
* copy .config to new kernel (newest minor version)
* set new kernel active using "eselect kernel"
* run "make oldconfig"
* run "genkernel all" if modules are enabled or "genkernel bzImage initramfs" 
if not
* run "module-rebuild rebuild"

Only a suggestion. I am aware that not everyone is using genkernel though...


> 
> > Maybe both things yould coexist? Why not have both kinds of SLOTs
> > then?
> 
> Hmm, subslots definitely sound interesting to use; only needs to
> figure out if that fits the case and whether users will understand them.

Sounds interesting.

So you mean something like SLOT="3.7/5" for linux 3.7.5 ?

nvidia-drivers for example could then depend on "gentoo-sources-3.7*:=" if 
that is supported by subslot dependencies.

But that may cause a rebuild of nvidia-drivers before "eselect kernel" has 
been called to point to the new kernel. Maybe that step could be automated 
then if configured somewhere, maybe through a USE flag?


> > > For small packages, it doesn't really matter how you do it; but
> > > setting up the kernel (copy config, make oldconfig) and compiling it
> > > make explicit (un)masking much more annoying than just keeping
> > > multiple versions within a branch around.
> > 
> > Sorry I do not get it. What is your point here? Getting minor kernel
> > updates automatically without having to fiddle with masks/unmaks each
> > time is the goal here IMO.
> 
> I'm not sure which part you didn't get, but be aware that the
> suggested SLOT approach does not keep multiple versions within a branch
> around; which forces the user to upgrade and therefore requires the
> user to do all that I said.

I was not sure if you were suggesting to use more masking/unmasking and 
whether you find that more complex or easier do manage. Nevermind...

Yes it would remove older releases. I got that part.
But when would that be a real problem?
AFAICS only if you install/update packages *after* the kernelsource update and 
*before* kernel rebuild.
Deferring a source update (and removing previous source) to the end of an 
emerge run might help a bit here.

But anyhow we are talking about subslots already which migth be a way better 
solution so we might not deepen that part any further... ;)

> Kernels release way too often for that, and it is not guaranteed that
> newer versions work so users will have to try them first; 

Is that really true for minor updates like 3.7.x -> 3.7.y ?

> if one breaks
> for them, the new SLOT approach would have removed their old sources
> and therefore they would have to start all over with them if they have
> the need to rebuild their kernel or compile something against them.

Ack. But thats the case mainly for feature updates (3.7 -> 3.8)

> There is more than a single goal when talking about changing the SLOT
> syntax, especially for a bigger package like the kernel; users use it
> differently, yielding different reasons for different approaches to
> specify which version are selected and which versions are masked.
> 
> Changing the SLOT syntax makes you need to consider what else changes,
> because it's not really worth pulling off something for a few users
> when it breaks the work flow for the majority of users. 

full ack!

> And note, we're
> pitting of only two or three use cases here, there are possibly more of
> them; I would love to see some regulars join the discussion.
> 
> > So how about just add a new SLOTs for every stable long term kernel
> > release series like "3.4" and leaving current SLOTs as they are?
> 
> Hmm, since stable kernel releases break less often, this might be
> reasonable. This introduces some inconsistency though, although that
> could be abused to make it clear to users that they are LTS series.

Do you remeber any major breakage in a point release?

> 
> I'll try to hear, I need to bug them about 3.4.3x stabilization too.

+1


Cheers
-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[gentoo-kernel] Re: Which Kernel?

[Gino!]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks for the response..

I think I will go with 3.4 release and stay there for a while.

Gino

On 02/25/2013 06:51 AM, Tom Wijsman wrote:
> On Mon, 25 Feb 2013 01:05:01 -0500
> "Gino!" <ginolovesyou@gmail.com> wrote:
> 
>> So, it seems like gentoo-sources loves EOL kernels..
> 
> Well, if they EOL both 3.5 and 3.6 there isn't much we can do
> about that. Although, since we're now with at least two we try to
> provide everything in 3.x. So the only thing we don't do for the moment
> is the 2.x kernels, there is one in the vanilla sources if needed.
> 
>> I always move up to the latest amd64 stable, but 3.7.9 is
>> super buggy (nvidia and aufs3 complain among others)
> 
> The problem here is those external drivers are not following along the
> kernel changes in a timely matter, not the other way around. If needed,
> you can find patches for them by now; there is even a patch to run
> NVIDIA on 3.8, it's just that NVIDIA takes their time to apply them.
> 
>> so I'm staying at 3.6.11... although I would feel allot more
>> comfortable with something like 3.4.33!! but its at 3.4.9...
> 
> What's wrong with 3.6.11 then?
> 
> And yes, I'll try to check up with mpagano if it is possible to
> stabilize one or two kernels from those gaps.
> 
>> Do you gentoo-sources folks recommend a particular release for Long
>> Term Stable ongoing support??? Thats the one i want to use.
> 
> You've named them, if you want to go for "stable" versions you can take
> your pick between 3.4.9, 3.5.7, 3.6.11 or 3.7.9. I assume you will want
> to avoid the EOL kernels, so you might end up deciding between 3.4.9
> (where we might stabilize ~3.4.33) or 3.7.9 (for which NVIDIA and
> other external drivers will eventually work, you can patch them).
> 
> 
> With kind regards,
> 
> Tom Wijsman (TomWij)
> Gentoo Developer
> 
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEroqQACgkQ4qXYIPju5+LN/gD+L0H61ORPGVqh4guDPzVdlc4+
6U/wmLqg8EyueiL4HWMA/1tk5DT4j2/rHyxcbyB6ICrzrnLOhXfnwGqL5EpM9XY1
=Mctc
-----END PGP SIGNATURE-----

Re: [gentoo-kernel] Which Kernel?

[Greg KH]

On Mon, Feb 25, 2013 at 01:05:01AM -0500, Gino! wrote:
> So, it seems like gentoo-sources loves EOL kernels..
> can anybody tell me why this is, it seems like that would be a bad thing...
> I always move up to the latest amd64 stable, but 3.7.9 is super buggy
> (nvidia and aufs3 complain among others)

What is "super buggy" about 3.7.9?  Have you reported this anywhere?

Also, 3.7.y upstream is about to go end-of-life, so you really should
move to 3.8 soon.

> so I'm staying at 3.6.11...

Why that one?  It's been end-of-life for a while now, with known
security issues...

> although I would feel allot more comfortable with something like
> 3.4.33!! but its at 3.4.9...
> 
> Do you gentoo-sources folks recommend a particular release for Long Term
> Stable ongoing support???

If you have to have something like this, then use the versions that
upstream is saying is going to be "long term", meaning the 3.0 or 3.4
releases.  But note that new hardware will not work on these releases,
so you will be out of luck if you have really modern hardware, sorry.

> Thats the one i want to use.

Why?  What does something like this buy you in a rolling-release distro
like Gentoo?

thanks,

greg k-h

[gentoo-kernel] Re: Which Kernel?

[Gino!]

Firstly thanks for all your great responses...

On 02/25/2013 09:26 AM, Greg KH wrote:
> On Mon, Feb 25, 2013 at 01:05:01AM -0500, Gino! wrote:
>> So, it seems like gentoo-sources loves EOL kernels..
>> can anybody tell me why this is, it seems like that would be a bad thing...
>> I always move up to the latest amd64 stable, but 3.7.9 is super buggy
>> (nvidia and aufs3 complain among others)
> 
> What is "super buggy" about 3.7.9?  Have you reported this anywhere?
> 
I as a stable packages only, style gentoo user have an (perhaps
unrealistic), expectation that kernels that go stable have some vetting
process with all other stable packages, and I can expect no failed
interactions between things.. this is not yet true with 3.7.9...

> Also, 3.7.y upstream is about to go end-of-life, so you really should
> move to 3.8 soon.
> 
>> so I'm staying at 3.6.11...
> 
> Why that one?  It's been end-of-life for a while now, with known
> security issues...
> 

I just happen to be here at the moment, I will probably roll back to
3.4.9, my computer is fairly new but not bleeding edge..

>> although I would feel allot more comfortable with something like
>> 3.4.33!! but its at 3.4.9...
>>
>> Do you gentoo-sources folks recommend a particular release for Long Term
>> Stable ongoing support???
> 
> If you have to have something like this, then use the versions that
> upstream is saying is going to be "long term", meaning the 3.0 or 3.4
> releases.  But note that new hardware will not work on these releases,
> so you will be out of luck if you have really modern hardware, sorry.
> 
>> Thats the one i want to use.
> 
> Why?  What does something like this buy you in a rolling-release distro
> like Gentoo?
I would prefer to not constantly use new kernel implementations,
sometimes new features come out, and I may need some old package, that
depends on the older feature.. I would like for it to operate smoothly..
my most recent example of this would be changes to how wireless drivers
are implemented,
the new stuff is great but if my old packages don't work, its no good
for me.
I would like an (*slightly) older kernel that maintains security patches
and maintenance repairs for a long period of time..

I don't feel I *need any new features, what I got is great feature wise
:).. just keep it repaired and tidy! thats what I look for in a kernel.
does that answer your question?
> 
> thanks,
> 
> greg k-h
> 
> 

TA.

Gino

Re: [gentoo-kernel] Re: Which Kernel?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]

On Mon, 25 Feb 2013 12:27:21 -0500
"Gino!" <ginolovesyou@gmail.com> wrote:

> Firstly thanks for all your great responses...
> 
> On 02/25/2013 09:26 AM, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 01:05:01AM -0500, Gino! wrote:
> >> So, it seems like gentoo-sources loves EOL kernels..
> >> can anybody tell me why this is, it seems like that would be a bad
> >> thing... I always move up to the latest amd64 stable, but 3.7.9 is
> >> super buggy (nvidia and aufs3 complain among others)
> > 
> > What is "super buggy" about 3.7.9?  Have you reported this anywhere?
> > 
> I as a stable packages only, style gentoo user have an (perhaps
> unrealistic), expectation that kernels that go stable have some
> vetting process with all other stable packages, and I can expect no
> failed interactions between things.. this is not yet true with
> 3.7.9...

This makes the stabilization process unnecessary long; again, it's the
responsibility of other packages to work with the kernel, not the other
way around. We have waited long enough (several 3.7 versions) for those
packages to be patched; and besides that we had to wait for nouveau to
somewhat become more reliable as well, since they did a major refactor
in early 3.7 that broke it for some people.

Stabilizing more kernel versions but making sure they work together with
other packages is impossible with the limited kernel team we currently
have, remember that this has been just mpagano for a while [1] and that
out of everyone that responded [2] nobody else really stayed around.

 [1]: http://www.mpagano.com/blog/?p=165
 [2]: http://www.mpagano.com/blog/?p=167

> >> although I would feel allot more comfortable with something like
> >> 3.4.33!! but its at 3.4.9...
> >>
> >> Do you gentoo-sources folks recommend a particular release for
> >> Long Term Stable ongoing support???
> > 
> > If you have to have something like this, then use the versions that
> > upstream is saying is going to be "long term", meaning the 3.0 or
> > 3.4 releases.  But note that new hardware will not work on these
> > releases, so you will be out of luck if you have really modern
> > hardware, sorry.
> > 
> >> Thats the one i want to use.
> > 
> > Why?  What does something like this buy you in a rolling-release
> > distro like Gentoo?
> I would prefer to not constantly use new kernel implementations,
> sometimes new features come out, and I may need some old package, that
> depends on the older feature.. I would like for it to operate
> smoothly.. my most recent example of this would be changes to how
> wireless drivers are implemented,
> the new stuff is great but if my old packages don't work, its no good
> for me.
> I would like an (*slightly) older kernel that maintains security
> patches and maintenance repairs for a long period of time..

Then following 3.4 is the way to go, I'll hear for stabilization...


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] Re: Which Kernel?

[Thierry]

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]

Hi,

I do not understand why linux-headers package is behind the kernel 
release (at the time of writing, the latest unstable is 3.7, while 3.8 
is out for some time. Is it manage by another team? Should it be managed 
by the kernel team to ensure that releases are in line?

Thanks

Thierry

On 02/25/13 19:00, Tom Wijsman wrote:
> On Mon, 25 Feb 2013 12:27:21 -0500
> "Gino!" <ginolovesyou@gmail.com> wrote:
>
>> Firstly thanks for all your great responses...
>>
>> On 02/25/2013 09:26 AM, Greg KH wrote:
>>> On Mon, Feb 25, 2013 at 01:05:01AM -0500, Gino! wrote:
>>>> So, it seems like gentoo-sources loves EOL kernels..
>>>> can anybody tell me why this is, it seems like that would be a bad
>>>> thing... I always move up to the latest amd64 stable, but 3.7.9 is
>>>> super buggy (nvidia and aufs3 complain among others)
>>> What is "super buggy" about 3.7.9?  Have you reported this anywhere?
>>>
>> I as a stable packages only, style gentoo user have an (perhaps
>> unrealistic), expectation that kernels that go stable have some
>> vetting process with all other stable packages, and I can expect no
>> failed interactions between things.. this is not yet true with
>> 3.7.9...
> This makes the stabilization process unnecessary long; again, it's the
> responsibility of other packages to work with the kernel, not the other
> way around. We have waited long enough (several 3.7 versions) for those
> packages to be patched; and besides that we had to wait for nouveau to
> somewhat become more reliable as well, since they did a major refactor
> in early 3.7 that broke it for some people.
>
> Stabilizing more kernel versions but making sure they work together with
> other packages is impossible with the limited kernel team we currently
> have, remember that this has been just mpagano for a while [1] and that
> out of everyone that responded [2] nobody else really stayed around.
>
>   [1]: http://www.mpagano.com/blog/?p=165
>   [2]: http://www.mpagano.com/blog/?p=167
>
>>>> although I would feel allot more comfortable with something like
>>>> 3.4.33!! but its at 3.4.9...
>>>>
>>>> Do you gentoo-sources folks recommend a particular release for
>>>> Long Term Stable ongoing support???
>>> If you have to have something like this, then use the versions that
>>> upstream is saying is going to be "long term", meaning the 3.0 or
>>> 3.4 releases.  But note that new hardware will not work on these
>>> releases, so you will be out of luck if you have really modern
>>> hardware, sorry.
>>>
>>>> Thats the one i want to use.
>>> Why?  What does something like this buy you in a rolling-release
>>> distro like Gentoo?
>> I would prefer to not constantly use new kernel implementations,
>> sometimes new features come out, and I may need some old package, that
>> depends on the older feature.. I would like for it to operate
>> smoothly.. my most recent example of this would be changes to how
>> wireless drivers are implemented,
>> the new stuff is great but if my old packages don't work, its no good
>> for me.
>> I would like an (*slightly) older kernel that maintains security
>> patches and maintenance repairs for a long period of time..
> Then following 3.4 is the way to go, I'll hear for stabilization...
>
>
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


[-- Attachment #2: Type: text/html, Size: 4779 bytes --]

Re: [gentoo-kernel] Re: Which Kernel?

[Greg KH]

On Tue, Feb 26, 2013 at 08:01:52AM +0100, Thierry wrote:
> Hi,
> 
> I do not understand why linux-headers package is behind the kernel release (at
> the time of writing, the latest unstable is 3.7, while 3.8 is out for some
> time. Is it manage by another team? Should it be managed by the kernel team to
> ensure that releases are in line?

linux-headers has nothing to do with the kernel that is running on the
system, that is why it is separate and managed by a different group of
people.

Hope this helps,

greg k-h

Re: [gentoo-kernel] Re: Which Kernel?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Tue, 26 Feb 2013 08:01:52 +0100
Thierry <thierry@de-leeuw.org> wrote:

> Hi,
> 
> I do not understand why linux-headers package is behind the kernel 
> release (at the time of writing, the latest unstable is 3.7, while
> 3.8 is out for some time. Is it manage by another team? Should it be
> managed by the kernel team to ensure that releases are in line?
> 

 $ equery m sys-kernel/linux-headers
 * sys-kernel/linux-headers [gentoo]
Herd:        toolchain (toolchain@gentoo.org)

Indeed, a different herd maintains it. But that isn't necessarily the
cause of the delay, you also have to take the stabilization process
into account.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-kernel] Re: Which Kernel?

[Gino!]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/25/2013 01:00 PM, Tom Wijsman wrote:
> On Mon, 25 Feb 2013 12:27:21 -0500
> "Gino!" <ginolovesyou@gmail.com> wrote:
> 
>> Firstly thanks for all your great responses...
>>
>> On 02/25/2013 09:26 AM, Greg KH wrote:
>>> On Mon, Feb 25, 2013 at 01:05:01AM -0500, Gino! wrote:
>>>> So, it seems like gentoo-sources loves EOL kernels..
>>>> can anybody tell me why this is, it seems like that would be a bad
>>>> thing... I always move up to the latest amd64 stable, but 3.7.9 is
>>>> super buggy (nvidia and aufs3 complain among others)
>>>
>>> What is "super buggy" about 3.7.9?  Have you reported this anywhere?
>>>
>> I as a stable packages only, style gentoo user have an (perhaps
>> unrealistic), expectation that kernels that go stable have some
>> vetting process with all other stable packages, and I can expect no
>> failed interactions between things.. this is not yet true with
>> 3.7.9...
> 
> This makes the stabilization process unnecessary long; again, it's the
> responsibility of other packages to work with the kernel, not the other
> way around. We have waited long enough (several 3.7 versions) for those
> packages to be patched; and besides that we had to wait for nouveau to
> somewhat become more reliable as well, since they did a major refactor
> in early 3.7 that broke it for some people.
> 
> Stabilizing more kernel versions but making sure they work together with
> other packages is impossible with the limited kernel team we currently
> have, remember that this has been just mpagano for a while [1] and that
> out of everyone that responded [2] nobody else really stayed around.
> 
>  [1]: http://www.mpagano.com/blog/?p=165
>  [2]: http://www.mpagano.com/blog/?p=167
> 
>>>> although I would feel allot more comfortable with something like
>>>> 3.4.33!! but its at 3.4.9...
>>>>
>>>> Do you gentoo-sources folks recommend a particular release for
>>>> Long Term Stable ongoing support???
>>>
>>> If you have to have something like this, then use the versions that
>>> upstream is saying is going to be "long term", meaning the 3.0 or
>>> 3.4 releases.  But note that new hardware will not work on these
>>> releases, so you will be out of luck if you have really modern
>>> hardware, sorry.
>>>
>>>> Thats the one i want to use.
>>>
>>> Why?  What does something like this buy you in a rolling-release
>>> distro like Gentoo?
>> I would prefer to not constantly use new kernel implementations,
>> sometimes new features come out, and I may need some old package, that
>> depends on the older feature.. I would like for it to operate
>> smoothly.. my most recent example of this would be changes to how
>> wireless drivers are implemented,
>> the new stuff is great but if my old packages don't work, its no good
>> for me.
>> I would like an (*slightly) older kernel that maintains security
>> patches and maintenance repairs for a long period of time..
> 
> Then following 3.4 is the way to go, I'll hear for stabilization...
> 
Thanks so much,

Yeah if you think its wise, more rapid stabilization on minor patches
here would be a great incentive to stay with the 3.4 series..

Gino
> 
> With kind regards,
> 
> Tom Wijsman (TomWij)
> Gentoo Developer
> 
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEtCL0ACgkQ4qXYIPju5+LHeQD/QIUFCGvYgzi9/uxdHvYG1b3J
y73Pa040ZtvLf7SsCbMA/0Ejh3oJFk8kObip0YIyX3jORse9of7kbQZ0GWqN7ok5
=u+0E
-----END PGP SIGNATURE-----