On 15/03/26 at 21:45 +0100, Salvo Tomaselli wrote: > Hello, > > > Why? Can you point to specific results that you believe are problematic? > > See this, and all the packages in that namespace > > https://salsa.debian.org/qt-kde-team/kde/alligator > > the source is not in salsa, we rely on uscan to download the upstream > tarfile and check the signature. > > I'm not even aware of a field to use to point to the upstream's vcs. > So I don't know how you would implement it in practice, and it's not > clear to me what the tool is trying to compare.
>From the announcement: > It currently includes three checkers: > > 1. upstream2orig: Verifies that the upstream tarball (e.g., .orig.tar.gz) > in Debian is a faithful representation of the original source code > released by upstream developers. so this is unrelated to Vcs-Git, and checks that the upstream tarball in unstable matches what you get with uscan. alligator succeeds: https://debaudit.debian.net/upstream2orig/result/0972f0c4ab32d1edd80c5620daabf62e776d825d97bb17e64878cf993a1013cb > 2. git2dsc: Verifies that the source package built from the Vcs-Git > repository matches the source package currently in the Debian archive. alligator also succeeds here because the orig tarball is taken from the archive: https://debaudit.debian.net/git2dsc/result/0972f0c4ab32d1edd80c5620daabf62e776d825d97bb17e64878cf993a1013cb > 3. git2orig: Verifies that the orig tarball generated from the Vcs-Git > repository matches the orig tarball in the archive. that one fails, and I agree that git2orig should try to identify if the package does not store the upstream source in git, and issue a specific code in that case. > > Are you talking about packages that do not provide a Vcs-Git, or about > > packages that use a Vcs-Git outside salsa (e.g. on GitHub)? > > Both really. > > For the ones without Vcs-Git it should just show nothing I guess The diagnostic code in git2dsc and git2orig is 100 in that case, and the explanation is pretty clear. See e.g. https://debaudit.debian.net/git2dsc/result/957a2a78452116627f6bcdc1fcd0e7e3a17b130822ea1641db39344f01a792cd > for the ones who aren't on salsa they seem to be all failing because > it expects gbp's naming convention for tags I presume. No, it tries various naming conventions until it finds one that fits (but maybe it doesnt try hard enough). A specific example would be nice. An example of a package not hosted on salsa and not failing is bomstrip: https://udd.debian.org/reproducibility/?bomstrip Lucas
