GNU bug report logs - #79082
30.1; [reproducibility] sysinfo call during profile dump

Previous Next

Full log

View this message in rfc822 format

From: "Dr. Werner Fink" <werner <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79082 <at> debbugs.gnu.org, ngraves <at> ngraves.fr, liliana.prikler <at> gmail.com
Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Date: Tue, 29 Jul 2025 13:46:59 +0200

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

On 2025/07/29 14:26:43 +0300, Eli Zaretskii wrote:
> 
> I'm not sure we can rely on that.  Some future change might call it
> more than once, in which case it will return the same value and could
> break something.
> 
> So I would prefer making such changes where the time value is used in
> a way that it makes the build not reproducible, instead of changing a
> low-level function that can be used in other context.

Is there any way to remember which value will be stored in the final
(p)dump image?  Like set a mark/tag in the Lisp Cons or Lisp Float to
not to dump such values into the resulting (p)dump images?

> 
> > In my spec file I use the line
> > 
> >  SOURCE_DATE_EPOCH="$(sed -n '/^----/n;s/ - .*$//;p;q' emacs.changes| date -u -f - +%%s)"
> >  export SOURCE_DATE_EPOCH
> > 
> > with the changelog which gets added to the spec file.
> 
> Isn't this completely unportable?

Sorry but this is the defacto standard to get reproducible builds, see

  https://reproducible-builds.org/docs/source-date-epoch/

and any distribution depends on it. On how SOURCE_DATE_EPOCH is
determined is an other story.  I've choosen the latest changelog
entry as this is here the last change before a package gets
submitted to QA staging area.  Means no changes of the package
will results in a reproducible build on every rebuild.

Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

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

Previous Next

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