- Package:
- git-debpush
- Source:
- git-debpush
- Submitter:
- Andrea Pappacoda
- Date:
- 2026-08-09 10:33:02 UTC
- Severity:
- normal
Hi! For a changelog entry like "0~20260423-1", git-deborig currently tries to generate the orig tarball using the 0_20260423, v0_20260423, and upstream/0_20260423 tags. The issue with this is that the "0~" prefix in the changelog is used as the upstream version number is a date, which would sort newer in the case in which upstream changes to a regular version numbering scheme. This means that the upstream tag is actually just "20260423", without the "0_" prefix, and it needs to be manually supplied by the user to generate the tarball. Would it make sense to special case this convention and automatically look for tags without "0_", like it's currently done with the "v" prefix? This question has been prompted by me seeing debaudit failing the git2orig check for android-udev-rules. https://debaudit.debian.net/git2orig/result/411924764aa1f0c09e49ce419a1170b312fba8d2ead740ca2750b86ca60a30c2 Bye!
Andrea Pappacoda writes ("Bug#1139658: git-deborig: should look for tag without 0_ prefix"):
So, just to make sure I have understood correctly:
In this package upstream do make tags, but their tags are named things
like `20260423`. In Debian we have the `0~` for the reasons you
describe. What you ask is for git-deborig to guess this upstream tag
format in this situation.
I think this is probably too unusual to special case. Often such a
0~ means there's no upstream at all.
Instead, I think this should be handled as follows:
* Somewhere in the git tree's debian/ directory there should be a
config file that specifies the tag convention.
* git-deborig (and git-debpush and other tools) should honour it.
Currently both uscan and gbp have separate config files for this.
So, in summary, I think this would be fixed by a fix to #1105759,
CC'd.
Ian.
Hi Ian, Yes. <https://lintian.debian.org/tags/new-package-uses-date-based-version-number.html>. Still, it's nowhere near as common as the "v" prefix for version numbers, so it's fair not to special case this. That makes more sense! I guess you are talking about gbp-import-orig's upstream-vcs-tag option, but I don't get the uscan reference (maybe you mean d/upstream/metadata?). Feel free to close or merge this bug :)
Andrea Pappacoda writes ("Re: Bug#1139658: git-deborig: should look for tag without 0_ prefix"):
That's something subtly broader. That lint covers also cases where
upstream don't make tags at all. TBH, I don't have a strong feeling
about a special case for this, but I think we should focus our efforts
on the general solution:
...
Yes, in gbp, upstream-vcs-tag. Weirdly, gbp import-ref doesn't seem
to support it. (As you know, in our opinion, one should generally not
use gbp-import-orig, common practice in Debian notwithstanding.)
In uscan this is
mode=git
matching-pattern=refs/tags/...
Ian.
Ian Jackson [11/Jun 4:30pm +01] wrote: I think there are probably many similar conventions that would have just as much an argument for being looked for by git-deborig as this 0~ one. It *is* more convenient for people if we support them and they don't have to edit gbp.conf. On the other hand, requiring the user to edit gbp.conf removes ambiguity, and we won't let git-deborig proceed unless the situation is unambiguous anyway. I guess that if someone wanted to encode some of these special cases into git-deborig in a sensible way, we should probably accept those patches, but I working on the gbp.conf support would be a much more fruitful use of time.