On Thu, Dec 12, 2019 at 1:22 AM Bryce Harrington < [email protected]> wrote:
> > ######################################################################## > ## Proposed Migration ## > ######################################################################## > > Below is a comprehensive look at remaining items. > Thanks for compiling that, I hope it wasn't too much work. > 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." > Lucas said he opened bug against the remaining packages that need work. Maybe he can share the bug links here. > > ####################### > ### 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... > I have talked to coreycb and he confirmed that he will take a look at these. The reason is that most of the packages are from the Openstack scope and likely need an update anyway. So consider this in Coreys/Openstacks hands for now. > > ############################## > ### 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? > I've had some people that wanted slurm to be ok - not on s390x but anyway. Since I also have easy s390x access I'll take a look into these. ################### > ### 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 > > > -- > ubuntu-server mailing list > [email protected] > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
