Yo Hal!
On Mon, 08 Jan 2018 19:42:28 -0800
Hal Murray wrote:
> > 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 py
Hal Murray via devel writes:
>> 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.
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
> 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
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
> 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
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
>> 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
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
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
Can someone please fix this stupidity that waf is doing with the version
strings? It keeps the version around in multiple files, some of which
only get topuched when reconfiguring. I should be able to build from
any git checkout and not have to remember to jump through all those
hoops in order
Right. It's in config.h That's what we have to fix if we want to get decent
version strings.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Yo Hal!
On Tue, 23 May 2017 13:56:07 -0700
Hal Murray wrote:
> >> configure sets up NTPSEC_VERSION_STRING
> >> ntptime is the only useage.
> > Seems like a different issue than detecting an old or unusable
> > configure. Do you propose a tie-in?
>
> Only that the version and EPOCH stuff ar
There may be some confusion between comments about what exists and what I'd
like.
> Yes. People forgetting to run configure is a persistent problem.
Eric: An item for your list.
I don't have any good suggestions for how to fix that. I think it could also
happen if a tarball was extracted on
Yo Hal!
On Mon, 22 May 2017 23:26:05 -0700
Hal Murray via devel wrote:
> I think the tangle mentioned at Issue #313 needs wider discussion.
> ntpsec | build version not updated after git pull (#313)
> https://gitlab.com/NTPsec/ntpsec/issues/313
Yes. People forgetting to run configure is a
I think the tangle mentioned at Issue #313 needs wider discussion.
ntpsec | build version not updated after git pull (#313)
https://gitlab.com/NTPsec/ntpsec/issues/313
A while ago, we changed things to not use __DATE__. Maybe we didn't get that
right. Maybe the default should be to use __D
Yo Hal!
On Sun, 16 Apr 2017 18:52:07 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > Before we get into how much extra work this adds to the build, what
> > exactly is the extra info we would want?
>
> I'm not sure we need any "extra" info.
The repro build does need different info.
> T
g...@rellim.com said:
> Before we get into how much extra work this adds to the build, what exactly
> is the extra info we would want?
I'm not sure we need any "extra" info.
The NMEA driver wants as late a time-stamp as it can get. It will work with
the last commit date. It will work better
the extra info we would want?
For repro builds we replace __DATE__ and __TIME__ with MKREPRO_TIME
and MKREPRO_DATE.
Could MKREPRO_xxx be derived easily from last the lsat commit meta data?
> I'm willing to rebuild a few extra modules in order to get useful
> version strings.
What would you d
ow buildbots; qemu images
> for exotic architectures would be right out.
My proposal was for a option that defaulted to off. Buildbots wouldn't
enable it.
I'm willing to rebuild a few extra modules in order to get useful version
strings. The when-to-update complexity doesn'
Hal Murray :
> I consider the current setup to be close to useless. If I go through the
> typical edit, build, test cycle, the string doesn't get updated so I can't
> tell if I'm running the version from git or something with local
> modifications.
>
> I gather there is a constraint from distr
I consider the current setup to be close to useless. If I go through the
typical edit, build, test cycle, the string doesn't get updated so I can't
tell if I'm running the version from git or something with local
modifications.
I gather there is a constraint from distros. They want the binari
31 matches
Mail list logo
