Ian Jackson <[email protected]> writes: > "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.
Right. I use 'gbp import-orig --uscan' to import new upstreams. Arguably the Go team default debian/gbp.conf should include upstream-vcs-tag = v%(version%~%-)s and things would be better. We realized this and changed some packages, but most doesn't have it: https://lists.debian.org/debian-go/2025/11/msg00028.html > 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. This is becaues of .gitattributes. The file exists upstream: https://github.com/smallstep/certificates/blob/v0.29.0/.VERSION It exists in the Debian branch: https://salsa.debian.org/go-team/packages/golang-github-smallstep-certificates/-/blob/debian/0.29.0-1/.VERSION?ref_type=tags It exists in the Debian upstream branch: https://salsa.debian.org/go-team/packages/golang-github-smallstep-certificates/-/blob/upstream/0.29.0/.VERSION?ref_type=tags This is because the package uses a default debian/watch like this: https://salsa.debian.org/go-team/packages/golang-github-smallstep-certificates/-/blob/debian/latest/debian/watch?ref_type=heads Which uses the upstream git-archive sources, which were created with .gitattributes support. Upstream git-archive sources published on GitHub respects .gitattributes and performs the version substitution. Possibly the debian/watch file should check out sources from git instead. But not respecting .gitattributes could make things not build at all, or even introduce a vulnerability. > Maybe you want to add that to your set of bodges. *sigh* > (Who can say if a .VERSION file would affect the build output.) Indeed, not respecting .gitattributes here could introduce a vulnerability. So could respecting .gitattributes. Maybe this have to be tuneable by the maintainer, who can make an informed choice. > 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. While I have stopped being a supporter of pristine-tar (I'm now neutral on it -- it doesn't seem to add any significant advantage, and it comes with complexity costs) maybe this will change my mind again. /Simon
signature.asc
Description: PGP signature
