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
