Hi folks!
I was on +1 maintenance from April 17-20, which was Lunar's release week, too.
In order not to interrupt the release process with non-critical uploads, I
created a PPA and uploaded my stuff into it using the "devel" series, so the
packages can be copied over into the main archive, once it re-opens:
https://pad.lv/ppa/slyon/plusone-lunar
PPA autopkgtests can be found in:
https://autopkgtest.ubuntu.com/results/autopkgtest-lunar-slyon-plusone-lunar/?format=plain
You can find the previous +1 report from @ginggs here:
https://lists.ubuntu.com/archives/ubuntu-devel/2023-April/042549.html
### tinyssh ###
tinyssh / 20230101-1ubuntu1
This package has been stuck in -proposed for at least a year, skipping many new
(upstream) versions in -proposed. Its -proposed version broke many systemd
autopkgtest (and probably others), leading to unnecessary test runs to validate
those failures with tinyssh from -release.
Ubuntu's PAM configuration sets the user-session default umask to 0002 (instead
of the traditional 0022), as defined in "/etc/login.defs" via USERGROUPS_ENAB
(see /etc/pam.d/common-session*). Therefore, the autopkgtest (re-)creates
~/.ssh/authorized_keys with group-write permissions, which makes tinysshd reject
connections.
Furthermore, we had the test launching "tcpserver", which launched "tinyssh" and
that one launched a subcommand (e.g. "ftpd") in the background. On slower
testbeds (mostly s390x and ppc64el ) this chain of commands led to flaky
failures, due to the subcommand not being ready, when the test commands started
execution. I fixed that by introducing a small delay ("sleep 1") after launching
"tcpserver", as done in the corresponding Python based testcase ("02handshake").
https://pad.lv/2016597
https://bugs.debian.org/1034512
https://bugs.debian.org/1034513
### clasp ###
clasp / 3.3.5-4.2ubuntu1
clasp FTBFS on s390x due to a test failure, while it passes build on Debian
s390x. It has been using GCC-10 explicitly before, but was upgraded to use the
GCC-12 toolchain. Disabling LTO fixes the build/tests with GCC-12.
This will be fixed via lto-disbaled-list, which already contains clasp for arm64
and ppc64el.
https://bugs.debian.org/1034521
https://bugs.launchpad.net/ubuntu/+source/lto-disabled-list/+bug/2017091
### elementpath ###
elementpath / 3.0.2-1
This shows an autopkgtest regression for python-xmlschema/1.10.0-3. It's
supposed to be fixed in xmlschema 2.0.0, but it's probably not worth moving
ahead of Debian just to fix this autopkgtest failure. Let's just wait for the
new version to land. I created an 'update-excuse' bug to make people aware of
this.
https://pad.lv/2016699
https://bugs.debian.org/1027439
https://github.com/sissaschool/xmlschema/commit/52c3147
### ubuntu-archive-assistant ###
uaa / 20190919+gitr+f4a0d0c
Ubuntu Archive Assistant is a nice helper tool that supports people, especially
newcomers, with proposed-migration (and therefore +1 maintenance work). I've
recently discovered this old tool and felt like it makes sense to revive it.
It needed a few small fixes to make the `./uaa proposed` subcommand work with
today's infrastructure. It will automatically provide its user with the next
package to work on and the next steps to take on that package, all nicely
formatted (and colorful). Two examples are provided below:
```
$ ./uaa proposed -s tinyssh
Next steps for tinyssh 20230101-1:
Fix autopkgtests triggered by this package for:
E: Keine Pakete gefunden
tinyssh/20230101-1: arm64, amd64, armhf, ppc64el, s390x ✘
http://autopkgtest.ubuntu.com/packages/p/tinyssh
Consider submitting a PR for bad tests (if they can't be fixed)
```
```
$ ./uaa proposed
No source package name was provided. The following packages are blocked in proposed:
(1) gkrellm2-cpufreq (Age: 721 days)
(2) tiledarray (Age: 471 days)
(3) bettercap-caplets (Age: 164 days)
(4) kgb-bot (Age: 164 days)
(5) node-address (Age: 164 days)
[...]
Page -1-. Press any key for next page or Q to select a package.
q
Which package do you want to look at?
5
Next steps for node-address 1.2.1-1:
Fix autopkgtests triggered by this package for:
node-address/1.2.1-1: ppc64el ✘
http://autopkgtest.ubuntu.com/packages/p/node-address
Consider submitting a PR for bad tests (if they can't be fixed)
```
http://blog.cyphermox.net/2018/09/help-needed-to-improve-proposed.html
https://code.launchpad.net/~slyon/ubuntu-archive-assistant/+git/master/+merge/441438
### node-address ###
node-address / 1.2.1-1ubuntu1
This package showed two stacked autopkgtest failure cases:
1/ flaky timeouts, especially on slow testbeds (ppc64el/s390x).
I increased the mocha timeout from 20 sec to 60 sec to avoid it hitting the
timeout if the queues are loaded. I wasn't able to fully reproduce this issue,
but could see it taking 17-18 sec on a ppc64el Canonistack m1.small instance,
which is almost the timeout. Flaky failures were visible for some testruns on
DebCI and autopkgtest.ubuntu.com. I filed a bug+patch with Debian to resolve
this.
2/ Upstream did some refactoring of the tests in v1.2.1 which (accidentally?)
dropped some null-pointer checks, that lead to a "string vs null" assertion in
some cases:
AssertionError [ERR_ASSERTION]: The "string" argument must be of type string.
Received type object (null)
I filed a PR with the upstream project, explaining all the details and proposing
a patch to fix the issue.
https://bugs.debian.org/1034603
https://github.com/node-modules/address/pull/35
### eztrace ###
eztrace / 2.0+repack-11
As Graham stated in the previous +1 maintenance report, disabling LTO makes the
build/tests (mostly) pass, but it still fails for the "OMPT_ARCHS" (amd64 arm64
i386 ppc64el riscv64), as defined in d/rules.
This can be done via lto-disabled-list or d/rules:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto
I tried a few different things in eztrace to make the toolchain mimic the Debian
build (which passes):
* Switch to clang-14:
CC=clang-14 in d/rules and clang-14 & libomp-14-dev B-Ds in d/control
* Strip Ubuntu's -Bsymbolic-functions optimization from the linker flags
export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions in d/rules
But didn't have any success with the above changes.
Then I noticed LP: #1899199, which indicates the root-cause being in the libomp5
dependency instead of eztrace itself, i.e. llvm-toolchain-* (or libomp.so.5
specifically) needs to be build without the -Wl,-Bsymbolic-functions LDFLAGS
optimization. This seems to be the case!
After downloading relevant binaries from Debian
(https://packages.debian.org/source/sid/llvm-toolchain-15), I was able to build
eztrace successfully (with just LTO disabled, but no other changes):
sbuild --extra-package ../libomp5-15_15.0.7-4_amd64.deb --extra-package ../libomp-15-dev_15.0.7-4_amd64.deb -dlunar .
https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1899199
https://bugs.launchpad.net/ubuntu/+source/eztrace/+bug/2016471
### rust-zram-generator ###
rust-zram-generator / 1.1.2-2ubuntu1
This package FTBFS on LLVM-15 when LTO is enabled in Cargo.toml due to rustc
generating invalid DWARF data. dh_dwz gives and error like this: "Couldn't find
DIE at [55d39] referenced by DW_AT_abstract_origin from DIE at [25457]"
I worked around this issue by disabling dwz for the time being.
https://github.com/rust-lang/rust/issues/66118
https://bugs.debian.org/1034632
### Sync, dropping deltas ###
a2jmidid / 9-3 => applied in Debian
python-structlog / 22.3.0-2 => applied upstream
markdown-it-py / 2.1.0-5 => applied in Debian
bbswitch / 0.8-15 => applied in Debian
libuninum / 2.7-1.2 => deprecated by Debian (migrated to dh)
matplotlib / 3.6.3-1 => applied in Debian
dtfabric / 20221218-1 => applied upstream
### TODO ###
Here you can find some hints for follow-up work.
* Review UAA:
https://code.launchpad.net/~slyon/ubuntu-archive-assistant/+git/master/+merge/441438
* Fix llvm-toolchain-15 (libomp.so.5) build:
https://pad.lv/2016471
* Copy packages from +1 PPA into the archive, once re-opened:
https://launchpad.net/~slyon/+archive/ubuntu/plusone-lunar
- lto-disabled-list needs to be uploaded/published before clasp & eztrace
Cheers,
Lukas
