On Fri, Apr 1, 2016 at 7:38 AM, Mark Atwood wrote:
>
> We should configure it to be TZ=0 GMT
>
I would rather it printed the local time (with the offset). Trying in a
build script to guess what the UTC is requires an updated (current) tzdata,
and embedded systems may not have that.
eg:
ntpd 0.
fallenpega...@gmail.com said:
>> Speaking of version strings, the current string doesn't include
>> the time zone.
> We should configure it to be TZ=0 GMT
The version string comes from the compiler's __DATE__ and __TIME__
I assume that's the local time. We Amar can tell the compiler which time
On Tue, Mar 29, 2016 at 12:25 PM Hal Murray wrote:
>
> Speaking of version strings, the current string doesn't include the time
> zone.
>
>
We should configure it to be TZ=0 GMT
..m
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailma
v...@darkbeer.org said:
> Can you elaborate on this please? Are you talking about rebuilding each
> version.c for the respective tool it is meant for if a file for that tool
> changes?
Yes, If you are relinking ntpd, waf should recompile ntpd/version.c as part
of this batch. It doesn't need t
On 2016-03-29 12:25 -0700, Hal Murray wrote:
>
> It would be nice if waf was smart enough to recompile version at all the
> right times. It might miss some case. I mostly use a script that rm-s the
> build directory so I haven't had problems.
Can you elaborate on this please? Are you talking
The date string in the version printout is the date/time it was built, not
the date of the last change in git. That gives you a useful string if you
have a sequence of local edits that aren't committed yet. The git hash is
there if you want the git info.
You can find version.c in build/main/
Hi,
I have a strange issue. My ntp{d,q} versions seem wrong.
I do a git pull
root@ntpmon:~/ntpsec# git branch
* master
root@ntpmon:~/ntpsec# git describe
NTPsec_0_9_2-35-g9f732ba
root@ntpmon:~/ntpsec# git log | head
commit 9f732bada3b40fe7676bb248d8905dddfe79b671
Author: Eric S. Raymond
Date
