© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
These are my considerations for go-md2man:
- it's a rebuild for all arches, even though only ppc64el needs it. I don't see a way to only rebuild it for one arch, maybe an AA would be able to do it, but only if extraordinary circumstances warranted it I guess.
- the versioning is going from -1 to -1build1. I talked with the security team and they would have used 1ubuntu0.1, even though no change is being made, but this is because of their tooling. 1build0.1 would have been a bit better, but in this case 1build1 is fine, as no other ubuntu release is expected to get this same version and the upgrade path is safe.
- since golang uses mostly static linking, I wondered if bringing in a new build-dep after the other packages were rebuilt would be an issue. In this case, go-md2man produces a binary that is used by other packages to produce manpages, and not a library or module that is linked, so it's fine.
- the rebuild is to fix an FTBFS, which on its own usually does not warrant an SRU[1], but is allowed together with another bugfix. In this case, the rebuild is the fix at the same time, so it's fine. I was wondering if it needed a separate bug, though, but we have the case already of other packages being mentioned in this bug (the two golang-github-* ones).
- I also checked that the rebuild of go-md2man did NOT use the new backported golang 1.16, which is expected as the new golang-1.16 is not changing the default version of golang that is used in bionic.
- I also did a quick check that the output of go-md2man on an unaffected architecture (amd64) didn't change when rendering the same md document into a manpage, after the rebuild (sanity check).
1. https:/