GNU bug report logs - #22213
24.5; please allow specification or elimination of timestamp in autoloads

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22213 in the body.
You can then email your comments to 22213 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Bremner <david <at> tethera.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sat, 19 Dec 2015 14:52:10 -0400

I'm maintaining a tool in debian that installs package.el packages so
they can be managed by the system package system.

For various reasons (see http://reproducible-builds.org for motivations)
it is desirable if packages unpack into elpa directories in a
reproducible (i.e. bit identical every time) way. Unfortunately
update-directory-autoloads uses (current-time), which effectively means
this unpacking is different every time. It would be nice to be able to
override the time used, or perhaps eliminate the timestamp entirely. 

Currently I'm doing something like

    (defun dhelpa-autoload-insert-section-header (real-fun outbuf autoloads load-name file time)
      (funcall real-fun outbuf autoloads load-name file  pkg-time))
    (advice-add #'autoload-insert-section-header
		:around #'dhelpa-autoload-insert-section-header)
    (package--make-autoloads-and-stuff pkg-desc pkg-dir)
    (advice-remove #'autoload-insert-section-header
		   #'dhelpa-autoload-insert-section-header)

I'd prefer not to use advice here, since it makes things harder to
debug, and it's depending on the internals of
package--make-autoloads-and-stuff (of course calling the internal
function is itself not great, but that's an orthogonal problem).

In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.2)
 of 2015-10-24 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11703000
System Description:	Debian GNU/Linux testing (stretch)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_CA.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Circe Channel

Minor modes in effect:
  global-git-commit-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  tracking-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Mark set [2 times]
Sending via mail...
Sending...done
End of buffer [2 times]
widget-before-change: Text is read-only: "Attempt to change text outside editable field" [2 times]
End of search results.
Mark activated
call-interactively: Text is read-only
delete-backward-char: Text is read-only
Making completion list...

Load-path shadows:
/usr/share/emacs/24.5/site-lisp/elpa/markdown-mode-2.0snapshot78/markdown-mode hides /usr/share/emacs24/site-lisp/emacs-goodies-el/markdown-mode
/usr/share/org-mode/lisp/htmlize hides /usr/share/emacs24/site-lisp/emacs-goodies-el/htmlize
/home/bremner/.emacs.d/elpa/csv-mode-1.5/csv-mode hides /usr/share/emacs24/site-lisp/emacs-goodies-el/csv-mode
/usr/share/emacs/24.5/site-lisp/elpa/company-0.8.12/all hides /usr/share/emacs24/site-lisp/emacs-goodies-el/all
/usr/share/emacs/24.5/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs24/site-lisp/flim/hex-util hides /usr/share/emacs/24.5/lisp/hex-util
/usr/share/emacs24/site-lisp/flim/md4 hides /usr/share/emacs/24.5/lisp/md4
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/24.5/lisp/textmodes/rst
/usr/share/emacs24/site-lisp/org-mode/ob-table hides /usr/share/emacs/24.5/lisp/org/ob-table
/usr/share/emacs24/site-lisp/org-mode/ob-mscgen hides /usr/share/emacs/24.5/lisp/org/ob-mscgen
/usr/share/emacs24/site-lisp/org-mode/org-rmail hides /usr/share/emacs/24.5/lisp/org/org-rmail
/usr/share/emacs24/site-lisp/org-mode/org-pcomplete hides /usr/share/emacs/24.5/lisp/org/org-pcomplete
/usr/share/emacs24/site-lisp/org-mode/org-clock hides /usr/share/emacs/24.5/lisp/org/org-clock
/usr/share/emacs24/site-lisp/org-mode/ox-beamer hides /usr/share/emacs/24.5/lisp/org/ox-beamer
/usr/share/emacs24/site-lisp/org-mode/ob-sass hides /usr/share/emacs/24.5/lisp/org/ob-sass
/usr/share/emacs24/site-lisp/org-mode/ob-fortran hides /usr/share/emacs/24.5/lisp/org/ob-fortran
/usr/share/emacs24/site-lisp/org-mode/org-macs hides /usr/share/emacs/24.5/lisp/org/org-macs
/usr/share/emacs24/site-lisp/org-mode/org-entities hides /usr/share/emacs/24.5/lisp/org/org-entities
/usr/share/emacs24/site-lisp/org-mode/org-capture hides /usr/share/emacs/24.5/lisp/org/org-capture
/usr/share/emacs24/site-lisp/org-mode/ob-lilypond hides /usr/share/emacs/24.5/lisp/org/ob-lilypond
/usr/share/emacs24/site-lisp/org-mode/org-info hides /usr/share/emacs/24.5/lisp/org/org-info
/usr/share/emacs24/site-lisp/org-mode/org-bbdb hides /usr/share/emacs/24.5/lisp/org/org-bbdb
/usr/share/emacs24/site-lisp/org-mode/ob-js hides /usr/share/emacs/24.5/lisp/org/ob-js
/usr/share/emacs24/site-lisp/org-mode/ob-dot hides /usr/share/emacs/24.5/lisp/org/ob-dot
/usr/share/emacs24/site-lisp/org-mode/ob-ledger hides /usr/share/emacs/24.5/lisp/org/ob-ledger
/usr/share/emacs24/site-lisp/org-mode/ox-md hides /usr/share/emacs/24.5/lisp/org/ox-md
/usr/share/emacs24/site-lisp/org-mode/org-docview hides /usr/share/emacs/24.5/lisp/org/org-docview
/usr/share/emacs24/site-lisp/org-mode/ob-plantuml hides /usr/share/emacs/24.5/lisp/org/ob-plantuml
/usr/share/emacs24/site-lisp/org-mode/ob-awk hides /usr/share/emacs/24.5/lisp/org/ob-awk
/usr/share/emacs24/site-lisp/org-mode/ob-clojure hides /usr/share/emacs/24.5/lisp/org/ob-clojure
/usr/share/emacs24/site-lisp/org-mode/ob-screen hides /usr/share/emacs/24.5/lisp/org/ob-screen
/usr/share/emacs24/site-lisp/org-mode/ob-eval hides /usr/share/emacs/24.5/lisp/org/ob-eval
/usr/share/emacs24/site-lisp/org-mode/org-ctags hides /usr/share/emacs/24.5/lisp/org/org-ctags
/usr/share/emacs24/site-lisp/org-mode/org-attach hides /usr/share/emacs/24.5/lisp/org/org-attach
/usr/share/emacs24/site-lisp/org-mode/org-plot hides /usr/share/emacs/24.5/lisp/org/org-plot
/usr/share/emacs24/site-lisp/org-mode/org-id hides /usr/share/emacs/24.5/lisp/org/org-id
/usr/share/emacs24/site-lisp/org-mode/ob-gnuplot hides /usr/share/emacs/24.5/lisp/org/ob-gnuplot
/usr/share/emacs24/site-lisp/org-mode/ob-emacs-lisp hides /usr/share/emacs/24.5/lisp/org/ob-emacs-lisp
/usr/share/emacs24/site-lisp/org-mode/ob-makefile hides /usr/share/emacs/24.5/lisp/org/ob-makefile
/usr/share/emacs24/site-lisp/org-mode/ob-maxima hides /usr/share/emacs/24.5/lisp/org/ob-maxima
/usr/share/emacs24/site-lisp/org-mode/org-timer hides /usr/share/emacs/24.5/lisp/org/org-timer
/usr/share/emacs24/site-lisp/org-mode/ox-odt hides /usr/share/emacs/24.5/lisp/org/ox-odt
/usr/share/emacs24/site-lisp/org-mode/org-mouse hides /usr/share/emacs/24.5/lisp/org/org-mouse
/usr/share/emacs24/site-lisp/org-mode/org-agenda hides /usr/share/emacs/24.5/lisp/org/org-agenda
/usr/share/emacs24/site-lisp/org-mode/org-install hides /usr/share/emacs/24.5/lisp/org/org-install
/usr/share/emacs24/site-lisp/org-mode/org-bibtex hides /usr/share/emacs/24.5/lisp/org/org-bibtex
/usr/share/emacs24/site-lisp/org-mode/ob-scala hides /usr/share/emacs/24.5/lisp/org/ob-scala
/usr/share/emacs24/site-lisp/org-mode/ob-haskell hides /usr/share/emacs/24.5/lisp/org/ob-haskell
/usr/share/emacs24/site-lisp/org-mode/org-table hides /usr/share/emacs/24.5/lisp/org/org-table
/usr/share/emacs24/site-lisp/org-mode/ob-ditaa hides /usr/share/emacs/24.5/lisp/org/ob-ditaa
/usr/share/emacs24/site-lisp/org-mode/org-gnus hides /usr/share/emacs/24.5/lisp/org/org-gnus
/usr/share/emacs24/site-lisp/org-mode/org-eshell hides /usr/share/emacs/24.5/lisp/org/org-eshell
/usr/share/emacs24/site-lisp/org-mode/ob-picolisp hides /usr/share/emacs/24.5/lisp/org/ob-picolisp
/usr/share/emacs24/site-lisp/org-mode/org-mhe hides /usr/share/emacs/24.5/lisp/org/org-mhe
/usr/share/emacs24/site-lisp/org-mode/ox-texinfo hides /usr/share/emacs/24.5/lisp/org/ox-texinfo
/usr/share/emacs24/site-lisp/org-mode/ob-keys hides /usr/share/emacs/24.5/lisp/org/ob-keys
/usr/share/emacs24/site-lisp/org-mode/ob-octave hides /usr/share/emacs/24.5/lisp/org/ob-octave
/usr/share/emacs24/site-lisp/org-mode/org-protocol hides /usr/share/emacs/24.5/lisp/org/org-protocol
/usr/share/emacs24/site-lisp/org-mode/org-datetree hides /usr/share/emacs/24.5/lisp/org/org-datetree
/usr/share/emacs24/site-lisp/org-mode/ob-core hides /usr/share/emacs/24.5/lisp/org/ob-core
/usr/share/emacs24/site-lisp/org-mode/ob-lob hides /usr/share/emacs/24.5/lisp/org/ob-lob
/usr/share/emacs24/site-lisp/org-mode/ob-latex hides /usr/share/emacs/24.5/lisp/org/ob-latex
/usr/share/emacs24/site-lisp/org-mode/org-footnote hides /usr/share/emacs/24.5/lisp/org/org-footnote
/usr/share/emacs24/site-lisp/org-mode/org-w3m hides /usr/share/emacs/24.5/lisp/org/org-w3m
/usr/share/emacs24/site-lisp/org-mode/org-archive hides /usr/share/emacs/24.5/lisp/org/org-archive
/usr/share/emacs24/site-lisp/org-mode/org-faces hides /usr/share/emacs/24.5/lisp/org/org-faces
/usr/share/emacs24/site-lisp/org-mode/org-list hides /usr/share/emacs/24.5/lisp/org/org-list
/usr/share/emacs24/site-lisp/org-mode/ob-comint hides /usr/share/emacs/24.5/lisp/org/ob-comint
/usr/share/emacs24/site-lisp/org-mode/org-indent hides /usr/share/emacs/24.5/lisp/org/org-indent
/usr/share/emacs24/site-lisp/org-mode/ob-org hides /usr/share/emacs/24.5/lisp/org/ob-org
/usr/share/emacs24/site-lisp/org-mode/org-inlinetask hides /usr/share/emacs/24.5/lisp/org/org-inlinetask
/usr/share/emacs24/site-lisp/org-mode/org-compat hides /usr/share/emacs/24.5/lisp/org/org-compat
/usr/share/emacs24/site-lisp/org-mode/ob-io hides /usr/share/emacs/24.5/lisp/org/ob-io
/usr/share/emacs24/site-lisp/org-mode/org-mobile hides /usr/share/emacs/24.5/lisp/org/org-mobile
/usr/share/emacs24/site-lisp/org-mode/ob-scheme hides /usr/share/emacs/24.5/lisp/org/ob-scheme
/usr/share/emacs24/site-lisp/org-mode/ob-python hides /usr/share/emacs/24.5/lisp/org/ob-python
/usr/share/emacs24/site-lisp/org-mode/ox-html hides /usr/share/emacs/24.5/lisp/org/ox-html
/usr/share/emacs24/site-lisp/org-mode/ob-java hides /usr/share/emacs/24.5/lisp/org/ob-java
/usr/share/emacs24/site-lisp/org-mode/org-colview hides /usr/share/emacs/24.5/lisp/org/org-colview
/usr/share/emacs24/site-lisp/org-mode/ob-ruby hides /usr/share/emacs/24.5/lisp/org/ob-ruby
/usr/share/emacs24/site-lisp/org-mode/ox-latex hides /usr/share/emacs/24.5/lisp/org/ox-latex
/usr/share/emacs24/site-lisp/org-mode/ox hides /usr/share/emacs/24.5/lisp/org/ox
/usr/share/emacs24/site-lisp/org-mode/ob-ref hides /usr/share/emacs/24.5/lisp/org/ob-ref
/usr/share/emacs24/site-lisp/org-mode/org-macro hides /usr/share/emacs/24.5/lisp/org/org-macro
/usr/share/emacs24/site-lisp/org-mode/org hides /usr/share/emacs/24.5/lisp/org/org
/usr/share/emacs24/site-lisp/org-mode/ob-css hides /usr/share/emacs/24.5/lisp/org/ob-css
/usr/share/emacs24/site-lisp/org-mode/ob-shen hides /usr/share/emacs/24.5/lisp/org/ob-shen
/usr/share/emacs24/site-lisp/org-mode/org-irc hides /usr/share/emacs/24.5/lisp/org/org-irc
/usr/share/emacs24/site-lisp/org-mode/ob-sql hides /usr/share/emacs/24.5/lisp/org/ob-sql
/usr/share/emacs24/site-lisp/org-mode/org-element hides /usr/share/emacs/24.5/lisp/org/org-element
/usr/share/emacs24/site-lisp/org-mode/ob hides /usr/share/emacs/24.5/lisp/org/ob
/usr/share/emacs24/site-lisp/org-mode/ob-sqlite hides /usr/share/emacs/24.5/lisp/org/ob-sqlite
/usr/share/emacs24/site-lisp/org-mode/ox-publish hides /usr/share/emacs/24.5/lisp/org/ox-publish
/usr/share/emacs24/site-lisp/org-mode/ob-tangle hides /usr/share/emacs/24.5/lisp/org/ob-tangle
/usr/share/emacs24/site-lisp/org-mode/ob-lisp hides /usr/share/emacs/24.5/lisp/org/ob-lisp
/usr/share/emacs24/site-lisp/org-mode/ob-exp hides /usr/share/emacs/24.5/lisp/org/ob-exp
/usr/share/emacs24/site-lisp/org-mode/org-crypt hides /usr/share/emacs/24.5/lisp/org/org-crypt
/usr/share/emacs24/site-lisp/org-mode/ob-perl hides /usr/share/emacs/24.5/lisp/org/ob-perl
/usr/share/emacs24/site-lisp/org-mode/org-src hides /usr/share/emacs/24.5/lisp/org/org-src
/usr/share/emacs24/site-lisp/org-mode/ox-icalendar hides /usr/share/emacs/24.5/lisp/org/ox-icalendar
/usr/share/emacs24/site-lisp/org-mode/org-loaddefs hides /usr/share/emacs/24.5/lisp/org/org-loaddefs
/usr/share/emacs24/site-lisp/org-mode/ob-ocaml hides /usr/share/emacs/24.5/lisp/org/ob-ocaml
/usr/share/emacs24/site-lisp/org-mode/ox-ascii hides /usr/share/emacs/24.5/lisp/org/ox-ascii
/usr/share/emacs24/site-lisp/org-mode/ob-R hides /usr/share/emacs/24.5/lisp/org/ob-R
/usr/share/emacs24/site-lisp/org-mode/ob-C hides /usr/share/emacs/24.5/lisp/org/ob-C
/usr/share/emacs24/site-lisp/org-mode/org-version hides /usr/share/emacs/24.5/lisp/org/org-version
/usr/share/emacs24/site-lisp/org-mode/ob-asymptote hides /usr/share/emacs/24.5/lisp/org/ob-asymptote
/usr/share/emacs24/site-lisp/org-mode/org-habit hides /usr/share/emacs/24.5/lisp/org/org-habit
/usr/share/emacs24/site-lisp/org-mode/ob-matlab hides /usr/share/emacs/24.5/lisp/org/ob-matlab
/usr/share/emacs24/site-lisp/org-mode/ox-org hides /usr/share/emacs/24.5/lisp/org/ox-org
/usr/share/emacs24/site-lisp/org-mode/ox-man hides /usr/share/emacs/24.5/lisp/org/ox-man
/usr/share/emacs24/site-lisp/org-mode/ob-calc hides /usr/share/emacs/24.5/lisp/org/ob-calc
/usr/share/emacs24/site-lisp/org-mode/org-feed hides /usr/share/emacs/24.5/lisp/org/org-feed
/usr/share/emacs24/site-lisp/flim/sasl-cram hides /usr/share/emacs/24.5/lisp/net/sasl-cram
/usr/share/emacs24/site-lisp/flim/sasl hides /usr/share/emacs/24.5/lisp/net/sasl
/usr/share/emacs24/site-lisp/flim/sasl-digest hides /usr/share/emacs/24.5/lisp/net/sasl-digest
/usr/share/emacs24/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/24.5/lisp/net/sasl-ntlm
/usr/share/emacs24/site-lisp/flim/hmac-def hides /usr/share/emacs/24.5/lisp/net/hmac-def
/usr/share/emacs24/site-lisp/flim/hmac-md5 hides /usr/share/emacs/24.5/lisp/net/hmac-md5
/usr/share/emacs24/site-lisp/flim/ntlm hides /usr/share/emacs/24.5/lisp/net/ntlm
/usr/share/emacs24/site-lisp/auctex/prv-emacs hides /usr/share/emacs/site-lisp/auctex/prv-emacs
/usr/share/emacs24/site-lisp/auctex/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs24/site-lisp/auctex/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs24/site-lisp/auctex/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs24/site-lisp/auctex/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs24/site-lisp/auctex/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs24/site-lisp/auctex/tex hides /usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs24/site-lisp/auctex/context-en hides /usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs24/site-lisp/auctex/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs24/site-lisp/auctex/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs24/site-lisp/auctex/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf
/usr/share/emacs24/site-lisp/auctex/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite
/usr/share/emacs24/site-lisp/auctex/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs24/site-lisp/auctex/plain-tex hides /usr/share/emacs/site-lisp/auctex/plain-tex
/usr/share/emacs24/site-lisp/auctex/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs24/site-lisp/auctex/preview hides /usr/share/emacs/site-lisp/auctex/preview
/usr/share/emacs24/site-lisp/auctex/context hides /usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs24/site-lisp/auctex/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs24/site-lisp/auctex/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs24/site-lisp/auctex/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs24/site-lisp/auctex/latex hides /usr/share/emacs/site-lisp/auctex/latex

Features:
(shadow emacsbug whitespace lisp-mnt pp cperl-mode misearch
multi-isearch mm-uu mml2015 nnheader apropos eieio-opt speedbar sb-image
ezimage dframe debug debian-bug debian-changelog-mode org-capture macros
markdown-mode shr-color linum magit-version magit-blame magit-stash
magit-bisect magit-remote magit-commit magit-sequence magit magit-apply
magit-wip magit-log magit-diff smerge-mode magit-core magit-process
magit-popup magit-mode magit-git magit-section magit-utils git-commit
log-edit pcvs-util add-log with-editor tramp-sh tramp tramp-compat
auth-source eieio eieio-core tramp-loaddefs cl-macs trampver shell
js2-mode js2-old-indent js byte-opt bytecomp byte-compile cconv json
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs imenu sgml-mode org-clock view cal-china lunar solar
cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs cal-iso
vc-git org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
jka-compr image-mode dired org-bibtex bibtex org-bbdb org-w3m org-agenda
qp sort company-files company-oddmuse company-keywords company-etags
etags company-gtags company-dabbrev-code company-dabbrev company-capf
company-cmake company-ropemacs company-xcode company-clang
company-semantic company-eclim company-template company-css company-nxml
company-bbdb company gnus-util mail-extr mm-archive shr browse-url
mule-util edmacro kmacro notmuch-jump notmuch hl-line notmuch-message
notmuch-maildir-fcc notmuch-hello wid-edit notmuch-tree notmuch-show
notmuch-print notmuch-crypto notmuch-mua notmuch-address notmuch-company
notmuch-parser notmuch-wash diff-mode coolj notmuch-query goto-addr
icalendar diary-lib diary-loaddefs notmuch-tag crm notmuch-lib
notmuch-version cl gv message sendmail rfc822 mml mailabbrev mail-utils
gmm-utils mailheader mm-view mml-smime mml-sec smime password-cache dig
mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr cl-extra server tempo org-notmuch
org-element avl-tree org org-macro org-footnote org-pcomplete pcomplete
org-list org-faces org-entities time-date noutline outline org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys
ob-comint comint ansi-color ob-core ob-eval org-compat org-macs
org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs rx vc
vc-dispatcher circe-color-nicks color circe-chanop circe advice help-fns
lui-irc-colors irc make-tls-process tls lcs lui-format lui tracking
cl-loaddefs cl-lib shorten thingatpt paren help-mode flyspell ispell
ring circe-compat info easymenu finder-inf package epg-config debian-el
debian-el-loaddefs org-install emacs-goodies-el emacs-goodies-custom
emacs-goodies-loaddefs easy-mmode dpkg-dev-el dpkg-dev-el-loaddefs
dash-functional dash preview-latex tex-site auto-loads tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 1091474 152776)
 (symbols 48 51492 0)
 (miscs 40 12970 4097)
 (strings 32 164752 34578)
 (string-bytes 1 5101678)
 (vectors 16 61496)
 (vector-slots 8 1692108 45087)
 (floats 8 2751 2648)
 (intervals 56 73412 1686)
 (buffers 960 140)
 (heap 1024 85890 4651))

Message #8 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David Bremner <david <at> tethera.net>
Cc: 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sat, 19 Dec 2015 14:11:44 -0500

David Bremner wrote:

> Unfortunately update-directory-autoloads uses (current-time), which
> effectively means this unpacking is different every time.

Actually it doesn't, since 5200c2baefbc8:

http://lists.gnu.org/archive/html/emacs-diffs/2015-06/msg00357.html

So long as the timestamps of your inputs are fixed, the output should
not vary. I would be interested to hear if this solves the problem for you.

The only remaining issue I'm aware of is if there are generated files in
your inputs, they get a new timestamp every build, so the output
loaddefs file still varies. Eg this applies to the lisp/loaddefs.el file
in Emacs. I think the right solution for that might be to skip
no-update-autoloads files altogether (rather than recording them in the
trailing section of loaddefs), but I haven't looked at this properly.

Message #11 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: David Bremner <david <at> tethera.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sat, 19 Dec 2015 15:49:22 -0400

Glenn Morris <rgm <at> gnu.org> writes:

> David Bremner wrote:
>
>> Unfortunately update-directory-autoloads uses (current-time), which
>> effectively means this unpacking is different every time.
>
> Actually it doesn't, since 5200c2baefbc8:
>
> http://lists.gnu.org/archive/html/emacs-diffs/2015-06/msg00357.html

Aha, thanks for the pointer (and the work it points to).

>
> So long as the timestamps of your inputs are fixed, the output should
> not vary. I would be interested to hear if this solves the problem for you.

It changes the problem to one of managing timestamps of files. This is
probably easier than the current situation, but not completely trivial,
since e.g. both git checkout and build systems that copy files will
modify timestamps.

Cheers,

David

Message #14 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David Bremner <david <at> tethera.net>
Cc: 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sat, 19 Dec 2015 22:39:01 -0500

David Bremner wrote:

> It changes the problem to one of managing timestamps of files. This is
> probably easier than the current situation, but not completely trivial,
> since e.g. both git checkout and build systems that copy files will
> modify timestamps.

Point taken about VCS checkouts. Is that a case you need to deal with?
I was thinking of rebuilding a binary package from a given
source tarfile. But surely a build system must preserve source file
timestamps, for the sake of make?

Anyway, for an optional, non-default behaviour controlled by an
(env)var, two ideas come to mind.

1) Store no timestamp in the loaddefs file, and use the modtime of the
loaddefs file instead. In fact, I'm not sure why we don't just do it
this way...

The only reason I can come up with is parallel builds where the input
files may get modified during the time it takes to write the loaddefs
file. But if that could happen, then the generated loaddefs file might
be wrong, so the build system dependencies must be written to prevent this.
(Generated lisp files are almost always no-update-autoloads anyway.)
So after thinking about it, this explanation doesn't make sense.
So maybe I'm missing some other reason why it is how it is...?

2) Use md5sums instead of timestamps.
This would require the final "these files contained no autoloads"
section to be split up into one section per file, each with its own md5sum.
This method would slow down the (re)building of loaddefs (which is why
timestamps are used now most of the time). This would be more work to
implement, and make builds slower, but it would be strictly correct.


