Re: spec hacks for vanilla and git-based kernel rpm builds
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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 [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
On 02/07/07, Dave Jones [EMAIL PROTECTED] 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? ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
On Mon, Jul 02, 2007 at 05:50:13PM +0100, Jonathan Underwood wrote: On 02/07/07, Dave Jones [EMAIL PROTECTED] 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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
spec hacks for vanilla and git-based kernel rpm builds
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
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: spec hacks for vanilla and git-based kernel rpm builds
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
