Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Never seen a distro deliver updates this fast.
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Jojobinha_2009
Tux's lil' helper
Tux's lil' helper


Joined: 27 Mar 2021
Posts: 77
Location: Brazil

PostPosted: Wed Apr 07, 2021 10:08 pm    Post subject: Never seen a distro deliver updates this fast. Reply with quote

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!
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Thu Apr 08, 2021 3:30 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Thu Apr 08, 2021 3:58 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Thu Apr 08, 2021 4:08 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Thu Apr 08, 2021 4:25 pm    Post subject: Reply with quote

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

Code:
$ eshowkw gentoo-sources
Keywords for sys-kernel/gentoo-sources:
              |                             |   u           | 
              | a   a     p s   a   r       |   n           | 
              | m   r h   p p   l i i m m s | e u s         | r
              | d a m p p c a x p a s 6 i 3 | a s l         | e
              | 6 r 6 p p 6 r 8 h 6 c 8 p 9 | p e o         | p
              | 4 m 4 a c 4 c 6 a 4 v k s 0 | i d t         | o
--------------+-----------------------------+---------------+-------
   4.4.257    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.4.257   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.261    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.261   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.262    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.262   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.263    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.263   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.264    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.4.264   | gentoo
--------------+-----------------------------+---------------+-------
   4.4.265    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.4.265   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.257    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.9.257   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.261    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.261   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.262    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.262   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.263    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.263   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.264    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.9.264   | gentoo
--------------+-----------------------------+---------------+-------
   4.9.265    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.9.265   | gentoo
--------------+-----------------------------+---------------+-------
  4.14.221    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.14.221  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.225    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.225  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.226    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.226  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.227    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.227  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.228    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.14.228  | gentoo
--------------+-----------------------------+---------------+-------
  4.14.229    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.14.229  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.175    | + + ~ ~ + + + + ~ ~ o o ~ ~ | 6 o 4.19.175  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.181    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.181  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.182    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.182  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.183    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.183  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.184    | + + ~ ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 4.19.184  | gentoo
--------------+-----------------------------+---------------+-------
  4.19.185    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 4.19.185  | gentoo
--------------+-----------------------------+---------------+-------
    5.4.97    | + + + ~ + + + + ~ ~ o o ~ ~ | 6 o 5.4.97    | gentoo
--------------+-----------------------------+---------------+-------
   5.4.105    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.105   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.106    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.106   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.107    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.107   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.108    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.108   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.109    | + + + ~ ~ ~ + + ~ ~ o o ~ ~ | 6 o 5.4.109   | gentoo
--------------+-----------------------------+---------------+-------
   5.4.110    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ | 6 o 5.4.110   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.24    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.24   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.25    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.25   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.26    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.26   | gentoo
--------------+-----------------------------+---------------+-------
   5.10.27    | + + + ~ ~ ~ + + ~ ~ ~ o ~ ~ | 6 o 5.10.27   | gentoo
--------------+-----------------------------+---------------+-------
[I]5.10.28    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.10.28   | gentoo
--------------+-----------------------------+---------------+-------
    5.11.6    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.6    | gentoo
--------------+-----------------------------+---------------+-------
    5.11.7    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.7    | gentoo
--------------+-----------------------------+---------------+-------
    5.11.8-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.8-r1 | gentoo
--------------+-----------------------------+---------------+-------
    5.11.9    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.9    | gentoo
--------------+-----------------------------+---------------+-------
   5.11.10    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.10   | gentoo
--------------+-----------------------------+---------------+-------
   5.11.11    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.11   | gentoo
--------------+-----------------------------+---------------+-------
   5.11.12    | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o ~ ~ | 6 o 5.11.12   | gentoo
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Thu Apr 08, 2021 4:26 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2702

PostPosted: Thu Apr 08, 2021 10:50 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Thu Apr 08, 2021 11:12 pm    Post subject: Reply with quote

Ok good...sigh still need to update again...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
figueroa
Advocate
Advocate


Joined: 14 Aug 2005
Posts: 2912
Location: Edge of marsh USA

PostPosted: Fri Apr 09, 2021 4:04 am    Post subject: Reply with quote

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:
Code:
>=sys-kernel/gentoo-sources-5.5

I always upgrade pretty quickly to new stable point releases.

On my #2 machine that only does server duties as well as a remote server, I'm still at 4.9 and it meets all my needs. I won't change either of those till obsolescence draws closer in late 2022. Everything works great and I don't need any grief. They would still be on 4.4 except that I got itchy feet back when Spectre and Meltdown became new things. The LAST think I need to do is be on the bleeding edge of new kernels.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/17.1/desktop (stable), OpenRC, -systemd -pulseaudio -uefi
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 555
Location: Ásgarðr

PostPosted: Fri Apr 09, 2021 7:35 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Goverp
Veteran
Veteran


Joined: 07 Mar 2007
Posts: 1972

PostPosted: Fri Apr 09, 2021 8:15 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
sdauth
Guru
Guru


