I've been looking at this test failure, but remain puzzled. Basically, the source for this test is here: https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429. This test is testing code in https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go which has only two external dependencies (golang-github-docker-distribution-dev) and (golang-github-sirupsen-logrus-dev).
I've checked the build log of the previous build at https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=amd64&ver=20.10.25%2Bdfsg1-2%2Bb3&stamp=1704672923&raw=0 and note that the same test passes in that build. This also uses the same package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and golang-github-sirupsen-logrus-dev==1.9.0-1 I also note that the old build was using golang 1.21, and the FTBFS was introduced after upgrading unstable to golang 1.22. Shengjing, I believe you handled the recent update of the golang toolchain from 1.21 to 1.22. Have you seen similar "mysterious" test failures that resulted from using a newer golang compiler? I am considering just disabling this test, as the rest of the testsuite seem to pass, but I'm getting nervous that this wouldn't just paper over a real issue. Thanks, -- regards, Reinhard
