1 Dec
2010
1 Dec
'10
10:26
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
8 Dec
8 Dec
17:15
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
17:46
> On
08.12.10 at 17:15, Stephan Kulow <coolo(a)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. 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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
9 Dec
9 Dec
09:46
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
10:31
On Thursday 09 December 2010, 09:46:18 Stephan Kulow wrote:
Am Mittwoch, 8. Dezember 2010 schrieb Jan Beulich:
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
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 ; ( 
20:04
On Thu, 9 Dec 2010 10:31:02 +0100
"Hans-Peter Jansen" <hpj(a)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.
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
11:36
On 8.12.2010 17:15, Stephan Kulow wrote:
Am Mittwoch, 1. Dezember 2010 schrieb Stephan Kulow:
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
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 $@'
12:52
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
15:09
On 9.12.2010 12:52, Michal Marek wrote:
On 9.12.2010 11:36, Michal Marek wrote:
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
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.
16:32
On 9.12.2010 15:09, Michal Marek wrote:
On 9.12.2010 12:52, Michal Marek wrote:
Should be fixed now with commit 149d22b and sr 55395.
Michal
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
On 9.12.2010 11:36, Michal Marek wrote:
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. 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.
11 Jan
11 Jan
11:20
Am Donnerstag, 9. Dezember 2010 schrieb Michal Marek:
On 9.12.2010 15:09, Michal Marek wrote:
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
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
On 9.12.2010 12:52, Michal Marek wrote:
Should be fixed now with commit 149d22b and sr 55395.
On 9.12.2010 11:36, Michal Marek wrote:
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. 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.
16:05
On 11.1.2011 11:20, Stephan Kulow wrote:
Am Donnerstag, 9. Dezember 2010 schrieb Michal Marek:
Happens only on i586 in the build service and I can't reproduce it on my
machine at all :-/.
Michal
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
On 9.12.2010 15:09, Michal Marek wrote:
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 On 9.12.2010 12:52, Michal Marek wrote:
Should be fixed now with commit 149d22b and sr 55395.
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.
3905
days inactive
3946
days old
11 comments
5 participants
participants (5)
-
Hans-Peter Jansen -
Jan Beulich -
Michal Marek -
Stefan Seyfried -
Stephan Kulow