Re: [PATCH v1 1/2] No insert of the build timestamp into the x86 xen efi binary

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Oct 30, 2020 at 01:30:08PM +0000, Andrew Cooper wrote:
> On 30/10/2020 12:48, Jan Beulich wrote:
> > On 30.10.2020 13:23, Marek Marczykowski-Górecki wrote:
> >> On Fri, Oct 30, 2020 at 01:08:44PM +0100, Jan Beulich wrote:
> >>> On 30.10.2020 13:03, Frédéric Pierret (fepitre) wrote:
> >>>
> >>>> --- a/xen/arch/x86/Makefile
> >>>> +++ b/xen/arch/x86/Makefile
> >>>> @@ -170,6 +170,7 @@ EFI_LDFLAGS += --major-image-version=$(XEN_VERSION)
> >>>>  EFI_LDFLAGS += --minor-image-version=$(XEN_SUBVERSION)
> >>>>  EFI_LDFLAGS += --major-os-version=2 --minor-os-version=0
> >>>>  EFI_LDFLAGS += --major-subsystem-version=2 --minor-subsystem-version=0
> >>>> +EFI_LDFLAGS += --no-insert-timestamp
> >>> Generally I prefer binaries to carry timestamps, when they are
> >>> intended to do so (i.e. when they have a respective field). So
> >>> I think if no timestamp is wanted, it should be as an option
> >>> (not sure about the default).
> >> What about setting it to the SOURCE_DATE_EPOCH[1] variable value, if
> >> present? Of course if there is an option to set explicit timestamp
> >> value.
> >>
> >> [1] https://reproducible-builds.org/docs/source-date-epoch/
> > Why not.
> 
> SOURCE_DATE_EPOCH is the right way to fix this.

Hmm, reading 'ld' man page, I don't see an option to set explicit value,
on --insert-timestamp / --no-insert-timestamp.

> It probably wants to default to something sane in the root Makefile, so
> it covers tools as well.

In practice, the package build system (deb, rpm, etc) do set it based on
last package changelog entry, so _for package build case_ it isn't
needed. But probably nice addition.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature