Proposed migration report

[Bryce Harrington]

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
for me.


### 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
triggers:

        'dogtag-pki': '10.9.1-2',
        'freeipa-healthcheck': '0.6-1',
        'tomcatjss': '7.5.0-1',
        'jss': '4.7.2-1',
        'tomcat9': '9.0.37-3',
        'nspr': '2:4.27-1',


### 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:

        'network-manager': '1.26.0-1ubuntu1',
        'isc-dhcp': '4.4.1-2.1ubuntu9',
        'linux': '5.8.0-16.17',
        'linux-signed': '5.8.0-16.17',
        'linux-meta': '5.8.0.16.18',


### 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:

        'sqlite3': '3.33.0-1',
        'rsync': '3.2.3-1ubuntu1',

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.


Bryce