Git-buildpackage
This is a pretty thorough tutorial on git-buildpackage with a lot of info. If you just want to quickly have an environment to build a package cleanly and get going look at https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/package_builder/ and apply the role::package::builder on a labs VM |
Using git-buildpackage with source that already has a debian/ directory
(extracted from #Experiments below.)
Initially cloning the git repository from Upstream
- Clone the repository from upstream if it doesn't already exist in Gerrit, e.g. from git.debian.org:
$ cd ~/git/debs/ $ git clone git://git.debian.org/git/pkg-puppet/repo.git
- Set git username/email
$ git config --global user.name "Your Name" $ git config --global user.email you@example.com
- Set up the local branches upstream and pristine-tar from the remote branches (but don't switch to them):
$ git branch upstream origin/upstream $ git branch pristine-tar origin/pristine-tar
- Build a source package:
$ git-buildpackage --git-export-dir=/var/tmp/build-area/packagename -S
- Build the binary packages with Pbuilder:
# pbuilder --basetgz /var/cache/pbuilder/lucid.tgz /var/tmp/build-area/packagename/packagename_version.dsc
Note: Applying role::package::builder on a labs VM will pre-populate a pbuilder/cowbuilder environment for you. Documentation on it is kept up to date at: https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/package_builder/
Making changes and testing snapshot builds
- Make changes to the package files
- Make commits or amended commits (uncommitted changes are not exported to the build directory)
- Build snapshot builds for testing with:
$ git-dch --snapshot $ git-buildpackage --git-export-dir=/var/tmp/build-area/packagename -S # pbuilder --build --basetgz /var/cache/pbuilder/lucid.tgz /var/tmp/build-area/packagename/packagename_version.dsc
Doing a release
When a package is ready to be released, use the following steps:
$ git-dch -R -N version
- Commit the debian/changelog file (or amend a previous commit)
- Build the final source package with --git-tag:
$ git-buildpackage --git-tag --git-export-dir=/var/tmp/build-area/varnish -S
- Build the binaries with Pbuilder as usual
Pushing changes into Gerrit
Push changes for each of the three branches (if applicable): $ git push gerrit master:refs/for/master $ git push gerrit upstream:refs/for/upstream $ git push gerrit pristine-tar:refs/for/pristine-tar
Pushing the repository into Gerrit
You should push any repository with local changes into Gerrit.
- Create a new repository, operations/debs/packagename using the following Gerrit command:
$ ssh username@gerrit.wikimedia.org -p 29418 'gerrit create-project -d "Package packagename" -n operations/debs/packagename -o ldap/ops -p operations/debs'
- Create a new remote called gerrit:
$ git remote add gerrit ssh://username@gerrit.wikimedia.org:29418/operations/debs/packagename
- Push the three local branches (master, upstream and pristine-tar) into the fresh remote repository:
$ git push gerrit --all
How to build a Python deb package using git-buildpackage
First, it might be good to familiarize yourself with git-buildpackage. This manual is actually very helpful: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
Particularly, read the bit about different ways to import packages. The package that you are importing may vary in its own packaging. Do they release tarballs? Are you importing from an upstream git repository? Etc. etc.
Building a python package from a release tarball
I just built python-jsonschema. I'll use it as an example case.
Prep your git repository
Download the release tarball:
wget https://pypi.python.org/packages/source/j/jsonschema/jsonschema-1.1.0.tar.gz
If you don't yet have a repository in gerrit, you'll need to create one:
ssh username@gerrit.wikimedia.org -p 29418 'gerrit create-project -d "Package python-jsonschema" -n operations/debs/python-jsonschema -o ldap/ops -p operations/debs' git remote add gerrit ssh://username@gerrit.wikimedia.org:29418/operations/debs/python-jsonschema
The gerrit repository we just created is empty. Let's start a new one locally.
mkdir -p python-jsonschema cd python-jsonschema git init .
We are importing from a tarball, and not a git repository and git-import-orig wants an empty 'upstream' branch to exist on our repository. See: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#AEN212
git checkout --orphan upstream git commit --allow-empty -m 'Initial upstream branch.' # switch back to master git checkout -f master
NOTE: master will be the name of the git-buildpackage specific 'debian-branch'.
IF you want to use a different branch for this name, you will have to tell
git-buildpackage via a config file, or via the CLI options. git-buildpackage
suggests using master, so we'll stick with it.
Import the tarball
Since we're building a python module, be sure to name the package with the 'python-' prefix. We're also using --pristine-tar as git-buildpackage recommends.
git-import-orig --pristine-tar ../jsonschema-1.1.0.tar.gz What will be the source package name? [jsonschema] python-jsonschema What is the upstream version? [1.1.0] gbp:info: Importing '../jsonschema-1.1.0.tar.gz' to branch 'upstream'... gbp:info: Source package is python-jsonschema gbp:info: Upstream version is 1.1.0 gbp:info: Merging to 'master' Merge made by the 'recursive' strategy. gbp:info: Successfully imported version 1.1.0 of ../jsonschema-1.1.0.tar.gz
Use stdeb to create the debian/ directory
Faidon says not to use stdeb, but it creates a decent debian/ directory that gives a good starting point. You can create your debian/ directory however you like. See python-jsonschema/debian for a decent version of a python package debian/ directory that will use dh_python2.
For our example, we'll use stdeb and then edit the debian/ files and use dh_python2 to build the package.
See: https://pypi.python.org/pypi/stdeb
python setup.py --command-packages=stdeb.command debianize
Since we don't like stdeb's output, follow these instructions to modify debian/ files to work with dh_python2:
http://wiki.debian.org/Python/TransitionToDHPython2
In summary:
Changes in small were not relevant when I tried this valhallasw (talk) 20:04, 9 May 2015 (UTC)
- changelog:
- Change maintainer to you.
- Change changelog message to 'Initial release.'
- compat:
- change to 8
- control:
- Change maintainer to you.
- debhelper (>= 8)
- remove python-support from Build-Depends
- Add python (>= 2.6.6-3~) to Build-Depends
- Put relevant dependencies (from setup.py / requirements.txt) in Depends
- Change Standards-Version to 3.9.3
- Remove XB-Python-Version
- Modify description to remove any special formatting (markdown, etc.)
- python-<package-name>.preinst
- remove this file completely.
- rules
- remove comments about stdeb
- remove unexports
- remove export DH_OPTIONS
- add --with python2 to dh command:
dh $@ --with python2
- source/format
- change to 3.0 (quilt)
Add the debian/ directory to git:
git add debian git commit -m 'Initial deb packaging'
Build the package
Now try to build the package, yay!
mkdir -p ../build-area/python-jsonschema git-buildpackage --git-export-dir=../build-area/python-jsonschema
Check to see that the .deb looks like it should:
dpkg -c ../build-area/python-jsonschema/*.deb
If that looks good, push everything to gerrit, minus your most recent commit (that one needs review).
Push to gerrit for review
Directly push the upstream and pristine-tar branches, those don't need review:
git push gerrit upstream git push gerrit pristine-tar
Directly push everything in master except for the commit in which you added the debian/ directory:
git push gerrit HEAD~1:refs/heads/master
Finally git-review (or whatever) to push the last unpushed commit for review:
git review
Add the reviewed package to apt.wikmedia.org
Once your review has been approved and merge, copy the files in build-area/python-jsonschema to carbon, and add the .changes file with reprepro. We need to add the --ignore=wrongdistribution flag, since we didn't build the package with a special wikimedia distribution name.
reprepro --ignore=wrongdistribution -C main include precise-wikimedia jsonschema_1.1.0-1_amd64.changes
Building a python package from an existing git repository
Based on [1]
$ git clone https://github.com/sripathikrishnan/redis-rdb-tools
$ cd redis-rdb-tools
$ vim .git/config
# hack out the branch "master" upstream tracking
# upstream doesn't have tags, hack these in
$ git reset --hard d2792069291484af1d9d64abd849aaa44ddf6211
$ git tag upstream/0.1.6
then follow the instructions above from 'Use stdeb to create the debian/ directory'.
Ottomata TODO: understand and write this section.
FAQ
You might have dpkg-source complains about local change. You can get them ignore by editing debian/source/options and add the file to ignore list:
$ cat debian/source/options extend-diff-ignore = '^\.gitreview$'
Reference: http://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourceopt
Experiments
Mark is experimenting with building puppet using git-buildpackage, in labs.
On i-00000080:
- The debian puppet package git repository was cloned into ~/git/debs/puppet:
$ cd ~/git/debs/ $ git clone git://git.debian.org/git/pkg-puppet/puppet.git
- Package build was attempted with git-buildpackage --git-ignore-new --git-pristine-tar
- Signing the package failed, as the Debian maintainer's secret key is not available.
- Package build was attempted without signing:
$ git-buildpackage --git-ignore-new --git-pristine-tar -us -uc
- This worked. We ended up with built packages in ~/git/debs, and a dirty git working dir.
- The git working directory was made clean again, and another build was attempted using
$ git-buildpackage --git-ignore-new --git-pristine-tar -us -uc --git-export-dir=/var/tmp/build-area/puppet
- This worked as well. Packages were being built, and the git working dir remained clean. Packages ended up in the build dir.
- The debian git dir only had version 2.7.6, but we want 2.7.7rc2. So I tried importing the dev release with
$ git-import-orig /tmp/puppet-2.7.7rc2.tar.gz
- This failed, as there was no local upstream branch in the cloned git repository yet. Ok, so let's create it from origin/upstream:
$ git branch upstream origin/upstream
- Now the import worked. But commits were made, with the default git name/mail address. Do set it:
$ git config --global user.name "Your Name" $ git config --global user.email you@example.com
- Try another build.
$ git-buildpackage --git-ignore-new --git-pristine-tar -us -uc --git-export-dir=/var/tmp/build-area/puppet
- Oops. This used version 2.7.6. But, the git-buildpackage manual says changing the changelog itself all the time isn't a good idea. Let's try git-dch:
$ git-dch --snapshot Changelog has been prepared for snapshot #1 at 48473567008ad82cdb0d0a5654dffe7c868fad91
$ git diff diff --git a/debian/changelog b/debian/changelog index 796b61e..f6da810 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +puppet (2.7.6-1ubuntu1~1.gbp484735) UNRELEASED; urgency=low + + ** SNAPSHOT build @48473567008ad82cdb0d0a5654dffe7c868fad91 ** + + * Imported Upstream version 2.7.7rc2 + + -- Mark Bergsma <mark@i-00000080.pmtpa.wmflabs> Wed, 23 Nov 2011 14:06:45 +0000 +
- Cool, but not quite what I need. There was no commit, so let's simply revert that, and try again after reading the git-dch manual:
$ git checkout debian/changelog $ git-dch --snapshot -N 2.7.6+2.7.7rc2 --git-author
$ git diff diff --git a/debian/changelog b/debian/changelog index 796b61e..06a9cac 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +puppet (2.7.6+2.7.7rc2~1.gbp484735) UNRELEASED; urgency=low + + ** SNAPSHOT build @48473567008ad82cdb0d0a5654dffe7c868fad91 ** + + * Imported Upstream version 2.7.7rc2 + + -- Mark Bergsma <mark@wikimedia.org> Wed, 23 Nov 2011 14:23:22 +0000 +
- Now let's try a new build:
$ git-buildpackage --git-ignore-new --git-pristine-tar -us -uc --git-export-dir=/var/tmp/build-area/puppet
- Whoops. It built 2.7.6 instead. Probably because it exported HEAD into the build area. Let's see what it does within the git repository.
$ git-buildpackage --git-ignore-new --git-pristine-tar -us -uc
- So that worked. Hmm, inconsistent. :( I guess we could choose not to care about version numbers for snapshots, and only care about them for releases.
experiment build mathoid debian package on vagrant and publish to ppa =
The result https://launchpad.net/~physikerwelt/+archive/ubuntu/mathoid/+packages
sudo apt-get install git-buildpackage sudo apt-get install libdistro-info-perl
without the libdistro-info-perl the changes between the last release could not be calculated
cd
it does not work in a folder that is mounted to the windows host machine (i.e. /vagrant/srv/mathoid can not be used)
mkdir container ls cd container/ git clone https://github.com/physikerwelt/mathoid-server cd mathoid-server/ npm install git-dch -R -N 0.2.8 git commit -a -m "Update debian release notes" sudo apt-get install dh-make sudo apt-get install gnupg2 gpg2 --gen-key apt-get install haveged
this command was executed in a second terminal window because it was hard to generate entropy
gpg2 --send-keys --keyserver=keyserver.ubuntu.com 7271B791 vi test.msg
you get an encrypted email that contains a link that you have to click... you need to find some way to read the contents... probably there is also a plugin for the gmail webui... but I could not find it
gpg -d test.msg rm test.msg git-buildpackage --git-tag -S -k7271B791
normally the k argument should not be required
sudo apt-get install dput dput ppa:physikerwelt/mathoid ../mathoid_0.2.8_source.changes git push origin debian/0.2.8