Monday, 28 July 2025

+1 Maintenance Report - Week 29, 2025

cross-post from
https://discourse.ubuntu.com/t/1-maintenance-report-week-29-2025/65212

# +1 Maintenance report from 21 July to 27 July
I mostly worked on clearing some of the things on the update_excuses
page. I encountered a bug with
[autopkgtest-tools](https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2118909)
on my Pi 5, so I had to rely on the prodstack for autopkgtest runs.

## Work-needed items

* [borgbackup2](https://bugs.launchpad.net/ubuntu/+source/borgbackup2/+bug/2118916)
- more investigation required
* [python-pbr](https://bugs.launchpad.net/ubuntu/+source/python-octaviaclient/+bug/2118836)
- more investigation required
* [valkey](https://bugs.launchpad.net/ubuntu/+source/redis/+bug/2118952)
- more investigation required

### Sponsorship needed

* [node-form-data
fix](https://bugs.launchpad.net/ubuntu/+source/node-form-data/+bug/2118850)
- sponsor required
* [endless-sky](https://bugs.launchpad.net/ubuntu/+source/endless-sky/+bug/2117461)
- sponsor required

## Full logs

* **node-form-data**: There was a fix for CVE-2025-7783 in Debian, but
it changes the boundary string length, which failed autopkgtests
relying on payload size assertions. The fix applied upstream was
different from the one done in Debian, and that kept the length same.
I have created an MP to alter the fix to mimic the behaviour upstream,
and opened an MR in salsa as well.
* **endless-sky**: One of the tests used `abs()` but expected it to be
`std::abs(double)`. The default `abs()` on arm64 was returning int
instead of double. This was fixed by using cmath's `abs()`.
* **borgbackup2**: Pending migration since the new autopkgtests were
added to it. These tests do run during build, so running them again is
a bit redundant. The tests fail to run as the coverage config is not
available - and I believe running them without `pytest-cov` should
work right now (as we don't know what is the coverage threshold, which
should have been in the `.coveragec`). I didn't spend a lot of time
with this as iterating with prostack autopkgtests using a PPA was
slow.
* [**python-lua**](https://bugs.launchpad.net/ubuntu/+source/python-lua/+bug/2118922):
This is a bit interesting. The autopkgtests fail and it looks like it
needs some serious work. According to other issues and the commits on
the project upstream, it looks like it is being overhauled, along with
syntax changes (which are not documented yet). Instead of trying to
fix this myself, I have filed a bug upstream to make the author aware
of the autopkgtest failure. They might fix the changes in syntax or
write new tests for this package. Not much we can do here for now.
* **python-pbr**, **python-octaviaclient** - This is blocking the
migration of rally-openstack. At first glance it looked like
`python-pbr` does not account for `.*+dfsg.*` or `.*+git.*` like
patterns in the version string. It has a `LocalDebVersion` class, but
it just parses the pip version into a debian version. However, on
going further, I noticed that the autopkgtest files set the
`PBR_VERSION` and `OSLO_PACKAGE_VERSION` env vars, which should have
short-circuited the version determination in python-pbr entirely, but
it doesn't. I didn't go further here.
* **autopkgtest-tools**: This was one of the reasons why I couldn't
run a lot of the tests locally and had to wait for packages to get
published in a PPA and then run the tests for each iteration. The qemu
backend fails with -EBADF during the cloud-init run. I tried different
image sizes, increasing the memory to the VM and the nmuber of CPUs
too, but it still ends up in failure. The failure does not seem to
have a consistent trigger and looks like a resource issue. In
hindsight I should've spent more time on this, as that would have made
fixing others things faster.
* **valkey**, **redis**: I have detailed my findings
[here](https://bugs.launchpad.net/ubuntu/+source/valkey/+bug/2118952/comments/1).
I think this is due to not being able to write to the logfile, but I
didn't test this fix. I checked for the differences in redis.conf and
valkey.conf, and the logfile change sticks out, along with the pidfile
change. I checked the valkey postinst files, and while they do account
for the path change of redis dumps and confs, they do not move the
logfile.

Regards
Pragyansh

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel