groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PROPOSAL] time zones and reproducible builds (was: How to make grof


From: Deri
Subject: Re: [PROPOSAL] time zones and reproducible builds (was: How to make groff use local timezone?)
Date: Mon, 21 Dec 2020 23:33:18 +0000

On Sunday, 20 December 2020 06:10:25 GMT G. Branden Robinson wrote:
> 2.  Switch output of date comments embedded by output drivers off by
>     default, and add a common option to reënable them.  Document this in
>     NEWS.
> 3a. Add a device-independent output command, something like "x
>     timestamp", which records the time gathered by input.cpp.
> 3b. Modify the HTML, PDF, and PostScript output drivers to initialize
>     their idea of the current time from this new command instead of
>     calling libgroff's `current_time()` themselves.
> 3c. At that point the only call site of `current_time()` will be
>     input.cpp.  Maybe the function should be moved out of the library.
> 

I may be misunderstanding something here, apologies if I am. Both grops and 
gropdf use the 
time given in SOURCE_DATE_EPOCH if it is present to embed in the meta-data. 
This was to 
assist in making reproducible builds. The coding of "current_time()" in 
curtime.cpp is also aware 
of this setting. So I thought the only problem was the sorting objects in the 
output file, for which 
we have a patch.

Am I missing something, or are 2 and 3 required to create reproducible builds?

In cases where reproducible builds are not necessary having the output drivers 
embed the time 
when they actually ran can be useful. Consider the case where multiple -Z 
produced groff files, 
produced at different times, are combined into one gropdf run. The only 
sensible time to include 
in the meta-data is the time the pdf was created, why lose potentially useful 
information?

Cheers

Deri



reply via email to

[Prev in Thread] Current Thread [Next in Thread]