From hmurray at megapathdsl.net  Fri Jan  1 01:20:57 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 31 Dec 2015 17:20:57 -0800
Subject: ntpdsim status and question
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Thu, 31 Dec 2015 15:38:04 EST." <20151231203804.GA30545@thyrsus.com>
Message-ID: <20160101012057.424B6406057@ip-64-139-1-69.sjc.megapath.net>


>> If/when we decide to build a minimal version of ntpd, I could
>> easily imagine that a compile time option to avoid the intercept
>> layer would be a useful idea.

> The only reasonable way to do this would be to not compile in the replay/
> capture support in the intercept layer, leaving the normal-mode
> implementations in place. 

I was thinking of pushing it up to the header file so it didn't have to 
bounce through a useless intercept layer.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Fri Jan  1 07:06:27 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 1 Jan 2016 02:06:27 -0500
Subject: Cannot compile on Windows 7 64 bits with Visual Studio 2013
 community.
In-Reply-To: <20151231220952.79C96406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20151231210247.GC30545@thyrsus.com>
 <20151231220952.79C96406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160101070627.GA2128@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> > With a little work (a simple enough job that I don't need to be the one to
> > do it, I think) it should be possible to change the --disable-dns-lookup
> > option to always use synchronous lookup on hostnames, so the IP-only
> > restriction is removed at the cost of a small amount of startup lag.
> 
> I think you are confusing things by thinking of it as a startup problem.

OK, the places where I made asynchronous lookups an option are on 
command line and config-file hostames.

> The pool stuff also does DNS lookups and those may happen at non-startup time.

Right, I do tend to forget about that case.

> Even if startup works, I'd like to be able to occasionally (say daily) use 
> DNS to verify that the server is still in the pool.  That's a long-term 
> project.  Something like that would also be useful to verify that a 
> (non-pool) server hadn't moved.

Noted.

> I agree that it's worth investigating using synchronous DNS.  I expect it 
> will work fine on a lightly loaded system which covers most of the systems 
> running ntpd.
> 
> On the other hand, I think we should be able to make a clean threaded 
> version.  Don't get fooled by the current code.  It's not an inherently hard 
> problem.  A good example might be useful for other projects.

Maybe.  This is me looking for complexity reductions; important part of my job.

> > Later, after I deliver replay, I'm going to do a bunch of profiling. I'm not
> > actually convinced that the async-dns code is worth its complexity cost in
> > avoided startup lag, and I mean to measure the difference over a large
> > number of runs to find out. 
> 
> I think that will be misleading on several counts.
> 
> The question is not what is the average time, but rather what is the worst 
> case.
> 
> The performance in your environment may not tell you much about my 
> environment.

You are certainly right on the first count, but I question the second.
I believe the cost of synchronous lookups is dominated by WAN latency
rather than the local system's performance, and I think those
latencies have dropped a lot in the last decade.  Instead of
theorizing I want to *look*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Fri Jan  1 09:47:51 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 01 Jan 2016 01:47:51 -0800
Subject: Cannot compile on Windows 7 64 bits with Visual Studio 2013 
 community.
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Fri, 01 Jan 2016 02:06:27 EST." <20160101070627.GA2128@thyrsus.com>
Message-ID: <20160101094751.93F02406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> I believe the cost of synchronous lookups is dominated by WAN latency rather
> than the local system's performance, and I think those latencies have
> dropped a lot in the last decade.  Instead of theorizing I want to *look*. 

If everything goes right, WAN latency may be the major delay.  But my ISP may 
be less competent than yours and one of their DNS servers may be down more 
than yours, or more overloaded, or ...

Maybe we should start a project outside of NTP to measure DNS lookup times.

-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Sun Jan  3 07:37:12 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 02 Jan 2016 23:37:12 -0800
Subject: asciidoc tables - column widths
Message-ID: <20160103073713.1009C406057@ip-64-139-1-69.sjc.megapath.net>


Many of the tables in decode.html are hard to read.  I just hacked things a 
bit, but I can't find a way to say what I want.  I can set the width of the 
whole table as a fraction of the window and each column as a fraction of the 
table width.

But I have no idea how wide the user has setup their window for the web page. 
 Expressing things in fractions is good most of the time, but this seems to 
be one of the nasty examples.  With a reasonable width window, the table only 
needs a small fraction of the window.  But if the window is narrower, the 
table needs the full width.

Is there any way to tell asciidoc to make this column wide enough to hold the 
longest text in this column?

I'd be willing to describe widths in characters if that will help.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sun Jan  3 18:02:40 2016
From: esr at thyrsus.com (Eric)
Date: Sun, 3 Jan 2016 13:02:40 -0500
Subject: asciidoc tables - column widths
In-Reply-To: <20160103073713.1009C406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160103073713.1009C406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160103180240.GB31346@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> Many of the tables in decode.html are hard to read.  I just hacked things a 
> bit, but I can't find a way to say what I want.  I can set the width of the 
> whole table as a fraction of the window and each column as a fraction of the 
> table width.
> 
> But I have no idea how wide the user has setup their window for the web page. 
>  Expressing things in fractions is good most of the time, but this seems to 
> be one of the nasty examples.  With a reasonable width window, the table only 
> needs a small fraction of the window.  But if the window is narrower, the 
> table needs the full width.
> 
> Is there any way to tell asciidoc to make this column wide enough to hold the 
> longest text in this column?
> 
> I'd be willing to describe widths in characters if that will help.

TL;DR I don't think there's any way to express column widths in absolute units.
IIRC the underlying XML-DocBook can't do that.

Here's the relevant documentation.  In the second bullet point of 23.4,
"output column width markup attributes" links to 23.7.

http://www.methods.co.nz/asciidoc/userguide.html#X70

   23.4. Column Specifiers

   Column specifiers define how columns are rendered and appear in the
   table cols attribute. A column specifier consists of an optional
   column multiplier followed by optional alignment, width and style
   values and is formatted like:

   [<multiplier>*][<align>][<width>][<style>]

   * All components are optional. The multiplier must be first and the
     style last. The order of <align> or <width> is not important.

   * Column <width> can be either an integer proportional value (1?) or a
     percentage (1%?100%). The default value is 1. To ensure portability
     across different backends, there is no provision for absolute column
     widths (not to be confused with output column width markup
     attributes which are available in both percentage and absolute
     units).

   * The <align> column alignment specifier is formatted like:

     [<horizontal>][.<vertical>]

     Where <horizontal> and <vertical> are one of the following characters:
     <, ^ or > which represent left, center and right horizontal alignment
     or top, middle and bottom vertical alignment respectively.

   * A <multiplier> can be used to specify repeated columns
     e.g. cols="4*<" specifies four left-justified columns. The default
     multiplier value is 1.

   * The <style> name specifies a table style to used to markup column
     cells (you can use the full style names if you wish but the first
     letter is normally sufficient).

   * Column specific styles are not applied to header rows.


http://www.methods.co.nz/asciidoc/userguide.html#X72

   23.7. Markup attributes

   AsciiDoc makes a number of attributes available to table markup
   templates and tags. Column specific attributes are available when
   substituting the colspec cell data tags.

   pageunits
      DocBook backend only. Specifies table column absolute width
      units. Defaults to *.

   pagewidth
      DocBook backend only. The nominal output page width in pageunit
      units. Used to calculate CALS tables absolute column and table
      widths. Defaults to 425.

   tableabswidth
      Integer value calculated from width and pagewidth attributes. In
      pageunit units.

   tablepcwidth
      Table width expressed as a percentage of the available
      width. Integer value (0..100).

   colabswidth
      Integer value calculated from cols column width, width and
      pagewidth attributes. In pageunit units.

   colpcwidth
      Column width expressed as a percentage of the table width. Integer
      value (0..100).

   colcount
      Total number of table columns.

   rowcount
      Total number of table rows.

   halign
      Horizontal cell content alignment: left, right or center.

   valign
      Vertical cell content alignment: top, bottom or middle.

   colnumber, colstart
      The number of the leftmost column occupied by the cell (1?).

   colend
   The number of the rightmost column occupied by the cell (1?).

   colspan
      Number of columns the cell should span.

   rowspan
      Number of rows the cell should span (1?).

   morerows
      Number of additional rows the cell should span (0?).



-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Sun Jan  3 18:44:44 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 03 Jan 2016 10:44:44 -0800
Subject: asciidoc tables - column widths
In-Reply-To: Message from Eric <esr@thyrsus.com>
 of "Sun, 03 Jan 2016 13:02:40 EST." <20160103180240.GB31346@thyrsus.com>
Message-ID: <20160103184444.AE1A2406057@ip-64-139-1-69.sjc.megapath.net>

Thanks.

I guess I'll assume that people are using reasonable widths.  If anybody 
finds an example that doesn't look reasonable in their browser, please tell 
me, and/or send a screen shot.

-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Mon Jan  4 09:18:07 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 04 Jan 2016 01:18:07 -0800
Subject: Replay progress report
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Thu, 31 Dec 2015 15:50:15 EST." <20151231205015.GB30545@thyrsus.com>
Message-ID: <20160104091807.8FD38406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> I considered doing it that way.  The problem is that if you multithread the
> DNS lookups, the order in which the capture events land is no longer
> deterministic. At that point the minimum complexity required of the replay
> interpreter *explodes*.  I chose to dodge that lest I find myself down a
> rathole. 

Let me try again.

If you want replay to handle the pool case, then you have to handle the 
asynchronous DNS case.  I think the pool case is important, but it can wait 
until you get a simple case working.

I think the asynchronous DNS is just like processing packets.  The idea is to 
work at the edges of the main thread and ignore the DNS thread.  (Intercept 
might have to ignore logging from the DNS thread.  Daniel added a lock in the 
logging a while ago.  It was discovered due to mangled logging so there is 
some logging from the DNS thread.)

Recording the DNS request is similar to recording transmit packets.  Replay 
compares the current request with the next line in the log file.

Processing the DNS result is like processing a receive packet.  Record has to 
intercept where the main thread pulls the result off the queue.  When replay 
finds a DNS result in the log file, it has to do whatever the main thread 
does with the result.



-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Mon Jan  4 17:19:27 2016
From: esr at thyrsus.com (Eric)
Date: Mon, 4 Jan 2016 12:19:27 -0500
Subject: Replay progress report
In-Reply-To: <20160104091807.8FD38406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20151231205015.GB30545@thyrsus.com>
 <20160104091807.8FD38406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160104171927.GA6204@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I considered doing it that way.  The problem is that if you multithread the
> > DNS lookups, the order in which the capture events land is no longer
> > deterministic. At that point the minimum complexity required of the replay
> > interpreter *explodes*.  I chose to dodge that lest I find myself down a
> > rathole. 
> 
> Let me try again.
> 
> If you want replay to handle the pool case, then you have to handle the 
> asynchronous DNS case.  I think the pool case is important, but it can wait 
> until you get a simple case working.

Agreed on both counts.

> I think the asynchronous DNS is just like processing packets.  The idea is to 
> work at the edges of the main thread and ignore the DNS thread.  (Intercept 
> might have to ignore logging from the DNS thread.  Daniel added a lock in the 
> logging a while ago.  It was discovered due to mangled logging so there is 
> some logging from the DNS thread.)
> 
> Recording the DNS request is similar to recording transmit packets.  Replay 
> compares the current request with the next line in the log file.
> 
> Processing the DNS result is like processing a receive packet.  Record has to 
> intercept where the main thread pulls the result off the queue.  When replay 
> finds a DNS result in the log file, it has to do whatever the main thread 
> does with the result.

All this is correct.  Furthermore I know what the event recorded when
the lookup returns would look like. This is a sample:

   getaddrinfo 0.ubuntu.pool.ntp.org 96.126.105.86 1

But because the asynch processing has an unpredictable delay, you cannot
predict where it will land in the capture file with respect to other events.
Apparently I failed to make clear why this is a problem.

The way that the replay mode presently works is dead simple.  Before
the main receive loop (captured by the intercept_replay() function),
each intercept function pops a line off the logfile and checks to see
if its event type matches what is expected at this point - for
example, a call to intercept_drift_read() wants to see a drift_read
event.  During the main loop, either of two events (sendpkt or
receive) is accepted and interpreted.

This scheme depends on the assumption that, before the main loop, intercept
functions will be called in the exact same order during replay that
they were during capture.  There's no separate replay interpreter that
is dispatching events itself, so there is no way to handle a
getaddrinfo event.

I part-fixed this problem by arranging for getaddrinfo triggered by
command-line and config-file calls to be done synchronously in capture
and replay mode. This means they land at a fixed place in the capture
file (just after the config file read) and will be interpreted by the
replay code recapitualating that control flow.  You are correct that this
does not address pool lookups.

During the main loop we have a little more slack; I could add a
getaddrinfo event type and have it update the peer list.  The problem
is that we have no guarantee the getaddrinfo callback won't fire (recording
the event) too soon.

There are some ways to get around this.  The simplest would be for the
intercept layer to store replies from the getaddrinfo callback but
defer recording them until intercept_replay() begins.  But "simplest"
would still drive the complexity of the replay interpreter way up,
which is not a good thing when I'm still trying to debug operation
of the simplest possible replay case.

Right now I'm trying to pursue the simplest path to getting one replay
case working, and it's still damn difficult.  Once I have a proof of
concept I will be able to afford doing things in trickier but more
general ways.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From esr at thyrsus.com  Mon Jan  4 18:00:36 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon,  4 Jan 2016 13:00:36 -0500 (EST)
Subject: Securing your systems
Message-ID: <20160104180036.D636B13A6109@snark>

Two days ago Susan Sons came to my place and we spent a day hardening
my security.  I now have full-disk encryption on both the Great Beast
and my laptop, a lock code on my phone, I'm using Signal for encrypted
SMS, and have begun to set up 2FA on my web accounts that support it.
Some weeks back, at her urging, I switched to a GPG key with the
largest bit width currently possible.

Why bother?  Because, as Susan explained and Mark has previously
noted, DDoS via NTP is a favored tool for all manner of bad guys from
script kiddies up to and including advanced persistent threats like
the PLA and the Russian Mafia.  They have a strong interest in
compromising NTPsec's security so they can know what we know about
unpublished vulns.

This means, in particular, that our personal computers are prime
targets. So are our GPG keys - both personal and project-related.

Take this threat seriously.  We probably don't need to worry about
rubber-hose attacks, because the bad guys want a compromise that's
covert and deniable.  But some of our potential adversaries are
state-level actors with enough patience and resources that they were
able to undetectably subvert Google's Perforce repositories
(undetectably until the inserted code was noticed, anyway - that one
was probably the PLA).  They will throw as much cracking skill at us
as they think they need to.

While we can't perfectly secure ourselves against the likes of the PLA
or the NSA, we can and should make it difficult for them to compromise
our security without being noticed.

Susan was, therefore, right to insist that I tighten up my security.
Those of you who aren't hardened at least to the level I described
above should do likewise.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

There's a truism that the road to Hell is often paved with good intentions.
The corollary is that evil is best known not by its motives but by its
*methods*.

From dtpoirot at gmail.com  Mon Jan  4 18:51:17 2016
From: dtpoirot at gmail.com (Dan Poirot)
Date: Mon, 4 Jan 2016 12:51:17 -0600
Subject: Securing your systems
In-Reply-To: <20160104180036.D636B13A6109@snark>
References: <20160104180036.D636B13A6109@snark>
Message-ID: <002401d14720$e57c7700$b0756500$@gmail.com>

I have been a two factor authentication fanboy for a good, long time.

While Industry and Government are big fans of the RSA dongle and photo ID
smart-cards, the one-time PIN need not be a significant burden. 

There is a nice discussion on using Google Authentication here:
	
https://support.google.com/accounts/answer/1085463?hl=en&ref_topic=1099588

Using Google Auth on my iPhone 6 (and the iPhone's fingerprint scanner)
gives me 2+ factor (just how good is the scanner?)

My watch also calculates Google Auth one time use PINs:
	
http://pebble.devpost.com/submissions/21538-pebbleauth-two-step-authenticati
on-for-pebble 

- dan


-----Original Message-----
From: devel [mailto:devel-bounces at ntpsec.org] On Behalf Of Eric S. Raymond
Sent: Monday, January 04, 2016 12:01 PM
To: devel at ntpsec.org
Subject: Securing your systems

Two days ago Susan Sons came to my place and we spent a day hardening my
security.  I now have full-disk encryption on both the Great Beast and my
laptop, a lock code on my phone, I'm using Signal for encrypted SMS, and
have begun to set up 2FA on my web accounts that support it.
Some weeks back, at her urging, I switched to a GPG key with the largest bit
width currently possible.

Why bother?  Because, as Susan explained and Mark has previously noted, DDoS
via NTP is a favored tool for all manner of bad guys from script kiddies up
to and including advanced persistent threats like the PLA and the Russian
Mafia.  They have a strong interest in compromising NTPsec's security so
they can know what we know about unpublished vulns.

This means, in particular, that our personal computers are prime targets. So
are our GPG keys - both personal and project-related.

Take this threat seriously.  We probably don't need to worry about
rubber-hose attacks, because the bad guys want a compromise that's covert
and deniable.  But some of our potential adversaries are state-level actors
with enough patience and resources that they were able to undetectably
subvert Google's Perforce repositories (undetectably until the inserted code
was noticed, anyway - that one was probably the PLA).  They will throw as
much cracking skill at us as they think they need to.

While we can't perfectly secure ourselves against the likes of the PLA or
the NSA, we can and should make it difficult for them to compromise our
security without being noticed.

Susan was, therefore, right to insist that I tighten up my security.
Those of you who aren't hardened at least to the level I described above
should do likewise.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

There's a truism that the road to Hell is often paved with good intentions.
The corollary is that evil is best known not by its motives but by its
*methods*.
_______________________________________________
devel mailing list
devel at ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel


From srinivasan.srivatsan at hpe.com  Tue Jan  5 21:26:46 2016
From: srinivasan.srivatsan at hpe.com (Srivatsan, Srinivasan)
Date: Tue, 5 Jan 2016 21:26:46 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <20151224061529.37D8D406057@ip-64-139-1-69.sjc.megapath.net>
References: <srinivasan.srivatsan@hpe.com>
 <A170ADF3-907D-4A0C-A471-4882709A3CC4@hpe.com>
 <20151224061529.37D8D406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <AE893ED6-FBF8-4FA0-913D-4E6A289741B3@hpe.com>

Thanks Hal and Eric. I was experimenting with ntpq and found it useful as you said it would. 

Progress updates:
* I have created a NTPsec docker image so that anyone can start playing with it. Its available at https://hub.docker.com/r/srinsriv/ntp/. Steps on how to use it available in the website.
* I also have a partially working NTPsec recipe. Here?s the review in process for that. https://review.openswitch.net/#/c/2991/
* I tried playing with ntpq and have a few things like configuration and statistics sorted out but have some doubts which I?ve listed below.


