On Wed, Jun 30, 2021, at 11:59 AM Hal Murray wrote:
>
>
> > The build epoch has been replaced with a hardcoded timestamp which will be
> > manually updated every nine years or so (approx 512w). This makes the
> > binaries reproducible by default.
>
> What source file holds that timestamp?
libntp
> The build epoch has been replaced with a hardcoded timestamp which will be
> manually updated every nine years or so (approx 512w). This makes the
> binaries reproducible by default.
What source file holds that timestamp?
Where is it used?
One place is the version string. Where else?
--
T
On Wed, Jun 30, 2021, at 5:17 AM Hal Murray via devel wrote:
>
>
> e...@thyrsus.com said:
> > The remaining blocker is that the NTP packet format would need to be
> > redesigned.
>
> No, we just have to play the wrap around game when converting from network
> time to unix time. If the network tim
e...@thyrsus.com said:
> The remaining blocker is that the NTP packet format would need to be
> redesigned.
No, we just have to play the wrap around game when converting from network
time to unix time. If the network time is before the build time add 1<<32
seconds. And drop the high bits whe
Hal Murray via devel :
> There is the 32bit time_t problem. We've got a few more years.
I've been thinking forward about that. One of my objectives in the
big cleanup was to make the time width easier to change, and now it
would be internally. The remaining blocker is that the NTP packet
format
Sanjeev Gupta said:
> PS: My official reason for not using newer hardware is "I am making sure
> NTPsec and gpsd do not drop support for i386". :-)
There are 2 parts to that.
The first is does it run on 32 bit systems. The second is what distros
support i386.
The latter may
