I have a Launchpad recipe that looks like this:

# git-build-recipe format 0.4 deb-version {latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}
lp:kvantum master
nest packaging lp:~krisives/kvantum/+git/kvantum-packaging debian master

However, the upstream prefixes the version numbers with a V which causes the packaging process to complain that versions must begin with a number. The author wants to keep his V prefixed tag names.

Other than manually modifying the changelog in my packaging repository is there a way to have the recipe automatically use the {latest-tag} without breaking the build process?


One workaround is to simply make sure that the upstream version part of your package version does start with a digit by inserting one. For example, you could use:

# git-build-recipe format 0.4 deb-version 0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}

Note that this will compare lower than anything you might have already published with your current expansion, however, since for example 0V1 sorts after V1. If you must, you could use an epoch (eg. 1:0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging} to ensure it sorts higher than anything published previously, but this bump is not reversible and so should be avoided if at all possible.

For further information:

I don't see any option in the documentation to do anything with the "latest upstream tag" apart from to embed it in your final version string, nor any other way to grab the upstream version if the tag is the only place upstream declare it. Therefore I think my workaround, or something like it, is your only option at the moment, but we can see if anyone else has any other answers.

If the workaround is not acceptable to you, bug reports against git-build-recipe are welcome including for feature requests to cover new use cases such as this. I can't speak for what the answer will be as to what enhancements would be suitable in general, though. An enhancement to provide a regexp-based substitution inside an expansion might be possible, for example, but would probably need to be implemented in a way that ensures that malicious code cannot be executed on the host running git-build-recipe in the face of an untrusted recipe input. It would probably be best to find agreement in a bug first, before attempting to implement such a feature enhancement.

  • Thanks. Do you know if it's possible to run something in debian/rules like sed to replace the version of the debian/changelog and how that might affect the final deb version of a git-build-recipe? – Kristopher Ives Dec 13 '18 at 19:36
  • It might work as a hack. Binary package versions don't have to match the source package version so you could arrange in debian/rules for at least the binary versions to end up using exactly what you want using sed or other tooling. However this won't help with the source package version, unless Launchpad's pipeline doesn't care that the source package that went in mismatches the source package that came out (which might well be the case). So try it and see! You'll need to ensure that the source package version uploaded to the PPA does change, since otherwise the next upload will be rejected. – Robie Basak Dec 13 '18 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.