Colors of Noise

Git-buildpackage 0.5.0 in experimental fixes quiet some bugs related to the import of upstream sources and Debian source packages. By getting rid of a complete source tree copy it also got about 50% faster when doing so. Since the code changed quiet a bit in that area it'd be great if some of you could give it some testing before I'll push it to unstable.

Here's a short overview of 3.0 source format support in git-buildpackage 0.4.64:

• git-import-dsc & git-import-dscs import 3.0 (quilt and native) format packages.
• git-import-orig: imports gzip and bz2 compressed archives. Other formats will be enabled once pristine-tar supports them (#499489).
• git-buildpackage handles creating gzip, bzip2, lzma and xz compressed tarballs with the --git-compression option although it could get a bit smarter and autodetect the compression type.

One loose end is the handling of multiple upstream tarballs (#561071, #561072). I'd be great to hear from people already using this feature how this can best be added into the gbp workflow.

The newer kids in town gbp-clone, gbp-pull (for keeping the repo up to date when using team maintenance) and gbp-pq (for managing the quilt patch-queue) don't care about the underlying source package format. These three are a bit underdocumented in the manual but information about the workflow is in the wiki.

As of git-buildpackage 0.4.60 gbp-pull supports --redo-pq which additionally recreates the patch-queue branch after a pull. Now you can keep your clone fresh with one command.

Inspired by tools developed by Debian's OCaml maintainers git-buildpackage now ships gbp-pull that can be used to keep your debian-, upstream- and pistine-tar branch up to date when doing team maintenance.

I added a short explanation on howto handle backports with git-buildpackage to the GBP workflow page.

git-buildpackage 0.4.57 adds gbp-clone to /usr/share/doc/examples/. If you use it instead of git pull it will automatically set up your upstream and pristine-tar branches. This was inspired by the helper scripts the ocaml team uses.

git-import-orig now calls a postimport hook which can be used to call git-dch after import so I could remove the hardcoded dch call.

git-buildpackage 0.4.55 now ships gbp-pq for easier serializing of git patch queue branches into quilt patch series and vice versa. It's currently in /usr/share/doc/git-buildpackage/examples/. I'll move it to /usr/bin/ once I feel a bit more confident that this is the right interface.

As of version 0.4.53 git-buildpackage's git-import-orig supports --fast-import. This uses git fast-import to import the new upstream version and speeds up imports by about a factor of two.

It's not as well tested as importing without --fast-import so please be careful and file bugreports if it fails.

As of version 0.4.47 git-buildpackage exports these environment variables to a called posttag hook:

• GBP_TAG: the tags name
• GBP_BRANCH: the branch you were on when creating the tag
• GBP_SHA1: the sha1 of the commit the tag was created at

This allows you to write posttag hooks that push out only the changes that correspond to the created tag. For a simple example see the GBP Manual. Using such a hook makes team maintenance a lot easier since you can't forget to push out the commits and tags for a newly uploaded package while making sure you don't push out any other changes.

When following Debian changelogs (e.g. via apt-listchanges or update-manager) one often wonders what an actual commit messages actually means or how a bug got actually fixed. Currently finding this information is cumbersome:

• Find out the version control system of the package, either via the PTS or via debian/control.
• Browse it's VCSs revision history either by using the web interface or by cloning the repository.
• Try to locate the correct commit from it's commit message. Hopefully it's the same as in the changelog and hopefully it mentions the bug number - otherwise: tough luck!

However this process can be automated if a package uses the following format for changelog entries:

* [commitd] changelog message

e.g.:

* [fed3f3d] fixed segfault during daemon startup (Closes: #7005180)

then you can use Cl2vcs to locate the exact commit that corressponds to that changelog entry. Cl2vcs uses the PTS to parse the packages Vcs-Browser URL to create a link back to the commit.

If you maintian your package in Git, creating this type of changelog entry is simple: You can tell git-dch to include N digits of the commit's SHA1 (the commit id) using the --id-length option, e.g.:

git-dch --release --auto --id-length=7

This way git-dch will include the first 7 digits of the commit's SHA1 (this options can of course also be specified in gbp.conf). Packages already using this are e.g. libvirt and calendarserver.

Note: a possibly useful extension of the above format would be:

 * [commitid1,commitid2,commitid3] changelog message 

so several commits can make up a changelog entry. For Subversion this would then look like:

 * [r123,r125.r127] cleanup whitespace errors

Nothing earth shaking in this release:

• [bf8738f] add --git-tag-only (Closes: #485114)
• [b06bcf0] document git-import-dscs
• [c1deeb2] add epoch to dch call (Closes: #483718)
• [6640ac7] Fix typo (Closes: #484243)

''--git-tag-only'' allows you to create a tag without having to build the whole project again - useful for large packages. You can either clone from:

git clone http://honk.sigxcpu.org/git/git-buildpackage.git/

or fetch the package from the Debian Archive once it went through the new queue. The updated documentation is available here