continuing on the trend of finding novel ways to make life more interesting with git, here's the description from a new hook:
# prepare-commit-msg hook for debian package git repositories
#
# this script scans the diff that is going into a commit, and automatically
# injects some "proposed" comments based on what it finds in the diff. this
# can be used to avoid a few extra keystrokes when performing some of the
# more standard/boring tasks.
(see below for how to fetch the script)
this one definitely falls in the "carrot" category, as it encourages properly isolated (and thus automatically identifiable) changes. the proposed comments are then given to the standard editor, so one can easily amend them, append "Closes:" lines, etc.
some sample use-cases currently implemented:
-
changelog entries
-
detect when a new version is introduced in debian/changelog
prepare release information for <dist>/<vers> -
detect when an existing version is updated in debian/changelog
release information for <dist>/<vers>
-
-
debconf translations
-
detect when one or more po files are modified
updates to (<lang1>,<lang2>...) debconf translations * <lang1>: <translator for lang1> * <lang2>: <translator for lang1>
-
-
updates in debian/patches
-
detect when a new patch is introduced
new debian patch <patchname> <patch header (anything before the diff)> -
detect when an existing patch is modified
update debian patch <patchname> <patch header> -
detect when several patches are imported simultaneously
import <n> files in debian/patches <patch1>: <patch header> <patch2>: <patch header> <non-patch-file (series/etc)>: no patch description/comments found ... -
detect when several patches are created/modified simultaneously
create/update <n> files in debian/patches ...
-
as always, comments/feedback/suggestions/etc welcome 
using this new hook
note this is the same repo as the previous hooks i've blogged about, so if you already have that set up you can skip the clone and instead just pull in the changes. also note that this is in your local repo, not the remote one.
to set it up:
REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/debian/git-hooks/prepare-commit-msg-guess-message.py $REPO_PATH/.git/hooks/prepare-commit-msg
there aren't currently any configurable options in this hook.
previously i threw together a small hook to make it a bit easier to avoid duplicate work while maintaining packages, as well as easily keep the BTS up to date with relevant information.
now i've commonized the code just a bit and have a second hook which can be used to maintain certian (what i believe to be) good practices for keeping packages in git. admittedly, it's a bit more "stick" than "carrot" with respect to streamlining workflows, but i feel the justifications and the resulting benefits are worth it.
so the hook does basically two things, either of which can be customized and/or disabled.
prevent "non-debian" changes on a "debian" branch
assuming that there are seperate branches for "debian" packaging and for "upstream" development, this hook prevents upstream-style changes on the debian branches. that is to say changes to files outside ./debian are not permitted on a "debian" branch, unless of course you're merging from an upstream branch.
instead, changes to the source in a debian branch should be managed by quilt-style "feature patches", or a more advanced branch topology using some kind of feature branches (topgit or similar).
prevent changelog modifications from being mixed in with other commits
this one might be a bit more controversial for some. basically, the idea is that:
- stuff is fixed in a commit
- there is a log message for this commit, which contains a description of the fix
- the changelog update is redundant information to this log
- it's impossible to merge/cherry-pick/revert the fix later if the changelog gets tangled into the commit.
- there are nice tools (git dch) for managing debian/changelog updates anyway.
therefore, this hook "declines" commits which modify debian/changelog, unless it is the only file being changed.
using this new hook
note this is the same repo as the other hook, so if you already have that set up you can skip the clone and instead just pull in the changes.
to set it up:
REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/debian/git-hooks/pre-receive-fileset-fascism.py $REPO_PATH/hooks/pre-receive
the config options for controlling this hook (these are git config options just like the other hook):
# hooks.debianbranches (default: 'debian-.*')
# a regular expression which indicates which branches are "debian" branches.
# in the context of this hook such branches are not allowed to have changes
# in files outside of the ./debian directory.
# hooks.sacredchangelog (default: True)
# if set to True, debian/changelog can not be changed in a commit that
# also modifies other files. this helps ensure changes that are easily
# merged/cherry-picked/reverted.
examples of the hook in action
rejecting a commit that has an entangled changelog:
rangda[~/debian/php] git push :)
Counting objects: 9, done.
Delta compression using 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 442 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
fileset-fascism rejecting commit 2fab3269b3d9daedd7013a576483a11ccb4cb86a
debian/changelog must be changed seperately from other files.
changed files in this commit:
debian/changelog
debian/control
error: hooks/pre-receive exited with error code 1
To ssh://git.debian.org/git/pkg-php/php.git
! [remote rejected] debian-sid -> debian-sid (pre-receive hook declined)
error: failed to push some refs to 'ssh://git.debian.org/git/pkg-php/php.git'
rejecting a commit that has non ./debian changes:
rangda[~/debian/php] git push :)
Counting objects: 5, done.
Delta compression using 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 309 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
fileset-fascism rejecting commit d96669c0780e33b250af81404e263fc181fe0547
non ./debian changes on a debian branch in this commit.
error: hooks/pre-receive exited with error code 1
To ssh://git.debian.org/git/pkg-php/php.git
! [remote rejected] debian-sid -> debian-sid (pre-receive hook declined)
error: failed to push some refs to 'ssh://git.debian.org/git/pkg-php/php.git'
as always, comments/feedback/suggestions/etc welcome 
(note that i've just tried enabling the comments feature of
ikiwiki, so feel free to use it
)
(update: okay so i apparently failed to enable comments
earlier... but it should be working now
)
compiz(-fusion) 0.8.2 uploaded to unstable
for all you lovers of desktop bling, the latest stable release of compiz-fusion has been uploaded to unstable. new features of note:
- new kde4 based decorator and kconfig4 module for the kde4.2 desktop
- better stability for suspend/resume (that might be a driver improvement though)
- gnomecompat support for importing keyboard shortcuts
- fix for xdamage/refresh problems on some nvidia cards
- zomg more bling plugins
new one-off script for building compiz packages
the biggest problem with trying to maintain compiz packages is that they're for some reason distributed as almost a dozen different source projects upstream, but extremely interdependant wrt their API. therefore updating the packages to a new upstream version is a Big Pain. i've numbed that pain a bit with a new helper script, which should amongst other things make it easier to manage backports to lenny, which i've already seen people requesting.
compiz 0.8.2 lenny packages available for testing
..which brings us to our next topic. before i upload them to somewhere a little more official, i figure i could put a call out to teh lazywebs to do some QA work and make sure that it doesn't totally explode on your system (unless you're using the explode animation plugin, in which case it's functioning properly)
sources.list entry to try it out on an amd64 lenny system:
deb http://people.debian.org/~seanius/compiz/lenny-backports/amd64 ./
sources.list entry to try it out on an i386 lenny system:
deb http://people.debian.org/~seanius/compiz/lenny-backports/i386 ./
and then apt-get install compiz compiz-fusion-plugins-main (etc)
so give it a try and let me know how it goes!
pkg-php moving to git
with some initial legwork from Mark Hershberger we've migrated to a git repository for the php packaging vcs. due to the long and convoluted history of our svn repository, we decided it wasn't worth the effort of trying to get every single svn commit mapped into the new repo. as a compromise to having to start from scratch, we used the existing branches/tags on top of a series of upstream tarball imports to get an accurate representation of the release history.
new git<->bts integration hook for debian packaging
i've been dabbling with a new hook to make for more useful integration from a git-buildpackage oriented workflow. in this workflow the changelog is often the last thing prepared, possibly days or even weeks after a fix has been committed for a bug. therefore the standard tagpending and typical changelog-scanning hooks aren't incredibly useful.
instead, this hook scans for "Closes:" meta-info in the commits, similar to how "git dch" does, and then sends a notification and/or control commands to the bts. here's an example. note that it also mentions the branch that recieved the fix in the notification, so it's easier to see which branches have a fix at a quick glance.
how to use this for your own git repo:
REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/git-post-receive-url-notifications.py $REPO_PATH/hooks/post-receive
there's a number of configurable options (take a look at the top of the file for some fairly verbose comments), but it should work with some fairly reasonable defaults out of the box.
it can also be configured to do the more traditional changelog-scanning, but i'm finding it to be a better workflow to avoid combining changelog entries with the actual fixes (makes them harder to cherry-pick later), and a notification with a link to the changelog entry really isn't that useful beyond what "bts tag nnn pending" can already do. plus i don't like the typical duplication involved in manually managing the changelog. i find it better to generate the changelog via git-dch and automatically get all the "closes:" tags, and then just do a bit of editorial touchups before preparing/releasing the upload.
so give it a try if you like, feel free to send feedback/fixes/etc. for example i think the utf-8 support might still be a bit dodgy, as well as possibly the automatic gitweb url detection and changelog scanning.