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. IIRC, in the haskell team, the tag signifies "this package has been uploaded and ACCEPTed". in our flow, this is signified by a commit that *only* finalizes the changelog entry, and is pushed when uploading, and merged when accepted. adding a tag to this process (either when uploading, or when merging) would be trivial, since those commits are already machine-generated anyway. we could likely even synthesize them going backwards in history. Fabian