Non-technical points:
* What is the license which you guys have for using and distributing NTPsec ? I saw this page (https://www.ntpsec.org/license.html). Is this the final license list for NTPsec usage and distribution ? 


I am stuck at a few technical points here:
*  I have enabled a control key but was unable to configure a server through a single ntpq command because it keeps on asking for keyid and password for configuration through ntpq. But it would be helpful to add a server with a single ntpq command with all the options on it, including the keyid and password. Have you used it this way ? 
*  I see that the password is set using 'crypto pw? and its all plain text. Is there a way to save the password differently or configure the password during runtime ?
*  Could you share the configuration and commands which you used for your tests ? 
*  I have not tested authentication scenario, what is the server configuration which you used for testing authentication. 
* One major issue I see when enabling the NTPsec recipe with my build process is when doing the ?waf configure? step it fails. I see it internally calls a configuration script to check the compiler. For checking the compiler it generates a C file, compiles it and tries to execute to find get a specific value from the executable. Currently I see it fail at the last step, because it fails to execute the generated executable with ?No such file or directory?. I?ve posted the build/config.log file and ldd,readelf,objdump for the testbuild/testprog which is created in this process. Could you please provide pointers on how to fix this. Link to paste bin: http://pastebin.com/raw/AJBMpqsb 

Thanks
Srinivasan




On 12/23/15, 10:15 PM, "Hal Murray" <hmurray at megapathdsl.net> wrote:

>
>srinivasan.srivatsan at hpe.com said:
>> For the initial release we are planning to support only NTP client.
>
>You get a server for "free", without asking for it.  You might be able to 
>hide it with the restrict stuff.
>
>
>>      *   Daemon is up and we need to print the current ntp status info,
>>      *   Daemon is up and we need to print the NTP associations info, 
>
>Poke around with ntpq.  It can read most of the interesting status including 
>the associations.
>
>There are several different versions of the peers command that squeeze 
>slightly different info into an 80 character line.  (Let us know if you find 
>that something is missing.)
>
>
>>      *   Daemon is up, but we need to allow runtime configuration for
>> different NTP servers, along with ?prefer? and ?version? setting for that
>> NTP server. Can we update the Daemon to pick up this new configuration or do
>> we have to write to the .conf file and then restart the daemon ? 
>
>ntpq has a :config command which feeds the rest of the line to the config 
>file parser.  I haven't used it.  I expect some parts will work fine and some 
>won't work because it's too late to change the baud rate on a refclock that 
>has already been opened and things like that.  (If you find interesting 
>examples that don't work, we may be able to fix them.)
>
>I think there is an unpeer command (in the config file, not ntpq) so you can 
>remove servers and add them again to change things.  Again, I haven't tried 
>it.
>
>>      *   Daemon is up, the user would provide the key-number and md5
>> clientpassword. We want to use this configuration for the specific server
>> instead of using autokey. Can a restart of the Daemon be avoided when
>> setting authentication with the ntp client. 
>
>I haven't tried Autokey.  Shared keys (MD5 and SHA1) work.  I don't know if 
>you can reload the keys file from ntpq.
>
>
>>      *   Does the Daemon support configuring of Broadcast, Multicast or
>> Manycasting clients.
>
>I've tried most of those options, but I might have missed one.  Everything I 
>have tried worked, but sometimes it took me a while to set it up correctly.
>
>>      *   Does the Daemon support Ipv6 Configuration ? If so does Daemon
>> support mixed Ipv4 and Ipv6 NTP server configuration ? 
>
>Yes.  Yes.
>
>
>
>-- 
>These are my opinions.  I hate spam.
>
>
>

From hmurray at megapathdsl.net  Tue Jan  5 22:30:37 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 05 Jan 2016 14:30:37 -0800
Subject: NTPsec on OpenSwitch
In-Reply-To: Message from "Srivatsan,
 Srinivasan" <srinivasan.srivatsan@hpe.com> of "Tue,
 05 Jan 2016 21:26:46 GMT." <AE893ED6-FBF8-4FA0-913D-4E6A289741B3@hpe.com>
Message-ID: <20160105223037.171AB406057@ip-64-139-1-69.sjc.megapath.net>


srinivasan.srivatsan at hpe.com said:
> *  I have enabled a control key but was unable to configure a server through
> a single ntpq command because it keeps on asking for keyid and password for
> configuration through ntpq. But it would be helpful to add a server with a
> single ntpq command with all the options on it, including the keyid and
> password. Have you used it this way ?  

I haven't tried that.  I just edit the config file and restart ntpd.  If that 
isn't convenient in your environment, it's probably simpler to debug things 
on a pair of PCs.

Read the shared key stuff.  The keyid is the slot number in the server's 
shared key file.  The password is the corresponding password.  Or something 
like that.

> *  I see that the password is set using 'crypto pw??? and its all plain text.
> Is there a way to save the password differently or configure the password
> during runtime ? 

I think that's a different password.  It's for decoding the autokey stuff 
which hasn't been tested and isn't generally used.



srinivasan.srivatsan at hpe.com said:
> *  Could you share the configuration and commands which you used for your
> tests ?
> *  I have not tested authentication scenario, what is the server
> configuration which you used for testing authentication.  

For the shared key stuff, use ntpkeygen -M to make a batch of keys.  It will 
make 10 MD5 keys.  If you have the openssl libraries (and headers) installed, 
it will also make 10 more SHA1 keys.

Put the file on both server and client.  You need something like this in your 
config file on both client and server:
  keys      /etc/ntp/ntp.keys
  trustedkey (1 ... 20)

The 20 assumes you have SSL.  If not, use 10.

Then on the client, you say something like:
  server 1.2.3.4 key 3

The important idea is that the slot you pick (3 above) has to have the same 
line in the keys file on both machines - both systems use the same slot 
number as well as the same key.

If you run tcpdump, the length of the packet changes depending on if you have 
 none, MD5, or SHA1 keys.

I don't know of any easy way to debug the authentication stuff.  None of the 
log files nor ntpq tell you anything helpful.  If it works, ntpq will show 
you the same stuff as it does without authentication.

Actually, there are a few syslog messages and a few counters but I forget 
where they are.




-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Wed Jan  6 08:40:43 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 06 Jan 2016 00:40:43 -0800
Subject: Replay progress report
In-Reply-To: Message from Eric <esr@thyrsus.com>
 of "Mon, 04 Jan 2016 12:19:27 EST." <20160104171927.GA6204@thyrsus.com>
Message-ID: <20160106084043.ED9BC406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> This scheme depends on the assumption that, before the main loop, intercept
> functions will be called in the exact same order during replay that they
> were during capture.  There's no separate replay interpreter that is
> dispatching events itself, so there is no way to handle a getaddrinfo event.

Ahh.  I think you need a dispatching layer.  DNS is just the tip of the 
iceberg.

You also need to handle timeouts from the select and anything else the normal 
main loop does.  That includes signal handling.  I think most of the signal 
handlers just set a flag then the main loop notices the flag and does the 
work.

Currently, the only interesting signal tells ntpd to exit.

There are signal handlers to incr/decr the debug level.  I think those get "processed" at interrupt level.  That will be hard to intercept.  Do we want to replay debugging stuff?

I think there is an I/O signal handler.  The idea was to grab arriving packets "now" to get a better time stamp in case the CPU is tied up doing crypto, and queue them up for the main loop to process.  That isn't necessary if the kernel time-stamps arriving packets.  I haven't looked for this code.

Refclocks will add another place to dispatch.

You will also need to intercept PPS.

----------

I divide lines in the replay log file into 3 types:
  input - for the dispatcher
    these are generally asynchronous events
  environment - time, random
  output - packets, time adjustments, writes to files (drift, syslog, stats) 

---------

I have half baked code for a signal that will reopen various files:
  log file (for syslog stuff, to cooperate with logrotate)
  leap file
  authentication keys

ntpd checks for a new leap file occasionally.  The signal lets you verify that your new leap file works without having to wait for ntpd to get around to noticing it.

The stats files have their own mechanism to roll over to another file name.

-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Wed Jan  6 15:56:32 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 6 Jan 2016 10:56:32 -0500
Subject: Replay progress report
In-Reply-To: <20160106084043.ED9BC406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160104171927.GA6204@thyrsus.com>
 <20160106084043.ED9BC406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160106155632.GC636@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > This scheme depends on the assumption that, before the main loop, intercept
> > functions will be called in the exact same order during replay that they
> > were during capture.  There's no separate replay interpreter that is
> > dispatching events itself, so there is no way to handle a getaddrinfo event.
> 
> Ahh.  I think you need a dispatching layer.  DNS is just the tip of the 
> iceberg.

You may be right, but this is complexity I am strenuously trying to
avoid while I get the basic function up.

> You also need to handle timeouts from the select and anything else the normal 
> main loop does.  That includes signal handling.  I think most of the signal 
> handlers just set a flag then the main loop notices the flag and does the 
> work.
> 
> Currently, the only interesting signal tells ntpd to exit.

Right, that doesn't require a full dispatch layer.

> There are signal handlers to incr/decr the debug level.  I think those get "processed" at interrupt level.  That will be hard to intercept.  Do we want to replay debugging stuff?

Maybe eventually, but that is way fancier than I want to try to get yet.

> I think there is an I/O signal handler.  The idea was to grab arriving packets "now" to get a better time stamp in case the CPU is tied up doing crypto, and queue them up for the main loop to process.  That isn't necessary if the kernel time-stamps arriving packets.  I haven't looked for this code.

That's in the part replay nrcessarily bypasses.

> Refclocks will add another place to dispatch.
> 
> You will also need to intercept PPS.

I belive this is what is most likely to force me to a full dispatch layer
eventually.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Thu Jan  7 09:57:09 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 07 Jan 2016 01:57:09 -0800
Subject: Replay progress report
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Wed, 06 Jan 2016 10:56:32 EST." <20160106155632.GC636@thyrsus.com>
Message-ID: <20160107095709.EA212406057@ip-64-139-1-69.sjc.megapath.net>


>> Ahh.  I think you need a dispatching layer.  DNS is just the
>> tip of the iceberg.
> You may be right, but this is complexity I am strenuously trying to avoid
> while I get the basic function up. 

What's the current problem?  How far does it get?

How are you handling timeouts from the main select?  I'd expect there to be 
calls to get the time in there that would cause you troubles.

Actually, I think the dispatching layer will be pretty simple after you do it.

-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Thu Jan  7 10:23:48 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 7 Jan 2016 05:23:48 -0500
Subject: Replay progress report
In-Reply-To: <20160107095709.EA212406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160106155632.GC636@thyrsus.com>
 <20160107095709.EA212406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160107102348.GA9195@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> What's the current problem?  How far does it get?

In the simple capture I have now, it gets all the way to the first
receive, but replay then fails to call adjtime() as expected from the
capture.

My current belief is that replay mode is not populating the peer
list correctly; I am instrumenting to check this.

The bad news is that I'm deep into trying to trace the behavior of difficult
code.  The good news is that this could be the last problem before I get
a first full replay.

> How are you handling timeouts from the main select?  I'd expect there to be 
> calls to get the time in there that would cause you troubles.

Any time call that is in pure I/O is not captured, precisely in order
to avoid problems on replay.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Thu Jan  7 11:07:16 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 07 Jan 2016 03:07:16 -0800
Subject: Replay progress report
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Thu, 07 Jan 2016 05:23:48 EST." <20160107102348.GA9195@thyrsus.com>
Message-ID: <20160107110716.C0C0C406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> In the simple capture I have now, it gets all the way to the first receive,
> but replay then fails to call adjtime() as expected from the capture.

> My current belief is that replay mode is not populating the peer list
> correctly; I am instrumenting to check this.

What does the log file look like?  If you turn on lots of logging, it will 
tell you when it sets up a peer.  I use:
  logfile /var/log/ntp/ntpd.log
  logconfig =syncall +clockall +peerall +sysall

 3 Dec 10:29:15 ntpd[31873]: 192.168.1.3 8011 81 mobilize assoc 35989
 3 Dec 10:29:17 ntpd[31873]: 192.168.1.3 8024 84 reachable


We should start a collection of debugging routines to print out things like 
the list of peers.  The idea is to be able to call it from gdb.  In this 
case, you would have to run your test case in non-replay mode to see what it 
should look like, then compare with what it says when replay doesn't work.

> Any time call that is in pure I/O is not captured, precisely in order to
> avoid problems on replay. 

What does "pure I/O" mean?


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Thu Jan  7 11:31:14 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 7 Jan 2016 06:31:14 -0500
Subject: Replay progress report
In-Reply-To: <20160107110716.C0C0C406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160107102348.GA9195@thyrsus.com>
 <20160107110716.C0C0C406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160107113114.GA15266@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> We should start a collection of debugging routines to print out things like 
> the list of peers.  The idea is to be able to call it from gdb.  In this 
> case, you would have to run your test case in non-replay mode to see what it 
> should look like, then compare with what it says when replay doesn't work.

This is *exactly* what I am working on. Or, rather, was working on before
I got interrupted by urgent GPSD bug reports and concluded I needed to ship
a release. I expect to be back on NTPsec later today.

> > Any time call that is in pure I/O is not captured, precisely in order to
> > avoid problems on replay. 
> 
> What does "pure I/O" mean?

The part of the main select that replay bypasses - that isn't receive() or
the intercepted functions beneath it.  Corresponds closely to what's
in ntp_io.c.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From ghane0 at gmail.com  Sat Jan  9 04:14:34 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 9 Jan 2016 12:14:34 +0800
Subject: Building HTML documentation
Message-ID: <CAHZk5WfYoP1HGyzFuqE=UXUt4X-_c=3mGXrrwj3jQKTvgNvnpQ@mail.gmail.com>

Hi,

waf build man pages, but how do I build HTML documentation (using the build
system)?

My plan is to print out and proof-read the doc/ directory; and push merge
requests via gitlab (first time I am trying this, rather than email patches
to the list).

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160109/4ae652ac/attachment.html>

From ghane0 at gmail.com  Sat Jan  9 04:34:57 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 9 Jan 2016 12:34:57 +0800
Subject: Buildbot slaves
Message-ID: <CAHZk5WdeOs+9NAPidSSz_SrR3U=uTkr2vR7jxkKKuGP3AEyv5g@mail.gmail.com>

Amar,

Do you still require VMs for buildbots?  I can offer you a 16G VMWare
server, and install your choices of Linux/BSD/Windows on them (the Windows
will be licensed, not sure of the build system).

Server will have IPv6 as well.  You will retain root access on the VMs.

Please let me know.
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160109/18f87fa6/attachment.html>

From verm at darkbeer.org  Sat Jan  9 04:43:23 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Sat, 9 Jan 2016 04:43:23 +0000
Subject: Buildbot slaves
In-Reply-To: <CAHZk5WdeOs+9NAPidSSz_SrR3U=uTkr2vR7jxkKKuGP3AEyv5g@mail.gmail.com>
References: <CAHZk5WdeOs+9NAPidSSz_SrR3U=uTkr2vR7jxkKKuGP3AEyv5g@mail.gmail.com>
Message-ID: <20160109044323.GA38966@darkbeer.org>

On 2016-01-09 12:34 +0800, Sanjeev Gupta wrote:
> Amar,
> 
> Do you still require VMs for buildbots??? I can offer you a 16G VMWare server,
> and install your choices of Linux/BSD/Windows on them (the Windows will be
> licensed, not sure of the build system).

We have gotten access to various hosting providers I'll be working on setting 
up on there next week.  I will keep your offer in mind!


> Server will have IPv6 as well.?? You will retain root access on the VMs.

OK, thank you for letting me know.


Amar.

From hmurray at megapathdsl.net  Sat Jan  9 05:25:08 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 08 Jan 2016 21:25:08 -0800
Subject: Building HTML documentation
Message-ID: <20160109052508.B523F406057@ip-64-139-1-69.sjc.megapath.net>


ghane0 at gmail.com said:
> waf build man pages, but how do I build HTML documentation (using the build
> system)? 

waf configure --enable-doc (or --enable-doc-only)

waf configure --help will show you the options.


-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Sat Jan  9 06:03:45 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 9 Jan 2016 14:03:45 +0800
Subject: Building HTML documentation
In-Reply-To: <20160109052508.B523F406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160109052508.B523F406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5WdjBHWKzQD1tKvkjZUqW0NKuxAKJgsXChUS9GbzVyEnHg@mail.gmail.com>

On Sat, Jan 9, 2016 at 1:25 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> ghane0 at gmail.com said:
> > waf build man pages, but how do I build HTML documentation (using the
> build
> > system)?
>
> waf configure --enable-doc (or --enable-doc-only)
>

The --enable-doc option to waf configure seems a no-op.  See
http://pastebin.com/rVf3RX6S


> waf configure --help will show you the options.


Ack.  The man pages get built (I can see asciidoc being called), but not
HTML.

Might be relevant, but I see temp files left in the build directory. Eg,

sanjeev at X201wily:~/SRC/ntpsec$ ls -l build/ntptrace/
total 12
-rwxr-xr-x 1 sanjeev sanjeev 3313 Jan  9 12:41 ntptrace
-rw-rw-r-- 1 sanjeev sanjeev 3406 Jan  9 12:41 ntptrace.1
-rw-rw-r-- 1 sanjeev sanjeev  334 Jan  9 12:41 ntptrace-man.txt.man-tmp

I am on a Ubuntu 16.04-dev.  I have some experience with asciidoc, mostly
when I think LaTex is overkill for a small document, and with the gpsd
project.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160109/dd3fb6ab/attachment.html>

From hmurray at megapathdsl.net  Sat Jan  9 06:56:25 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 08 Jan 2016 22:56:25 -0800
Subject: Building HTML documentation
In-Reply-To: Message from Sanjeev Gupta <ghane0@gmail.com> of "Sat,
 09 Jan 2016 14:03:45 +0800."
 <CAHZk5WdjBHWKzQD1tKvkjZUqW0NKuxAKJgsXChUS9GbzVyEnHg@mail.gmail.com>
Message-ID: <20160109065626.05ACE406057@ip-64-139-1-69.sjc.megapath.net>


ghane0 at gmail.com said:
> The --enable-doc option to waf configure seems a no-op.

It leaves a flag behind somewhere so that "waf build" will make the html docs.

"waf build -v" will show the command line:

[  1/171] Compiling docs/access.txt
22:54:50 runner ['/usr/bin/asciidoc', '-b', 'html5', '-a', 'linkcss', '-f', 
'/home/murray/ntpsec/play/docs/asciidoc.conf', '-o', 'access.html', 
'/home/murray/ntpsec/play/docs/access.txt']
[  2/171] Compiling docs/accopt.txt
22:54:51 runner ['/usr/bin/asciidoc', '-b', 'html5', '-a', 'linkcss', '-f', 
'/home/murray/ntpsec/play/docs/asciidoc.conf', '-o', 'accopt.html', 
'/home/murray/ntpsec/play/docs/accopt.txt']
[  3/171] Compiling docs/assoc.txt
22:54:52 runner ['/usr/bin/asciidoc', '-b', 'html5', '-a', 'linkcss', '-f', 
'/home/murray/ntpsec/play/docs/asciidoc.conf', '-o', 'assoc.html', 
'/home/murray/ntpsec/play/docs/assoc.txt']


-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Sat Jan  9 07:15:04 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 9 Jan 2016 15:15:04 +0800
Subject: Building HTML documentation
In-Reply-To: <20160109065626.05ACE406057@ip-64-139-1-69.sjc.megapath.net>
References: <ghane0@gmail.com>
 <CAHZk5WdjBHWKzQD1tKvkjZUqW0NKuxAKJgsXChUS9GbzVyEnHg@mail.gmail.com>
 <20160109065626.05ACE406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5We_Ssjib1REjVSVVzubAgHfbHqzDOsY4PfV2dO=2zq8hA@mail.gmail.com>

On Sat, Jan 9, 2016 at 2:56 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> ghane0 at gmail.com said:
> > The --enable-doc option to waf configure seems a no-op.
>
> It leaves a flag behind somewhere so that "waf build" will make the html
> docs.
>
> "waf build -v" will show the command line:
>
> [  1/171] Compiling docs/access.txt
> 22:54:50 runner ['/usr/bin/asciidoc', '-b', 'html5', '-a', 'linkcss',
> '-f',
> '/home/murray/ntpsec/play/docs/asciidoc.conf', '-o', 'access.html',
> '/home/murray/ntpsec/play/docs/access.txt']


And it did.  I kept trying the build with the --enable-docs , not the
configure .

Thank you.  Expect a slew of typo fixes over the next few days, vir gitlab
PRs.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160109/355ccb13/attachment.html>

From ghane0 at gmail.com  Sun Jan 10 03:03:57 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 10 Jan 2016 11:03:57 +0800
Subject: driver36 [WWV / WWH decoder]
Message-ID: <CAHZk5Wd+2a6QCnrifShaXmD1CrL9YvXzn7NPa7gm8FLwwJct4A@mail.gmail.com>

Hi,

The doc file for driver36 is missing in the docs.  Has this driver been
dropped, or the file just not been ported over?  If the latter, I can copy
and reformat from Dr Mills' site.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160110/3aab57c6/attachment.html>

From hmurray at megapathdsl.net  Sun Jan 10 03:35:39 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 09 Jan 2016 19:35:39 -0800
Subject: driver36 [WWV / WWH decoder]
Message-ID: <20160110033539.91611406061@ip-64-139-1-69.sjc.megapath.net>


> The doc file for driver36 is missing in the docs.  Has this driver been
> dropped, ...

Yes, it's been dropped.

Do you use it?




-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Sun Jan 10 04:01:52 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 10 Jan 2016 12:01:52 +0800
Subject: driver36 [WWV / WWH decoder]
In-Reply-To: <20160110033539.91611406061@ip-64-139-1-69.sjc.megapath.net>
References: <20160110033539.91611406061@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5WdUo3-GM9bh3a1H5oNtp+zVGRir9XBr+Lka1RQmYR688g@mail.gmail.com>

On Sun, Jan 10, 2016 at 11:35 AM, Hal Murray <hmurray at megapathdsl.net>
wrote:

> Yes, it's been dropped.
>
> Do you use it?
>

Not at all, (I am in Singapore).

I will remove references to it in the docs.  Thanks.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160110/8dba36db/attachment.html>

From hmurray at megapathdsl.net  Sun Jan 10 07:32:51 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 09 Jan 2016 23:32:51 -0800
Subject: DNS thread simplification
Message-ID: <20160110073251.B0A20406061@ip-64-139-1-69.sjc.megapath.net>


In case anybody is thinking about this area...

The current code has two modes, one for server lookup and another for pool 
lookup.  The difference is that a server only wants 1 address and the pool 
can use several.

We can simplify the handoff to/from the thread if it always returns all the 
IP Addresses that it finds and the server code picks one.

-- 
These are my opinions.  I hate spam.




From srinivasan.srivatsan at hpe.com  Mon Jan 11 23:02:15 2016
From: srinivasan.srivatsan at hpe.com (Srivatsan, Srinivasan)
Date: Mon, 11 Jan 2016 23:02:15 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <20160105223037.171AB406057@ip-64-139-1-69.sjc.megapath.net>
References: <srinivasan.srivatsan@hpe.com>
 <AE893ED6-FBF8-4FA0-913D-4E6A289741B3@hpe.com>
 <20160105223037.171AB406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <0E5AD137-A637-4639-B064-02E086100971@hpe.com>

Thanks Hal,

Hal/Amar,
Regarding the issue with ?waf configure?. Is there a way to bypass the configure step ? And  provide a default configuration to work with ?

Thanks
Srinivasan


On 1/5/16, 2:30 PM, "Hal Murray" <hmurray at megapathdsl.net> wrote:

>
>srinivasan.srivatsan at hpe.com said:
>> *  I have enabled a control key but was unable to configure a server through
>> a single ntpq command because it keeps on asking for keyid and password for
>> configuration through ntpq. But it would be helpful to add a server with a
>> single ntpq command with all the options on it, including the keyid and
>> password. Have you used it this way ?  
>
>I haven't tried that.  I just edit the config file and restart ntpd.  If that 
>isn't convenient in your environment, it's probably simpler to debug things 
>on a pair of PCs.
>
>Read the shared key stuff.  The keyid is the slot number in the server's 
>shared key file.  The password is the corresponding password.  Or something 
>like that.
>
>> *  I see that the password is set using 'crypto pw??? and its all plain text.
>> Is there a way to save the password differently or configure the password
>> during runtime ? 
>
>I think that's a different password.  It's for decoding the autokey stuff 
>which hasn't been tested and isn't generally used.
>
>
>
>srinivasan.srivatsan at hpe.com said:
>> *  Could you share the configuration and commands which you used for your
>> tests ?
>> *  I have not tested authentication scenario, what is the server
>> configuration which you used for testing authentication.  
>
>For the shared key stuff, use ntpkeygen -M to make a batch of keys.  It will 
>make 10 MD5 keys.  If you have the openssl libraries (and headers) installed, 
>it will also make 10 more SHA1 keys.
>
>Put the file on both server and client.  You need something like this in your 
>config file on both client and server:
>  keys      /etc/ntp/ntp.keys
>  trustedkey (1 ... 20)
>
>The 20 assumes you have SSL.  If not, use 10.
>
>Then on the client, you say something like:
>  server 1.2.3.4 key 3
>
>The important idea is that the slot you pick (3 above) has to have the same 
>line in the keys file on both machines - both systems use the same slot 
>number as well as the same key.
>
>If you run tcpdump, the length of the packet changes depending on if you have 
> none, MD5, or SHA1 keys.
>
>I don't know of any easy way to debug the authentication stuff.  None of the 
>log files nor ntpq tell you anything helpful.  If it works, ntpq will show 
>you the same stuff as it does without authentication.
>
>Actually, there are a few syslog messages and a few counters but I forget 
>where they are.
>
>
>
>
>-- 
>These are my opinions.  I hate spam.
>
>
>

From hmurray at megapathdsl.net  Tue Jan 12 00:27:24 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 11 Jan 2016 16:27:24 -0800
Subject: NTPsec on OpenSwitch
In-Reply-To: Message from "Srivatsan,
 Srinivasan" <srinivasan.srivatsan@hpe.com> of "Mon,
 11 Jan 2016 23:02:15 GMT." <0E5AD137-A637-4639-B064-02E086100971@hpe.com>
Message-ID: <20160112002724.AB6E8406057@ip-64-139-1-69.sjc.megapath.net>


srinivasan.srivatsan at hpe.com said:
> Regarding the issue with ???waf configure???. Is there a way to bypass the
> configure step ? And  provide a default configuration to work with ? 

Not that I know of.  Why would you want to do that and/or what are you trying 
to do?

Perhaps there is some confusion with the word "configure".

"waf configure" is part of the build process.  It sets up things for "waf 
build" and makes build/config.h which is included by most modules when they 
get compiled and linked to make ntpd.

The other use for the word "configure" is the run time parameters for ntpd 
that come from the command line and a configuration file which defaults to 
/etc/ntp.conf

If your problem is ntp.conf, it can be pretty simple.  (You can actually do 
it all from the command line.)

Do you have servers you want to use?  Then ntp.conf can be as simple as:

server <server1>
server <server2>
server <server3>


You can get ideas from the ntp.conf on any handy Linux or BSD box..



-- 
These are my opinions.  I hate spam.




From srinivasan.srivatsan at hpe.com  Tue Jan 12 01:01:16 2016
From: srinivasan.srivatsan at hpe.com (Srivatsan, Srinivasan)
Date: Tue, 12 Jan 2016 01:01:16 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <20160112002724.AB6E8406057@ip-64-139-1-69.sjc.megapath.net>
References: <srinivasan.srivatsan@hpe.com>
 <0E5AD137-A637-4639-B064-02E086100971@hpe.com>
 <20160112002724.AB6E8406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <9971E7AB-C90A-467C-B154-3E621CAB0347@hpe.com>

Hal,

Sorry for the confusion. I was referring to ?waf configure? which is part of the build process. What I meant was instead of ?checking C compiler? or any of the other binaries/libraries ?waf configure? step would check for. Would it be possible to provide a config file which it can take instead of ?running? a test executable and finding the info out.

Regards
Srinivasan



On 1/11/16, 4:27 PM, "Hal Murray" <hmurray at megapathdsl.net> wrote:

>
>srinivasan.srivatsan at hpe.com said:
>> Regarding the issue with ?waf configure?. Is there a way to bypass the
>> configure step ? And  provide a default configuration to work with ? 
>
>Not that I know of.  Why would you want to do that and/or what are you trying 
>to do?
>
>Perhaps there is some confusion with the word "configure".
>
>"waf configure" is part of the build process.  It sets up things for "waf 
>build" and makes build/config.h which is included by most modules when they 
>get compiled and linked to make ntpd.
>
>The other use for the word "configure" is the run time parameters for ntpd 
>that come from the command line and a configuration file which defaults to 
>/etc/ntp.conf
>
>If your problem is ntp.conf, it can be pretty simple.  (You can actually do 
>it all from the command line.)
>
>Do you have servers you want to use?  Then ntp.conf can be as simple as:
>
>server <server1>
>server <server2>
>server <server3>
>
>
>You can get ideas from the ntp.conf on any handy Linux or BSD box..
>
>
>
>-- 
>These are my opinions.  I hate spam.
>
>
>

From hmurray at megapathdsl.net  Tue Jan 12 05:49:44 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 11 Jan 2016 21:49:44 -0800
Subject: NTPsec on OpenSwitch
In-Reply-To: Message from "Srivatsan,
 Srinivasan" <srinivasan.srivatsan@hpe.com> of "Tue,
 12 Jan 2016 01:01:16 GMT." <9971E7AB-C90A-467C-B154-3E621CAB0347@hpe.com>
Message-ID: <20160112054944.BBBC3406057@ip-64-139-1-69.sjc.megapath.net>


srinivasan.srivatsan at hpe.com said:
> Sorry for the confusion. I was referring to ???waf configure??? which is part of
> the build process. What I meant was instead of ???checking C compiler??? or any
> of the other binaries/libraries ???waf configure??? step would check for. Would
> it be possible to provide a config file which it can take instead of
> ???running??? a test executable and finding the info out. 

I don't know how to do that.

What is the real problem?  It normally doesn't take long enough that anybody 
has investigated avoiding that step.

If you have edited some source file(s), you don't need to run configure 
again.  "waf build" will re-compile/link what is appropriate.

-- 
These are my opinions.  I hate spam.




From srinivasan.srivatsan at hpe.com  Tue Jan 12 19:15:33 2016
From: srinivasan.srivatsan at hpe.com (Srivatsan, Srinivasan)
Date: Tue, 12 Jan 2016 19:15:33 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <20160112054944.BBBC3406057@ip-64-139-1-69.sjc.megapath.net>
References: <srinivasan.srivatsan@hpe.com>
 <9971E7AB-C90A-467C-B154-3E621CAB0347@hpe.com>
 <20160112054944.BBBC3406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <4D53A29C-F407-4794-9EDB-D5FE3D556DEE@hpe.com>

Hal,

I was able to compile/build/install ntpsec locally on my ubuntu vm. But when I try and configure ntpsec using a yocto environment which uses ntpsec.bb recipe am unable to do so. For this I have detailed how and where it has failed, below is the snippet of the conversation for that. Only when we have this ?waf configure? step corrected, we?ll be able to use ntpsec with the yocto environment which openswitch uses. That?s where I need help from NTPsec-devel. 

Snippet from previous conversation:
One major issue I see when enabling the NTPsec recipe with my build process is when doing the ?waf configure? step it fails. I see it internally calls a configuration script to check the compiler. For checking the compiler it generates a C file, compiles it and tries to execute to find get a specific value from the executable. Currently I see it fail at the last step, because it fails to execute the generated executable with ?No such file or directory?. I?ve posted the build/config.log file and ldd,readelf,objdump for the testbuild/testprog which is created in this process. Could you please provide pointers on how to fix this. Link to paste bin: http://pastebin.com/raw/AJBMpqsb 


Recipe file is located at: https://review.openswitch.net/#/c/2991/




Regards
Srinivasan


On 1/11/16, 9:49 PM, "Hal Murray" <hmurray at megapathdsl.net> wrote:

>
>srinivasan.srivatsan at hpe.com said:
>> Sorry for the confusion. I was referring to ?waf configure? which is part of
>> the build process. What I meant was instead of ?checking C compiler? or any
>> of the other binaries/libraries ?waf configure? step would check for. Would
>> it be possible to provide a config file which it can take instead of
>> ?running? a test executable and finding the info out. 
>
>I don't know how to do that.
>
>What is the real problem?  It normally doesn't take long enough that anybody 
>has investigated avoiding that step.
>
>If you have edited some source file(s), you don't need to run configure 
>again.  "waf build" will re-compile/link what is appropriate.
>
>-- 
>These are my opinions.  I hate spam.
>
>
>

From verm at darkbeer.org  Tue Jan 12 19:28:21 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Tue, 12 Jan 2016 19:28:21 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <4D53A29C-F407-4794-9EDB-D5FE3D556DEE@hpe.com>
References: <srinivasan.srivatsan@hpe.com>
 <9971E7AB-C90A-467C-B154-3E621CAB0347@hpe.com>
 <20160112054944.BBBC3406057@ip-64-139-1-69.sjc.megapath.net>
 <4D53A29C-F407-4794-9EDB-D5FE3D556DEE@hpe.com>
Message-ID: <20160112192821.GA20349@darkbeer.org>

On 2016-01-12 19:15 +0000, Srivatsan, Srinivasan wrote:
> One major issue I see when enabling the NTPsec recipe with my build process is 
> when doing the ???waf configure??? step it fails. I see it internally calls a 
> configuration script to check the compiler. For checking the compiler it 
> generates a C file, compiles it and tries to execute to find get a specific 
> value from the executable. Currently I see it fail at the last step, because 
> it fails to execute the generated executable with ???No such file or 
> directory???. I???ve posted the build/config.log file and ldd,readelf,objdump 
> for the testbuild/testprog which is created in this process. Could you please 
> provide pointers on how to fix this. Link to paste bin: 
> http://pastebin.com/raw/AJBMpqsb

I've never seen this happen before.  I'll take a look at it later today.

Can you try this version of waf to see if anything changes?

  https://waf.io/waf-1.8.18


Amar.

From hmurray at megapathdsl.net  Tue Jan 12 19:39:11 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 12 Jan 2016 11:39:11 -0800
Subject: NTPsec on OpenSwitch
In-Reply-To: Message from "Srivatsan,
 Srinivasan" <srinivasan.srivatsan@hpe.com> of "Tue,
 12 Jan 2016 19:15:33 GMT." <4D53A29C-F407-4794-9EDB-D5FE3D556DEE@hpe.com>
Message-ID: <20160112193911.90362406057@ip-64-139-1-69.sjc.megapath.net>


waf builds and runs several tiny programs to see if the environment contains 
things like header files and procedures.

It looks like it's trying to run an ELF file on a system that doesn't support 
ELF files.  I'm guessing you are cross compiling.  I don't think we have 
tried that yet.

That's Amar's territory.


-- 
These are my opinions.  I hate spam.




From verm at darkbeer.org  Tue Jan 12 19:44:41 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Tue, 12 Jan 2016 19:44:41 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <20160112193911.90362406057@ip-64-139-1-69.sjc.megapath.net>
References: <srinivasan.srivatsan@hpe.com>
 <4D53A29C-F407-4794-9EDB-D5FE3D556DEE@hpe.com>
 <20160112193911.90362406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160112194441.GA20690@darkbeer.org>

On 2016-01-12 11:39 -0800, Hal Murray wrote:
> It looks like it's trying to run an ELF file on a system that doesn't support 
> ELF files.  I'm guessing you are cross compiling.  I don't think we have 
> tried that yet.

Oh, it's a cross compile?  Yes, that is not supported at the moment.  Though the 
error shouldn't be 'No such file or directory'.

Cross compile support will be fixed at some point once the build is cleaned up.

I don't know about supplying a config.h and _c4che.py and skipping configure we 
can discuss this offlist if you like.


Amar.

From hmurray at megapathdsl.net  Tue Jan 12 22:07:24 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 12 Jan 2016 14:07:24 -0800
Subject: NTPsec on OpenSwitch
In-Reply-To: Message from Hal Murray <hmurray@megapathdsl.net> of "Tue,
 12 Jan 2016 11:39:11 PST."
 <20160112193911.90362406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160112220724.0E33F406057@ip-64-139-1-69.sjc.megapath.net>


verm at darkbeer.org said:
> Oh, it's a cross compile?  Yes, that is not supported at the moment.  Though
> the  error shouldn't be 'No such file or directory'. 

My cross-compile idea could well be a wild goose chase.

Srinivasan: Can you please try running the file by hand, both when cd-ed to 
the local directory and when using the full long name.  If it works, waf has 
troubles running the file rather than building it.

Are there any non-execute permissions along the directory chain?


-- 
These are my opinions.  I hate spam.




From srinivasan.srivatsan at hpe.com  Tue Jan 12 22:40:01 2016
From: srinivasan.srivatsan at hpe.com (Srivatsan, Srinivasan)
Date: Tue, 12 Jan 2016 22:40:01 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <20160112220724.0E33F406057@ip-64-139-1-69.sjc.megapath.net>
References: <hmurray@megapathdsl.net>
 <20160112193911.90362406057@ip-64-139-1-69.sjc.megapath.net>
 <20160112220724.0E33F406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <158EE8DA-A5F0-4112-AF84-2C9AA17A6AC8@hpe.com>

Hal/Amar,

Responses inline. When are we looking to support cross compiling ? 


On 1/12/16, 2:07 PM, "Hal Murray" <hmurray at megapathdsl.net> wrote:

>
>verm at darkbeer.org said:
>> Oh, it's a cross compile?  Yes, that is not supported at the moment.  Though
>> the  error shouldn't be 'No such file or directory'. 
>
>My cross-compile idea could well be a wild goose chase.
>
>Srinivasan: Can you please try running the file by hand, both when cd-ed to 
>the local directory and when using the full long name.  If it works, waf has 
>troubles running the file rather than building it.

[srinsriv] I ran it both ways and it still shows ?No such file or directory?. But If I ran it as /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 OR put my ubuntu vm?s ld-linux-x86-64.so.2 in the path then it seems to work. Which means its unable to find the library its looking for when its xcompiling.

Regards
Srinivasan
>
>Are there any non-execute permissions along the directory chain?
[srinsriv] Permissions are fine for the executable. More info at http://pastebin.com/raw/AJBMpqsb
$ ls -lrt
total 24
-rw-r--r-- 1 srinsriv srinsriv 6272 Jan 5 13:12 test.c.1.o
-rwxr-xr-x 1 srinsriv srinsriv 13032 Jan 5 13:12 testprog

>
[Amar]
Can you try this version of waf to see if anything changes?
  https://waf.io/waf-1.8.18
[srinsriv] This version does not work either. Why do you think that the waf version would help us resolve this issue ?. Logs stored at http://pastebin.com/raw/ULRP3Vg9


>
>

From verm at darkbeer.org  Tue Jan 12 22:43:50 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Tue, 12 Jan 2016 22:43:50 +0000
Subject: NTPsec on OpenSwitch
In-Reply-To: <158EE8DA-A5F0-4112-AF84-2C9AA17A6AC8@hpe.com>
References: <hmurray@megapathdsl.net>
 <20160112193911.90362406057@ip-64-139-1-69.sjc.megapath.net>
 <20160112220724.0E33F406057@ip-64-139-1-69.sjc.megapath.net>
 <158EE8DA-A5F0-4112-AF84-2C9AA17A6AC8@hpe.com>
Message-ID: <20160112224350.GA24199@darkbeer.org>

On 2016-01-12 22:40 +0000, Srivatsan, Srinivasan wrote:
> Hal/Amar,
> 
> Responses inline. When are we looking to support cross compiling ? 
<snip>

The changes to the build system I started in December should fix cross compiling 
I'm not sure when it will be I need to cutover Buildbot first and get the 
testsuite formed up.

> [srinsriv] This version does not work either. Why do you think that the waf 
> version would help us resolve this issue ?. Logs stored at 
> http://pastebin.com/raw/ULRP3Vg9

I didn't think it would fix the problem I was looking for a better error 
message.  What I'm trying to figure out is why it's saying "No such file or 
directory."  I think the only way to fix this is to setup a local environment 
and try to replicate the issue.

I can work with you offline to hack around this so you can cross compile please 
send me an email directly explaining what you're trying to do and what 
architecture / compiler.

Thanks.


Amar.

From hmurray at megapathdsl.net  Wed Jan 13 00:29:26 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 12 Jan 2016 16:29:26 -0800
Subject: NTPsec on OpenSwitch
In-Reply-To: Message from "Srivatsan,
 Srinivasan" <srinivasan.srivatsan@hpe.com> of "Tue,
 12 Jan 2016 22:40:01 GMT." <158EE8DA-A5F0-4112-AF84-2C9AA17A6AC8@hpe.com>
Message-ID: <20160113002926.2F3B8406057@ip-64-139-1-69.sjc.megapath.net>


> [srinsriv] I ran it both ways and it still shows ???No such file or
> directory???. But If I ran it as /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 OR
> put my ubuntu vm???s ld-linux-x86-64.so.2 in the path then it seems to work.
> Which means its unable to find the library its looking for when its
> xcompiling. 

What environment are you running on and what is your target?

If the problem is only that it can't find a library, you may be able to hack 
around that by adding a link from your normal library location over to 
wherever the file lives.


-- 
These are my opinions.  I hate spam.




From verm at darkbeer.org  Fri Jan 15 02:22:07 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Fri, 15 Jan 2016 02:22:07 +0000
Subject: Cross-compiling update.
Message-ID: <20160115022207.GA74080@darkbeer.org>

This is more work than I was expecting I was nearly done but (re)discovered that 
keyword-gen uses libntp!

I want to avoid building libntp twice if the host and target are the same so I 
need to refactor a little.  I have variants working in waf I'll tackle this 
tomorrow.

I'll also hookup cross-compiling under buildbot so we can catch as many 
architecture issues as possible during compile-time.

I also discovered one quirk by accident when compiling for ARM:

  37:#error libntp supplied mktime()/timegm() do not support 64-bit time_t

I wonder how often users will hit that?


Amar.

From hmurray at megapathdsl.net  Fri Jan 15 03:04:17 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 14 Jan 2016 19:04:17 -0800
Subject: Cross-compiling update.
In-Reply-To: Message from Amar Takhar <verm@darkbeer.org>
 of "Fri, 15 Jan 2016 02:22:07 GMT." <20160115022207.GA74080@darkbeer.org>
Message-ID: <20160115030417.B5038406057@ip-64-139-1-69.sjc.megapath.net>


verm at darkbeer.org said:
> This is more work than I was expecting I was nearly done but (re)discovered
> that  keyword-gen uses libntp! 

Will it simplify things if I fix that?


> I also discovered one quirk by accident when compiling for ARM:
>   37:#error libntp supplied mktime()/timegm() do not support 64-bit time_t
> I wonder how often users will hit that?

How did you generate that error?

Do we really need our copy of mktime and timegm?  Is that one more piece of 
cruft we can get rid of?

grep says that timegm isn't used.

My Linux man page says:
   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
       asctime_r(), ctime_r(), gmtime_r(), localtime_r():
              _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _BSD_SOURCE ||
              _SVID_SOURCE || _POSIX_SOURCE

I think that means if we are assuming POSIX, gmtime will be there.



-- 
These are my opinions.  I hate spam.




From verm at darkbeer.org  Fri Jan 15 03:13:22 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Fri, 15 Jan 2016 03:13:22 +0000
Subject: Cross-compiling update.
In-Reply-To: <20160115030417.B5038406057@ip-64-139-1-69.sjc.megapath.net>
References: <verm@darkbeer.org> <20160115022207.GA74080@darkbeer.org>
 <20160115030417.B5038406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160115031322.GA76909@darkbeer.org>

On 2016-01-14 19:04 -0800, Hal Murray wrote:
> 
> verm at darkbeer.org said:
> > This is more work than I was expecting I was nearly done but (re)discovered
> > that  keyword-gen uses libntp! 
> 
> Will it simplify things if I fix that?

Yes, by a large amount it is very worth it if we can make it depend only on 
itself.


> > I also discovered one quirk by accident when compiling for ARM:
> >   37:#error libntp supplied mktime()/timegm() do not support 64-bit time_t
> > I wonder how often users will hit that?
> 
> How did you generate that error?

I'm not sure, it's not detecting timegm in the ARM libraries I'm using for some 
reason it's probably an odd environment quirk.  I'm setting up a proper one 
tomorrow morning that I can copy over to Buildbot.


> Do we really need our copy of mktime and timegm?  Is that one more piece of 
> cruft we can get rid of?

No idea, are there any systems that don't have a mktime that we need?


> grep says that timegm isn't used.
> 
> My Linux man page says:
>    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
>        asctime_r(), ctime_r(), gmtime_r(), localtime_r():
>               _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _BSD_SOURCE ||
>               _SVID_SOURCE || _POSIX_SOURCE
> 
> I think that means if we are assuming POSIX, gmtime will be there.

I think this is the case, too.


Amar.

From hmurray at megapathdsl.net  Fri Jan 15 03:38:23 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 14 Jan 2016 19:38:23 -0800
Subject: Cross-compiling update.
In-Reply-To: Message from Amar Takhar <verm@darkbeer.org>
 of "Fri, 15 Jan 2016 03:13:22 GMT." <20160115031322.GA76909@darkbeer.org>
Message-ID: <20160115033823.5BB82406057@ip-64-139-1-69.sjc.megapath.net>

[fix keyword-gen]

> Yes, by a large amount it is very worth it if we can make it depend only on
> itself. 


verm at darkbeer.org said:
>> How did you generate that error?
> I'm not sure, it's not detecting timegm in the ARM libraries I'm using for
> some  reason it's probably an odd environment quirk.  I'm setting up a
> proper one  tomorrow morning that I can copy over to Buildbot. 

I haven't noticed any quirks on a Raspberry Pi.  It's based on Debian.

>> I think that means if we are assuming POSIX, gmtime will be there.
>I think this is the case, too.

[nuke mktime and timegm]
> No idea, are there any systems that don't have a mktime that we need?

If we discover one, we can decide what to do.

I'll nuke them now and then work on keygen.

-------

Maybe we should have a waf option to only build ntpd.  The idea is that you 
would run all the other programs on a real machine.


-- 
These are my opinions.  I hate spam.




From verm at darkbeer.org  Fri Jan 15 03:44:58 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Fri, 15 Jan 2016 03:44:58 +0000
Subject: Cross-compiling update.
In-Reply-To: <20160115033823.5BB82406057@ip-64-139-1-69.sjc.megapath.net>
References: <verm@darkbeer.org> <20160115031322.GA76909@darkbeer.org>
 <20160115033823.5BB82406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160115034458.GA77419@darkbeer.org>

On 2016-01-14 19:38 -0800, Hal Murray wrote:
> 
> I haven't noticed any quirks on a Raspberry Pi.  It's based on Debian.

This was a cross compile I'm assuming something was wrong with the environment I 
threw together.  I'll get a proper one going tomorrow.


> Maybe we should have a waf option to only build ntpd.  The idea is that you 
> would run all the other programs on a real machine.

I don't think that's necessary.  Once I fix this problem everything else will do 
the right thing.  I would rather get wider testing than have users focus on one 
part.


Amar.

From hmurray at megapathdsl.net  Fri Jan 15 04:35:44 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 14 Jan 2016 20:35:44 -0800
Subject: keyword-gen
Message-ID: <20160115043544.AA1A8406057@ip-64-139-1-69.sjc.megapath.net>


I just pushed a version that doesn't depend on libntp (or any other 
non-default library).



-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Fri Jan 15 09:50:13 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 15 Jan 2016 01:50:13 -0800
Subject: Posix threads
Message-ID: <20160115095013.DAF5F406057@ip-64-139-1-69.sjc.megapath.net>

I'm looking for cruft to clean up.

If we have pthreads, will we also have pthread_attr_getstacksize and 
pthread_attr_setstacksize?

devel/hacking.txt says
> You can view POSIX-1.2001, with 2004 Corrigendum, online for free here:
>    http://pubs.opengroup.org/onlinepubs/009695399/toc.htm

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstack
size.html says:

The pthread_attr_getstacksize() and pthread_attr_setstacksize() functions are 
marked as part of the Threads and Thread Stack Size Attribute options.

The restrict keyword is added to the pthread_attr_getstacksize() prototype 
for alignment with the ISO/IEC 9899:1999 standard.

I can't figure out if that means somebody could implement Threads without 
implementing Thread Stack Size.  Or even if they can, would anybody actually 
do it?


-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Fri Jan 15 18:29:34 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 16 Jan 2016 02:29:34 +0800
Subject: Using ntpsec in the poll
Message-ID: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>

Apologies for the cross posting.

Since Sun 10 Jan, I switched one of the servers I have in the pool,
ntpmon.dcs1.biz , to ntpsec 0.9.0 , with gpsd 17-dev

I am happy to report that over the last 5 days, all is well, and the server
continues to chug along happily.

I plan to run both the ntpsec and gpsd on the git HEAD, daily.

Thanks to Eric, Hal, Gary, Ask, et al; with a special shoutout to Beat for
the git teach/cheat sheet.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160116/71758d94/attachment.html>

From esr at thyrsus.com  Fri Jan 15 18:46:45 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 15 Jan 2016 13:46:45 -0500
Subject: [gpsd-dev] Using ntpsec in the poll
In-Reply-To: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>
References: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>
Message-ID: <20160115184645.GA24869@thyrsus.com>

Sanjeev Gupta <ghane0 at gmail.com>:
> Since Sun 10 Jan, I switched one of the servers I have in the pool,
> ntpmon.dcs1.biz , to ntpsec 0.9.0 , with gpsd 17-dev
> 
> I am happy to report that over the last 5 days, all is well, and the server
> continues to chug along happily.

Thanks.  A lot of hard work has gone into ntpsec, nice to know it's paying off.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From joel at rtems.org  Fri Jan 15 20:06:31 2016
From: joel at rtems.org (Joel Sherrill)
Date: Fri, 15 Jan 2016 14:06:31 -0600
Subject: Cross-compiling update.
In-Reply-To: <20160115030417.B5038406057@ip-64-139-1-69.sjc.megapath.net>
References: <verm@darkbeer.org> <20160115022207.GA74080@darkbeer.org>
 <20160115030417.B5038406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAF9ehCVfbZiaqZRt=OMV5LmhPObibd1RQM9R1nZ3DeLmiBOdyg@mail.gmail.com>

Do not use gmtime. Use gmtime_r.

As a rule, never use a method when there is a version with _r in the
standard. The version without _r is not thread safe.

--joel

On Thu, Jan 14, 2016 at 9:04 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

>
> verm at darkbeer.org said:
> > This is more work than I was expecting I was nearly done but
> (re)discovered
> > that  keyword-gen uses libntp!
>
> Will it simplify things if I fix that?
>
>
> > I also discovered one quirk by accident when compiling for ARM:
> >   37:#error libntp supplied mktime()/timegm() do not support 64-bit
> time_t
> > I wonder how often users will hit that?
>
> How did you generate that error?
>
> Do we really need our copy of mktime and timegm?  Is that one more piece of
> cruft we can get rid of?
>
> grep says that timegm isn't used.
>
> My Linux man page says:
>    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
>        asctime_r(), ctime_r(), gmtime_r(), localtime_r():
>               _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _BSD_SOURCE ||
>               _SVID_SOURCE || _POSIX_SOURCE
>
> I think that means if we are assuming POSIX, gmtime will be there.
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160115/5a01bd36/attachment.html>

From joel at rtems.org  Fri Jan 15 20:08:09 2016
From: joel at rtems.org (Joel Sherrill)
Date: Fri, 15 Jan 2016 14:08:09 -0600
Subject: Posix threads
In-Reply-To: <20160115095013.DAF5F406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160115095013.DAF5F406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAF9ehCWES4+U+F4GMXoCOEpp_m_O2L9cgVX+p8sU=T7cDaWD8Q@mail.gmail.com>

On Fri, Jan 15, 2016 at 3:50 AM, Hal Murray <hmurray at megapathdsl.net> wrote:

> I'm looking for cruft to clean up.
>
> If we have pthreads, will we also have pthread_attr_getstacksize and
> pthread_attr_setstacksize?
>
> devel/hacking.txt says
> > You can view POSIX-1.2001, with 2004 Corrigendum, online for free here:
> >    http://pubs.opengroup.org/onlinepubs/009695399/toc.htm
>
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstack
> size.html says:
>
> The pthread_attr_getstacksize() and pthread_attr_setstacksize() functions
> are
> marked as part of the Threads and Thread Stack Size Attribute options.
>
> The restrict keyword is added to the pthread_attr_getstacksize() prototype
> for alignment with the ISO/IEC 9899:1999 standard.
>
> I can't figure out if that means somebody could implement Threads without
> implementing Thread Stack Size.  Or even if they can, would anybody
> actually
> do it?
>
>
The bottom of the Open Group web pages have revision history and note which
issue version things appeared or changed. This is the 2013 version:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_attr_getstacksize.html

It has the history at the bottom and says it has been in since Issue 5 and
was updated to add restrict keyword in 2001 for Issue 6.

I think this means it is always in the NTPsec assumed base OS profile of
POSIX 2001 and C99. My RTEMS memory says we have had this since our first
pthreads support which would have been 1994. That may be what is called
Issue 5.

I have a paper copy of that POSIX version but forgot to check it at the
office.

Bottom line, assume it is safe to use in the NTPsec assumed POSIX 2001
baseline.
--joel

>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160115/5afeacbc/attachment.html>

From fallenpegasus at gmail.com  Fri Jan 15 21:59:45 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Fri, 15 Jan 2016 21:59:45 +0000
Subject: Using ntpsec in the poll
In-Reply-To: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>
References: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>
Message-ID: <CANW5CYU6tZyygawa1W7stV62BeRde8dnxcuqFmfqCdCkBZULZA@mail.gmail.com>

Awesome, thank you, Sanjeev!

Have you been logging it?  If so, we on the NTPsec team would like to see
it's logs, to see if there are any warnings or anything unexpected.

..m

On Fri, Jan 15, 2016 at 10:29 AM Sanjeev Gupta <ghane0 at gmail.com> wrote:

> Apologies for the cross posting.
>
> Since Sun 10 Jan, I switched one of the servers I have in the pool,
> ntpmon.dcs1.biz , to ntpsec 0.9.0 , with gpsd 17-dev
>
> I am happy to report that over the last 5 days, all is well, and the
> server continues to chug along happily.
>
> I plan to run both the ntpsec and gpsd on the git HEAD, daily.
>
> Thanks to Eric, Hal, Gary, Ask, et al; with a special shoutout to Beat for
> the git teach/cheat sheet.
>
> --
> Sanjeev Gupta
> +65 98551208     http://www.linkedin.com/in/ghane
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160115/930f91c9/attachment.html>

From hmurray at megapathdsl.net  Fri Jan 15 23:23:07 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 15 Jan 2016 15:23:07 -0800
Subject: Posix threads
In-Reply-To: Message from Joel Sherrill <joel.sherrill@gmail.com> of "Fri,
 15 Jan 2016 13:32:31 CST."
 <CAF9ehCWybQBpfPaGfCMxjT64rWADzkwf8MH5K7vgYQka8DUjoA@mail.gmail.com>
Message-ID: <20160115232307.E4919406057@ip-64-139-1-69.sjc.megapath.net>


joel.sherrill at gmail.com said:
> I think this means it is always in our base profile.

Thanks.  I just removed that pair of tests.  (also fixed a bug in error 
checking)


> Do not use gmtime. Use gmtime_r.

Thanks for the reminder.  There were only 2 cases left.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Fri Jan 15 23:29:21 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 15 Jan 2016 15:29:21 -0800
Subject: Error from buildbot
Message-ID: <20160115232921.52645406057@ip-64-139-1-69.sjc.megapath.net>

I just pushed a couple of changes that should either work or break 
everywhere.  They worked here.

I don't think they were related to this, so I'm assuming this problem is a 
quirk is something you are working on rather than a bug in my stuff.

'-I/usr/home/worker/worker/status/docs_ntpsec_org/build/libisc/include', 
'-I/usr/home/worker/worker/status/docs_ntpsec_org/build/libisc/unix/include', 
'-DNTPS_VERSION_MAJOR=0', '-DNTPS_VERSION_MINOR=0', '-DNTPS_VERSION_REV=0', 
'-DCOMPILER_CLANG=1', '-DDEBUG=1', 'ntpd/ntp_parser.tab.c', '-c', '-o', 
'/usr/home/worker/worker/status/docs_ntpsec_org/build/build/host/ntpd/ntp_pars
er.tab.c.1.o']
e/usr/home/worker/worker/status/docs_ntpsec_org/build/ntpd/ntp_parser.y:14:12:
 fatal error: 'config.h' file not found
e  #include <config.h>
e           ^
e1 error generated.

-- 
These are my opinions.  I hate spam.




From verm at darkbeer.org  Fri Jan 15 23:38:28 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Fri, 15 Jan 2016 23:38:28 +0000
Subject: Error from buildbot
In-Reply-To: <20160115232921.52645406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160115232921.52645406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160115233828.GA94976@darkbeer.org>

On 2016-01-15 15:29 -0800, Hal Murray wrote:
> I just pushed a couple of changes that should either work or break 
> everywhere.  They worked here.
> 
> I don't think they were related to this, so I'm assuming this problem is a 
> quirk is something you are working on rather than a bug in my stuff.

Haven't figured out why this is happening yet.  It's only the doc build and it 
may be local to the worker as I can't replicate it here.


Amar.

From kurt at roeckx.be  Sat Jan 16 00:12:43 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 16 Jan 2016 01:12:43 +0100
Subject: github mirror
Message-ID: <20160116001243.GB19449@roeckx.be>

Hi,

It seems the github mirror is out of date.


Kurt


From ghane0 at gmail.com  Sat Jan 16 03:51:48 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 16 Jan 2016 11:51:48 +0800
Subject: Using ntpsec in the poll
In-Reply-To: <CANW5CYU6tZyygawa1W7stV62BeRde8dnxcuqFmfqCdCkBZULZA@mail.gmail.com>
References: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>
 <CANW5CYU6tZyygawa1W7stV62BeRde8dnxcuqFmfqCdCkBZULZA@mail.gmail.com>
Message-ID: <CAHZk5WeJYLC43p=ju+xCLus3aLpscVFVL2cESPWDqeHsmKyDGg@mail.gmail.com>

On Sat, Jan 16, 2016 at 5:59 AM, Mark Atwood <fallenpegasus at gmail.com>
wrote:

> Have you been logging it?  If so, we on the NTPsec team would like to see
> it's logs, to see if there are any warnings or anything unexpected.


Can you please give me the stanza I should add?

I can also give people ssh access to the box, for debugging and playing
around.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160116/314d90e2/attachment.html>

From hmurray at megapathdsl.net  Sat Jan 16 06:54:41 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 15 Jan 2016 22:54:41 -0800
Subject: Using ntpsec in the poll
Message-ID: <20160116065441.9EF3C406057@ip-64-139-1-69.sjc.megapath.net>

>> Have you been logging it?  If so, we on the NTPsec team would like to see
>> it's logs, to see if there are any warnings or anything unexpected.

> Can you please give me the stanza I should add?

This is what I use:

logfile /var/log/ntp/ntpd.log
logconfig =syncall +clockall +peerall +sysall

statsdir /var/log/ntp/
filegen loopstats  type day link
filegen peerstats  type day link
filegen protostats type day link
filegen rawstats   type day link
filegen sysstats   type day link


The first two lines will put lots of syslog style messages into 
/var/log/ntp/ntpd.log  You can setup logrotate/newsyslog to rotate it, but 
ntpd won't switch to the new file until you restart it.  (So you don't want 
to compress it.)

