guix-devel
[Top][All Lists]
Advanced

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

Re: Timestamps in ...-autoloads.el files


From: Alex Kost
Subject: Re: Timestamps in ...-autoloads.el files
Date: Sat, 14 Nov 2015 14:32:08 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ludovic Courtès (2015-11-03 16:27 +0300) wrote:

> Alex Kost <address@hidden> skribis:
>
>> Ludovic Courtès (2015-10-21 19:55 +0300) wrote:
>>
>>> Alex Kost <address@hidden> skribis:
>>>
>>>> I like the idea to honor SOURCE_DATE_EPOCH, so I'm attaching a patch for
>>>> this.  But now I don't know how to make Guix set this variable during
>>>> the build process :-(  Need help.
>>>
>>> Ahem, eventually, we’ll have to set it in ‘gnu-build’ in (guix build
>>> gnu-build-system) in the next ‘core-updates’ cycle.
>>
>> So would it be as simple as this (?):
>>
>> diff --git a/guix/build/gnu-build-system.scm 
>> b/guix/build/gnu-build-system.scm
>> index ff7646b..92e15d1 100644
>> --- a/guix/build/gnu-build-system.scm
>> +++ b/guix/build/gnu-build-system.scm
>> @@ -576,6 +576,9 @@ in order.  Return #t if all the PHASES succeeded, #f 
>> otherwise."
>>    ;; Encoding/decoding errors shouldn't be silent.
>>    (fluid-set! %default-port-conversion-strategy 'error)
>>  
>> +  ;; Avoid non-determinism related to generated timestamps.
>> +  (setenv "SOURCE_DATE_EPOCH" "1")
>> +
>>    ;; The trick is to #:allow-other-keys everywhere, so that each procedure 
>> in
>>    ;; PHASES can pick the keyword arguments it's interested in.
>>    (every (match-lambda
>
> Yes, as simple as this.

Great, thanks!  I see that you used (setenv "SOURCE_DATE_EPOCH" "0") in
'tk-update' commit, so I also changed the value to "0".

>>> In the interim, we can set it in a phase of ‘emacs-build-system’, which
>>> would entail few rebuilds.
>>>
>>> WDYT?
>>
>> I think it is not so important to make a temporary workaround for
>> master.  What about just fixing it in core-updates?
>
> Sure, makes sense.  It’ll be several weeks before it is merged, though,
> but we can probably live with that.

So is it OK to push the attached patches to 'core-updates'?

>>>> +++ b/gnu/packages/patches/emacs-source-date-epoch.patch
>>>> @@ -0,0 +1,20 @@
>>>> +Honor SOURCE_DATE_EPOCH variable to avoid non-determinism in generated
>>>> +"autoloads" files.
>>>> +
>>>> +--- a/lisp/emacs-lisp/autoload.el
>>>> ++++ b/lisp/emacs-lisp/autoload.el
>>>> +@@ -378,8 +378,12 @@
>>>> +   "Insert the section-header line,
>>>> + which lists the file name and which functions are in it, etc."
>>>> +   (insert generate-autoload-section-header)
>>>> +-  (prin1 `(autoloads ,autoloads ,load-name ,file ,time)
>>>> +-  outbuf)
>>>> ++  (let* ((env  (getenv "SOURCE_DATE_EPOCH"))
>>>> ++         (time (if env
>>>> ++                   (seconds-to-time (string-to-number env))
>>>> ++                 time)))
>>>> ++    (prin1 `(autoloads ,autoloads ,load-name ,file ,time)
>>>> ++           outbuf))
>>>> +   (terpri outbuf)
>>>> +   ;; Break that line at spaces, to avoid very long lines.
>>>> +   ;; Make each sub-line into a comment.
>>>
>>> Could you also submit it upstream, Cc’ing guix-devel and
>>> address@hidden  Hopefully that is
>>> acceptable.  (I searched a bit but didn’t find a similar patch by the
>>> Debian Reproducible team, but patch-tracker.debian.org is unreachable.)
>>
>> I'm afraid it's a too hard task for me, sorry.  I wouldn't like to mail
>> to so many places.
>
> Or email only emacs-devel if you prefer.
>
> An experienced Emacs hacker like you shouldn’t have to be afraid of that.

After fighting with myself for all these days, I must admit I'm not
brave enough for this task yet, sorry.

Attachment: 0001-build-system-gnu-Set-SOURCE_DATE_EPOCH.patch
Description: Text Data

Attachment: 0002-gnu-emacs-Honor-SOURCE_DATE_EPOCH.patch
Description: Text Data


reply via email to

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