Never seen a distro deliver updates this fast.

[Jojobinha_2009]

I mean it's even faster than Arch!
The 5.11.12 kernel was released literally 9 hours ago...

Went to do my usual emerge update and bam!

5.11.12 is here up and running already!


Love this distro!
_________________
Intel Core i5-9400F / 24GB DDR4 2666MHz / GeForce GTX 1060 3GB

Powered by Gentoo for x86_64

======================================================

Seize the day, and remember to have fun!

[eccerr0r]

Okay, this is getting ridiculous, got 5.4 -> 5.10 -> 5.11 stabilized in a matter of weeks... this isn't "stable" ...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[NeddySeagoon]

eccerr0r,

5.4 and 5.10 are LTS kernels. 5.11 is not.
That looks a bit odd.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[eccerr0r]

I guess I'm assuming that it really got stabilized, I didn't check... but the 5.4 -> 5.10 transition did happen fairly recently, and if 5.11 did as well, that's just weird.

(I had been running 4.14.* ... and *just* updated to 5.4 on all my boxes... more electricity to burn... )
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[asturm]

5.11 is not stable. 5.4 was stable for a *long* time.

[Hu]

If I recall correctly, Gentoo marks LTS kernels as stable, and non-LTS kernels as testing. Whether any of those series are stable enough is a function of upstream's project management. In theory, both 5.4 and 5.10 should be stable, because they are built on their respective Linus releases, with appropriate backports from later kernels. If you're happy with the 5.4 line's hardware support and software features, you can stay in that line for as long as upstream releases LTS kernels for it.

[Ionen]

Gentoo does their own testing as well and won't stabilize a kernel if there's known issues that may impact a lot of users (5.10.x notably waited a while because of an intel gpu issue I recall), nor would it ever get stabilized without (at least) the usual 30-days period unless a major issue was found in stable and there's an urgency.

And as already stated, 5.11 is not stabilized. Note that even on ~testing you can use some stable packages (like the kernel) by using '-~amd64' in package.accept_keywords if preferred.

[eccerr0r]

Ok good...sigh still need to update again...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[figueroa]

I only recently upgraded to the 5.4 kernel series, for LTS reasons. I was on 4.4 and 4.9 both for a long time and now plan to stay with 5.4 on my main system for at least a couple of years. I have the following in /etc/portage/package.mask:

[sdauth]

I'm doing the same as figueroa.
Masking all sys-kernel/gentoo-sources :
echo "sys-kernel/gentoo-sources" >> /etc/portage/package.mask
and only unmask the kernel series I want, and nothing else :
echo "=sys-kernel/gentoo-sources-5.4*" >> /etc/portage/package.unmask

From what I read, 5.4 LTS is going to last longer than 5.10 LTS so I'm sticking with 5.4. Of course pure stable because I don't want to build a new kernel every week.

Back with the thread, yeah some packages are fast to receive updates (even on "stable" channel) but sometimes when looking at my accept.keywords file I regret the lack of maintainer for some packages. I try to always open a "version bump" bug when some packages are old. I'm not confident enough to do the maintainer job myself.

[Goverp]

IIUC just 'cos it's LTS doesn't mean there won't be fixes (backported from latest and greatest) every week, but they should be relatively painless.
There may be fewer changes, but they still happen. 5.10 has had 28 updates; 5.4, 110, and 4.9 is up to 256!
_________________
Greybeard

[sdauth]

Yes of course. I mean I don't put sys-kernel/gentoo-sources in accept.keywords, I let Gentoo kernel team to stabilize when needed. The default way when you're on stable to sum up.
This way, kernel bump only happens once a month (sometimes more or sometimes less when there is a sec issue or whatever)

[pietinger]

[Ionen]

[pietinger]

[Ionen]

[figueroa]

[timeBandit]

[Hu]

If the code did try to use that new ABI, it would get ENOSYS (for missing system calls) or possibly some other error for missing extensions to existing system calls. It is a bug if the caller (1) works properly with old headers and (2) fails when using new headers with an old kernel. Callers are permitted to depend on new features and simply fail when run on old kernels, but if they can run on an old kernel, then they must run correctly even when made aware of extensions that the running kernel lacks. Typically, glibc handles this transparently by observing that the running kernel lacks the new feature, and falling back to an older system call that can do the job.

[Goverp]

I'd forgotten the slower rate of updates on a stable kernel; my new box needed ~arch a year or so ago. Now it's a case of emerge --update; make oldconfig; make install every week (+ other bits of course); at least the new box is so fast it still takes less time.
_________________
Greybeard

[Ionen]

[pietinger]

[Hu]

The other part of Ionen's post addresses your concern. A user program which uses kernel headers version 1 cannot see kernel features introduced in kernel headers version 2. A user program which uses kernel headers version 2 can see features from both version 1 and version 2, and can choose which to use. A kernel matching the kernel header version 1 interface does not offer version 2 features, and so cannot run a program which requires those features. However, as I said in my post that Ionen quoted, the user program could choose to try version 2 and, if that fails, use version 1 instead of aborting the program. As Ionen's post elaborates, glibc has internal support for exactly this, and the packager can choose how much of that internal support to enable. With the =3.2.0 that Ionen mentions, glibc will include enough fallbacks to try older version features all the way down to what Linux v3.2.0 supported, but presumably can have a hard requirement on v3.2.0 features, and fail outright on v3.1.0. If the package picks a newer --enable-kernel= when building glibc, fewer fallbacks are included, and the resulting glibc binaries can therefore have a hard requirement on a newer kernel, all the way up to the version specified by the packager. Assuming no bugs in the glibc support, this means you can upgrade kernel headers arbitrarily far into the future and, as long as you keep the --enable-kernel= parameter unchanged, you retain support for the older kernels.

Since glibc supports this and is the standard path to make system calls (via libc wrapper functions), most user applications are automatically as compatible as the glibc on which they run. Only special programs that bypass glibc and use kernel headers directly are at risk of having a higher minimum due to a kernel header upgrade.

[pietinger]

Hu,
thank you very much for this detailed explanation.

[pietinger]

I thought about: