[arch-general] Why did kernel packaging become slow?
The kernel package (linux) is constantly out of date, both in Testing & Core. Whenever a version is pushed in kernel.org, the previous stable will be still in testing. And then the (old) stable version gets pushed to core, and the next one in testing will be already old (because it's the latest stable). Such as the case right now (Core=4.5.1, testing=4.5.2. Stable on kernel.org=4.5.3) Is there a reason for such delay?
On Sat, May 7, 2016 at 11:15 AM, Abderrahman Najjar wrote:
The kernel package (linux) is constantly out of date, both in Testing & Core.
Whenever a version is pushed in kernel.org, the previous stable will be still in testing. And then the (old) stable version gets pushed to core, and the next one in testing will be already old (because it's the latest stable). Such as the case right now (Core=4.5.1, testing=4.5.2. Stable on kernel.org=4.5.3)
Is there a reason for such delay?
Maybe because stable and even lts kernels in the recent past have repeatedly regressed?
Am Sat, 7 May 2016 09:15:13 +0000 schrieb Abderrahman Najjar <abderrahman.najjar@gmail.com>:
The kernel package (linux) is constantly out of date, both in Testing & Core.
Whenever a version is pushed in kernel.org, the previous stable will be still in testing. And then the (old) stable version gets pushed to core, and the next one in testing will be already old (because it's the latest stable). Such as the case right now (Core=4.5.1, testing=4.5.2. Stable on kernel.org=4.5.3)
Is there a reason for such delay?
Simply because our main kernel pkg maintainer is busy with real life and so somewhat late with packaging the releases. -Andy
Am 07.05.2016 um 14:09 schrieb Andreas Radke:
Am Sat, 7 May 2016 09:15:13 +0000 schrieb Abderrahman Najjar <abderrahman.najjar@gmail.com>:
The kernel package (linux) is constantly out of date, both in Testing & Core.
Whenever a version is pushed in kernel.org, the previous stable will be still in testing. And then the (old) stable version gets pushed to core, and the next one in testing will be already old (because it's the latest stable). Such as the case right now (Core=4.5.1, testing=4.5.2. Stable on kernel.org=4.5.3)
Is there a reason for such delay? Simply because our main kernel pkg maintainer is busy with real life and so somewhat late with packaging the releases.
-Andy Thanks Andy, yes this is correct. Sorry folks sometimes real life catches you and that's more important. I'm sure all understand this.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sat, May 7, 2016 at 6:24 PM, Tobias Powalowski via arch-general < arch-general@archlinux.org> wrote:
Thanks Andy, yes this is correct. Sorry folks sometimes real life catches you and that's more important. I'm sure all understand this.
greetings tpowa
I appreciate that. But there are two maintainers listed on the package
[2016-05-07 20:00:35 +0000] Abderrahman Najjar:
On Sat, May 7, 2016 at 6:24 PM, Tobias Powalowski via arch-general < arch-general@archlinux.org> wrote:
Thanks Andy, yes this is correct. Sorry folks sometimes real life catches you and that's more important. I'm sure all understand this.
I appreciate that. But there are two maintainers listed on the package
It takes time to carefully configure, build and test a quality package. I, for one, am perfectly happy with Tobias taking all the time he needs to make sure we can all depend on this critical piece of software. You are of course free to try and maintain a kernel package yourself, there are numerous options in the AUR too. -- Gaetan
May I ask what are the patches applied? i.e. what's the difference between the package in the repo, and a vanilla source compiled kernel?
On Sun, 8 May 2016 13:01:31 +0000, Abderrahman Najjar wrote:
May I ask what are the patches applied? i.e. what's the difference between the package in the repo, and a vanilla source compiled kernel?
[rocketmouse@archlinux ~]$ ls -hAl /var/abs/core/linux total 396K -rw-r--r-- 1 root root 674 May 8 00:06 change-default-console-loglevel.patch -rw-r--r-- 1 root root 181K May 8 00:06 config -rw-r--r-- 1 root root 175K May 8 00:06 config.x86_64 -rw-r--r-- 1 root root 1.2K May 8 00:06 linux.install -rw-r--r-- 1 root root 376 May 8 00:06 linux.preset -rw-r--r-- 1 root root 13K May 8 00:06 PKGBUILD [rocketmouse@archlinux ~]$ grep -i patch /var/abs/core/linux/PKGBUILD "https://www.kernel.org/pub/linux/kernel/v4.x/patch-${pkgver}.xz" "https://www.kernel.org/pub/linux/kernel/v4.x/patch-${pkgver}.sign" 'change-default-console-loglevel.patch') # add upstream patch patch -p1 -i "${srcdir}/patch-${pkgver}" # (relevant patch sent upstream: https://lkml.org/lkml/2011/7/26/227) patch -p1 -i "${srcdir}/change-default-console-loglevel.patch"
Le 08/05/2016 à 15:01, Abderrahman Najjar a écrit :
May I ask what are the patches applied? i.e. what's the difference between the package in the repo, and a vanilla source compiled kernel?
Kernel configuration is not about patches (only one in ArchLinux currenty, which you can find here[1] BTW, sometimes they are more when critical fixes takes time to come down from upstream). It’s about the config flags (look at both config files in the above link), and related issues reported by users. If you look at the commit log[2] and dig into the actual commits, you will see changes done each time. And if you ever compiled a kernel by yourself, you know that they are tons of them. So, you have to track new flags added upstream, what they do and what implies each value of them in order to choose the sensible default for Arch users. Then, someone might also open a bug report because his beloved flag is missing, but you have to look for the consequences of changing that flag for others users. In a few words, kernel packaging is not a job of fixing things that should be fixed upstream by adding patches, it’s about carefully selecting the kernel configuration to suit most user cases. So yes, kernel packaging isn’t a trivial task, and I too trust our kernel maintainers to do the right thing, taking their time for it. :) If you don’t like that, you’re free to compile your own version (which has some benefits too). ;) Bruno [1]: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux [2]: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/linux
On Sun, 8 May 2016 15:18:08 +0200, Bruno Pagani wrote:
It’s about the config flags
One patch is applied. However, for those building their own kernels make localmodconfig might be something that reduces the time needed to build the kernel much and apart from this, it reduces the risk of possible issues. I build kernels myself, but don't use 'make localmodconfig'. [rocketmouse@archlinux ~]$ grep 'Configure the kernel' -A5 /var/abs/core/linux/PKGBUILD # Configure the kernel. Replace the line below with one of your choice. #make menuconfig # CLI menu for configuration #make nconfig # new CLI menu for configuration #make xconfig # X-based configuration #make oldconfig # using old config from previous kernel version # ... or manually edit .config Regards, Ralf
participants (7)
-
Abderrahman Najjar
-
Andreas Radke
-
Bruno Pagani
-
Carsten Mattner
-
Gaetan Bisson
-
Ralf Mardorf
-
Tobias Powalowski