Friday 14 May 2021

+1 maintenance report

Here's my report for the (short) week of May 10-15 (Thu was a national holiday).


The week started by having a small merge party with the foundations team 🎉,
distracting me ("team +1 work") from my actual +1 work a bit, by merging:
* popularity-contests / 1.71ubuntu1, migrated
* vim / 2:8.2.2434-3ubuntu1, migrated
* curl / 7.74.0-1.2ubuntu1, pending migration for "hyphy" autopkgtest


### atlas ###

atlas / 3.10.3-10ubuntu1 ftbfs on riscv64

This FTBFS happened only on Risc-V, after some debugging I was able to reproduce
the problem locally (on amd64) when building with 'DEB_BUILD_OPTIONS=nocheck'.
I confirmed the problem is related to the build environment, by building Debian's
package (no Ubuntu modifications) in Bileto: It builds fine on Debian's buildd
on riscv but fails on Launchpad's buildd (due to building with the 'nocheck'
profile).
Trying to skip the libatlas-test package via "Build-Profiles: <!nocheck>" [0]
was a red herring, that spec does not seem to be (fully?) implemented.
https://wiki.debian.org/BuildProfileSpec
In the end I force executed the 'make check/ptcheck' targets via debian/rules
so that the relevant files for libatlas-test are always build (and tests run...)
@xnox suggested that exporting/overriding a new DEB_BUILD_OPTIONS variable at
the top of debian/rules might have worked as well, @rbalint pointed me to dpkg's
1.20.9ubuntu1 changelog where the override is described as:
DEB_BUILD_OPTIONS := $(filter-out nocheck,$(DEB_BUILD_OPTIONS))
So I implemented this improved solution as well in 3.10.3-10ubuntu3. Also, I
filed a bug at Debian, to find a proper solution to this problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988370


### jack-rack ###

jack-rack / 1.4.8~rc1-2ubuntu4 python2-rm transition

Removal bug filed, as this is blocking the python2-rm transition, has been
removed from Debian testing/unstable and is unmaintained upstream.
https://bugs.launchpad.net/ubuntu/+source/jack-rack/+bug/1928087


### kpatch ####

kpatch / 0.8.0-0ubuntu7 python2-rm transition

This package depends on python2-dev, upstream just changed it to python3-dev.
Changed the dependency to python3-dev as well and the package still builds fine.
No autopkgtests are provided for verification.
https://github.com/dynup/kpatch/commit/4df66fa15f95c86946050ae969658c17caebc0d2


### cdrkit ###

cdrkit / 9:1.1.11-3.2 sponsoring sync

The Debian package contains all relevant changes from Ubuntu. The delta is not
needed anymore, as explained by @waveform:
https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/1927944


### python-pyscss ###

python-pyscss / 1.3.7-3 sponsoring sync

The Debian package contains all relevant changes from Ubuntu and is in better
shape. Sponsoring for @logan.
https://bugs.launchpad.net/ubuntu/+source/python-pyscss/+bug/1922971


### python-barbicanclient ###

python-barbicanclient / 5.0.1-0ubuntu1 ftbfs on amd64 (any)

Reviewed and sponsored a debdiff from @hellsworth.
https://bugs.launchpad.net/ubuntu/+source/python-barbicanclient/+bug/1923626


### db5.3 ###

db5.3 / db5.3 5.3.28+dfsg1-0.8 sponsoring merge

Reviewed and sponsored a debdiff from @waveform.
https://bugs.launchpad.net/ubuntu/+source/db5.3/+bug/1927978


### ply ###

ply / 3.11-4 python2-rm transition

I've dropped the python-ply package and python2 build-depends + python2
tests (in autopkgtest) for this package, to satisfy the python2-rm
transition. Also, I've sent the patch to Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937304


### pycparser ###

pycparser / 2.20-3 python2-rm transition

I've dropped the python-pycparser package and python2 build-depends + python2
tests (in autopkgtest) for this package, to satisfy the python2-rm
transition. Also, I've sent the patch to Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937411


### pypy & pypy3 ###

pypy+pypy3 / 7.3.4+dfsg-2 python2-rm transition

There are some issues with pypy/pypy3. According to @tumbleweed pypy is used to
build pypy3. And pypy is also used to build pypy itself (it can be bootstrapped
using python2.7, tho). Neither of both can be built using python3. Upstream
is apparently working on this Python3 support, but they are not quite ready:
https://foss.heptapod.net/pypy/pypy/-/commits/branch/rpython3/

The pypy maintainer @tumbleweed is pretty active and suggested using the
pycparser bundled with pypy, to avoid that dependency. Also, a python2.7
source could be bundled with pypy to avoid that dependency as well, if need be
(i.e. after src:python2.7 is removed).

It builds fine without the python-pycparser build-dependency (for non 'stage1'
build profiles, i.e. building with pypy with pypy itself). @tumbleweed wants to
look into fixing the '--profile=stage1' bootstrapping build using the bundled
pycparser.


### hyphy ###

hyphy / 2.5.28+dfsg-3 autopkgtest failure on amd64

The tests for this package crash with "Illegal instruction (core dumped)"
("Using /usr/lib/hyphy/bin/hyphy-avx"). I was not able to reproduce the issue
locally in qemu, so this seems to be an infrastructure issue. The test first
failed for the new "curl" upload, but I did a baseline test against "hello",
which shows that this package regressed in -release, independently of "curl".
The tests still pass on hirsute-release, tho. I'm not really sure how to
continue here...
Did something change wrt. the AVX instruction set on our amd64 test runners?


### nss (dogtag-pki) ###

nss / 2:3.63-1ubuntu1 (vs dogtag-pki) autopkgtest failure on s390x

This problem is unrelated to the s390x autopkgtest failures we had some while
ago. The 389-ds-base patch (https://github.com/389ds/389-ds-base/pull/4573) is
included in the 389-ds-base package. The dogtag-pki test passes if tested
against "389-ds-base"; it passes if tested against "hello" (using old "nss");
it fails when tested using the new "nss" (2:3.63-1ubuntu1).
Looking into DebianCI, the new "nss" passes testing with "dogtag-pki" on
s390x, tho. So this seems to be a real regression in nss 2:3.63-1ubuntu1, most
probably inside the ubuntu delta itself.
It's kind of hard to debug this right now, as Canonistack is still flaky, there
is no proper access to s390x machines... Also, I'm running out of time, so this
is something to pick up next time.


### TODO ###

- Check back with @tumbleweed about the pypy/stage1 build
- Figure out what changed wrt. AVX instruction set on the test runners
- Verify the Ubuntu delta of nss 2:3.63-1ubuntu1 regressed on s390x (dogtag-pki)


Cheers,
  Lukas