Re: Various cleanups: threads, STA_NANO

2019-01-23 Thread Eric S. Raymond via devel
Matthew Selsky : > > There is some point in listing known-good platforms (Linux is the > > biggie), but no point in trying to be exhaustive about it, because > > anybody with enough chops to build this on a Unix variant we don't > > know about is necessarily clued in enough to apply this creterion

Re: Various cleanups: threads, STA_NANO

2019-01-23 Thread Matthew Selsky via devel
On Wed, Jan 23, 2019 at 01:36:33AM -0800, Hal Murray wrote: > > e...@thyrsus.com said: > > In particular, some of our targets (some BSDs, I don't remember which) have > > only microsecond, not nanosecond resolution in the clock-adjustment calls. > > NetBSD and FreeBSD have NANO. > > Matthew

Re: Various cleanups: threads, STA_NANO

2019-01-23 Thread Matthew Selsky via devel
On Wed, Jan 23, 2019 at 12:43:53AM -0500, Eric S. Raymond wrote: > That's because our actual support target is this: > > This software should build on any operating system conformant to > POSIX.1-2001 and ISO/IEC 9899:1999 (C99). In addition, the operating > system must have an

Re: lockclock runtime option

2019-01-23 Thread Eric S. Raymond via devel
Hal Murray : > > e...@thyrsus.com said: > >> Perhaps we should review this area. What will we want to see > >> when NTS is deployed. > > You and Achim are probably the best judges of that we have. So write a > > strawman and put it in nts.adoc. > > I don't plan to put anything related to

Re: Are we going to have a no-NTS-KE build option?

2019-01-23 Thread Eric S. Raymond via devel
Hal Murray : > > > James, you are correct. Privileged ntpq functions require the crypto. > > Not quite. > > Privileged operations require a password, but it is sent in the clear. There > is no crypto on that path. The packet format doesn't support it. We could > fix that at the cost of

Re: lockclock runtime option

2019-01-23 Thread Eric S. Raymond via devel
Hal Murray via devel : > ntp_control really needs a big cleanup. There are several tables that must > be > kept in sync by hand. I added issue #539 for that. (It may be a duplicate, > but I didn't see an old one.) I noticed that back when I was in "rip out all the code" mode. Priority:

Re: lockclock runtime option

2019-01-23 Thread Eric S. Raymond via devel
Achim Gratz via devel : > Well, it turns out ntpq has regressed from classic and doesn't > understand at least some of that syntax anymore: > > Classic> /usr/sbin/ntpq -c 'rv 0 offset' > offset=-0.023122 > > NTPsec~> ntpq -c 'rv 0 offset' > server=0 status=0415 leap_none, sync_uhf_radio, 1

Re: 'AnsiTerm' object has no attribute 'buffer'

2019-01-23 Thread Hal Murray via devel
Gary said: > That one failure is on Gentoo stable. Oddly I have many other Gentoo stable > that do not show the same problm. That's consistent with what I'm seeing. > I'm guessing it is more an environment setting than distro dependent. Could be, but I can't think of anything I've changed

Re: lockclock runtime option

2019-01-23 Thread Hal Murray via devel
e...@thyrsus.com said: >> Perhaps we should review this area. What will we want to see >> when NTS is deployed. > You and Achim are probably the best judges of that we have. So write a > strawman and put it in nts.adoc. I don't plan to put anything related to this into nts.adoc ntp_control

Re: 'AnsiTerm' object has no attribute 'buffer'

2019-01-23 Thread Gary E. Miller via devel
Yo Hal! On Wed, 23 Jan 2019 12:18:01 -0800 Hal Murray wrote: > Gary said: > > I'm getting an odd build error on one of my hosts. Ideas? > > I asked about the same quirk yesterday evening. No responses. I'm way behind on my INBOX... > What OS/Distro are you using? That one failure is on

Re: lockclock runtime option

2019-01-23 Thread Hal Murray via devel
> So, lockclock is not known as a system variable of course. I just pushed a fix for that. $ ntpq ntpq> rv 0 lockclock lockclock=0 ntpq> ntp_control really needs a big cleanup. There are several tables that must be kept in sync by hand. I added issue #539 for that. (It may be a duplicate,

Re: 'AnsiTerm' object has no attribute 'buffer'

2019-01-23 Thread Matthew Selsky via devel
On Wed, Jan 23, 2019 at 12:23:26PM -0800, James Browning via devel wrote: >I think I remember seeing that. IIRC I was piping something somewhere. >That was back before pylib/poly.py though. Per https://docs.python.org/2/library/io.html#io.TextIOBase: buffer The underlying binary buffer

Re: 'AnsiTerm' object has no attribute 'buffer'

2019-01-23 Thread James Browning via devel
On Wed, Jan 23, 2019, 12:18 PM Hal Murray via devel > Gary said: > > I'm getting an odd build error on one of my hosts. Ideas? > > I asked about the same quirk yesterday evening. No responses. > > What OS/Distro are you using? > > I've seen it on NetBSD and FreeBSD. I thought I had one on

Re: 'AnsiTerm' object has no attribute 'buffer'

2019-01-23 Thread Hal Murray via devel
Gary said: > I'm getting an odd build error on one of my hosts. Ideas? I asked about the same quirk yesterday evening. No responses. What OS/Distro are you using? I've seen it on NetBSD and FreeBSD. I thought I had one on Linux, but didn't have an example handy when I typed things in.

Re: Are we going to have a no-NTS-KE build option?

2019-01-23 Thread Hal Murray via devel
> James, you are correct. Privileged ntpq functions require the crypto. Not quite. Privileged operations require a password, but it is sent in the clear. There is no crypto on that path. The packet format doesn't support it. We could fix that at the cost of breaking compatibility. The

✘ 'AnsiTerm' object has no attribute 'buffer'

2019-01-23 Thread Gary E. Miller via devel
Yo All! I'm getting an odd build error on one of my hosts. Ideas? [275/275] Processing build/main/tests/test_ntpd Waf: Leaving directory `/usr/local/src/NTP/ntpsec/build/main' Traceback (most recent call last): File

Re: lockclock runtime option

2019-01-23 Thread Achim Gratz via devel
Hal Murray via devel writes: > Achim said: >> Well, it turns out ntpq has regressed from classic and doesn't understand at >> least some of that syntax anymore: > >> NTPsec~> ntpq -c 'rv 0 offset' >> server=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, >> version="ntpd

Re: lockclock runtime option

2019-01-23 Thread Hal Murray via devel
Achim said: > Well, it turns out ntpq has regressed from classic and doesn't understand at > least some of that syntax anymore: > NTPsec~> ntpq -c 'rv 0 offset' > server=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, > version="ntpd ntpsec-1.1.3+ 2019-01-21T16:51:20Z (git rev

Re: ntpq change in behaviour

2019-01-23 Thread Achim Gratz via devel
Eric S. Raymond via devel writes: > Feel free to open an RFE on the tracker, but be aware that this is trickier > than it sounds. NTS has to get done first. Tracker requires an account… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User

Re: lockclock runtime option

2019-01-23 Thread Achim Gratz via devel
Eric S. Raymond via devel writes: > Achim Gratz via devel : >> It would be nice if lockclock mode would get displayed in the system >> variables in ntpq if it was on, however. > > Alas, it's not a system variable. > > I could, I suppose, make it one. But you can get the same effect by querying >

Re: Are we going to have a no-NTS-KE build option?

2019-01-23 Thread Eric S. Raymond via devel
James Browning via devel : > > If we did away with shared key authentication, we could potentially do > > away > > with needing libcrypto. Aside from authentication, we also use > > RAND_bytes() > > so we would need to substitute something for that. > > Funny, I thought -lssl needed libcrypto as

Re: Are we going to have a no-NTS-KE build option?

2019-01-23 Thread James Browning via devel
On Wed, Jan 23, 2019, 3:07 AM Hal Murray via devel > I'm thinking of updating INSTALL and/or devel/hacking.adoc to say > something > about pthreads and OpenSSL. > > If we did away with shared key authentication, we could potentially do > away > with needing libcrypto. Aside from authentication,

Are we going to have a no-NTS-KE build option?

2019-01-23 Thread Hal Murray via devel
I'm thinking of updating INSTALL and/or devel/hacking.adoc to say something about pthreads and OpenSSL. If we did away with shared key authentication, we could potentially do away with needing libcrypto. Aside from authentication, we also use RAND_bytes() so we would need to substitute

Re: Various cleanups: threads, STA_NANO

2019-01-23 Thread Hal Murray via devel
e...@thyrsus.com said: > In particular, some of our targets (some BSDs, I don't remember which) have > only microsecond, not nanosecond resolution in the clock-adjustment calls. NetBSD and FreeBSD have NANO. Matthew Selsky suggested Solaris. Can anybody confirm that? Anybody know of others?