Turns out that backporting https://github.com/moby/moby/commit/97921915a801dd82b1f5a70e0a69353539c1e3ae.patch seems to actually make the test pass
I'm not sure why that worked before, but I've pushed a backport of that patch to https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737 to let the salsa pipeline work on it. I plan to make a team-upload tomorrow or later in the week. Please let me know if you have concerns or thoughts on this. Thanks -rt On Sun, May 5, 2024 at 11:20 AM Reinhard Tartler <siret...@gmail.com> wrote: > 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 > -- regards, Reinhard
