Hi,
xen is back in factory and with it unfortunately also the problems in building kmps ;(
xtables-addon:
checking kernel version that we will build against... /bin/sh: /usr/src/linux-2.6.37-rc3-git6-8-obj/x86_64/xen/scripts/Makefile.xen: Permission denied /usr/src/linux-2.6.37-rc3-git6-8/scripts/basic/fixdep.c:398:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied compilation terminated. make[4]: *** [scripts/basic/fixdep] Error 1 make[3]: *** [scripts_basic] Error 2 ./configure: line 10822: Updating /usr/src/linux+0: division by 0 (error token is "/src/linux+0")
omnibook: Processing files: omnibook-kmp-xen-20100406_kUpdating-3.21.x86_64 error: File not found: /usr/src/packages/BUILDROOT/omnibook-20100406-3.21.x86_64/lib/modules/Updating- xen error: File must begin with "/": 2.6.37-rc3-git6-8
These problems did not appear when xen was disabled. Please fix them.
Greetings, Stephan
Am Mittwoch, 1. Dezember 2010 schrieb Stephan Kulow:
Hi,
xen is back in factory and with it unfortunately also the problems in building kmps ;(
xtables-addon:
checking kernel version that we will build against... /bin/sh: /usr/src/linux-2.6.37-rc3-git6-8-obj/x86_64/xen/scripts/Makefile.xen: Permission denied /usr/src/linux-2.6.37-rc3-git6-8/scripts/basic/fixdep.c:398:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied compilation terminated. make[4]: *** [scripts/basic/fixdep] Error 1 make[3]: *** [scripts_basic] Error 2 ./configure: line 10822: Updating /usr/src/linux+0: division by 0 (error token is "/src/linux+0")
omnibook: Processing files: omnibook-kmp-xen-20100406_kUpdating-3.21.x86_64 error: File not found: /usr/src/packages/BUILDROOT/omnibook-20100406-3.21.x86_64/lib/module s/Updating- xen error: File must begin with "/": 2.6.37-rc3-git6-8
These problems did not appear when xen was disabled. Please fix them.
A week passed and I still can't get KMPs to build ;(
What seems to trigger the omnibook breakage is this from Makefile.build:
Makefile.xen := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD), $(objtree)/scripts)/Makefile.xen $(Makefile.xen): $(srctree)/scripts/Makefile.xen.awk $(srctree)/scripts/Makefile.build @echo ' Updating $@'
the above echo gets into the output expected from the rpm macros.
Greetings, Stephan
On 08.12.10 at 17:15, Stephan Kulow coolo@suse.de wrote:
What seems to trigger the omnibook breakage is this from Makefile.build:
Makefile.xen := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD), $(objtree)/scripts)/Makefile.xen $(Makefile.xen): $(srctree)/scripts/Makefile.xen.awk $(srctree)/scripts/Makefile.build @echo ' Updating $@'
the above echo gets into the output expected from the rpm macros.
This construct has been there for ages, and didn't cause problems earlier. Hence so far I have no reason to think we need to fix something on the Xen side.
From what you write I'd guess there's a dependency on certain
output to result from certain build steps - shouldn't such, if needed at all, be done in a more tolerable way then? Why isn't any of the other kernel build output a problem?
Jan
Am Mittwoch, 8. Dezember 2010 schrieb Jan Beulich:
From what you write I'd guess there's a dependency on certain output to result from certain build steps - shouldn't such, if needed at all, be done in a more tolerable way then? Why isn't any of the other kernel build output a problem?
It looks like noone feels responsible for the rpm macros used by our kernels ; (
Greetings, Stephan
On Thursday 09 December 2010, 09:46:18 Stephan Kulow wrote:
Am Mittwoch, 8. Dezember 2010 schrieb Jan Beulich:
From what you write I'd guess there's a dependency on certain output to result from certain build steps - shouldn't such, if needed at all, be done in a more tolerable way then? Why isn't any of the other kernel build output a problem?
It looks like noone feels responsible for the rpm macros used by our kernels ; (
Jiri might.
I really don't want to disappoint anybody here, but back in 2007/2008, when I had issues in that area due to obvious bugs, I've proposed patches and guess what: (after being told, that "we" do it differently to _avoid_ the problem) I simply got ignored.
https://bugzilla.novell.com/show_bug.cgi?id=271286 https://bugzilla.novell.com/show_bug.cgi?id=293558
Check the dates.
You're lucky, Stephan. People talk to you. You can use your influence to make an impact. Others might not.
Pete
On Thu, 9 Dec 2010 10:31:02 +0100 "Hans-Peter Jansen" hpj@urpla.net wrote:
https://bugzilla.novell.com/show_bug.cgi?id=271286 https://bugzilla.novell.com/show_bug.cgi?id=293558
Check the dates.
You're lucky, Stephan. People talk to you. You can use your influence to make an impact. Others might not.
I think you are extrapolating from before the time when Michal took over kernel packaging. IMHO things have improved greatly since then.
On 8.12.2010 17:15, Stephan Kulow wrote:
Am Mittwoch, 1. Dezember 2010 schrieb Stephan Kulow:
Hi,
xen is back in factory and with it unfortunately also the problems in building kmps ;(
xtables-addon:
checking kernel version that we will build against... /bin/sh: /usr/src/linux-2.6.37-rc3-git6-8-obj/x86_64/xen/scripts/Makefile.xen: Permission denied /usr/src/linux-2.6.37-rc3-git6-8/scripts/basic/fixdep.c:398:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied compilation terminated. make[4]: *** [scripts/basic/fixdep] Error 1 make[3]: *** [scripts_basic] Error 2 ./configure: line 10822: Updating /usr/src/linux+0: division by 0 (error token is "/src/linux+0")
omnibook: Processing files: omnibook-kmp-xen-20100406_kUpdating-3.21.x86_64 error: File not found: /usr/src/packages/BUILDROOT/omnibook-20100406-3.21.x86_64/lib/module s/Updating- xen error: File must begin with "/": 2.6.37-rc3-git6-8
These problems did not appear when xen was disabled. Please fix them.
A week passed and I still can't get KMPs to build ;(
What seems to trigger the omnibook breakage is this from Makefile.build:
Makefile.xen := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD), $(objtree)/scripts)/Makefile.xen $(Makefile.xen): $(srctree)/scripts/Makefile.xen.awk $(srctree)/scripts/Makefile.build @echo ' Updating $@'
Ah. There is an older bug that some of the KMP macros results in the kernel Makefile attempting to rebuild _something_. What was bizarre when I tried to debug this was that when I built again in the same chroot, the problem disappeared (although a non-root build should not change anything in the chroot). So far this has been only a "aesthetic" issue, the KMPs built OK. Now with the echo added by the xen patches, becomes a real problem. I'll have a deeper look now.
Michal
On 9.12.2010 11:36, Michal Marek wrote:
Ah. There is an older bug that some of the KMP macros results in the kernel Makefile attempting to rebuild _something_. What was bizarre when I tried to debug this was that when I built again in the same chroot, the problem disappeared (although a non-root build should not change anything in the chroot). So far this has been only a "aesthetic" issue, the KMPs built OK. Now with the echo added by the xen patches, becomes a real problem. I'll have a deeper look now.
.config is newer than include/config/auto.conf in /usr/src/linux-obj/$arch/$flavor, resulting in the rebuild. Now running a kernel build to find out what touches .config.
Michal
On 9.12.2010 12:52, Michal Marek wrote:
On 9.12.2010 11:36, Michal Marek wrote:
Ah. There is an older bug that some of the KMP macros results in the kernel Makefile attempting to rebuild _something_. What was bizarre when I tried to debug this was that when I built again in the same chroot, the problem disappeared (although a non-root build should not change anything in the chroot). So far this has been only a "aesthetic" issue, the KMPs built OK. Now with the echo added by the xen patches, becomes a real problem. I'll have a deeper look now.
.config is newer than include/config/auto.conf in /usr/src/linux-obj/$arch/$flavor, resulting in the rebuild. Now running a kernel build to find out what touches .config.
I think it's because fdupes notices that /boot/config-$version and /usr/src/linux-$version-obj/$arch/$flavor/.config have the same content and links them. I'm now running another testbuild to verify.
Michal
On 9.12.2010 15:09, Michal Marek wrote:
On 9.12.2010 12:52, Michal Marek wrote:
On 9.12.2010 11:36, Michal Marek wrote:
Ah. There is an older bug that some of the KMP macros results in the kernel Makefile attempting to rebuild _something_. What was bizarre when I tried to debug this was that when I built again in the same chroot, the problem disappeared (although a non-root build should not change anything in the chroot). So far this has been only a "aesthetic" issue, the KMPs built OK. Now with the echo added by the xen patches, becomes a real problem. I'll have a deeper look now.
.config is newer than include/config/auto.conf in /usr/src/linux-obj/$arch/$flavor, resulting in the rebuild. Now running a kernel build to find out what touches .config.
I think it's because fdupes notices that /boot/config-$version and /usr/src/linux-$version-obj/$arch/$flavor/.config have the same content and links them. I'm now running another testbuild to verify.
Should be fixed now with commit 149d22b and sr 55395.
Michal
Am Donnerstag, 9. Dezember 2010 schrieb Michal Marek:
On 9.12.2010 15:09, Michal Marek wrote:
On 9.12.2010 12:52, Michal Marek wrote:
On 9.12.2010 11:36, Michal Marek wrote:
Ah. There is an older bug that some of the KMP macros results in the kernel Makefile attempting to rebuild _something_. What was bizarre when I tried to debug this was that when I built again in the same chroot, the problem disappeared (although a non-root build should not change anything in the chroot). So far this has been only a "aesthetic" issue, the KMPs built OK. Now with the echo added by the xen patches, becomes a real problem. I'll have a deeper look now.
.config is newer than include/config/auto.conf in /usr/src/linux-obj/$arch/$flavor, resulting in the rebuild. Now running a kernel build to find out what touches .config.
I think it's because fdupes notices that /boot/config-$version and /usr/src/linux-$version-obj/$arch/$flavor/.config have the same content and links them. I'm now running another testbuild to verify.
Should be fixed now with commit 149d22b and sr 55395.
Hi,
It worked for a while, but now a new kernel brought new problems of the same smell:
checking kernel version that we will build against... /bin/sh: /usr/src/linux-2.6.37-obj/i386/xen/scripts/Makefile.xen: Permission denied /usr/src/linux-2.6.37/scripts/basic/fixdep.c:398:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied
(xtables-addons build failure)
Greetings, Stephan
On 11.1.2011 11:20, Stephan Kulow wrote:
Am Donnerstag, 9. Dezember 2010 schrieb Michal Marek:
On 9.12.2010 15:09, Michal Marek wrote:
On 9.12.2010 12:52, Michal Marek wrote:
On 9.12.2010 11:36, Michal Marek wrote:
Ah. There is an older bug that some of the KMP macros results in the kernel Makefile attempting to rebuild _something_. What was bizarre when I tried to debug this was that when I built again in the same chroot, the problem disappeared (although a non-root build should not change anything in the chroot). So far this has been only a "aesthetic" issue, the KMPs built OK. Now with the echo added by the xen patches, becomes a real problem. I'll have a deeper look now.
.config is newer than include/config/auto.conf in /usr/src/linux-obj/$arch/$flavor, resulting in the rebuild. Now running a kernel build to find out what touches .config.
I think it's because fdupes notices that /boot/config-$version and /usr/src/linux-$version-obj/$arch/$flavor/.config have the same content and links them. I'm now running another testbuild to verify.
Should be fixed now with commit 149d22b and sr 55395.
Hi,
It worked for a while, but now a new kernel brought new problems of the same smell:
checking kernel version that we will build against... /bin/sh: /usr/src/linux-2.6.37-obj/i386/xen/scripts/Makefile.xen: Permission denied /usr/src/linux-2.6.37/scripts/basic/fixdep.c:398:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied
Happens only on i586 in the build service and I can't reproduce it on my machine at all :-/.
Michal
-
Hans-Peter Jansen -
Jan Beulich -
Michal Marek -
Stefan Seyfried -
Stephan Kulow