<div dir="ltr">We should hold off still on adding or changing crypto for a while still.<div><br></div><div>Tweaking ntpq to show the setup is interesting.  Is ntpq called by anything of note in any of the main distributions.  It may be worth adding that to the display in a way that doesnt change too much, and then wait for bug reports from distros and users.</div><div>..</div><div>If you think it continues to be productive, keep unsnarling ^C/SIGINT/setjmp, and talk who whoever else may have some insight.</div><div><br></div><div>At present, IIRC, our default build install location is /usr/local/...   with the expectation that we will let the distro packagers move things around, instead of trying to keep track of all the various distro policies in our own build scripts.   IIRC, you can configure man with a dotfile or environment variable to also look in /usr/local/man</div><div><br></div><div>Interesting about the bug in the startup.  Does NTP Classic do it too?    If so, report it to their bugtracker, after we release 0.9.2</div><div><br></div><div>Thank you for all your work, Hal.</div><div><br></div><div>..m</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 4, 2016 at 3:31 AM Hal Murray <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<a href="mailto:fallenpegasus@gmail.com" target="_blank">fallenpegasus@gmail.com</a> said:<br>
> What have you all worked on in the past couple of weeks, what successes and<br>
> frustrations have you had, and what do you see yourself working on over this<br>
> next week?<br>
<br>
I've been poking around with shared key crypto and various ways of getting<br>
connected to a server.  A lot of ways to establish a connection default to<br>
requiring crypto.  Everything I tried worked, but it often took me a while to<br>
figure it out.<br>
<br>
The ntpq peers command could be tweaked to tell you how a "peer" got setup.<br>
That would be a minor incompatibility.  We might be able to eliminate some of<br>
the modes.  Mumble, they probably don't cost much.  I should try to document<br>
all the modes in one place.  That would be easier after ntpq was "fixed" to<br>
help.<br>
<br>
<br>
ntpq uses ^C to bail out of the current command.  The mrulist command is two<br>
passes, the first collects data and the second prints it out.  (The order may<br>
change while the data is being collected.)  ^C is supposed to stop collecting<br>
and print out what it has collected.  Another ^C is supposed to stop<br>
printing.  I looked into porting the fix from NTP Classic, but it seemed<br>
unreasonably complicated.  I tried the obvious code.  It didn't work.<br>
Eventually, I tracked the problem back to somebody masking SIGINT.  It's<br>
tangled with setjmp/longjmp and/or what's being jmp-ed out of.  siglongjum<br>
works as expected.  I haven't found any documentation of the need to do that.<br>
 At that point, I got sidetracked.  I think I can fix the code not to use<br>
longjmp, but that will probably take a while.  I'll have to find out where<br>
the people who work on longjmp and/or getaddrinfo hang out and/or try it on<br>
other OSes/distros.<br>
<br>
--------<br>
<br>
The man pages are not getting installed where my man command is looking.  Are<br>
we installing them in the wrong place or do I need to tell my man command to<br>
look where we put them?  We need to document this.  We probably have the same<br>
issue with executables, but I fixed that ages ago so I'm not noticing any<br>
troubles.<br>
<br>
<br>
I may have blundered into a bug in ntpd's startup logic.  I think it's<br>
stepping the time when the first server responds rather than waiting to hear<br>
from a few more servers.<br>
<br>
<br>
--<br>
These are my opinions.  I hate spam.<br>
<br>
<br>
<br>
</blockquote></div>