There should be a batch of messages at startup and another batch at exit and 
not much in between.  If you find something that isn't reasonably obvious, 
ask me.
  

The second clump will put info into various files and rotate to new ones 
daily.  You probably want to add clockstats and turn on flag4 for the SHM 
driver.

Details on the stats files are in monopt.html
The clockstats info is different for each driver.  Look in the individual 
driverNN.html files.

You have to get the permissions on the directories right so ntpd can make new 
files after it has switched to a non-root user.

----------

All that doesn't tell you much about what your clients are doing.

There is an hourly summary in sysstats.

You can collect client info per-IPaddress by making the mrulist much bigger.

I'm using:
  mru initmem 32000 maxmem 64000 maxage 86400000
That will use up to 64 megabytes of memory and drop slots after 1000 days.

I set the age to super-long so it wouldn't automatically discard info that I 
might want.  It will also drop the oldest if it needs room for a new slot.  I 
haven't seen that with 64 megabytes.

I'll probably drop the age to 2 days now that I have a nightly cron job to 
capture the data.

Then "ntpq -c mru" will print the list for you.  Details are in the ntpq man 
page.  There is a mincount option to skip the light users.

I print everything from a cron job at midnight.  For a system in the pool 
with the default bandwidth, the file from the cron job grows about 2 
megabytes per day.