I'm guessing you don't care about in-place updating of a pre-existing
loaddefs after modifying the inputs, so 1) would be fine?

Message #17 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5; please allow specification or elimination of
 timestamp in autoloads
Date: Sun, 20 Dec 2015 09:29:18 +0000

[Message part 1 (text/plain, inline)]

David Bremner <david <at> tethera.net> schrieb am Sa., 19. Dez. 2015 um
19:56 Uhr:

>
> I'm maintaining a tool in debian that installs package.el packages so
> they can be managed by the system package system.
>
> For various reasons (see http://reproducible-builds.org for motivations)
> it is desirable if packages unpack into elpa directories in a
> reproducible (i.e. bit identical every time) way. Unfortunately
> update-directory-autoloads uses (current-time), which effectively means
> this unpacking is different every time. It would be nice to be able to
> override the time used, or perhaps eliminate the timestamp entirely.
>

My understanding of
https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00309.html is
that the goal is to make Emacs builds fully deterministic (even by default,
or as the only option). According to
https://reproducible-builds.org/docs/timestamps/ it would be great to avoid
timestamps in loaddef files (and everywhere else) entirely.

[Message part 2 (text/html, inline)]

Message #20 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: David Bremner <david <at> tethera.net>, Glenn Morris <rgm <at> gnu.org>
Cc: 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5; please allow specification or elimination of
 timestamp in autoloads
Date: Sun, 20 Dec 2015 09:33:13 +0000

[Message part 1 (text/plain, inline)]

David Bremner <david <at> tethera.net> schrieb am Sa., 19. Dez. 2015 um
20:50 Uhr:

> >
> > So long as the timestamps of your inputs are fixed, the output should
> > not vary. I would be interested to hear if this solves the problem for
> you.
>
> It changes the problem to one of managing timestamps of files. This is
> probably easier than the current situation, but not completely trivial,
> since e.g. both git checkout and build systems that copy files will
> modify timestamps.
>

Agreed, this basically means that you have to do a 'find -exec touch -d @0
'{}' +' or so before every build. That's doable, but increases complexity
and can be brittle if e.g. the filesystem doesn't have accurate mtimes or
something else modifies the input files. Preferably builds should only
depend on relative file names and file contents, not other kinds of
metadata.

[Message part 2 (text/html, inline)]

Message #23 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sun, 20 Dec 2015 19:38:19 -0500

Hi Stefan,

A question about the timestamps in loaddefs files:
Why do we need to store the last modtime for each input file?
Why can't we just compare current modtime of input file against that of
the loaddefs file itself? Is there a reason not to trust the latter?

Thanks.

Message #26 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sun, 20 Dec 2015 20:54:12 -0500

> A question about the timestamps in loaddefs files:
> Why do we need to store the last modtime for each input file?
> Why can't we just compare current modtime of input file against that of
> the loaddefs file itself? Is there a reason not to trust the latter?

Not sure, to tell you the truth.  Given the time it takes to generate
the loaddefs.el file, there's definitely a chance/risk that the file
gets modified between the time it's read by autoloads.el and the time
the corresponding loaddefs.el is written.

Not sure how serious this risk is, tho.  Worth a try.
What I suggested for the "reproducible build" was to do something
simpler (in terms of safety of the change): just strip the comments from
loaddefs.el during "make install".


        Stefan

Message #29 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Sun, 20 Dec 2015 21:20:33 -0500

 
Oh, I wonder if it is to allow us to only scan some of the input files
at a time (eg a single subdir)?

If the inputs can change during the time it takes us to write loaddefs,
then making autoloads twice in succession could change the output. IMO
that would be a bug in the build system (missing dependencies).

Message #32 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: David Bremner <david <at> tethera.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Mon, 21 Dec 2015 08:28:12 -0400

[Message part 1 (text/plain, inline)]

Glenn Morris <rgm <at> gnu.org> writes:

> David Bremner wrote:
>
>> It changes the problem to one of managing timestamps of files. This is
>> probably easier than the current situation, but not completely trivial,
>> since e.g. both git checkout and build systems that copy files will
>> modify timestamps.
>
> Point taken about VCS checkouts. Is that a case you need to deal with?

It seems pretty common for multi-file packages to have some kind of
staging process (e.g. "make elpa") in their build process (at least
company-mode, circe, magit, and projectile all do). This means the
production of tarball itself has timestamps based the VCS checkout.

Of course, in this case one could push the responsibility back onto the
package authors, but toolchain fixes seem better if possible (where
emacs is the toolchain here).

> I was thinking of rebuilding a binary package from a given
> source tarfile. But surely a build system must preserve source file
> timestamps, for the sake of make?

They only need to be preserved in a limited way to satisfy make; for
example in the staging process above, the copied files are not examined
by make after copying.

> 1) Store no timestamp in the loaddefs file, and use the modtime of the
> loaddefs file instead. In fact, I'm not sure why we don't just do it
> this way...

