On 01/09/2018 12:28 AM, Hal Murray wrote:
> Humm... I just noticed that most man pages have something in the middle of
> the top line where our man pages are blank.
>
> man 3 open, Fedora:
> OPEN(3P) POSIX Programmer's Manual OPEN(3P)
>
> man ntp.keys:
> NTP.KE
> asciidoc shows a manversion in the bottom left, but asciidoctor has dropped
> this attribute.
> asciidoctor seems to be the future[0], so it this worth it?
I think so. I assume we can work out some way to do it and/or asciidoctor
will add support for it if they expect to capture a big chunk
matthew.sel...@twosigma.com said:
> Yes, what if we build the version from the VERSION file (+ last git commit
> short hash + BUILD_EPOCH, only when building from git)?
> This would avoid having to calculate the distance to the tag, etc, that
> autorevision currently does.
> The BUILD_EPOCH woul
On 01/08/2018 08:28 PM, Hal Murray wrote:
> Our man pages already have the date in the center of the bottom line.
>
> What I was looking for was to add the version string in the left corner.
>
> Our page:
> 12/31/2017 NTP.KEYS(5)
Interestin
Hal Murray :
>
> e...@thyrsus.com said:
> > I don't know. My from-the-code-out view does not make me confident that I
> > know what the consequences of *not* processing mode 1 are.
>
> If somebody else said:
> peer
> It would stop working.
>
> It's probably reasonably easy to process them.
> What's wrong with being tangled up in ntpsec's policy and library. Now we
> just have to fix it one place, not two. How does adding complexity help
> here?
I was looking for a way to decouple simple scripts from the python library
package.
It all started when you wanted to be able to run s
>>> Who cares about the dynamic peak? That is handled by the RasPi on
>>> board capacitors. When the capacitors can not hold up the DC any
>>> longer then the meter sees the problem.
>> No, the meter is much too slow for that. (Or at least mine is.)
> I'd love to test that. Maybe the $100 USB
e...@thyrsus.com said:
> I don't know. My from-the-code-out view does not make me confident that I
> know what the consequences of *not* processing mode 1 are.
If somebody else said:
peer
It would stop working.
It's probably reasonably easy to process them. Just treat them like mode 3
unt
devel@ntpsec.org said:
> I just re-read this. I see you said "date". I addressed the version number,
> not the date. I think the change is still good for that reason.
My fat finger. Sorry.
Our man pages already have the date in the center of the bottom line.
What I was looking for was to add
On Mon, Jan 08, 2018 at 08:07:53PM -0600, Richard Laager via devel wrote:
> On 01/08/2018 07:58 PM, Richard Laager wrote:
> >> There was similar discussion of waf editing man pages to get the date on
> >> the
> >> bottom left corner.
> > Since I already learned a bunch about waf substitutions for
On 01/08/2018 07:58 PM, Richard Laager wrote:
>> There was similar discussion of waf editing man pages to get the date on the
>> bottom left corner.
> Since I already learned a bunch about waf substitutions for the path
> embedding thing, this didn't take me long to implement. Here is the
> merge
On 01/08/2018 03:41 PM, Hal Murray via devel wrote:
>>> Maybe it's time to move ntpviz and the logging
>>> stuff to a separate package.
>> How does that help?
> Then they could have their own version string policy rather than getting
> tangled up with ntpsec's policy and library.
Please don't. Th
On 01/08/2018 03:14 PM, Hal Murray via devel wrote:
>> waf should be putting the version in ntploggps, then it will mean something,
>> and can run standalone
If you need the version number in a Python utility, use something like
this (which I did test) to get the version number:
VERSION='@NTPSEC_V
On Mon, Jan 08, 2018 at 02:06:18PM -0800, Hal Murray wrote:
>
> > Long-term, I'd like to simplify and just do the same git checks within waf
> > itself.
>
> It's got to work without git, and it has to get the same checksum when built
> from git or tarball. I think that means you have to stash
Yo Hal!
On Mon, 08 Jan 2018 13:41:49 -0800
Hal Murray wrote:
> >> Maybe it's time to move ntpviz and the logging
> >> stuff to a separate package.
>
> > How does that help?
>
> Then they could have their own version string policy rather than
> getting tangled up with ntpsec's policy and li
Yo Hal!
On Mon, 08 Jan 2018 13:53:23 -0800
Hal Murray wrote:
> > Who cares about the dynamic peak? That is handled by the RasPi on
> > board capacitors. When the capacitors can not hold up the DC any
> > longer then the meter sees the problem.
>
> No, the meter is much too slow for that. (
devel@ntpsec.org said:
> That sounds useful, yes. Again, I wouldn't want a configurable delay as
> much as I would like to ensure that it only ever flushes a full block (or a
> whole multiple of that), as defined by the underlying fs (so most likely
> 512byte or 4kiB), to storage unless the proce
> Long-term, I'd like to simplify and just do the same git checks within waf
> itself.
It's got to work without git, and it has to get the same checksum when built
from git or tarball. I think that means you have to stash the git timestamp
in a local file. That file doesn't get checked into
Hal Murray :
> We only expect 3 modes of packets:
> Mode 6 gets diverted off to separate logic very early.
> Mode 3 is requests. We answer them.
> Mode 4 is responses to our requests.
>
> Do we want to process mode 1? (Other end is trying to peer with us.)
> I think it works to answer them
On Fri, Jan 05, 2018 at 11:37:15AM -0500, Matthew Selsky wrote:
> On Fri, Jan 05, 2018 at 08:17:18AM -0600, Ian Bruene via devel wrote:
> >
> > How can I get a detailed report on the new python test coverage check? And
> > how
> > robust is it: does it only count the percentage of functions teste
> Who cares about the dynamic peak? That is handled by the RasPi on board
> capacitors. When the capacitors can not hold up the DC any longer then the
> meter sees the problem.
No, the meter is much too slow for that. (Or at least mine is.)
--
These are my opinions. I hate spam.
__
On Mon, Jan 08, 2018 at 01:41:49PM -0800, Hal Murray via devel wrote:
> >> Maybe it's time to move ntpviz and the logging
> >> stuff to a separate package.
>
> > How does that help?
>
> Then they could have their own version string policy rather than getting
> tangled up with ntpsec's policy and
> The page that covers differences from Classic - docs/ntpsec.txt. It's under
> Security.
Thanks.
* peer mode has been removed. The keyword peer in ntp.conf is now
just an alias for keyword server.
* Broadcast- and multicast client modes, which are impossible to
secure, have been removed
Yo Achim!
On Mon, 08 Jan 2018 22:28:49 +0100
Achim Gratz via devel wrote:
> > Easy, get a USB VA meter. Good ones for $8. You'll be amazed at
> > all the things it teachs you.
>
> I have one, but how does that help me figure out the current draw
> before I buy the USB drive?
Hehehe, the
>> Maybe it's time to move ntpviz and the logging
>> stuff to a separate package.
> How does that help?
Then they could have their own version string policy rather than getting
tangled up with ntpsec's policy and library.
I think I'd call it a bug if a script only uses the python library to get
Hal Murray via devel writes:
>> Unless it's made optional it should be kept that way.
>
> Agreed. I was thinking of a parameter in the config file to set the flush
> delay.
That sounds useful, yes. Again, I wouldn't want a configurable delay as
much as I would like to ensure that it only ever
Yo Hal!
On Mon, 08 Jan 2018 13:14:49 -0800
Hal Murray via devel wrote:
> There was similar discussion of waf editing man pages to get the date
> on the bottom left corner.
Yup.
> I don't understand waf well enough to go there.
Ditto, and not high enough on my list to work on.
> I think this
Gary E. Miller via devel writes:
>> I might contemplate a mini USB drive for the logs, but I'd like to
>> keep things local.
>
> I've never beat on a USB drive as much as I beat on an SD card. Would
> they really be better? At least if the data is on its own device I
> only lose the data.
I gues
>> The logging code currently includes a flush. A few lines of
>> code could batch that.
> Unless it's made optional it should be kept that way.
Agreed. I was thinking of a parameter in the config file to set the flush
delay.
--
These are my opinions. I hate spam.
___
Was: Re: Catching up
Gary said:
> waf should be putting the version in ntploggps, then it will mean something,
> and can run standalone
There was similar discussion of waf editing man pages to get the date on the
bottom left corner.
I don't understand waf well enough to go there.
I think this
Yo Achim!
On Mon, 08 Jan 2018 21:47:05 +0100
Achim Gratz via devel wrote:
> You might have better luck with somewhat less cheap cards, one of the
> big differences between SD cards is how well they do wear levelling.
Yup. I see that, can't say it corelates so much to price as brand.
> Also, a
Hal Murray via devel writes:
> I keep daily log files. I think I modified the start script to copy the
> latest day to the tempfs and the stop script would copy it back and an hourly
> cron job would also copy it back and delete older files.
Yes, quite siomilar to what I had in mind, but I'd pr
Gary E. Miller via devel writes:
> I seem to burn out SD cards about monthly, spread out over 6 RasPi's. I
> just keep a pile of $10 SD cards handy and deal with it.
You might have better luck with somewhat less cheap cards, one of the
big differences between SD cards is how well they do wear lev
Yo Hal!
On Sun, 07 Jan 2018 19:22:30 -0800
Hal Murray wrote:
> >> I don't think running directly out of the source tree is very
> >> interesting.
>
> > OTOH, a bunch of programs, like ntplogtemp, that used to be able to
> > run in tree, no longer can. I think that is our loss. Creeping
> >
Yo Richard!
On Sun, 7 Jan 2018 23:03:41 -0600
Richard Laager via devel wrote:
> I did some light looking at eselect, and it seems it uses various
> mechanisms under the hood to implement the selection, depending on the
> situation.
Yeah, 'various'. More than I can keep track of. But the comma
> To be somewhat nicer to the SD card I think of moving the ntpd statistic
> logs to a tmpfs and then periodically moving them to permanent storage
I did something like that ages ago. I don't remember why I stopped. Most
likely it just fell through the cracks.
I keep daily log files. I thin
Yo Achim!
On Mon, 08 Jan 2018 21:02:41 +0100
Achim Gratz via devel wrote:
> To be somewhat nicer to the SD card I think of moving the ntpd
> statistic logs to a tmpfs and then
I seem to burn out SD cards about monthly, spread out over 6 RasPi's. I
just keep a pile of $10 SD cards handy and dea
To be somewhat nicer to the SD card I think of moving the ntpd statistic
logs to a tmpfs and then periodically moving them to permanent storage
(maybe parcelling them exactly into block sizes to minimize the write
amplification) so that they're not completely gone if the unexpected
reboot happens.
On 01/08/2018 05:30 AM, Hal Murray via devel wrote:
This smells like a Gitlab glitch, probably transient.
Is there a simple way to say "Please try again?" (without adding clutter to
git's log)
Click the pipeline icon, there will be options from there.
--
/"In the end; what separates a Man,
> This smells like a Gitlab glitch, probably transient.
Is there a simple way to say "Please try again?" (without adding clutter to
git's log)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/
Hal Murray via devel :
> I figured out why I didn't get the expected response from GitLab's build
> checker the other day. I forgot to do the push. Blush/Sigh.
>
> This just arrived:
>
> Subject: ntpsec | Pipeline #15898502 has failed for master | e349aa13
>
> WARNING: The following packages
I figured out why I didn't get the expected response from GitLab's build
checker the other day. I forgot to do the push. Blush/Sigh.
This just arrived:
Subject: ntpsec | Pipeline #15898502 has failed for master | e349aa13
WARNING: The following packages cannot be authenticated!
libcap2 libb
42 matches
Mail list logo
