bug-groff
[Top][All Lists]
Advanced

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

[bug #57218] [PATCH] Reproducible builds support is broken and embeds ti


From: G. Branden Robinson
Subject: [bug #57218] [PATCH] Reproducible builds support is broken and embeds timezone
Date: Tue, 22 Dec 2020 03:19:31 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #57218 (project groff):

             Assigned to:              bgarrigues => gbranden               

    _______________________________________________________

Follow-up Comment #10:

I'm attaching a diff of two back to back builds I did today with:


SOURCE_DATE_EPOCH=1608607664 CORES=3 make-groff


...where `make-groff` is a local script I have that essentially wraps the
following:


./bootstrap && \
    mkdir build && \
    cd build && \
    ../configure && \
    make -j $CORES && \
    make check && \
    make doc && \
    make distcheck


The attached diff is 542KiB.  If, however, I delete the diffs resulting from
pdfroff's different choices of temporary filenames, it shrinks to 5.3KiB.

We can literally solve 99% of our reproducibility problem by making pdfroff
use deterministic temporary file names.

I further find the following.

A. There are nondeterministic temporary file names in config.log.  I assume
this is a problem for GNU autoconf to solve.

B. groff.dvi differs.  Of TeX DVI, it has famously been observed that its
"wiki page...feels the need to specifically point out that “DVI is not a
document encryption format”"[1].  I propose not to undertake research of
this item until the next one is resolved.  In any event, this DVI file is
produced not by groff -Tdvi but by makeinfo, so if resolving (C) below doesn't
fix this as a side effect, it seems likely that this is GNU Texinfo's problem
to solve.

C. Log files created by pdfTeX query the system clock and embed a timestamp. 
I assume this is a problem for pdfTeX to solve.

D. The generated distribution tar archives (gzipped) differ.  As far as I can
tell from a quick inspection, the gunzipped tar files differ only in file
metadata, not a surprise given tar's purpose. GNU tar has a feature to support
SOURCE_DATE_EPOCH[2], so I assume that this detail of archive generation is a
problem for GNU automake to solve.

E. One test case log differs, appearing two places (the individual and
combined test logs).  The difference is in the number of the file descriptor
GNU Bash opens when using process substitution, a non-POSIX shell feature. 
Ingo has encouraged me to get rid of Bashisms in the test cases, and this item
of trouble is sufficient to motivate me to do so in the instant case.

Conclusions: (1) Adjusting pdfroff's temporary file naming will pay a big
dividend.  (2) Taking a Bashism out of one of our test cases (which I wrote)
will pay a small one.  (3) The rest are going to require effort from other
projects.

[1] https://yakshav.es/the-patron-saint-of-yakshaves/
[2] https://www.gnu.org/software/tar/manual/html_section/tar_33.html

(file #50541, file #50542)
    _______________________________________________________

Additional Item Attachment:

File name: groff-repro-build_2020-12-22.diff Size:541 KB
   
<https://file.savannah.gnu.org/file/groff-repro-build_2020-12-22.diff?file_id=50541>

File name: groff-repro-build_2020-12-22_pdfroff_trimmed.diff Size:5 KB
   
<https://file.savannah.gnu.org/file/groff-repro-build_2020-12-22_pdfroff_trimmed.diff?file_id=50542>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57218>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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