FS#14534 - PKGBUILD of kernel26 downloads the wrong kernel sources (typo in PKGBUILD)
Attached to Project:
Arch Linux
Opened by Heiko Baums (cyberpatrol) - Friday, 01 May 2009, 08:10 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 02 May 2009, 06:35 GMT
Opened by Heiko Baums (cyberpatrol) - Friday, 01 May 2009, 08:10 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 02 May 2009, 06:35 GMT
|
Details
Description:
I was called attention to a bug (typo) in the kernel26 PKGBUILD by Xabre, who posted a comment to my package kernel26-fbcondecor in AUR. Unfortunately he deleted it at once. Because I'm using the PKGBUILD from the stock kernel (core/kernel26), this bug is also in the PKGBUILD of the stock kernel and possibly in some other kernel packages. In the source array of this PKGBUILD there is this line for downloading the latest kernel sources: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_basekernel.tar.bz2 In fact this line should be: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_pkgver.tar.bz2 These are the variables from the PKGBUILD in the core repository: _basekernel=2.6.29 pkgver=${_basekernel}.1 These variables are set correctly, but the wrong variable is used in the source array. The current PKGBUILD of package version 2.6.29.1 downloads linux-2.6.29.tar.bz2, though it should download the more recent linux-2.6.29.1.tar.bz2. So even if the kernel package was updated, the kernel itself wasn't updated. It would be nice, if this could be fixed. Additional info: * package version(s) kernel26 >=2.6.29 |
This task depends upon
The vanilla sources, on top of which the stock patch is built, are not updated.
source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_basekernel.tar.bz2
ftp://ftp.archlinux.org/other/kernel26/${_patchname}.bz2
# the main kernel config files
config config.x86_64
# standard config files for mkinitcpio ramdisk
kernel26.preset)
With the values of the variables this source array looks like this:
source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
ftp://ftp.archlinux.org/other/kernel26/patch-2.6.29.1-3-ARCH.bz2
# the main kernel config files
config config.x86_64
# standard config files for mkinitcpio ramdisk
kernel26.preset)
So even if the package version is 2.6.29.1, only the vanilla sources of 2.6.29 are downloaded and then patched with the seperately downloaded stock patch.
This source array should in fact look like this with the values of the variables:
source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
ftp://ftp.archlinux.org/other/kernel26/patch-2.6.29.1-3-ARCH.bz2
# the main kernel config files
config config.x86_64
# standard config files for mkinitcpio ramdisk
kernel26.preset)
Because the current vanilla kernel is not 2.6.29, but 2.6.29.1 (in the meantime 2.6.29.2).
So the source array in the PKGBUILD should be this one:
source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$pkgver.tar.bz2
ftp://ftp.archlinux.org/other/kernel26/${_patchname}.bz2
# the main kernel config files
config config.x86_64
# standard config files for mkinitcpio ramdisk
kernel26.preset)
This one is in the current PKGBUILD:
cd ${srcdir}/linux-$_basekernel
This must be this one:
cd ${srcdir}/linux-$pkgver
And of course the stock kernel patch patch-${pkgver}-3-ARCH needs to be patched against the vanilla sources linux-2.6.29.1.tar.bz2 instead of linux-2.6.29.tar.bz2, as it is done now.
The generated -ARCH patch on the FTP doesn't match what is in git at this moment however. Tobias deleted the intel patch that had been merged upstream, but didn't commit the new PATCHCFG file to git.
I'm not quite sure, if this is the best practise. I think it would be better, if the customized ARCH patchset would be kept separated from the vanilla sources. In this point I have to agree with Xabre, who just wrote, that it would make it easier to maintain a custom kernel on top of the stock kernel package for people, who just want to have a vanilla kernel without the ARCH patches. And for other users, who probably are just interested, it would be easier to find out, which changes are made by the distribution's patchset, etc.
Btw., the new PKGBUILD makes it indeed a lot easier to build a customized kernel package.