Joined: 19 Sep 2018
Posts: 555
Location: Ásgarðr

PostPosted: Fri Apr 09, 2021 8:46 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Fri Apr 09, 2021 9:51 am    Post subject: Reply with quote

figueroa wrote:
[...]I have the following in /etc/portage/package.mask:
Code:
>=sys-kernel/gentoo-sources-5.5

I highly recommend to add this also:
Code:
>=sys-kernel/linux-headers-5.5
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2702

PostPosted: Fri Apr 09, 2021 9:59 am    Post subject: Reply with quote

pietinger wrote:
figueroa wrote:
[...]I have the following in /etc/portage/package.mask:
Code:
>=sys-kernel/gentoo-sources-5.5

I highly recommend to add this also:
Code:
>=sys-kernel/linux-headers-5.5
Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

Plus there's some packages that won't build with old headers like pax-utils-1.2.9 needs >=5.8
Edit: and pax-utils' requirement was needed for a glibc-2.33 fix, not an issue right now if still using 2.32 but eventually it'll come bite when stable
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Fri Apr 09, 2021 12:08 pm    Post subject: Reply with quote

Ionen wrote:
Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

Really ? I cant believe.

You know what happens if you compile a programm against a header-file telling there is a new abi in the kernel ... and the kernel itself doesnt have it ... ?!
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2702

PostPosted: Fri Apr 09, 2021 1:08 pm    Post subject: Reply with quote

pietinger wrote:
Ionen wrote:
Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.
Really ? I cant believe.
https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F
Back to top
View user's profile Send private message
figueroa
Advocate
Advocate


Joined: 14 Aug 2005
Posts: 2912
Location: Edge of marsh USA

PostPosted: Fri Apr 09, 2021 2:34 pm    Post subject: Reply with quote

Goverp wrote:
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!

Not every point releases comes into the stable tree. That's been making stable kernel maintenance more like a monthly activity, more or less. I'm happy with that pace of activity.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/17.1/desktop (stable), OpenRC, -systemd -pulseaudio -uefi
Back to top
View user's profile Send private message
timeBandit
Bodhisattva
Bodhisattva


Joined: 31 Dec 2004
Posts: 2719
Location: here, there or in transit

PostPosted: Fri Apr 09, 2021 2:56 pm    Post subject: Reply with quote

pietinger wrote:
You know what happens if you compile a programm against a header-file telling there is a new abi in the kernel ... and the kernel itself doesnt have it ... ?!
Absolutely nothing, unless said program actually calls the new ABI. Code written to the pre-existing interface would not notice any additions. I could amend my kernel headers with last week's grocery list expressed as a series of function prototypes*, rebuild my entire system, and nothing untoward would happen--because no code on my system orders groceries. ;)

*Grocery-purchasing API specification is left as an exercise for the reader. Grocery list provided on request. :)
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Fri Apr 09, 2021 6:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Goverp
Veteran
Veteran


Joined: 07 Mar 2007
Posts: 1972

PostPosted: Fri Apr 09, 2021 9:00 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2702

PostPosted: Fri Apr 09, 2021 11:47 pm    Post subject: Reply with quote

Hu wrote:
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.
If "really" wanted to, removing that support would involve using --enable-kernel= on glibc, in case of glibc-2.33 it has code specific to kernels up to 5.8.0 on amd64 (5.4.0 for 2.32), if you wanted to strip all the old cruft it'd be --enable-kernel=5.8.0 and then "now" it wouldn't run on old kernels -- not that this is really worthwhile.

By default it still uses =3.2.0, so even if you use linux-headers-5.11 it should run on a 3.2.0 kernel. So it's a pretty wide range of old kernels even if wanted to chroot using an ancient minimal cd with a old kernel.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Tue Mar 07, 2023 9:58 am    Post subject: Reply with quote

Ionen wrote:
Why, I mean glibc upstream recommends to use latest headers regardless of running kernel.

I had read this recommendation, but I had in my mind that it is wrong to use newer linux headers than your used kernel version. But I was not able to remember why I had this in my mind. By accident I found today the source:
Quote:
Kernel headers are backwards compatible, but not forwards compatible. This means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel.

https://www.kernel.org/doc/html/latest/kbuild/headers_install.html

So, we have two contradictory recommendations ?
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Tue Mar 07, 2023 11:59 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Tue Mar 07, 2023 1:00 pm    Post subject: Reply with quote

Hu,
thank you very much for this detailed explanation. :D
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3996
Location: Bavaria

PostPosted: Sun Mar 12, 2023 7:47 am    Post subject: Reply with quote

I thought about:

Hu wrote:
[...] 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.

... and how Gentoo is handling linux-headers: If you emerge stable gentoo-sources (6.1 at the moment) you will get (automatically) linux-headers 6.1 ... and not 6.3 (newest at the moment).

So, is it correct if I recommend to not use the newest linux-headers ... or does Gentoo handles linux-headers wrong ?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum