#1139658 git-deborig: should look for tag without 0_ prefix

#1139658#5
Date:
2026-06-10 18:23:10 UTC
From:
To:
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!

#1139658#10
Date:
2026-06-10 18:39:19 UTC
From:
To:
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.

#1139658#15
Date:
2026-06-11 15:20:51 UTC
From:
To:
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 :)

#1139658#20
Date:
2026-06-11 15:30:10 UTC
From:
To:
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.

#1139658#25
Date:
2026-08-09 10:24:05 UTC
From:
To:
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.