© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Those are mostly all flaky tests which is usual for apache2. (It would be helpful if autopkgtest would re-run such failures automatically since this is so common with its infrastructure). I've retriggered all these and for Jammy they all passed except for piuparts.
piuparts fails because of a known issue in debootstrap (LP: #2020530), since debootstrap needs an SRU update every cycle to add the new devel release codename (i.e. LP: #1995612 (lunar), LP: #1970454 (kinetic), LP: #1947362 (jammy), LP: #1925753 (impish)) and it has not yet been updated for mantic. That's "not a real regression"[1] for apache2 but I guess just a perennial problem that happens at the start of each new development cycle.
1: https:/
On Kinetic, there still seems to be some trouble with backuppc on one arch (which I've retriggered once again in case its a persistent flaky issue). Also, all the apache2 tests fail here due to a 403 permissions error in one of t/apache/mmn.t's test cases. I'm unclear why that fails on kinetic but not jammy, but it's doing so for all architectures so seems more than just flakiness. It does not seem like this relates to the change for this bug, but I don't have evidence to definitively convince me of that.
So, on the jammy side I think the SRU can proceed to release. Kinetic is probably ok but needs more sleuthing.