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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
