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. > - wine: > https://orig-check.debian.net/orig-check/result/a2f1e53637b4a36179b6b24a825e7a1d94ebf0c6666fc8c9729d0e060584d8c2 > In 10.0~repack-12, debian/copyright was modified to exclude some files > from the repacked orig tarball. But since there wasn't a new upstream > version, the orig tarball was not updated. >... Problems around exclusions could be avoided by only checking whether every file in the Debian sources is also present and identical in the upstream sources. > Lucas cu Adrian
