Hi Robie, Apologies for delay.
The concerns you raised are valid and worthy of considering a different approach. With guidance following some Canonical internal discussions, we decided to build these packages that are missing .buildinfo files for Focal and Jammy in a PPA. Using the .buildinfo files produced there we can verify builds, either by comparing the built .debs in the PPA or by verifying separately using the generated .buildinfo files. Using the output for these investigations, we can assess whether it is worth pursuing the request to rebuild any packages in the Focal and Jammy main archives. This approach will also help provide justification and proof of no regression should we need to rebuild. Thanks, Phil On Wed, 5 Jun 2024 at 12:31, Robie Basak <[email protected]> wrote: > Hi Phil, > > Thank you for working on verifiable package builds! > > On Wed, Jun 05, 2024 at 12:20:28PM +0100, Phil Roche wrote: > > I am bringing this to your attention as in support of being able to > verify > > package builds in Ubuntu LTS releases I propose that we no change rebuild > > the above packages. > > The downside of this is that every user who has these packages installed > would have extra updates to download even if they have no interest (and > therefore gain no benefit) from the rebuild. There's also the risk of a > change in the build environment or non-determinimism in the build > resulting in a regression for existing users, and whatever QA we might > apply can never fully mitigate this. > > It certainly makes sense to do this in the development release - thank > you for verifying that it is already done! > > To do it retrospectively in previous releases I think we need a specific > justification though please, given the burden and risk on existing > users. > > > The current understanding is that this would require SRU for each > > package. @SRU-team Is that true for this use case or can an exception be > > made? > > We could do something in bulk to save doing unnecessary paperwork, but I > think we would need _some_ kind of QA plan to have some confidence that > something in the build environment or non-determinism hasn't changed > such that the rebuild turns out to regress users. > > > If SRU is required, are the SRU team willing to accept these packages > > through SRU? perhaps a prioritised list initially? > > I think this would depend on the justification provided. > > Thanks, > > Robie > -- Phil Roche Staff Software Engineer Canonical Public Cloud
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
