+1 maintenance report

Mon May 17 06:47:48 UTC 2021

On Fri, May 14, 2021 at 5:58 PM Lukas Märdian <lukas.maerdian at canonical.com>
wrote:

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

Hi Lukas,
There is no single "AVX instruction set", it actually consists of various
things introduced in different chip generations.
And what can be passed to the guest also depends on kernel and
qemu versions.
For a feeling of it look at `$ qemu-system-x86_64 -cpu ? | grep avx`

It is quite likely that your local test didn't have avx enabled at all.

My local autopkgtest for example specifies by default:
  -cpu kvm64,+vmx,+lahf_lm

This default has no avx capabilities at all.

In a local autopkgtest you can pass qemu cpu options via:
-- qemu --qemu-options=

Unless you need to do things much more fine grained you could try
  --qemu-options="-cpu host"

If still not locally reproducible, you might need to find a server with the
same chips as being used in the test infrastructure.
And you'd want to find the cpu spec that autopkgtest CPUs are run with
(this is an openstack, so there are
libvirt XMLs representing the guests and logs of the qemu commandling in
/var/log/libvirt/qemu/<guestname>.log
Look for "-cpu ..." in there

- Verify the Ubuntu delta of nss 2:3.63-1ubuntu1 regressed on s390x
> (dogtag-pki)
>
>
> Cheers,
>   Lukas
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20210517/e77b351d/attachment.html>