Missing .buildinfo files in Focal and Jammy for packages in main

Phil Roche phil.roche at canonical.com
Tue Jul 9 12:28:23 UTC 2024


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 <robie.basak at ubuntu.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20240709/4334121f/attachment.html>


More information about the Ubuntu-release mailing list