Marius Bakke <mba...@fastmail.com> skribis: > Danny Milosavljevic <dan...@scratchpost.org> writes: > >> Fixes <https://bugs.gnu.org/27593>. >> >> * gnu/packages/groff.scm (groff)[source]: Remove timestamps. >> --- >> gnu/packages/groff.scm | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/gnu/packages/groff.scm b/gnu/packages/groff.scm >> index 46e1ccf23..1a74194a6 100644 >> --- a/gnu/packages/groff.scm >> +++ b/gnu/packages/groff.scm >> @@ -40,7 +40,23 @@ >> (uri (string-append "mirror://gnu/groff/groff-" version >> ".tar.gz")) >> (sha256 (base32 >> - >> "1998v2kcs288d3y7kfxpvl369nqi06zbbvjzafyvyl3pr7bajj1s")))) >> + >> "1998v2kcs288d3y7kfxpvl369nqi06zbbvjzafyvyl3pr7bajj1s")) >> + (modules '((guix build utils))) >> + (snippet >> + '(begin >> + (substitute* "mdate.sh" >> + (("^LANGUAGE=") " >> + >> +echo \"1 Jan 1970\" >> +exit 0 >> + >> +")) > > It would be more obvious what's going on if we substitute the "mdate.sh" > invocation from the Makefile instead. OTOH, this is more > future-proof. No strong opinion, but feels a bit "hacky". > > Note that you can use \n here. > >> + (substitute* '("src/devices/grops/ps.cpp" >> + "src/devices/grohtml/post-html.cpp" >> + "src/roff/troff/input.cpp") >> + (("time\\(0\\)") "0")) >> + (substitute* "src/devices/gropdf/gropdf.pl" >> + (("\\(time\\)") "(0)")))))) > > Are all of these really a cause of indeterminism in the build process? > It looks like this could make "legitimate" uses of groff return epoch 0 > at runtime, I'm not sure if that is okay. > > Which output files are fixed by these substitutions? Are there other > ways to deal with the indeterminism, e.g. substitute them in place?
Sometimes it’s better to make such changes available as a .patch file so that we can more clearly see from the context that we’re patching the right thing. Perhaps that’s one such case here. BTW, looking at issues.yml in git://git.debian.org/git/reproducible/notes.git leads me to: https://wiki.debian.org/ReproducibleBuilds/TimestampsInDocumentationGeneratedByGroff Debian has a SOURCE_DATE_EPOCH patch: http://sources.debian.net/patches/groff/1.22.3-9/source-date-epoch.patch/ Perhaps we could just use that? That way, the default behavior of groff would remained unchanged. Apparently upstream wasn’t convinced by the idea of SOURCE_DATE_EPOCH, so we could also restart the discussion with upstream in parallel. However, it would be nice to commit this groff change quickly so we can go on with core-updates builds. :-) Thoughts? Ludo’.
