Hal Murray :
>
> > Looking at the changelog, the only one that jumps out at me is James's new
> > UI
> > options for ntpq.
>
> Should we have a policy of mentioning all UI changes?
I think so. I've been trying to do that whenever I write NEWS entries.
> How about config file changes?
Well,
Hal Murray :
> Is this an opportunity to clean up that area?
I don't think so. It's pretty clean now, functionally speaking - I put
a lot of work into rationalizing the configurator structures and the
way they talk to the protocol machine.
I suppose it might be if we were willing to make
cimparib
> The current blocker on the port is that Flex and Bison can't yet emit Go
> code. I'm probably going to have to fix that myself. There are roughly
> equivalent tools such as goyacc that are fine for new projects, but
> guaranteeing that you get the same accept grmmar from specifications in two
Hal Murray :
>
> >> If you want to claim your Go program has no buffer overruns,
> >> you can't call out to big complicated libraries written in c. You
> >> would have to rewrite them in Go.
>
> > Fair point. That changes my to-do list.
>
> Could you please say more? What did you add or drop?
> Looking at the changelog, the only one that jumps out at me is James's new UI
> options for ntpq.
Should we have a policy of mentioning all UI changes? I don't want a lot of
clutter, a quick mention should be enough to get people to check the
documentation.
How about config file changes?
>> If you want to claim your Go program has no buffer overruns,
>> you can't call out to big complicated libraries written in c. You
>> would have to rewrite them in Go.
> Fair point. That changes my to-do list.
Could you please say more? What did you add or drop?
--
These are my opinions
Can we run ntpd long enough to test the initialization and much of the other
code?
I'm thinking of something like start ntpd, wait a while, then kill it. While
it is running, we can also test ntpq. The idea is to take advantage of the
handful of environments that are readily available.
Is
On Fri, Sep 4, 2020 at 1:31 PM Hal Murray via devel wrote:
>
>
> Are any of the recent changes interesting enough to mention in NEWS?
Probably not so I'm just gonna empty the bucket. j/k
* duplicate server error message
* documentation updates/fixes
* shebang updates
* ntpkeygen can use secrets
*
Hal Murray via devel :
> Are any of the recent changes interesting enough to mention in NEWS?
Looking at the changelog, the only one that jumps out at me is James's new
UI options for ntpq.
Otherwise the recent stuff is bug triage and validator cleanups (LGTM
looks like a big win). I wouldn't wa
Are any of the recent changes interesting enough to mention in NEWS?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Yo Richard!
On Fri, 4 Sep 2020 02:14:13 -0500
Richard Laager via devel wrote:
> On 9/4/20 1:37 AM, Hal Murray via devel wrote:
> > Another question... How many systems are we interested in that
> > have Python2, don't have Python3, and have a version of OpenSSL
> > that is too old for NTS?
>
Yo Stephan!
On Fri, 4 Sep 2020 09:37:47 +0200
Stephan Seitz via devel wrote:
> I don’t know how much work it is to support python 2, but python 2 is
> dead and
Just because you do not use something does not make it dead.
When distros no longer support Python 2, then it will be dead.
> I woul
Yo Eric!
On Fri, 4 Sep 2020 08:23:05 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > As previously mentioned here: RHEL 6.
>
> Which is about to EOL.
Then let us table the discussion until all the major distros have
EOLed Python 2.
>
> > Supporting Python 2 is trivial. Why
Gary E. Miller via devel :
> As previously mentioned here: RHEL 6.
Which is about to EOL.
> Supporting Python 2 is trivial. Why the hate?
Because it's not in fact trivial. It's *doable*; Peter Donis and I are
the expers on how to do it. But it's not trivial. It proliferates
code and test path
I don't know what changed to trigger this.
I assume you can't easily test on Alpine, so I poked around a bit.
It's working after the edit below. I don't know if this will break on some
other system. Probably not. These look like vanilla system calls. Some
syscalls don't exist on some syst
On Do, Sep 03, 2020 at 23:06:48 -0700, Gary E. Miller via devel wrote:
Why the hate for Python 2? Supporting it is trivial. Let the distros
stop supporting Python 2 before we do. When distros support Python 2, we
I think this is the wrong way.
Distros can stop supporting python 2 when every
On 9/4/20 1:37 AM, Hal Murray via devel wrote:
> Another question... How many systems are we interested in that have Python2,
> don't have Python3, and have a version of OpenSSL that is too old for NTS?
The OpenSSL requirement* (>= 1.1.1b) requires a lot newer distro
versions than the Python 3 r
17 matches
Mail list logo
