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

[Kaz Kylheku]

On 2021-07-18 03:36, Guillaume Le Vaillant wrote:
> Hi Kaz,
>
> I tried your patch and it doesn't fix all the timestamps in the
> environment used to build Guix packages:
>  - Timestamps have the "YYYY-MM-DDTHH:MM:SSZ" format instead of
>    "YYYY-MM-DDTHH:MM:SS+00:00"
>  - There are two "...Date(D:YYYYMMDDHHMMSSZ..." timestamps after the 
> XML
>    block, although SOURCE_DATE_EPOCH is set to 1 in the environment

These are precisely the entries I was referring to in my other post.
In the Ubuntu environment, these are following SOURCE_DATE_EPOCH.

In fact, all the dates follow SOURCE_DATE_EPOCH. Even with my
hack commented out, if we do this:

  $ SOURCE_DATE_EPOCH=0 make txr-manpage.pdf
  ./txr checkman.txr txr.1
  tbl txr.1 | pdfroff -ww -man --no-toc - > txr-manpage.pdf
  ./pdfroff-eCdDwXuD8U/pdf29977.cmp:1: warning: macro `pdfhref' not 
defined
  txr.1:36: warning: number register `M2' not defined
  # [ $SOURCE_DATE_EPOCH ] && ./txr pdf-clobber-stamps.tl || true

the resulting dates are all set to 1970-01-01:

 $ strings txr-manpage.pdf | grep -E 'Mod|Crea'
 <rdf:Description rdf:about='uuid:9f558000-55ee-11bd-0000-096f2d10ec33' 
xmlns:xmp='http://ns.adobe.com/xap/1.0/'><xmp:ModifyDate>1970-01-01T00:00:00Z</xmp:ModifyDate>
  <xmp:CreateDate>1970-01-01T00:00:00Z</xmp:CreateDate>
  <xmp:CreatorTool>groff version 
1.22.3</xmp:CreatorTool></rdf:Description>
  /CreationDate(D:19700101000000Z00'00')
  /ModDate(D:19700101000000Z00'00')
  /Creator(groff version 1.22.3)>>endobj

Moreover, the uuid: strings are not changing between repetitions.

Either Ubuntu has a different upstream for these tools, or else they 
have
some patches (which would be worth stealing instead of repeating the 
work).

Moreover, if Ubuntu has patches for this, it might be getting them from
Debian.

> With the following modified 'pdf-clobber-stamps.tl' the document 
> becomes
> reproducible with Guix (but probably not in some other environments,
> depending on the timezone format):

This is interesting, not to mention an annoying variation. I wonder
where this timezone format is coming from? It doesn't seem to be any
local variable under LC_TIME.

It's also weird how the timezone is expressed with a colon in the
Ubuntu build, as -07:00.  I don't see anything in strftime for that,
looking at the latest Glibc documentation online.

In the Ghostscript code it seems that the latter dates: /CreationDate
and all, are the source of the values put into the XML.

The /CreationDate is being printed using a gs_sprintf call. Here is
the link to the Debian repo, inside a function called 
pdf_image_finish_file:

https://sources.debian.org/src/ghostscript/9.53.3%7Edfsg-7/devices/gdevpdfimg.c/?hl=670#L753

        gs_sprintf(CreationDate, 
"(D:%04d%02d%02d%02d%02d%02d%c%02d\'%02d\')",
            tms.tm_year + 1900, tms.tm_mon + 1, tms.tm_mday,
            tms.tm_hour, tms.tm_min, tms.tm_sec,
            timesign, timeoffset / 60, timeoffset % 60);


I found the code which converst the date with the colon in the timezone,
the function pdf_xmp_convert_time:

https://sources.debian.org/src/ghostscript/9.53.3%7Edfsg-7/devices/vector/gdevpdfe.c/#L222

It looks the same as in the ArtifexSoftware ghostpd upstream. It is 
ad-hoc
code not using strftime, which puts in the colon.

This behavior is conditional depending on the input, though.
There is a case in which it puts in a Z and terminates, resulting
(I am guessing) in the format seen on Guix:

    dt[19] = buf[14]; /* designator */
    if (dt[19] == 'Z')
        return 20;

The pdf_image_finish_function writes a Z if it is compiled with #ifdef 
CLUSTER.
This CLUSTER compile-time switch has to do with some "cluster testing" 
that
requires reproducible files.

It will also write a Z if it finds that the time offset is zero:

  #ifdef CLUSTER
        memset(&t, 0, sizeof(t));
        memset(&tms, 0, sizeof(tms));
        timesign = 'Z';
        timeoffset = 0;
  #else
        time(&t);
        tms = *gmtime(&t);
        tms.tm_isdst = -1;
        timeoffset = (int)difftime(t, mktime(&tms)); /* tz+dst in 
seconds */
        timesign = (timeoffset == 0 ? 'Z' : timeoffset < 0 ? '-' : '+');
        timeoffset = any_abs(timeoffset) / 60;
        tms = *localtime(&t);
  #endif

Aha, this may be what is going on in the Guix build: that the time 
offset has
been set to zero and so the 'Z' character is written; then the
conversion function to the other date format writes a 'Z' and quits.

I don't see where this code reacts to SOURCE_DATE_EPOCH like I'm seeing
on Ubuntu; maybe I'm looking at the wrote branch of the Debian repo,
or it really is Ubuntu who did that?

In any case, if we end up needing any aspect of my hack, I think I can 
make it
account for all the variations we can expect to see out of this code.

Cheers ...