Proposed migration report

Tue Aug 18 20:57:34 UTC 2020

On Mon, Aug 17, 2020 at 07:10:38PM -0700, Bryce Harrington wrote:
> 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.

Same build failures.  Looking further, Debian is also experiencing the
same multiple definition issues:

  https://buildd.debian.org/status/package.php?p=libiscsi
  https://qa.debian.org/excuses.php?package=libiscsi
  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libiscsi.html

It looks like the current -2 version attempting to migrate includes a
fix for a (different) 'multiple defintion' issue, so apparently the fix
was not a complete one?  Guessing it's due to new gcc, and will need a
flag passed to gcc.

But probably next step is to forward the bug upstream.  I've done so
here:

  https://github.com/sahlberg/libiscsi/issues/340

After that's fixed, next would be to ping Debian to get them to pull it,
so we can sync.

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

It still fails.  The merge was uploaded by Balint Reczey, who also
committed the change to Debian's git repo.  I've reached out to him to
see if he is already looking into it.

> ### 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',

This migrated.

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

Rafael investigating.

> ### rabbitmq-server ###
> 
> Blocked by bunny.  This was mentioned by Lucas (iirc) at standup today.

Sergio investigating.

> ### 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',

Looking at the first failing test case (nm.py), it looks like the issue is a
mismatch of its check of `ip address` output:

AssertionError: Regex didn't match:
   'inet6 2600::[0-9a-f:]+/64 scope global (?:tentative )?(?:mngtmpaddr)?(?:noprefixroute )?dynamic'

   not found in:

     """
1:   14: eth42 at veth42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
2:   link/ether ea:56:3f:35:c2:78 brd ff:ff:ff:ff:ff:ff
3:   inet6 2600::11/128 scope global dynamic noprefixroute 
4:   valid_lft 86398sec preferred_lft 86398sec
5:   inet6 2600::39fc:4415:a2e1:fbb6/64 scope global noprefixroute 
6:   valid_lft forever preferred_lft forever
7:   inet6 fe80::6c53:268c:c8f8:40/64 scope link noprefixroute 
8:   valid_lft forever preferred_lft forever
     """

It looks like it was expecting 'dynamic' at the end of the first '/64'
entry (line 5 above, I think?)

There are 9 failed test cases, all of which appear to use the same regex
as above, but with permutations of IPv6 network settings.

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

This migrated

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

Neither of these pokes worked.  Sergio said it's a bug in dgit and is
investigating.

Bryce