[ipxe-devel] reproducible builds, what if
Christian Nilsson
nikize at gmail.com
Mon May 4 06:03:43 UTC 2020
On Mon, 4 May 2020, 13:32 Michael Brown, <mcb30 at ipxe.org> wrote:
> On 04/05/2020 02:10, Neil Roza wrote:
> > On Sun, May 03, 2020 at 12:18:26PM +0900, Christian Nilsson wrote:
> > > What if there is any local non commited changes, or config file
> > changes, or
> > > embedded script changes. The checksum over linked solves the
> > hash, but is
> > > it actually correct to use git as a source for BUILD_TIMESTAMP
> > when there
> > > is local changes?
> >
> > I see the warning, but I don't see the problem.
> > In case that doesn't answer the "What if question",
> > please elaborate what the hidden danger is.
> >
> > No, I get it: a pristine HEAD and a dirty HEAD don't deserve the same
> > source date epoch. There's some ways to disambiguate these with `git
> > stash`, but this is starting to get complicated. It could become an ugly
> > `$(shell ...)` in the Makefile.housekeeping, or I could put it in a
> > helper shell script. What's the right decision for ipxe?
>
> BUILD_TIMESTAMP has a weaker requirement than BUILD_ID: it gets used
> only as a means to automatically select the newest version of iPXE if
> multiple iPXE drivers are loaded concurrently in a UEFI system. It's
> already rounded down to the nearest minute when used for that purpose.
>
> For BUILD_TIMESTAMP (but not BUILD_ID), I am happy with using the commit
> date as extracted from git.
>
Good, can we just make sure that the purpose and usage is documented in the
makefile as well?
>
> Michael
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20200504/6563b75e/attachment.htm>
More information about the ipxe-devel
mailing list