On 07/01/26 at 19:48 +0000, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Include git commit id and git tree id in
> *.changes files when uploading? [and 1 more messages]"):
> > The third line is the interesting one. Some examples are caused by
> > repacking, like
> > https://debaudit.debian.net/orig-check/result/0b67b4adc5a7fa1b898a29b025e1ac7b9decee8edb666033a4112a64665ba404
> > Detailed list for those 143 packages is available at
> > https://people.debian.org/~lucas/t2u_wrong_commit.txt
>
> I confess I'm not entirely sure what I'm seeing here.
>
> I think you're saying that these are the packages where the commitid
> embedded in the .orig (which we think came from t2u) is not the same
> commitid as the one reported by uscan.
Yes, it's about the commit ids embedded in both tarballs.
> "700 - tarballs not identical" is more exciting. It's expected when
> we see "+ds1" etc., but otherwise, I would think it anomalous if the
> maintainer had adopted a git-first workflow. I looked at one from
> your list roughly at random:
> golang-github-smallstep-certificates 0.29.0-1
> The t2u log for that says that it reused an orig from the archive:
> downloading golang-github-smallstep-certificates_0.29.0.orig.tar.xz...
> # using existing orig(s)
> Tracker says that there was 0.29.0-1~exp0 in experimental first.
> That seesm to be where the orig came from. That was also a t2u
> upload, where we see:
> # no orig(s) in archive, generating
> + git deborig 916322e730d9671d709ed8962aec21af04054a72
> # created orig
>
> 916322e730d9671d709ed8962aec21af04054a72 is a commit by the Debian
> maintainer titled "New upstream version 0.29.0". I looked at the
> history and it seems like the Debian git history contains *some* of
> the upstream git history, but debian/29.0-01 is not a descendant of
> the upstream v0.29.0 tag (which I got from github). So the Debian
> history is *partly* based on upstream somehow.
>
> The only difference betwen the trees is a .VERSION file. It must have
> been introduced by whatever tool the maintainer used to import the
> tarball.
That .VERSION file is in the upstream git repo:
https://github.com/smallstep/certificates/blob/v0.29.0/.VERSION
According to
https://debaudit.debian.net/orig-check/result/70c397652ea4a15a59047cc550f1fa8fc0eee102c34aba0546351b1915093700
the problem is that the upstream tarball includes a 'debian' directory,
that was probably manually cleaned up by the maintainer. If that cleanup
was encoded as a repacking operation by uscan (or gbp) then orig-check
would not complain.
> This is all very interesting. You are definitely selling me on the
> thesis that pristine-tar support in tag2upload being would be helpful
> to this kind of audit, rather than a hindrance.
I think that it also shows that we have actually three classes of
workflows, with different properties: traditional ones, pure t2u, and
the hybrid ones where packaging work is done with traditional tools but
the upload is done with t2u.
Lucas
