Tuesday 13 September 2022

+1 Maintenance Report

I was on +1 maintenance for the week of September 5-9. Below are the
things I worked on.
TL;DR see 'Package still in need of attention' at the bottom.

r-cran-cppparallel
==================
Reverse-dependencies of r-cran-cppparallel needed to be rebuilt
against onetbb, but this was only possible after sync'ing
r-cran-stanheaders, r-cran-rstan, r-cran-rstantools, r-cran-prophet
and r-cran-rstanarm from Debian. I checked the dates when
reverse-dependencies had been built, and uploaded no-change rebuilds
for r-bioc-dada2, r-cran-lamw and r-cran-openmx.

r-cran-plm
==========
This package was blocked by regressions in r-cran-clubsandwich and
r-cran-parameters. I retried the autopkgtests after
r-cran-cppparallel had migrated and they succeeded.

r-cran-pkgload / r-cran-devtools
================================
The autopkgtests of r-cran-pkgload were missing a dependency, which
was fixed in Debian. After sync'ing r-cran-pkgload, r-cran-devtools'
autopkgtests succeeded and both migrated.

nbclient
========
There was an autopkgtest regression on armhf which only needed a retry.

astropy / hipspy
================
Astropy was blocked due to an autopkgtest regression in hipspy.
According to Debian bug #1012277, hipspy was no longer supported
upstream and had already been removed from Debian testing. I filed
LP: #1988740 and hipspy was removed from kinetic allowing astropy to
migrate.

casacore
========
There was a FTBFS on ppc64el due to test failure. I solved this by
building with -O2.

pcl
===
The build failed on armf due to a dh_dwz error. It turned out that
armhf was our only architecture where pcl is built with Clang instead
of GCC. I used override_dh_dwz to avoid the error, but then found
builds in my PPA on the other architectures were failing due to OOM,
solved by building with --max-parallel=3.

pgbackrest
==========
This package FTBFS everywhere except amd64. This was already fixed in
Debian, so I sync'd the new version.

sptag
=====
This package FTBFS with LTO disabled. I filed LP: #1988992 and added
sptag to lto-disabled-list.

gst-omx
=======
This package failed its own autopkgtests as well as those of
libomxalsa, libomxcamera, libomxfbdevsink, etc. due to being built
with LTO. I filed #1988985, added get-omx to lto-disabled-list, and
then uploaded a no-change rebuild of gst-omx.

visp
====
This package FTBFS due to an incorrect build-dependency. This was
already fixed in Debian, so I sync'd the new version.

racket
======
There was a FTBFS on ppc64el which only needed a retry.

pysolid / pyscanfcs
===================
Both packages FTBFS on ppc64el and s390x, but only needed retries
since the builds of skimage on these architectures had been fixed.

deviceinfo
==========
This package had a bad symbols file and it had previously only built
on armhf and riscv64. I updated the symbols for LTO and fixed some
for ppc64el and riscv64, and it built everywhere.

python-tornado / jupyter-core
=============================
Both packages were blocked by an autopkgtest regression in
jupyter-client on arm64 only. I triggered jupyter-client's
autopkgtests against python-tornado and jupyter-core separately and
they both passed. Once they had migrated, I triggered a
migration-reference/0 test to check that it still passed, and it did.

dnstwist
========
The autopkgtest of this package gained new dependencies which were not
installable everywhere. This had been hinted in Debian, so I added
force-badtest hints on the architectures that failed and allowed it to
migrate.

python-pynndescent
==================
This package FTBFS on ppc64el due to a precision error in a test. I
fixed this by increasing the tolerance and forwarded the fix upstream.


Package still in need of attention:

kiwi
====
This package is unable to migrate due to kiwi-dracut-oem-dump/riscv64
having an unsatisfiable dependency on kexec-tools. I filed LP:
#1988966 and linked to Debian bug #1019254 which contains a patch.

gensio / ser2net
================
gensio FTBFS with LTO due to missing symbols. I had a look at fixing
this, but the symbols file needs a lot of work and has many
duplicates. gensio also has no autopkgtest, so it should be tested
that it still works when built with LTO, and if not, maybe adding it
to lto-disabled-list is the way forward.

dolfin
======
The last autosync'd version from Debian FTBFS due an added dependency
on libc-dev (>= 2.34) for their glibc 2.34 transition. I sync'd the
next upload from the Debian maintainer which reverted that, and it
built, but now has seemingly unrelated autopkgtest regressions in
fenics and mshr.

gemmi
=====
The last autosync'd version from FTBFS on arm64, ppc64el and s390x. I
sync'd the next upload from Debian which fixed the build, but now has
autopkgtest regressions on those same architectures.

scikit-learn / top / imbalanced-learn
=====================================
The new version of scikit-learn has a bus error in one of its
autopkgtests on armhf. This was allowed to regress in Debian during a
numpy transition almost a year ago. I'm not sure whether it's worth
the time to try to fix this, or simply skip the failing test.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel