© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Running autoupdate, or any such tool (like autoreconf and others) in an SRU is a bit scary. The change it introduces to the configure script cannot be easily verified, as it's usually a huge diff.
What I would suggest for future SRUs of this type, is to think carefully about what could go wrong with such a fix. Mainly, that the new ./configure could detect different things, and build the binary in a different way. Which may be exactly what we want for the SRU (like in this case here), but still, it's a regression potential.
I would suggest to carefully check the ./configure output from before and now, to see what else might have changed. Or perhaps there is another tool to show us that from the resulting binaries (diffoscope perhaps?).
For this SRU, I did a quick check of the dependencies of the new jammy build, and they remained the same. I also checked the configure output between the build from the release pocket, and the build from the proposed pocket. Saw some differences of course, but nothing that struck me as odd or that needed further inspection.
That all said and done, there are multiple build failures of this package:
jammy: riscv64 (and it built before)
focal: armhf, ppc64el, riscv64 (which also built before)
I'll retry these, but until then, this cannot be released.