On Tue, 10 Feb 2026 at 20:12:43 +0800, Otto Kekäläinen wrote:
I would really like to use tag2upload, but many of my upstreams sign
their releases and tag2upload (->dgit) will recreate those tarballs
and invalidate the signatures.
As I said, if you want to preserve tarball identity/signatures, you
can't use tag2upload for the first upload of a new upstream release, but
you *can* do that first upload using dgit (as long as what's in your git
repo is identical to what ends up in the .dsc).
For example dbus 1.16.2-1 was uploaded by building a source package,
then uploading it with
dgit push-source -C /path/to/*_source.changes
which validates that the result of unpacking the .dsc does correctly
match the git repo (they're said to be "tree-same" in dgit jargon). This
upload did include the upstream detached signature on the .orig tarball
(which in this case also came from me, but it could equally well have
been a co-maintainer).
For the second and subsequent uploads of an upstream release, like dbus
1.16.2-3, you can use tag2upload (and in fact I did), as long as the
first upload has already reached the archive so that tag2upload can see
the pre-existing .orig tarball.
dbus 1.16.2-2 was uploaded with dgit and not tag2upload, but I don't
remember why I did that - it could equally well have been tag2upload.
smcv
