Here I am again with those hacks to do alternate builds from the kernel spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
--- kernel-2.6.spec 08 Jun 2007 12:55:12 -0700 1.3213 +++ kernel-2.6.spec 08 Jun 2007 12:55:05 -0700 @@ -63,7 +63,8 @@ Summary: The Linux kernel (the core of t %define sublevel 21 %define kversion 2.6.%{sublevel} %define rpmversion 2.6.%{sublevel} -%define release %(R="$Revision: 1.3213 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid} +%define specrelease %(R="$Revision: 1.3213 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid} +%define release %{specrelease}
%define make_target bzImage %define kernel_image x86 @@ -76,6 +77,24 @@ Summary: The Linux kernel (the core of t %define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE} %define hdrarch %_target_cpu
+%if 0%{!?nopatches:1} +%define nopatches 0 +%endif + +%if %{nopatches} +%define includexen 0 +%define variant -vanilla +%else +%define variant_fedora -fedora +%endif + +%define using_upstream_branch 0 +%if 0%{?upstream_branch:1} +%define using_upstream_branch 1 +%define variant -%{upstream_branch}%{?variant_fedora} +%define release %{upstream_branch_release}.%{specrelease} +%endif + # if requested, only build base kernel %if %{with_baseonly} %define with_smp 0 @@ -248,6 +267,15 @@ Summary: The Linux kernel (the core of t %define kernel_image vmlinux %endif
+%if %{nopatches} +%define with_modsign 0 +# Ignore unknown options in our config-* files. +# Some options go with patches we're not applying. +%define oldconfig_target loose_nonint_oldconfig +%else +%define oldconfig_target nonint_oldconfig +%endif + # To temporarily exclude an architecture from being built, add it to # %nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we # don't build kernel-headers then the new build system will no longer let @@ -297,7 +325,7 @@ Summary: The Linux kernel (the core of t # %define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-1
-Name: kernel +Name: kernel%{?variant} Group: System Environment/Kernel License: GPLv2 Version: %{rpmversion} @@ -332,7 +360,9 @@ BuildPreReq: bzip2, findutils, gzip, m4, BuildPreReq: gnupg %endif BuildRequires: gcc >= 3.4.2, binutils >= 2.12, redhat-rpm-config +%if %{usesparse} BuildRequires: sparse >= 0.3 +%endif BuildConflicts: rhbuildsys(DiskFree) < 500Mb
@@ -380,7 +410,16 @@ Source80: config-rhel-generic Source81: config-rhel-x86-generic Source82: config-olpc-generic
+%if %{using_upstream_branch} +### BRANCH PATCH ### +%else +# Here should be only the patches up to the upstream canonical Linus tree. Patch00: patch-2.6.22-rc4.bz2 +%endif + +%if !%{nopatches} + +# Patches 10 through 99 are for things that are going upstream really soon. Patch10: linux-2.6-utrace.patch Patch20: nouveau-drm.patch Patch30: linux-2.6-sysrq-c.patch @@ -849,10 +888,16 @@ ApplyPatch() patch -p1 -F1 -s < $RPM_SOURCE_DIR/$1 }
+%if %{using_upstream_branch} +### BRANCH APPLY ### +%else
# Update to latest upstream. bzcat $RPM_SOURCE_DIR/patch-2.6.22-rc4.bz2 | patch -p1 -F1 -s
+%endif +%if !%{nopatches} + # Patches 10 through 100 are meant for core subsystem upgrades
# Roland's utrace ptrace replacement. @@ -895,12 +940,14 @@ ApplyPatch linux-2.6-pmac-zilog.patch # # Bugfixes to the core system and patches related to how RPMs are build # +%endif
# This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). -ApplyPatch linux-2.6-build-nonintconfig.patch +ApplyPatch linux-2.6.17-build-nonintconfig.patch
+%if !%{nopatches} # Exec shield ApplyPatch linux-2.6-execshield.patch
@@ -1076,6 +1123,7 @@ ApplyPatch linux-2.6-warnings-emptymacro ApplyPatch linux-2.6-warnings-register.patch
# END OF PATCH APPLICATIONS +%endif
cp %{SOURCE10} Documentation/
@@ -1098,7 +1146,7 @@ for i in *.config do mv $i .config Arch=`head -1 .config | cut -b 3-` - make ARCH=$Arch nonint_oldconfig > /dev/null + make ARCH=$Arch %{oldconfig_target} > /dev/null echo "# $Arch" > configs/$i cat .config >> configs/$i done @@ -1184,7 +1232,7 @@ BuildKernel() { KernelImage=arch/$Arch/boot/bzImage fi
- make -s ARCH=$Arch nonint_oldconfig > /dev/null + make -s ARCH=$Arch %{oldconfig_target} > /dev/null make -s ARCH=$Arch %{?_smp_mflags} $MakeTarget %{?sparse_mflags} make -s ARCH=$Arch %{?_smp_mflags} modules %{?sparse_mflags} || exit 1
On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote:
Here I am again with those hacks to do alternate builds from the kernel spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
# This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). -ApplyPatch linux-2.6-build-nonintconfig.patch +ApplyPatch linux-2.6.17-build-nonintconfig.patch
This bit looks odd.
No other objections though. (Don't forget to add a changelog entry)
Dave
On Fri, 2007-06-08 at 16:03 -0400, Dave Jones wrote:
On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote:
Here I am again with those hacks to do alternate builds from the kernel spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
# This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). -ApplyPatch linux-2.6-build-nonintconfig.patch +ApplyPatch linux-2.6.17-build-nonintconfig.patch
This bit looks odd.
No other objections though. (Don't forget to add a changelog entry)
Just wondering about the usesparse macro. Any reason to conditionalize running sparse on it?
josh
Just wondering about the usesparse macro. Any reason to conditionalize running sparse on it?
The only change in my diff is not to buildrequire sparse when not using it. The reasons to conditionalize are unrelated to this change. (They are some arch problems in sparse, and sparse not in repos for buildrequire in fc<7, in case this spec is copied for later fc[56] updates.)
Thanks, Roland
On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote:
Here I am again with those hacks to do alternate builds from the kernel spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
# This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). -ApplyPatch linux-2.6-build-nonintconfig.patch +ApplyPatch linux-2.6.17-build-nonintconfig.patch
This bit looks odd.
Oh, yeah, that bit will not be there. Instead I'll replace linux-2.6-build-nonintconfig.patch with my version (posted here before), which adds loose_nonint_oldconfig.
I committed it. A little more tweaking was actually necessary, since something changed since last time I used this. Ironically, the kernel-vanilla build works now though the normal build doesn't because of configs lag.
I also took the liberty of enabling usesparse for F>=7 since I noticed it was always off now.
I'll follow up shortly with the makefile bits.
Thanks, Roland
Oops, I accidentally checked in my Makefile too. So I guess I'll just assume you thought its changes were good. ;-)
This one copies some extras-style boilerplate that is necessary if you have a whole-tree checkout of /cvs/pkgs/rpms. It does not give you individual foobar/common/ checkouts like it will if you do "cvs co foobar", and the old extras style was for everything to use your single common/ checkout at the top. This is now the standard boilerplate apparently, which every formerly Core package needs to work with whole-tree checkouts.
The rest (cvs diff -r 1.49 -r 1.50 Makefile) is all additions at the end. You can use "make vanilla-x86_64" or "make vanilla-prep" or whatnot, and various git/blah targets. The details were previously discussed here, and are in comments in the makefile additions.
@@ -14,7 +14,22 @@ UPSTREAM_CHECKS = sign # local targets we need to carry around in addition to the default sources TARGETS = configs download
-include ../common/Makefile.common +define find-makefile-common +for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$/Makefile.common ] ; then cd $$d ; cvs -Q update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done +endef + +MAKEFILE_COMMON := $(shell $(find-makefile-common)) + +ifeq ($(MAKEFILE_COMMON),) +# attept a checkout +define checkout-makefile-common +test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo "common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to checkout the 'common' module." ; exit -1 ; } >&2 +endef + +MAKEFILE_COMMON := $(shell $(checkout-makefile-common)) +endif + +include $(MAKEFILE_COMMON) include Makefile.config
debug:
Thanks, Roland
Roland McGrath wrote:
Oops, I accidentally checked in my Makefile too. So I guess I'll just assume you thought its changes were good. ;-)
This one copies some extras-style boilerplate that is necessary if you have a whole-tree checkout of /cvs/pkgs/rpms. It does not give you individual foobar/common/ checkouts like it will if you do "cvs co foobar", and the old extras style was for everything to use your single common/ checkout at the top. This is now the standard boilerplate apparently, which every formerly Core package needs to work with whole-tree checkouts.
The rest (cvs diff -r 1.49 -r 1.50 Makefile) is all additions at the end. You can use "make vanilla-x86_64" or "make vanilla-prep" or whatnot, and various git/blah targets. The details were previously discussed here, and are in comments in the makefile additions.
So I finally got around to poking at these bits again myself (in relation to bug 240878), but ran into an issue with a vanilla/nopatches build:
$ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec RPM build errors: File not found: /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64
There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though. (Looking into it more now, but figured I'd throw it out there, in case someone already knows what's up).
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote:
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages.
Dave
On Mon, 2007-07-02 at 11:57 -0400, Dave Jones wrote:
On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote:
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages.
Yay!
josh
On Mon, Jul 02, 2007 at 11:00:59AM -0500, Josh Boyer wrote:
On Mon, 2007-07-02 at 11:57 -0400, Dave Jones wrote:
On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote:
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages.
Yay!
There's another reason I'd like to get this done for F8. I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly). Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
Dave
On 02/07/07, Dave Jones davej@redhat.com wrote:
There's another reason I'd like to get this done for F8. I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly). Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
Sort of related to this - it's (usually? often?) the case that the shipped kernel is based on a "stable" point release - eg. on this F-7 box, the kernel is based on 2.6.21.2 according to the %changelog, and yet the kernel rpm is kernel-2.6.21-1.3228. Would it not be sensible to also add that last point number?
Jonathan.
ps. Sorry to Dave for sending this mail to him alone rather than the list pps. Why does this list not set the Reply-To to the list rather than the message sender?
On Mon, Jul 02, 2007 at 05:50:13PM +0100, Jonathan Underwood wrote:
On 02/07/07, Dave Jones davej@redhat.com wrote:
There's another reason I'd like to get this done for F8. I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly). Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
Sort of related to this - it's (usually? often?) the case that the shipped kernel is based on a "stable" point release - eg. on this F-7 box, the kernel is based on 2.6.21.2 according to the %changelog, and yet the kernel rpm is kernel-2.6.21-1.3228. Would it not be sensible to also add that last point number?
Sounds sensible. I did try a long time ago (when 2.6.x.y first began) and it broke something which I now forget, but it's probably something that just needs a bit more thought.
ps. Sorry to Dave for sending this mail to him alone rather than the list pps. Why does this list not set the Reply-To to the list rather than the message sender?
http://www.unicom.com/pw/reply-to-harmful.html
Dave
On 02.07.2007 18:27, Dave Jones wrote:
On Mon, Jul 02, 2007 at 11:00:59AM -0500, Josh Boyer wrote:
On Mon, 2007-07-02 at 11:57 -0400, Dave Jones wrote:
On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote:
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages.
There's another reason I'd like to get this done for F8. I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly).
I'd say it's unlikely that 2.6.23 is not ready in time for F8. Some statistics that lead to my opinion:
2.6.18 took 94 days to develop 2.6.19 took 71 days 2.6.20 took 66 days 2.6.21 took 80 days
2.6.22 is about 5-7 days away afaics; so it will have had around 73 days to get finished.
Final devel freeze for F8 currently is 24 October 2007 -- that's 114 days away from now; minus those ~6 days until 2.6.22; that leaves around 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that should work out when I look at the numbers from recent kernels found above.
Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
A proper kernel naming would help there as well (e.g. name the kernels just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old topic again that never got solved.
CU thl
On Mon, Jul 02, 2007 at 07:27:17PM +0200, Thorsten Leemhuis wrote:
I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly).
I'd say it's unlikely that 2.6.23 is not ready in time for F8. Some statistics that lead to my opinion:
2.6.18 took 94 days to develop 2.6.19 took 71 days 2.6.20 took 66 days 2.6.21 took 80 days
2.6.22 is about 5-7 days away afaics; so it will have had around 73 days to get finished.
Final devel freeze for F8 currently is 24 October 2007 -- that's 114 days away from now; minus those ~6 days until 2.6.22; that leaves around 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that should work out when I look at the numbers from recent kernels found above.
The concerns I have is that summertime is usually a slower period. People go to conferences, summits, beaches a lot more, so it could drag out a little. But based on your numbers, there is quite a bit of room for lag in there, so it's still plausible that we'll make it by October.
Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
A proper kernel naming would help there as well (e.g. name the kernels just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old topic again that never got solved.
Indeed. That's what Jarod was proposing to fix no?
Dave
Dave Jones wrote:
On Mon, Jul 02, 2007 at 07:27:17PM +0200, Thorsten Leemhuis wrote:
Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
A proper kernel naming would help there as well (e.g. name the kernels just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old topic again that never got solved.
Indeed. That's what Jarod was proposing to fix no?
Well, initially, I was thinking only for the vanilla variant to start out, but screw it, I'll go whole hog. Working on it now...
On 02.07.2007 19:39, Dave Jones wrote:
On Mon, Jul 02, 2007 at 07:27:17PM +0200, Thorsten Leemhuis wrote:
I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly).
I'd say it's unlikely that 2.6.23 is not ready in time for F8. Some statistics that lead to my opinion:
2.6.18 took 94 days to develop 2.6.19 took 71 days 2.6.20 took 66 days 2.6.21 took 80 days
2.6.22 is about 5-7 days away afaics; so it will have had around 73 days to get finished.
Final devel freeze for F8 currently is 24 October 2007 -- that's 114 days away from now; minus those ~6 days until 2.6.22; that leaves around 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that should work out when I look at the numbers from recent kernels found above.
The concerns I have is that summertime is usually a slower period. People go to conferences, summits, beaches a lot more, so it could drag out a little.
You have a point there -- just look at the numbers from 2.6.18 above (2.6.17 was 18.06.2006) and one ca see that 2.6.18 took a bit longer. But anyway:
But based on your numbers, there is quite a bit of room for lag in there, so it's still plausible that we'll make it by October.
+1
Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel".
A proper kernel naming would help there as well (e.g. name the kernels just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old topic again that never got solved.
Indeed. That's what Jarod was proposing to fix no?
/me reads thread again
Yeah, missed that, sorry.
Cu thl
On Mon, Jul 02, 2007 at 07:51:23PM +0200, Thorsten Leemhuis wrote:
2.6.22 is about 5-7 days away afaics; so it will have had around 73 days to get finished.
Final devel freeze for F8 currently is 24 October 2007 -- that's 114 days away from now; minus those ~6 days until 2.6.22; that leaves around 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that should work out when I look at the numbers from recent kernels found above.
The concerns I have is that summertime is usually a slower period. People go to conferences, summits, beaches a lot more, so it could drag out a little.
You have a point there -- just look at the numbers from 2.6.18 above (2.6.17 was 18.06.2006) and one ca see that 2.6.18 took a bit longer. But anyway:
actually, Red Hat was at least partly responsible for why .18 dragged out a bit too. When Linus & Andrew found out we were going to base RHEL5 on it, they wanted to be sure that the final .18 on which we built was fairly solid. During -rc for that kernel quite a few nasty long-drawn out bugs were found and fixed iirc.
Dave
Dave Jones wrote:
On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote:
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages.
Cool, I've got an implementation of this for kernel-vanilla I did a while back that I can resurrect and fire along for review.
So I finally got around to poking at these bits again myself (in relation to bug 240878), but ran into an issue with a vanilla/nopatches build:
$ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec RPM build errors: File not found: /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64
There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though. (Looking into it more now, but figured I'd throw it out there, in case someone already knows what's up).
Hmm. There are various magic things that use %{name} and others that use "kernel" explicitly. I'm sure this worked when I checked the stuff in. So something must have changed. I had to tweak something or other because of this issue, probably the %setup -n arg, but I don't quite recall. I made it use plain kernel-%{version} for the source dir name mostly so that an rpmbuild in your working dir reuses the kernel-V/vanilla dir and links. For having both installed in debuginfo rpms, it might make more sense to let it all use %{name}.
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
My gen-patches script used for the git-based rpms does something vaguely like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'. The -gitN names are not actual tags so git tools don't tell you about them, but the newfangled git-describe "number of commits since" version number makes for something that increases and can be resolved into an upstream rev.
Roland McGrath wrote:
So I finally got around to poking at these bits again myself (in relation to bug 240878), but ran into an issue with a vanilla/nopatches build:
$ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec RPM build errors: File not found: /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64
There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though. (Looking into it more now, but figured I'd throw it out there, in case someone already knows what's up).
Hmm. There are various magic things that use %{name} and others that use "kernel" explicitly. I'm sure this worked when I checked the stuff in. So something must have changed. I had to tweak something or other because of this issue, probably the %setup -n arg, but I don't quite recall. I made it use plain kernel-%{version} for the source dir name mostly so that an rpmbuild in your working dir reuses the kernel-V/vanilla dir and links. For having both installed in debuginfo rpms, it might make more sense to let it all use %{name}.
It looks like all the debug stuff is in a directory structure that matches whatever resulted from %setup, and the %files section references them using %{name}, but needs to use "kernel" instead of %{name}.
Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
My gen-patches script used for the git-based rpms does something vaguely like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'. The -gitN names are not actual tags so git tools don't tell you about them, but the newfangled git-describe "number of commits since" version number makes for something that increases and can be resolved into an upstream rev.
I just sent off a spec diff a few minutes ago that basically implements what I was thinking of (and now I see you've already commented on...). The main rc and git numbers I was interested in are those from the upstream Linus tree snapshots, which usually end up getting manually entered in the form of the patches added to the build, so I figured no magic necessary. The new stuff should interoperate with your bits as well for other-tree-git-based rpms too though.
kernel@lists.fedoraproject.org
-
Dave Jones -
Jarod Wilson -
Jonathan Underwood -
Josh Boyer -
Roland McGrath -
Roland McGrath -
Thorsten Leemhuis