[bug#49517] [PATCH] gnu: txr: Build documentation and update to 265.

[Paul A. Patience]

Hi Guillaume,

On Sunday, July 18th, 2021 at 06:36, Guillaume Le Vaillant <glv@posteo.net> 
wrote:

> Hi Kaz,
>
> I tried your patch and it doesn't fix all the timestamps in the
> environment used to build Guix packages:

I had sent an email last night but accidentally only to Kaz. Here it is below:

On Saturday, July 17th, 2021 at 18:51, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2021-07-17 02:57, Guillaume Le Vaillant wrote:
>> When testing the patch to build the HTML and PDF documentation,
>> I noticed that the 'share/doc/txr-263/txr-manpage.pdf' file is not
>> reproducible. There are some timestamps and UUIDs in it that change at
>> each build (diffoscope output attached).

I've updated the first patch to fix this by setting GS_GENERATE_UUIDS
to 0, which seems to be the standard Guix way to patch groff's use of
Ghostscript.
It removes most of the date (i.e., the hours, minutes and seconds) and
the UUID, but leaves the year, month and day:

  $ xxd 
/gnu/store/h94iilsa2xsp2ymn3k9x3ckmvfjha731-txr-266/share/doc/txr-266/txr-manpage.pdf
 | grep -C 1 Date
  00231430: 702f 312e 302f 273e 3c78 6d70 3a4d 6f64  p/1.0/'><xmp:Mod
  00231440: 6966 7944 6174 653e 3230 3231 2d30 372d  ifyDate>2021-07-
  00231450: 3138 3c2f 786d 703a 4d6f 6469 6679 4461  18</xmp:ModifyDa
  --
  00231470: 6174 653e 3230 3231 2d30 372d 3138 3c2f  ate>2021-07-18</
  00231480: 786d 703a 4372 6561 7465 4461 7465 3e0a  xmp:CreateDate>.
  00231490: 3c78 6d70 3a43 7265 6174 6f72 546f 6f6c  <xmp:CreatorTool

Is this acceptable?
Otherwise we may have to resort to a variation of the method Kaz
mentioned, though it's probably better to fix the Ghostscript patches
implementing GS_GENERATE_UUIDS, because otherwise any package relying on
groff to make PDFs will suffer from this very problem.

> Thank you for your report. I don't see anything in the pdfroff
> documentation about getting rid of this.

The problem is in fact with Ghostscript [1].
Ghostscript is the program adding the metadata.

> 2. Is there some recommended practice with regard to some
>     ./configure option or environment/make variable to react to
>     for ensuring reproducible builds? So that is to say, suppose
>     I don't wish to do the above embedded XML cleaning, except
>     when building for a distro that strives for reproducibility.
>
>     For opting in to reproducibilty, should I again rely on
>     SOURCE_DATE_EPOCH and have the build react to it?

I think the goal of SOURCE_DATE_EPOCH is for projects such as TXR to
need do nothing, and rather have Guix arrange for the "builder"
applications (i.e., Ghostscript here) to produce reproducible outputs.
In this case with GS_GENERATE_UUIDS=0.
So I don't think TXR need change anything.

Since I had to make a change in one of the patches, I have added a third
patch (squeezed in between the other two) adjusting the installation of
the license files.
The three patches are attached.

(Kaz, if there's anything TXR should change, perhaps it is the target
directory of the license files, i.e., $(datadir) -> $(docdir).
I think it's more common in general to install license files into
/usr/share/doc/APP rather than /usr/share/APP -- at least, that's where
Guix installs them.
This would render the second attached patch unnecessary.)

Best regards,
Paul

[1]: https://bugs.ghostscript.com/show_bug.cgi?id=696765

0001-gnu-txr-Build-documentation.patch
Description: Text Data

0002-gnu-txr-Fix-license-installation.patch
Description: Text Data

0003-gnu-txr-Update-to-266.patch
Description: Text Data