| Message ID | 1438425169-13978-1-git-send-email-judge.packham@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Tom Rini |
| Headers | show |
Le samedi 01 août 2015 à 22:32 +1200, Chris Packham a écrit : > Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a > build with a specific date timestamp. This allows the verification of > source supplied with a pre-compiled binary. > > If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify > what will appear in the output of the version command. If SOURCE_DATE_TZ > is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not > have an affect. Well, I worked with the assumption that SOURCE_DATE_EPOCH would always be provided in UTC, but I see no harm in providing SOURCE_DATE_TZ as well, provided that it falls back to UTC when not set, as is the current behaviour of tour patch. Looks good to me! > Signed-off-by: Chris Packham <judge.packham@gmail.com> > --- > This is a quick proof of concept that allows some control of how the > timezone is displayed. > > Makefile | 7 ++++--- > README | 9 ++++++--- > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/Makefile b/Makefile > index f75c730..5102a9c 100644 > --- a/Makefile > +++ b/Makefile > @@ -1232,9 +1232,10 @@ endef > define filechk_timestamp.h > (if test -n "$${SOURCE_DATE_EPOCH}"; then \ > SOURCE_DATE="@$${SOURCE_DATE_EPOCH}"; \ > - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \ > - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \ > - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \ > + SOURCE_TZ="$${SOURCE_DATE_TZ:-UTC}"; \ > + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \ > + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \ > + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \ > else \ > LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \ > LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \ > diff --git a/README b/README > index 1bcb63c..d2e3e94 100644 > --- a/README > +++ b/README > @@ -5087,11 +5087,14 @@ Reproducible builds > In order to achieve reproducible builds, timestamps used in the U-Boot build > process have to be set to a fixed value. > > -This is done using the SOURCE_DATE_EPOCH environment variable. > -SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a configuration > -option for U-Boot or an environment variable in U-Boot. > +This is done using the SOURCE_DATE_EPOCH and SOURCE_DATE_TZ environment > +variables. These are to be set on the build host's shell, not as a > +configuration option for U-Boot or an environment variable in U-Boot. > > SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC. > +SOURCE_DATE_TZ will default to UTC but can be set to another timezone and is > +used to determine how the date is displayed (tzselect(1) can be used to > +determine an appropriate value). > > Building the Software: > ======================
On 01/08/15 20:47, Paul Kocialkowski wrote: > Le samedi 01 août 2015 à 22:32 +1200, Chris Packham a écrit : >> Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a >> build with a specific date timestamp. This allows the verification of >> source supplied with a pre-compiled binary. >> >> If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify >> what will appear in the output of the version command. If SOURCE_DATE_TZ >> is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not >> have an affect. > > Well, I worked with the assumption that SOURCE_DATE_EPOCH would always > be provided in UTC, but I see no harm in providing SOURCE_DATE_TZ as > well, provided that it falls back to UTC when not set, as is the current > behaviour of tour patch. > To clarify, SOURCE_DATE_EPOCH is a unix timestamp which is defined as the number of seconds (excluding leap seconds) since Jan 1 1970 UTC. There is no way to specify this "in another timezone"; there is no ambiguity here. However, I am not sure that us at Reproducible Builds will actually adopt this variable. We haven't talked about it beyond my previous email [1], it was just me quickly skimming off my thoughts and firing off quick ideas. My personal concern about SOURCE_DATE_TZ is that it implies that it could take actual named time zones, like "EST" or "Europe/London"; it is **extremely unlikely** that we will do anything like this soon, because this would involve timezone databases and complex things like that. This is why in my previous email I suggested the SOURCE_DATE_TZOFFSET variable. Also, the TZ variable as specified by POSIX specifies the offset in the *opposite* direction to what ISO8601 and RFC2822 displays. The git internal timestamp format only supports timezone offsets in the common direction, opposite to TZ, i.e. positive for east of Greenwich and negative for west. I'd suggest to leave out SOURCE_DATE_TZ for now, until we come up with a more precisely defined *meaning* for this variable. It is meant to be a standard across all tools, so some time to think through the issues is necessary. Otherwise we risk leaving a clusterfuck of a legacy, like the POSIX time functions. X [1] https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150727/002562.html or http://lists.denx.de/pipermail/u-boot/2015-July/221301.html
On 02/08/15 00:02, Ximin Luo wrote:
> However, I am not sure that us at Reproducible Builds will actually adopt this variable. We haven't talked about it beyond my previous email [1], it was just me quickly skimming off my thoughts and firing off quick ideas.
Whoops, I mean the _TZ variable. The _EPOCH variable has been decided and we're trying to get tools to support this.
On Sat, Aug 01, 2015 at 10:32:49PM +1200, Chris Packham wrote: > Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a > build with a specific date timestamp. This allows the verification of > source supplied with a pre-compiled binary. > > If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify > what will appear in the output of the version command. If SOURCE_DATE_TZ > is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not > have an affect. > > Signed-off-by: Chris Packham <judge.packham@gmail.com> > --- > This is a quick proof of concept that allows some control of how the > timezone is displayed. Can you please re-submit this, and the related EPOC patches as a series together? Thanks!
On Thu, Aug 13, 2015 at 4:40 AM, Tom Rini <trini@konsulko.com> wrote: > On Sat, Aug 01, 2015 at 10:32:49PM +1200, Chris Packham wrote: > >> Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a >> build with a specific date timestamp. This allows the verification of >> source supplied with a pre-compiled binary. >> >> If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify >> what will appear in the output of the version command. If SOURCE_DATE_TZ >> is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not >> have an affect. >> >> Signed-off-by: Chris Packham <judge.packham@gmail.com> >> --- >> This is a quick proof of concept that allows some control of how the >> timezone is displayed. > > Can you please re-submit this, and the related EPOC patches as a series > together? Thanks! > Hi Tom, Will do although Ximin Luo had some concerns[1]. The code works but there may (will?) be some churn in the naming/concept for the TZ part. -- [1] - http://marc.info/?l=u-boot&m=143851366020937&w=2
diff --git a/Makefile b/Makefile index f75c730..5102a9c 100644 --- a/Makefile +++ b/Makefile @@ -1232,9 +1232,10 @@ endef define filechk_timestamp.h (if test -n "$${SOURCE_DATE_EPOCH}"; then \ SOURCE_DATE="@$${SOURCE_DATE_EPOCH}"; \ - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \ - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \ - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \ + SOURCE_TZ="$${SOURCE_DATE_TZ:-UTC}"; \ + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \ + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \ + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \ else \ LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \ LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \ diff --git a/README b/README index 1bcb63c..d2e3e94 100644 --- a/README +++ b/README @@ -5087,11 +5087,14 @@ Reproducible builds In order to achieve reproducible builds, timestamps used in the U-Boot build process have to be set to a fixed value. -This is done using the SOURCE_DATE_EPOCH environment variable. -SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a configuration -option for U-Boot or an environment variable in U-Boot. +This is done using the SOURCE_DATE_EPOCH and SOURCE_DATE_TZ environment +variables. These are to be set on the build host's shell, not as a +configuration option for U-Boot or an environment variable in U-Boot. SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC. +SOURCE_DATE_TZ will default to UTC but can be set to another timezone and is +used to determine how the date is displayed (tzselect(1) can be used to +determine an appropriate value). Building the Software: ======================
Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a build with a specific date timestamp. This allows the verification of source supplied with a pre-compiled binary. If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify what will appear in the output of the version command. If SOURCE_DATE_TZ is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not have an affect. Signed-off-by: Chris Packham <judge.packham@gmail.com> --- This is a quick proof of concept that allows some control of how the timezone is displayed. Makefile | 7 ++++--- README | 9 ++++++--- 2 files changed, 10 insertions(+), 6 deletions(-)