Re: 1.0.1 and ntpsnmpd

2018-03-02 Thread Ian Bruene via devel 



On 03/02/2018 03:47 PM, Hal Murray via devel wrote:

It wouldn't surprise me if we had added something interesting.  I'm pretty
sure I have added things.  The only question is did we fill in a gap in
classic and/or will ntpsnmpd do the right thing if it encounters something
like that.


ntpsnmpd can handle when ntpd isn't running at all, so missing data 
isn't a problem.


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

2018-03-02 Thread Hal Murray via devel 

Eric said:
>> I could imagine that we have tweaked mode6 enough to be interesting.
> There's really only one possible point of breakage - driver IDs for
> reclocks.  I think we're safe there. 

It wouldn't surprise me if we had added something interesting.  I'm pretty 
sure I have added things.  The only question is did we fill in a gap in 
classic and/or will ntpsnmpd do the right thing if it encounters something 
like that.

In any case, we should have a classic setup where we can test things like 
this.  We'll also need it for testing authentication.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

2018-03-02 Thread Eric S. Raymond via devel 
Hal Murray via devel :
> I could imagine that we have tweaked mode6 enough to be interesting.

There's really only one possible point of breakage - driver IDs for
reclocks.  I think we're safe there.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: 1.0.1 and ntpsnmpd

2018-03-02 Thread Richard Laager via devel 
On 03/01/2018 05:54 PM, Mark Atwood wrote:
> ntpsnmpd should be it's own Debian package, please.  It's useful to both
> NTPsec and to NTP Classic installations.

Unless this is going to be actively supported and tested upstream, I'm
not interested in supporting that combination.

I'm going a little out-of-my-way to allow ntp + ntpsec-ntpviz, though
I'm not actively testing that the stats work (though they should). If
you made ntpviz officially supported with NTP Classic, I'd probably
pursue a package name change from ntpsec-ntpviz to ntpviz.

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Issue #450: python install dir

2018-03-02 Thread Richard Laager via devel 
On 03/02/2018 01:29 AM, Hal Murray via devel wrote:
> I think we should sort it out for the release.

My 2 cents:

If trivial (which it should be), switch to installing to PYTHONARCHDIR.
Otherwise, it's not a regression, so there's no need to hold the release.

This is an example of the "always one more thing to fix" I was talking
about.

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: prep for 1.0.1

2018-03-02 Thread Richard Laager via devel 
On 03/01/2018 08:09 PM, Hal Murray via devel wrote:
> It will take a day or two to fix the truncate case.  Maybe tonight.
> 
> It will take a week or so to add CMAC support.  Waiting for that seems like a 
> good idea.  It will give a good focus for a release.

Are these a regression from 1.0.0? If not, why hold the release? If
these aren't ready in time, there's no harm in cutting a 1.0.2 once they
are.

This is a (possible) example of the "always one more thing to fix" I was
talking about.

If it *is* a regression, then by all means hold the release.

-- 
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel