Alex Kost <alez...@gmail.com> skribis: > Ludovic Courtès (2015-10-20 02:09 +0300) wrote: > >> If we diff as explained in the doc below, we see that the Git >> discrepancies are due to timestamp in Perl’s POD files as well as >> sorted-by-inode-number ‘tclIndex’ files. For the Emacs modes, the >> problem is the autogenerated autoloads files, which include some sort of >> a timestamp as well. >> >> You’re welcome to help fix these issues! > > Thanks for the info! > > Those timestamps are inserted by `autoload-insert-section-header' and > we can avoid them by advising this function, for example, like this: > > (defun guix-autoload-no-timestamp (fun outbuf autoloads load-name file time) > (funcall fun outbuf autoloads load-name file 0)) > > (advice-add 'autoload-insert-section-header > :around 'guix-autoload-no-timestamp) > > So after putting this code into ‘emacs-generate-autoloads’ procedure > from (guix build emacs-utils) module, there will be zeros instead of > non-deterministic timestamps.
Great. > However this will fix only those packages, that use > ‘emacs-generate-autoloads’ directly or via ‘emacs-build-system’. But > there are also packages that generate autoloads on their own (for > example, 'emacs-w3m' or 'guix' itself). What to do for these ones? > > Perhaps we can make a special 'emacs-build' package (that will advise > ‘autoload-insert-section-header’ function somehow) and use it as an > input for emacs-packages, or are there other ways? What about patching Emacs directly? An upstreamable patch would be one that honors the ‘SOURCE_DATE_EPOCH’ variable¹. Alternately, a patch that simply changes ‘autoload-insert-section-header’ to always use zero as the timestamp would work as well, unless this would somehow break functionality. Thoughts? Thanks for looking into it, Ludo’. ¹ https://reproducible-builds.org/specs/source-date-epoch/