The mrulist only records time requests, both requests and responses.  It 
doesn't count ntpq/ntpdc packets so it won't show bad guys probing for DoS 
helpers.

I haven't seen any really nasty bad clients.




-- 
These are my opinions.  I hate spam.





-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sat Jan 16 19:24:19 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 16 Jan 2016 14:24:19 -0500 (EST)
Subject: Yup, it's the peer structures
Message-ID: <20160116192419.4F42D13A61FF@snark.thyraus.com>

I have verified that I'm not getting replicability on replay because
I'm not capturing the state of the peer list.

This is bad news, because the peer list is a dumping ground for a lot
of poorly managed state.  It has over a hundred members.

This leaves me with difficult choices.  I could brute-force the thing by
dumping the entire peer list state on each packet capture, and picking
it up on replay.  Or I could try to narrow the interface of receive()
so that it only needs to see the peer structure for the packet's
origin.  Or I could try to clean up the peer structure so it doesn't
have so damn much junk in it.  I might have to do all three...

Or, I'm increasingly worried that the present replay architecture may
just be wrong, a bad fit for where the complexity lives. I thought I
could bypass the network I/O layer on replay, but it may be that the
protocol processing is too entangled with it for that to practical.

If that's so, I will have to spoof packet recipt in the UDP read calls
rather than spoofing the protocol machine's receive() function (this
in order to get the peer structures updated properly).  That might
have problems of its own near the polling logic, unless we're willing
for replays to run as slowly as NTP.

It's a good thing we don't seem to have broken anything
functional, because any way I jump it's going to be damned hard
work and require my total concentration for well into the
foreseeable future.

Accordingly, I apologize for seeming kind of absent lately but
that's going to be normal for a while.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

In the absence of any evidence tending to show that possession 
or use of a 'shotgun having a barrel of less than eighteen inches 
in length' at this time has some reasonable relationship to the 
preservation or efficiency of a well regulated militia, we cannot 
say that the Second Amendment guarantees the right to keep and bear 
such an instrument. [...] The Militia comprised all males 
physically capable of acting in concert for the common defense.  
        -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939)

From hmurray at megapathdsl.net  Sat Jan 16 21:15:36 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sat, 16 Jan 2016 13:15:36 -0800
Subject: Yup, it's the peer structures
In-Reply-To: Message from esr@thyrsus.com (Eric S. Raymond) of "Sat,
 16 Jan 2016 14:24:19 EST." <20160116192419.4F42D13A61FF@snark.thyraus.com>
Message-ID: <20160116211536.14584406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> I have verified that I'm not getting replicability on replay because I'm not
> capturing the state of the peer list. 

Is the basic structure correct?  Right number of peers, right IP Addresses, 
...

If so, what is the difference between the play and the replay?


The problem could be as simple as you aren't capturing and replaying the 
timer returns from the main select.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sat Jan 16 21:36:57 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 16 Jan 2016 16:36:57 -0500
Subject: Yup, it's the peer structures
In-Reply-To: <20160116211536.14584406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160116192419.4F42D13A61FF@snark.thyraus.com>
 <20160116211536.14584406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160116213657.GA27403@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> Is the basic structure correct?  Right number of peers, right IP Addresses, 

My printfs don't tell me that for sure yet.

> The problem could be as simple as you aren't capturing and replaying the 
> timer returns from the main select.

Doubtful.  But I'm instrumenting to learn more.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From ghane0 at gmail.com  Sun Jan 17 01:43:54 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 17 Jan 2016 09:43:54 +0800
Subject: Using ntpsec in the poll
In-Reply-To: <20160116065441.9EF3C406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160116065441.9EF3C406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5WdBHuH4bS-pNGXFFJP-EfC7nr=ptKrs9qH4BrXwh3ke9g@mail.gmail.com>

On Sat, Jan 16, 2016 at 2:54 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> logfile /var/log/ntp/ntpd.log
> logconfig =syncall +clockall +peerall +sysall
>
> statsdir /var/log/ntp/
> filegen loopstats  type day link
> filegen peerstats  type day link
> filegen protostats type day link
> filegen rawstats   type day link
> filegen sysstats   type day link
>

Logs are available, at:

https://ntpmon.dcs1.biz/ntp

If there is anything you would like me to tweak in config, please do let me
know.

I will keep gpsd and ntpsec current, so the processes might restart.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160117/5b1f684d/attachment.html>

From fallenpegasus at gmail.com  Sun Jan 17 02:03:30 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Sun, 17 Jan 2016 02:03:30 +0000
Subject: github mirror
In-Reply-To: <20160116001243.GB19449@roeckx.be>
References: <20160116001243.GB19449@roeckx.be>
Message-ID: <CANW5CYXijq_pPgYi1SqcuYB92X19XKzRv=LJVtuJenWdPZQo6w@mail.gmail.com>

ill get that fixed

On Fri, Jan 15, 2016, 4:12 PM Kurt Roeckx <kurt at roeckx.be> wrote:

> Hi,
>
> It seems the github mirror is out of date.
>
>
> Kurt
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160117/dbb94802/attachment.html>

From ghane0 at gmail.com  Mon Jan 18 16:55:35 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Tue, 19 Jan 2016 00:55:35 +0800
Subject: GitLab pull request
Message-ID: <CAHZk5Wc9z9R_6k5ijf0KYpdttOSBd3rmnV9t7xYZXK4SK3rTFQ@mail.gmail.com>

Hi,

Can someone review and merge the pull request on GitLab?

Once this is done, and I am clear on how PRs work, I have a whole slew of
minor fixes in the documentation (broken links, typos, etc).

Thanks
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160119/053700f1/attachment.html>

From fallenpegasus at gmail.com  Tue Jan 19 07:44:43 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Mon, 18 Jan 2016 23:44:43 -0800
Subject: GitLab pull request
In-Reply-To: <CAHZk5Wc9z9R_6k5ijf0KYpdttOSBd3rmnV9t7xYZXK4SK3rTFQ@mail.gmail.com>
References: <CAHZk5Wc9z9R_6k5ijf0KYpdttOSBd3rmnV9t7xYZXK4SK3rTFQ@mail.gmail.com>
Message-ID: <etPan.569de989.27aa0f02.1cc0@Marks-MacBook.local>

Hello Sanjeev,

I?ve just merged your typo correction PRs. ?Thank you!

..m


On January 18, 2016 at 8:56:00 AM, Sanjeev Gupta (ghane0 at gmail.com) wrote:

Hi,

Can someone review and merge the pull request on GitLab?

Once this is done, and I am clear on how PRs work, I have a whole slew of minor fixes in the documentation (broken links, typos, etc).

Thanks
--
Sanjeev Gupta
+65 98551208? ?? http://www.linkedin.com/in/ghane
_______________________________________________  
devel mailing list  
devel at ntpsec.org  
http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160118/80f4a2e2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160118/80f4a2e2/attachment.bin>

From fallenpegasus at gmail.com  Tue Jan 19 21:21:34 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 19 Jan 2016 21:21:34 +0000
Subject: seeking brags for 0.9.1. and update the NEWS file
Message-ID: <CANW5CYWk_aRyaDYVAWv4snhHCL+cuDKmhkmRvMpvZRHfj-0Lfg@mail.gmail.com>

Hi!

We are very soon going to tag and release and announce version 0.9.1

Thus, we need to update the NEWS file.

Especially good are references to security issues that have cleared
embargo, and user and operator visible improvements.

Feel free to either email stuff to me, or else push a changeset with your
additions to the NEWS file.

Thanks everyone!

..m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160119/6322932d/attachment.html>

From verm at darkbeer.org  Tue Jan 19 21:22:47 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Tue, 19 Jan 2016 21:22:47 +0000
Subject: seeking brags for 0.9.1. and update the NEWS file
In-Reply-To: <CANW5CYWk_aRyaDYVAWv4snhHCL+cuDKmhkmRvMpvZRHfj-0Lfg@mail.gmail.com>
References: <CANW5CYWk_aRyaDYVAWv4snhHCL+cuDKmhkmRvMpvZRHfj-0Lfg@mail.gmail.com>
Message-ID: <20160119212247.GA86227@darkbeer.org>

On 2016-01-19 21:21 +0000, Mark Atwood wrote:
> Hi!
> 
> We are very soon going to tag and release and announce version 0.9.1
> 
> Thus, we need to update the NEWS file.
> 
> Especially good are references to security issues that have cleared embargo,
> and user and operator visible improvements.
> 
> Feel free to either email stuff to me, or else push a changeset with your
> additions to the NEWS file.

I will take a look at this first thing in the morning and add notes about the 
build improvements.

Very close to having cross compiling working I really want this in for 9.1.


Amar.

From fallenpegasus at gmail.com  Tue Jan 19 21:27:51 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 19 Jan 2016 21:27:51 +0000
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
Message-ID: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>

Hi!

We are hoping to tag, release, and announce 0.9.1 very soon.

If you have work that you have not pushed that you think should be in 0.9.1
that you are confident will not break it, please push it.

I would like a go/nogo from Hal, Daniel, Joel, Eric, Amar, and Susan.

If nogo, please say why.  And it's ok if your reason is "I have a bad
feeling about this".

Thank you everyone!

..m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160119/a2ba80b6/attachment.html>

From fallenpegasus at gmail.com  Tue Jan 19 21:46:03 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 19 Jan 2016 21:46:03 +0000
Subject: proposed policy change, new contributors use gitlab merge requests,
 not direct pushes
Message-ID: <CANW5CYV-OW4uSK9F05LtHKaPJc69JLPGttHWSvKUv9rbBgesPQ@mail.gmail.com>

Hi!

I am proposing instituting a project policy change, to generally not grant
write/push access to the main gitlab repo to any additional contributors.

Instead, we will ask contributors to open a gitlab merge request with their
change, and then members of the existing core team will review their merge
request and act on it.

If someone of amazing talent and wide ranging skill shows up, and they good
reasons to need push access, and are generally able to make a convincing
case for it, we can still grant it.

I will ask everyone to regularly look at the merge request queue at
https://gitlab.com/NTPsec/ntpsec/merge_requests and review and merge them
as they come, and to give the necessary feedback, shepherding, and
gratitude to contributors.

I do not yet see the need to add more complexity to this workflow, and
integrating it with the CI/CD and formalized review processes.  Nor am I
asking any of the existing core team to change their own workflow to use
merge requests instead of direct pushes.

If you have objections to this proposed change, please let me know, either
here in devel or privately.

Thank you!

..m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160119/ce9378b3/attachment.html>

From Matthew.Selsky at twosigma.com  Tue Jan 19 21:49:03 2016
From: Matthew.Selsky at twosigma.com (Matthew Selsky)
Date: Tue, 19 Jan 2016 16:49:03 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
References: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
Message-ID: <20160119214903.GC20684@twosigma.com>

On Tue, Jan 19, 2016 at 09:27:51PM +0000, Mark Atwood wrote:
> Hi!
> 
> We are hoping to tag, release, and announce 0.9.1 very soon.
> 
> If you have work that you have not pushed that you think should be in 0.9.1
> that you are confident will not break it, please push it.
> 
> I would like a go/nogo from Hal, Daniel, Joel, Eric, Amar, and Susan.
> 
> If nogo, please say why.  And it's ok if your reason is "I have a bad feeling
> about this".
> 
> Thank you everyone!
> 
> ..m

Mark,

Can we get the fix from https://gitlab.com/NTPsec/ntpsec/issues/28 committed?

Thanks,
-Matt


From verm at darkbeer.org  Tue Jan 19 21:59:16 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Tue, 19 Jan 2016 21:59:16 +0000
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <20160119214903.GC20684@twosigma.com>
References: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
 <20160119214903.GC20684@twosigma.com>
Message-ID: <20160119215916.GA86757@darkbeer.org>

I will look at this in the morning.


Amar.

From ghane0 at gmail.com  Sun Jan 17 01:43:54 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 17 Jan 2016 09:43:54 +0800
Subject: [Pool] Using ntpsec in the poll
In-Reply-To: <20160116065441.9EF3C406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160116065441.9EF3C406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5WdBHuH4bS-pNGXFFJP-EfC7nr=ptKrs9qH4BrXwh3ke9g@mail.gmail.com>

On Sat, Jan 16, 2016 at 2:54 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> logfile /var/log/ntp/ntpd.log
> logconfig =syncall +clockall +peerall +sysall
>
> statsdir /var/log/ntp/
> filegen loopstats  type day link
> filegen peerstats  type day link
> filegen protostats type day link
> filegen rawstats   type day link
> filegen sysstats   type day link
>

Logs are available, at:

https://ntpmon.dcs1.biz/ntp

If there is anything you would like me to tweak in config, please do let me
know.

I will keep gpsd and ntpsec current, so the processes might restart.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
_______________________________________________
pool mailing list
pool at lists.ntp.org
http://lists.ntp.org/listinfo/pool

From ghane0 at gmail.com  Fri Jan 15 18:29:34 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 16 Jan 2016 02:29:34 +0800
Subject: [Pool] Using ntpsec in the poll
Message-ID: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>

Apologies for the cross posting.

Since Sun 10 Jan, I switched one of the servers I have in the pool,
ntpmon.dcs1.biz , to ntpsec 0.9.0 , with gpsd 17-dev

I am happy to report that over the last 5 days, all is well, and the server
continues to chug along happily.

I plan to run both the ntpsec and gpsd on the git HEAD, daily.

Thanks to Eric, Hal, Gary, Ask, et al; with a special shoutout to Beat for
the git teach/cheat sheet.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
_______________________________________________
pool mailing list
pool at lists.ntp.org
http://lists.ntp.org/listinfo/pool

From hmurray at megapathdsl.net  Tue Jan 19 22:35:50 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 14:35:50 -0800
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: Message from Mark Atwood <fallenpegasus@gmail.com> of "Tue,
 19 Jan 2016 21:27:51 GMT."
 <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
Message-ID: <20160119223550.4575F406057@ip-64-139-1-69.sjc.megapath.net>

> We are hoping to tag, release, and announce 0.9.1 very soon.

I vote for waiting until Amar gets cross compiling sorted out.  It's close.

That will give you something for the brag list.

I'd also vote for a couple of days of no-changes while we all look for quirks 
before you actually push the button.  (Actually, that should be no changes to 
the code.  Tweaking the documentation is OK.)




-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Tue Jan 19 22:37:49 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 19 Jan 2016 17:37:49 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
References: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
Message-ID: <20160119223749.GA2322@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> Hi!
> 
> We are hoping to tag, release, and announce 0.9.1 very soon.
> 
> If you have work that you have not pushed that you think should be in 0.9.1
> that you are confident will not break it, please push it.
> 
> I would like a go/nogo from Hal, Daniel, Joel, Eric, Amar, and Susan.
> 
> If nogo, please say why.  And it's ok if your reason is "I have a bad
> feeling about this".
> 
> Thank you everyone!
> 
> ..m

Go.  I have no pending changes; I'm doing the replay work on a local branch.

I have a *good* feeling about this.  Our defect rate since the fork has
been, and continues to be, enviably low.  Well done everybody!
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From esr at thyrsus.com  Tue Jan 19 22:39:17 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 19 Jan 2016 17:39:17 -0500
Subject: proposed policy change, new contributors use gitlab merge
 requests, not direct pushes
In-Reply-To: <CANW5CYV-OW4uSK9F05LtHKaPJc69JLPGttHWSvKUv9rbBgesPQ@mail.gmail.com>
References: <CANW5CYV-OW4uSK9F05LtHKaPJc69JLPGttHWSvKUv9rbBgesPQ@mail.gmail.com>
Message-ID: <20160119223917.GB2322@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> Hi!
> 
> I am proposing instituting a project policy change, to generally not grant
> write/push access to the main gitlab repo to any additional contributors.
> 
> Instead, we will ask contributors to open a gitlab merge request with their
> change, and then members of the existing core team will review their merge
> request and act on it.
> 
> If someone of amazing talent and wide ranging skill shows up, and they good
> reasons to need push access, and are generally able to make a convincing
> case for it, we can still grant it.
> 
> I will ask everyone to regularly look at the merge request queue at
> https://gitlab.com/NTPsec/ntpsec/merge_requests and review and merge them
> as they come, and to give the necessary feedback, shepherding, and
> gratitude to contributors.
> 
> I do not yet see the need to add more complexity to this workflow, and
> integrating it with the CI/CD and formalized review processes.  Nor am I
> asking any of the existing core team to change their own workflow to use
> merge requests instead of direct pushes.
> 
> If you have objections to this proposed change, please let me know, either
> here in devel or privately.
> 
> Thank you!
> 
> ..m

No objection.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Tue Jan 19 23:06:35 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 15:06:35 -0800
Subject: proposed policy change, new contributors use gitlab merge 
 requests, not direct pushes
Message-ID: <20160119230635.3B773406057@ip-64-139-1-69.sjc.megapath.net>


fallenpegasus at gmail.com said:
> I am proposing instituting a project policy change, to generally not grant
> write/push access to the main gitlab repo to any additional contributors.

> Instead, we will ask contributors to open a gitlab merge request with their
> change, and then members of the existing core team will review their merge
> request and act on it. 

Seems fine to me.  I think there may be some fine print to work out.

I think there is some way to tell git to grab a patch and make it look like 
it was submitted by the author.  We need to document that recipe.

Is there a simple way I can pull the changes locally to try them out?  Again, 
we need documentation.

It may take a mailing list to get somebody to look for changes that need 
checking.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Tue Jan 19 23:28:28 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 15:28:28 -0800
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: Message from Mark Atwood <fallenpegasus@gmail.com> of "Tue,
 19 Jan 2016 21:27:51 GMT."
 <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
Message-ID: <20160119232828.5A9CE406057@ip-64-139-1-69.sjc.megapath.net>


Is this a good time to document what needs to happen to get out a release?

I think there are two areas.  One is a checklist of steps to get ready.  The 
other is how to actually do it.

Suggestions for the first part:
  Announce via email...
  Go through the Issues list.
  Testing time.



-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Wed Jan 20 01:38:56 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 20 Jan 2016 09:38:56 +0800
Subject: proposed policy change, new contributors use gitlab merge
 requests, not direct pushes
In-Reply-To: <CANW5CYV-OW4uSK9F05LtHKaPJc69JLPGttHWSvKUv9rbBgesPQ@mail.gmail.com>
References: <CANW5CYV-OW4uSK9F05LtHKaPJc69JLPGttHWSvKUv9rbBgesPQ@mail.gmail.com>
Message-ID: <CAHZk5WckBhHV2Bo=xv2EM6Vfm9ggp2HGpMdAao1q9=1TKPQc6g@mail.gmail.com>

On Wed, Jan 20, 2016 at 5:46 AM, Mark Atwood <fallenpegasus at gmail.com>
wrote:

> I will ask everyone to regularly look at the merge request queue at
> https://gitlab.com/NTPsec/ntpsec/merge_requests and review and merge them
> as they come, and to give the necessary feedback, shepherding, and
> gratitude to contributors.
>

May I request that someone also review
https://gitlab.com/NTPsec/www/merge_requests/ , regularly, please?

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160120/a95ee87f/attachment.html>

From ghane0 at gmail.com  Wed Jan 20 02:23:41 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 20 Jan 2016 10:23:41 +0800
Subject: Is Python2.5 a dependency
Message-ID: <CAHZk5Wd0pdyXnyPNPjUHmSfAs+2ktaSbCs4qb3h8OA9DmJHCew@mail.gmail.com>

Hi,


in www/supported-platforms.txt:

We expect the NTPsec code to run with at most minor port changes on
Unix-like operating systems conforming to POSIX.1-2001 and ISO/IEC
9899:1999 (aka C99) and supporting ntp_gettime(2)/ntp_adjtime(2).
Python 2.5 is also required.  We will fully support these platforms.

Is Python 2.5 required, or will Python 2.x (x>=5) do?  Most modern distros
have Python2 == 2.7.y

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160120/bf6b5fa4/attachment.html>

From verm at darkbeer.org  Wed Jan 20 02:34:16 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Wed, 20 Jan 2016 02:34:16 +0000
Subject: Is Python2.5 a dependency
In-Reply-To: <CAHZk5Wd0pdyXnyPNPjUHmSfAs+2ktaSbCs4qb3h8OA9DmJHCew@mail.gmail.com>
References: <CAHZk5Wd0pdyXnyPNPjUHmSfAs+2ktaSbCs4qb3h8OA9DmJHCew@mail.gmail.com>
Message-ID: <20160120023416.GA90952@darkbeer.org>

On 2016-01-20 10:23 +0800, Sanjeev Gupta wrote:
> Is Python 2.5 required, or will Python 2.x (x>=5) do??? Most modern distros have
> Python2 == 2.7.y

2.5+ is fine the build is not ready for 3.0+.  I will be working on that in the 
future.


Amar.

From dtpoirot at gmail.com  Wed Jan 20 02:48:16 2016
From: dtpoirot at gmail.com (Daniel Poirot)
Date: Tue, 19 Jan 2016 20:48:16 -0600
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
References: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
Message-ID: <CAPTtsGaiJfhCb3h0Fq76+qtxQ5K9K3m253x_8xpmd2xSFQwGcA@mail.gmail.com>

Hello Mark,

Eric let me know that he can no longer analyze.

I grabbed the code from GitLab a minute ago and generated the attached.


Best regards,
- dan


On Tue, Jan 19, 2016 at 3:27 PM, Mark Atwood <fallenpegasus at gmail.com> wrote:
> Hi!
>
> We are hoping to tag, release, and announce 0.9.1 very soon.
>
> If you have work that you have not pushed that you think should be in 0.9.1
> that you are confident will not break it, please push it.
>
> I would like a go/nogo from Hal, Daniel, Joel, Eric, Amar, and Susan.
>
> If nogo, please say why.  And it's ok if your reason is "I have a bad
> feeling about this".
>
> Thank you everyone!
>
> ..m
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTPsec.PDF
Type: application/pdf
Size: 82935 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160119/2fa1c021/attachment.pdf>

From ghane0 at gmail.com  Wed Jan 20 02:49:19 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 20 Jan 2016 10:49:19 +0800
Subject: Is Python2.5 a dependency
In-Reply-To: <20160120023416.GA90952@darkbeer.org>
References: <CAHZk5Wd0pdyXnyPNPjUHmSfAs+2ktaSbCs4qb3h8OA9DmJHCew@mail.gmail.com>
 <20160120023416.GA90952@darkbeer.org>
Message-ID: <CAHZk5WcbyJvZ2aKKRv8uWO1=mdQ18TvgdthdwqH+5uoLORcLww@mail.gmail.com>

On Wed, Jan 20, 2016 at 10:34 AM, Amar Takhar <verm at darkbeer.org> wrote:

> 2.5+ is fine the build is not ready for 3.0+


Thank you, I have pushed a PR for the www/ docs.  The text on the main
ntpsec INSTALL file was already correct.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160120/36dcc2c8/attachment.html>

From hmurray at megapathdsl.net  Wed Jan 20 03:04:08 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 19:04:08 -0800
Subject: Is Python2.5 a dependency
In-Reply-To: Message from Amar Takhar <verm@darkbeer.org>
 of "Wed, 20 Jan 2016 02:34:16 GMT." <20160120023416.GA90952@darkbeer.org>
Message-ID: <20160120030408.92CBC406057@ip-64-139-1-69.sjc.megapath.net>


