Hi all,
I forgot to send my +1 report for my last shift. This was possibly because it was amazingly frustrating, it was in the middle of the ghc/libffi transition and mostly consisted of waiting for riscv and armhf builds to take ages to fail and have to be restarted. But at least those transitions did get completed in the end.
Notes from my 31/8 - 01/9 shift:
I started by looking at the libffi transition.
I saw that ecl was blocked by slime tests failing on armhf and arm64. The slime tests that are failing were the sbcl ones rather than the ecl ones though so I retriggered them with the version of sbcl in groovy-proposed. They passed (and sbcl migrated).
allure ftbfs on riscv64 because, I think haskell-lambdahack failed to build on riscv. Someone has already retried the build 4 hours ago but the last version took 21 hours to build so I'll have to come back to this tomorrow.
I then spent a good long while digging into haskell packages which seemed to have been built out of order and realized that this was why Steve and Gianfranco were talking about getting haskell-gi-harfbuzz out of Debian NEW and into Ubuntu.
glib2.0 ftbfs because of a doc test. It seems that it would build with the version of gtk-doc in unstable, but we've synced gtk-doc from experimental and it doesn't work with that? seb128 sorted this out.
gjs is failing autopkgtests on amd64 with lots of segfaults but it passed when tested with all-proposed=1...
bagel has regressed in release on s390x https://code.launchpad.net/~mwhudson/britney/hints-ubuntu/+merge/390049
I retried the cffi/amd64 test with the ecl from proposed.
Notes from 14/9 - 15/9 shift:
I looked at cl-usocket. The version in proposed actually runs the testsuite now, and this makes connections to internet hosts that are not going to work on our infrastructure. So I filed a MP to force-reset-test this package: https://code.launchpad.net/~mwhudson/britney/hints-ubuntu-cl-usocket/+merge/390651, then I filed a Debian bug http://bugs.debian.org/970345.
I looked at bilibop for too long before finding that Steve had already filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969606
python-biopython tests fail because clustalo segfaults on s390x, which is also why that package fails to build on s390x. It turned out Steve had already looked into this, and it's very strange: it only happens on the buildds, not on more-or-less identically configured canonistack instances.
mksh fails because the build process runs chmod -x when a binary fails the testsuite but still ships it and then the testsuite breaks. I filed debian bug 970268 about this which got fixed, so I synced the fix.
libgraphics-colornames-perl is held in proposed by libcolor-calc-perl failing tests, but the latter ftbfs and has been removed from testing so we should follow along. I filed https://bugs.launchpad.net/ubuntu/+source/libcgi-application-plugin-authorization-perl/+bug/1895489 for this.
I forgot to send my +1 report for my last shift. This was possibly because it was amazingly frustrating, it was in the middle of the ghc/libffi transition and mostly consisted of waiting for riscv and armhf builds to take ages to fail and have to be restarted. But at least those transitions did get completed in the end.
Notes from my 31/8 - 01/9 shift:
I started by looking at the libffi transition.
I saw that ecl was blocked by slime tests failing on armhf and arm64. The slime tests that are failing were the sbcl ones rather than the ecl ones though so I retriggered them with the version of sbcl in groovy-proposed. They passed (and sbcl migrated).
allure ftbfs on riscv64 because, I think haskell-lambdahack failed to build on riscv. Someone has already retried the build 4 hours ago but the last version took 21 hours to build so I'll have to come back to this tomorrow.
I then spent a good long while digging into haskell packages which seemed to have been built out of order and realized that this was why Steve and Gianfranco were talking about getting haskell-gi-harfbuzz out of Debian NEW and into Ubuntu.
glib2.0 ftbfs because of a doc test. It seems that it would build with the version of gtk-doc in unstable, but we've synced gtk-doc from experimental and it doesn't work with that? seb128 sorted this out.
gjs is failing autopkgtests on amd64 with lots of segfaults but it passed when tested with all-proposed=1...
bagel has regressed in release on s390x https://code.launchpad.net/~mwhudson/britney/hints-ubuntu/+merge/390049
I retried the cffi/amd64 test with the ecl from proposed.
Notes from 14/9 - 15/9 shift:
I looked at cl-usocket. The version in proposed actually runs the testsuite now, and this makes connections to internet hosts that are not going to work on our infrastructure. So I filed a MP to force-reset-test this package: https://code.launchpad.net/~mwhudson/britney/hints-ubuntu-cl-usocket/+merge/390651, then I filed a Debian bug http://bugs.debian.org/970345.
I looked at bilibop for too long before finding that Steve had already filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969606
python-biopython tests fail because clustalo segfaults on s390x, which is also why that package fails to build on s390x. It turned out Steve had already looked into this, and it's very strange: it only happens on the buildds, not on more-or-less identically configured canonistack instances.
mksh fails because the build process runs chmod -x when a binary fails the testsuite but still ships it and then the testsuite breaks. I filed debian bug 970268 about this which got fixed, so I synced the fix.
libgraphics-colornames-perl is held in proposed by libcolor-calc-perl failing tests, but the latter ftbfs and has been removed from testing so we should follow along. I filed https://bugs.launchpad.net/ubuntu/+source/libcgi-application-plugin-authorization-perl/+bug/1895489 for this.
acpica-unix fails on s390x and seems pretty broken (initialization fails). It seems upstream does not support big-endian and this is added in a debian patch, so I guess this needs updating.
lintian-brush tests fail on s390x but it seems very likely the problem is really in "ruamel.yaml.clib", a Python C extension library which does not have (afaics) any tests (!).
elpy seems a bit flaky on (at least) s390x, I retried it and after a couple of goes it migrated.
pygalmesh is failing tests on s390x, I investigated a little and filed an upstream bug: https://github.com/nschloe/pygalmesh/issues/111
cp2k fails on armhf and I suspect would also on other 32 bit arches. ginngs filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948909 back in January with no reply about this. Maybe the next +1 person can action the plan there of not building on 32 bit and removing the existing binaries.
minimap2 was failing to build on most architectures (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969596) so I whipped up a simple patch, uploaded it and attached it to the Debian report, which got uploaded so I synced it.
Then Steve pointed me at golang-github-grpc-ecosystem-grpc-gateway which currently ftbfs. It seems that the issue here is that groovy-proposed has moved golang-goprotobuf to the 1.4 series, and this is quite a big change. golang-github-grpc-ecosystem-grpc-gateway does have a "v2" branch upstream that has support for goprotobuf 1.4 but that is not yet released and it's not clear to me when it will be released: https://github.com/grpc-ecosystem/grpc-gateway/issues/1223. Balint says he'll look at this. One option would be to make a golang-goprotobuf13 package that contains the older branch of the protobuf package but well. That's pretty ugly.
Cheers,
mwh
