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

Previous Next

Full log

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

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

> Date: Tue, 29 Jul 2025 13:46:59 +0200
> From: "Dr. Werner Fink" <werner <at> suse.de>
> Cc: ngraves <at> ngraves.fr, 79082 <at> debbugs.gnu.org, liliana.prikler <at> gmail.com
> 
> 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?

I thought you already knew that.  If not, how did you figure out that
timespec_to_lisp is the place where to make the change?

> > 
> > > 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.

Then I guess this will only work on Posix systems with Bash.  Too bad.

Previous Next

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