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

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

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

Cross-posted to 2 groups.

Show all headers | View raw

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

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