Building packages from the &git; repository
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 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;
If &git-buildpackage; doesn't find a valid upstream tarball it will
create one by looking at the tag matching the upstream version. To change
this behaviour see the option.
If you want to recreate the original tarball using the additional
information from the you have to
specify the 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;
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 and
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
option, the default is debian/<version>.Using a separate build dirTools like &svn-buildpackage; use a separate build-area. To achieve a similar behaviour
with &git-buildpackage; use the option:
&git-buildpackage; =../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
to export any treeish object, here are some
examples:
&git-buildpackage; =../build-area =debian/0.4.3
&git-buildpackage; =../build-area =etch
&git-buildpackage; =../build-area =8caed309653d69b7ab440e3d35abc090eb4c6697
&git-buildpackage; =../build-area =INDEX
&git-buildpackage; =../build-area =WCThe 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
() and building the package
() you can also invoke hooks during the package
build: immediately before a build (),
after a successful build () and after
creating a tag (). Typical applications are running
lintian or pushing changes into a remote
repository.
Running lintian&git-buildpackage; exports several variables into the
's environment (for details see the ).
To invoke &lintian; we need to tell it where to find the changes file:
git-buildpackage ='lintian $GBP_CHANGES_FILE'
To call &lintian; automatically after each successful build add:
=lintian $GBP_CHANGES_FILE
to your .gbp.conf.
Pushing into a remote repositoryIf you want to push your changes automatically after a successful build and tag
you can use &git-buildpackage;'s posttag hook. A very simple invocation would look like this:
git-buildpackage ="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:
="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.
Working with patches
You can use &gbp-pq; to handle patches. See
for an example workflow.
In order to avoid a patched (unclean) source tree after the build you
can use &dpkg-source;'s option and
tell &git; to ignore the .pc directory.
/usr/share/doc/examples/git-buildpackage/examples/gbp-config-unpatched-source
sets up these two files for you.