Triage report ("Monday triage")

Tue Nov 26 06:55:20 UTC 2019

On Tue, Nov 26, 2019 at 6:03 AM Bryce Harrington
<bryce.harrington at 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 at 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