Matthew Selsky via devel :
> We added the STA_NANO checks to support systems that have some STA_
> symbols, but not all. See
> https://lists.ntpsec.org/pipermail/vc/2017-December/003604.html
In particular, some of our targets (some BSDs, I don't remember which)
have only microsecond, not nanoseco
Hal Murray :
> 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.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the I
> The C code has no #ifdefs for HAVE_PTHREAD or HAVE_PTHREAD_H, so we're only
> talking about cleaning up some waf python code, correct?
Yes, or eliminating it.
Simplifying "little" things like this often allows simplification in some
other area.
> libthr is a FreeBSD thing...
Than
Anybody recognize this? I've seen it on NetBSD and FreeBSD
I haven't figure out what I'm doing to make it happen.
Waf: Leaving directory `/home/murray/ntpsec/foo/build/main'
Traceback (most recent call last):
File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w
aflib/S
On Tue, Jan 22, 2019 at 07:37:18PM -0800, Hal Murray via devel wrote:
>
> We have various cruft associated with threads. Can we add POSIX threads to
> our list of requirements? Or is it already included in POSIX.1-2001 and
> ISO/IEC 9899:1999 (C99)?
POSIX threads are optional for POSIX.1-2001
We have various cruft associated with threads. Can we add POSIX threads to
our list of requirements? Or is it already included in POSIX.1-2001 and
ISO/IEC 9899:1999 (C99)?
The idea is to remove HAVE_PTHREAD_H and HAVE_PTHREAD from config.h and remove
most of wafhelpers/check_pthread.py
waf
Eric said:
> It's never been an an *ntpq* "system variable" that can be queried through
> that interface, I meant.
It's easy to add new variables. Old ntpq may not show them in any of its
packaged printout like peers or kerninfo, but you can get them by asking
explicityly.
There are also 2
Hal Murray :
> > Alas, it's not a system variable.
>
> Looks like it is:
> include/ntpd.h:extern bool lockclock; /* lock to the system
> clock? */
It's never been an an *ntpq* "system variable" that can be queried through
that interface, I meant.
--
http://www
> Alas, it's not a system variable.
Looks like it is:
include/ntpd.h:extern bool lockclock; /* lock to the system
clock? */
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/
Achim Gratz via devel :
> Before I forget: I really don't care about when I've configured the
> project. Can that date please be the date of the corresponding commit
> (if it's there at all) and the version string something that git
> describe puts out, like NTPsec_1_1_3-35-g6c029ef4c (which is wa
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 the
driver tyoe and flag1.
--
h
Hal Murray via devel writes:
> I think there are 2 cases for the version string I'd like.
>
> If I have made local edits, I want the build date. That's the best summary
> of
> the edits I've made.
Git describe already tells you if you have uncommited local edits, by
adding "-dirty" at the end.
> Before I forget: I really don't care about when I've configured the project.
> Can that date please be the date of the corresponding commit (if it's there
> at all) and the version string something that git describe puts out, like
> NTPsec_1_1_3-35-g6c029ef4c (which is way more helpful to me in
Achim Gratz via devel writes:
> Hal Murray via devel writes:
>> A likely candidate is a call to loop_config()
>
> Yes, I think you've got the bug there. I'll still have to watch the
> statistics to see if there's something else amiss, but for the short
> while I've run with the new code it looks l
Eric S. Raymond via devel writes:
> I don't either, and I think there is no functional point in trying to cope
> with that. So I'm going to deal with this by adding to the documentation a
> line that says changing this flag at runtime may produce undefined behavior.
Works for me.
It would be nice
15 matches
Mail list logo
