<div dir="ltr"><div dir="ltr"> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 12, 2019 at 1:22 AM Bryce Harrington <<a href="mailto:bryce.harrington@canonical.com">bryce.harrington@canonical.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ######################################################################## ## 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. <a href="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" rel="noreferrer" target="_blank">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</a> 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 <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040833.html" rel="noreferrer" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040833.html</a> * 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: <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040833.html" rel="noreferrer" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040833.html</a> - 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 - <a href="https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852</a> - "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 <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945978" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945978</a> * 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 <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html" rel="noreferrer" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html</a> * 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 <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html" rel="noreferrer" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html</a> ################## ### 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 <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html" rel="noreferrer" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html</a> - For now, I just triggered a rerun of the test since one's done that yet </blockquote><div> </div><div>This is resolved per:</div><div>[00:01] <vorlon> ignoring test failures from dpdk on i386 </div></div></div>