On Sat, Jan 31, 2026 at 06:31:05PM +0100, Lucas Nussbaum wrote: >... > On 31/01/26 at 13:39 +0200, Adrian Bunk wrote: > > On Fri, Jan 30, 2026 at 05:27:25PM +0100, Lucas Nussbaum wrote: > > >... > > > > > > The current regressions can be browsed on: > > > https://debaudit.debian.net/orig-check/regressions/forky > > > and > > > https://debaudit.debian.net/git2dsc/regressions/forky > > > > > > There are currently 14 source packages that would be blocked because of > > > orig-check regressions, and 32 because of git2dsc regressions. > > > > > > I'm not aware of false positives (= AFAIK, regressions are real problems > > > that should be fixed). > > >... > > > > - 700 - generated dsc differs > > │ -asn1c deb devel unknown arch=any > > │ - asn1c-doc deb doc unknown arch=all > > │ +asn1c deb devel optional arch=any > > │ + asn1c-doc deb doc optional arch=all > > That looks like a false positive? > > What happens here is: > > * asn1c (source) was built on a system with dpkg-dev 1.22.6ubuntu6.5, > according to > > https://buildinfos.debian.net/ftp-master.debian.org/buildinfo/2026/01/30/asn1c_0.9.28+dfsg-6_source.buildinfo > * asn1c dropped its Priority field with that upload > * dpkg-dev issued 'unknown' in that case before dpkg-dev 1.22.12 > (uploaded in January 2025) > > What should we do in that case? I think that it makes sense to require > that source uploads are prepared with a toolchain that generates > packages identical to our current toolchain.
That wouldn't be an easy requirement. Many maintainers (including myself) are not running unstable on the machine where uploads are made from, and there is a diversity of workflows how to create and sign source packages. Running "dpkg-buildpackage -S -nc" on a stable system to create and sign a source package for unstable would not be an exotic setup. I haven't checked how tag2upload is setup, but this is the kind of production service where it would make sense not having to worry about toolchain breakages in unstable. > But there's a normalization step I could use to ignore those > differences if needed. > > > - 290 - uscan did not produce an orig tarball with matching name > > With the same tarball, caused by > > * update watch file to version 5 > > IMHO it would be bad if people were forced to upload "new" upstream > > tarballs for the same upstream code when debian/watch changed. > > I'm not sure. If there's a change in debian/watch that causes a change > in the used upstream tarball, maybe it's worth uploading a fake new > upstream version? The fundamental issue is that debian/watch is for downloading the next upstream version. A maintainer might update debian/watch today for downloading xz instead of gz when upstream announces there will only be xz in the future. Same for the corresponding upstream signing key, we should not ship and trust the revoked one that created the signature in our archive for the current version a decade ago but the one that might sign the next release. I won't touch debian/watch when doing an NMU for an RC bug, even when it points to a long gone upstream location. Your check might make sense on the version where a new upstream tarball is uploaded (which might have been an upload to experimental), but when an upload didn't touch the upstream tarball then it shouldn't be checked. > > - Sid result: 220 - uscan failed -- network error > > Testing migration shouldn't depend on network connectivity to the > > upstream location. > > Assuming it's a transient problem, the maintainer could request a retry > on debaudit. Also debaudit already has a retry policy, that could be > made more aggressive for regressions if that's considered necessary. > > > How will debaudit handle it when an upstream location adds a JavaScript > > Challenge that is not yet supported by uscan? > > debaudit just uses uscan, so it's a wider problem. That's true, but it would move that from a minor annoyance to a blocker for testing migration. > Note that some upstream locations, like GitHub, already do quite > aggressive rate limiting (which is fine for debaudit because it doesn't > perform that many requests). Maybe that rate limiting alone will be enough > to avoid add JS-based challenges? Perhaps for GitHub, but the number of distinct upstream locations in debian/watch is likely 4 digit. salsa.debian.org is an example of an upstream location used in debian/watch of some packages where a JS-based challenge is already in use today, minicom and postgresql-debversion are examples of packages where uscan can no longer download the upstream source of the package in Debian due to that. > Lucas cu Adrian