verm at darkbeer.org said:
> 2.5+ is fine the build is not ready for 3.0+.  I will be working on that in
> the  future. 

It's worth pointing out that Python is only required on the build machine.  
ntpd will run fine without it, either on another instance of the same OS but 
with less stuff installed or on another target if cross compiled.


-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Wed Jan 20 03:21:09 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 20 Jan 2016 11:21:09 +0800
Subject: proposed policy change, new contributors use gitlab merge
 requests, not direct pushes
In-Reply-To: <CANW5CYVKaiCXnDyfH-Bvb=bnrKqsgywDgjO1rQTaJvk7PkKPgw@mail.gmail.com>
References: <CANW5CYV-OW4uSK9F05LtHKaPJc69JLPGttHWSvKUv9rbBgesPQ@mail.gmail.com>
 <CAHZk5WckBhHV2Bo=xv2EM6Vfm9ggp2HGpMdAao1q9=1TKPQc6g@mail.gmail.com>
 <CANW5CYVKaiCXnDyfH-Bvb=bnrKqsgywDgjO1rQTaJvk7PkKPgw@mail.gmail.com>
Message-ID: <CAHZk5Wdf=jLucpAUcaWURpOAD4TxL18OeOoBdQvHbxVwaHQcFQ@mail.gmail.com>

On Wed, Jan 20, 2016 at 10:48 AM, Mark Atwood <fallenpegasus at gmail.com>
wrote:

> Sanjeev, you have developer push access to www.
>
> You actually review and merge other contributors merge requests.
>

Apologies for the trivia.  I am cc:ing devel for help.

I was working on my own branches in my fork, and sending PR to www/master.

Mark informs me that I have been granted push access to www at GitLab.  In
the new scenario, I can create a *branch* locally (I delete my fork), and
push upstream to www/ .  I can see the new branch there, and can create a
PR, but I cannot actually merge it.

I think the reason is that www/master is "protected", so only Masters, not
Developers, can change into it.  Is this correct?

(If someone has a better workflow, I would appreciate it.  My contributions
will be low-hanging fruit, build testing, documentation, etc, only, no real
code).

Thanks,
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160120/7620b7f3/attachment.html>

From ghane0 at gmail.com  Wed Jan 20 03:21:47 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 20 Jan 2016 11:21:47 +0800
Subject: Is Python2.5 a dependency
In-Reply-To: <20160120030408.92CBC406057@ip-64-139-1-69.sjc.megapath.net>
References: <verm@darkbeer.org> <20160120023416.GA90952@darkbeer.org>
 <20160120030408.92CBC406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5Wf-n389ekjkW5qkrzhO=Mkt6zi_gEBBVu-xRkv2ohj19Q@mail.gmail.com>

On Wed, Jan 20, 2016 at 11:04 AM, Hal Murray <hmurray at megapathdsl.net>
wrote:

> It's worth pointing out that Python is only required on the build machine.


Only for waf ?  Or does something else require it as well in the build?

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160120/694647ec/attachment.html>

From esr at thyrsus.com  Wed Jan 20 04:04:37 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 19 Jan 2016 23:04:37 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <CAPTtsGaiJfhCb3h0Fq76+qtxQ5K9K3m253x_8xpmd2xSFQwGcA@mail.gmail.com>
References: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
 <CAPTtsGaiJfhCb3h0Fq76+qtxQ5K9K3m253x_8xpmd2xSFQwGcA@mail.gmail.com>
Message-ID: <20160120040437.GA5420@thyrsus.com>

Daniel Poirot <dtpoirot at gmail.com>:
> Hello Mark,
> 
> Eric let me know that he can no longer analyze.
> 
> I grabbed the code from GitLab a minute ago and generated the attached.
> 
> 
> Best regards,
> - dan

I don't consider this an 0.9.1 release blocker, because the code has
been pretty stable since the last successful scan.  But it will be a
significant issue when I start merging in replay changes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Wed Jan 20 04:30:41 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 20:30:41 -0800
Subject: Is Python2.5 a dependency
In-Reply-To: Message from Sanjeev Gupta <ghane0@gmail.com> of "Wed,
 20 Jan 2016 11:21:47 +0800."
 <CAHZk5Wf-n389ekjkW5qkrzhO=Mkt6zi_gEBBVu-xRkv2ohj19Q@mail.gmail.com>
Message-ID: <20160120043041.63D06406057@ip-64-139-1-69.sjc.megapath.net>

>> It's worth pointing out that Python is only required on the build machine.
> Only for waf ?  Or does something else require it as well in the build?

waf needs it.

I poked around a bit and didn't find anyplace other than waf where python is 
used.  On the other hand, we have mantioned reworking ntpq or writing 
something like it to use json and python.

"required" is an interesting term.  I consider ntpd to be the only required 
program.  It's common for some init scripts to use ntpdate.  I think ntpd has 
enough options to cover all those use cases but the details haven't been 
worked out.  So ntpfrob might be required too, and/or maybe a few scripts 
like ntp-wait.

The other stuff in there ranges from really useful, like ntpq, to something 
that somebody thought was useful a long time ago.  You can run ntpq on 
another machine, so it isn't really required on the target system.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Wed Jan 20 04:44:01 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 20:44:01 -0800
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Tue, 19 Jan 2016 23:04:37 EST." <20160120040437.GA5420@thyrsus.com>
Message-ID: <20160120044401.C1D8B406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> I don't consider this an 0.9.1 release blocker, because the code has been
> pretty stable since the last successful scan.  But it will be a significant
> issue when I start merging in replay changes. 

We can discuss whether it should be a blocker, but it just caught a bug I 
introduced when I fixed a bug in some error handling.

I think we should add something like "run all the checker tools" to the 
get-ready list.



-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Wed Jan 20 05:28:08 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 20 Jan 2016 00:28:08 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <20160120044401.C1D8B406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160120040437.GA5420@thyrsus.com>
 <20160120044401.C1D8B406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160120052808.GA6154@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I don't consider this an 0.9.1 release blocker, because the code has been
> > pretty stable since the last successful scan.  But it will be a significant
> > issue when I start merging in replay changes. 
> 
> We can discuss whether it should be a blocker, but it just caught a bug I 
> introduced when I fixed a bug in some error handling.

Urgh. You can still run scans?  I can't.  I think my cov tools are
obsolete since the gcc 5 changeover when I upgraded to Ubuntu 15.10 on
2 Jan, but I haven't been able to find a link to download
replacements.

How are you doing your scans?

> I think we should add something like "run all the checker tools" to the 
> get-ready list.

As a general thing I agree.  This is explicit in GPSD's release checklist.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Wed Jan 20 06:33:45 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 19 Jan 2016 22:33:45 -0800
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Wed, 20 Jan 2016 00:28:08 EST." <20160120052808.GA6154@thyrsus.com>
Message-ID: <20160120063345.73EAF406057@ip-64-139-1-69.sjc.megapath.net>

> How are you doing your scans?

I'm looking at the pdf that Daniel sent to the list.  :)

I fixed the other nasty bug.  I'm scratching my head on the minor ones.

------

A couple of the utilities use ntplib to get strlcat and/or the command line 
options stuff.  That drags in a whole pile of crap including threads.  I 
haven't figured out if it's worth splitting that out.


-- 
These are my opinions.  I hate spam.




From dtpoirot at gmail.com  Wed Jan 20 07:33:44 2016
From: dtpoirot at gmail.com (Dan Poirot)
Date: Wed, 20 Jan 2016 01:33:44 -0600
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <20160120052808.GA6154@thyrsus.com>
References: <esr@thyrsus.com> <20160120040437.GA5420@thyrsus.com>
 <20160120044401.C1D8B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160120052808.GA6154@thyrsus.com>
Message-ID: <001401d15354$e518efb0$af4acf10$@gmail.com>

Coverity sales engineer here. I use my local Coverity install.

I have also had Defensics fuzzing the service in 'continuous' mode for a few
days. I see timeouts using heavily loaded networks but haven't SEGFAULTed
the daemon in a long, long time.


Eric, have you used the NESTED_INDENT_MISMATCH checker before? Very cool and
very low false positves.

The guy who ran SCAN (and grew it from ~200 FOSS projects to over 6600
projects!) is no longer with the company. We have assigned the role to our
most senior PostgreSQL expert. He has become distracted by making some
changes and updates...


I would like to set us up with a Coverity 8.0 install but need a 64-bit
Linux to do the job.

- dan


-----Original Message-----
From: Eric S. Raymond [mailto:esr at thyrsus.com] 
Sent: Tuesday, January 19, 2016 11:28 PM
To: Hal Murray
Cc: Daniel Poirot; devel at ntpsec.org
Subject: Re: upcoming release 0.9.1. please push work, and answer go/nogo

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I don't consider this an 0.9.1 release blocker, because the code has 
> > been pretty stable since the last successful scan.  But it will be a 
> > significant issue when I start merging in replay changes.
> 
> We can discuss whether it should be a blocker, but it just caught a 
> bug I introduced when I fixed a bug in some error handling.

Urgh. You can still run scans?  I can't.  I think my cov tools are obsolete
since the gcc 5 changeover when I upgraded to Ubuntu 15.10 on
2 Jan, but I haven't been able to find a link to download replacements.

How are you doing your scans?

> I think we should add something like "run all the checker tools" to 
> the get-ready list.

As a general thing I agree.  This is explicit in GPSD's release checklist.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


From hmurray at megapathdsl.net  Wed Jan 20 10:31:29 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 20 Jan 2016 02:31:29 -0800
Subject: Bug: deadlock from msyslog
Message-ID: <20160120103129.BA607406057@ip-64-139-1-69.sjc.megapath.net>


A while (months) ago, we had troubles with msyslog scrambling output when 
called from the DNS thread and the main thread at the same time.  That was 
fixed by adding a lock.

That will deadlock if a signal handler calls msyslog when the signal goes off 
in the middle of a msyslog call.

I poked around a bit.  There are a few signal handlers that call msyslog.  I 
think they can be deferred.  It's probably worthwhile to study all the signal 
usage and make some notes.

The only timing critical signal handler that I know about would be the one 
grabbing the time of received packets.  That code doesn't get enabled by our 
current build system.  NTP Classic uses it on NetBSD.

-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Wed Jan 20 11:35:52 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 20 Jan 2016 06:35:52 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <20160120063345.73EAF406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160120052808.GA6154@thyrsus.com>
 <20160120063345.73EAF406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160120113552.GA7444@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> > How are you doing your scans?
> 
> I'm looking at the pdf that Daniel sent to the list.  :)

Oh, damn.

> A couple of the utilities use ntplib to get strlcat and/or the command line 
> options stuff.  That drags in a whole pile of crap including threads.  I 
> haven't figured out if it's worth splitting that out.

Um, I'd say...probably not, under modern conditions, but worth keeping
an eye on in case somebody deploying to constrained environments squawks.
It wouldn't take much argument to reverse me on this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From esr at thyrsus.com  Wed Jan 20 11:37:30 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 20 Jan 2016 06:37:30 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <001401d15354$e518efb0$af4acf10$@gmail.com>
References: <esr@thyrsus.com> <20160120040437.GA5420@thyrsus.com>
 <20160120044401.C1D8B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160120052808.GA6154@thyrsus.com>
 <001401d15354$e518efb0$af4acf10$@gmail.com>
Message-ID: <20160120113730.GB7444@thyrsus.com>

Dan Poirot <dtpoirot at gmail.com>:
> The guy who ran SCAN (and grew it from ~200 FOSS projects to over 6600
> projects!) is no longer with the company. We have assigned the role to our
> most senior PostgreSQL expert. He has become distracted by making some
> changes and updates...

Where can I download the latest scan tools?  Upgrading *might* solve the
problem.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From kurt at roeckx.be  Wed Jan 20 11:43:44 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 20 Jan 2016 12:43:44 +0100
Subject: Bug: deadlock from msyslog
In-Reply-To: <20160120103129.BA607406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160120103129.BA607406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160120114344.GA29004@roeckx.be>

On Wed, Jan 20, 2016 at 02:31:29AM -0800, Hal Murray wrote:
> 
> A while (months) ago, we had troubles with msyslog scrambling output when 
> called from the DNS thread and the main thread at the same time.  That was 
> fixed by adding a lock.
> 
> That will deadlock if a signal handler calls msyslog when the signal goes off 
> in the middle of a msyslog call.
> 
> I poked around a bit.  There are a few signal handlers that call msyslog.  I 
> think they can be deferred.  It's probably worthwhile to study all the signal 
> usage and make some notes.

You should be careful with signal handers.  The only thing you can
really do do in standard C is access a volatile sig_atomic_t, or
call functions like abort(), _exit(), or signal().  Your OS might provide
more async safe function, but that's implementation defined.
POSIX has a relative long list of such functions.

OpenBSD also defines some others async safe functions, like snprint(),
vsprint() and syslog_r().


Kurt


From joel at rtems.org  Wed Jan 20 16:57:35 2016
From: joel at rtems.org (Joel Sherrill)
Date: Wed, 20 Jan 2016 10:57:35 -0600
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <20160119223550.4575F406057@ip-64-139-1-69.sjc.megapath.net>
References: <fallenpegasus@gmail.com>
 <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
 <20160119223550.4575F406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAF9ehCXboE+EEoPDm5zQzunWr507XXmH9Pz9WLga8MQRg=Cb4A@mail.gmail.com>

On Tue, Jan 19, 2016 at 4:35 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> > We are hoping to tag, release, and announce 0.9.1 very soon.
>
> I vote for waiting until Amar gets cross compiling sorted out.  It's close.
>
> That will give you something for the brag list.
>
> I'd also vote for a couple of days of no-changes while we all look for
> quirks
> before you actually push the button.  (Actually, that should be no changes
> to
> the code.  Tweaking the documentation is OK.)
>
>
>
This is always prrudent before a release.

But ship it. Better to release often especially until we can get distros
and large deployments switched over.


>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160120/b9908c6d/attachment.html>

From dfoxfranke at gmail.com  Thu Jan 21 02:03:48 2016
From: dfoxfranke at gmail.com (Daniel Franke)
Date: Wed, 20 Jan 2016 21:03:48 -0500
Subject: upcoming release 0.9.1. please push work, and answer go/nogo
In-Reply-To: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
References: <CANW5CYWcU8i-Vkh-EPnhBe812ap8rJiU6DR0Tj46TR5Md=+WhQ@mail.gmail.com>
Message-ID: <CAJm83bCr=8rKnE8-uvvi0Ku3rnDw+v5ucRn80TtWgfUmqN+Ukw@mail.gmail.com>

My changes are pushed. Please abuse them as thoroughly as practical
under the given time constraints, and aim to tag a release sometime
tomorrow.

From ghane0 at gmail.com  Thu Jan 21 03:53:08 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Thu, 21 Jan 2016 11:53:08 +0800
Subject: Using ntpsec in the poll
In-Reply-To: <CANW5CYU6tZyygawa1W7stV62BeRde8dnxcuqFmfqCdCkBZULZA@mail.gmail.com>
References: <CAHZk5WcoVGB_oDLAiLCgmczcTNGLy_9q1fy6mKupvrmjWdzycw@mail.gmail.com>
 <CANW5CYU6tZyygawa1W7stV62BeRde8dnxcuqFmfqCdCkBZULZA@mail.gmail.com>
Message-ID: <CAHZk5WcOW9HK4=o4XgiHGs6O7PsZm30KPKcWBB=ikqC4LM0ogQ@mail.gmail.com>

On Sat, Jan 16, 2016 at 5:59 AM, Mark Atwood <fallenpegasus at gmail.com>
wrote:

>
> Have you been logging it?  If so, we on the NTPsec team would like to see
> it's logs, to see if there are any warnings or anything unexpected.
>

Hi,

Upgraded today:
ntpd 0.9.0-72b2d7b Jan 21 2016 11:23:19
gpsd: 3.17~dev (revision release-3.16-7-g9ef2aa9)

All seems good, logs at: https://ntpmon.dcs1.biz/ntp/

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160121/6c547920/attachment.html>

From hmurray at megapathdsl.net  Thu Jan 21 06:39:21 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 20 Jan 2016 22:39:21 -0800
Subject: Garbled error message
Message-ID: <20160121063921.2324E406057@ip-64-139-1-69.sjc.megapath.net>

I can't figure out what this is trying to tell me.

Checking for header dns_sd.h                                : not found
Checking if libcap works                                    : yes
Warning %s headers not detected, binaries build/run
Checking if libevent2 works                                 : yes
Checking if mDNSResponder works                             : no


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Thu Jan 21 17:35:05 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Thu, 21 Jan 2016 12:35:05 -0500
Subject: I have merged all pending www fixups
Message-ID: <20160121173505.GA19784@thyrsus.com>

I have merged all pending www fixups; the website is now clean and
synchromized for the release.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From ghane0 at gmail.com  Thu Jan 21 20:12:54 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Fri, 22 Jan 2016 04:12:54 +0800
Subject: I have merged all pending www fixups
In-Reply-To: <20160121173505.GA19784@thyrsus.com>
References: <20160121173505.GA19784@thyrsus.com>
Message-ID: <CAHZk5WcE6=EeWz-RiyZkz3RXfuGTeVLvJh1UzGuEs5h7SN_4aQ@mail.gmail.com>

On Fri, Jan 22, 2016 at 1:35 AM, Eric S. Raymond <esr at thyrsus.com> wrote:

> I have merged all pending www fixups; the website is now clean and
> synchromized for the release.
>

Eric,

   1. I see you have pulled in my patches, but at least one does not seem
   to be visible on the website (contributer.html , correct name of CC-BY
   licence).  Doesn't seem to be a cache issue, either.
   2. I am sending via email a check-in of asciidoc.js , required for the
   generated html

Thanks

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160122/c0a86dcc/attachment.html>

From ghane0 at gmail.com  Thu Jan 21 20:13:01 2016
From: ghane0 at gmail.com (Sanjeev)
Date: Fri, 22 Jan 2016 04:13:01 +0800
Subject: [PATCH 1/1] Add asciidoc.js , to keep the site clean
Message-ID: <1453407181-3539-1-git-send-email-ghane0@gmail.com>

We use asciidoc , and it needs both the .js and .css files.
Website is missing the .js

---
 asciidoc.js | 189 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 189 insertions(+)
 create mode 100644 asciidoc.js

diff --git a/asciidoc.js b/asciidoc.js
new file mode 100644
index 0000000..ac36563
--- /dev/null
+++ b/asciidoc.js
@@ -0,0 +1,189 @@
+var asciidoc = {  // Namespace.
+
+/////////////////////////////////////////////////////////////////////
+// Table Of Contents generator
+/////////////////////////////////////////////////////////////////////
+
+/* Author: Mihai Bazon, September 2002
+ * http://students.infoiasi.ro/~mishoo
+ *
+ * Table Of Content generator
+ * Version: 0.4
+ *
+ * Feel free to use this script under the terms of the GNU General Public
+ * License, as long as you do not remove or alter this notice.
+ */
+
+ /* modified by Troy D. Hanson, September 2006. License: GPL */
+ /* modified by Stuart Rackham, 2006, 2009. License: GPL */
+
+// toclevels = 1..4.
+toc: function (toclevels) {
+
+  function getText(el) {
+    var text = "";
+    for (var i = el.firstChild; i != null; i = i.nextSibling) {
+      if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
+        text += i.data;
+      else if (i.firstChild != null)
+        text += getText(i);
+    }
+    return text;
+  }
+
+  function TocEntry(el, text, toclevel) {
+    this.element = el;
+    this.text = text;
+    this.toclevel = toclevel;
+  }
+
+  function tocEntries(el, toclevels) {
+    var result = new Array;
+    var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
+    // Function that scans the DOM tree for header elements (the DOM2
+    // nodeIterator API would be a better technique but not supported by all
+    // browsers).
+    var iterate = function (el) {
+      for (var i = el.firstChild; i != null; i = i.nextSibling) {
+        if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
+          var mo = re.exec(i.tagName);
+          if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
+            result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
+          }
+          iterate(i);
+        }
+      }
+    }
+    iterate(el);
+    return result;
+  }
+
+  var toc = document.getElementById("toc");
+  if (!toc) {
+    return;
+  }
+
+  // Delete existing TOC entries in case we're reloading the TOC.
+  var tocEntriesToRemove = [];
+  var i;
+  for (i = 0; i < toc.childNodes.length; i++) {
+    var entry = toc.childNodes[i];
+    if (entry.nodeName.toLowerCase() == 'div'
+     && entry.getAttribute("class")
+     && entry.getAttribute("class").match(/^toclevel/))
+      tocEntriesToRemove.push(entry);
+  }
+  for (i = 0; i < tocEntriesToRemove.length; i++) {
+    toc.removeChild(tocEntriesToRemove[i]);
+  }
+  
+  // Rebuild TOC entries.
+  var entries = tocEntries(document.getElementById("content"), toclevels);
+  for (var i = 0; i < entries.length; ++i) {
+    var entry = entries[i];
+    if (entry.element.id == "")
+      entry.element.id = "_toc_" + i;
+    var a = document.createElement("a");
+    a.href = "#" + entry.element.id;
+    a.appendChild(document.createTextNode(entry.text));
+    var div = document.createElement("div");
+    div.appendChild(a);
+    div.className = "toclevel" + entry.toclevel;
+    toc.appendChild(div);
+  }
+  if (entries.length == 0)
+    toc.parentNode.removeChild(toc);
+},
+
+
+/////////////////////////////////////////////////////////////////////
+// Footnotes generator
+/////////////////////////////////////////////////////////////////////
+
+/* Based on footnote generation code from:
+ * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
+ */
+
+footnotes: function () {
+  // Delete existing footnote entries in case we're reloading the footnodes.
+  var i;
+  var noteholder = document.getElementById("footnotes");
+  if (!noteholder) {
+    return;
+  }
+  var entriesToRemove = [];
+  for (i = 0; i < noteholder.childNodes.length; i++) {
+    var entry = noteholder.childNodes[i];
+    if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
+      entriesToRemove.push(entry);
+  }
+  for (i = 0; i < entriesToRemove.length; i++) {
+    noteholder.removeChild(entriesToRemove[i]);
+  }
+
+  // Rebuild footnote entries.
+  var cont = document.getElementById("content");
+  var spans = cont.getElementsByTagName("span");
+  var refs = {};
+  var n = 0;
+  for (i=0; i<spans.length; i++) {
+    if (spans[i].className == "footnote") {
+      n++;
+      var note = spans[i].getAttribute("data-note");
+      if (!note) {
+        // Use [\s\S] in place of . so multi-line matches work.
+        // Because JavaScript has no s (dotall) regex flag.
+        note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
+        spans[i].innerHTML =
+          "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
+          "' title='View footnote' class='footnote'>" + n + "</a>]";
+        spans[i].setAttribute("data-note", note);
+      }
+      noteholder.innerHTML +=
+        "<div class='footnote' id='_footnote_" + n + "'>" +
+        "<a href='#_footnoteref_" + n + "' title='Return to text'>" +
+        n + "</a>. " + note + "</div>";
+      var id =spans[i].getAttribute("id");
+      if (id != null) refs["#"+id] = n;
+    }
+  }
+  if (n == 0)
+    noteholder.parentNode.removeChild(noteholder);
+  else {
+    // Process footnoterefs.
+    for (i=0; i<spans.length; i++) {
+      if (spans[i].className == "footnoteref") {
+        var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
+        href = href.match(/#.*/)[0];  // Because IE return full URL.
+        n = refs[href];
+        spans[i].innerHTML =
+          "[<a href='#_footnote_" + n +
+          "' title='View footnote' class='footnote'>" + n + "</a>]";
+      }
+    }
+  }
+},
+
+install: function(toclevels) {
+  var timerId;
+
+  function reinstall() {
+    asciidoc.footnotes();
+    if (toclevels) {
+      asciidoc.toc(toclevels);
+    }
+  }
+
+  function reinstallAndRemoveTimer() {
+    clearInterval(timerId);
+    reinstall();
+  }
+
+  timerId = setInterval(reinstall, 500);
+  if (document.addEventListener)
+    document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
+  else
+    window.onload = reinstallAndRemoveTimer;
+}
+
+}
-- 
2.7.0.rc3


From esr at thyrsus.com  Fri Jan 22 10:26:45 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 22 Jan 2016 05:26:45 -0500
Subject: I have merged all pending www fixups
In-Reply-To: <CAHZk5WcE6=EeWz-RiyZkz3RXfuGTeVLvJh1UzGuEs5h7SN_4aQ@mail.gmail.com>
References: <20160121173505.GA19784@thyrsus.com>
 <CAHZk5WcE6=EeWz-RiyZkz3RXfuGTeVLvJh1UzGuEs5h7SN_4aQ@mail.gmail.com>
Message-ID: <20160122102645.GA28879@thyrsus.com>

Sanjeev Gupta <ghane0 at gmail.com>:
> Eric,
> 
>    1. I see you have pulled in my patches, but at least one does not seem
>    to be visible on the website (contributer.html , correct name of CC-BY
>    licence).  Doesn't seem to be a cache issue, either.
>    2. I am sending via email a check-in of asciidoc.js , required for the
>    generated html

Please re-express these as a git patch.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From ghane0 at gmail.com  Fri Jan 22 15:32:14 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Fri, 22 Jan 2016 23:32:14 +0800
Subject: Broken links in ntpsec documentation
Message-ID: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>

Hi,

Crawling the docs/ directory, I am seeing broken links to external sites.
This is probably because hosts have disappeared, or vendors have moved
their website structure.

My rough count is about 15 broken links.

There are also fixable _syntax_ errors in mailto: , these are awaiting a
merge.  Hint, hint.

For the broken URLs, should one:

   1. Leave as is; bitrot will always occur, and much of the documentation
   has historical value as a record
   2. Try and locate a new copy; failing which elide the text

Guidance, please.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160122/75629bfa/attachment.html>

