Well then, there is our proof that Python is not quite universal yet.
It's always available, but it's presence cannot be blindly assumed.
On Fri, Sep 29, 2017 at 10:52 PM Hal Murray via devel wrote:
>
> >> What are the plans for splitting out the python stuff? Do most distros
> >> include Python
I "test" buildprep for Debian for every release, because I spin up a
small minimal Debian instance for each release.
One of my todo's is to collate and add to the docs the set of packages
I have apt-get each time.
On Fri, Sep 29, 2017 at 11:18 PM Hal Murray via devel wrote:
>
>
> Should we test
Jupyter is pretty cool. My dayjob recently hired one of the lead
contributors, and Jupyter use is spreading across the company,
especially by the data scientists and the econometrics people.
It's basically matlab with Python.
On Mon, Jul 15, 2019 at 3:41 AM Hal Murray via devel wrote:
>
> Mark
That looks neat!
Everyone, what do you think?
..m
On Mon, Aug 5, 2019 at 5:57 AM James Browning via devel
wrote:
>
> I have set up a branch replacing the current Python version-specific
> ntp.ntpc with a language-agnostic foreign function interface stub point
> and a version agnostic Python ntp
Can OnCore be supported by gpsd?
And while I also like removing code, we've removed a lot, and I'm not
instantly adverse to giving the hobbyests a command option to handle
wraparound on their old hardware.
On Thu, Aug 8, 2019 at 5:36 AM Eric S. Raymond via devel
wrote:
>
> Issue #608, "Future ne
> This would actually be pretty easy to do, mechanically speaking. The
hard question is what you do with this timing information once you have it.
Oh, believe me, cloud scale devops shops know what to do with all the
timing information.
On Sun, Jul 14, 2019 at 3:19 PM Eric S. Raymond wrote:
>
Hi guys, what do you think is causing this problem?
-- Forwarded message -
From: Marco Davids
Date: Tue, Jul 9, 2019 at 12:11 AM
Subject: NTPsec bug - maybe?
To: mark.atw...@ntpsec.org
Hi Mark,
Sorry for contacting you directly, but I can't seem to get any mails
through via th
You are right, it't not appearing in the FTP server. We'll find out why.
..m
On Tue, Jul 2, 2019 at 12:39 PM Fred Wright via devel wrote:
>
>
> On Sun, 30 Jun 2019, Mark Atwood wrote:
>
> > The NTPsec Project is pleased to announce the tagging of version 1.1.5
>
> I guess "tagging" is a good de
Don't remove it just yet, I will email someone about it.
On Thu, Jan 31, 2019 at 11:42 AM Eric S. Raymond via devel
wrote:
> Hal Murray via devel :
> > Or does anybody know if that path has been tested? If so, when?
> >
> > In case you don't recognize the term, it's when you get with
> --enable
How hard would it be to implement, and what does it buy us?
--
Mark Atwood
http://about.me/markatwood
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Screw it, it's worth it. I'm going to be at this.
..m
--
Mark Atwood
http://about.me/markatwood
+1-206-604-2198
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
| The CERT Coordination Center invites you to attend
| the CERT Vendor Meeting 2019. The meeting will
| be held on Monday March 4, 2019, at the Westin
| St. Francis in San Francisco, CA, US.
This is the sort of thing that does make me occationally wish I lived near
the SF Bay Area.
..m
--
Mar
I'm going to decide to not to decide right now. We leave those refclocks
in for now. This conversation is illuminating.
On Wed, Feb 6, 2019 at 9:32 AM Eric S. Raymond via devel
wrote:
> Richard Laager via devel :
> > I have (and was/am using) a clock using the Spectracom driver, with the
> > t
This sounds somewhat similar to the brilliant hack that is
https://github.com/ioerror/tlsdate
On Wed, Feb 6, 2019 at 9:34 AM Eric S. Raymond via devel
wrote:
> Richard Laager via devel :
> > On 2/5/19 7:49 PM, Richard Laager wrote:
> > > I have a specific proposal that I'll hopefully write up to
lockclock stays in
Thanks!
..m
On Sun, Jan 6, 2019 at 6:28 AM Eric S. Raymond via devel
wrote:
> Gary E. Miller via devel :
> > Lockclock mode is very important to the PTP people. They use PTP to
> > distribute time on the local net to the clients. Then a PTP client can
> > use NTP to server
We do indeed, thank you, Hal.
I would like to cut a release Sunday night, 2019-01-13
Everyone, please chime in, let me know if you think No Go or otherwise have
concerns.
Is buildbot happy?
Everyone, please no new features or major refactoring on the master
branch. If you have any pending bran
Wow, fast. Thanks Hal! ..m
On Mon, Oct 29, 2018 at 1:23 PM Gary E. Miller via devel
wrote:
> Yo Hal!
>
> On Mon, 29 Oct 2018 12:49:22 -0700
> Hal Murray wrote:
>
> > > Should be easy to fix. Anyone want to try?
> >
> > Done.
>
> Thanks!
>
> > const int totalLength = 36;
> > char packetPtr
Looks straightforward enough. Ian?
On Mon, Oct 29, 2018 at 12:02 PM Gary E. Miller via devel
wrote:
> Yo All!
>
> The Linux kernel has now removed all Varible Length Arrays (VLAs).
>
> Linux has spoke:
>
> "USING VLA'S IS ACTIVELY STUPID! It generates much more code, and much
> _slower_ code (an
https://osseu18.sched.com/event/FwGb/the-end-of-time-19-years-to-go-arnd-bergmann-linaro-ltd
There will be a video recording of this presentation. I will post a link
to that when it is available.
..m
--
Mark Atwood
http://about.me/markatwood
+1-206-604-2198
Thank you Hal!
On Thu, Sep 20, 2018 at 4:53 PM Hal Murray via devel
wrote:
>
> It's simple, at least conceptually. I'm embarrassed I didn't see it
> (much)
> sooner.
>
> The general idea with the old code is:
>
> From several places deep in ntp_io
> read data into rb
> rb->receiver = xxx
>
I've not seen an docs or use for it.
Unless Eric or Gary chime in, rip it out.
..m
On Wed, Sep 19, 2018 at 4:06 PM Hal Murray via devel
wrote:
>
> Is it documented anyplace?
>
> If nobody uses it, I propose to remove it to simplify work on SINGLEBUFFER.
>
> If somebody wants it, we can reimple
Thank you Mike! Please submit the PEP8 MR after you've fixed the merge
conflict. I will review your existing MRs.
On Thu, Sep 6, 2018 at 6:50 PM MIKE MAJOR via devel
wrote:
> Hi everyone,
>
> I'd like to tell you what I've been working on. I submitted MRs for the
> HOWTO section numbering and
I'm kind of a fan of dropping forking as well, and letting the distros do
the locally Right Thing with their startup scripts. Not enough of a fan to
say to do it right now, but I would like some more pros and cons about it.
--
Mark Atwood
http://about.me/markatwood
+1-206-604-2198
__
You are on the right track. You are discovering how git workflows work.
Feel free to keep asking questions on this mailing list.
Also, feel free to write up your experience, as a blog post, and to suggest
improvements to our HACKING.txt document.
Thank you for playing with NTPsec, and welcome!
I am going to tag the next release of NTPsec while at the f2f at SELF this
coming weekend.
No major work, new feature, or code removals are to go into mainline this
week. If you have a burning need to do major work, do it in a personal
branch.
Please cycle over the small cleanups, nits, doc fixe
We could kill the interface command, and let the usual syntax error happen.
Or we could raise a special syntax error, calling out the need to use the
packet filter instead. Then the question becomes, is it a
warn-and-continue, or a error-and-halt?
..m
On Tue, May 29, 2018 at 12:17 PM Eric S. Ra
On Tue, May 29, 2018 at 11:15 AM Achim Gratz via devel
wrote:
> However, there is still value in the knowledge of which interface the
> packet came in so that ntpd can place different levels of trust
> depending on whether it's from a private (virtual) network segement, an
> internal or public ne
There are a couple of different but very similar angles of approach to
explain why a network security experts will not trust a userspace daemon to
control it's own defensive packet filtering.
The UNIX concept: each tool should do one thing, and do it well. The ntpd
should no more do packet filte
There are a small core of trusted people who currently have ACLs and
blessing to develop with "git push", mainly ESR, GEM, Hal, and DFF, (and
myself when I'm cutting a release).
Everyone else is to use gitlab merge requests, and now MR's with the code
review voting that Matthew has set up.
Hal,
Ok, trying again. We held the 1.0.1 release for a fix for a problem that
Hal discovered and fixed. Thank you, Hal!
Since we have a CVE fix in this release, and also a "make it work better on
AWS AMIs" fix in, I do want to get this release out soonest.
Please chime in, is there any reason to not
Thank you!
On Mon, Mar 5, 2018 at 2:25 PM Hal Murray via devel
wrote:
> > Do you have the truncate fix in?
>
> Apologies for not sending a specific announcement.
>
> Yes.
>
> commit b01f1d658b11c4e8c24b307a7a79e8307364fbc2
> Author: Hal Murray
> Date: Fri Mar 2 00:38:49 2018 -0800
>
> Tru
Hi Hal,
Do you have the truncate fix in?
..m
On Thu, Mar 1, 2018 at 6:09 PM Hal Murray wrote:
>
> fallenpega...@gmail.com said:
> > If Hal isn't happy, I'm not happy. I'll hold the release until this gets
> > unsnarled. ..m
>
> It will take a day or two to fix the truncate case. Maybe tonig
Are we comfortable with the 1.0.1 release on March 3rd?
I look forward to seeing it move down all the distribution pipelines.
Google Alerts have shown 1.0.0 in Debian, Ubuntu, and Gentoo distribution
build reports.
..m
On Tue, Feb 20, 2018 at 6:41 PM Mark Atwood wrote:
> Hi!
>
> A few months a
The SNMP MIB RFCs are notorious for including magic blue sky values and
measurements that nobody knows how to measure and that are not well defined.
For things that don't make enough sense, it's ok to not implement that
particular snmp variable.
As for the "Check if ntpd configuration changed", t
Hi!
Due to our recently done fix for working correctly with the Amazon time
service, I think it is a good idea to push out a point release this week,
this coming weekend.
Please make sure that whatever you have pushed to master is ready for
release, andor let me know if there is any good reason n
35 matches
Mail list logo
