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?
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
And, as with other "every package in git" initiatives like dgit and
tag2upload, I think that if we are pushing to get every package in git
with upstream source code included, we will need a mechanism to make
exceptions for very large data packages like 0ad-data, where this
treatment probably doesn't make sense and would cost a disproportionate
amount of processing time.
smcv
