[bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH

[Miguel Ángel Arruga Vivas]

Follow-up Comment #5, bug #59658 (project gettext):

>From [comment #2 comment #2:]
> This is a bit complex. I claim there is a simpler solution.
>
> In https://savannah.gnu.org/bugs/?49654 I wrote:
> "The POT-Creation-Date is important information for a translator, so that
she knows whether to review the entire file or not."
>
> Similarly, the PO-Revision-Date is important information for a translator,
so that she knows whether she updated the file after she got a new POT file.
>
> But in this case (en@quot catalog), there is no translator. Therefore no
PO-Revision-Date is needed.
IMHO this doesn't address the main issue: the output of xgettext and msginit
cannot be easily generated again after one minute (xgettext) or after one year
(msginit) in the scenario you suggest---msginit also replaces the YEAR
template from the source header.  These tags are the symptom, not the actual
issue.

As a translator I consider these tags very useful, although from that POV the
date of the last update to the VCS is usually more meaningful and reproducible
than a timestamp of the make dist/update-po invocation on the maintainer
machine.  Only walking with that shoes I'd even bring back the old behavior of
msgfmt, perhaps as a flag, keeping POT-Creation-Date inside .mo files as far
as its contents are reproducible, to retain that traceability in the binary
file too; msgfmt-19 could easily be extended to cover that use case too (e.g.
--keep-pot-creation-date to keep the default since 0.20 or
--remove-pot-creation-date to revert to the old default.)

As a software developer I'd like to be sure that anybody can reproduce the
distributed tarball from the sources used to generate it: MO files generated
by msgfmt should be as reproducible as POT files generated by xgettext and PO
files generated msginit.

The usage of SOURCE_DATE_EPOCH satisfies both points of view (with extra
advantages) and doesn't trim any input data as should be expected.

>From [comment #3 comment #3:]
> Can you submit a Gnulib module for SOURCE_DATE_EPOCH handling?
I'm glad you ask.  I though about this while working on it, as any
time/localtime call introduce that kind of reproducibility problems.  Reading
gnulib's manual
<https://www.gnu.org/software/gnulib/manual/html_node/Contributing-to-Gnulib.html>
I see that at least one project has to use it.  GCC
<https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-common.c;h=0b348aec77b8262306b37d1e4a5de490ca293e8e;hb=HEAD#l8557>
has some code for it, which I'm using to discover missing points from my
implementation: errno, long vs long long...

Nonetheless, I guess that a library interface should allow client code to
identify issues with the variable as suggested by the specification, what do
you think about this interface?

/* Read the environment variable SOURCE_DATE_EPOCH into the provided
   time_t object.

   Return 0 when the value has been read successfully, or number of
   characters left to read (up to INT_MAX) at SOURCE_DATE_EPOCH if the
   number isn't well formed.

   Return -1 when the variable isn't defined or -2 when the variable
   is defined but empty.

   See https://reproducible-builds.org/specs/source-date-epoch/  */
int source_date_epoch_time (time_t *);

/* Like source_date_epoch_time but read into struct tm.  */
int source_date_epoch_tm (struct tm *);


It allows the client code to ignore any error like this:

if (source_date_epoch_time (&now) != 0)
  /* oops: SOURCE_DATE_EPOCH is not there, perhaps call time (&now),
     show a message, check errno...  */


Or to handle them:

switch (source_date_epoch_time (&now))
{
  case -2:
    /* Do the thing when it is defined but empty, fall through?  */
  case -1:
    /* Do the thing when it isn't defined.  */
    break;
  case 0:
    /* Do the thing when it is defined and OK.  */
    break;
  default:
    /* Exit with non-zero as suggested by the spec.  */
    exit (1);
}


Also, I've noticed that the common idiom is to define TZ together with
SOURCE_DATE_EPOCH, as gettext's copy of help2man
<https://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/man/help2man#n273>
does, even though the spec says that it must be treated always as UTC.  If
that assumption is made, the modifications to po_strftime can be removed and
we can forget about any issue regarding the localtime/gmtime because they will
return the same value.  If not, I suggest keeping the interface modification
from the latest patch
<https://savannah.gnu.org/bugs/download.php?file_id=50444>.

>From [comment #4 comment #4:]
> > Is this time requirement acceptable?
> A time requirement of 1 or 2 seconds is acceptable. A time requirement of 61
seconds is not; this is excessive.
That's the main issue with wall clock tests, they need an annoying amount of
time.  It would be worse for the msginit test, as a call to 'sleep 1y' would
have been indeed even less acceptable. :-)

Jokes aside, the test can be trimmed to the main functionality as msginit-5,
instead of depending on the wall clock to ensure it isn't used when
SOURCE_DATE_EPOCH is provided, but I preferred to err on the safe side and
provide the test with the full behavior just in case.

I'm preparing the patches based on these ideas, I hope they'll be available
soon.

    _______________________________________________________

Reply to this item at:

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

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