Bug#1068755: docker.io: FTBFS: failing tests
On Mon, 6 May 2024 at 17:00, Cyril Brulebois wrote: > I'm adding Tianon to the loop explicitly since I'm definitely no Docker > (or Go) expert, in case some time can be spared to look into this > problem. Otherwise I'll try and come up with something. I think the backport by Reinhard[1][2] is probably correct/simplest, although definitely a case of "how did this test ever work??" [1]: https://bugs.debian.org/1068755#13 [2]: https://bugs.debian.org/1068755#20 (it might be worth annotating that upstream patch with slightly more DEP3 so it's clear we can just drop it in v23+, though it got backported from v24 in [3]) [3]: https://github.com/moby/moby/pull/45062 ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#1068755: docker.io: FTBFS: failing tests
Hi Santiago, And thanks for the report. Santiago Vila (2024-04-10): > Package: src:docker.io > Version: 20.10.25+dfsg1-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > > === FAIL: distribution/xfer > TestMaxDownloadAttempts/max-attempts=5,_fail_at_6th_attempt (0.88s) > time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (2/5): > simulating download attempt 2/2" > time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (1/5): > simulating download attempt 1/6" > download_test.go:425: assertion failed: expected error "simulating > download attempt 5/6", got "simulating download attempt 6/6" > time="2024-04-10T10:28:42Z" level=info msg="Download failed, retrying (5/5): > simulating download attempt 5/5" > > === FAIL: distribution/xfer TestMaxDownloadAttempts (0.00s) That FTBFS is easily reproducible via cowbuilder (sid, amd64), and also within an unclean, up-to-date devel schroot (still sid, amd64). I'm adding Tianon to the loop explicitly since I'm definitely no Docker (or Go) expert, in case some time can be spared to look into this problem. Otherwise I'll try and come up with something. Thanks for considering! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1068755: docker.io: FTBFS: failing tests
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 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=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=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
Bug#1068755: docker.io: FTBFS: failing tests
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=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=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
