+1 maintenance report

Lukas Märdian lukas.maerdian at canonical.com
Fri May 14 15:57:00 UTC 2021

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

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
the problem locally (on amd64) when building with
I confirmed the problem is related to the build environment, by building
package (no Ubuntu modifications) in Bileto: It builds fine on Debian's
on riscv but fails on Launchpad's buildd (due to building with the 'nocheck'
Trying to skip the libatlas-test package via "Build-Profiles: <!nocheck>"
was a red herring, that spec does not seem to be (fully?) implemented.
In the end I force executed the 'make check/ptcheck' targets via
so that the relevant files for libatlas-test are always build (and tests
@xnox suggested that exporting/overriding a new DEB_BUILD_OPTIONS variable
the top of debian/rules might have worked as well, @rbalint pointed me to
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:

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

### kpatch ####

kpatch / 0.8.0-0ubuntu7 python2-rm transition

This package depends on python2-dev, upstream just changed it to
Changed the dependency to python3-dev as well and the package still builds
No autopkgtests are provided for verification.

### cdrkit ###

cdrkit / 9:1.1.11-3.2 sponsoring sync

The Debian package contains all relevant changes from Ubuntu. The delta is
needed anymore, as explained by @waveform:

### python-pyscss ###

python-pyscss / 1.3.7-3 sponsoring sync

The Debian package contains all relevant changes from Ubuntu and is in
shape. Sponsoring for @logan.

### python-barbicanclient ###

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

Reviewed and sponsored a debdiff from @hellsworth.

### db5.3 ###

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

Reviewed and sponsored a debdiff from @waveform.

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

### pycparser ###

pycparser / 2.20-3 python2-rm transition

I've dropped the python-pycparser package and python2 build-depends +
tests (in autopkgtest) for this package, to satisfy the python2-rm
transition. Also, I've sent the patch to Debian:

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

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
(i.e. after src:python2.7 is removed).

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

### 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
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
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
ago. The 389-ds-base patch (https://github.com/389ds/389-ds-base/pull/4573)
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
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,
probably inside the ubuntu delta itself.
It's kind of hard to debug this right now, as Canonistack is still flaky,
is no proper access to s390x machines... Also, I'm running out of time, so
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20210514/140e5e82/attachment-0001.html>

More information about the ubuntu-devel mailing list