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

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

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 Adrian,

On 27/02/26 at 18:03 +0200, Adrian Bunk wrote:
> On Wed, Feb 11, 2026 at 01:26:48PM +0100, Lucas Nussbaum wrote:
> > On 06/02/26 at 13:32 +0200, Adrian Bunk wrote:
> > > On Fri, Feb 06, 2026 at 09:40:51AM +0100, Lucas Nussbaum wrote:
> > > >...
> > > > The common denominator used by orig-check is the use of debian/watch.
> > > >...
> > > > One case that is difficult to deal with is workflow changes (even minor)
> > > > outside of new upstream versions. For example, among the current
> > > > orig-check regressions, there's:
> > > > - vite: https://orig-check.debian.net/orig-check/result/4506d8769158822444ef829488c2e3107a3844a5d3cad85ef062214d9808ba07
> > > >   In 1.4-6, the maintainer updated debian/watch to use the tag-based tarball
> > > >   generated by gitlab, while it previously used the manually-generated
> > > >   "release asset" tarball. Since that was done outside of a new upstream
> > > >   release, the tarball used for 1.4-6 does not match the method
> > > >   described in 1.4-6's debian/watch, but rather the method described in
> > > >   1.4-1's debian/watch.
> > > 
> > > Such "regressions" are not rare, given the number of packages in unstable.
> > > 
> > > Paul gave an example of an upstream where no releases were expected with
> > > debian/watch following git commits - but then there was a one-off tarball
> > > release that is now in unstable.
> > > 
> > > It is also very common that debian/watch follows only stable releases,
> > > and it wouldn't be uncommon if a maintainer anyhow decides to upload
> > > an RC version to unstable.
> > > 
> > > A maintainer could also use debian/watch on tarballs only for being
> > > notified about new releases, with the sources in Debian being created
> > > in a different way like from a git tree with submodules in a workflow
> > > without tarballs.
> > > 
> > > debian/watch is simply meant for a different purpose.
> > 
> > I don't think that's true. Of course the historical/original purpose of
> > debian/watch is the detection of new upstream releases, but it has also
> > been used to generate orig tarballs for a long time. This was first used
> > only to download new upstream versions, but even its use to download a
> > specific version is quite common if you look at
> > https://codesearch.debian.net/search?q=uscan.*--download-%28current-%29%3Fversion&literal=0
> 
> "downloading the next version" and "how the current version was 
> downloaded" are identical most of the time, but not always.
> 
> When you start with wanting to block testing migration, then every 
> obscure corner case suddenly becomes relevant.
> 
> > Maybe we need an opt-out mechanism for packages to signal that they only
> > use debian/watch to detect new upstream versions, and that the
> > generation of orig tarballs is done using a different mechanism.
> >...
> 
> What exactly are the use case(s) you have in mind?
> 
> Some upstreams provide only a tarball for the latest version, so 
> everything you are doing might work fine for testing migration but
> it would never be possible to verify it later for a version of that
> package in stable.
> 
> Upstream locations disappearing is not rare.
> 
> Upstream might later provide a tarball with the same name but different 
> contents - every obscure or stupid issue imaginable has already happened
> to some package at some point in time.
> 
> AFAIR there was some talk from reproducible folks about comparing 
> whether different distributions have the same sources, I could see
> possible use cases in that area.

Note that some of the cases you mention would not be affected by
blocking migrations on *regressions*, since they would not be
regressions compared to the current state in testing. (if it's already
failing for the version in testing, for example because the upstream
only provides a tarball for the latest version)

And some other cases which are real regressions are probably worth being
checked manually, such as if the upstream updated the tarball with a
different content.

When I made the suggestion of blocking migration on regressions, it was
obvious to me that this would come with a way to ignore some corner
cases manually (similarly to how it's done for other tests used for
gating migrations).

When I look at the current regressions compared to forky, I see lots of
minor maintainer mistakes such as forgetting to push git tags:
https://debaudit.debian.net/upstream2orig/regressions/forky
https://debaudit.debian.net/git2dsc/regressions/forky
https://debaudit.debian.net/git2orig/regressions/forky
Those are probably worth detecting systematically and fixing.

Maybe I should try to report severity:minor bugs for those problems for
some time (after analyzing each of them), to see what kind of feedback I
get.

Lucas

Back to linux.debian.bugs.dist | Previous | Next — Previous 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