kernel dist-git

[Roland McGrath]

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,

[Kyle McMartin]

On Thu, Jul 29, 2010 at 01:48:49AM -0700, Roland McGrath wrote:
>  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).
>   
It looks like a lot of the loss came in when rawhide was cvs branched
for private-f14-2_6_34, a lot of the deleted files exist from that point
in the git tree.

That branch is useless now, can we re-run the script ignoring it and see
what happens?

--Kyle

[Dave Jones]

On Thu, Jul 29, 2010 at 01:48:49AM -0700, Roland McGrath wrote:
 
>  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. 
it's currently busted anyway, since kernel.org changed their output again.
If rc7 come out right now, the finger banner would show it as
'the latest mainline', but it would also show rc6-gitwhatever as 'latest
snapshot'.

why did they make it do this ? hell knows. I looked at fixing it, but just
made it worse, so gave up on it for now. I've been rebasing by hand since.

I wonder if ketchup has already solved this. We could just use that to get
the version number.

	Dave

[Jon Masters]

On Thu, 2010-07-29 at 12:35 -0400, Dave Jones wrote:
>  On Thu, Jul 29, 2010 at 01:48:49AM -0700, Roland McGrath wrote:
>   
>   > 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.
>  
>  it's currently busted anyway, since kernel.org changed their output again.
>  If rc7 come out right now, the finger banner would show it as
>  'the latest mainline', but it would also show rc6-gitwhatever as 'latest
> snapshot'.
>  
>  why did they make it do this ? hell knows. I looked at fixing it, but just
>  made it worse, so gave up on it for now. I've been rebasing by hand since.
>  
>  I wonder if ketchup has already solved this. We could just use that to get
>  the version number. 
Did you ping John Hawley (who did the k.o bits for that)?

Jon.