kernel dist-git - kernel - Fedora mailing-lists

29 Jul 2010

The new repo at ssh://pkgs.fedoraproject.org/kernel is supposedly live,
but I suggest that nobody attempt to touch it.  I think the CVS
migration might need to be redone and invalidate that old git repo.
Do:
cvs -Q -d cvs.fedoraproject.org:/cvs/pkgs co -P -d cvs-devel rpms/kernel/devel
git clone ssh://pkgs.fedoraproject.org/kernel git-devel
diff -ru --exclude={CVS,.git,.{cvs,git}ignore} {cvs,git}-devel
and marvel at the lossage.
cvs -Q -d cvs.fedoraproject.org:/cvs/pkgs co -P -d cvs-f13 rpms/kernel/F-13
git clone -b f13/master ssh://pkgs.fedoraproject.org/kernel git-f13
diff -ru --exclude={CVS,.git,.{cvs,git}ignore} {cvs,git}-f13
is not nearly as bad, but still disturbingly wrong.
And then f12 looks perfectly fine, and I didn't check the rest.
The "master" branch (aka devel aka rawhide) is just all messed up.
The kernel.spec is the right one, but nearly all the other files
are the entirely wrong ones, as if it got everything else from
another branch (including adding/removing files).
The f13/master branch is only somewhat messed up.  Mostly it just has
some files that were previously removed in CVS.  But it is also missing
one patch file, and apparently has an older revision for a couple of
patch files.
The only differences that there should be in this comparison are:
* no "branch" files
* .cvsignore -> .gitignore
* files with embedded $Tag: ...$ -> $Tag$
In fact, there are "branch" files in git though there should not be any.
We have the $Tag$ differences and .gitignore as we expect.
Everything else is just scary, scary, bogons.
My best guess is that the use of (real) CVS branches confused the
repository converter (I don't know which one he used).  It did convert
some real CVS branches to git branches, so it at least thinks it knows
about the concept.  But it sure got confused somehow.
Before I noticed this lossage, I was trying to start fiddling our magic
to cope with dist-git.  What I did is below.  Since the git repo is scrod,
I didn't commit anything anywhere.
The kernel.spec changes mean, as the comment says, that you have to
start using rpmdev-bumpspec to make your log entries and update the
release, or else remember to do it by hand.  No more $Revision$ magic.
We discussed on IRC doing newfangled git versions of that magic, but it
was just going to get entirely silly.  If we can't keep our rear ends in
gear, we can consider some git hooks to bludgeon ourselves for errors.
But since the new dist-git scheme means no git tags get made for builds
until you do them right, you probably won't manage to leave any evidence
of your pilot error that makes it obvious you didn't mean to do that.
The next person to rebase will get to rewrite rebase.sh to work in the
new world order.  When you do that, make it fiddle baserelease back to 1
while you're at it.  That and rpmdev-bumpspec will probably make for all
the release-number-setting magic we should really care to think we need.
The Makefile changes are just the first cut at basic decrufting.
IMHO we should rid of most of the rest of what's in Makefile.
Probably most of it belongs in separate scripts/foo scripts.
Thanks,
Roland

diff --git a/Makefile b/Makefile
index 42d84b2..6cdec44 100644  
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,4 @@
 # Makefile for source rpm: kernel
-# $Id$
-NAME     := kernel
 SPECFILE := kernel.spec
# use noarch for make prep instead of the current CPU
@@ -11,25 +9,12 @@ PREPARCH  = noarch
 # we only check the .sign signatures
 UPSTREAM_CHECKS = sign
-# local targets we need to carry around in addition to the default sources
-TARGETS		= download
+.PHONY: help
+help:
+%:
+	@echo "Try fedpkg $@ or something like that"
+	@exit 1
-define find-makefile-common
-for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; then if [ -f $$d/CVS/Root -a -w $$d/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
ifndef KVERSION
@@ -182,9 +167,6 @@ reconfig:
    @VERSION=$(KVERSION) make -f Makefile.config configs
    @scripts/reconfig.sh
-force-tag: $(SPECFILE) $(COMMON_DIR)/branches
-	@$(MAKE) tag TAG_OPTS="-F $(TAG_OPTS)"
-
 unused-kernel-patches:
    @for f in *.patch; do if [ -e $$f ]; then (egrep -q "^Patch[[:digit:]]+:[[:space:]]+$$f" $(SPECFILE) || echo "Unused:    $$f") && egrep -q "^ApplyPatch[[:space:]]+$$f|^ApplyOptionalPatch[[:space:]]+$$f" $(SPECFILE) || echo "Unapplied: $$f"; fi; done
diff --git a/kernel.spec b/kernel.spec
index 1a7fab9..21f34bc 100644  
--- a/kernel.spec
+++ b/kernel.spec
@@ -38,19 +38,18 @@ Summary: The Linux kernel
 %endif
 %endif
-# fedora_build defines which build revision of this kernel version we're
-# building. Rather than incrementing forever, as with the prior versioning
-# setup, we set fedora_cvs_origin to the current cvs revision s/1.// of the
-# kernel spec when the kernel is rebased, so fedora_build automatically
-# works out to the offset from the rebase, so it doesn't get too ginormous.
-#
-# If you're building on a branch, the RCS revision will be something like
-# 1.1205.1.1.  In this case we drop the initial 1, subtract fedora_cvs_origin
-# from the second number, and then append the rest of the RCS string as is.
-# Don't stare at the awk too long, you'll go blind.
-%define fedora_cvs_origin   2037
-%define fedora_cvs_revision() %2
-%global fedora_build %(echo %{fedora_cvs_origin}.%{fedora_cvs_revision $Revision$} | awk -F . '{ OFS = "."; ORS = ""; print $3 - $1 ; i = 4 ; OFS = ""; while (i <= NF) { print ".", $i ; i++} }')
+# baserelease defines which build revision of this kernel version we're
+# building.  We used to call this fedora_build, but the magical name
+# baserelease is matched by the rpmdev-bumpspec tool, which you should use.
+#
+# We used to have some extra magic weirdness to bump this automatically,
+# but now we don't.  Just use: rpmdev-bumpspec -c 'comment for changelog'
+# When changing base_sublevel below or going from rc to a final kernel,
+# reset this by hand to 1 (or to 0 and then use rpmdev-bumpspec).
+# scripts/rebase.sh should be made to do that for you, actually.
+#
+%global baserelease 57
+%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
 # on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,

    