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.

Attachment: signature.asc
Description: PGP signature

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reply via email to