hi, it seems there should happened something with centos build system between kernel 2.6.28-128.1.1 and 2.6.18-128.1.6 compilation. because although the two spec files only differs with a few dozen of patches the resulted src.rpm are different ie: ----------------------------------------- # rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef unifdef # rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef # ----------------------------------------- and this small differences means the latest kernel can't be compiled in mock. what's more the same is not true for rhel's kernel ie. in case of rhel's 2.6.18-128.1.6 it gives unifdef. so it's a centos bug and with this bug centos don't follow upstream behavior. just my 2c.
On Sun, Apr 19, 2009 at 8:30 AM, Farkas Levente lfarkas@lfarkas.org wrote:
hi, it seems there should happened something with centos build system between kernel 2.6.28-128.1.1 and 2.6.18-128.1.6 compilation. because although the two spec files only differs with a few dozen of patches the resulted src.rpm are different ie:
# rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef unifdef # rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef
#
and this small differences means the latest kernel can't be compiled in mock. what's more the same is not true for rhel's kernel ie. in case of rhel's 2.6.18-128.1.6 it gives unifdef. so it's a centos bug and with this bug centos don't follow upstream behavior. just my 2c.
I believe CentOS kernels are built using mock. In any event, I was able to build kernel-2.6.18-128.1.6.el5 from the CentOS srpm without an issue. What errors did you get?
Akemi
Farkas Levente wrote:
what's more the same is not true for rhel's kernel ie. in case of rhel's 2.6.18-128.1.6 it gives unifdef. so it's a centos bug and with this bug centos don't follow upstream behavior. just my 2c.
sounds like an issue on your setup rather than at the centos end, the kernels build fine in mock for me, and the sources match whats upstream.
Karanbir Singh wrote:
Farkas Levente wrote:
what's more the same is not true for rhel's kernel ie. in case of rhel's 2.6.18-128.1.6 it gives unifdef. so it's a centos bug and with this bug centos don't follow upstream behavior. just my 2c.
sounds like an issue on your setup rather than at the centos end, the kernels build fine in mock for me, and the sources match whats upstream.
ok i try to describe in more detail the problem: run this two command on centos's src.rpm: -------------------------------------- rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef -------------------------------------- now download rhel's src.rpm and run it on that rpms. the result are different. while both rhel's src.rpm are required unifdef the latest centos kernel do _not_ require unifdef. it has nothing to do with my setup since all these files are downloaded from centos and rhel. anyway see this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=496464 and if i build in mock i've got: ---------------------------------- Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.7677 + umask 022 + cd /builddir/build/BUILD + cd kernel-2.6.18 + LANG=C + export LANG + unset DISPLAY + cd linux-2.6.18.i386 + make ARCH=i386 INSTALL_HDR_PATH=/var/tmp/kernel-2.6.18-128.1.6.el5-root/usr headers_install CHK include/linux/version.h UPD include/linux/version.h make: execvp: unifdef: Permission denied make: *** [headers_install] Error 127 error: Bad exit status from /var/tmp/rpm-tmp.7677 (%install) RPM build errors: Could not canonicalize hostname: buildsys Bad exit status from /var/tmp/rpm-tmp.7677 (%install) Child returncode was: 1 ----------------------------------
Farkas Levente wrote:
run this two command on centos's src.rpm:
rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef
here is what I get on the src.rpm at this end: rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef unifdef
let me investigate what the problem might be
Karanbir Singh wrote:
Farkas Levente wrote:
run this two command on centos's src.rpm:
rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef
here is what I get on the src.rpm at this end: rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef unifdef
let me investigate what the problem might be
ok. i recheck it on centos-5.3 and still not true. did you test the src.rpm on the mirror sites? --------------------------------------------------------------- # wget ftp://mirrors.kernel.org/centos/5.3/updates/SRPMS/kernel-2.6.18-128.1.6.el5.src.rpm --13:46:30-- ftp://mirrors.kernel.org/centos/5.3/updates/SRPMS/kernel-2.6.18-128.1.6.el5.src.rpm => `kernel-2.6.18-128.1.6.el5.src.rpm' Resolving mirrors.kernel.org... 199.6.1.174, 204.152.191.39, 130.239.17.6, ... Connecting to mirrors.kernel.org|199.6.1.174|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /centos/5.3/updates/SRPMS ... done. ==> SIZE kernel-2.6.18-128.1.6.el5.src.rpm ... 68294189 ==> PASV ... done. ==> RETR kernel-2.6.18-128.1.6.el5.src.rpm ... done. Length: 68294189 (65M)
100%[====================================================================================================================>] 68,294,189 2.37M/s in 29s
13:46:59 (2.26 MB/s) - `kernel-2.6.18-128.1.6.el5.src.rpm' saved [68294189]
# rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef # rpm -q rpm rpm-4.4.2.3-9.el5 ---------------------------------------------------------------
On Apr 20, 2009, at 7:49 AM, Farkas Levente wrote:
Karanbir Singh wrote:
Farkas Levente wrote:
run this two command on centos's src.rpm:
rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef
here is what I get on the src.rpm at this end: rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef unifdef
let me investigate what the problem might be
ok. i recheck it on centos-5.3 and still not true. did you test the src.rpm on the mirror sites?
At the link you reported https://bugzilla.redhat.com/show_bug.cgi?id=496464 the root cause of the problem is likely described I'd suspect something changed in the build process that caused with_headers to be undefined. Have you tried to confirm that analysis? There's noone saying that you're not seeing what you're seeing, a kernel package without Requires: unifdef
73 de Jeff
Jeff Johnson wrote:
At the link you reported https://bugzilla.redhat.com/show_bug.cgi?id=496464 the root cause of the problem is likely described I'd suspect something changed in the build process that caused with_headers to be undefined. Have you tried to confirm that analysis? There's noone saying that you're not seeing what you're seeing, a kernel package without Requires: unifdef
Too long for a haiku >:) But it has some rhythm ...
scnr,
Ralph
Farkas Levente wrote:
rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef unifdef let me investigate what the problem might be
ok. i recheck it on centos-5.3 and still not true. did you test the src.rpm on the mirror sites?
This end == what goes into the buidsystem. And yes, I can see there is an issue which is what I was going to investigate as soon as I get some time.
In the mean time if someone wants to go ahead and work out why that with_headers got undefined, please go ahead and let us know whats going on.
Also, I can still build that kernel rpm in mock without any issues here.
Karanbir Singh wrote:
In the mean time if someone wants to go ahead and work out why that with_headers got undefined, please go ahead and let us know whats going on.
A very brief look at the spec file seems to show that its a bit random, depending on which arch the package is being built for the with_headers can go either way.
Why a src.rpm should be affected by required binary output based on arch, is something that needs investigating - however instinct tells me its a bug in the spec itself. Ideally, a src.rpm should be identical generated on any arch with any given set of '--defines'.
On Apr 20, 2009, at 8:27 AM, Karanbir Singh wrote:
Karanbir Singh wrote:
In the mean time if someone wants to go ahead and work out why that with_headers got undefined, please go ahead and let us know whats going on.
A very brief look at the spec file seems to show that its a bit random, depending on which arch the package is being built for the with_headers can go either way.
Why a src.rpm should be affected by required binary output based on arch, is something that needs investigating - however instinct tells me its a bug in the spec itself. Ideally, a src.rpm should be identical generated on any arch with any given set of '--defines'.
SRPM's are produced on a machine with an arch, and so results can/will vary.
Your instinct is correct.
But the kernel.spec has always been hugely complicated.
73 de Jeff
Jeff Johnson wrote:
On Apr 20, 2009, at 8:27 AM, Karanbir Singh wrote:
Karanbir Singh wrote:
In the mean time if someone wants to go ahead and work out why that with_headers got undefined, please go ahead and let us know whats going on.
A very brief look at the spec file seems to show that its a bit random, depending on which arch the package is being built for the with_headers can go either way.
Why a src.rpm should be affected by required binary output based on arch, is something that needs investigating - however instinct tells me its a bug in the spec itself. Ideally, a src.rpm should be identical generated on any arch with any given set of '--defines'.
SRPM's are produced on a machine with an arch, and so results can/will vary.
Your instinct is correct.
But the kernel.spec has always been hugely complicated.
Jeff as you're the rpm developer the question is: - it's kernel bug (eg. kernel's spec is wrong) - it's an rpm bug (rpm generate wrong require list) - it's a build system bug (the build system setup faulty) - or it's not a bug at all this should have to be in this way if the src.rpm generated on i386 arch?
if you said the srpms are arch dependent then the whole setup (rhel, centos, dag and all repos) where there is only one dir for srpms for all dir is wrong. or ...? thanks.
On Apr 20, 2009, at 8:46 AM, Farkas Levente wrote:
SRPM's are produced on a machine with an arch, and so results can/ will vary.
Your instinct is correct.
But the kernel.spec has always been hugely complicated.
Jeff as you're the rpm developer the question is:
- it's kernel bug (eg. kernel's spec is wrong)
- it's an rpm bug (rpm generate wrong require list)
- it's a build system bug (the build system setup faulty)
- or it's not a bug at all this should have to be in this way if the
src.rpm generated on i386 arch?
All depends on POV. E.g. The Debian Borg considers RPM itself to be the bug. ;-)
This is one of the two pleasant lies in RPM: reproducible builds. (The other lie is install "transactions" which implies no side effects ...)
From a CentOS POV:
CentOS is attempting to rebuild RHEL *.rpm's with no (or at least minimal) changes. So ultimately the CentOS build system is to blame because not achieving the stated goal.
OTOH, the kernel build is one of the packages that *IS* slightly modified in CentOS and, as Karabiner has pointed out, the spec file may need a tweak.
if you said the srpms are arch dependent then the whole setup (rhel, centos, dag and all repos) where there is only one dir for srpms for all dir is wrong. or ...?
The expectation is that SRPMS build everywhere, yes.
One directory for SRPM's makes sense iff the necessary QA to guarantee "reproducible builds" has been done. Which CentOS does at least as well as RHEL ;-)
hth
73 de Jeff
Farkas Levente wrote:
- it's kernel bug (eg. kernel's spec is wrong)
imho, the problem is in the kernel-2.6.spec and this section specifically:
%if %{with_headers} BuildRequires: unifdef %endif
specially when things like this are being done:
%ifarch i586 i686 ppc64iseries %define with_headers 0 %endif
and..
%ifarch noarch %define with_up 0 %define with_headers 0 %define with_debug 0 %define all_arch_configs kernel-%{kversion}-*.config %endif
----- the 'problem' you have in this case, is directly a fallout from the fact that depending on what arch-target the kernel-2.6.spec is built for, you might or might not get a usable src.rpm ( in your case, you didnt ).
We always use the src.rpm from the 'first target built'; wherein 'target' can not really be predicted since there are many threads each handling specific targets all running to different loads.
Given that Red Hat only published one set of sources ( in this case, from their ppc builders ) - this is an issue they should address upstream there. Since even ppc targets seem to impact what BuildRequires: are setup for the sources.
For now, and since we know this is a problem with the src.rpm out there, I'll replace the sources with a source only build done locally. And mark this as an issue for all future kernel builds. But a resolution to the issue upstream would still be something that should be attempted.
btw, I completely fail to see why you would want to have a kernel*.src.rpm that isnt usable to build a i686 kernel; so why conditional'ise the BuildRequires: ? Sounds like the Red Hat buildsystem might be broken :) I hope they dont do the really stupid mock trick of trying to build a src.rpm from a src.rpm first and then try to build it. or if they need that, perhaps they are not building from src.rpms at all[1]
- KB
kernel-2.6.18-128.1.6.el5.src.rpm from upstream provider can be rebuilded without any problems with mock. You must set proper target architectures in mock: $ mock --target noarch,i686,i386 -r redhat-5.3-i386 kernel-2.6.18-128.1.6.el5.src.rpm
Rebuilded package has unifdef: $ rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef unifdef
On Sun, 2009-04-19 at 17:30 +0200, Farkas Levente wrote:
hi, it seems there should happened something with centos build system between kernel 2.6.28-128.1.1 and 2.6.18-128.1.6 compilation. because although the two spec files only differs with a few dozen of patches the resulted src.rpm are different ie:
# rpm -qp --requires kernel-2.6.18-128.1.1.el5.src.rpm | grep unifdef unifdef # rpm -qp --requires kernel-2.6.18-128.1.6.el5.src.rpm | grep unifdef
#
and this small differences means the latest kernel can't be compiled in mock. what's more the same is not true for rhel's kernel ie. in case of rhel's 2.6.18-128.1.6 it gives unifdef. so it's a centos bug and with this bug centos don't follow upstream behavior. just my 2c.
-
Akemi Yagi -
Farkas Levente -
Jeff Johnson -
Karanbir Singh -
Nikolay Ulyanitsky -
Ralph Angenendt