spec hacks for vanilla and git-based kernel rpm builds

[Roland McGrath]

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

[Dave Jones]

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

-- 
http://www.codemonkey.org.uk

[Josh Boyer]

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

[Roland McGrath]

>  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

[Roland McGrath]

>  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

[Roland McGrath]

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

[Jarod Wilson]

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.

-- 
Jarod Wilson
jwilson(a)redhat.com

[Dave Jones]

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

-- 
http://www.codemonkey.org.uk

[Jarod Wilson]

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.

-- 
Jarod Wilson
jwilson(a)redhat.com

[Josh Boyer]

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

[Dave Jones]

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

-- 
http://www.codemonkey.org.uk

[Jonathan Underwood]

On 02/07/07, Dave Jones <davej(a)redhat.com&gt; 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?

[Dave Jones]

On Mon, Jul 02, 2007 at 05:50:13PM +0100, Jonathan Underwood wrote:
>  On 02/07/07, Dave Jones <davej(a)redhat.com&gt; 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

-- 
http://www.codemonkey.org.uk

[Thorsten Leemhuis]

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

[Dave Jones]

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

-- 
http://www.codemonkey.org.uk

[Jarod Wilson]

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...

-- 
Jarod Wilson
jwilson(a)redhat.com

[Thorsten Leemhuis]

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

[Dave Jones]

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

-- 
http://www.codemonkey.org.uk

[Roland McGrath]

>  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.

[Jarod Wilson]

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.

-- 
Jarod Wilson
jwilson(a)redhat.com