+1 maintenance report

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

+1 maintenance report

Olivier Tilloy
Hello everyone,

I was scheduled for two full days of +1 maintenance duty this week
(Wednesday and Thursday), but other urgent tasks meant I only did it
part-time and spread over 3 days.
Here are some notes of what I looked into and the actions I took (also
including notes from a partial shift I did two weeks ago).

gettext was FTBFS on armhf (https://launchpad.net/bugs/1910792), I
cherry-picked an upstream commit to fix it, and uploaded
0.21-3ubuntu1.
It was then FTBFS on i386 because dh-elpa pulls in [emacs-nox | emacs]
which isn't built on i386. Laney suggested moving dh-elpa to
Build-Depends-Indep, and I ended up doing that but with
dh-sequence-elpa instead, which required a dh-elpa upload
(2.0.6ubuntu1), after which I uploaded gettext 0.21-3ubuntu2.
This should unblock the following:
  * FTBFS on i386 caused by a b-d on gettext: gnulib
  * b-d on gettext: gkdebconf, puppetlabs-i18n-clojure
  * depends on gettext: kdesdk-thumbnailers, poxml, wine

emacs was FTBFS on almost all architectures, this was caused by new
unit tests requiring DNS lookup (https://launchpad.net/bugs/1911209).
I uploaded 1:27.1+1-3ubuntu2 with a patch to skip those tests.
After that, s390x was still FTBFS because of a consistently failing
unit test (https://launchpad.net/bugs/1911236), I spent a bit of time
investigating it and found that the regression most likely happened
with the toolchain update in Groovy, but I didn't go to the bottom of
it, and xnox did a new upload (1:27.1+1-3ubuntu3) skipping that test.
The bug remains open for future investigation.

rust-smallvec autopkgtests failed on all architectures because of
using const generics.
I re-ran them with an additional trigger on rustc 1.47.0 in -proposed,
and it successfully migrated.

glib-d is FTBFS on armhf, riscv64 and s390x.
On architectures where it builds successfully, the D compiler used is
ldc2. Where it fails to build, gdc is used.
I tested building with ldc2 on armhf (by hand-editing
/usr/share/dh-dlang/dlang-flags.mk to whitelist it) and the build
succeeded, so it looks like a gdc bug to me.
Building with ldc2 on all architectures is not an option, because it's
only available on amd64, arm64 and armhf.
So we need to look into that gdc bug, but I'm D-illiterate and I ran
out of time.

 Olivier

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel