On 01/09/2019 10:04 PM, Mark Atwood, Project Manager via devel wrote:
We do indeed, thank you, Hal.
I would like to cut a release Sunday night, 2019-01-13
Everyone, please chime in, let me know if you think No Go or otherwise
have concerns.
Is buildbot happy?
Everyone, please no new featu
lockclock stays in
Thanks!
..m
On Sun, Jan 6, 2019 at 6:28 AM Eric S. Raymond via devel
wrote:
> Gary E. Miller via devel :
> > Lockclock mode is very important to the PTP people. They use PTP to
> > distribute time on the local net to the clients. Then a PTP client can
> > use NTP to server
We do indeed, thank you, Hal.
I would like to cut a release Sunday night, 2019-01-13
Everyone, please chime in, let me know if you think No Go or otherwise have
concerns.
Is buildbot happy?
Everyone, please no new features or major refactoring on the master
branch. If you have any pending bran
Gary said:
> I would imagine that every anal retentive sysadmin, like myself, would like
> to know when the leap second file changed. Maybe not so verbose.
"Verbose" has two dimensions - the number of messages and the length of an
individual message.
The thing that attracted my attention was
Yo Hal!
On Wed, 09 Jan 2019 10:44:08 -0800
Hal Murray via devel wrote:
> There is an optional flag to leapsec_load_file() that
> enables/disables logging of the hash validity (and maybe other
> things).
> Anybody know why we want this? Anybody object if I remove it?
I would imagine that every
Hal Murray via devel writes:
> Please play with it and let me know if you find anything interesting.
Asus TinkerBoard:
--8<---cut here---start->8---
tinkerboard1:~/ntpsec$ ./build/main/attic/clocks
res avg min dups CLOCK
1 526 291
There is an optional flag to leapsec_load_file() that enables/disables logging
of the hash validity (and maybe other things). The result is different
logging on startup and the rare case where ntpd finds a new leap file.
Anybody know why we want this? Anybody object if I remove it?
[ntpd re
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> I could try to contact the responsible person for NTP at PTB if you
>> can't get at information from NIST.
>
> Probably a good idea to have PTB figures even if we *can* get some from NIST.
I've sent the questions off, let's see how res
