> That's annoying. Looks like that hack never actually got completed.
> I've just pushed an attempted fix.
Progress. Thanks. NetBSD and FreeBSD are now building.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
h
Mark Atwood :
> If you want a randomly different thing to relaxation hack on with Go,
> instead of an IRC server, consider a Matrix.ORG server. A Matrix.org
> server that is binary and performant actually has a good chance of
> significant uptake. But, your choice, your project.
That's not a b
Hal Murray :
>
> e...@thyrsus.com said:
> > The part that might be missing if you lost an update somewhere is
> > "includes=ctx.env.PLATFORM_INCLUDES". That needs to be there for sodium.h to
> > be found if it's not under /include or /include/sys.
>
> That's working now. I assume one of us lost
If you want a randomly different thing to relaxation hack on with Go,
instead of an IRC server, consider a Matrix.ORG server. A Matrix.org
server that is binary and performant actually has a good chance of
significant uptake. But, your choice, your project.
Thank you for your work, Eric. I ha
Yo Kurt!
On Fri, 20 Jan 2017 01:51:23 +0100
Kurt Roeckx wrote:
> > You are right, I probably should have said the resolution of the
> > PPS is just one second That PPS just fires once a second. There is
> > no way to tall anything about anything, except that one moment in
> > time at the top of
e...@thyrsus.com said:
> The part that might be missing if you lost an update somewhere is
> "includes=ctx.env.PLATFORM_INCLUDES". That needs to be there for sodium.h to
> be found if it's not under /include or /include/sys.
That's working now. I assume one of us lost an update.
It now has sim
On Thu, Jan 19, 2017 at 02:40:08PM -0800, Gary E. Miller wrote:
> > > I'm worried about 1 micro Second or less. And one should not
> > > confuse accuracy with resolution. A PPS signal only has a
> > > resolution of one Second, but can eaaily have an accuracy of 10
> > > nano seconds.
> >
> > P
Gary E. Miller :
> Yo Eric!
>
> On Thu, 19 Jan 2017 17:00:31 -0500 (EST)
> e...@thyrsus.com (Eric S. Raymond) wrote:
>
> > There is now an executable script named "buildprep" in the top-level
> > directory that attempts to automate the job of installing build
> > perequisites.
>
> Not there. I
Hal Murray :
>
> >> if ctx.env.PLATFORM_TARGET in ["freebsd", "osx", "openbsd"]:
> >> ctx.env.PLATFORM_INCLUDES = ["/usr/local/include"]
> >> ctx.env.PLATFORM_LIBPATH = ["/usr/local/lib"]
> >> That looks like it should work on FreeBSD, but it doesn't. I looked in
> >> config
>> if ctx.env.PLATFORM_TARGET in ["freebsd", "osx", "openbsd"]:
>> ctx.env.PLATFORM_INCLUDES = ["/usr/local/include"]
>> ctx.env.PLATFORM_LIBPATH = ["/usr/local/lib"]
>> That looks like it should work on FreeBSD, but it doesn't. I looked in
>> config.log. It's not there.
Yo Eric!
On Thu, 19 Jan 2017 17:00:31 -0500 (EST)
e...@thyrsus.com (Eric S. Raymond) wrote:
> There is now an executable script named "buildprep" in the top-level
> directory that attempts to automate the job of installing build
> perequisites.
Not there. I just did this:
kong ntpsec # git pul
Yo Eric!
On Thu, 19 Jan 2017 17:23:01 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Yo Eric!
> >
> > On Thu, 19 Jan 2017 14:30:35 -0500
> > "Eric S. Raymond" wrote:
> >
> > > Gary E. Miller :
> > > > > - to fuzz the low-order bits of the clock.
> > > >
> > > > Hmm, can you ex
Yo Kurt!
On Thu, 19 Jan 2017 23:11:18 +0100
Kurt Roeckx wrote:
> > In my GR-601W experiments I can show it would be bad.
>
> I really have no idea what kind of experiment that was, but I
> doubt that it somehow has an ADC.
That is getting the most accurate time possible onto an NTP server
th
Hal Murray :
>
> > At first glance this seems reasonable, but my experience with the GR-601W
> > suggests otherwise. My experience with the GR-601W shows that ntpd can find
> > a timing edge and hold onto it very well.
>
> The fuzz we are talking about has nothing to do with where the time come
Hal Murray :
>
> k...@roeckx.be said:
> >> Running Wheezy, I take it?
> > It's libsodium-dev
>
> Thanks.
>
> Works on Jessie. Doesn't work on Wheezy.
> E: Unable to locate package libsodium-dev
>
> Works on Ubuntu 16.04.1, Doesn't work on 14.04.5
> E: Unable to locate package libsodium-de
Hal Murray :
>
> >> NetBSD puts sodium.h in /usr/pkg/include/
> >> FreeBSD puts it in /usr/local/include/
> > I added includes=ctx.env.PLATFORM_INCLUDES as an argument to the header
> > check. In theory that ought to fix this.
>
> Still doesn't work on either NetBSD or FreeBSD. (Of course, I m
Kurt Roeckx :
> But I'm currently not really sure that it either improves
> things, make things worse, or has no effect at all.
I'm not either. At modern clock speeds it may well be *useless* noise -
I've harbored that suspicion - but I'm not expert enough in this area to
feel confident ripping i
Gary E. Miller :
> Yo Eric!
>
> On Thu, 19 Jan 2017 14:30:35 -0500
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller :
> > > > - to fuzz the low-order bits of the clock.
> > >
> > > Hmm, can you expand on this a bit? Which clock? How much fuzz?
> > > Does this degrade anything?
> >
> > Whe
On Thu, Jan 19, 2017 at 01:00:50PM -0800, Gary E. Miller wrote:
> Yo Kurt!
>
> On Thu, 19 Jan 2017 21:20:23 +0100
> Kurt Roeckx wrote:
>
> > On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote:
> > > Gary E. Miller :
> > > > > - to fuzz the low-order bits of the clock.
> > > >
>
There is now an executable script named "buildprep" in the top-level
directory that attempts to automate the job of installing build
perequisites.
I've tested it on recent Ubuntu and am reasonably sure it will work
on recent systems with a yum installer.
It doesn't yet handle Gentoo, SLES, or the
Yo Kurt!
On Thu, 19 Jan 2017 21:20:23 +0100
Kurt Roeckx wrote:
> On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote:
> > Gary E. Miller :
> > > > - to fuzz the low-order bits of the clock.
> > >
> > > Hmm, can you expand on this a bit? Which clock? How much fuzz?
> > > Does t
On Thu, Jan 19, 2017 at 02:30:35PM -0500, Eric S. Raymond wrote:
> Gary E. Miller :
> > > - to fuzz the low-order bits of the clock.
> >
> > Hmm, can you expand on this a bit? Which clock? How much fuzz?
> > Does this degrade anything?
>
> Whenever ntpd polls the system clock, it fuzzes the low
Yo Hal!
On Thu, 19 Jan 2017 12:03:51 -0800
Hal Murray wrote:
> > At first glance this seems reasonable, but my experience with the
> > GR-601W suggests otherwise. My experience with the GR-601W shows
> > that ntpd can find a timing edge and hold onto it very well.
>
> The fuzz we are talkin
> At first glance this seems reasonable, but my experience with the GR-601W
> suggests otherwise. My experience with the GR-601W shows that ntpd can find
> a timing edge and hold onto it very well.
The fuzz we are talking about has nothing to do with where the time comes
from. It's the precis
k...@roeckx.be said:
>> Running Wheezy, I take it?
> It's libsodium-dev
Thanks.
Works on Jessie. Doesn't work on Wheezy.
E: Unable to locate package libsodium-dev
Works on Ubuntu 16.04.1, Doesn't work on 14.04.5
E: Unable to locate package libsodium-dev
--
These are my opinions. I hat
Yo Eric!
On Thu, 19 Jan 2017 14:30:35 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > > - to fuzz the low-order bits of the clock.
> >
> > Hmm, can you expand on this a bit? Which clock? How much fuzz?
> > Does this degrade anything?
>
> Whenever ntpd polls the system clock, it fuz
e...@thyrsus.com said:
> Whenever ntpd polls the system clock, it fuzzes the lowest-order digits of
> the result. The amount of fuzz to apply is bounded by half the measured
> interval between system clock ticks.
> That shouldn't degrade anything. I presume it's a measure to foil timing
> attacks
>> NetBSD puts sodium.h in /usr/pkg/include/
>> FreeBSD puts it in /usr/local/include/
> I added includes=ctx.env.PLATFORM_INCLUDES as an argument to the header
> check. In theory that ought to fix this.
Still doesn't work on either NetBSD or FreeBSD. (Of course, I might have
fatfingered some
Gary E. Miller :
> > - to fuzz the low-order bits of the clock.
>
> Hmm, can you expand on this a bit? Which clock? How much fuzz?
> Does this degrade anything?
Whenever ntpd polls the system clock, it fuzzes the lowest-order digits
of the result. The amount of fuzz to apply is bounded by half
Yo Eric!
On Thu, 19 Jan 2017 13:32:20 -0500
"Eric S. Raymond" wrote:
> > waf errors out when it can't find sodium.h even if you haven't
> > configured with --enable-crypto
>
> That is correct behavior. The code uses ntp_random() - which calls
> libsodium
And sad we need a crypto library jus
On Thu, Jan 19, 2017 at 01:32:20PM -0500, Eric S. Raymond wrote:
> > INSTALL says:
> > Debian: libsodium
> >
> > apt-get install on my debian box says:
> > E: Unable to locate package libsodium
>
> Running Wheezy, I take it?
It's libsodium-dev
Kurt
_
Hal Murray :
> Eric: Please please please send a message to devel when you make a change
> like this.
Sorry, I occasionally forget that you don't watch #ntpsec.
In case you haven't looked at the commit log - and for those of you on
devel who missed this - there's good reason I yanked libsodium o
Eric: Please please please send a message to devel when you make a change
like this.
waf errors out when it can't find sodium.h even if you haven't configured
with --enable-crypto
NetBSD puts sodium.h in /usr/pkg/include/
FreeBSD puts it in /usr/local/include/
(In case it isn't obvious, waf doe
33 matches
Mail list logo
