Hi, On 05/02/26 at 17:44 -0700, Sam Hartman wrote: > >>>>> "Lucas" == Lucas Nussbaum <[email protected]> writes: > > Lucas> Hi, I'd like to open a discussion about using > Lucas> https://debaudit.debian.net data to gate testing > Lucas> migrations. The service is quite new, so this would likely > Lucas> need a long testing period, but I guess that it's probably > Lucas> better to open the discussion early. > > Lucas> In short, debaudit currently includes two "checkers" > Lucas> (orig-check and git2dsc). orig-check ensures that the orig > Lucas> tarball in Debian matches upstream's. git2dsc ensures that > Lucas> the Vcs-Git repository matches the Debian source package. > > Lucas> I think that it would make sense to block migration when > Lucas> packages regress (similar to what was implemented for > Lucas> reproducible builds, if I remember correctly) -- that would > Lucas> allow packages that fail in testing to still migrate, while > Lucas> still gradually improving the overall status. > > I'm not convinced we have a consensus that using upstream tarballs is > the best practice. > I agree that we have a consensus that it is a best practice, but I think > that for example repacking an upstream git tag is also a best practice > or other workflows that are more git centered.
The common denominator used by orig-check is the use of debian/watch. Workflows that use git tags and result in tree-same orig tarballs (not bit-identical orig tarballs) are supported by orig-check (but result in "800" diagnostic, not "900" diagnostic), because orig-check tries to "normalize" tarballs before comparing them again if the initial comparison shows that they are not bit-identical. Relevant examples of packages using Git-centric workflows are ktls-utils: https://debaudit.debian.net/orig-check/result/4b519e53da98f6b0ba1ad8b82b83579779b66b57c4f630a8ecb26711255e4d3b and c-evo-dh: https://debaudit.debian.net/orig-check/result/a6fe40a68cbf7715b3c294961fc5537cadf36ebdeea531dd43497c5132951e9d > I don't want to have to get release team permission to get a migration > when I move from one of these best practices to another. I absolutely > support blocking migrations on unintended regressions if the false > positive rate is lower, but I think maintainers should have a way to > indicate a workflow change. I don't think it's a problem in practice. Since orig-check can distinguish between the various cases, we could decide which state transitions require release team approval or not. For example, the current implementation allows moving from bit-identical to three-same. We could also allow moving from "reproducible orig tarball" to "no watch file so no way to check orig tarball". As usual, the problem is drawing a line between things that are most likely unintended regressions and require manual review/acknowledgement, and things that are most likely intended... One case that is difficult to deal with is workflow changes (even minor) outside of new upstream versions. For example, among the current orig-check regressions, there's: - vite: https://orig-check.debian.net/orig-check/result/4506d8769158822444ef829488c2e3107a3844a5d3cad85ef062214d9808ba07 In 1.4-6, the maintainer updated debian/watch to use the tag-based tarball generated by gitlab, while it previously used the manually-generated "release asset" tarball. Since that was done outside of a new upstream release, the tarball used for 1.4-6 does not match the method described in 1.4-6's debian/watch, but rather the method described in 1.4-1's debian/watch. - wine: https://orig-check.debian.net/orig-check/result/a2f1e53637b4a36179b6b24a825e7a1d94ebf0c6666fc8c9729d0e060584d8c2 In 10.0~repack-12, debian/copyright was modified to exclude some files from the repacked orig tarball. But since there wasn't a new upstream version, the orig tarball was not updated. One could argue that the above cases should be fixed by uploading a fake new upstream version (e.g. with a +ds suffix). Others could argue that we don't care and it will be fixed anyway when there will be a new upstream version. Lucas
