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
