+1 maintenance report

[Dan Bungert]

+1 Maintenance Report
Dan Bungert, Jul-26-2021 - Jul-30-2021

##### breezy #####

Since Christian's report, Chris MacNaughton stopped by one of the LPs and
pointed to https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1932313 ,
which had some good info.  The recent python change where '.' in sys.path
can cause problems for module loading definitely affects breezy.  I was able to
verify that newer pythons, including main as of Tuesday, do not have this
resolved.  On the python mailing list was a discussion and a test case,
https://www.reportlab.com/ftp/timport-310b1.py
I spent some time cleaning that up but I found in my testing of the reportlab
case that it demonstrates a slightly different bug - their test case changes
from failing with the affected python versions to erratic failure, whereas
breezy seems ok with the good python versions and not erratic.

Suggested next steps are to extract a test case for submission to upstream
matching the breezy scenario, and consider incorporating a workaround like
https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1932313/comments/7

##### delve #####

Delve is failing on a test introduced with a new feature with version 1.6.1,
but only on arm.  I traced backwards thru the failing case (using delve) quite
a bit and eventually found that it was attempting to dump the mappings listed
in smaps, and on which mapping it was failing.  Delve does some filtering to
reduce which mappings get dumped - smaps does have a "dd" flag that is intended
to say "do not include area into core dump", but vvar in this case doesn't have
the flag, and it's working OK on older kernels.  Opened launchpad and upstream
issue with this information.  Upstream is considering also filtering on the
"pf" flag, which is present in the vvar mapping info on the failing kernels.

https://bugs.launchpad.net/ubuntu/+source/delve/+bug/1938474
https://github.com/go-delve/delve/issues/2630

##### ncbi-blast+ vs cct #####

The upstream change to ncbi-blast+ at 2.11 talks about some multithread
changes.  Like ginggs, I could see extended test times on cct (consistently 2x
in my case compared to ncbi-blast+ 2.10) but nowhere close to the extreme that
is seen in official autopkgtests.  I experimented with values of --cpus for
autopkgtest qemu, but didn't find anything interesting there.

ncbi-blast+ 2.12 is out but not yet in Debian.  I did a quick take getting 2.12
ncbi-blast+ packaged to see if that was better, but that failed with some
mbedtls link errors and I lost interest.

##### golang-testify vs golang-github-uber-go-atomic #####

golang-testify 1.6.1-2 had been blocked due to what looked like a test
regresion in go-atomic.  Really it seems to have been go 1.16 related.

The listed test failure in the logs
Error: "missing $GOPATH\n" does not contain
"struct containing nocmp cannot be compared"
was fixed upstream in version 1.8.0 of go-atomic.
https://github.com/uber-go/atomic/issues/82

I was able to get this to migrate by manual construction of retest URLs so that
testify was triggered with go-atomic 1.8.0.  Thanks bdmurrary for retest help.

##### python-xarray #####

I started looking at this and got as far as reproducing the issue, but that's
about it.  Upstream has 0.19 released, maybe that will help?

-Dan