Version Strings - doesn't show recent edits

[Gary E. Miller]

Yo Hal!

On Sun, 16 Apr 2017 18:52:07 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> gem at 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.

> 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 with the actual
> build date - more-better as the time between commit and build
> increases.

Since both work, we just need a switch between commit data and
build date for NMEA driver.  They will rarely differ by more than 
a small percentage of 10 years, and at runtime other reality checks
are usually available.



> > Could MKREPRO_xxx be derived easily from last the lsat commit meta
> > data?  
> 
> I view that as an implementation detail.  I assume the answer is yes.
> 
> Currently, the version string comes from autorevision and the
> time-stamp that NMEA uses comes from __DATE__ or MKREPRO_DATE and
> friends.

So no changes needed to autorevision?

> We could fix the NMEA problem by using the time-stamp from
> autorevision. There is a scanf that pulls fields from __DATE__ and
> __TIME__.  It should be a simple change to use the string from
> autorevision in that step.

Works for me.

> We could remove a lot of cruft from libntp/ntp_calendar.c if whatever 
> time-stamp was used for NMEA was pre-processed by an external script
> rather than at run time.

I like that idea.

> > What would you define as 'useful' for a dev build?  
> 
> I'd be happy with the build time.  (as compared to the current last
> commit)

I'm not familiar with the problems that came up last time the
version scheme changed.  Here is one I have now:

ntpd ntpsec-0.9.7+421 2017-04-15T19:46:45Z

So, for you purposes that is good now?  And for report build just
replace with the last commit timestamp?

> If you want to do something fancy like the latest edit of any sources
> that would be OK too, but don't forget to include config.h

I'm not up to doing anything fancy/  Patches welcome.

> > Gentoo on RasPi sets the time with a special file that is updated
> > now and again.  ntpd could use the file time on the driftfile.  Or
> > many other possibilities.   
> 
> The problem with schemes like that is not which file to use, it's how
> to recover if the time on that file ever gets set into the future.

Yes, I see that all the time on my RasPi's.  Sort of.  The problem is
Linux thinks the time is in the future, but it really is not in the
future because the system clock not set properly yet.

> We could use something like the leap-seconds file which gets updated 
> occasionally as long as the update mechanism preserves the last-edit
> date.

That is worse than Gentoo does on RasPi now and would create many more
problems.  Just being a few hours wrong creates havoc, and the longer
the time spread the worse it gets.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170417/c71430bd/attachment.bin>