No longer add linuxcnc.org APT repo for unstable and bookworm builds
and add override to debian/configure and update-dch-from-git to get
sid/bookworms building until <URL: https://bugs.debian.org/1008735 > is
fixed.
Now that we've renamed our debian package to "linuxcnc", we no longer
need to maintain version number consistency with the old "emc2" packages.
We're going to keep the human-readable part of the version number
consistent with the old scheme, but we're going to drop the "1:" prefix,
it was a work-around for a version numbering bug back at the beginning
of time.
This commit does these things:
* Add a small shell library called githelper.sh, which reads a bunch
of info from git and makes it available as environment variables
in the caller.
* Add a script called version-is-release, which checks to see if
the current version (HEAD) has a signed release tag pointing to it.
* Update update-dch-from-git and get-version-from-git to use the
new githelper library, for consistency.
This amends commit 7e8dbfd6f0, changing
the debian version number again. 7e8dbfd changed the debian version
number to be valid, but broke automatic upgrades: the new debian version
numbers had a + instead of a -, so the new numbers sorted as older than
the old numbers.
This changes the + to another ., which is valid and makes the version
number sort come out right.
Before this commit, we had debian version numbers like this:
<MostRecentTag>-<CommitsSinceThen>-g<GitHash>
In pre-releases (such as "2.5.0-pre1"), the "-" was replaced with "~",
so it would sort as younger than the actual release (such as "2.5.0").
An example version number is: 2.5.0~pre1-537-g3748da4
After this commit, we will have debian version numbers like this:
<MostRecentTag>+<CommitsSinceThen>.g<GitHash>
Again with the "-" replaced with "~".
An example version number is: 2.5.0~pre1+538.g08d3fe2
Rationale:
We have a "native" debian package: a piece of software that's distributed
with its own debian packaging setup.
Debian version numbers are governed by the Debian Policy Manual. Section
5.6.12 of version 3.8.4.0 (and other sections of earlier versions, going
back to the very beginning I think) specify that native debian packages
may not contain the "-" (dash) character in their version numbers.
The dash character is normally used to separate the upstream version
number from the debian packaging version number, and as a native package
we have no such division.
Details here:
<http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version>
Sane humans always work in the branch they currently have checked out
(ie, in the branch specified by .git/HEAD).
The buildbot, in contrast, is insane, and always works in the branch
"master", but with the working tree "git reset --hard" to the commit
it's building.
Thus for the buildbot's sake you need to pass the current branch in to
the tools that end up calling git describe.
This commit also makes debian/update-dch-from-git check for success or
failure of the get-version-from-git script.
This commit splits the debian/update-dch-from-git script, factoring
out the code that determines the version, leaving behind the code that
updates the changelog.
This way the version information can be used to overwrite the VERSION
file, and generally be useful elsewhere.
When the release manager releases, they manually update the
debian/changelog with the changes and the new version number. They also
tag the tree at that point with the version number.
This commit makes that update-dch-from-git script detect this condition
and *not* prepend anything to the changelog.
The buildbot interface to git does not record what branch it's working on
in the repo itself, so this info needs to be supplied from the outside,
via the commandline.
"git describe" shows the most recent (timewise) tag in the history.
When we merge a branch that has tags into another branch, for example
merging 2.4 into master, the tags from both branches get searched by
git-describe.
Since we use tags to make the version numbers of our debian packages,
this can lead to incorrect debian versions. Debs in the master repos are
always builds of the master branch, but they sometimes would incorrectly
claim to be 2.4 debs.... Debs in the 2.4 repos are always builds of the
2.4 branch, and they always have correct 2.4 version numbers (since we
haven't merged any branch with tags into 2.4 yet).
This commit fixes the way we run git-describe so it only searches for
tags appropriate for the current branch.
