bug-groff
[Top][All Lists]
Advanced

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

[bug #57218] [PATCH] Reproducible builds support is broken and embeds ti


From: G. Branden Robinson
Subject: [bug #57218] [PATCH] Reproducible builds support is broken and embeds timezone
Date: Wed, 21 Oct 2020 04:05:26 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #57218 (project groff):

                Severity:              3 - Normal => 5 - Blocker            
                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #2:

I nominate this as a blocker because the groff 1.23 release should be
reproducible.

> This patch should be incorporated upstream if possible. Was it ever proposed
here? Is it suitable for inclusion as-is?

No and no, not as far as I know.  Colin Watson is active on the groff mailing
list (and has committed to its repository), so I reckon he'd have brought it
forward if he thought it was ready.

The tricky part would seem to be this:

> (Note that this changes the semantics of \n[hours] etc., so may need further
work.)

If anything the above is understated; it affects the semantics of every
date-related register coarser than the second, I reckon.  

There are localtime offsets smaller than one hour; Australia perversely does
this, and as the great Christopher Hitchens pointed out:

"The time-zone difference between India and Pakistan, for example, is half an
hour.  That's a nicely irrational and arbitrary slice out of daily life.  In
Cyprus, the difference between the clocks in the Greek and Turkish sectors is
an hour--but it's the only in-country north-south time change that I am aware
of, and it operates on two sides of the same capital city."

The closer to New Year's Day you generate your document, the worse the
situation becomes.

That includes the traditional AT&T troff registers: \n[dw], \n[dm], \n[mo],
and \n[yr], plus the groff extensions \n[hours], \n[minutes], and \n[year].

(\n[yr] had a Y2K bug.)

I guess we could have a register \n[.utc] which is normally zero but is set to
1 if SOURCE_DATE_EPOCH is in the environment.

Thoughts?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57218>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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