Package: dgit-infrastructure
Version: 13.3
Debian tag2upload service writes ("[tag2upload 264] failed,
golang-github-chainguard-dev-clog 1.7.0-2"):
> builder:work$ dgit -wn -pgolang-github-chainguard-dev-clog
> --build-products-dir=../bpd --for-push download-unfetched-origs
> fetching orig file
> http://ftp.debian.org/debian/pool/main/g/golang-github-chainguard-dev-clog/golang-github-chainguard-dev-clog_1.7.0.orig.tar.gz
>
> % Total % Received % Xferd Average Speed Time Time Time
> Current
> Dload Upload Total Spent Left Speed
>
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 260 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
> curl: (22) The requested URL returned error: 404
> dgit: failed command: curl --proto-redir '-all,http,https' -L -f -o
> ../bpd/golang-github-chainguard-dev-clog_1.7.0.orig.tar.gz.tmp --
> http://ftp.debian.org/debian/pool/main/g/golang-github-chainguard-dev-clog/golang-github-chainguard-dev-clog_1.7.0.orig.tar.gz
>
> dgit: error: subprocess failed with error exit status 22
> t2u processor [dgit-repos-server]: failed command: dgit -wn
> -pgolang-github-chainguard-dev-clog --build-products-dir=../bpd --for-push
> download-unfetched-origs
This package was very new so the orig hadn't propagated to mirrors.
This is unavoidable where the .orig can't be made from git by the
oracle. But the oracle could try to regenerate the orig itself, and
see if it got the same one (same sha256). If it did, it could use
that.
I think in many cases, this would work. It would work if the
uploader's workflow for one with the .orig was sufficiently t2u-like.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
