+1 maintenance report

[Bryce Harrington]

### golang-* ###

Since there's a lot of golang-* packages I made that my main focus for
the week, and made some progress.

* golang-github-grpc-ecosystem-grpc-gateway
  - One test case was broken because it uses deprecated code and
    unstable API.  Easiest to just skip the test.
  - The other test case breakage was causing a 'panic'.  I found an
    upstream fix for that, but this enabled more tests to run and more
    test failures.
  - I filed bug LP: #1897179 with my patches if anyone wants to carry it
    forward from here.  There might be existing fixes upstream for the
    remaining test failures.
  - However time might be better invested merging and testing a newer
    upstream release (1.5.x maybe?), and/or the unreleased v2 branch.

* These just needed re-triggered against current archive:
  - golang-github-willf-bitset: Passed migration
  - golang-github-armon-go-metrics: Passed migration
  - golang-github-marten-seemann-qpack: Passed migration

* golang-golang-x-exp:  I think this might need this patch:
  https://github.com/golang/exp/commit/7c80518d1cc79ffde9e571fe4fd281f321d36200

* These are blocked on i386 because of dependency on other packages not
  installable on i386:
  - golang-github-fernet-fernet-go
  - golang-github-rakyll-statik

There's a dozen more golang packages waiting on each other or stuck for
other reasons.


### heat / python-oslo ###

There was a cluster of migration issues around heat and the
python-oslo.* packages.  These are now mostly all resolved.

* I cleared a lot of these with some customized re-triggers:
  - python-troveclient: Passed migration
  - python-cinderclient: Passed migration
  - python-oslo.cache: Passed migration
  - python-oslo.config: Passed migration
  - python-oslo.context: Passed migration
  - python3-oslo.serialization: Passed migration
  - python-osprofiler: Passed migration

The last two were failing due to an expired (25 sec) timeout starting up
the heat daemon.  Since they passed on re-trigger I'm guessing it was
just a random timing issue.  However, I'm also assuming these will occur
off and on in the future.

While investigating, I also noticed an error in the timeout handling
that was preventing the error log from getting displayed in the test
results.  I uploaded a fix, and sent an MP:

  https://code.launchpad.net/~bryce/ubuntu/+source/heat/+git/heat/+merge/391390

The build won't finish before my EOW and won't know if the oslo/heat
package troubles will persist or resolve, so next +1 maintenance person
my need to pick it up from here.  But hopefully the error log fix will
ensure there's some better details for diagnosis.


### pygalmesh ###

I opened an update-excuse bug (LP: #1897338) on this, with a link to the
upstream bug report that Michael Hudston-Doyle filed when he looked at
this a couple weeks ago.  Probably needs someone on s390x to do some gdb
work to figure out what the failure is.


### osmo-sgsn ###

After updating to newer gcc, this is failing on a warning being treated
as an error, for code that it thinks may have a null pointer deref.  The
fix for this is to check the return from gprs_subscr_get_or_create() for
NULL and then... maybe warn & bail?  That implies all users of
gprs_subscr_get_or_create_by_mmctx() will need to test for NULL too.  I
see that the issue is still relevant to upstream's current codebase, so
a next action might be to report it to them.

Note we're several versions behind upstream here.  I don't think
updating to a newer version would solve this bug, but from the upstream
git changelog there's lots of fixes.  Might make more sense to try
merging a newer version from upstream before investing too much time
fixing CI issues.


### ruby-joiner ###

After retriggering with a more complete set of dependencies, this
passed, however it still is blocked from migrating due to rails.


### ruby-http-parser ###

Has some sort of dependency issue on s390x with ruby-http.  It's been
stuck in proposed-migration with this issue since April.  I couldn't
make headway on it, but I think a good next-action might be to open a
bug report where we can start accumulating analysis.


### securefs ###

This is hitting an error with a too-long filename on amd64 in a getattr
operation, which triggers some exceptions.  This failure has been going
on for a few releases.

* I found a couple similar-sounding issues upstream but I don't think
  they're the same as this:
  - https://github.com/netheril96/securefs/issues/82
  - https://github.com/netheril96/securefs/issues/84


### lintian-brush ###

Michael had said, "lintian-brush tests fail on s390x but it seems very
likely the problem is really in "ruamel.yaml.clib", a Python C extension
library which does not have (afaics) any tests (!)."

There aren't any relevant bugs or changes in upstream for either
lintian-brush or ruamel.yaml.clib.  The issue doesn't reproduce on amd64
unfortunately.

Next action for this would be to try to reproduce on s390x.  The test
case is pretty simple, and it looks like maybe ruamel.yaml.clib is
mis-handling python bytes objects.


### boxfort ###

sergiodj says he'd like to try to tackle this one.  I think it just
needs a (now-obsolete) binary package removed.

* boxfort (0.0.0-git20200105-3e16c0a-6 to 0.0.0-git20200808-ac0507b-3)
  - missing build on armhf: libboxfort, libboxfort-dev
  - Two issues (I think...) from 0.0.0-git20200808-ac0507b-1
    + Debian limited architectures for libboxfort-dev from "any" to just
      "amd64 arm64 i386"
    + Debian stopped building libboxfort
  - libboxfort binary package needs to be removed from the archive
  - Possibly libboxfort-dev:armhf binary package needs some sort of
    attention (not sure)


### Other ###

* docker.io:  Passed after a retrigger with containerd on amd64.

* ffmpeg:  was stuck on build dependency for libdc1394-dev, which was
  just recently renamed.  Just needed a rebuild.

* puma:  had some network glitch, and passed on simple re-trigger

* libvorbisidec:  Build failure on armhf due to some assembly errors,
  but passed with a rebuild.

* container:  Looked like an intermittent docker.service job error.
  Passed on a simple re-trigger.

* texlive-extra:  Passed after a re-trigger against current nbsphinx.

* translate-toolkit:  Passed after a re-trigger against current virtaal
  (and sphinx).

* Lots of other poking and prodding with re-builds and re-triggers that
  didn't pan out.


### Stats ###

Monday:    308 update excuse records found
Tuesday:   321 update excuse records found
Wednesday: 285 update excuse records found
Thursday:  270 update excuse records found
Friday:    261 update excuse records found