Following the DebConf25 talk by Ian Jackson
tag2upload - upload simply by
pushing a signed git
tag
I decided to use the quiet time during the day of the DayTrip on DebConf 25 to
try out uploading a package using
tag2upload.
Given the current freeze a couple of the packages I maintainer have new
releases waiting. I decided on uploading the new version of labwc to
experimental.
Labwc is a Wayland compositor based on
the wlroots compositor library (the library that
sway is
using). Labwc is inspired by the
Openbox window manager.
The upstream team of Labwc
released version
0.9.0 last week, the first
version that is based on wlroots 0.19.x. Wlroots 0.19.x is also only available
in experimental, so that was a good fit for trying an upload with tag2upload.
I first used my usual workflow, going into my package repository, doing
get fetch origin, checking out the tag of the new release and tagging that
with
git tag upstream/0.9.0. Then I bumped the version in the
debian/experimental branch, adapted the
debian/control file for the changed
wlroots dependency, committed and built the package using
git-buildpackage to
check if it builds fine and there are no lintian errors.
Then I moved on to look at tag2upload.
As a starting point for using tag2upload I read the blogpost by Jonathan Carter
My first tag2upload
upload. It
pointed me to one very important option of
git debpush, namely the
--baredebian option which I have to use because I use the bare Debian git
layout. Given that the last upload of labwc I did was to unstable, I also had
to add the
--force=changed-suite.
I also started right away to use the
--tag-only option, because for my first
tests I only wanted to have local changes and nothing pushed to anywhere.
I also used the
--dry-run option. This led to the following command:
> git debpush --baredebian --force=changed-suite --dry-run --tag-only
tags 0.9.0, upstream/0.9.0 all exist in this repository
tell me which one you want to make an orig.tar from: git deborig --just-print '--version=0.9.0-1' TAG
git-debpush: git-deborig failed; maybe try git-debpush --upstream=TAG
This was a bit confusing, because the error message talked about
git-deborig,
but I was using
git-debpush. I also did not want to make an orig.tar! The
--upstream option in the git-debpush(1)
manual
gave an explanation for this:
When pushing a non-native package, git-debpush needs a tag for the
upstream part of your package.
By default git-debpush asks git-deborig(1), which searches for a
suitable tag based on the upstream version in debian/changelog.
So apparently
git-debpush can not find out what the correct tag for the
upstream version is, because
git-deborig can not find out what the correct
tag for the upstream version is.
git-debpush simply
calls git deborig --just-print --version="$version" in line 437.
This fails because I initially created a second
upstream/0.9.0 to the existing
0.9.0 release tag. I do this for
git-buildpackage to find the upstream sources,
but with multiple tags
git-deborig is not sure which one is the tag it should
use (although both point to the same commit).
So I removed the
upstream/0.9.0 tag and ran
git debpush again and now there
was no error message (besides the warning regarding the changed suite) but it also
did not give an feedback about what is happening. So I tried without the
--dry-run
option. Again, no output whatsoever, other than the warning about the changed
release, BUT my gnupg asked me for permission to sign via my yubikey! And
when I looked at the list of tags, I saw that there is now a
debian/0.9.0-1
tag that was not there before! Looking at the tag I saw that it was a tag in
the format described in the
tag2upload(5)
manual page, containing the following lines:
labwc release 0.9.0-1 for experimental
[dgit distro=debian split --quilt=baredebian]
[dgit please-upload source=labwc version=0.9.0-1 upstream-tag=0.9.0 upstream=4beee3851f75b53afc2e8699c594c0cc222115bd]
and the tag was signed by me. The
4beee3851f75b53afc2e8699c594c0cc222115bd commit
ID is the commit the
0.9.0 tag points to.
Now that I had a signed commit tag in the correct format, I went to the
labwc
packaging repository on salsa and enabled
the webhook to trigger the tag2upload service (I just saw that
the
documentation was updated and there is now
a global webhook on salsa, so this step is not needed anymore).
Finally I pushed the tags using
git push --tags. I could also have used
git-debpush for this step, but I d rather use git directly. I then looked at
the
tag2upload queue and saw how a worker
built and uploaded the newest labwc release and I also got an email from the
tag2upload service
[tag2upload 275] uploaded labwc 0.9.0-1. And a couple of
minutes later I got the confirmation that labwc 0.9.0-1 was accepted into
experimental. Great!
So, to conclude: for tag2upload to work we simply need a git tag in the correct
format. The tag2upload service now gets triggered by every pushed tag on salsa
but only acts on tags that adhere to the
tag2upload(5)
format.
git-debpush is a simply bash script that creates such a tag and by default also
pushes the tag.
I think the script could be a bit more verbose, for example telling me that it
created a tag and the name of that tag. I think the dependency on
git-deborig
is also a problem. I use
git-buildpackage to build my packages and by default
git-buildpacakge assumes upstream tags are of the form upstream/%(version)s
(
source).
I could now change that for all the packages I maintain, but I also think it
makes sense to control the tag myself and not use a tag that is controlled by
upstream. Upstream could change or delete that tag or I might need to create a
tag for a version that is not tagged by upstream.
I also think
git-debpush is a rather mileading command name, given that the
main task of the script is to create a tag in the correct format.
Other than that, I m pretty happy about this service. I have a rather crappy
uplink at home and it is not so uncommon for my uploads to fail because the
connection dropped during
dput. Using a simple git based upload approach
makes these problems a thing of the past. I might look into other ways to
create the needed tag, though.