Proposed Migration - Reference Edition
Christian Ehrhardt
christian.ehrhardt at canonical.com
Thu Dec 12 07:01:12 UTC 2019
On Thu, Dec 12, 2019 at 1:22 AM Bryce Harrington <
bryce.harrington at canonical.com> wrote:
>
> ########################################################################
> ## Proposed Migration ##
> ########################################################################
>
> Below is a comprehensive look at remaining items.
>
> A lot of good work has been done lately to clear the board down. I've
> gone through everyone's reports and compiled analysis comments relating
> to stuff still needing done. Hopefully this serves as a reference as
> people look for next actions towards clearing the remaining items.
>
>
>
> #####################
> ### pyjwt (Lucas) ###
> #####################
>
> pyjwt (1.7.1-1 to 1.7.1-2) in proposed for 45 days
> candidate
>
> * pyjwt is maybe stuck due to python-oauthlib?
> - The transition for this package from 1.7.1-1 to 1.7.1-2 is to "Drop
> python2 support". This will result in the removal of python-jwt,
> which python-oauthlib has a dependency on.
> - I've manually triggered a coupled test run specifying both of the new
> py3 packages for python-oauthlib and pyjwt against arch's amd64, arm64,
> armhf, i386, ppc64el, s390x.
>
>
> https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=${ARCH}&package=python-oauthlib&trigger=python-oauthlib%2F3.1.0-1&trigger=pyjwt%2F1.7.1-2
> <https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=$%7BARCH%7D&package=python-oauthlib&trigger=python-oauthlib%2F3.1.0-1&trigger=pyjwt%2F1.7.1-2>
>
> If that doesn't resolve both packages, may need to do coupled test
> triggers also with package=pyjwt.
>
> * Christian wrote, "I was working with Lucas on pyjwt. This is listed as
> valid candidate in terms of build&autopkgtest for a long time. The
> reason it is still blocked is that plenty of Ubuntu-only python
> packages depend on its python2 portion. This is detected as making
> those uninstallable. Lucas will look into those dependencies and
> identity existing or open new bugs to have all those updated or
> removed for 20.04."
>
>
> #######################
> ### python-oauthlib ###
> #######################
>
> python-oauthlib (2.1.0-1 to 3.1.0-1) in proposed for 44 days
> candidate
>
> * python-oauthlib lists a bunch of dependencies, not sure which is
> blocking it:
> * amd64: lptools, python-apport, python-launchpadlib,
> python-launchpadlib-toolkit, python-lazr.restfulclient,
> python-oops-datedir-repo, python-piston-mini-client,
> python-requests-oauthlib, python-ssoclient,
> python-ubuntu-kylin-sso-client,
> python-ubuntu-kylin-sso-client.tests, sbuild-launchpad-chroot,
> software-center-aptdaemon-plugins, subiquity-tools,
> ubuntu-kylin-sso-client, ubuntu-kylin-sso-client-qt,
> unity-scope-launchpad
>
> - Is moving from python 2.1.0-1 to 3.1.0-1. Presumably this means
> it's going through a python2->3 transition?
> - python-oauthlib is mentioned on Doko's Python2 removal email
>
> https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040833.html
>
> * Possible fix: I'm guessing maybe we need to trigger tests against
> python-oauthlib=3.1.0-1 and some or all of these packages:
> - django-oauth-toolkit
> - keystone
> - lazr.restfulclient
> - python-jira
> - python-keystoneauth1
> - python-lti
>
>
> ###############
> ### subunit ###
> ###############
>
> subunit (1.3.0-5 to 1.3.0-6) in proposed for 33 days
> candidate
>
> * subunit is stuck due to python-autopilot-trace (ppc64el)
> - This is just a no-change rebuild by debian
> - subunit is marked stuck due to python-autopilot-trace (ppc64el),
> which is provided by autopilot-legacy (I guess?) Other packages
> also are blocked on autopilot, but it's last changelog entry was
> zesty in 2017.
> - autopilot is a GUI test tool for desktop applications. It is listed
> on Doko's Python2 removal email:
>
> https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040833.html
> - However, there is no mention of "*autopilot*" anywhere in subunit's
> codebase. So, I'm not sure how this is affecting things.
> - subunit's rdepends shows it's depended on by samba-testsuite,
> however samba-testsuite's changelog indicates it was dropped as a
> dependency by Debian in 2016. In our package it's listed as a
> Suggests.
>
> * Possible fix: Maybe we should just drop the subunit suggest for
> samba-testsuite?
>
>
> ###########
> ### six ###
> ###########
>
> six (1.12.0-2build1 to 1.13.0-1) in proposed for 29 days
> Regressions
> python-oslo.cache/1.37.0-0ubuntu1: amd64 (log, history), arm64
> (log, history), armhf (log, history), ppc64el (log, history), s390x (log,
> history)
> python-oslo.config/1:6.11.1-0ubuntu1: amd64 (log, history),
> arm64 (log, history), armhf (log, history), ppc64el (log, history), s390x
> (log, history)
> python-oslo.log/3.44.1-0ubuntu1: amd64 (log, history), arm64
> (log, history), armhf (log, history), ppc64el (log, history), s390x (log,
> history)
> python-oslo.messaging/9.7.1-0ubuntu3: amd64 (log, history),
> arm64 (log, history), armhf (log, history), ppc64el (log, history), s390x
> (log, history)
> python-oslo.policy/2.3.2-0ubuntu1: amd64 (log, history), arm64
> (log, history), armhf (log, history), ppc64el (log, history), s390x (log,
> history)
> python-oslo.serialization/2.29.2-0ubuntu1: arm64 (log,
> history), armhf (log, history), s390x (log, history)
> python-oslo.service/1.40.2-0ubuntu1: amd64 (log, history),
> arm64 (log, history), armhf (log, history), ppc64el (log, history), s390x
> (log, history)
> python-pyeclib/1.5.0-1ubuntu7: amd64 (log, history), arm64
> (log, history), armhf (log, history), ppc64el (log, history), s390x (log,
> history)
>
> * One change of note in this release is the addition of
> autopkgtest-pkg-python.
> * This is also dropping build-deps on python-py and python3-py
> * It still includes some python2 components and dependencies...
>
>
> ##############################
> ### libseccomp (Christian) ###
> ##############################
>
> libseccomp (2.4.1-0ubuntu0.19.10.3 to 2.4.2-2ubuntu1) in proposed for
> 22 days
> Regressions
> systemd/243-3ubuntu1: s390x (log, history)
>
> * Christian is working this one
> - https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852
> - "That is what I talk about every now and then. I continue to work
> on this as time between other tasks permits."
> - "I worked for quite some days on libseccomp being blocked
> anyway. Upstream systemd now accepted my changes last week which
> will resolve the test issues that were holding libseccomp back. An
> MP for those was today accepted for systemd packaging and once v244
> is in focal this should resolve and then finally migrate."
>
>
>
> ####################
> ### walinuxagent ###
> ####################
>
> walinuxagent (2.2.40-0ubuntu1 to 2.2.44-0ubuntu1) in proposed for 14
> days
> Blocked by bug: #1851064 (block-proposed SRU)
>
> - blocked by LP: #1851064 (block-proposed SRU), as mentioned by paride
> - this tag was added recently (11-27) but not spotting rationale?
>
>
> ################
> ### requests ###
> ################
>
> requests (2.21.0-1 to 2.22.0-2) in proposed for 6 days
> Regressions
> python-meshio/3.1.6-1ubuntu1: arm64 (log, history), armhf
> (log, history), ppc64el (log, history), s390x (log, history)
> python-oslo.config/1:6.11.1-0ubuntu1: amd64 (log, history),
> arm64 (log, history), armhf (log, history), ppc64el (log, history), s390x
> (log, history)
> python-oslo.policy/2.3.2-0ubuntu1: amd64 (log, history), arm64
> (log, history), armhf (log, history), ppc64el (log, history), s390x (log,
> history)
> snakemake/5.8.1-1: amd64 (log, history), ppc64el (log, history)
>
> * This mentions python-oslo like six does, maybe it's related?
> * The package sets some strict version dependencies. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945978
> * I wonder if we're simply not satisfying the strict dependencies, and
> if so, perhaps a fix might be to tinker with the requirements until it
> goes through.
>
>
> ##############
> ### sphinx ###
> ##############
>
> python-cffi blocking sphinx (1.8.5-3 to 1.8.5-4) for 6 days
> Regressions
> python-cffi/1.13.1-1: i386 (log, history)
>
> python-cryptography blocking sphinx (1.8.5-3 to 1.8.5-4) for 6 days
> Regressions
> python-cryptography/2.6.1-4: i386 (log, history)
>
> * Failing with unmet dependencies, maybe some i384/amd64 confusion?
> * Have some python2 dependencies
> * See
> https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html
>
> * Possible fix: A 404 error is showing in python-cffi/i386's log, so
> I've triggered a re-test to see if it was just a network issue.
>
>
> #######################
> ### bind9 (Andreas) ###
> #######################
>
> bind9 blocking netbase (5.6 to 5.8) for 5 days
> Regressions
> bind9/1:9.11.5.P4+dfsg-5.1ubuntu4: i386 (log, history)
>
> * bind9 (i386)
> - Looks like maybe something to do with netbase/5.8?
> - Andreas writes, "Blocking migration: I spotted bind9/i386 blocking
> the migration of netbase, so I'll take a look at that tomorrow. It
> was also in Steve's last email about the i386 status in focal."
>
> * See
> https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html
>
>
> ##################
> ### slurm-llnl ###
> ##################
>
> mysql-8.0 (8.0.18-0ubuntu3 to 8.0.18-0ubuntu4) in proposed for 4 days
> Regressions
> slurm-llnl/19.05.3.2-2: s390x (log, history)
>
> freeipmi (1.6.3-1.1ubuntu2 to 1.6.4-3ubuntu1) in proposed for 0 days
> Regressions
> slurm-llnl/19.05.3.2-2: s390x (log, history)
>
> * slurm-llnl
> - The gtk+ runs pass, but not the ones with freeipmi or mysql
>
> * Possible fix: Maybe trigger a run with the new versions of both
> mysql-8.0 and freeipmi together?
>
>
> ###################
> ### ocfs2-tools ###
> ###################
>
> ocfs2-tools (1.8.6-1ubuntu1 to 1.8.6-2ubuntu1) in proposed for 2 days
> Missing builds, see excuses
>
> * ocfs2-tools is failing autopkgtest, and seems to be hitting some kernel
> panics, which I don't know if it's normal or exceptional:
>
> [ 1.470204] md: ... autorun DONE.
> [ 1.471873] VFS: Cannot open root device
> "PARTUUID=5b57f3f9-086a-4a7d-ae78-efdee8842586" or
> unknown-block(0,0): error -6
> [ 1.475808] Please append a correct "root=" boot option; here are
> the available partitions:
> [ 1.478858] Kernel panic - not syncing: VFS: Unable to mount root fs
> on unknown-block(0,0)
>
> I don't know if it's relevant, but there was also a "Fail" on
> lxd.daemon:
>
> [[0;32m OK [0m] Listening on [0;1;39mD-Bus System Message Bus
> Socket[0m.
> [[0;1;31mFAILED[0m] Failed to listen on [0;1;39mSocket?r snap
> application lxd.daemon[0m.
> See 'systemctl status snap.lxd.daemon.unix.socket' for details.
> [[0;32m OK [0m] Listening on [0;1;39mUUID daemon activation
> socket[0m.
> - Someone more knowledgeable about this package's test and their VFS
> usage may need to study this one, if it's a legit issue.
> - No one appears to have attempted a rebuild on this, so I've done so
> for all architectures.
>
> * Paride wrote, "ocfs2-tools still has a regression despite Bryce
> triggering
> a rebuild yesterday. Same failure mode: kernel panic due to:
> "VFS: Cannot open root device". I have no experience with
> ocfs2, however if nobody steps in I can dig into this."
>
>
> ##############
> ### clamav ###
> ##############
>
> clamav (0.101.4+dfsg-1ubuntu1 to 0.102.1+dfsg-1ubuntu1) in proposed
> for 2 days
> Regressions
> cyrus-imapd/3.0.12-2: arm64 (log, history), armhf (log,
> history)
>
>
> * cyrus-imapd (armhf and arm64)
> - cyrus-imapd itself passes, but not with liblist-someutils or
> automake
>
> * Possible fix: Maybe re-run test with triggers against some or all of
> util-linux/2.34-0.1ubuntu4, liblist-someutils-perl/0.58-1,
> automake-1.16/1:1.16.1-4ubuntu4, cyrus-imapd/3.0.12-2, and
> clamav/0.102.1+dfsg-1ubuntu1
>
>
>
> ############
> ### dpdk ###
> ############
>
> dpdk blocking util-linux (2.34-0.1ubuntu2 to 2.34-0.1ubuntu4) for 0
> days
> Regressions
> dpdk/18.11.5-1: i386 (log, history)
>
> * dpdk (i386)
> - Unmet dependencies for dpdk-dev:i386 and python-pexpect:i386
> - See
> https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html
> - For now, I just triggered a rerun of the test since one's done that yet
>
This is resolved per:
[00:01] <vorlon> ignoring test failures from dpdk on i386
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20191212/1461084d/attachment-0001.html>
More information about the ubuntu-server
mailing list