[Top][All Lists]

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

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

From: Kaz Kylheku
Subject: [bug#49517] [PATCH] gnu: txr: Build documentation and update to 265.
Date: Sun, 18 Jul 2021 13:27:18 -0700
User-agent: Roundcube Webmail/0.9.2

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
- 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 || 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=''><xmp:ModifyDate>1970-01-01T00:00:00Z</xmp:ModifyDate>
<xmp:CreatorTool>groff version 1.22.3</xmp:CreatorTool></rdf:Description>
  /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

With the following modified '' 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:

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:

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;
        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);

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 ...

reply via email to

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