Hi,
golang-gomega was reported as causing a regression in golang-github-go-redis-redis on s390x. This seems a bit unlikely on the face of it. golang-gomega itself does not have autopkgtests and builds an arch: all package so I ran the build on s390x but it passed. I triggered a test of golang-github-go-redis-redis on s390x in release to see what happens.
There were versions of both and golang-github-tdewolff-parse and golang-github-tdewolff-minify in proposed and it looked like they needed to be tested together, so I triggered that and they both migrated.
golang-github-pkg-errors triggers a regression in golang-github-src-d-gcfg which is a fork of some other go package and oh god why
golang-github-roaringbitmap-roaring was another package that needed the new testify, so I retriggered its tests on all arches. If it migrates, it should be retriggered against some other packages.
I had to take a day of my shift off and the other day also ended up being a bit disrupted so I didn't make as much progress as I would have hoped.
My basic plan was to work on the go packages by scrolling to the bottom of excuses and searching upwards for "debian go packaging team".
I looked at the nomad build failures on armhf and arm64 and got a bit sad.
golang-gomega was reported as causing a regression in golang-github-go-redis-redis on s390x. This seems a bit unlikely on the face of it. golang-gomega itself does not have autopkgtests and builds an arch: all package so I ran the build on s390x but it passed. I triggered a test of golang-github-go-redis-redis on s390x in release to see what happens.
golang-go.uber-atomic reported a regression in golang-go.uber-zap, upstream acknowledges the test is flaky (https://github.com/uber-go/zap/issues/334) so I was going to disable it but then noticed that Andreas fixed it better and his fix had migrated to I retriggered the tests (and on a couple of other packages it had "regressed" against, golang-github-apex-log and golang-github-pkg-errors). golang-go.uber-atomic and golang-github-apex-log migrated.
golang-github-yl2chen-cidranger reported regressions on all arches. It looks like it needs a newer version of golang-github-stretchr-testify-dev. It looks like a new version of that has migrated since the tests ran, so I just retriggered the tests on all architectures. It migrated.
golang-github-yl2chen-cidranger reported regressions on all arches. It looks like it needs a newer version of golang-github-stretchr-testify-dev. It looks like a new version of that has migrated since the tests ran, so I just retriggered the tests on all architectures. It migrated.
golang-yaml.v2 is failing autopkgtests on s390x that was chased down to a compiler bug that is now fixed upstream, so I backported that and uploaded it after doing some testing with a build in my PPA.
golang-github-smira-go-aws-auth is failing with a request to route53 timing out. I suspect this will have regressed in release but will check. If so, I'll make an upload to skip the test.
golang-github-pkg-errors triggers a regression in golang-github-src-d-gcfg which is a fork of some other go package and oh god why
golang-github-miekg-dns fails on armhf. Andreas reported this upstream (https://github.com/miekg/dns/issues/1129) which has a suggestion on it, which I'll try when I've got my build environment set up on my arm64 canonistack node... The suggestion helps but there is another failure as well.
continuity no longer builds the continuity binary package so I filed a bug to get that removed.
golang-github-roaringbitmap-roaring was another package that needed the new testify, so I retriggered its tests on all arches. If it migrates, it should be retriggered against some other packages.
Cheers,
mwh
