There are some manual hacks in the kernel specfile now for building stable release candidates. However, kernel 2.6.23.9-rc1 ends up being released as 2.6.23.8-NN because we don't have a good way to change the version. This update automates that; the only question is whether we should label the built kernel as an -rc. I didn't add that part, and the changes are untested: --- kernel.spec 29 Nov 2007 00:25:06 -0000 1.279 +++ kernel.spec 29 Nov 2007 22:45:41 -0000 @@ -34,6 +34,15 @@ %if 0%{?released_kernel} # Do we have a 2.6.21.y update to apply? %define stable_update 9 +# Do we have a stable RC update to apply? +%define stable_rc 0 +# Stable rc patches are incremental against the previous -stable +# If this is an rc we need the previous stable patch too +%if 0%{?stable_rc} +%define stable_base %(expr %{stable_update} - 1) +%else +%define stable_base %{stable_update} +%endif # Set rpm version accordingly %if 0%{?stable_update} %define stablerev .%{stable_update} @@ -534,8 +543,12 @@ # Here should be only the patches up to the upstream canonical Linus tree. # For a stable release kernel -%if 0%{?stable_update} -Patch00: patch-2.6.%{base_sublevel}.%{stable_update}.bz2 +%if 0%{?stable_base} +Patch00: patch-2.6.%{base_sublevel}.%{stable_base}.bz2 +%endif +%if 0%{?stable_rc} +Patch01: patch-2.6.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2 +%endif # non-released_kernel case # These are automagically defined by the rcrev and gitrev values set up @@ -1006,8 +1019,12 @@ # Update to latest upstream. # released_kernel with stable_update available case -%if 0%{?stable_update} -ApplyPatch patch-2.6.%{base_sublevel}.%{stable_update}.bz2 +%if 0%{?stable_base} +ApplyPatch patch-2.6.%{base_sublevel}.%{stable_base}.bz2 +%endif +%if 0%{?stable_rc} +ApplyPatch patch-2.6.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.bz2 +%endif # non-released_kernel case %else _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list