From verm at darkbeer.org  Fri Jan 22 15:34:37 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Fri, 22 Jan 2016 15:34:37 +0000
Subject: Broken links in ntpsec documentation
In-Reply-To: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
References: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
Message-ID: <20160122153437.GA50933@darkbeer.org>

On 2016-01-22 23:32 +0800, Sanjeev Gupta wrote:
>  2. Try and locate a new copy; failing which elide the text
> 
> Guidance, please.

I would leave the original URL but add a footnote with a URL to archive.org.  
Find a copy there the archive.org URL should be good forever but the original 
URL should stay to let users know where it came from.


Amar.

From ghane0 at gmail.com  Fri Jan 22 15:38:23 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Fri, 22 Jan 2016 23:38:23 +0800
Subject: Broken links in ntpsec documentation
In-Reply-To: <20160122153437.GA50933@darkbeer.org>
References: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
 <20160122153437.GA50933@darkbeer.org>
Message-ID: <CAHZk5WdTgDnHqigpTThksf3N_2B_2yXGUeHt+g87rQM_mmDiCQ@mail.gmail.com>

On Fri, Jan 22, 2016 at 11:34 PM, Amar Takhar <verm at darkbeer.org> wrote:

>
> I would leave the original URL but add a footnote with a URL to
> archive.org.
> Find a copy there the archive.org URL should be good forever but the
> original
> URL should stay to let users know where it came from.
>

Would it be better the other way: if found on archive.org, replace with
that link?  The archive link refers to and cites the original, anyway.

With a footnote, the user clicks, gets a 404, comes back, goes to the
footnote, at which point he has lost his place in the text (at least the
way I read web pages).

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160122/7010ce6b/attachment.html>

From verm at darkbeer.org  Fri Jan 22 15:42:38 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Fri, 22 Jan 2016 15:42:38 +0000
Subject: Broken links in ntpsec documentation
In-Reply-To: <CAHZk5WdTgDnHqigpTThksf3N_2B_2yXGUeHt+g87rQM_mmDiCQ@mail.gmail.com>
References: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
 <20160122153437.GA50933@darkbeer.org>
 <CAHZk5WdTgDnHqigpTThksf3N_2B_2yXGUeHt+g87rQM_mmDiCQ@mail.gmail.com>
Message-ID: <20160122154238.GA53554@darkbeer.org>

On 2016-01-22 23:38 +0800, Sanjeev Gupta wrote:
> 
> Would it be better the other way: if found on archive.org, replace with that
> link??? The archive link refers to and cites the original, anyway.
> 
> With a footnote, the user clicks, gets a 404, comes back, goes to the footnote,
> at which point he has lost his place in the text (at least the way I read web
> pages).

I've tried that in the past the problem is if somehow the archive.org content is 
wrong then the user is misdirected.  Keeping the original URL is better since 
some users may have known or know where to get a copy of the content if anyone 
cares they'll look at the footnote.  I'd rather them have no details vs wrong 
ones.


Amar.

From ghane0 at gmail.com  Fri Jan 22 16:21:56 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 23 Jan 2016 00:21:56 +0800
Subject: Garbled error message
In-Reply-To: <20160121063921.2324E406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160121063921.2324E406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAHZk5WeWAhD8xOX_A1acF4RscSpU0hic7WUyBys0f=ysf=ykaQ@mail.gmail.com>

There was a wrong parameter being passed to check_sanity (CAPABILITY
instead of libcap)

Fix committed, awaiting a review and merge.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

On Thu, Jan 21, 2016 at 2:39 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> I can't figure out what this is trying to tell me.
>
> Checking for header dns_sd.h                                : not found
> Checking if libcap works                                    : yes
> Warning %s headers not detected, binaries build/run
> Checking if libevent2 works                                 : yes
> Checking if mDNSResponder works                             : no
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160123/b39b7433/attachment.html>

From ghane0 at gmail.com  Fri Jan 22 16:22:52 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sat, 23 Jan 2016 00:22:52 +0800
Subject: Broken links in ntpsec documentation
In-Reply-To: <20160122154238.GA53554@darkbeer.org>
References: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
 <20160122153437.GA50933@darkbeer.org>
 <CAHZk5WdTgDnHqigpTThksf3N_2B_2yXGUeHt+g87rQM_mmDiCQ@mail.gmail.com>
 <20160122154238.GA53554@darkbeer.org>
Message-ID: <CAHZk5WcTooWHY211ttYi4w5=6rC6ksGPT3Mhi18B1Ae08s__Kw@mail.gmail.com>

On Fri, Jan 22, 2016 at 11:42 PM, Amar Takhar <verm at darkbeer.org> wrote:

> I've tried that in the past the problem is if somehow the archive.org
> content is
> wrong then the user is misdirected.  Keeping the original URL is better
> since
> some users may have known or know where to get a copy of the content if
> anyone
> cares they'll look at the footnote.  I'd rather them have no details vs
> wrong
> ones.
>

Understood.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160123/6b50b175/attachment.html>

From fallenpegasus at gmail.com  Fri Jan 22 18:30:40 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Fri, 22 Jan 2016 18:30:40 +0000
Subject: plan: release 0.9.1 on Monday 2016-01-25
Message-ID: <CANW5CYW-rHxKbfdKXfvRb_XbHWCzxwn8yq5g6Rdp6eRHNnNz_Q@mail.gmail.com>

Hi!

Thank you everyone for this drive to 0.9.1

We should not ship today, as it's a Friday and that's rude to ops people.
So, Monday.

Enjoy your weekend, everyone!

..m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160122/88f2cb79/attachment.html>

From esr at thyrsus.com  Fri Jan 22 18:37:28 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Fri, 22 Jan 2016 13:37:28 -0500
Subject: plan: release 0.9.1 on Monday 2016-01-25
In-Reply-To: <CANW5CYW-rHxKbfdKXfvRb_XbHWCzxwn8yq5g6Rdp6eRHNnNz_Q@mail.gmail.com>
References: <CANW5CYW-rHxKbfdKXfvRb_XbHWCzxwn8yq5g6Rdp6eRHNnNz_Q@mail.gmail.com>
Message-ID: <20160122183728.GA7430@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> We should not ship today, as it's a Friday and that's rude to ops people.
> So, Monday.
> 
> Enjoy your weekend, everyone!

Epic blizzard is set to hit the East Coast tonight, so my 'enjoyment' may
consist largely of shoveling out our driveway.  But I should find time to
merge Sanjeev's doc changes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From dfoxfranke at gmail.com  Fri Jan 22 18:52:07 2016
From: dfoxfranke at gmail.com (Daniel Franke)
Date: Fri, 22 Jan 2016 13:52:07 -0500
Subject: plan: release 0.9.1 on Monday 2016-01-25
In-Reply-To: <20160122183728.GA7430@thyrsus.com>
References: <CANW5CYW-rHxKbfdKXfvRb_XbHWCzxwn8yq5g6Rdp6eRHNnNz_Q@mail.gmail.com>
 <20160122183728.GA7430@thyrsus.com>
Message-ID: <CAJm83bDA9XPk3kCT=_Rcs4iC4=wh88HBbTo3D8N1v_L4cq7-iw@mail.gmail.com>

Current forecast has Boston getting little or no snow from the blizzard,
but I'll be hiking in the mountains. Can't let Eric have *all* the winter
fun.
On Jan 22, 2016 1:37 PM, "Eric S. Raymond" <esr at thyrsus.com> wrote:

> Mark Atwood <fallenpegasus at gmail.com>:
> > We should not ship today, as it's a Friday and that's rude to ops people.
> > So, Monday.
> >
> > Enjoy your weekend, everyone!
>
> Epic blizzard is set to hit the East Coast tonight, so my 'enjoyment' may
> consist largely of shoveling out our driveway.  But I should find time to
> merge Sanjeev's doc changes.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160122/ee346b08/attachment.html>

From hmurray at megapathdsl.net  Fri Jan 22 18:53:09 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 22 Jan 2016 10:53:09 -0800
Subject: Broken links in ntpsec documentation
In-Reply-To: Message from Amar Takhar <verm@darkbeer.org>
 of "Fri, 22 Jan 2016 15:34:37 GMT." <20160122153437.GA50933@darkbeer.org>
Message-ID: <20160122185309.1621F406057@ip-64-139-1-69.sjc.megapath.net>


verm at darkbeer.org said:
> I would leave the original URL but add a footnote with a URL to archive.org.
>   Find a copy there the archive.org URL should be good forever but the
> original  URL should stay to let users know where it came from. 

I would first check to see if the page had moved.

URLs are often links to interesting sites rather than just a single page.  
Following links doesn't work so well at archive.org.



-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Sat Jan 23 19:53:33 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Sat, 23 Jan 2016 14:53:33 -0500
Subject: I have resolved all pending merge requests
Message-ID: <20160123195333.GA2655@thyrsus.com>

I have resolved all pending merge requests.  They were pretty trivial.
All but two were just documentation tweaks.

Hal, if you can port over the Classic fix for the MRU ^C bug that
would be a good thing.  Otherwise I think this is what we should ship
on Monday.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From ghane0 at gmail.com  Sat Jan 23 22:09:57 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 24 Jan 2016 06:09:57 +0800
Subject: I have resolved all pending merge requests
In-Reply-To: <20160123195333.GA2655@thyrsus.com>
References: <20160123195333.GA2655@thyrsus.com>
Message-ID: <CAHZk5WeTsCqScK15FPsBGGPTBZycMcd88rWFBKcuBUuqnyP7Yw@mail.gmail.com>

On Sun, Jan 24, 2016 at 3:53 AM, Eric S. Raymond <esr at thyrsus.com> wrote:

> I have resolved all pending merge requests.  They were pretty trivial.
> All but two were just documentation tweaks.
>
> Hal, if you can port over the Classic fix for the MRU ^C bug that
> would be a good thing.  Otherwise I think this is what we should ship
> on Monday.
>

I have sent in a merge request, and will do some more over the weekend.
All of these are in the docs/ directory, and do not block 0.9.1 at all.

Thank you.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160124/aa3eb299/attachment.html>

From ghane0 at gmail.com  Sun Jan 24 11:40:35 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 24 Jan 2016 19:40:35 +0800
Subject: Buildbot with gcc5
Message-ID: <CAHZk5WfXNtpKq70BpfSpaJzbbd8zfQkcNWZ99b+2cvPDuHHx2g@mail.gmail.com>

Hi,

Looking at: https://buildbot.ntpsec.org/#/builders , I see no slaves with
gcc5.

Amar, I can set some up, if it would help.  debian/testing or
ubuntu/16/04-dev

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160124/611bd2a5/attachment.html>

From verm at darkbeer.org  Sun Jan 24 14:16:07 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Sun, 24 Jan 2016 14:16:07 +0000
Subject: Buildbot with gcc5
In-Reply-To: <CAHZk5WfXNtpKq70BpfSpaJzbbd8zfQkcNWZ99b+2cvPDuHHx2g@mail.gmail.com>
References: <CAHZk5WfXNtpKq70BpfSpaJzbbd8zfQkcNWZ99b+2cvPDuHHx2g@mail.gmail.com>
Message-ID: <20160124141607.GA16295@darkbeer.org>

On 2016-01-24 19:40 +0800, Sanjeev Gupta wrote:
> Hi,
> 
> Looking at: https://buildbot.ntpsec.org/#/builders , I see no slaves with gcc5.
> 
> Amar, I can set some up, if it would help.?? debian/testing or ubuntu/16/04-dev

I can set that up thanks for the suggestion I've added it to the list.  It will 
be up this week. :)

If you have any other ideas / permutations for builds please feel free to 
suggest.


Amar.

From ghane0 at gmail.com  Sun Jan 24 14:21:23 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Sun, 24 Jan 2016 22:21:23 +0800
Subject: Buildbot with gcc5
In-Reply-To: <20160124141607.GA16295@darkbeer.org>
References: <CAHZk5WfXNtpKq70BpfSpaJzbbd8zfQkcNWZ99b+2cvPDuHHx2g@mail.gmail.com>
 <20160124141607.GA16295@darkbeer.org>
Message-ID: <CAHZk5WfK6x9Dr+9NrA9LWTPh3aaEZ=WVPjdDcj3dejSuM16XjA@mail.gmail.com>

On Sun, Jan 24, 2016 at 10:16 PM, Amar Takhar <verm at darkbeer.org> wrote:

> I can set that up thanks for the suggestion I've added it to the list.  It
> will
> be up this week. :)
>

Man, this is the life!  I sit back and suggest, others do all the work.
What's not to like about Open Source?   ;-)

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160124/7691e9f0/attachment.html>

From dtpoirot at gmail.com  Sun Jan 24 15:38:41 2016
From: dtpoirot at gmail.com (Daniel Poirot)
Date: Sun, 24 Jan 2016 09:38:41 -0600
Subject: Buildbot with gcc5
In-Reply-To: <20160124141607.GA16295@darkbeer.org>
References: <CAHZk5WfXNtpKq70BpfSpaJzbbd8zfQkcNWZ99b+2cvPDuHHx2g@mail.gmail.com>
 <20160124141607.GA16295@darkbeer.org>
Message-ID: <4FA2C79D-FD6C-4DDB-912A-77E2C038C537@gmail.com>

Do we have a Linux host with external access yet?

The Coverity Scan service is down right now. 

- Dan


> On Jan 24, 2016, at 8:16 AM, Amar Takhar <verm at darkbeer.org> wrote:
> 
>> On 2016-01-24 19:40 +0800, Sanjeev Gupta wrote:
>> Hi,
>> 
>> Looking at: https://buildbot.ntpsec.org/#/builders , I see no slaves with gcc5.
>> 
>> Amar, I can set some up, if it would help.  debian/testing or ubuntu/16/04-dev
> 
> I can set that up thanks for the suggestion I've added it to the list.  It will 
> be up this week. :)
> 
> If you have any other ideas / permutations for builds please feel free to 
> suggest.
> 
> 
> Amar.
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel

From verm at darkbeer.org  Sun Jan 24 15:40:17 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Sun, 24 Jan 2016 15:40:17 +0000
Subject: Buildbot with gcc5
In-Reply-To: <4FA2C79D-FD6C-4DDB-912A-77E2C038C537@gmail.com>
References: <CAHZk5WfXNtpKq70BpfSpaJzbbd8zfQkcNWZ99b+2cvPDuHHx2g@mail.gmail.com>
 <20160124141607.GA16295@darkbeer.org>
 <4FA2C79D-FD6C-4DDB-912A-77E2C038C537@gmail.com>
Message-ID: <20160124154017.GA17510@darkbeer.org>

On 2016-01-24 09:38 -0600, Daniel Poirot wrote:
> Do we have a Linux host with external access yet?
> 
> The Coverity Scan service is down right now. 

I can work on that I have added it to the list I will let you know after I 
finish migrating Buildbot.


Amar.

From ghane0 at gmail.com  Sun Jan 24 17:18:06 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Mon, 25 Jan 2016 01:18:06 +0800
Subject: Broken links in ntpsec documentation
In-Reply-To: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
References: <CAHZk5WdWknW3HjvGkAoRezp74XAXgYYtnjNSNvm2FxA=ouE2EA@mail.gmail.com>
Message-ID: <CAHZk5Wf33UOc31=LJKwaW_dVU210n2zGO1jjikEKvXBHM8k0zA@mail.gmail.com>

On Fri, Jan 22, 2016 at 11:32 PM, Sanjeev Gupta <ghane0 at gmail.com> wrote:

>
> For the broken URLs, should one:
>
>    1. Leave as is; bitrot will always occur, and much of the
>    documentation has historical value as a record
>    2. Try and locate a new copy; failing which elide the text
>
>
For all but two links, it was possible to find the page again on the same
(or similar) website; the paths had changed.

For one (clock.co.jp), the domain expired last year.  The only hits to the
domain are in NTP documentation copies online.

For another (Rockwell), alternative copies of the manual have been found
and linked.

This completes (merge request sent) this issue.  All links work.


-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160125/61d30cd4/attachment.html>

From hmurray at megapathdsl.net  Sun Jan 24 20:40:32 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 24 Jan 2016 12:40:32 -0800
Subject: Buildbot with gcc5
In-Reply-To: Message from Amar Takhar <verm@darkbeer.org>
 of "Sun, 24 Jan 2016 14:16:07 GMT." <20160124141607.GA16295@darkbeer.org>
Message-ID: <20160124204032.CAB94406057@ip-64-139-1-69.sjc.megapath.net>


verm at darkbeer.org said:
> If you have any other ideas / permutations for builds please feel free to
> suggest. 

Many OSes/Distros have 2 supported versions.  For Intel, they come in both 32 
and 64 bit versions.

I'm assuming the above systems would have all packages interesting to ntpsec 
installed.  It would also help to build on a system with minimal installed 
packages, just enough to build a useful version of ntpd.  We would need to 
document what packages were installed.


I think we should also include some ARM systems.  The main distro for the 
Raspberry PI is Raspbian, derived from Debian.  Pi-s come in two CPU 
versions.  The old/slow ones take 6-9 minutes for a build (no doc, no check) 
and another 1-2 minutes for check.  The new CPU takes 2.5 minutes to build 
and under 1 to check.

I think NetBSD and FreeBSD both run on the Raspberry Pi, but I haven't found 
a good install  HOWTO for either.

We also need to actually run the code.  I don't know how to monitor for 
obscure quirks but we should be able to setup something for a sanity check.

We also need a way to test refclocks.  I'd be happy if we could run one of 
each major type on any OS.


Where are OS-x and RTEMS on the radar?

A wrong endian system would be high on my list.  That requires actually 
running the code.



-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Sun Jan 24 21:07:01 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Sun, 24 Jan 2016 13:07:01 -0800
Subject: I have resolved all pending merge requests
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Sat, 23 Jan 2016 14:53:33 EST." <20160123195333.GA2655@thyrsus.com>
Message-ID: <20160124210701.C2A75406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> Hal, if you can port over the Classic fix for the MRU ^C bug that would be a
> good thing.

I took a look.  It's not simple.  There have been lots of changes to ntpq.  
Taking everything risks dropping some of our fixes and/or picking up some of 
their new bugs.

I think I'll see if I can work out a simple fix.




-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Mon Jan 25 10:27:20 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 25 Jan 2016 05:27:20 -0500
Subject: Coverity upped its game again
Message-ID: <20160125102720.GA28332@thyrsus.com>

An encouraging news bulletin because things have been a bit slow over the
holidays:

I'm now able to do Coverity scanning again after a hiatus of about three
weeks due to my cov-build tools going stale when I ubgraded to Ubuntu 15.

Coverity has improved its scan quality while I wasn't looking.
I found a resource leak in async DNS this morning and plugged it.
There was also a bad shift operation in one of the clock drivers
that had not been caught before and was easy to fix.

These are nice things to have land just before 0.9.1.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From fallenpegasus at gmail.com  Mon Jan 25 18:49:14 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Mon, 25 Jan 2016 18:49:14 +0000
Subject: Coverity upped its game again
In-Reply-To: <20160125102720.GA28332@thyrsus.com>
References: <20160125102720.GA28332@thyrsus.com>
Message-ID: <CANW5CYXKg7TJyebZ5mJ2=ZOv6Ce2JLbFO8B4d5gQDP5evZG0+g@mail.gmail.com>

awesome!

On Mon, Jan 25, 2016 at 2:27 AM Eric S. Raymond <esr at thyrsus.com> wrote:

> An encouraging news bulletin because things have been a bit slow over the
> holidays:
>
> I'm now able to do Coverity scanning again after a hiatus of about three
> weeks due to my cov-build tools going stale when I ubgraded to Ubuntu 15.
>
> Coverity has improved its scan quality while I wasn't looking.
> I found a resource leak in async DNS this morning and plugged it.
> There was also a bad shift operation in one of the clock drivers
> that had not been caught before and was easy to fix.
>
> These are nice things to have land just before 0.9.1.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160125/f7546dbf/attachment.html>

From fallenpegasus at gmail.com  Mon Jan 25 19:39:31 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Mon, 25 Jan 2016 19:39:31 +0000
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
Message-ID: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>

Hi!

If the buildbot status makes me happy, and nobody chimes in with a blocker,
I will tag and release ntpsec 0.9.1 at about 7pm PST this evening 2016-01-25

Thank you, everyone.

..m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160125/11041c9a/attachment.html>

From esr at thyrsus.com  Mon Jan 25 20:45:10 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 25 Jan 2016 15:45:10 -0500
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>
References: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>
Message-ID: <20160125204510.GB32454@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> Hi!
> 
> If the buildbot status makes me happy, and nobody chimes in with a blocker,
> I will tag and release ntpsec 0.9.1 at about 7pm PST this evening 2016-01-25
> 
> Thank you, everyone.
> 
> ..m

No blockers here.

Sure would have been nice if we could have crossported Classic's fix for the ^C
bug in ntpq, though.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Tue Jan 26 01:16:48 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Mon, 25 Jan 2016 17:16:48 -0800
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Mon, 25 Jan 2016 15:45:10 EST." <20160125204510.GB32454@thyrsus.com>
Message-ID: <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> Sure would have been nice if we could have crossported Classic's fix for the
> ^C bug in ntpq, though. 

That particular bug isn't a big deal or somebody would have worked on it 
sooner.

The real question is are we going to track fixes from NTP Classic and if so 
who, how, when, etc?  There were a lot of patches released in the past few 
days.  I haven't scanned them. I don't think anybody has reviewed all the 
changes since the fork.


I looked into the ^C tangle.  I'm trying to do it from scratch rather than 
blindly copy the new code.  Maybe I'll learn enough to understand why the new 
code seems so complicated.

It should be simple.  The general idea is that the code that calls the 
command dispatcher does a setjmp and sets a flag for the ^C signal handler.  
If the flag is on, the signal handler does a longjmp to bail from the command.

I put a printf in the top of the signal handler.  The problem I'm seeing is 
that the ^C handler goes away after the first jump.  If it doesn't jump, it 
keeps on working.

An additional complication is that readline sets a bunch of signal handlers.  
I haven't investigated.  Since it isn't mentioned in the man page, I assume 
it puts things back the way they were and/or calls the old signal handler.

I tried blindly setting the signal handler again but that didn't fix it.  
That's as far as I got before it was time for sleep.  Maybe it's masked?

I've spent some time googling but haven't found anything interesting yet.  
Are there any obvious gotchas associated with signals and longjmp that I 
should know about?

I'm working on Linux/Fedora.



-- 
These are my opinions.  I hate spam.




From dfoxfranke at gmail.com  Tue Jan 26 01:35:52 2016
From: dfoxfranke at gmail.com (Daniel Franke)
Date: Mon, 25 Jan 2016 20:35:52 -0500
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>
References: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>
Message-ID: <CAJm83bCRfT6TfETQLAVbupp4R_HzCeg364=hetjyFq2TyXdK-g@mail.gmail.com>

Remember to update the VERSION file and the release date in the NEWS file.
On Jan 25, 2016 2:39 PM, "Mark Atwood" <fallenpegasus at gmail.com> wrote:

> Hi!
>
> If the buildbot status makes me happy, and nobody chimes in with a
> blocker, I will tag and release ntpsec 0.9.1 at about 7pm PST this evening
> 2016-01-25
>
> Thank you, everyone.
>
> ..m
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160125/3905bf4e/attachment.html>

From fallenpegasus at gmail.com  Tue Jan 26 02:13:37 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 02:13:37 +0000
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>
References: <CANW5CYXmFSg2610dkh47GVWgArHnp2fGisSXaFdYuFx=h4LS1Q@mail.gmail.com>
Message-ID: <CANW5CYWxMgQxBwn68oOh3XKatmRdF=h9dr-etC-DG86vorKCuQ@mail.gmail.com>

On Mon, Jan 25, 2016 at 11:39 AM Mark Atwood <fallenpegasus at gmail.com>
wrote:

> If the buildbot status makes me happy, and nobody chimes in with a
> blocker, I will tag and release ntpsec 0.9.1 at about 7pm PST this evening
> 2016-01-25
>
>
Hi!

I'm happy with buildbot, I created a clean VM and cloned and built in it,
I've updated NEWS and VERSION, I just created a signed tag NTPsec_0_9_1.
I'm about to push.

..m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/d0088020/attachment.html>

From esr at thyrsus.com  Tue Jan 26 02:37:09 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 25 Jan 2016 21:37:09 -0500
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160125204510.GB32454@thyrsus.com>
 <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160126023709.GA1766@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> The real question is are we going to track fixes from NTP Classic and if so 
> who, how, when, etc?  There were a lot of patches released in the past few 
> days.  I haven't scanned them. I don't think anybody has reviewed all the 
> changes since the fork.

Uh oh.  We've had a moderately serious coordination failure here.  Fortunately
it should be recoverable without a huge amound of work.

Just before 0.9.0 I reviewed all Classic changes from the fork to
September 29th and forward-ported everything relevant up to their fix
for bug 2902 on 29 September.  The only thing I skipped that I regret a
little is pearly's cleanup of the calendar code - I have a bit set to
look back at that if we don't recruit him first.

So the good news is we're caught up to well past the fork.

After I did the catchup to late September I thought *you* had accepted
the job of tracking Classic's fixes while I concentrated on
capture/replay.  That was in the proposed work plan I published just
after 0.9.0, which Mark approved.  I thought you were obviously the best
positioned for this, since you track ntp-hackers and occasionally
contribute fixes there.

As for where we are now, we elected not to port the Classic fix for
2332 because we're planning to plain rewrite the async stuff.
Excluding the CVEs we already have fixes for, I don't actually see a
lot of bugfixes affter Sep 29 that need porting.  I'm looking at the
Classic history now and I see these: 2845 2882 2772 2948 2939 2935
2937 2814 2829 2887 2958 2962.

The better news is that most of these look like pretty trivial
patches; I'd be surprised if it takes more than a day and a half to
cross-port them all.  If I'd known we'd had a disconnect and you
weren't working on this I'd have knocked off a few to relax from the
heavy stuff.

