I've been also half-occupied with meetings this week as part of an
internal Canonical event but I've managed to look at proposed migration
for some of the time at least. On Wednesday I chose to do my SRU shift
instead as I assume this is preferable.
# apport
This looked like it was holding up quite a few migrations so I took a
look. Looks like it assumes a dpkg-divert exists but dash no longer has
one causing an autopkgtest failure. Additionally it FTBFS because of a
change in pylint. I discussed these with bdrung in #ubuntu-devel as I
didn't want to step on toes about choices like using (or not using)
pylint. I wrote the status up in LP: #2028881 and LP: #2028879.
Following discussion and bdrung's suggestions we have a plan and he will
upload (follow from the bugs for details).
# pandas
Newly built six hours ago, autopkgtests not complete yet. Later: pandas
armhf failed and I retriggered. Maybe a spurious network error? But I've
seen the same error in a few other test failures now, so maybe needs
further investigation. Waiting on pandas armhf autopkgtest.
# ocaml-ssl
ocaml-cohttp already rebuilt but dep-wait on ppc64el. Looks resolved by
a rebuild of js-of-ocaml so retried the build. Later: looks like this
worked and excuses is out of date. There's a bunch of about 60 packages
held up on mathcomp-analysis but the only excuse I see is a missing
risc64 build that is now present.
# coq-unimath
missing build on risc64 but still building (up to 12 hours) from rebuild
already submitted.
# rust-block-padding
I didn't really make sense of this. How is a build of
rust-block-buffer-0.9 resulting in a binary
librust-block-buffer-0.9+block-padding-dev that has a versioned binary
dependency on librust-block-padding-0.2+default-dev without a build-dep
on something from rust-block-padding? I could dig deeper but I moved on
for now.
# pytest
This seems to be holding up quite a few packages. python-pytest-flake8
not reproducible on amd64, but looks suspiciously to do with
Build-Depends change in pytest 7.4.0-2. Tried retrigger on
python-pytest-flake8 on armhf to see if the problem still remains.
Later: this succeeded So it seems that failures of this pattern are now
resolved.
I tried:
retry-autopkgtest-regressions -s mantic --blocks pytest --log-regex "module 'py' has no attribute"
However this fails with "You submitted an invalid request: Expecting
value: line 1 column 1 (char 0)" and also even when using the retry
button directly on the xcuses page. Is there an outage or regression
somewhere on autopkgtests.u.c? I asked on #ubuntu-devel.
