bug-guix
[Top][All Lists]
Advanced

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

bug#27593: [PATCH v2] gnu: groff: Remove timestamps.


From: Ludovic Courtès
Subject: bug#27593: [PATCH v2] gnu: groff: Remove timestamps.
Date: Sun, 09 Jul 2017 21:51:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Marius Bakke <address@hidden> skribis:

> Danny Milosavljevic <address@hidden> 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’.





reply via email to

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