| Message ID | 20210219212154.27107-1-vfazio@xes-inc.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | support/download/svn: fix date format for archive creation | expand |
Vincent, All, Arnout, question for you toward the end... On 2021-02-19 15:21 -0600, Vincent Fazio spake thusly: > Previously we would use the date provided by: > `svn info --show-item last-changed-date ...` > > The date returned from this command could include sub-second precision > which is not compatible with the PAX options we specify to GNU tar. > > Now the returned date is massaged to drop the sub-seconds. > > Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Thank you for spinning this one right before you sprung on the train to your holidays! > --- > support/download/svn | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/support/download/svn b/support/download/svn > index 839dccaf62..ea1032267f 100755 > --- a/support/download/svn > +++ b/support/download/svn > @@ -52,6 +52,9 @@ _svn export ${verbose} "${@}" "'${uri}@${rev}'" "'${basename}'" > # last line (svn outputs everything on stdout) > date="$( _svn info --show-item last-changed-date "'${uri}@${rev}'" |tail -n 1 )" > > +# Drop sub-second precision to play nice with GNU tar's valid_timespec check > +date="$( date -d "${date}" -uIseconds )" So, I did some checks about when 'date -d' learnt to deal with sub-second precision. Not sure when, but it is suported in all the major distributions still maintained (centos 7, debian jessie, ubuntu trusty), while it was not in some earlier versions (centos 6, debian squeeze). So that's fine for me. But I wonder whether this should be svn-specific, or whether we should move it into the generic herlper mk_tar_gz()... Arnout, thoughts? Regards, Yann E. MORIN. > # Generate the archive. > # We did a 'svn export' above, so it's not a working copy (there is no .svn > # directory or file to ignore). > -- > 2.30.0 >
On 20/02/2021 10:51, Yann E. MORIN wrote: > Vincent, All, > > Arnout, question for you toward the end... > > On 2021-02-19 15:21 -0600, Vincent Fazio spake thusly: >> Previously we would use the date provided by: >> `svn info --show-item last-changed-date ...` >> >> The date returned from this command could include sub-second precision >> which is not compatible with the PAX options we specify to GNU tar. >> >> Now the returned date is massaged to drop the sub-seconds. >> >> Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> > > Thank you for spinning this one right before you sprung on the train to > your holidays! > >> --- >> support/download/svn | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/support/download/svn b/support/download/svn >> index 839dccaf62..ea1032267f 100755 >> --- a/support/download/svn >> +++ b/support/download/svn >> @@ -52,6 +52,9 @@ _svn export ${verbose} "${@}" "'${uri}@${rev}'" "'${basename}'" >> # last line (svn outputs everything on stdout) >> date="$( _svn info --show-item last-changed-date "'${uri}@${rev}'" |tail -n 1 )" >> >> +# Drop sub-second precision to play nice with GNU tar's valid_timespec check >> +date="$( date -d "${date}" -uIseconds )" > > So, I did some checks about when 'date -d' learnt to deal with > sub-second precision. Not sure when, but it is suported in all the > major distributions still maintained (centos 7, debian jessie, ubuntu > trusty), while it was not in some earlier versions (centos 6, debian > squeeze). A much simpler solution is date="$( date -d "${date}" -u +%Y-%m-%dT%T%:z )" which is fully portable over any POSIX-compliant version of date. > > So that's fine for me. > > But I wonder whether this should be svn-specific, or whether we should > move it into the generic herlper mk_tar_gz()... Arnout, thoughts? I would expect any sane VCS to be able to show the last change date in ISO 8601 format - I'd hope that SVN is the exception rather than the rule... Regards, Arnout > > Regards, > Yann E. MORIN. > >> # Generate the archive. >> # We did a 'svn export' above, so it's not a working copy (there is no .svn >> # directory or file to ignore). >> -- >> 2.30.0 >> >
Arnout, All, On 2021-02-22 11:58 +0100, Arnout Vandecappelle spake thusly: > On 20/02/2021 10:51, Yann E. MORIN wrote: > > On 2021-02-19 15:21 -0600, Vincent Fazio spake thusly: > >> Now the returned date is massaged to drop the sub-seconds. [--SNIP--] > A much simpler solution is > date="$( date -d "${date}" -u +%Y-%m-%dT%T%:z )" > which is fully portable over any POSIX-compliant version of date. %:z is not POSIX, it's a GNU extension. However, we do not care about computing the timezone: it's forcibly +00:00 becasue we do request -u. Also, %T is OK, but to keep in line with the %Y-%m-%d part, I've switched to %H:%M:%S. Eventually, I've settled for: > > But I wonder whether this should be svn-specific, or whether we should > > move it into the generic herlper mk_tar_gz()... Arnout, thoughts? > I would expect any sane VCS to be able to show the last change date in ISO 8601 > format - I'd hope that SVN is the exception rather than the rule... Actually, sub-second precision *is* allowed by ISO8601. ISO8601 even allows fractional parts after the last time element, eg.: 14:30,5 to represent 14 hours, 30.5 minutes (i.e. 30min and 30s). The precision of the fractional part is even left unspecified, with parties agreeing in advance (or autodetectig, I'd guess): https://en.wikipedia.org/wiki/ISO_8601#Times So, svn *is* ISO8601-compliant. Regards, Yann E. MORIN. > Regards, > Arnout > > > > > Regards, > > Yann E. MORIN. > > > >> # Generate the archive. > >> # We did a 'svn export' above, so it's not a working copy (there is no .svn > >> # directory or file to ignore). > >> -- > >> 2.30.0 > >> > >
Arnout,All, I was rushing for dinner, so forgot to properly complete my mail before sending it; here's a complement... On 2021-02-22 19:28 +0100, Yann E. MORIN spake thusly: > On 2021-02-22 11:58 +0100, Arnout Vandecappelle spake thusly: > > On 20/02/2021 10:51, Yann E. MORIN wrote: > > > On 2021-02-19 15:21 -0600, Vincent Fazio spake thusly: > > >> Now the returned date is massaged to drop the sub-seconds. > [--SNIP--] > > A much simpler solution is > > date="$( date -d "${date}" -u +%Y-%m-%dT%T%:z )" > > which is fully portable over any POSIX-compliant version of date. [--SNIP--] > Eventually, I've settled for: ... for: +%Y-%m-%dT%H:%M:%S+00:00 > Actually, sub-second precision *is* allowed by ISO8601. [...] And so, I still think it is better to have that clamping in the helper. Regards, Yann E. MORIN.
Vincent, All, On 2021-02-19 15:21 -0600, Vincent Fazio spake thusly: > Previously we would use the date provided by: > `svn info --show-item last-changed-date ...` > > The date returned from this command could include sub-second precision > which is not compatible with the PAX options we specify to GNU tar. > > Now the returned date is massaged to drop the sub-seconds. > > Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> In the end, I did move it to the helper, because: - this really is an internal detail on a limitation of the PAX format, - we do not really mind what exact timestamp goes in the archive, as long as it is reproducible. Also, as suggested by Arnout, I switched to usig an explicit date-time POSIX-compliant format string, rather than rely on -Iseconds, which is a GNU extension. Applied to master, thanks. Regards, Yann E. MORIN. > --- > support/download/svn | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/support/download/svn b/support/download/svn > index 839dccaf62..ea1032267f 100755 > --- a/support/download/svn > +++ b/support/download/svn > @@ -52,6 +52,9 @@ _svn export ${verbose} "${@}" "'${uri}@${rev}'" "'${basename}'" > # last line (svn outputs everything on stdout) > date="$( _svn info --show-item last-changed-date "'${uri}@${rev}'" |tail -n 1 )" > > +# Drop sub-second precision to play nice with GNU tar's valid_timespec check > +date="$( date -d "${date}" -uIseconds )" > + > # Generate the archive. > # We did a 'svn export' above, so it's not a working copy (there is no .svn > # directory or file to ignore). > -- > 2.30.0 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
diff --git a/support/download/svn b/support/download/svn index 839dccaf62..ea1032267f 100755 --- a/support/download/svn +++ b/support/download/svn @@ -52,6 +52,9 @@ _svn export ${verbose} "${@}" "'${uri}@${rev}'" "'${basename}'" # last line (svn outputs everything on stdout) date="$( _svn info --show-item last-changed-date "'${uri}@${rev}'" |tail -n 1 )" +# Drop sub-second precision to play nice with GNU tar's valid_timespec check +date="$( date -d "${date}" -uIseconds )" + # Generate the archive. # We did a 'svn export' above, so it's not a working copy (there is no .svn # directory or file to ignore).
Previously we would use the date provided by: `svn info --show-item last-changed-date ...` The date returned from this command could include sub-second precision which is not compatible with the PAX options we specify to GNU tar. Now the returned date is massaged to drop the sub-seconds. Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> --- support/download/svn | 3 +++ 1 file changed, 3 insertions(+)