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.
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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
