Proposed migration report
bryce.harrington at canonical.com
Tue Aug 18 02:10:38 UTC 2020
I was happy to see json-c transition today (and icu this weekend), which
has cleared most of the packages on the server team's update excuses
page. I took a look through the remaining 8 migration items,
retriggered a few things, and peeked into logs. Notes below:
### libiscsi ###
All arch's are build failing on a sync of this package from
Debian. The build is erroring on linking the test code due to
multiple definitions of various symbols.
Since it's last build was a couple weeks ago, I've requested
rebuilds on all architectures.
### golang-goprotobuf ###
autopkgtest regression on all arch's on package sync'd from
Debian. Since last attempt was 3 weeks ago, I retriggered on all
arch's, but expect it'll fail again.
The failure is with a single test case:
panic: mismatching field: got github_com.grpc_ecosystem.grpc_gateway.runtime.errorBody.error, want github_com.grpc_ecosystem.grpc_gateway.runtime.errorBody.message
If it still fails, next step is probably to study the source code
to interpret what this error means. Nothing turned up in google
### nspr (dogtag-pki) ###
nspr's sync from Debian of a new upstream release is stuck due to
regression in dogtag-pki. This looks like it just needs a more
sophisticated trigger, as dogtag-pki seems to depend on several
packages currently in -proposed. I've re-triggered with these
### libqb ###
Only the i386 autopkgtest is failing, and Rafael's been looking into it.
The log shows something about needing gcc:i386, aka usual issue for i386.
### rabbitmq-server ###
Blocked by bunny. This was mentioned by Lucas (iirc) at standup today.
### dnsmasq ###
This is a sync from Debian of a new upstream release. The tests
are failing only for amd64, arm64, and ppc64el. It passes for
some combinations of triggers, but not others, so I've done a more
inclusive retriggering on all archs, with these triggers:
### asterisk ###
This is blocking an alsa-lib transition, but fails only on armhf.
The error in the test log is:
Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)
We've had some flaky armhf results that resolved by re-triggering
the test, and that error message feels like it might be of that
type, so I've retriggered the failed test run as-is. But, it might
need also triggered against the -proposed sqlite3 and alsa-lib.
### rsync ###
Sergio and Christian are working on this merge from Debian, and I
recall they mentioned its tests were failing with dgit. It looks like
a simple retrigger still failed on two test cases, but I wonder if dgit
needs retriggered against the sqlite3 in -proposed as well? I've done
so with these triggers:
A second issue is a regression with diaspora-installer on armhf,
but that looks like yet another connection issue on
armhf ("Resolving squid.internal (squid.internal)... failed:
Temporary failure in name resolution.") I've done a simple
retrigger here. But it might need retriggered also with
ocsigenserver and/or tyxml.
More information about the ubuntu-server