<div dir="ltr">Subject: Triage and Proposed-Migration Report for Friday<br><br>## Triage ##<br><br>I've got 14 bugs to look at (and did a few more of paride and andreas that got punted due to feature freeze frenzy).<br><br>A few needed some minor triage, but none was needing further big effort.<div><br></div><div>I picked some more waiting triage days and got 32 more bugs.</div><div>A few even got into out queues that need further work, of those worth mentioning are two:</div><div><br></div><div><a href="https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1864555">https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1864555</a></div><div>This seems to be a change due to the merge that should be analyzed before 20.04 is final.</div><div>@Rafael I assigned you for now to take a look as you did the merge.<br><br><a href="https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1864338">https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1864338</a></div><div>IPv4 issues with nmbd, I feel like I had heard Andreas mention that.</div><div>@Andreas - could you answer on that bug if it is a known issue (maybe a dup) or something new we really need/want to look at?<br></div><div><br><br><div>In general the subscription and server-next queue are rather full now.</div><div>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.</div><div><br>## Proposed Migration ##<br><br>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.<br><br>Therefore after talking with bryce I was taking a look at arm build issues of <a href="https://launchpad.net/ubuntu/+source/php-msgpack">https://launchpad.net/ubuntu/+source/php-msgpack</a> to help the php migration to go on.<br><br>Seeing a build time test fail on armhf&arm64:<br><br>TEST 35/132 [tests/034.phpt]<br>XFAIL Unserialize invalid random data [tests/034.phpt]   XFAIL REASON: REGRESSION<br>TEST 36/132 [tests/035.phpt]<br>FAIL Profiling perf test. [tests/035.phpt] <br>TEST 37/132 [tests/040.phpt]<br>SKIP broken random data test [tests/040<br><br>On an arm64 cloud instance I uprgaded to focal-proposed and ran the build there.<br>And of course for the loacl test there I got:<br>Number of tests :  132               128<br>Tests skipped   :    4 (  3.0%) --------<br>Tests warned    :    0 (  0.0%) (  0.0%)<br>Tests failed    :    0 (  0.0%) (  0.0%)<br>Expected fail   :    1 (  0.8%) (  0.8%)<br>Tests passed    :  127 ( 96.2%) ( 99.2%)<br><br>While the one breaking on LP has:<br>Number of tests :  132               128<br>Tests skipped   :    4 (  3.0%) --------<br>Tests warned    :    0 (  0.0%) (  0.0%)<br>Tests failed    :    1 (  0.8%) (  0.8%)<br>Expected fail   :    1 (  0.8%) (  0.8%)<br>Tests passed    :  126 ( 95.5%) ( 98.4%)<br><br>:-/<br><br>Tests ran against 7.4 as intended (and as in the failing case):<br>PHP         : /usr/bin/php7.4 <br>PHP_SAPI    : cli<br>PHP_VERSION : 7.4.3<br>ZEND_VERSION: 3.4.0<br><br>As silly as it is, I was retrying the LP build to see if it would change.<br><br>FYI and probably related:<br>- (other) 7.4 FTBFS fails on Debian: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952204">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952204</a><br>- upstream report old but still ongoing <a href="https://github.com/msgpack/msgpack-php/issues/123">https://github.com/msgpack/msgpack-php/issues/123</a><br><br>On the latter they mention (<a href="https://github.com/msgpack/msgpack-php/issues/123#issuecomment-568308971">https://github.com/msgpack/msgpack-php/issues/123#issuecomment-568308971</a>) that the test is dependent on the build-env "speed" and might fail on slow ones.<br>This might be exactly what differs between the build env on LP and my 8 core arm64 test box.<br><br>I can rerun the tests in my environment via<br>$ cd build-7.4<br>$ make test<br><br>As-is I pass the test in 9/10 runs (but not always) of the cases usually running in 15-17 seconds.<br><br>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.<br><br>At the builders a run takes ~20 seconds and have less CPUs.<br>So this might really just be unreliable to be run in build environments.<br>Let us skip the test and be good with it.<br><br>@Bryce - please try it with this debdiff (attached)<div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Christian Ehrhardt<br>Staff Engineer, Ubuntu Server<br>Canonical Ltd</div></div></div></div></div>