On Tue, Nov 26, 2019 at 6:03 AM Bryce Harrington <bryce.harring...@canonical.com> wrote: > > ## Bug Triage ## > > Date range identified as: "Monday triage" > Found 10 bugs + 3 backlog > > Only these needed any action: > > LP: #1853494 - *(Confirmed) [mysql-5.7] - Add back WITH_SSL build > parameter > * Security needs reproducer. User provided workaround + stack trace. > * The suggested patch looks minimal and SRU-able to me. > --> Set to Incomplete and clarified what's required > > LP: #1853636 - (New) [mysql-5.7] - Client SSL connection > errors in 5.7.28 > * The provided error message seems to be generic, just indicates version > mismatch between client and server. However, since this was caused by > a stable update, seems to qualify as a legit regression and might need > priority attention once understood. > --> Requested logs, since none were provided. > --> Marked regression-release > > LP: #1641238 - (Triaged) [apache2] - as a reverse proxy, a 100 > continue response is sent prematurely when a request contains expects: > 100-continue > * Fix has been backported upstream, though not to the specific Apache > versions xenial/trusty/bionic we have > --> Added respective bug tasks, medium priority > > LP: #1782650 - (Triaged) [nagios-nrpe] - nrpe plugin in bionic > fails with Error - Could not complete SSL handshake > * The bionic package expects v3 (2048-bit) keys and refuses to work with > older keys. Users would like a workaround to make it accept v2 keys. > * If I understand it, bionic <-> bionic and bionic <-> newer are > unaffected. > --> Added bug task for bionic, but eventually everyone will have to > upgrade their keys anyway. Don't see a need to bump priority up from > Medium at this point. > > > ## Proposed Migration ## > > * psmisc's log looks like it hit a network error on armhf > (connection timed out trying to reach ftpmaster.internal) > -> Requested a rebuild > > * libseccomp is blocked by systemd, which is failing autopkgtest on i386 > and s390x for two tests, 'root-unittests' and 'upstream'. Looks like > they've gotten re-test requests already by paelzer. The failure for > 'root-unittests' appears to happen with this part of the log:
That is what I talk about every now and then. I continue to work on this as time between other tasks permits. There is a bug for it: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852 > Failed to add shmat() rule for architecture x86, skipping: Invalid argument > Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function > test_memory_deny_write_execute_mmap(). Aborting. > memoryseccomp-mmap terminated by signal ABRT. > Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, > WAIT_LOG) == EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, > function test_memory_deny_write_execute_mmap(). Aborting. > FAIL: test-seccomp (code: 134) > > s390x has similar output. > > I couldn't discern where the 'upstream' test case was failing. > > * dovecot is marked "Valid candidate", but the reason it's on the excuses > page is due to dovecot-antispam which apparently has an api version > dependence and needs no-change rebuilds. > > -> Uploaded a no-change rebuild (not sure of the correct procedure, > but this seems to be what's been done before.) > > * exim4 was blocked, and sent me an email that it was stuck on the 22nd, > but it seems not to be on the list today. Maybe something already > unstuck it? > > * pyjwt is maybe stuck due to python-oauthlib? > > * 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 > > * 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. > > * subunit is stuck due to python-autopilot-trace (ppc64el) > > -- > ubuntu-server mailing list > ubuntu-server@lists.ubuntu.com > 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 ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
