On 01/02/26 at 13:28 +0200, Adrian Bunk wrote: > 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.
Note that in that case, dpkg-dev/stable would have have been fine. > 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. I suppose that things will converge to a state where some URLs will be blocked by JS-based challenges, and some others will not (but remain subject to rate-limiting). I suppose that the URLs typically used by uscan will fall in the second category. Lucas
