On 16/03/26 at 19:37 +0100, Fabian Grünbichler wrote: > On Mon, Mar 16, 2026, at 8:01 AM, Lucas Nussbaum wrote: > > On 16/03/26 at 00:23 +0100, kpcyrd wrote: > >> Cool project, I also noticed some common error cases (replying to this > >> email > >> to keep the debian-devel@ discussion in one thread): > >> > >> > 290 - uscan did not produce an orig tarball with matching name > >> > >> This seems to be a problem with +dfsg style version suffixes > >> > >> https://debaudit.debian.net/upstream2orig/result/319e02fb7513c475b0c1412bfb63074251403e254b5e1c5d29e0611af45614a3 > > > > This can be avoided by using e.g. > > Dversion-Mangle: s/(\d{2})\.(\d{2})\+dfsg$/$1$2/ > > Oversion-Mangle: s/(\d{2})(\d{2})$/$1.$2+dfsg/ > > as in: > > https://debaudit.debian.net/upstream2orig/result/f8058dc07cdeb8b085b415704541db653ad9e11aafa75af72a3833d10c2892ad > > > > this was found by searching for 'dfsg" in > > https://debaudit.debian.net/upstream2orig/ > > and then filtering on successful results; > > for packages created with recent debcargo, this should already be handled > correctly: > > Filenamemangle: s/.*\/(.*)\/download/taskchampion-$1\.tar\.gz/g > Uversionmangle: s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/ > Dversionmangle: s/@DEB_EXT@//g > Compression: gzip > Repack: yes > Repacksuffix: +dfsg > > creates tarballs via uscan with the expected name > > >> > 720 - archive tarball fully included in generated tarball > >> > >> This is "normal" when excluding files that can't be uploaded to Debian, > >> maybe this should be yellow instead of red? > >> > >> https://debaudit.debian.net/upstream2orig/result/c588756e9a693dc423bacd81fa8f2cf6d6f13af442836747f391267f3d28f717 > > > > It means that the exclusion of such files is not properly automated in > > debian/watch or debian/copyright, but instead done manually(?) > > this is handled correctly by recent debcargo as well, with one caveat - > d/watch > is almost never manually overridden, d/copyright always is - so if you forget > to update the latter with the matching `Files-Excluded` stanza, then uscan and > debcargo might still disagree which files should be excluded. > > I'll see about improving debcargo or the team wrapper scripts to emit a > warning > or error in this case, since it is easy to detect (there is a 1:1 mapping > between debcargo.toml `excludes` and d/watch `Files-Excluded` after all). > > in general, the expected diff between uscan tarballs and debcargo tarballs is > none without repacking (obviously), and some null-bytes at the end with > repacking (uscan removes files with `tar --delete` via mk-origtargz, debcargo > uses Rust tar bindings to create a new archive). > > I've just verified this is the case by updating one of the existing crate > packages with excludes. it will take a while until all the existing, not yet > correct packages are regenerated though, unless somebody in the team runs a > targeted campaign of mass uploads. > > debaudit/upstream2orig was the required "kick in the ass" to fix these issues > on the debcargo side btw, and is much appreciated :) > > >> > 330 - failed to guess tag > >> > >> It seems it's searching for a git tag in > >> https://salsa.debian.org/rust-team/debcargo-conf.git, but this repo only > >> contains configuration for the debian-rust tooling. > >> > >> https://debaudit.debian.net/git2dsc/result/4317d143808217889eeb13c6c0fa5ea0d6c97aab09bb9f308facc028639b27c8 > > > > The Rust team uses Vcs-Git with sub-dirs. In the above case: > > Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git > > [src/ratatui-widgets] > > debaudit correctly handles this, see for example > > > > However the team does not tag releases, so there's no way for debaudit > > to reliably find the relevant commit. > > > > A related case is the Haskell team, that also uses a single repository > > with subdirs, but tags releases, so debaudit works: > > https://debaudit.debian.net/git2dsc/result/455e8bec15cacd42f5f3e6a66a9c9e98d61f40c7bfd925cb7f2369adc75f3e3c > > AFAIR, the haskell team also keeps the full source package in git. we don't, > we only track the input for debcargo (including overridden and additional > contents of the debian/ dir, if needed). we've discussed a few times whether > it > would make sense to keep the full thing in git, also for easier diffing - but > it would require extra handling of generated vs. overridden parts, so we don't > for now. > > unless/until we do, the only way this would work is if git2dsc would call our > ./repackage.sh script with the crate name, which in turn calls debcargo to > create an unpacked source package. AFAICT, just adding tags on our end would > not be enough.
Oh, I did not know the details about debcargo. It goes much further than what I imagined. Very nice. If the Rust team added tags, I would be happy to extend git2dsc with the above workflow (as an additional conditional step before building the source package). Lucas
