Hi, 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. 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? > - 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. 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? Lucas