[snips]

> I'm guessing you don't care about in-place updating of a pre-existing
> loaddefs after modifying the inputs, so 1) would be fine?

Right, personally I think the installed files, including any generated
loaddefs (I'm guessing you're using loaddefs in a generic sense,
independent of the setting of GENERATED-AUTOLOADS-FILE?), should be
immutable.

Stefan's comment about stripping comments from the loaddefs files as
part of the install process is intriguing. Am I correct in thinking this
is pretty much equivalent to your option #1, in that the ";;;###"
section is only used for updating the loaddefs file?

Cheers,

David

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Mon, 21 Dec 2015 10:59:55 -0500

> A question about the timestamps in loaddefs files:
> Why do we need to store the last modtime for each input file?
> Why can't we just compare current modtime of input file against that of
> the loaddefs file itself? Is there a reason not to trust the latter?

Right, now I remember: for lisp/loaddefs.el I think the timestamps
wouldn't be needed and we could use the file's modtime instead.

But for autoloads.el in general this is not true because of the
existence of entry points such as update-file-autoloads which mean that
the autoloads file may be updated for some of the files it covers rather
than for all of them.


        Stefan

Message #38 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Thu, 07 Jan 2016 02:42:12 -0500

Stefan Monnier wrote:

> But for autoloads.el in general this is not true because of the
> existence of entry points such as update-file-autoloads which mean that
> the autoloads file may be updated for some of the files it covers rather
> than for all of them.

