Triage report - Monday Triage
Ubuntu Server Bug List Team 'ubuntu-server' currently subscribed to 412 bugs --- Bugs last updated between 2020-06-26 (Friday) and 2020-06-28 (Sunday) inclusive Date range identified as: "Monday triage" Found 26 bugs https://pad.lv/1885417 - (New)[rdma-core] - rxe_cfg is missing > manpages.ubuntu.com copied pages from eoan > perhaps man pages are not being deleted from one release to another > source package did not include that page any longer (rdma-core) > added to server-triage discuss > moved to ubuntu documentation project https://pad.lv/1885419 - (New)[qemu] - QEMU crash using virtio-scsi with iothread > this was a critical bug and as soon as I got into it I started > working. tested eoan to see if the issue happened in bionic only > because of the previous aarch64 SRU. bisected the 6 patch SRU changes > and saw that the *real* fix did not cause the issue. Issue was a > side effect of moving an assertion out of a condition in AIO code. > This is tricky because it could be caused by the existent bionic > qemu code AND any attempt of fix would require a big round of > tests, now including iothreads. > asked @paelzer to revert the SRU and he, thankfully, together > with @racb, did a very fast SRU reverting the change, after had > already asking AA to phase the change. --- Bugs tagged 'server-next' and not touched in 60 days Found 0 bugs --- Bugs in backlog and not touched in 180 days Found 0 bugs -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Triage report ("Monday triage")
On Tue, Nov 26, 2019 at 6:03 AM Bryce Harrington
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
Triage report ("Monday triage")
## 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:
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
Triage report ("Monday triage")
## Triage ## This was to cover bugs touched from Monday through Sunday. The only bug worth mentioning is LP: #1852758, which was another instance of a user with a custom MySQL configuration failing the upgrade because MySQL 8.0 invalidates some old configuration directives. I think we're getting a good collection of these now. Perhaps we can adjust the postinst to cover the common cases automatically for users in time for 20.04. ## Proposed Migration ## I struggled with this. It wasn't clear to me at all which entries have previously already been investigated from quite a big list, even with examining previous reports to this list. Surely most of them have already been looked at? It wasn't practical to look at them all during my shift. This continues my general opinion that having this on a daily rota is not an effective way of helping with proposed migration, since there's little record of progress on an individual package basis and so it just seems like a load of duplication of effort. I did look at mysql-8.0 blocking lz4. This needs fixing in the upstream MySQL test suite to accomodate changes in lz4. I filed LP: #1853144 and it turns out that Marc has simultaneously been working on it. signature.asc Description: PGP signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
