Server Team - Proposed Migration Notes

This collects notes and findings from the server team's proposed migration page for the current development release. This page lists packages that are stuck in proposed due to a variety of issues, some of which are in-scope for the server team, others of which may have broader causes.

Blocked Packages

Below are the server team's collective guesses as to what's going on with some of the packages listed as .

Openssl

Looking at openssl, krb5/i386[1] called my attention again, since I fixed an i386 problem recently. But this time I don't know what to do. It boils down to build-essential:amd64 being uninstallable in that muiti-arch environment with i386 being an additional architecture; # apt install build-essential

• build-essential : Depends: libc6-dev but it is not going to be installed or
  • libc-dev

  • Depends: g++ (>= 4:9.2) but it is not going to be installed

Following that path, we arrive at: # apt install linux-libc-dev ... The following packages will be REMOVED:

• comerr-dev:i386 krb5-multidev:i386 libc6-dev:i386

libgnutls28-dev:i386 libkrad-dev:i386 libkrb5-dev:i386 linux-libc-dev:i386

And those removals seem to be the problem. The g++ path also ends up there:

# apt install g++ g++-9 libstdc++-9-dev

• libstdc++-9-dev : Depends: libc6-dev (>= 2.13-0ubuntu6) but it is not

going to be installed

Galera-3

The other blocker for openssl is galera-3, which is weird because galera-arbitrator-3 was removed[2] (but bin:galera-3 remains), but it still builds fine in focal. Maybe the intention is to drop galera-3 altogether in favor of galera-4? Anyway, all galera-3 test are failing because of that (incomplete?) removal:

E: Package 'galera-arbitrator-3' has no installation candidate

Gnutls28/i386

Seems to be the same build-essential problem[3] that is afflicting krb5/i386:

The following packages have unmet dependencies:

• builddeps:/tmp/autopkgtest.pWJpZS/1-autopkgtest-satdep.dsc:i386 :

Depends: libgnutls28-dev:i386

• builddeps:essentials : Depends: build-essential but it is not going to be installed

=== Nut ==

nut (- to 2.7.4-11ubuntu3) in proposed for 2 days

• Unsatisfiable depends:
  • libpowerman0: amd64, arm64, armhf, ppc64el, s390x

    powerman (>= 2.3.3): amd64, arm64, armhf, ppc64el, s390x

Well that was expected, we re-added packages that depend on those. But while src:nut is in main those packages won't (no dependency pulling them in). So these should go to universe and indeed we see:

Binary only movements to universe (ubuntu-server)

• nut-powerman-pdu nut

Once that is done by an ArchiveAdmin the dependency issue above will resolve. Christian pinged on #ubuntu-release and seb128 was so kind to help after a short discussion on the reasons. So on nut all we have to do is wait a bit and it should (tm) resolve.

Qemu

There is a qemu 4.0 with some CVEs hanging on failed build. But Christian has a qemu 4.2 soon to be ready that works and will fix the same issues (and more).

nss

Is blocked by some JDK tests on arm Two of them seem odd and always fail or skip. The only one that sometimes works is http://autopkgtest.ubuntu.com/packages/o/openjdk-lts/focal/arm64 The result is literally "jdk FLAKY timed out" For now Christian restarted, but maybe the test should be masked. @Doko - from the uploader it seems you handle openjdk-lts opinions on how to handle its tests?

crmsh

tests block on new python3-default "crmsh.minieval.FeatureNotAvailable: Sorry, Constant is not available in this evaluator" The issue is reproducible outside the test environment. It seems ast processing changed in py3.8 Found other changes like "py3.8 uses ast.Constant instead of ast.Num, ast.Str, ast.NameConstant" in other projects. Seems crmsh needs py3.8 fixes for ast. Christian came up with a fix and submitted it upstream for review and integration

DPDK

DPDK breaks indirectly on the new python as well. The tests have a unversioned python dependency that e.g. breaks pciutils now. Christian has a fix in Debian already - needs an upload to debian to merge it from there.

Pacemaker

Pacemaker has been stuck for a while. Andreas believes the current blockage is due to python3.8. He somewhat traced it down to: pacemaker -> pacemaker-resource-agents -> resource-agents -> cluster-glue -> python3.8 -> libpython3.8-stdlib -> libffi

cluster-glue

Andreas recently rebuilt cluster-glue, which was still using python3.7, but more is needed.

Samba

Regarding samba, Andreas had to merge two i386 hints (for samba/i386 and tdb/i386), trigger rebuilds after ldb/talloc/tdb were uploaded, and kick new test runs with specific triggers to sort out tdb runs with plinth and samba itself.

sssd

sssd has an FTBFS with python3.8, which Andreas started to troubleshoot last night (Mon Jan 27, 2020) and will continue today. That rebuild needs to work to unblock all of this.

ldb

ldb is stuck because of python3-defaults, which still has many reds.

Current Transitions Notes

Cluster Stack Transition

There may be some residual items from this migration.

Python 2 Deprecation

Doko writes, "One more update, the unversioned python packages are now gone in focal. There will be some cleanup to do for NBS and build dependencies. A more complete follow-up will be sent next week. I removed a lot of packages from focal to get this done. Apologies if that affects any derivative. Please contact me on irc or via email to restore those package. However I don't have the resources to actively port these packages to Python3."

Python 3.8 Transition

These items appear blocked due to the https://people.canonical.com/~ubuntu-archive/transitions/html/python3.7-8.html python 3.8 transition.

On Focal tests related to python Christian has seen a zillion of these "/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used". None in server packages, but some cleanup for that is likely to follow.

Final Notes

The proposed migration list is highly volatile; packages come and go on a regular basis. So, if this page's last update is more than a few days ago it is probably outdated. If it hasn't been updated in a few weeks, it's probably obsolete. (And if it hasn't been updated in a few months, please feel free to delete it since it's evidently no longer used.)