> I looked into the ^C tangle.  I'm trying to do it from scratch rather than 
> blindly copy the new code.  Maybe I'll learn enough to understand why the new 
> code seems so complicated.
> 
> It should be simple.  The general idea is that the code that calls the 
> command dispatcher does a setjmp and sets a flag for the ^C signal handler.  
> If the flag is on, the signal handler does a longjmp to bail from the command.
> 
> I put a printf in the top of the signal handler.  The problem I'm seeing is 
> that the ^C handler goes away after the first jump.  If it doesn't jump, it 
> keeps on working.

Yeah, that looks like you're getting old-style resetting behavior when the
handler is called.  See below...

> 
> An additional complication is that readline sets a bunch of signal handlers.  
> I haven't investigated.  Since it isn't mentioned in the man page, I assume 
> it puts things back the way they were and/or calls the old signal handler.
> 
> I tried blindly setting the signal handler again but that didn't fix it.  
> That's as far as I got before it was time for sleep.  Maybe it's masked?
> 
> I've spent some time googling but haven't found anything interesting yet.  
> Are there any obvious gotchas associated with signals and longjmp that I 
> should know about?

Heh.  Looks like you tripped over them already. This sort of thing is
par for the course when you mess with signal handlers.  They're spooky
action at a distance and the side effects are hard to track.

General advice: Be sure you're using sigaction(2) rather than signal(2), the
older API may not preserve your signal bindings when a handler is fired. Make
sure the handler flags do *not* include SA_RESETHAND.

Be sure you signal-latch flag is declared volatile; compiler optimizations
can fuck you up otherwise.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From fallenpegasus at gmail.com  Tue Jan 26 02:40:06 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 02:40:06 +0000
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <20160126023709.GA1766@thyrsus.com>
References: <esr@thyrsus.com> <20160125204510.GB32454@thyrsus.com>
 <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160126023709.GA1766@thyrsus.com>
Message-ID: <CANW5CYXZ23PecU5cq2STkhvOcbVBwZvmbJHcbdcCr+p=tg6HLA@mail.gmail.com>

No worries.  Fix 2845 2882 2772 2948 2939 2935 2937 2814 2829 2887 2958
2962, and we will call that 0.9.2

Thanks!

..m

On Mon, Jan 25, 2016 at 6:37 PM Eric S. Raymond <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > The real question is are we going to track fixes from NTP Classic and if
> so
> > who, how, when, etc?  There were a lot of patches released in the past
> few
> > days.  I haven't scanned them. I don't think anybody has reviewed all the
> > changes since the fork.
>
> Uh oh.  We've had a moderately serious coordination failure here.
> Fortunately
> it should be recoverable without a huge amound of work.
>
> Just before 0.9.0 I reviewed all Classic changes from the fork to
> September 29th and forward-ported everything relevant up to their fix
> for bug 2902 on 29 September.  The only thing I skipped that I regret a
> little is pearly's cleanup of the calendar code - I have a bit set to
> look back at that if we don't recruit him first.
>
> So the good news is we're caught up to well past the fork.
>
> After I did the catchup to late September I thought *you* had accepted
> the job of tracking Classic's fixes while I concentrated on
> capture/replay.  That was in the proposed work plan I published just
> after 0.9.0, which Mark approved.  I thought you were obviously the best
> positioned for this, since you track ntp-hackers and occasionally
> contribute fixes there.
>
> As for where we are now, we elected not to port the Classic fix for
> 2332 because we're planning to plain rewrite the async stuff.
> Excluding the CVEs we already have fixes for, I don't actually see a
> lot of bugfixes affter Sep 29 that need porting.  I'm looking at the
> Classic history now and I see these: 2845 2882 2772 2948 2939 2935
> 2937 2814 2829 2887 2958 2962.
>
> The better news is that most of these look like pretty trivial
> patches; I'd be surprised if it takes more than a day and a half to
> cross-port them all.  If I'd known we'd had a disconnect and you
> weren't working on this I'd have knocked off a few to relax from the
> heavy stuff.
>
> > I looked into the ^C tangle.  I'm trying to do it from scratch rather
> than
> > blindly copy the new code.  Maybe I'll learn enough to understand why
> the new
> > code seems so complicated.
> >
> > It should be simple.  The general idea is that the code that calls the
> > command dispatcher does a setjmp and sets a flag for the ^C signal
> handler.
> > If the flag is on, the signal handler does a longjmp to bail from the
> command.
> >
> > I put a printf in the top of the signal handler.  The problem I'm seeing
> is
> > that the ^C handler goes away after the first jump.  If it doesn't jump,
> it
> > keeps on working.
>
> Yeah, that looks like you're getting old-style resetting behavior when the
> handler is called.  See below...
>
> >
> > An additional complication is that readline sets a bunch of signal
> handlers.
> > I haven't investigated.  Since it isn't mentioned in the man page, I
> assume
> > it puts things back the way they were and/or calls the old signal
> handler.
> >
> > I tried blindly setting the signal handler again but that didn't fix it.
> > That's as far as I got before it was time for sleep.  Maybe it's masked?
> >
> > I've spent some time googling but haven't found anything interesting yet.
> > Are there any obvious gotchas associated with signals and longjmp that I
> > should know about?
>
> Heh.  Looks like you tripped over them already. This sort of thing is
> par for the course when you mess with signal handlers.  They're spooky
> action at a distance and the side effects are hard to track.
>
> General advice: Be sure you're using sigaction(2) rather than signal(2),
> the
> older API may not preserve your signal bindings when a handler is fired.
> Make
> sure the handler flags do *not* include SA_RESETHAND.
>
> Be sure you signal-latch flag is declared volatile; compiler optimizations
> can fuck you up otherwise.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/d0e1c727/attachment.html>

From esr at thyrsus.com  Tue Jan 26 02:50:59 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 25 Jan 2016 21:50:59 -0500
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <CANW5CYXZ23PecU5cq2STkhvOcbVBwZvmbJHcbdcCr+p=tg6HLA@mail.gmail.com>
References: <esr@thyrsus.com> <20160125204510.GB32454@thyrsus.com>
 <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160126023709.GA1766@thyrsus.com>
 <CANW5CYXZ23PecU5cq2STkhvOcbVBwZvmbJHcbdcCr+p=tg6HLA@mail.gmail.com>
Message-ID: <20160126025059.GA3501@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> No worries.  Fix 2845 2882 2772 2948 2939 2935 2937 2814 2829 2887 2958
> 2962, and we will call that 0.9.2

Um...which one of us?  Or do you want us both to tackle them?

Fortunately none of those are very serious.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From fallenpegasus at gmail.com  Tue Jan 26 02:52:31 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 02:52:31 +0000
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <20160126025059.GA3501@thyrsus.com>
References: <esr@thyrsus.com> <20160125204510.GB32454@thyrsus.com>
 <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160126023709.GA1766@thyrsus.com>
 <CANW5CYXZ23PecU5cq2STkhvOcbVBwZvmbJHcbdcCr+p=tg6HLA@mail.gmail.com>
 <20160126025059.GA3501@thyrsus.com>
Message-ID: <CANW5CYVghVgwK9kG2hxhCecfk=kV8cjoHzXpw+TnprZrsgaafA@mail.gmail.com>

I leave it to each of your judgement and coordination, Eric and Hal.  I am
not technically qualified to assign them.  :)

On Mon, Jan 25, 2016 at 6:51 PM Eric S. Raymond <esr at thyrsus.com> wrote:

> Mark Atwood <fallenpegasus at gmail.com>:
> > No worries.  Fix 2845 2882 2772 2948 2939 2935 2937 2814 2829 2887 2958
> > 2962, and we will call that 0.9.2
>
> Um...which one of us?  Or do you want us both to tackle them?
>
> Fortunately none of those are very serious.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/97c19b7c/attachment.html>

From esr at thyrsus.com  Tue Jan 26 03:26:57 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Mon, 25 Jan 2016 22:26:57 -0500
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <CANW5CYVghVgwK9kG2hxhCecfk=kV8cjoHzXpw+TnprZrsgaafA@mail.gmail.com>
References: <esr@thyrsus.com> <20160125204510.GB32454@thyrsus.com>
 <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160126023709.GA1766@thyrsus.com>
 <CANW5CYXZ23PecU5cq2STkhvOcbVBwZvmbJHcbdcCr+p=tg6HLA@mail.gmail.com>
 <20160126025059.GA3501@thyrsus.com>
 <CANW5CYVghVgwK9kG2hxhCecfk=kV8cjoHzXpw+TnprZrsgaafA@mail.gmail.com>
Message-ID: <20160126032657.GA3642@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> I leave it to each of your judgement and coordination, Eric and Hal.  I am
> not technically qualified to assign them.  :)

OK, I'll take that as "both", then.  Hal, would you look over the
Classic fixes for the stuff on the list (2845 2882 2772 2948 2939 2935
2937 2814 2829 2887 2958 2962) and pick five or six you think
you can do easily?  Then I'll triage the rest and post a non-overlapping
list.  Any hard ones we can defer to a second pass

(Now I'm trying to think forward to expanding our developer pool.)

Mark, if we've got any n00bs you want to start training, I think
almost all of these fix transplants are in the not-hard category.  The
main difference is that a n00b would do this sort of thing more slowly
and with effort, as opposed to blowing through it as rapidly as Hal or
myself.  But since none of these are super-urgent and they're
bite-sized tasks, that's an opportunity.

Susan, do you have any New Guard people you think might be ready to write
C systems code in ... hm, not the deep end, but not the kiddie pool either. :-)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From fallenpegasus at gmail.com  Tue Jan 26 04:02:33 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 04:02:33 +0000
Subject: planning ntpsec 0.9.1 release at about 7pm PST tonight
In-Reply-To: <20160126032657.GA3642@thyrsus.com>
References: <esr@thyrsus.com> <20160125204510.GB32454@thyrsus.com>
 <20160126011648.5BC9B406057@ip-64-139-1-69.sjc.megapath.net>
 <20160126023709.GA1766@thyrsus.com>
 <CANW5CYXZ23PecU5cq2STkhvOcbVBwZvmbJHcbdcCr+p=tg6HLA@mail.gmail.com>
 <20160126025059.GA3501@thyrsus.com>
 <CANW5CYVghVgwK9kG2hxhCecfk=kV8cjoHzXpw+TnprZrsgaafA@mail.gmail.com>
 <20160126032657.GA3642@thyrsus.com>
Message-ID: <CANW5CYVLvA5pnadKF5X5sdxjFPFwf9CtkLX7v+oQABL6V8rcbA@mail.gmail.com>

Would it make sense to add a "low hanging fruilt" section to dev/TODO and
put these in it

or else put each of these in https://gitlab.com/NTPsec/ntpsec/issues with
an issue weight of "2", designating 2 as "low hanging fruit".

..m

On Mon, Jan 25, 2016 at 7:27 PM Eric S. Raymond <esr at thyrsus.com> wrote:

> Mark Atwood <fallenpegasus at gmail.com>:
> > I leave it to each of your judgement and coordination, Eric and Hal.  I
> am
> > not technically qualified to assign them.  :)
>
> OK, I'll take that as "both", then.  Hal, would you look over the
> Classic fixes for the stuff on the list (2845 2882 2772 2948 2939 2935
> 2937 2814 2829 2887 2958 2962) and pick five or six you think
> you can do easily?  Then I'll triage the rest and post a non-overlapping
> list.  Any hard ones we can defer to a second pass
>
> (Now I'm trying to think forward to expanding our developer pool.)
>
> Mark, if we've got any n00bs you want to start training, I think
> almost all of these fix transplants are in the not-hard category.  The
> main difference is that a n00b would do this sort of thing more slowly
> and with effort, as opposed to blowing through it as rapidly as Hal or
> myself.  But since none of these are super-urgent and they're
> bite-sized tasks, that's an opportunity.
>
> Susan, do you have any New Guard people you think might be ready to write
> C systems code in ... hm, not the deep end, but not the kiddie pool
> either. :-)
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/c9800204/attachment.html>

From ghane0 at gmail.com  Tue Jan 26 15:21:26 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Tue, 26 Jan 2016 23:21:26 +0800
Subject: POOL keyword in ntp.conf non resolving
Message-ID: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>

Hi,

Sometime between 21 Jan and today, the following line in my ntp.conf
pool hk.pool.ntp.org iburst


results in (ntpd.log)
01-26T23:14:40 ntpd[28107]: error resolving pool hk.pool.ntp.org: No
address associated with hostname (-5)

and (ntpq -pn)
root at ntpmon:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
-127.127.28.0    .GPS.            0 l   49   64  377    0.000  -19.426
15.467
*127.127.28.1    .PPS.            0 l   48   64  377    0.000   -0.003
0.001
 hk.pool.ntp.org .POOL.          16 p    -   64    0    0.000    0.000
0.000


-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/555d2e23/attachment.html>

From esr at thyrsus.com  Tue Jan 26 15:41:04 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 10:41:04 -0500
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
Message-ID: <20160126154104.GA14055@thyrsus.com>

Sanjeev Gupta <ghane0 at gmail.com>:
> Sometime between 21 Jan and today, the following line in my ntp.conf
> pool hk.pool.ntp.org iburst

OK, here's where you gain a level in hackery. :-)

Learn how to perform a git bisection (using Google to find a HOWTO) and
nail down which commit broke the lookup.  Konowing that, it should be
easy to fix.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From fallenpegasus at gmail.com  Tue Jan 26 15:59:40 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 15:59:40 +0000
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <20160126154104.GA14055@thyrsus.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
Message-ID: <CANW5CYV3WajwFrO9DNQ4k0nV4ZEjFDBPHYoy+VaJFUKZ-+Y3-w@mail.gmail.com>

Let me just chime in with...  bisect is awesome.

When I first did a bzr bisect about 8 years ago, I was delighted and
peeved.  Delighted because it's just so damn elegant, and peeved because
it's something that could have been tooled for 15 years sooner, but
generally wasn't.

On Tue, Jan 26, 2016 at 7:41 AM Eric S. Raymond <esr at thyrsus.com> wrote:

> Sanjeev Gupta <ghane0 at gmail.com>:
> > Sometime between 21 Jan and today, the following line in my ntp.conf
> > pool hk.pool.ntp.org iburst
>
> OK, here's where you gain a level in hackery. :-)
>
> Learn how to perform a git bisection (using Google to find a HOWTO) and
> nail down which commit broke the lookup.  Konowing that, it should be
> easy to fix.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/287760de/attachment.html>

From ghane0 at gmail.com  Tue Jan 26 16:10:52 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 27 Jan 2016 00:10:52 +0800
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <20160126154104.GA14055@thyrsus.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
Message-ID: <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>

On Tue, Jan 26, 2016 at 11:41 PM, Eric S. Raymond <esr at thyrsus.com> wrote:

> OK, here's where you gain a level in hackery. :-)
>
> Learn how to perform a git bisection (using Google to find a HOWTO) and
> nail down which commit broke the lookup.  Konowing that, it should be
> easy to fix.
>

Eric, I thought the whole point of my using Open Source was that I
complain, and you et al fix?  :-)

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160127/9c20c4b0/attachment.html>

From fallenpegasus at gmail.com  Tue Jan 26 16:16:52 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 16:16:52 +0000
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
Message-ID: <CANW5CYVZDScnQk1BEH1gjq+JVmiPyz+jUeo-hPC+0BcKZ1nu6g@mail.gmail.com>

> I thought the whole point of my using Open Source was that I complain,
and you et al fix?  :-)

It is!  However, you are one of the "et al".   ;)

..m

On Tue, Jan 26, 2016 at 8:11 AM Sanjeev Gupta <ghane0 at gmail.com> wrote:

>
> On Tue, Jan 26, 2016 at 11:41 PM, Eric S. Raymond <esr at thyrsus.com> wrote:
>
>> OK, here's where you gain a level in hackery. :-)
>>
>> Learn how to perform a git bisection (using Google to find a HOWTO) and
>> nail down which commit broke the lookup.  Konowing that, it should be
>> easy to fix.
>>
>
> Eric, I thought the whole point of my using Open Source was that I
> complain, and you et al fix?  :-)
>
>
> --
> Sanjeev Gupta
> +65 98551208     http://www.linkedin.com/in/ghane
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/ca69a723/attachment.html>

From dtpoirot at gmail.com  Tue Jan 26 16:32:33 2016
From: dtpoirot at gmail.com (Daniel Poirot)
Date: Tue, 26 Jan 2016 10:32:33 -0600
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CANW5CYVZDScnQk1BEH1gjq+JVmiPyz+jUeo-hPC+0BcKZ1nu6g@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
 <CANW5CYVZDScnQk1BEH1gjq+JVmiPyz+jUeo-hPC+0BcKZ1nu6g@mail.gmail.com>
Message-ID: <407B3A37-2846-4A5C-B222-CF111C39A13E@gmail.com>

No, no, no...

It's "Given enough eyeballs, all bugs are shallow"[1]...

That is why Open Source is so good! No bugs!

...wait, why are there over 6600 FOSS projects on SCAN...


Uh, never mind...

1) ^ http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html


> On Jan 26, 2016, at 10:16 AM, Mark Atwood <fallenpegasus at gmail.com> wrote:
> 
> > I thought the whole point of my using Open Source was that I complain, and you et al fix?  :-)
> 
> It is!  However, you are one of the "et al".   ;)
> 
> ..m
> 
>> On Tue, Jan 26, 2016 at 8:11 AM Sanjeev Gupta <ghane0 at gmail.com> wrote:
>> 
>>> On Tue, Jan 26, 2016 at 11:41 PM, Eric S. Raymond <esr at thyrsus.com> wrote:
>>> OK, here's where you gain a level in hackery. :-)
>>> 
>>> Learn how to perform a git bisection (using Google to find a HOWTO) and
>>> nail down which commit broke the lookup.  Konowing that, it should be
>>> easy to fix.
>> 
>> Eric, I thought the whole point of my using Open Source was that I complain, and you et al fix?  :-)
>> 
>> 
>> -- 
>> Sanjeev Gupta
>> +65 98551208     http://www.linkedin.com/in/ghane
>> _______________________________________________
>> devel mailing list
>> devel at ntpsec.org
>> http://lists.ntpsec.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/28ab26b6/attachment.html>

From ghane0 at gmail.com  Tue Jan 26 16:38:22 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 27 Jan 2016 00:38:22 +0800
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CANW5CYVZDScnQk1BEH1gjq+JVmiPyz+jUeo-hPC+0BcKZ1nu6g@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
 <CANW5CYVZDScnQk1BEH1gjq+JVmiPyz+jUeo-hPC+0BcKZ1nu6g@mail.gmail.com>
Message-ID: <CAHZk5Wf0t9nD3+jL8wa1BA66Fw9i7JPyGueYX7G82T3kNZLiGA@mail.gmail.com>

On Wed, Jan 27, 2016 at 12:16 AM, Mark Atwood <fallenpegasus at gmail.com>
wrote:

> > I thought the whole point of my using Open Source was that I complain,
> and you et al fix?  :-)
>
> It is!  However, you are one of the "et al".   ;)
>

Drat!  Foiled again.

Please see the two traces below:
>From ntpsec 0.9.1 (HEAD)

01-27T00:24:07 ntpd[10200]: Soliciting pool server 119.9.78.248
01-27T00:24:12 ntpd[10200]: Soliciting pool server 103.224.117.98
01-27T00:25:14 ntpd[10200]: Soliciting pool server 218.189.210.4
01-27T00:25:17 ntpd[10200]: Soliciting pool server 210.23.18.197
01-27T00:26:21 ntpd[10200]: Soliciting pool server 58.146.176.233
01-27T00:26:21 ntpd[10200]: Soliciting pool server 59.149.185.193
01-27T00:27:25 ntpd[10200]: Soliciting pool server 128.199.84.169
01-27T00:27:28 ntpd[10200]: Soliciting pool server 218.189.210.4
01-27T00:28:33 ntpd[10200]: Soliciting pool server 210.23.18.197
01-27T00:28:35 ntpd[10200]: Soliciting pool server 59.149.185.193
01-27T00:29:39 ntpd[10200]: Soliciting pool server 128.199.84.169
01-27T00:29:42 ntpd[10200]: Soliciting pool server 119.9.78.248
01-27T00:30:43 ntpd[10200]: Soliciting pool server 58.146.176.233
01-27T00:30:49 ntpd[10200]: Soliciting pool server 218.189.210.3
01-27T00:31:48 ntpd[10200]: Soliciting pool server 210.23.18.197
01-27T00:31:55 ntpd[10200]: Soliciting pool server 119.9.78.248

>From ntp 4.2.6p5 (ubuntu 16.04-dev)
27 Jan 00:28:16 ntpd[29007]: 192.168.1.1 8024 84 reachable
27 Jan 00:28:17 ntpd[29007]: 128.199.134.40 8024 84 reachable
27 Jan 00:28:18 ntpd[29007]: 202.156.0.34 8024 84 reachable
27 Jan 00:28:19 ntpd[29007]: 128.199.87.155 8024 84 reachable
27 Jan 00:28:20 ntpd[29007]: 218.189.210.3 8024 84 reachable
27 Jan 00:28:21 ntpd[29007]: 218.189.210.4 8024 84 reachable
27 Jan 00:28:22 ntpd[29007]: 192.168.1.1 903a 8a sys_peer
27 Jan 00:28:22 ntpd[29007]: 0.0.0.0 c615 05 clock_sync
27 Jan 00:28:23 ntpd[29007]: 119.9.78.248 8024 84 reachable
27 Jan 00:29:25 ntpd[29007]: 202.156.0.34 903a 8a sys_peer

I am going to install ntp Classic on the same server and check.

-- Call me Al, Betty.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160127/5b089da5/attachment.html>

From esr at thyrsus.com  Tue Jan 26 17:00:02 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 12:00:02 -0500
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CANW5CYV3WajwFrO9DNQ4k0nV4ZEjFDBPHYoy+VaJFUKZ-+Y3-w@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CANW5CYV3WajwFrO9DNQ4k0nV4ZEjFDBPHYoy+VaJFUKZ-+Y3-w@mail.gmail.com>
Message-ID: <20160126170002.GA14558@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> Let me just chime in with...  bisect is awesome.
> 
> When I first did a bzr bisect about 8 years ago, I was delighted and
> peeved.  Delighted because it's just so damn elegant, and peeved because
> it's something that could have been tooled for 15 years sooner, but
> generally wasn't.

I've actually considered this carefully, because...well, see below.

On the one hand, yes, one does wonder why it wasn't thought of sooner.

On the other hand, older VCSes were either (a) horribly slow, or (b)
didn't have unitary changesets, or (c) both.  There's a kind of
Sapir-Whorf-like effect by which the limits of your tools become the
limits of your thought. It would have been hard to imagine bisection
in the presence of those limits.

*I* didn't, and this is a specific technical area where I have a long
history of thinking outside the current box, bracketed by inventing
Emacs VC mode in 1992, the DRCS proposal in 1997, reposurgeon in 2010,
and src in 2014.

In fact, with DRCS I came *this close* to inventing the DVCS in 1997 -
I had the basic idea of building a distributed store around a
repository sync operation three years before arc and seven years
before git.  Probably would have gone the rest of the way if I hadn't
gotten distracted by having to be Mr. Famous Guy for five years.

Once you have DVCS, bisection falls out as a natural consequence because
changeset checkouts are fast.  I really don't think you can avoid having
the possibility slap you in the face if you have any design sense at all.
In particular, I don't think *I'm* dense enough to miss it.

So, in a sense, bisection is a discovery I should have made.  That's
why I've spent some effort on the question of why nobody got to it
a decade sooner than the bzr guys.  And I think it's just that
slow checkout speeds blocked our view.

The biggest failure of imagination in my career was that I didn't see
that a full open-source Unix was practical after the 386 reached
volume ship in 1989. If I'd had a clue then I would probably have
launched something like Linux myself, if my nerve didn't fail.  But...I
might not have had the capability to follow through.  Hard to know.

My *second* biggest failure of imagination was not grokking just how
important version control was, even though I was a very early adopter
of RCS/SCCS. If I had known to concentrate on that problem ... well,
in the history we have, I anticipated the DVCS.  I think it's quite
possible I would have short-circuited fifteen years of wrong turns in
VCS design before 1990.  Difference is, that wouldn't have taken any
nerve at all.  Following through on the key insights, had I got to them,
would have been easy stuff, comparatively - well within my capability
and our tools at the time.

Can't win 'em all, I guess.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From esr at thyrsus.com  Tue Jan 26 17:11:06 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 12:11:06 -0500
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
Message-ID: <20160126171106.GB14558@thyrsus.com>

Sanjeev Gupta <ghane0 at gmail.com>:
> On Tue, Jan 26, 2016 at 11:41 PM, Eric S. Raymond <esr at thyrsus.com> wrote:
> 
> > OK, here's where you gain a level in hackery. :-)
> >
> > Learn how to perform a git bisection (using Google to find a HOWTO) and
> > nail down which commit broke the lookup.  Konowing that, it should be
> > easy to fix.
> >
> 
> Eric, I thought the whole point of my using Open Source was that I
> complain, and you et al fix?  :-)

Well, yes, often.  But...and I'm being serious now...it's good form to
send a request for bisection back to the bug reporter when you suspect
that the bug might be sensitive to environmental factors that are
tricky to identify and replicate.  That way you avoid getting ratholed
by an inability to reproduce the bug locally.

(And you *always* suspect tricky environmental factors when DNS lookups
are involved.  That is, if you weren't born yesterday.)

Besides, I didn't think you'd *mind* an easy level gain in hackery. :-)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From ghane0 at gmail.com  Tue Jan 26 18:18:52 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 27 Jan 2016 02:18:52 +0800
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <20160126171106.GB14558@thyrsus.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
 <20160126171106.GB14558@thyrsus.com>
