Please consider the following before touching code: What happened where was that I push the limits of tag2upload a bit, in particular:
1) I did 'git-debpush' for a NEW upload, causing something not in the Debian archive at all to show up on dgit, but the source-ful upload from tag2upload succeding on your side but failing on the upload queue side. I upload my amd64 build at the same time as I do the git-debpush, and since gbp defaults to *.gz and tag2upload defaults to *.xz there is no filename clash in the upload, so my amd64 upload "wins" and the source-only upload gets discarded eventually. 2) This package was ACCEPTED by ftp-masters into the archive, and BEFORE the orig.tar file appeared on deb.debian.org etc I did a source-only -2 upload of the package. That failed below, and I was somewhat ready for this to fail, because I wanted to see how things behaved in this situation. So maybe you want to change something, but I'm not convinced that it is really necessary. It may be okay to treat this as "user confused, move along". I'm not even sure what you could actually do better? The problem in 2) is a race condition where I tag2upload'ed before the orig.tar was available. Is it possible for your queue daemon to notice this situation, and just re-try 6 hours later? Re 1) I have used this a couple of times now. It leads to things not in the archive showing up on browse.dgit.debian.org. This is open for abuse, any DD could start to spam Salsa with millions of git repos and valid tag2upload signed tags, and you would import all of it. I have been hoping you wouldn't notice, or care, because I find the ability to make a immutable (sort of) record of the -1 NEW upload in dgit useful. /Simon Sean Whitton <[email protected]> writes: > Package: dgit > X-debbugs-cc: Simon Josefsson <[email protected]> > > Hello, > > On Tue 25 Nov 2025 at 09:30am GMT, Debian tag2upload service wrote: > >> 1 orig file(s) could not be obtained >> # some orig(s) not available from archive mirrors, trying to regenerate >> + git deborig 93faf6e94766a092d1dd34aa889d83aace52116d >> # created orig >> sha256sum: golang-github-package-url-packageurl-go_0.1.3.orig.tar.gz: No such >> file or directory >> golang-github-package-url-packageurl-go_0.1.3.orig.tar.gz: FAILED open or >> read >> sha256sum: WARNING: 1 listed file could not be read >> t2u processor [dgit-repos-server]: failed command: tag2upload-obtain-origs >> p=golang-github-package-url-packageurl-go v=0.1.3-2 s=unstable >> u=93faf6e94766a092d1dd34aa889d83aace52116d > > I would guess what happened here is that git-deborig made a .tar.xz but > tag2upload-obtain-origs was expecting to find a .tar.gz so it failed. > > git-deborig doesn't have a way to force .gz compression so I think we > need to give it a new option to do that. > > Ian, I'll add that to git-deborig, perhaps you could handle the changes > to tag2upload-obtain-origs?
signature.asc
Description: PGP signature
