Re: Doubts about a typo fix

[G. Branden Robinson]

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!

signature.asc
Description: PGP signature