Triage and Migration for Friday

Fri Feb 28 19:36:07 UTC 2020

On Fri, Feb 28, 2020 at 10:30:05AM +0100, Christian Ehrhardt wrote:
> In general the subscription and server-next queue are rather full now.
> Let us maybe next week sit down and assign bugs from this queue to team
> members to get this down - especially for bugs that should/could be fixed
> in 20.04 before release to then SRU things while the release is in its
> latest hardening steps where it is hard to upload 20.04 packages anyway.

I just took a browse through, and while the queue does look full, about
a third to half are already well underway or a fix is already in.  We've
also been focusing lately more on transitions and merges, so with FF
past we can expect many of those bugs will naturally resolve on their
own.

So, filtering ones that appear to be covered, and categorizing what
remains:

## Databases ##
 #1831773 High CPU usage, MySQL process got stuck on "SHOW SESSION VARIABLES LIKE 'FOREIGN_KEY_CHECKS' "

## Web Server & Database ##
 #1832182 systemd unable to detect running apache if invoked via "apache2ctl graceful"
 #1850933 after upgrade 19.04 to 19.10, apache serves php code
 #1842701 Apache2 Balancer Manager mod_proxy_balancer not working after Update
 #1820288 Tomcat Web Application Manager does not copy context configuration

## Security ##
 #1861177 seccomp_rule_add is very slow
 #1849560 Please revise the files installed in /etc/
 #1853021 ssl-cert generate-default-snakeoil provides no way to override default 10 year expiration or reduc\
e to 825 day expiration
 #1844173 libwbclient-sssd package installation does not re-create expected symlink to libwbclient.so.0

## Other ##
 #1843804 Ruby - DEP8 segfault on arm64
 #1864612 requests ipmi-tool to include lasted patch for supporting quanta server
 #1785383 systemd - missing EDNS0 record confuses systemd-resolved
 #1851695 notary - DEP8 failure/regression in nspr on arm64 and armhf
 #1864555 upgrade if multipath-tools results in modprobe error messages

Note there is also a list of bugs our team is "related" to (subscribed,
assigned, etc.):

  https://bugs.launchpad.net/~canonical-server

There are 59 items on this list.  Many of these are redundant, already
fixed, or are SRUs against old ubuntu versions.  But this might be
another list worth grinding down.

I also looked for bugs with patches, since they could be
'patch-on-a-plate' opportunities, however all the ones I found are
already shown on the above lists.

For X.org, I used to have a report of "bugs against all X.org packages
that are fixed upstream."  This was a valuable list for easy post-FF
cherrypicks.  Do you know if we have such a report for server components?

> ## Proposed Migration ##
> 
> I've actually worked on this for a few days now unstucking libnbd/nbdkit as
> well as helping to get the new set of updates for azure-cli done. Nothing
> big to mention individually.
> 
> Therefore after talking with bryce I was taking a look at arm build issues
> of https://launchpad.net/ubuntu/+source/php-msgpack to help the php
> migration to go on.
> 
> Seeing a build time test fail on armhf&arm64:
> 
> TEST 35/132 [tests/034.phpt]
> XFAIL Unserialize invalid random data [tests/034.phpt]   XFAIL REASON:
> REGRESSION
> TEST 36/132 [tests/035.phpt]
> FAIL Profiling perf test. [tests/035.phpt]
> TEST 37/132 [tests/040.phpt]
> SKIP broken random data test [tests/040
> 
> On an arm64 cloud instance I uprgaded to focal-proposed and ran the build
> there.
> And of course for the loacl test there I got:
> Number of tests :  132               128
> Tests skipped   :    4 (  3.0%) --------
> Tests warned    :    0 (  0.0%) (  0.0%)
> Tests failed    :    0 (  0.0%) (  0.0%)
> Expected fail   :    1 (  0.8%) (  0.8%)
> Tests passed    :  127 ( 96.2%) ( 99.2%)
> 
> While the one breaking on LP has:
> Number of tests :  132               128
> Tests skipped   :    4 (  3.0%) --------
> Tests warned    :    0 (  0.0%) (  0.0%)
> Tests failed    :    1 (  0.8%) (  0.8%)
> Expected fail   :    1 (  0.8%) (  0.8%)
> Tests passed    :  126 ( 95.5%) ( 98.4%)
> 
> :-/
> 
> Tests ran against 7.4 as intended (and as in the failing case):
> PHP         : /usr/bin/php7.4
> PHP_SAPI    : cli
> PHP_VERSION : 7.4.3
> ZEND_VERSION: 3.4.0
> 
> As silly as it is, I was retrying the LP build to see if it would change.
> 
> FYI and probably related:
> - (other) 7.4 FTBFS fails on Debian:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952204
> - upstream report old but still ongoing
> https://github.com/msgpack/msgpack-php/issues/123
> 
> On the latter they mention (
> https://github.com/msgpack/msgpack-php/issues/123#issuecomment-568308971)
> that the test is dependent on the build-env "speed" and might fail on slow
> ones.
> This might be exactly what differs between the build env on LP and my 8
> core arm64 test box.
> 
> I can rerun the tests in my environment via
> $ cd build-7.4
> $ make test
> 
> As-is I pass the test in 9/10 runs (but not always) of the cases usually
> running in 15-17 seconds.
> 
> With background load hogging my CPU/kernel/Randomness (stress-ng -c 8
> --x86syscall 8 --urandom 8 --rdrand 8 --metrics-brief --getrandom 8) I get
> reliable fails 5/5 runs in ~30 seconds runtime.
> 
> At the builders a run takes ~20 seconds and have less CPUs.
> So this might really just be unreliable to be run in build environments.
> Let us skip the test and be good with it.
> 
> @Bryce - please try it with this debdiff (attached)

Thanks for working this.  I'll take this on my todo list for next week.
I also grabbed assignment on the bug you filed for php followup work.

Bryce