<div dir="ltr">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. <a href="https://wiki.debian.org/BuildProfileSpec">https://wiki.debian.org/BuildProfileSpec</a> 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: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988370">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988370</a> ### 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. <a href="https://bugs.launchpad.net/ubuntu/+source/jack-rack/+bug/1928087">https://bugs.launchpad.net/ubuntu/+source/jack-rack/+bug/1928087</a> ### 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. <a href="https://github.com/dynup/kpatch/commit/4df66fa15f95c86946050ae969658c17caebc0d2">https://github.com/dynup/kpatch/commit/4df66fa15f95c86946050ae969658c17caebc0d2</a> ### 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: <a href="https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/1927944">https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/1927944</a> ### 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. <a href="https://bugs.launchpad.net/ubuntu/+source/python-pyscss/+bug/1922971">https://bugs.launchpad.net/ubuntu/+source/python-pyscss/+bug/1922971</a> ### python-barbicanclient ### python-barbicanclient / 5.0.1-0ubuntu1 ftbfs on amd64 (any) Reviewed and sponsored a debdiff from @hellsworth. <a href="https://bugs.launchpad.net/ubuntu/+source/python-barbicanclient/+bug/1923626">https://bugs.launchpad.net/ubuntu/+source/python-barbicanclient/+bug/1923626</a> ### db5.3 ### db5.3 / db5.3 5.3.28+dfsg1-0.8 sponsoring merge Reviewed and sponsored a debdiff from @waveform. <a href="https://bugs.launchpad.net/ubuntu/+source/db5.3/+bug/1927978">https://bugs.launchpad.net/ubuntu/+source/db5.3/+bug/1927978</a> ### 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: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937304">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937304</a> ### 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: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937411">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937411</a> ### 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: <a href="https://foss.heptapod.net/pypy/pypy/-/commits/branch/rpython3/">https://foss.heptapod.net/pypy/pypy/-/commits/branch/rpython3/</a> 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 (<a href="https://github.com/389ds/389-ds-base/pull/4573">https://github.com/389ds/389-ds-base/pull/4573</a>) 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 </div>