Proposed Migration - Reference Edition
Bryce Harrington
bryce.harrington at canonical.com
Thu Dec 12 00:21:51 UTC 2019
########################################################################
## 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
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
More information about the ubuntu-server
mailing list