I think there are a lot of cases (the majority?) where we know that this
kind of partial update simply isn't going to happen.

I added an option to use the output file's modtime instead.
Seems to work ok for me, but I've left it using the previous method by
default.

Message #41 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Fri, 08 Jan 2016 02:41:49 -0500

>> But for autoloads.el in general this is not true because of the
>> existence of entry points such as update-file-autoloads which mean that
>> the autoloads file may be updated for some of the files it covers rather
>> than for all of them.
> I think there are a lot of cases (the majority?) where we know that this
> kind of partial update simply isn't going to happen.

Definitely.  I've never seen entry points like update-file-autoloads
being used.  I think autoloads.el would benefit greatly from getting rid
of such entry points (they significantly complicate the code, in my
experience, and they're very rarely used, if ever).


        Stefan

Message #44 received at 22213 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Glenn Morris <rgm <at> gnu.org>
Cc: David Bremner <david <at> tethera.net>, 22213 <at> debbugs.gnu.org
Subject: RE: bug#22213: 24.5; please allow specification or elimination of
 timestamp in autoloads
Date: Fri, 8 Jan 2016 06:53:52 -0800 (PST)

> >> But for autoloads.el in general this is not true because of the
> >> existence of entry points such as update-file-autoloads which
> >> mean that the autoloads file may be updated for some of the
> >> files it covers rather than for all of them.
> >
> > I think there are a lot of cases (the majority?) where we know
> > that this kind of partial update simply isn't going to happen.
> 
> Definitely.  I've never seen entry points like update-file-autoloads
> being used.  I think autoloads.el would benefit greatly from getting
> rid of such entry points (they significantly complicate the code, in
> my experience, and they're very rarely used, if ever).

(Caveat: I have not read this thread.)

I think they're useful.  I used to use them a lot, but in my
present situation I do not.  What makes you think that they
are not useful and are not used?

What's the problem with keeping this functionality for users
who might find it useful?  Why do they "significantly
complicate the code" more now than 10 or 20 or 30 years ago?
Why would they be less useful now than in the past?

Why is this different in principle from, say, being able to
create a tags file for only a given set of files or directories?

Message #49 received at 22213-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 22213-done <at> debbugs.gnu.org
Subject: Re: bug#22213: 24.5;
 please allow specification or elimination of timestamp in autoloads
Date: Wed, 25 May 2016 18:37:43 -0400

Version: 25.2

There's now a variable autoload-timestamps for this, defaulting to nil.
It will appear in whatever-next-release-from-master-is.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.