+1 maintenance report

[Nick Rosbrook]

Hi,

I was on +1 last week. Here is my report:

### python-llfuse autopkgtest regression on armhf

This was caused by a 32-bit integer overflow in one of the tests.  I
changed the offending test value to fit in 32-bit, and forwarded the
patch upstream.

William sponsored an upload that resolved this.

### gtk-gnutella FTBFS (https://pad.lv/1981474)

The FTBFS is due to checking PTHREAD_STACK_MIN != 0 with preprocessor
directives. But, PTHREAD_STACK_MIN may be defined dynamically, so it
should be checked at run time.

William sponsored an upload that resolved this.

### ruby-certificate-authority FTBFS (https://pad.lv/1981458)

There was a print format change for the x509 v3 authority key
identifer field in openssl 3.0, and this test suite appears to depend
on that format. Changing the expected test string to match the new
format fixes the issue.

William sponsored an upload that resolved this.

### reprotest FTBFS (https://pad.lv/1981624)

This package hardcodes py39 in tox.ini, so when python 3.10 is the
default this FTBFS. This package should dynamically set the tox env in
debian/rules.

William sponsored an upload that resolved this.

### pydantic FTBFS (https://pad.lv/1981341)

The failing test interacts with environment variables to initialize a
configuration (as a Python object). The test adds a 'v' field to the
class, with the default value of 'default'. The test case expects that
this class will *not* be changed by the execution environment.
However, in launchpad builds, the env var V=1 is configured. This
causes the assertion failure seen in the FTBFS log.

William sponsored an upload that resolved this.

### fastapi FTBFS

This needed the new version of pydantic, and a re-build succeeded
after we uploaded pydantic.

### sqlmodel FTBFS

The build time tests fail because of a bug in python3-fastapi
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005635). That bug
was fixed by fastapi in kinetic-proposed, so once fastapi built again
(as a result of the pydantic fix), this package was able to build
again too.

### tcpreplay no build on armhf (https://pad.lv/1981635)

The immediate cause of this is that armhf is not enabled in
debian/control. When armhf is re-enabled, it FTBFS with
https://github.com/appneta/tcpreplay/issues/725. That can be
worked-around by patching configure.ac to set FORCE_ALIGN on arm*
arches. But, then there is another bug
(https://github.com/appneta/tcpreplay/issues/726) that causes FTBFS.

It seems that the second bug is a todo item for the next upstream
release, so maybe it is best to just wait for the next upstream
release to resolve this.

### ruby-jwt FTBFS

The ruby-jwt package does not yet support openssl 3.0, so it is FTBFS.
There is work being upstream on this, so I just created
https://pad.lv/1981456 (with relevant upstream links), and tagged it
update-excuse.

### ruby-html-proofer

Did not spend too long looking at this one. I get different (and
disjoint) sets of failures in my local sbuild and on launchpad
builders.

### ocrad autopkgtest regressions (https://pad.lv/1981846)

The autopkgtest failures are due to undefined references to symbols in
libpng. This package's autopkgtest is a bit odd because it compiles a
new binary called ocradcheck, and uses that to perform the tests. I
tried to quick-fix the build in the autopkgtest, but predictably I hit
other issues. I wasn't able to push this one over the line, but it
seems like the best course would be for this package to have an
additional binary package (ocrad-test or ocradcheck) to be used in
autopkgtest (I suggested this on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004508).

### probabel FTBFS

I think this is a candidate for removal. The Debian maintainer has
also indicated this
(https://lists.debian.org/debian-med/2022/02/msg00093.html), which is
noted in the package's debian/Readme.Debian.

$ reverse-depends src:probabel -r kinetic
Reverse-Recommends
* med-bio                       (for probabel)
* med-cloud                     (for probabel)
Packages without architectures listed are reverse-dependencies in:
amd64, arm64, armhf, i386, ppc64el, s390x

$ reverse-depends src:probabel -r kinetic -a source
No reverse dependencies found

Thanks to William for reviewing and sponsoring several things.

-Nick