<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2020 at 5:40 AM Bryce Harrington <<a href="mailto:bryce.harrington@canonical.com">bryce.harrington@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">## Proposed Migration ##<br>
<br>
I again collected everyone's recent proposed migration notes, and this<br>
time as an experiment stuck them in wiki:<br>
<br>
<a href="https://wiki.ubuntu.com/ServerTeam/ProposedMigrationNotes" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/ServerTeam/ProposedMigrationNotes</a><br>
<br>
It would be nice to keep per-package notes in the update-excuses page,<br>
but from our meeting with slangasek it's clear that's easier said than<br>
done. I'm wondering if keeping those notes in a wiki would be "the next<br>
best thing" to that, or if it'd just be "one more thing to have to<br>
check". Give it a shot, see what you think.<br></blockquote><div><br></div><div>Feedback from just a few hours with it:</div><div>Pro:</div><div>- having one place to look at is nicer than re-reading multiple mails</div><div>Con:</div><div>- too bad it isn't the one place (excuses) everyone looks for</div><div>- feels like doubling the work, if we do wiki (or anything else like a trello board) we should then stop the mails</div><div> - but I think the mails reach more people I unfortunately doubt as many people will look at wiki/board :-/</div><div><br></div><div>Overall rating: I liked the mails more, but could live with it - maybe trello instead of wiki seems to feel better to me (personal opinion)</div><div><br></div><div><br></div><div>P.S. updating the wiki now as postgresql-12/postgresql-common/postgresql-pgmp/crmsh things are done.</div><div>I also did the test reruns to unblock python3-defaults which blocked on it as well.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
### re2c ###<br>
<br>
In addition to collecting the various info, I looked just a little into<br>
re2c.<br>
<br>
This is blocked on i386 due to a bunch of test failures, including some<br>
relating to "stadfa", and a scattering other others.<br>
<br>
Debian ran into a build issue due to a build date in the manual page<br>
which they've fixed in this version. Debian has an unreleased 1.3-2 that<br>
contains a build-dep for python3-pygments (this doesn't appear related<br>
to the test failure afaict.)<br>
<br>
The autopkgtest essentially just runs the upstream testsuite, which<br>
passes fine on i386, so the issue presumably is due to something<br>
distinct about the autopkgtest platform/hardware/set-of-x86-features...?<br>
<br>
LP: #1859980 is open for this migration issue.<br>
<br>
<br>
## Bug Triage ##<br>
<br>
Date range identified as: "Wednesday triage"<br>
Found 21 bugs<br>
<br>
Most took no action. Items of note below:<br>
<br>
LP: #1853760 - (Expired) [php7.2] - php 7.2 has dependency problems and they are not letting to update apache2 and php7.2 * modules<br>
* Still not enough info to troubleshoot (the provided logs don't cover<br>
the time period when the error occurred).<br>
* Looks like a typical update error where an unrelated service is left<br>
unconfigured.<br>
--> Gave general advice for resolving apt issues with unconfigured<br>
services.<br>
--> Set to incomplete.<br>
<br>
LP: #1821729 - (New) [edk2] - UEFI in ovmf package causes kernel panic<br>
* Debian maintainer had been advising previously.<br>
* Re-ping for status on this bug.<br>
--> Gave some advice on next steps, to do git-biset, or a process trace,<br>
or else exact steps to reproduce and/or simplified test case.<br>
<br>
LP: #1861177 - (New) [libseccomp] - seccomp_rule_add is very slow<br>
* Fix identified and proposed in Debian for inclusion<br>
* Looks pretty close to patch-on-a-plate, and appears needed by Canonical <br>
--> Attached patch<br>
--> Marked triaged<br>
--> Tagged server-next<br>
<br>
LP: #1861222 - (New) [libvirt] - Libvirt parallel shutdown is not truly parallel when agent-based shutdown is used<br>
--> Asked if it affects current libvirt as well, or only on 18.04<br>
<br>
<br>
Bryce<br>
<br>
-- <br>
ubuntu-server mailing list<br>
<a href="mailto:ubuntu-server@lists.ubuntu.com" target="_blank">ubuntu-server@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-server" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-server</a><br>
More info: <a href="https://wiki.ubuntu.com/ServerTeam" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/ServerTeam</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Christian Ehrhardt<br>Staff Engineer, Ubuntu Server<br>Canonical Ltd</div></div>