You are not logged in.
I understand the pkg maintainers will update when they're ready to and or have time.
The 'linux' package in Core: 'linux 6.13.8.arch1-1'
The 'linux' package in Core-Testing: ' linux 6.14.arch1-1'
The latest stable release from kernel.org: 6.13.9
I'm curious about the jump to 6.14 in testing rather than 6.13.9, 6.13.10, etc...
I thought the versions have been more incremental from official repo to testing repo, but I've only been watching this recently.
Is there or has there been any pattern or relationship between the kernels in these repos?
I also notice the same maintainers of Core and Core-Testing reops linux package.
Is there an issue with the kernels after 6.13.9 that may be preventing an update?
This question comes purely from curiosity as I've recently been dabbling in building and testing kernels.
I don't need 6.13.9 and have already build and test ran a pre-release of it. https://github.com/Cody-Learner/linux-stable-rc
Scripts I Use : https://github.com/Cody-Learner
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 7 8745HS w/ Radeon 780M Graphics
grep -m1 'model name' /proc/cpuinfo : Intel(R) N95
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 5 PRO 2400GE w/ Radeon Vega Graphics
Offline
no point in testing and releasing a minor update when a major update is already being tested
Offline
Is there or has there been any pattern or relationship between the kernels in these repos?
Yes... the one you're observing. Look at the Arch release git history to see the pattern.
When a new upstream kernel major revision is released it almost always is the next [core-testing] version.
Often lately, but not always throughout history, Arch waits for the first minor revision before it moves to [core]. Usually a small set of important fixes, and in this case of 6.14.1 it's tiny.
Is there an issue with the kernels after 6.13.9 that may be preventing an update?
Nope. Been on 6.13.9 since it was released.
Aside:
I'll typically use stable kernels until they EOL, and only then move to the next major revision.
This strategy avoids some possible pain points with potential regressions. The rare exception is when the next major rev contains some fix/feature I want which is not backported to older stable revs.
I will, however, boot into Arch 6.14.2 briefly for regression checks when it hits [core], so as not to remain in the dark for any issue which may be affecting my system.
Offline
I will, however, boot into Arch 6.14.2 briefly for regression checks
As a further aside... 6.14.2 is one of the mega-patch dumps resulting from the next major rev (6.15) merge window.
It's now at FOUR RC's! That's both comforting (someone's testing), and unsettling (contentious, unending opinion topic upstream about what qualifies as "stable" "fixes").
Offline
This has been discussed in #archlinux@Libera recently. The main takeaway is: Arch deployment model uses no branches. There is no option to have a single package to be at 6.14 and 6.13.9 at the same time.
This is not unresolvable. See libreoffice-fresh and libreoffice-still for one idea. But that’s requesting to complicate the release process and make maintenance more expensive. A request that would need a reason way beyond “the numbers don’t match.” Even harder to support with linux-lts present. The delay in deploying critical bugfixes, the original concern of the person asking in #archlinux, hasn’t been properly established as anything more than hypothetical either.
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
This is not unresolvable. See libreoffice-fresh and libreoffice-still for one idea.
That is a completely different situation, more like linux and linux-lts. Not really an option here.
Offline