rebasing rawhide kernels.
The Fedora kernels rebase to the latest upstream snapshot on a daily basis. I'm inherently, extremely lazy. These two statement sound like they are at odds with each other, but like most sneaky folks, I have a bunch of handy scripts to help me. Rebasing to a new -git snapshot is a single command for me if there aren't any rejects. (And most of the time, there aren't).


This is only really of use to people using the Fedora kernel CVS, but I'm posting it here for the morbidly curious, as I've had a few people ask about the frequency of updates, and how I manage to get it done almost daily along with everything else I do.

So here's the script in all its uglyness. (I freely admit its horrid, but I clearly have no shame).

#!/bin/bash
# Is there a new snapshot ?
OLD=`grep ^patch upstream | tail -n1`
NEW=`lynx -dump http://www.kernel.org/kdist/finger_banner | grep "snapshot for the stable"`
if [ "${?}" != 0 ] ; then
  echo "No new git snapshot of stable branch".
  exit
fi
NEW=`echo $NEW | awk '{ print $11 }'`

head -n2 upstream >upstream.new
echo patch-$NEW.bz2 >> upstream.new
rm -f upstream
mv upstream.new upstream

echo patch-$NEW.bz2 >> .cvsignore
perl -pi -e s/$OLD/patch-$NEW.bz2/ kernel-2.6.spec

make download

cvs add patch-$NEW.bz2.sign
rm -f $OLD.sign
cvs remove $OLD.sign

~/bin/bumpspecfile.py kernel-2.6.spec "- $NEW"

make prep 2>/dev/null
if [ "${?}" != 0 ] ; then
  echo "Rejects need fixing."
fi

This scriptlet doesn't handle quite a few cases. In fact, it only handles going from one -git release to another -git release. Going from -rc4-git8 to -rc5 will confuse it, and so I do that by hand still.
(That happens so infrequently, I haven't been lazy enough to rewrite the script to cope -- Getting the 99% case is what saves me most time here).

Sometimes, lazyness can be a good thing. In this case, it frees up a bunch of my time to do more useful things, like whacking bugs. The number of truly disgusting scripts like the above I've written and rely upon in my day-to-day hacking scares me sometimes.

Getting a new rawhide kernel out daily means as soon as we get a regression introduced upstream, we usually find out about it within 24hrs. The Red Hat build system is probably one of the first (if not the first) to do a daily build on every arch that we care about (from i386 to s390) each day. Having a daily kernel is also invaluable for going back and finding out when a problem first started happening.