Hardy maintenance update

[Tim Gardner]

As you are no doubt aware, maintenance of some of the custom binary 
flavours in Hardy are a major pain. openvz and xen are the most 
problematic, so I've made some changes that will lessen the maintenance 
burden as well as provide some tools to ensure we're getting everything 
done correctly.

To begin with I've flattened the sources into their own directory after 
applying all of the custom-binary patches for that flavour as of 
Ubuntu-2.6.24-30.98:

debian/binary-custom.d/xen/src
debian/binary-custom.d/openvz/src

Andy and I have added a couple of new helper scripts; 
debian/scripts/misc/validate-patch-range which is run at insertchanges 
time, and debian/scripts/misc/apply-patch-to-binary-custom which is used 
to assist in the application of upstream patches.

For example, if you've just applied and commited an upstream patch, then 
your workflow might look something like this:

git format-patch -1
debian/scripts/misc/apply-patch-to-binary-custom 0001*
git add -u
git commit -s -m"squash me into the upstream patch"
git rebase -i HEAD~2

One side effect of having flattened sources is that your working 
directory is now 3 times as large. In order to avoid ginormous source 
package diffs I've implemented some extra clean rule logic that produces 
a single diff from the master sources, then deletes the binary-custom 
source directory. For example, 'fakeroot debian/rules clean' generates a 
single patchset in debian/binary-custom.d/*/patchset/000.patch. Of 
course this is the first thing that happens before a source package is 
built, so _any_ uncommitted changes that you've made in 
debian/binary-custom.d/*/src are now part of the patchset, plus you've 
lost any local changes. I expect folks will trip over this a time or two 
before getting the hang of things.

Hopefully these changes will keep me from becoming apoplectic the next 
time I have to fix openvz.

It _still_ doesn't help us with the xen duplicated file problem, but 
thats a different rant.

rtg
-- 
Tim Gardner tim.gardner at canonical.com