Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1280398

Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations

Cross-posted to 2 groups.

Show all headers | View raw

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

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-01-30 17:30 +0100
  Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Adrian Bunk <bunk@debian.org> - 2026-01-31 12:50 +0100
    Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-01-31 18:40 +0100
      Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Adrian Bunk <bunk@debian.org> - 2026-02-01 12:40 +0100
        Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-02-01 17:50 +0100
  Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Simon McVittie <smcv@debian.org> - 2026-02-01 13:20 +0100
    Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-02-01 17:50 +0100
      Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-02-02 07:50 +0100
  Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Paul Gevers <elbrus@debian.org> - 2026-02-03 22:10 +0100
  Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Sam Hartman <hartmans@debian.org> - 2026-02-06 02:00 +0100
    Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-02-06 09:50 +0100
      Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Adrian Bunk <bunk@debian.org> - 2026-02-06 12:40 +0100
        Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-02-11 13:30 +0100
          Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Adrian Bunk <bunk@debian.org> - 2026-02-27 17:10 +0100
            Bug#1126685: release.debian.org: Using debaudit.debian.net data to gate testing migrations Lucas Nussbaum <lucas@debian.org> - 2026-03-01 22:10 +0100

csiph-web