2017-06-17 08:18:40 UTC
You may have seen (and even remember!) posts during the preparations for
1.0.27 about using `git` repository info to generate the package version
number for snapshots.
After running in semi-circles, chasing dead ends and barking up a wrong
tree, or two, I'm happy to inform you that the CI builds on GitLab.com
now do. If all you care about is getting a tarball for the latest push
to git (that has reached the GitLab.com mirror!), all you need to do is
wget -O - https://gitlab.com/sane-project/backends/builds/artifacts/master/download?job=archive \
| funzip | tar xzf -
to get an extracted sane-backend-*/ directory.
# The URL gives you a zipped archive of all the CI job's artifacts,
# hence, the pipes.
If you're more of a point-and-click type, point your browser at
and click the download button (see attachment).
The most recent build as of writing has a version number of
That's 24 commits since the annotated 1.0.27 tag (added as an alias of
RELEASE_1_0_27), with a 'g'it commit hash of e7d9779. The '-dirty' bit
is due to uncommitted changes to configure.ac and configure that result
from the way things are implemented at present.
If you like to know what's going on "under the covers" and why things
are done the way they are, then please read on.
My first thought was to use the git-version-gen module of gnulib. It
turned out that gnulib was a *FAT* dependency. Too fat for my liking.
A bit of poking around later, I realized that just pulling the script
from the module would do just fine. Tried that and realized after a
while that the script was WAY over-engineered for what I was trying to
All that's needed is simply changing the second argument to AC_INIT in
m4_esyscmd_s([git describe --dirty])
and run `autoconf -f` whenever you want the version info updated. Now
here's the snag. Running autoconf changes configure which we version
control with git. Doh! Infinite loop.
Since I didn't want to kick the status quo (just yet ;-) about keeping
generated files under version control, I implemented the current support
in the `.gitlab-ci.yml` file. That got a little bit more complicated
than necessary because of the change to a version controlled file but it
works without affecting whatever happens on Alioth.
So then, what does happen on Alioth when the daily snapshots are made?
These snapshots are, unsurprisingly, courtesy of a daily cron job. It
runs something close to
git archive --format=tar master | gzip > sane-backends-$DATE.tar.gz
I've tried to run `make dist` on Alioth. No such luck. That bombs
because the gettext tools are not installed. Also, you cannot run
autoconf on Alioth. It's not installed. So, trying to do this git
repository info based versioning thingy on Alioth is a no-go.
The fact you cannot run `make dist` on Alioth is probably why the daily
snapshots are just `git archive`s, but those archives are not made the
way as our release tarballs. And that bugs me. Maybe I should change
that cron job to pull the tarballs from GitLab.com ...
The git archives can be had from GitLab.com as well, BTW. Just point
your favourite download tool at
Well then, there you have it. We now have tarball snapshots that use
git repository info based versioning on GitLab.com and they are updated
with every push to Alioth shortly after the mirror sync runs on GitLab.
Next thing I would like to do is drop those pesky generated files from
git (perhaps after that daily cronjob starts pulling the snapshots from
GitLab so the unsuspecting user doesn't really notice ;-). Does that
sound like a good idea?
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join