Hi Paul, [delayed follow-up] At 2022-11-26T18:32:09-0800, Paul Eggert wrote: > On 2022-11-26 13:56, G. Branden Robinson wrote: > > > A lot of the pieces are in place to make this work (Deri and I have > > wrangled over gropdf's diagnostic messages in this very area, but I > > think we reached consensus :D ), but it needs integration testing > > under multiple scenarios. > > In the meantime I filed an Ubuntu bug here: > > https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1998031 > > Unfortunately I don't have an Ubuntu 22.10 host that's public. The GCC > Compile Farm has a 22.04 host; perhaps that's good enough. I found some info about this and will have a look. https://gcc.gnu.org/wiki/CompileFarm > > I believe Solaris troff to be fossilized > > Yes and no. Solaris 10 is no longer supported after January 2024, so > if it and all the other traditional troffs die out by 2024 we can stop > worrying about this then. That may in fact prove out; the only _currently-maintained_ troffs I know of are groff, Heirloom Doctools troff (though it has slowed down) and neatroff. > Solaris 11.4, the only Oracle Solaris version that is planned to be > supported after January 2024, is based on groff 1.22.3 instead of on > traditional troff. See: > > https://docs.oracle.com/cd/E88353_01/html/E37839/troff-1.html > https://www.illumos.org/issues/12692 How about that! Be nice to get 'em moved past an 8-year-old release. I don't expect anyone at Oracle to care, but maybe the Illumos folks... > Oh, and one more thing. And this is relevant to TZDB! Ubuntu's groff > ignores the TZ environment variable; see: > > https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1908333 > > This is apparently due to Ubuntu's reproducible-build folks going off the > deep end. For example, on Ubuntu 22.10: > > $ echo $TZ; date; echo '\n[year]-\n[mo]-\n[dy] > \n[hours]:\n[minutes]:\n[seconds]' | groff -Tascii | grep . > > Sat Nov 26 18:30:29 PST 2022 > 2022-11-27 2:30:29 > > I hope upstream groff never does this.... Much as I have grievances with Ubuntu for many reasons--for its "BDFL" personality cult governance structure, for starters[1]--this one can be laid their upstream's doorstep, Debian. With which I am affiliated. $ echo TZ=$TZ; date; cat <<EOF | groff -Tascii | grep . ##> .af hours 00 ##> .af minutes 00 ##> .af seconds 00 ##> .nf ##> groff \n[.x].\n[.y].\n[.Y] ##> \n[year]-\n[mo]-\n[dy] \n[hours]:\n[minutes]:\n[seconds] ##> EOF TZ= Tue 13 Dec 2022 01:16:19 PM CST groff 1.22.4 2022-12-13 19:16:19 But I have good news. $ echo TZ=$TZ; date; cat <<EOF | ./build/test-groff -Tascii | grep . .af hours 00 .af minutes 00 .af seconds 00 .nf groff \n[.x].\n[.y].\n[.Y] \n[year]-\n[mo]-\n[dy] \n[hours]:\n[minutes]:\n[seconds] EOF TZ= Tue 13 Dec 2022 01:23:02 PM CST groff 1.23.0 2022-12-13 13:23:02 Speaking of NEWS, I'll quote the groff distribution's file of that name. o The semantics of the environment variable SOURCE_DATE_EPOCH (support for which was added in 1.22.4) to groff were not established with respect to time zone selection, prompting divergent interpretations; Debian and distributions derived from it have for several years patched groff to implicitly use UTC as the time zone when interpreting the current time (or SOURCE_DATE_EPOCH) as a local time. While a convenient and defensible choice for reproducible build efforts, it runs against the grain of user expectations. Systems programmers like time zone-invariant, monotonically increasing clocks; the broader user base usually prefers a clock that follows an applicable civil calendar. groff programs now reckon SOURCE_DATE_EPOCH with respect to the local time zone. Users of SOURCE_DATE_EPOCH may wish to also set the TZ environment variable. I hope you find this satisfactory. Let me know. Regards, Branden [1] Just like a _real_ software company!
Attachment:
signature.asc
Description: PGP signature
