A week on and the linux-3.0.73 source tarball has been released. The appropriate files were submitted to the build systems and the expected kernel-lt-3.0.73-1.el5.elrepo packages were created. They have been signed, uploaded to the main mirror and their availability announced.
But what about the kernel-lt-3.0.73-1.el6.elrepo packages, you ask? Unfortunately the inability to test the patches so submitted has resulted in the presence of a different bug in the linux-3.0.73 source tarball. That bug only affects the 32-bit build of the kernel with the el6 configuration.
arch/x86/mm/numa_32.c:107: error: redefinition of 'alloc_remap'
include/linux/bootmem.h:144: note: previous definition of 'alloc_remap' was here
make[2]: *** [arch/x86/mm/numa_32.o] Error 1
make[1]: *** [arch/x86/mm] Error 2
make: *** [arch/x86] Error 2
Two successive buggy tarballs have now been released . . . We wonder what the next tarball (linux-3.0.74) will bring? A kick up the rear for the creators, applied by Linus Torvalds, perhaps?
Update (2013-04-15). By making a change to the configuration for the el6 kernel (namely CONFIG_NUMA disabled for 32-bit), we have been able to build and release the package set. If you are inconvenienced by this configuration change, please let us know and -- most importantly -- refer to this bug at bugzilla.kernel.org Hopefully you will not be ignored.
Reported the issue on the LKML:
ReplyDeletehttps://lkml.org/lkml/2013/4/13/158
No response to the error report posted to the LKML. But there is a patch related to NUMA in '3.0.74-stable review' :
ReplyDeletehttps://lkml.org/lkml/2013/4/14/141
Now, let's revert the change made to CONFIG_NUMA and try rebuilding 3.0.74.
ReplyDeleteYes, kernel 3.0.74 now builds without the error. The CONFIG_NUMA option will be re-enabled in the next release of kernel-lt.
ReplyDelete