Message-ID: <CAHZk5Wf_S6WhNVpZfprq9u5hyPxHRNKws35AeATcNckJ0T9CCA@mail.gmail.com>

On Wed, Jan 27, 2016 at 1:11 AM, Eric S. Raymond <esr at thyrsus.com> wrote:

> Well, yes, often.  But...and I'm being serious now...it's good form to
> send a request for bisection back to the bug reporter when you suspect
> that the bug might be sensitive to environmental factors that are
> tricky to identify and replicate.  That way you avoid getting ratholed
> by an inability to reproduce the bug locally.
>


I went through the bisect, starting from a commit of 17th Dec, and kept
seeing "good", till git told me that the bad commit was:

root at ntpmon:~/ntpsec# git bisect good
56630d4119ffeddd356a937c449026161c3f384b is the first bad commit
commit 56630d4119ffeddd356a937c449026161c3f384b
Author: Eric S. Raymond <esr at thyrsus.com>
Date:   Tue Jan 26 04:34:46 2016 -0500

    Fix a typo in a Coverity annotation.

:040000 040000 6411b1f4c3f968ce071a2f44ee89b9bfd84ecc76
4477eca5cfafa21e690f888e4c129ff9194c46a5 M    libparse

Luckily, just before I did a victory dance, I checked out HEAD again; and
did a waf configure; waf install .  And I can no longer see the problem;
all is well.



> (And you *always* suspect tricky environmental factors when DNS lookups
> are involved.  That is, if you weren't born yesterday.)
>

I assure you (for whatever little it is worth), that *nothing* changed.
Well, I am not sure I did a waf configure before the install earlier this
evening, if I can blame that.

Apologies for the noise, and thanks for the chance to learn something new.

-- Sanjeev "you can call me Betty now" Gupta

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160127/e9585a74/attachment.html>

From esr at thyrsus.com  Tue Jan 26 18:35:45 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 13:35:45 -0500
Subject: POOL keyword in ntp.conf non resolving
In-Reply-To: <CAHZk5Wf_S6WhNVpZfprq9u5hyPxHRNKws35AeATcNckJ0T9CCA@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CAHZk5We1XkpmFoQJEP3+yaq=tGKcmm+h-pDet6OwpJW0Vd0FJQ@mail.gmail.com>
 <20160126171106.GB14558@thyrsus.com>
 <CAHZk5Wf_S6WhNVpZfprq9u5hyPxHRNKws35AeATcNckJ0T9CCA@mail.gmail.com>
Message-ID: <20160126183545.GA15994@thyrsus.com>

Sanjeev Gupta <ghane0 at gmail.com>:
> Luckily, just before I did a victory dance, I checked out HEAD again; and
> did a waf configure; waf install .  And I can no longer see the problem;
> all is well.
> 
> > (And you *always* suspect tricky environmental factors when DNS lookups
> > are involved.  That is, if you weren't born yesterday.)
> 
> I assure you (for whatever little it is worth), that *nothing* changed.
> Well, I am not sure I did a waf configure before the install earlier this
> evening, if I can blame that.
> 
> Apologies for the noise, and thanks for the chance to learn something new.

Probably just a transient DNS glitch.  It happens.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From fallenpegasus at gmail.com  Tue Jan 26 18:45:40 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Tue, 26 Jan 2016 18:45:40 +0000
Subject: re almost inventing things
In-Reply-To: <20160126170002.GA14558@thyrsus.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CANW5CYV3WajwFrO9DNQ4k0nV4ZEjFDBPHYoy+VaJFUKZ-+Y3-w@mail.gmail.com>
 <20160126170002.GA14558@thyrsus.com>
Message-ID: <CANW5CYW-pzaNrcY9LucG6HYD_y4TqG6_1jW6jga4r4Hh1SqZQw@mail.gmail.com>

Re almost inventing DVCS and almost inventing Linux.

I keep a notebook list of ideas that I know I had, that I didnt have the
interest, realization, drive, time, or skills, to chase and execute on,
that within a year or two later had burst onto the scene as billion dollar
VC funded "awesome tech".

One of my biggest ones was back in 2004, when at my workplace I hacked
together a HTTP interface to controlling Xen, that pushed around boot and
mount file system images via HTTP GET/PUT/POST.   If I had pushed that a
bit farther, abstracted it a bit more, and had been allowed by Digeo to
open source it, I could have "invented" cloud computing....

My lesson I take away from that is not that I am some special fount of
valuable ideas, but that nearly everyone who works in the right parts of
the tech space is, but that means little, as ideas are cheap, it's
execution that is valuable.

(This is also part of the cultural gulf between the tech innovation
mindsets associated with the US west coast (ideas are cheap, execution and
regulation is expensive), and the US east coast (ideas are special,
precious, secret, and dangerous.  However, execution is something you hire
"staff" to do, and lawyers are plentiful and free, since you already have
them on staff.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160126/78507f3d/attachment.html>

From esr at thyrsus.com  Tue Jan 26 19:19:47 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 14:19:47 -0500
Subject: re almost inventing things
In-Reply-To: <CANW5CYW-pzaNrcY9LucG6HYD_y4TqG6_1jW6jga4r4Hh1SqZQw@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CANW5CYV3WajwFrO9DNQ4k0nV4ZEjFDBPHYoy+VaJFUKZ-+Y3-w@mail.gmail.com>
 <20160126170002.GA14558@thyrsus.com>
 <CANW5CYW-pzaNrcY9LucG6HYD_y4TqG6_1jW6jga4r4Hh1SqZQw@mail.gmail.com>
Message-ID: <20160126191947.GA16258@thyrsus.com>

Mark Atwood <fallenpegasus at gmail.com>:
> My lesson I take away from that is not that I am some special fount of
> valuable ideas, but that nearly everyone who works in the right parts of
> the tech space is, but that means little, as ideas are cheap, it's
> execution that is valuable.

I think this is *mostly* true.  Occasionally there are ideas that aren't cheap.
One of my favorite examples is Whitfield Diffie's insight about trapdoor
functions implying public-key crypto.

I would also say there is a third factor that comes between insight
and execution, a kind of courage. Many people fail at that step
because they lack the fortitude to believe the actual consequences of
their lightning-strike insight.  They flinch: "Someone else must have
thought of this," or "It can't really be like that!" or "Too weird!".
And then they don't follow through even to the point of beginning to
execute.

Whatever my other flaws, I've at least gotten pretty good at
recognizing the lightning when it lands and not flinching.  That's not
a capability I had reliably when I was younger.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Tue Jan 26 19:23:46 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 11:23:46 -0800
Subject: POOL keyword in ntp.conf non resolving
Message-ID: <20160126192346.1677D406057@ip-64-139-1-69.sjc.megapath.net>


ghane0 at gmail.com said:
> 01-26T23:14:40 ntpd[28107]: error resolving pool hk.pool.ntp.org: No address
> associated with hostname (-5) 

That tells you that DNS isn't working.

The pool stuff works for me.

Have you tried simple command line tools to verify that your DNS setup is 
working?  I use host and dig.


-- 
These are my opinions.  I hate spam.




From verm at darkbeer.org  Tue Jan 26 21:06:46 2016
From: verm at darkbeer.org (Amar Takhar)
Date: Tue, 26 Jan 2016 21:06:46 +0000
Subject: Release mode.
Message-ID: <20160126210646.GA71338@darkbeer.org>

I've added a release mode to the build.  The instructions are in the commit 
message.  This lowers the barrier for entry for using NTPSec and ensures our 
tested versions work the same for the public.

I'll be enabling snapshots using BuildBot and uploading them to ftp.ntpsec.org 
for users that want the version that passed testing.  The snapshot will only be 
created if all builds / tests pass.

I didn't want this in the latest release as I wanted to catch any edge cases 
through regular development.

This also means we can remove the 'waf' binary from the Git repository and 
package it in with the tarball releases in the future.


Amar.

From hmurray at megapathdsl.net  Tue Jan 26 21:07:04 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 13:07:04 -0800
Subject: SIGINT, longjmp
Message-ID: <20160126210704.75923406057@ip-64-139-1-69.sjc.megapath.net>


The problem is that somebody is masking off SIGINT.  It works if I replace 
setjmp+longjmp with sigsetjmp+siglongjmp.

The SIGINT handler was getting called with SIGINT masked off.  That seems a 
bit strange.  It was coming from deep within getnameinfo.

I haven't figured out if this is a bug in getnameinfo or if longjmp-ing is 
basically evil.


-- 
These are my opinions.  I hate spam.




From kurt at roeckx.be  Tue Jan 26 21:19:07 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 26 Jan 2016 22:19:07 +0100
Subject: SIGINT, longjmp
In-Reply-To: <20160126210704.75923406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160126210704.75923406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160126211907.GA29651@roeckx.be>

On Tue, Jan 26, 2016 at 01:07:04PM -0800, Hal Murray wrote:
> 
> The problem is that somebody is masking off SIGINT.  It works if I replace 
> setjmp+longjmp with sigsetjmp+siglongjmp.
> 
> The SIGINT handler was getting called with SIGINT masked off.  That seems a 
> bit strange.  It was coming from deep within getnameinfo.
> 
> I haven't figured out if this is a bug in getnameinfo or if longjmp-ing is 
> basically evil.

It's not clear to me when this longjmp() is called.  But if
changing to siglongjmp() fixed it, it seems the signal handling
got changed in between?


Kurt


From hmurray at megapathdsl.net  Tue Jan 26 21:38:52 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 13:38:52 -0800
Subject: SIGINT, longjmp
In-Reply-To: Message from Kurt Roeckx <kurt@roeckx.be>
 of "Tue, 26 Jan 2016 22:19:07 +0100." <20160126211907.GA29651@roeckx.be>
Message-ID: <20160126213852.1606C406057@ip-64-139-1-69.sjc.megapath.net>


kurt at roeckx.be said:
> It's not clear to me when this longjmp() is called.  But if changing to
> siglongjmp() fixed it, it seems the signal handling got changed in between? 

It's called from the ^C signal handler.  It's the brute force way of 
terminating a command.

I haven't found anyplace in our code that messes with the signal mask.  I 
could easily be overlooking something that will be obvious in hindsight.

Nor have I found the API specs that mention this tangle.  There is an 
opportunity for storage leaks if a routine returns storage that should be 
free-ed or even uses/frees storage internally.

I'm fishing for a list of routines that shouldn't be used with longjmp similar to the list that shouldn't be used with threads, or rather for the discussion of that list.


-- 
These are my opinions.  I hate spam.




From kurt at roeckx.be  Tue Jan 26 22:03:01 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 26 Jan 2016 23:03:01 +0100
Subject: SIGINT, longjmp
In-Reply-To: <20160126213852.1606C406057@ip-64-139-1-69.sjc.megapath.net>
References: <kurt@roeckx.be> <20160126211907.GA29651@roeckx.be>
 <20160126213852.1606C406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160126220300.GA30336@roeckx.be>

On Tue, Jan 26, 2016 at 01:38:52PM -0800, Hal Murray wrote:
> 
> kurt at roeckx.be said:
> > It's not clear to me when this longjmp() is called.  But if changing to
> > siglongjmp() fixed it, it seems the signal handling got changed in between? 
> 
> It's called from the ^C signal handler.  It's the brute force way of 
> terminating a command.

Why do you set up a signal handler for this, and don't let the OS
take care of it?

Or alternativly, just call _exit() from the signal handler.

> I haven't found anyplace in our code that messes with the signal mask.  I 
> could easily be overlooking something that will be obvious in hindsight.

Maybe getnameinfo() does.  Like I said before, you need to be
careful of what you do in signal handlers.  Calling longjmp()
clearly isn't documented as being safe to do in that context,
for a list of functions see man signal(7).


Kurt


From kurt at roeckx.be  Tue Jan 26 22:05:06 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 26 Jan 2016 23:05:06 +0100
Subject: SIGINT, longjmp
In-Reply-To: <20160126220300.GA30336@roeckx.be>
References: <kurt@roeckx.be> <20160126211907.GA29651@roeckx.be>
 <20160126213852.1606C406057@ip-64-139-1-69.sjc.megapath.net>
 <20160126220300.GA30336@roeckx.be>
Message-ID: <20160126220506.GA30565@roeckx.be>

On Tue, Jan 26, 2016 at 11:03:01PM +0100, Kurt Roeckx wrote:
> > I haven't found anyplace in our code that messes with the signal mask.  I 
> > could easily be overlooking something that will be obvious in hindsight.
> 
> Maybe getnameinfo() does.

I want to add that it likely does at least something with the
signal handlers so that it can time out.


Kurt


From hmurray at megapathdsl.net  Tue Jan 26 22:26:57 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 14:26:57 -0800
Subject: SIGINT, longjmp
In-Reply-To: Message from Kurt Roeckx <kurt@roeckx.be>
 of "Tue, 26 Jan 2016 23:05:06 +0100." <20160126220506.GA30565@roeckx.be>
Message-ID: <20160126222657.598C9406057@ip-64-139-1-69.sjc.megapath.net>


kurt at roeckx.be said:
> I want to add that it likely does at least something with the signal
> handlers so that it can time out. 

You don't need signals to time out on network activity.  Most reads/writes 
have a timeout option.  I forget the details.  It's been a long time.  If 
that doesn't work, you can use select.


-- 
These are my opinions.  I hate spam.




From hmurray at megapathdsl.net  Tue Jan 26 22:39:28 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 14:39:28 -0800
Subject: SIGINT, longjmp
In-Reply-To: Message from Kurt Roeckx <kurt@roeckx.be>
 of "Tue, 26 Jan 2016 23:03:01 +0100." <20160126220300.GA30336@roeckx.be>
Message-ID: <20160126223928.BCA8A406057@ip-64-139-1-69.sjc.megapath.net>


kurt at roeckx.be said:
> Why do you set up a signal handler for this, and don't let the OS take care
> of it?

> Or alternativly, just call _exit() from the signal handler. 

It's not trying to exit, just get out of a long running command.

ntpq has two long-running commands.  (Maybe more.)

One is peers (which has many variants).  Normally, it tries to translate the 
IP address of the slot to a name.

The other is mrulist.  It runs in two passes.  The first pass collects the 
data. Since slots may get updated while being collected there is the 
possibility to go back and fetch them again.  The second pass sorts and 
prints things out.

With two passes, you would like ^C during the collect pass to stop collecting 
and print out what it has.  So the ^C handler just sets a flag and the 
collect loop stops collecting.  The print pass resets the flag as it starts, 
then watches the flag so another ^C will stop printing.

I think I could avoid the longjmp by having the peers loop check the flag.  I 
haven't checked to see if there are any other commands that might run too 
long.


-- 
These are my opinions.  I hate spam.




From esr at thyrsus.com  Wed Jan 27 00:38:52 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 19:38:52 -0500
Subject: Release mode.
In-Reply-To: <20160126210646.GA71338@darkbeer.org>
References: <20160126210646.GA71338@darkbeer.org>
Message-ID: <20160127003852.GB22854@thyrsus.com>

Amar Takhar <verm at darkbeer.org>:
> This also means we can remove the 'waf' binary from the Git repository and 
> package it in with the tarball releases in the future.

I'd be opposed to this.  It might compromise build replicability in the future.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From esr at thyrsus.com  Wed Jan 27 00:46:00 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 19:46:00 -0500
Subject: SIGINT, longjmp
In-Reply-To: <20160126210704.75923406057@ip-64-139-1-69.sjc.megapath.net>
References: <20160126210704.75923406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160127004600.GD22854@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> I haven't figured out if this is a bug in getnameinfo or if longjmp-ing is 
> basically evil.

I wouldn't say "evil" exactly, but...remember my caveats about signal handlers?
They apply.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From esr at thyrsus.com  Wed Jan 27 00:56:44 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Tue, 26 Jan 2016 19:56:44 -0500
Subject: SIGINT, longjmp
In-Reply-To: <20160126213852.1606C406057@ip-64-139-1-69.sjc.megapath.net>
References: <kurt@roeckx.be> <20160126211907.GA29651@roeckx.be>
 <20160126213852.1606C406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160127005644.GE22854@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> I'm fishing for a list of routines that shouldn't be used with longjmp similar to the list that shouldn't be used with threads, or rather for the discussion of that list.

I don't know of any functions that are specifically unsafe around
setjmp()/longjmp().

The right way to think about setjmp()/longjmp() is as a save/restore of the
processor's register state, including  the stack and frame pointers.  It
doesn't have the concurrency issues that threads do because it doesn't
alter static memory or the heap.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Wed Jan 27 02:05:52 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 18:05:52 -0800
Subject: SIGINT, longjmp
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Tue, 26 Jan 2016 19:56:44 EST." <20160127005644.GE22854@thyrsus.com>
Message-ID: <20160127020552.2D9F7406057@ip-64-139-1-69.sjc.megapath.net>


esr at thyrsus.com said:
> I don't know of any functions that are specifically unsafe around setjmp()/
> longjmp().

The interesting case is longjmp-ing from a signal handler.

> The right way to think about setjmp()/longjmp() is as a save/restore of the
> processor's register state, including  the stack and frame pointers.  It
> doesn't have the concurrency issues that threads do because it doesn't alter
> static memory or the heap.

It doesn't alter the heap, but it doesn't restore it either.

Anything that calls malloc is an opportunity for a storage leak.  Jmp-ing 
from a signal handler yanks you out of the middle of a routine without any 
opportunity for cleanup.

I suspect getaddrinfo masks or intercepts SIGINT, but I haven't found 
anything like that in the man pages.  The symptom is that ^C doesn't work 
right away but does work after several seconds, a reasonable time for a DNS 
lookup if you need to retransmit or have a bloated link.

A signal handler is roughly equivalent to a short-lived thread.  The Linux 
man page has a list of routines that are guaranteed to work crrectly from a 
handler.  It doesn't say anything about longjmp.  The man page for longjmp 
doesn't say anything about signals other than siglongjmp restores the mask.


-- 
These are my opinions.  I hate spam.




From ghane0 at gmail.com  Wed Jan 27 03:26:13 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 27 Jan 2016 11:26:13 +0800
Subject: Release mode.
In-Reply-To: <20160126210646.GA71338@darkbeer.org>
References: <20160126210646.GA71338@darkbeer.org>
Message-ID: <CAHZk5WcELC=rkfmXiKoSAi6ZNDKDzouX1oWBOa4MZVhELm-bVQ@mail.gmail.com>

On Wed, Jan 27, 2016 at 5:06 AM, Amar Takhar <verm at darkbeer.org> wrote:

> This also means we can remove the 'waf' binary from the Git repository and
> package it in with the tarball releases in the future
>

Speaking for ease of use for me, I would prefer not to think about which
waf version to use when building from git.

Please?

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160127/53731678/attachment.html>

From ghane0 at gmail.com  Wed Jan 27 03:53:45 2016
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 27 Jan 2016 11:53:45 +0800
Subject: re almost inventing things
In-Reply-To: <CANW5CYW-pzaNrcY9LucG6HYD_y4TqG6_1jW6jga4r4Hh1SqZQw@mail.gmail.com>
References: <CAHZk5WfT1pLuBvSMGL_oOLwS+VE6Son_WD+LsRzdF+JLTyLxCQ@mail.gmail.com>
 <20160126154104.GA14055@thyrsus.com>
 <CANW5CYV3WajwFrO9DNQ4k0nV4ZEjFDBPHYoy+VaJFUKZ-+Y3-w@mail.gmail.com>
 <20160126170002.GA14558@thyrsus.com>
 <CANW5CYW-pzaNrcY9LucG6HYD_y4TqG6_1jW6jga4r4Hh1SqZQw@mail.gmail.com>
Message-ID: <CAHZk5WfWabYpgaUMxDSCAQzeNz8Fh3TEFgUAWgP4tOPM3seFBA@mail.gmail.com>

On Wed, Jan 27, 2016 at 2:45 AM, Mark Atwood <fallenpegasus at gmail.com>
wrote:

> My lesson I take away from that is not that I am some special fount of
> valuable ideas, but that nearly everyone who works in the right parts of
> the tech space is, but that means little, as ideas are cheap, it's
> execution that is valuable.


When I was 11 or so, in a secondary school in Africa that had a nice
building and a long history but few teachers and no textbooks, I tried to
make squaring a number easier by looking at how it could be cheated around.

Eg: The square of 38 is quite difficult to calculate, you need 4 multiply
steps, and a bunch of addition, and a place to write stuff down.  There
MUST be a way to get the answer, trivially, from the square of 3 and 8 (not
30 and 8, that is not much help).

I am not sure when I spotted the pattern, but have you realised that
squares of successive numbers always differ by an odd number, which
increases each time by 2?  You have?  Drat.

I remember waking my Dad (a practising Civil Engineer) to tell him this: I
could calculate 38^2 with a simple addition if I knew 37^2.  He nodded, and
did not destroy my happiness.  I was so happy at my insight, I dropped work
on the original problem.

A couple of years later, I found out that a mythical guy called Isaac
Newton had gone further, and also figured out a way to predict the odd
number.  Mythical, because, frankly, no one I have met has ever seen him,
he does not post to newsgroups, he has no Twitter account, etc.

PS: I tried to get Isaac Newton's birthday declared a holiday in my school,
and was told we had too few teaching days.  Considering the Asst Headmaster
was also our Physics teacher and our Chemistry teacher, etc, and we had no
lectures for weeks on end as he ran around, I am not sure what he thought
was going on on normal days, let alone on Newton's birthday.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160127/361f20c8/attachment.html>

From esr at thyrsus.com  Wed Jan 27 06:08:54 2016
From: esr at thyrsus.com (Eric S. Raymond)
Date: Wed, 27 Jan 2016 01:08:54 -0500
Subject: SIGINT, longjmp
In-Reply-To: <20160127020552.2D9F7406057@ip-64-139-1-69.sjc.megapath.net>
References: <esr@thyrsus.com> <20160127005644.GE22854@thyrsus.com>
 <20160127020552.2D9F7406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20160127060854.GA27194@thyrsus.com>

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I don't know of any functions that are specifically unsafe around setjmp()/
> > longjmp().
> 
> The interesting case is longjmp-ing from a signal handler.

Right.  I believe the way a signal handler works is actually like a
setjmp/longjmp; that is, on receipt of a signal the register contect
is saved, the handler is called, then on exit the register context is
restored.

It probably does follow that you don't want to longjmp() out of a signal
handler; hidden context like signal block masks mightnot be restored.
I note that the GPSD code does not do this.  I think I used to know details
about this that I've forgotten.

> > The right way to think about setjmp()/longjmp() is as a save/restore of the
> > processor's register state, including  the stack and frame pointers.  It
> > doesn't have the concurrency issues that threads do because it doesn't alter
> > static memory or the heap.
> 
> It doesn't alter the heap, but it doesn't restore it either.

Correct.

> Anything that calls malloc is an opportunity for a storage leak.  Jmp-ing 
> from a signal handler yanks you out of the middle of a routine without any 
> opportunity for cleanup.

Correct.

> I suspect getaddrinfo masks or intercepts SIGINT, but I haven't found 
> anything like that in the man pages.  The symptom is that ^C doesn't work 
> right away but does work after several seconds, a reasonable time for a DNS 
> lookup if you need to retransmit or have a bloated link.

Ah, it's probably doing a sigsuspend(2).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

From hmurray at megapathdsl.net  Wed Jan 27 06:25:52 2016
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 26 Jan 2016 22:25:52 -0800
Subject: SIGINT, longjmp
In-Reply-To: Message from "Eric S. Raymond" <esr@thyrsus.com>
 of "Wed, 27 Jan 2016 01:08:54 EST." <20160127060854.GA27194@thyrsus.com>
Message-ID: <20160127062552.54743406057@ip-64-139-1-69.sjc.megapath.net>

> Ah, it's probably doing a sigsuspend(2).

I doubt it.  That ties up your process/thread waiting for a signal.  If you 
want to wait for IO, there are simpler ways.

My guess was sigprocmask(2).  They way that I discovered that somebody was 
masking SIGINT was using it to read the current mask.



-- 
These are my opinions.  I hate spam.




From fallenpegasus at gmail.com  Sun Jan 31 22:03:57 2016
From: fallenpegasus at gmail.com (Mark Atwood)
Date: Sun, 31 Jan 2016 14:03:57 -0800
Subject: Reminder: NTP and TICTOC Joint Virtual Interim WG meeting (4 Feb 2016
 @ 1630 UTC) 
Message-ID: <1454277837.2584978.507844826.14ABB433@webmail.messagingengine.com>

----- Original message -----
From: IESG Secretary <iesg-secretary at ietf.org>
To: IETF Announcement List <ietf-announce at ietf.org>
Subject: NTP and TICTOC Joint Virtual Interim WG meeting (4 Feb 2016 @
1630 UTC) 
Date: Mon, 25 Jan 2016 16:49:39 -0800

Folks,

We will have an interim joint meeting of the Network Time Protocol (NTP) 
and Timing over IP Connection and Transfer of Clock (TICTOC) working 
groups on Thursday, 4 February 2016 at 11:30 EST (16:30 UCT).

Topics for the agenda include:
- WG status updates (Karen)
- NTS status and progress including any impacts from 1588 F2F (Dieter 
  and Kristof)
- Report from IEEE 1588 Yang model coordination meeting on 3 February 
  (Karen and
- NTP BCP progress (Denis)
- Discussion of proposed charter update (forthcoming) (Karen)
- AOB

Below are the webex details for the meeting.

NTP/TICTOC Interim WG meeting
Thursday, February 4, 2016
11:30 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr 30 mins

Meeting link:
https://isoc.webex.com/isoc/j.php?MTID=m61896241ddd31651e3e85164ab088599

Meeting number: 929 117 523
Meeting password: synch

Join by phone
1-877-668-4493 Call-in toll-free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)

Additional global numbers:

https://isoc.webex.com/cmp0401lsp11/webcomponents/widget/globalcallin/globalcallin.do?siteurl=isoc&serviceType=MC&eventID=326970087&tollFree=0