Le 11/3/20 à 11:11 AM, Julien Grall a écrit :
On 03/11/2020 10:05, Jan Beulich wrote:On 03.11.2020 11:00, Julien Grall wrote:Hi Frédéric, On 31/10/2020 15:14, Frédéric Pierret (fepitre) wrote:--- xen/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/Makefile b/xen/Makefile index 30b1847515..4cc35556ef 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -6,6 +6,8 @@ export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION) export XEN_FULLVERSION = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION) -include xen-version +export SOURCE_DATE_EPOCH ?= $(shell git log -1 --format=%ct 2>/dev/null)It is possible to download a tarball for Xen release (see [1]). They don't contain the .git directory and therefore this command would fail. Should we fallback to "date" in this case?Isn't this what already happens? The variable would be assigned an empty value in this case, wouldn't it?My question was whether empty SOURCE_DATE_EPOCH is acceptable? Looking at patch #1, the users of the variable will use "date" if it is empty. Why can't this behavior be common? Cheers,
In fact, we could fallback to date in SOURCE_DATE_EPOCH definition and in this case this would always be defined. Now, I'm wondering how misleading that could be with respect to its definition (see [1]): "The value MUST be reproducible (deterministic) across different executions of the build, depending only on the source code.". In this case, if someone looks to the code and interpret the build time etc, defined with respect to SOURCE_DATE_EPOCH, that would be odd? Regards, Frédéric [1]: https://reproducible-builds.org/specs/source-date-epoch/
OpenPGP_0x484010B5CDC576E2.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
