On 01/02/26 at 12:08 +0000, Simon McVittie wrote: > On Fri, 30 Jan 2026 at 17:27:25 +0100, Lucas Nussbaum wrote: > > In short, debaudit currently includes two "checkers" (orig-check and > > git2dsc). orig-check ensures that the orig tarball in Debian matches > > upstream's. git2dsc ensures that the Vcs-Git repository matches the > > Debian source package. > > > > I think that it would make sense to block migration when packages > > regress (similar to what was implemented for reproducible builds, if I > > remember correctly) -- that would allow packages that fail in testing to > > still migrate, while still gradually improving the overall status. > > Do you mean *blocking* migration, or do you mean *delaying* migration? I'm > not a release team member, but I think we should be very careful with what > we completely block from migrating: if an issue blocks migration, we're > effectively saying it's "worse than RC". > > I think a key difference between reproducible builds and orig-check is that > reproducible builds usually only regress as a result of changes to either > the package under test or one of its build-dependencies, whereas downloading > software from upstream can easily regress for upstream reasons that are > outside our control. > > And, a key difference between reproducible builds and both of these tools is > that reproducible builds are very careful to "pin" the versions of relevant > packages in use (via the extensive work that has been done on generating and > retaining .buildinfo), whereas these two checks seem to be using the latest > dpkg-source and the latest uscan from unstable?
Currently, yes, debaudit is using the latest dpkg and uscan from unstable. The "normalization" step tries to suppress differences that were introduced in recent dpkg versions. > > I'm not aware of false positives (= AFAIK, regressions are real problems > > that should be fixed). > > It's no longer visible because it has migrated, but at the time I first > looked at this, glib2.0 was showing up as having a git2dsc regression. The > diff appeared to be that the tarball had been generated with a different > version of dpkg, which produced a different (but equally valid!) > representation of build-profiles: one .dsc had profile:v1 (added in dpkg > 1.23.0) and the other did not. > > But I happen to know that for glib2.0/2.86.3-5, what's in git should > correspond exactly to what ended up in the archive, because I uploaded it > using tag2upload, which has that as one of its key design constraints. So > either tag2upload is helping to carry out an extremely subtle attack > (unlikely), or a wrong assumption is being made somewhere. > > I assume that the difference is that tag2upload runs in a stable container > (or possibly in a not-quite-bleeding-edge sid container) when it generates > its .dsc, therefore uses an older dpkg-source than the one that git2dsc uses > to attempt to reproduce the package? And I think that is, and should be, > considered to be valid: it should be equally OK for a maintainer to generate > a .dsc on a stable or testing system, as long as they build and test > binaries on an unstable machine/VM/container/chroot/thing. > > I've seen comments elsewhere saying that it should be considered to be a bug > if a source package can't be successfully built by the latest dpkg-source, > and I think that's valid (albeit possibly a bug in dpkg rather than in the > source package, if dpkg regresses); but that isn't the same as saying that > it's a bug if *the specific source package that was uploaded* wasn't > generated by the latest dpkg-source. > > A possible way to mitigate that class of false positives would be if git2dsc > did this: > > - take the .dsc from the archive, A > - take the .dsc that it produces from git, B > - unpack A > - repack A with the same dpkg-source version that it used for B, to get C > - compare B with C That's a good idea indeed. I will do that, it's actually cleaner than the current normalization step. Lucas
