Hi Lucas, On 1/30/26 17:27, Lucas Nussbaum wrote:
I'd like to open a discussion about using https://debaudit.debian.net data to gate testing migrations.
Thank you for providing that service, I think it's a great asset for Debian. However, I've been thinking about this for a while, and I'm not convinced it's right to include this in the migration checks in the near future. Both tools don't really improve what's in the archive. It seems to me that this is better exposed on tracker and similar pages.
In short, debaudit currently includes two "checkers" (orig-check and git2dsc). orig-check ensures that the orig tarball in Debian matches upstream's.
I recall Adrian referred to the same, but uscan and d/watch have been made for a different purpose. Using it like this feels like it needs to be accepted by the Debian community first. Incidentally (as an example), one [1] of the very few packages that I maintain regressed very recently because I switched some time ago to a git based version because upstream appeared to have stopped making releases and suddenly they did. I uploaded as 1.11-1 but expect +git... versions soon again. I didn't care to fix the watch file, also because I feared I would forget again. I don't want to block migrations for cases like this.
I also don't like to depend on real external sources (i.e. services not managed by the Debian community).
git2dsc ensures that the Vcs-Git repository matches the Debian source package.
Also here, I don't want to treat a mismatch, as Simon put it, worse than RC. I *think* what he means is that if an upload to unstable fixes an RC bug, than blocking migration on this would prevent the RC bug from being fixing in testing. I would immediately unblock the migration if I'd noticed. Similarly, we currently treat out-of-sync for more than 30 days as RC; I consider being out of sync much worse than have the repository not being up to date (which at this moment feels like nice-to-have at best to me). So while a delay might be acceptable, a block would not. But, what's more, the bug even isn't in what's uploaded, but elsewhere. It can even be fixed elsewhere (e.g. by pushing the missing pieces). I think influencing migration for that is wrong.
block migration when packages regress (similar to what was implemented for reproducible builds, if I remember correctly)
We're close with reproducible builds, but not there yet (it's only for-info). It's been a process of years.
There are currently 14 source packages that would be blocked because of orig-check regressions, and 32 because of git2dsc regressions.
That's a lot. Normally with new policies the numbers should be better than that.
This is my opinion as a Release Team member at this moment. If the rest of the team thinks it's nice to have, I wouldn't veto even if I could.
Paul[1] https://debaudit.debian.net/orig-check/ type in viking (is there a direct link?)
OpenPGP_signature.asc
Description: OpenPGP digital signature
