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

[Miguel Ángel Arruga Vivas]

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

As a general comment: v3 patch only define a macro and include the header into
xgettext.c and msginit.c, no other modification is needed and all the handling
has been moved to gnulib (patch included too for the sake of completeness.) 
The tests remain mostly the same, with the removal of the sleep at
xgettext-17, and the fixed timezone..

>From [comment #6 comment #6:]
> 1) What the "reproducible builds" initiative is about: See
https://reproducible-builds.org/docs/definition/ .
>
> The "artifacts" defined there is what gets installed through "make install"
and packaged as an installable package (rpm, deb, whatever) by the distro.
That definition of artifacts mentions distribution packages explicitly,
nowhere "installed".  Even rpm and deb can create source packages too, but
nowadays GNU tarballs are artifacts of that kind by themselves, as they are
generated from their corresponding VCS used for the actual development by make
dist.

> The "source code" defined there is a tarball, because GNU provides its
software through releases and tarballs, and for the vast majority of packages,
this is what the distros take as their inputs.
That may be a common case, but at least most of my gettext compilations start
from a git checkout, even when the one I usually use is the one compiled by
the distro or from a release when it isn't possible.  Isn't that your case
too?

Indeed the GPL <https://www.gnu.org/licenses/gpl-3.0.en.html> is very clear in
that respect:

The “source code” for a work means the preferred form of the work for
making modifications to it.

I'm not aware of any current project that generates and modify manually POT
files, nor it would be the scope of xgettext in that case.  From the same
paragraph of the GPL:

“Object code” means any non-source form of a work.

It can easily be interpreted that POT files emitted by xgettext, exactly the
same as en@quot.po by msginit, and unlike po files from translators, are
"object code" for the GPL because they are not used for modifications of the
work itself but subproducts of its generation, just like the .o files.

Note that tarballs of GNU software releases include object code, on purpose,
to not require maintainer dependencies as autotools, grammar parsers, vala,
texinfo, etc. for the compilation of that version.

> In this area, the en@quot.gmo and en@boldquot.gmo files are an issue, and
the solution I propose is that 'msginit --no-translator' omits the
PO-Revision-Date from the output.
As I said, they are symptoms, not the issue.  The impossibility of controlling
one of the implicit inputs (the time) is the issue here.

> 2) "As a software developer I'd like to be sure that anybody can reproduce
the distributed tarball from the sources used to generate it"
> 
> I guess you mean "as a software developer of a package that uses GNU gettext
for its po/ directory". [...] The "sources" in this case are a version control
repository (most likely).
> 
> In the current state of things, with issue 1) fixed, two tarballs produced
by different people will contain identical files, except for [...].
Sorry, they are identical or they are not: the return codes of diff are
different for exactly that reason.  The issue 1 fixed means that they are
identical given the same inputs: sources, build environment (including
SOURCE_DATE_EPOCH and TZ) and build instructions.

> Do we want to have it differently by default? No. The POT-Creation-Date
values in the *.pot and *.po files are important for the translator workflow.
As I said, I'm well aware of this, but nobody defines SOURCE_DATE_EPOCH on
their environment without a concrete objective, even less by default.

> Do we want the possibility for tarball builders to force a
"POT-Creation-Date: 1970-01-01 00:00:00" in all *.pot and *.po files? No. If
such a tarball gets in the hands of a translator, her workflow is negatively
impacted.
Of course it would impact the workflow negatively, but that date can be
modified anyway with sed -e 's,(POT-Creation-Date:)[^\\]*,\\1 1970-01-01
00:00+0000'.  I cannot understand the reason behind your concern, as their
suggested mechanism for git projects
<https://reproducible-builds.org/docs/source-date-epoch/#git> is:

SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)


> Should the POT-Creation-Date be replaced by something else that is not a
date? Since non-linear versioning control systems are in  use (e.g. git with
branches), people are sometimes using a 'git describe' output for the version
number. But for a translator, a version number "3.4-rc1" definitely makes more
sense than "3.4-217-ce814b" or - even worse - just "ce814b".
This is already encoded in the project version, something of the output that
already can be controlled unlike POT-Creation-Date.  The proposed mechanism
with git gets the best POT-Creation-Date you can expect based on the current
format---julian/gregorian based dates are "good enough" too, but that's
another social+cultural+political issue and not the one at hand.

> Should the POT-Creation-Date be replaced by a date that is not the current
date but instead reflects the latest modification to the version control
history? I am open to such a thing.
These patches allow exactly this without modifying the current build scripts
for any project.  Please try this with the patches applied, either v2 or
v3+gnulib:

cd /a/git/project/po
ts=`git log -1 --pretty=%ct`
gt=/compiled/gettext-tools/src
rm -f project.pot
PATH="$gt:$PATH" SOURCE_DATE_EPOCH=$ts make update-po
mv project.pot project.pot.v1
PATH="$gt:$PATH" SOURCE_DATE_EPOCH=$ts make update-po
diff project.pot project.pot.v1 || echo "Oops, something's broken"



(file #50464, file #50465)
    _______________________________________________________

Additional Item Attachment:

File name: v3-0001-xgettext-msginit-Honor-SOURCE_DATE_EPOCH-for-time.patch
Size:10 KB
   
<https://file.savannah.gnu.org/file/v3-0001-xgettext-msginit-Honor-SOURCE_DATE_EPOCH-for-time.patch?file_id=50464>

File name: 0001-source-date-epoch-New-module.patch Size:14 KB
   
<https://file.savannah.gnu.org/file/0001-source-date-epoch-New-module.patch?file_id=50465>



    _______________________________________________________

Reply to this item at:

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

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