Building packages from the Git repository

Table of Contents
Using a separate build dir
Invoking external programs

In order to build a Debian package from the Git repository you use: git-buildpackage. This builds the upstream tarball as will be described below and invokes Debuild to build the package. To use another build command you can use the --git-builder option as described later in the manual but Debuild is nice since it can invoke lintian. During the development phase (when you're either not on the debian-branch or when you have uncommitted changes in your repository) you'll usually use:

git-buildpackage --git-ignore-new

If git-buildpackage doesn't find a valid upstream tarball it will create one by looking at the tag matching the upstream version, if no tag can be found it uses the tip of the current upstream-branch. Any other treeish object to create the upstream tarball from can be given with the --upstream-branch option.

If you want to recreate the original tarball using the additional information from the pristine-tar branch you have to specify the --git-pristine-tar option. This will make sure the upstream tarball matches exactly the one imported. Using this option is the recommended way of recreating the upstream tarball.

Once you're satisfied with the build and want to do a release you commit all your changes and issue:

git-buildpackage --git-tag

This will again build the debian package and tag the final result after extracting the current version from the changelog. If you want GPG signed tags you can use the --git-sign and --git-keyid options. To save typing these option can be specified via the configuration files. You can futhermore change the tag format used when creating tags with the debian-tag option, the default is debian/<version>.


Using a separate build dir

Tools like svn-buildpackage use a separate build-area. To achieve a similar behaviour with git-buildpackage use the --git-export-dir option:

git-buildpackage --git-export-dir=../build-area/

This will export the head of the ecurrent branch to ../build-area/package-version, build the package. If you don't want to export the current branch head you can use --git-export to export any treeish object, here are some examples:

git-buildpackage --git-export-dir=../build-area --git-export=debian/0.4.3
git-buildpackage --git-export-dir=../build-area --git-export=etch
git-buildpackage --git-export-dir=../build-area --git-export=8caed309653d69b7ab440e3d35abc090eb4c6697
git-buildpackage --git-export-dir=../build-area --git-export=INDEX
git-buildpackage --git-export-dir=../build-area --git-export=WC

The special argument INDEX exports the state of the current index which can be used to include staged but uncommitted changes in the build. Whereas the special argument WC exports the current working copy as is.

If you want to default to build in a separate build area you can specify the directory to use in the gbp.conf.

[git-buildpackage]
# use a build area relative to the git repository
export-dir=../build-area
# to use the same build area for all packages use an absolute path:
#export-dir=/home/debian-packages/build-area
git-buildpackage will cleanup the build-area after a successful build. If you want to keep the build tree use --git-dont-purge.


Invoking external programs

Besides the commands for cleaning the package build dir (cleaner and building the package (builder) you can also invoke hooks during the package build: immediately before a build (prebuild, after a succesful build (postbuild) and after creating a tag (posttag). Typical applications are running lintian or pushing changes into a remote repository.


Running lintian

git-buildpackage exports several variables into the posttag's environment (for details see the git-buildpackage(1)). To invoke lintian we need to tell it where to find the changes file:

git-buildpackage --git-postbuild='lintian $GBP_CHANGES_FILE'
To call lintian automatically after each successful build add:
postbuild=lintian $GBP_CHANGES_FILE
to your .gbp.conf.


Pushing into a remote repository

If you want to push your changes automatically after a succesful build and tag you can use git-buildpackage's posttag hook. A very simple invocation would look like this:

git-buildpackage --git-tag --git-posttag="git push && git push --tags"
This assumes you have set up a remote repository to push to in .git/config.

Usually you want to make sure you don't push out any unrelated changes into the remote repository. This is handled by the following hook which only pushes out the created tag to where you pulled from and also forwards the corresponding remote branch to that position:

#!/bin/sh -e
#
# gbp-posttag-push: post tag hook to push out the newly created tag and to
# forward the remote branch to that position

if ! REMOTE=$(git config --get branch."${GBP_BRANCH}".remote); then
    REMOTE=origin
fi

if [ "$GBP_TAG" ]; then
     echo "Pushing $GBP_TAG to $REMOTE"
     git push "$REMOTE" "$GBP_TAG"
else
     echo "GBP_TAG not set."
     exit 1
fi

if [ "$GBP_SHA1" ] && [ "$GBP_BRANCH" ]; then
    git push "$REMOTE" "$GBP_SHA1":"$GBP_BRANCH"
else
    echo "GBP_SHA1 or GBP_BRANCH not set."
    exit 1
fi
echo "done."
GBP_TAG, GBP_SHA1 and GBP_BRANCH are passed to the hook via the environment. To call this hook automatically upon tag creation add:
posttag="gbp-posttag-push"
to your .gbp.conf and make sure gbp-push is somewhere in your $PATH. On Debian systems a more complete example can be found in /usr/share/doc/examples/git-buildpackage/examples/gbp-posttag-push.