Git buildpackage Debian workflow
I use git buildpackage
to wrangle and build all my debian packages. It’s nice and nippy when it works, especially when combined with my sbuild setup. I’ve never dug too deep into functionaliy, but I’m reading the manual a lot at the moment.
An annoying quirk, I have found, is Debian’s unwavering dependence on tarballs for every build activity. I found myself following the wiki, specifically ‘using the upstream repo’ and becoming very frustrated that gbp buildpackage
shouts about needing a tarball.
I’ve been Debian contributing for long enough that I understand why we like the tarballs and pristine-tars, but it rather frustrates me when I have the entire codebase in front of me in a git repo and I can’t just chuck that at sbuild.
Let’s cut some corners - for the project I’m working on, I care first and foremost about making packages work, I’m the ultimate source of truth and we can use the source as we need.
Basic gbp setup
First off, let’s get it running properly.
If I’m sticking with gbp
, I need to make sure it knows about my sbuilder setup. After reading the documents, I divined the following ~/.gbp.conf
[DEFAULT]
builder = sbuild
pristine-tar = False
[buildpackage]
export-dir = ../build-area
tarball-dir = ../tarballs
[dch]
full = True
The key takeaways here are my default builder is sbuild, I’m not desperate to deal with pristine tar and when I build a package, my tarballs and build output go to nice folders which keeps everything clean.
This means that every time I run gbp buildpackage
, it runs sbuild that snapshots the btrfs volume of debian unstable and goes for it.
In each repo I drop the following debian/gbp.conf
:
[DEFAULT]
debian-branch = debian/latest
upstream-branch = upstream/latest
occasionally this requires a git branch -m upstream/latest
when I’m on master
of the upstream repo.
This creates a nice separation of what’s happening upstream and what’s happening in my debian/latest folder. Every major version I’ll rebase debian/latest on upstream/latest and do some patchwork.
Generating a tarball
Now the corner cutting starts:
Sadly, sbuild won’t build without a tar.gz of upstream code, and that must line up pretty closely with what’s going on in debian/latest, so after frustration and reading, I stumbled over git archive
.
I use the following format to generate a tarball in ../tarballs
for me to build against:
git archive --prefix {package}-{version}/ -o ../tarballs/{package}_{version}.orig.tar.gz upstream/latest
.
With that tarball in place, gbp buildpackage
quite happily builds using sbuild.
sbuild btrfs setup
Just follow this, that’s all I did and it works great.
You could not use btrfs and follow sbuild setup from here, but I can’t vouch for it working without btrfs!
If you’re looking to cross build, I once again direct you to my sbuild crossbuild post
Committing to multiple Upstream git repos
Part of this is sharing code outside the debian world, and sharing everything to a new, different repo and that was much easier than I expected.
To add a new remote, I simply ran git remote add github {git repo}
, assuming that you want your remote to be called github.
Whenever I want to push to that, I run git push --all github
and everything shoots off there. Don’t forget git push --tags github
.
Tags: Debian Raspberry Pi