info-mtools
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH


From: Thomas Schmitt
Subject: [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH
Date: Thu, 17 Feb 2022 19:54:33 +0100

Hi,

during the attempt to make the EFI bootable ISO images of project pcmemtest
reproducible it turned out that mcopy yields different byte-level results
in different timezones, although environment variable SOURCE_DATE_EPOCH is
set to the same value.
This is caused by the use of localtime(3) in function mk_entry() which
interprets the overridden getTimeNow() value against the specification
of SOURCE_DATE_EPOCH at
  https://reproducible-builds.org/specs/source-date-epoch/
which says that it holds the number of seconds in UTC.

So in the special case that getTimeNow() is overridden by SOURCE_DATE_EPOCH,
the conversion in mk_entry() of directory.c should be done by

  now = gmtime(&date2);

instead of

  now = localtime(&date2);


Now i wonder how one would properly transfer from misc.c to directory.c
the information that the "now"-time was overridden.
Two alternative approaches come to my mind:

- Move the interpretation of SOURCE_DATE_EPOCH to config.c and store
  the value in two new global variables: A flag and a value.
  getTimeNow() would return the value if the flag says that it is valid.
  mk_entry() would use gmtime(3) if the flag says "valid".

- Introduce a new function
    int haveSourceDateEpoch(int set_to_1)
    {
        static int have = 0;

        if (set_to_1)
            have = 1;
        return(have);
    }
  It would be called as haveSourceDateEpoch(1) in getTimeNow() if
  SOURCE_DATE_EPOCH is accepted.
  It would be called as haveSourceDateEpoch(0) in mk_entry() in order
  to decide whether to use gmtime(3).

What does upstream say to these ideas ?


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]