## Triage
This covers some days I didn't get to while away, it is about:
- Bugs last updated on 2019-12-19 (Thursday) - 5 bugs
- Bugs last updated on 2019-12-26 (Thursday) - 0 bugs
- Bugs last updated on 2020-01-02 (Thursday) - 1 bug
- Bugs last updated between 2020-01-03 (Friday) and 2020-01-05 (Sunday)
inclusive - 10 bugs
Most were the common "already under control" updates, the few worth
mentioning are.
- https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1858354
An uncomfortable high amount of crashes, could be common user error
hiding as crash.
Subscribed Rbasak/Lars for mysql specific triage.
- https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1858121
By analyzing the case I realized we can make smartmontools a sync.
I asked Lucas to cross check that assumption as he has done the last
merge.
If he is ok let us syncpackage it.
Some more needed discussions/clarifications but let these stay with me
until there is better feedback/data on the bugs.
A few were in the backlog and not touched in 180 days, but all those were
ok - turned out
## Proposed Migration
We started to see some expected hickups due to python2's python now really
being dropped and likely will see more throughout January.
If affected in most cases an old depency on "python" needs instead be
"python2" and ensure that the shebangs are correct on python2 as well.
Recent syncs of ipmitool and open-vm-tools that were seen before now passed.
Bryce just reported on the list yesterday - and yes many seem to be python
or i386 cases that are worked on. Therefore I took two other cases out of
the growing set:
#1 libseccomp - blocked on tests
I haven't seen anyone working on it recently, which is why I picked it.
The libseccomp2 seems to build and work fine, but python3-seccomp:i386
fails to install. See [1] for details
Tests depend on python modules and that eventually means python3:i386 and
that will remove the amd64 python3.
Test Dependency line is for example: libseccomp-dev, build-essential,
python3-seccomp
Following Steve on [2] we should ignore those cases, so I filed [3] waiting
for the release team to review that.
[1]:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/libs/libseccomp/20191219_132712_23efa@/log.gz
[2]:
https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040859.html
[3]:
https://code.launchpad.net/~paelzer/britney/hints-ubuntu-focal-libseccomp-i386/+merge/377222
#2) virtglrenderer - FTFBS on s390x
The breakage is a post-build self test that fails on s390x only.
I retried the build (to check if it is flaky) and at the same time set up
an s390x container that build 0.8.0 (former) and 0.8.1 (current) versions.
The old version fails 4 tests, the new one just one - test_virgl_cmd
Last build was in early November and back then no tests were executed.
[4] has all zeros under "Testsuite summary for virglrenderer 0.8.0"
So it seems Focal got better and now the tests really run.
Due to that many were failing, 0.8.1 got better (Debian packaging but one
still is broken.
I need to analyze the actual failure next, the new version also has two
CVEs fixed so we really want this.
BTW broken the same way in Debian [5], I thought it needs to have a valid
build to be synced - interesting.
It turned out to be most likely a big endian issue, I eventually reported
this upstream [6], depending on the feedback there we can fix/mask the test
for now.
[4]:
https://launchpadlibrarian.net/448457462/buildlog_ubuntu-focal-s390x.virglrenderer_0.8.0-2_BUILDING.txt.gz
[5]:
https://buildd.debian.org/status/fetch.php?pkg=virglrenderer&arch=s390x&ver=0.8.1-1&stamp=1576876548&raw=0
[6]: https://gitlab.freedesktop.org/virgl/virglrenderer/issues/153
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
