GNU logs - #79082, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: Nicolas Graves <ngraves@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 23 Jul 2025 14:11:02 +0000
Resent-Message-ID: <handler.79082.B.17532798238040 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79082 <at> debbugs.gnu.org
Cc: Liliana Marie Prikler <liliana.prikler@HIDDEN>
From: Nicolas Graves <ngraves@HIDDEN>
Date: Wed, 23 Jul 2025 16:09:41 +0200
Message-ID: <87pldr2e3e.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=46.105.33.63; envelope-from=ngraves@HIDDEN;
 helo=3.mo562.mail-out.ovh.net
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)


Hi emacs,

I recently worked a bit on reproducibility which is not guaranteed in
particular in the profile dump.  I found that undeterminism during the
profile dump comes from two sources : calls to clock_gettime and
sysinfo.

clock_gettime is not that hard to patch using faketime, but it's called
multiple times so it'll be harder to find where in the codebase.

We don't have dedicated tools to patch sysinfo without compiling an
additional file an using the same LD_PRELOAD trick as faketime, but
there's actually an OK solution on the lisp side, IMHO (this is what I
propose for guix's emacs@HIDDEN, but it'd be great to add that on the next
release: 

(add-after 'unpack 'avoid-sysinfo-call-at-build-time
 (lambda _
  ;; This is a useful trick for reproducibility: when we configured
  ;; with --disable-build-details, (system-name) is nil at build
  ;; time on the lisp side.
  ;; Find those places with strace -k -e sysinfo.
  (substitute* "lisp/jit-lock.el"
    (("\\(condition-case nil \\(load-average\\) \\(error\\)\\)"
      all)
     (format #f "(and (system-name) ~a)" all)))))

It's only a single line change (with maybe a comment addition), please
proceed without my feedback if I don't answer, it doesn't deserve a
copyright citation.

-- 
Best regards,
Nicolas Graves

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Nicolas Graves <ngraves@HIDDEN>
Subject: bug#79082: Acknowledgement (30.1; [reproducibility] sysinfo call
 during profile dump)
Message-ID: <handler.79082.B.17532798238040.ack <at> debbugs.gnu.org>
References: <87pldr2e3e.fsf@HIDDEN>
X-Gnu-PR-Message: ack 79082
X-Gnu-PR-Package: emacs
Reply-To: 79082 <at> debbugs.gnu.org
Date: Wed, 23 Jul 2025 14:11:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 79082 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
79082: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79082
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: "Dr. Werner Fink" <werner@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 28 Jul 2025 14:14:02 +0000
Resent-Message-ID: <handler.79082.B79082.175371200727027 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Nicolas Graves <ngraves@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Mon, 28 Jul 2025 16:13:08 +0200
From: "Dr. Werner Fink" <werner@HIDDEN>
Message-ID: <aIeFeHn6cnm-OFAy@HIDDEN>
References: <87pldr2e3e.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="sqPu4wbGIuubbDeE"
Content-Disposition: inline
In-Reply-To: <87pldr2e3e.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>


--sqPu4wbGIuubbDeE
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Jul 2025 16:13:08 +0200
From: "Dr. Werner Fink" <werner@HIDDEN>
To: Nicolas Graves <ngraves@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org,
	Liliana Marie Prikler <liliana.prikler@HIDDEN>
Subject: Re: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call
 during profile dump

On 2025/07/23 16:09:41 +0200, Nicolas Graves wrote:
>=20
> Hi emacs,
>=20
> I recently worked a bit on reproducibility which is not guaranteed in
> particular in the profile dump.  I found that undeterminism during the
> profile dump comes from two sources : calls to clock_gettime and
> sysinfo.
>=20
> clock_gettime is not that hard to patch using faketime, but it's called
> multiple times so it'll be harder to find where in the codebase.
>=20
> We don't have dedicated tools to patch sysinfo without compiling an
> additional file an using the same LD_PRELOAD trick as faketime, but
> there's actually an OK solution on the lisp side, IMHO (this is what I
> propose for guix's emacs@HIDDEN, but it'd be great to add that on the next
> release:=20
>=20
> (add-after 'unpack 'avoid-sysinfo-call-at-build-time
>  (lambda _
>   ;; This is a useful trick for reproducibility: when we configured
>   ;; with --disable-build-details, (system-name) is nil at build
>   ;; time on the lisp side.
>   ;; Find those places with strace -k -e sysinfo.
>   (substitute* "lisp/jit-lock.el"
>     (("\\(condition-case nil \\(load-average\\) \\(error\\)\\)"
>       all)
>      (format #f "(and (system-name) ~a)" all)))))
>=20
> It's only a single line change (with maybe a comment addition), please
> proceed without my feedback if I don't answer, it doesn't deserve a
> copyright citation.

After some debugging with a helper function I've identified two
lisp objects, a Lisp Float which are set by the garbage collector,
and a Lisp Cons set by the initial lisp timestamp at startup.
Both are changing at every dump therefore avoid them or use
a fixed value at dump time.

During debugging I stumbled over some inconsistencies in
pdumper.c which are already fixed in upstream master branch.

Signed-off-by: Werner Fink <werner@HIDDEN>
---
 src/alloc.c   |    4 ++--
 src/pdumper.c |   10 +++++-----
 src/timefns.c |   34 ++++++++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+), 7 deletions(-)

--- src/alloc.c
+++ src/alloc.c	2025-07-10 10:54:56.217020919 +0000
@@ -6702,8 +6702,8 @@ garbage_collect (void)
   image_prune_animation_caches (false);
 #endif
=20
-  /* Accumulate statistics.  */
-  if (FLOATP (Vgc_elapsed))
+  /* Accumulate statistics, but not during dump to get reproducible pdmp i=
mages.  */
+  if (FLOATP (Vgc_elapsed) && !will_dump_p ())
     {
       static struct timespec gc_elapsed;
       gc_elapsed =3D timespec_add (gc_elapsed,
--- src/pdumper.c
+++ src/pdumper.c	2025-07-09 07:26:00.889706813 +0000
@@ -2140,9 +2140,9 @@ dump_interval_node (struct dump_context
   if (node->parent)
     dump_field_fixup_later (ctx, &out, node, &node->parent);
   if (node->left)
-    dump_field_fixup_later (ctx, &out, node, &node->parent);
+    dump_field_fixup_later (ctx, &out, node, &node->left);
   if (node->right)
-    dump_field_fixup_later (ctx, &out, node, &node->parent);
+    dump_field_fixup_later (ctx, &out, node, &node->right);
   DUMP_FIELD_COPY (&out, node, begin);
   DUMP_FIELD_COPY (&out, node, end);
   DUMP_FIELD_COPY (&out, node, limit);
@@ -2213,9 +2213,9 @@ dump_finalizer (struct dump_context *ctx
   /* Do _not_ call dump_pseudovector_lisp_fields here: we dump the
      only Lisp field, finalizer->function, manually, so we can give it
      a low weight.  */
-  dump_field_lv (ctx, &out, finalizer, &finalizer->function, WEIGHT_NONE);
-  dump_field_finalizer_ref (ctx, &out, finalizer, &finalizer->prev);
-  dump_field_finalizer_ref (ctx, &out, finalizer, &finalizer->next);
+  dump_field_lv (ctx, out, finalizer, &finalizer->function, WEIGHT_NONE);
+  dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->prev);
+  dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->next);
   return finish_dump_pvec (ctx, &out->header);
 }
=20
--- src/timefns.c
+++ src/timefns.c	2025-07-11 07:32:33.928031852 +0000
@@ -600,6 +600,40 @@ make_lisp_time (struct timespec t)
 Lisp_Object
 timespec_to_lisp (struct timespec t)
 {
+  if (will_dump_p())	/* Use provided epoch at dump to get reproducible pdm=
p images */
+    {
+      char *epoch;
+      epoch =3D secure_getenv("SOURCE_DATE_EPOCH");
+      if (epoch)
+        {
+          char *endptr;
+          const char env[] =3D "Environment variable SOURCE_DATE_EPOCH: ";
+          errno =3D 0;
+          t.tv_sec =3D strtoull(epoch, &endptr, 10);
+          if ((errno =3D=3D ERANGE && (t.tv_sec =3D=3D ULLONG_MAX || t.tv_=
sec =3D=3D 0)) ||\
+              (errno !=3D 0 && t.tv_sec =3D=3D 0))
+            {
+              fprintf(stderr, "%s strtoull: %m\n", env);
+              exit(EXIT_FAILURE);
+            }
+          if (endptr =3D=3D epoch)
+            {
+              fprintf(stderr, "%s No digits were found: %s\n", env, endptr=
);
+              exit(EXIT_FAILURE);
+            }
+          if (*endptr !=3D '\0')
+            {
+              fprintf(stderr, "%s Trailing garbage: %s\n", env, endptr);
+              exit(EXIT_FAILURE);
+            }
+          if (t.tv_sec > ULONG_MAX)
+            {
+              fprintf(stderr, "%s value must be smaller than or equal to %=
lu but was found to be: %ld \n", env, ULONG_MAX, t.tv_sec);
+              exit(EXIT_FAILURE);
+            }
+          t.tv_nsec =3D 0ULL;
+        }
+    }
   return Fcons (timespec_ticks (t), timespec_hz);
 }
=20

--sqPu4wbGIuubbDeE
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmiHhXQsFIAAAAAAFQAO
cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay7Y
IQ/8DS4Qm+LY1u6InZbjlwyeGrNnhLAC1Oxiytm42Wm5kxkyjLoMJ1pbYICmU1BX
/CJcwpah+X0bLMVmh5Sy/HalWQ0redkdZ+Z60q3elj86FhspzMducv9CaEujHvtp
BnR/NIirRBd3fhwEkt3isNgOxl5fIX768fjAmDyx6bX/RGUaUdbnDVcfeHbiwrvl
A67Ij2xc3nkW40uX3Fl90grBY1WZmKvwJMk2KEO1tDWeVerMPxFicFhxIaQJ3WRa
40d0QBuBF3HNnY/azn1jWLdIZVYCFimmC99/F7h8M9bkQGaY4ThwOT0xKMC4mdzb
ob7er3eUVkkrUYYexTMuf0SVqO4VBYkFTU7nXC68YXkLQzSllkfLpqNQ13Lfm4nB
A37Xy6sqGZV4O4upVRIwjbQku9+cwoGDrSddG44RQkU/vJU4JlZl+2t2JZIPIJSG
wk4g6Gpu2P5NCHNK1amMk1VUxJQ1n0Kyzi/7dv6gDdQEQIy7JPUYBKlI04Vn1Eke
uDCOwdfZdeZ3A0FKhBnSnvE+Hu6bBCUJ4OXiu8Z2rCIiyfBRW7055qLeYsnv3w34
juncqPgCPkjczbXBFiigU/uN5F32nbzV1vrQNfvtjbTol3JbyVYDjmJ+1Qu8sJul
pqSFMQKf9F83HlvR16M/Uux1RToKn/IU0YhaaPJoLQPqZhM=
=1KpD
-----END PGP SIGNATURE-----

--sqPu4wbGIuubbDeE--

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 28 Jul 2025 14:59:02 +0000
Resent-Message-ID: <handler.79082.B79082.17537147285426 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Dr. Werner Fink" <werner@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org, ngraves@HIDDEN, liliana.prikler@HIDDEN
Date: Mon, 28 Jul 2025 17:58:15 +0300
Message-Id: <86a54oxszc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <aIeFeHn6cnm-OFAy@HIDDEN> (werner@HIDDEN)
References: <87pldr2e3e.fsf@HIDDEN> <aIeFeHn6cnm-OFAy@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Cc: 79082 <at> debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler@HIDDEN>
> Date: Mon, 28 Jul 2025 16:13:08 +0200
> From: "Dr. Werner Fink" <werner@HIDDEN>
> 
> > Hi emacs,
> > 
> > I recently worked a bit on reproducibility which is not guaranteed in
> > particular in the profile dump.  I found that undeterminism during the
> > profile dump comes from two sources : calls to clock_gettime and
> > sysinfo.
> > 
> > clock_gettime is not that hard to patch using faketime, but it's called
> > multiple times so it'll be harder to find where in the codebase.
> > 
> > We don't have dedicated tools to patch sysinfo without compiling an
> > additional file an using the same LD_PRELOAD trick as faketime, but
> > there's actually an OK solution on the lisp side, IMHO (this is what I
> > propose for guix's emacs@HIDDEN, but it'd be great to add that on the next
> > release: 
> > 
> > (add-after 'unpack 'avoid-sysinfo-call-at-build-time
> >  (lambda _
> >   ;; This is a useful trick for reproducibility: when we configured
> >   ;; with --disable-build-details, (system-name) is nil at build
> >   ;; time on the lisp side.
> >   ;; Find those places with strace -k -e sysinfo.
> >   (substitute* "lisp/jit-lock.el"
> >     (("\\(condition-case nil \\(load-average\\) \\(error\\)\\)"
> >       all)
> >      (format #f "(and (system-name) ~a)" all)))))
> > 
> > It's only a single line change (with maybe a comment addition), please
> > proceed without my feedback if I don't answer, it doesn't deserve a
> > copyright citation.
> 
> After some debugging with a helper function I've identified two
> lisp objects, a Lisp Float which are set by the garbage collector,
> and a Lisp Cons set by the initial lisp timestamp at startup.
> Both are changing at every dump therefore avoid them or use
> a fixed value at dump time.
> 
> During debugging I stumbled over some inconsistencies in
> pdumper.c which are already fixed in upstream master branch.

Thanks.

However, in order for us to accept these patches, they must fulfill
the following conditions:

 . the special code which avoids causing the build to become not
   reproducible must be conditioned on an optional variable, or at
   least on some compile-time symbol (like, for example, something
   derived from --disable-build-details); and
 . the code changes should either be portable, or, if they are
   specific to GNU/Linux, they should be conditioned on an appropriate
   preprocessor macro to avoid compiling it on other platforms

> --- src/pdumper.c
> +++ src/pdumper.c	2025-07-09 07:26:00.889706813 +0000
> @@ -2140,9 +2140,9 @@ dump_interval_node (struct dump_context
>    if (node->parent)
>      dump_field_fixup_later (ctx, &out, node, &node->parent);
>    if (node->left)
> -    dump_field_fixup_later (ctx, &out, node, &node->parent);
> +    dump_field_fixup_later (ctx, &out, node, &node->left);
>    if (node->right)
> -    dump_field_fixup_later (ctx, &out, node, &node->parent);
> +    dump_field_fixup_later (ctx, &out, node, &node->right);

This code looks differently on master.

> @@ -2213,9 +2213,9 @@ dump_finalizer (struct dump_context *ctx
>    /* Do _not_ call dump_pseudovector_lisp_fields here: we dump the
>       only Lisp field, finalizer->function, manually, so we can give it
>       a low weight.  */
> -  dump_field_lv (ctx, &out, finalizer, &finalizer->function, WEIGHT_NONE);
> -  dump_field_finalizer_ref (ctx, &out, finalizer, &finalizer->prev);
> -  dump_field_finalizer_ref (ctx, &out, finalizer, &finalizer->next);
> +  dump_field_lv (ctx, out, finalizer, &finalizer->function, WEIGHT_NONE);
> +  dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->prev);
> +  dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->next);
>    return finish_dump_pvec (ctx, &out->header);

This is already in the code on master.

> --- src/timefns.c
> +++ src/timefns.c	2025-07-11 07:32:33.928031852 +0000
> @@ -600,6 +600,40 @@ make_lisp_time (struct timespec t)
>  Lisp_Object
>  timespec_to_lisp (struct timespec t)
>  {
> +  if (will_dump_p())	/* Use provided epoch at dump to get reproducible pdmp images */
> +    {
> +      char *epoch;
> +      epoch = secure_getenv("SOURCE_DATE_EPOCH");

secure_getenv is specific to glibc.  If we want to use it on other
platforms, we need to import the Gnulib secure_getenv module.

We should also make sure this change doesn't interfere with the build,
since we do have code in Emacs that manipulates time and is used
during the build.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: "Dr. Werner Fink" <werner@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Jul 2025 08:58:02 +0000
Resent-Message-ID: <handler.79082.B79082.175377946017111 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79082
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org, ngraves@HIDDEN, liliana.prikler@HIDDEN
Received: via spool by 79082-submit <at> debbugs.gnu.org id=B79082.175377946017111
          (code B ref 79082); Tue, 29 Jul 2025 08:58:02 +0000
Received: (at 79082) by debbugs.gnu.org; 29 Jul 2025 08:57:40 +0000
Received: from localhost ([127.0.0.1]:60297 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ugg9T-0004Rs-CM
	for submit <at> debbugs.gnu.org; Tue, 29 Jul 2025 04:57:40 -0400
Received: from smtp-out1.suse.de ([2a07:de40:b251:101:10:150:64:1]:38556)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <werner@HIDDEN>) id 1ugg9Q-0004RU-7Q
 for 79082 <at> debbugs.gnu.org; Tue, 29 Jul 2025 04:57:37 -0400
Received: from mydomainname.com (unknown
 [IPv6:2a07:de40:a101:3:21c:c0ff:fea4:1c14])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 12241219FC;
 Tue, 29 Jul 2025 08:57:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
 t=1753779448; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=OYkR2Auc9DuHfVc7aUzByX+pLAXR26HRZ1qQFjrAae8=;
 b=0hUoL5gzm/vhpfgai92IA3koWuQivZvmVeTmMG8hZB0Xq10TlBwt8RQfIpsey4HMi9T34o
 lemYS/9KQMIVlgKnYa8ML4VyIH559Q5UGLgpf9vr3rKN4Dc6YTej4Lsf0GBgJgqXcSkxXg
 x+/NkgtBze2eKGapWimy4FYlB6TMnHU=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
 s=susede2_ed25519; t=1753779448;
 h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=OYkR2Auc9DuHfVc7aUzByX+pLAXR26HRZ1qQFjrAae8=;
 b=98YVJZD/G1ayIT/Eqw+T2GfqEGZsp9JMuwkzCDkPDiW4HBV4Fbd7Zt5uJ6yaY8ZK5CfFiT
 fRWshSTYDj5plcDg==
Authentication-Results: smtp-out1.suse.de;
 dkim=pass header.d=suse.de header.s=susede2_rsa header.b=0hUoL5gz;
 dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="98YVJZD/"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
 t=1753779448; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=OYkR2Auc9DuHfVc7aUzByX+pLAXR26HRZ1qQFjrAae8=;
 b=0hUoL5gzm/vhpfgai92IA3koWuQivZvmVeTmMG8hZB0Xq10TlBwt8RQfIpsey4HMi9T34o
 lemYS/9KQMIVlgKnYa8ML4VyIH559Q5UGLgpf9vr3rKN4Dc6YTej4Lsf0GBgJgqXcSkxXg
 x+/NkgtBze2eKGapWimy4FYlB6TMnHU=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
 s=susede2_ed25519; t=1753779448;
 h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=OYkR2Auc9DuHfVc7aUzByX+pLAXR26HRZ1qQFjrAae8=;
 b=98YVJZD/G1ayIT/Eqw+T2GfqEGZsp9JMuwkzCDkPDiW4HBV4Fbd7Zt5uJ6yaY8ZK5CfFiT
 fRWshSTYDj5plcDg==
Received: from boole.nue2.suse.org (localhost [127.0.0.1])
 by mydomainname.com (8.18.1/8.18.1/SUSE Linux 0.8) with ESMTPS id
 56T8vPFf030616
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);
 Tue, 29 Jul 2025 10:57:27 +0200
Received: (from werner@localhost)
 by boole.nue2.suse.org (8.18.1/8.18.1/Submit) id 56T8vPep030615;
 Tue, 29 Jul 2025 10:57:25 +0200
Date: Tue, 29 Jul 2025 10:57:21 +0200
From: "Dr. Werner Fink" <werner@HIDDEN>
Message-ID: <aIiM9TCdXi4ZeylR@HIDDEN>
References: <87pldr2e3e.fsf@HIDDEN> <aIeFeHn6cnm-OFAy@HIDDEN>
 <86a54oxszc.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="kCFpZlrnZOPlKuGY"
Content-Disposition: inline
In-Reply-To: <86a54oxszc.fsf@HIDDEN>
X-GPG-Fingerprint: 1B06 BF5A 3829 90FB CBA2  75BE 50E9 0D55 1DC1 6B2E
X-MS-Reactions: disallow
X-Rspamd-Action: no action
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Spamd-Result: default: False [0.39 / 50.00]; BAYES_HAM(-3.00)[100.00%];
 HFILTER_HOSTNAME_UNKNOWN(2.50)[]; SIGNED_PGP(-2.00)[];
 RDNS_NONE(2.00)[]; SUSPICIOUS_RECIPS(1.50)[];
 FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_LONG(-1.00)[-1.000];
 MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain,text/x-patch];
 R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
 NEURAL_HAM_SHORT(-0.20)[-1.000]; MX_GOOD(-0.01)[];
 TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[];
 FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[];
 DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
 MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~];
 FREEMAIL_ENVRCPT(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[];
 TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2];
 FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[];
 FREEMAIL_CC(0.00)[ngraves.fr,debbugs.gnu.org,gmail.com];
 TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[4];
 MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[suse.de:+];
 DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,suse.de:dkim]
X-Spamd-Bar: /
X-Rspamd-Queue-Id: 12241219FC
X-Spam-Score: 0.39
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--kCFpZlrnZOPlKuGY
Content-Type: multipart/mixed; protected-headers=v1;
	boundary="uTmi/NnKNMfhq1qj"
Content-Disposition: inline
Date: Tue, 29 Jul 2025 10:57:21 +0200
From: "Dr. Werner Fink" <werner@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Cc: ngraves@HIDDEN, 79082 <at> debbugs.gnu.org, liliana.prikler@HIDDEN
Subject: Re: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility]
 sysinfo call during profile dump


--uTmi/NnKNMfhq1qj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2025/07/28 17:58:15 +0300, Eli Zaretskii wrote:
> Thanks.
>=20
> However, in order for us to accept these patches, they must fulfill
> the following conditions:
>=20
>  . the special code which avoids causing the build to become not
>    reproducible must be conditioned on an optional variable, or at
>    least on some compile-time symbol (like, for example, something
>    derived from --disable-build-details); and
>  . the code changes should either be portable, or, if they are
>    specific to GNU/Linux, they should be conditioned on an appropriate
>    preprocessor macro to avoid compiling it on other platforms
>=20
> > --- src/pdumper.c
> > +++ src/pdumper.c	2025-07-09 07:26:00.889706813 +0000
> > @@ -2140,9 +2140,9 @@ dump_interval_node (struct dump_context
> >    if (node->parent)
> >      dump_field_fixup_later (ctx, &out, node, &node->parent);
> >    if (node->left)
> > -    dump_field_fixup_later (ctx, &out, node, &node->parent);
> > +    dump_field_fixup_later (ctx, &out, node, &node->left);
> >    if (node->right)
> > -    dump_field_fixup_later (ctx, &out, node, &node->parent);
> > +    dump_field_fixup_later (ctx, &out, node, &node->right);
>=20
> This code looks differently on master.
>=20
> > @@ -2213,9 +2213,9 @@ dump_finalizer (struct dump_context *ctx
> >    /* Do _not_ call dump_pseudovector_lisp_fields here: we dump the
> >       only Lisp field, finalizer->function, manually, so we can give it
> >       a low weight.  */
> > -  dump_field_lv (ctx, &out, finalizer, &finalizer->function, WEIGHT_NO=
NE);
> > -  dump_field_finalizer_ref (ctx, &out, finalizer, &finalizer->prev);
> > -  dump_field_finalizer_ref (ctx, &out, finalizer, &finalizer->next);
> > +  dump_field_lv (ctx, out, finalizer, &finalizer->function, WEIGHT_NON=
E);
> > +  dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->prev);
> > +  dump_field_finalizer_ref (ctx, out, finalizer, &finalizer->next);
> >    return finish_dump_pvec (ctx, &out->header);
>=20
> This is already in the code on master.

I know as this was derived from master for 30.1.  In the attachment I've
skipped that and moved from will_dump_p() to !build_details, switched from
secure_getnev() to getenv(), and add a comment about SOURCE_DATE_EPOCH.

> > --- src/timefns.c
> > +++ src/timefns.c	2025-07-11 07:32:33.928031852 +0000
> > @@ -600,6 +600,40 @@ make_lisp_time (struct timespec t)
> >  Lisp_Object
> >  timespec_to_lisp (struct timespec t)
> >  {
> > +  if (will_dump_p())	/* Use provided epoch at dump to get reproducible=
 pdmp images */
> > +    {
> > +      char *epoch;
> > +      epoch =3D secure_getenv("SOURCE_DATE_EPOCH");
>=20
> secure_getenv is specific to glibc.  If we want to use it on other
> platforms, we need to import the Gnulib secure_getenv module.
>=20
> We should also make sure this change doesn't interfere with the build,
> since we do have code in Emacs that manipulates time and is used
> during the build.

That is the reason to use timespec_to_lisp() as these seems to be called
only once at start of the internal lisp engine. Without the attached patch
and the set SOURCE_DATE_EPOCH envvar there is always a changing timestamp

BUILD/emacs-30.1-build/emacs-30.1/src> od  -tx1 emacs.pdmp > x1
BUILD/emacs-30.1-build/emacs-30.1/src> diff -up x1 x2
--- x1  2025-07-29 08:38:00.204476936 +0000
+++ x2  2025-07-29 08:37:31.027684840 +0000
@@ -173419,7 +173419,7 @@
 15427560 00 50 00 03 00 00 00 40 30 2b 36 00 00 00 00 00
 15427600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 15427620 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
-15427640 fe 15 37 7a 29 b0 5a 61 02 28 6b ee 00 00 00 00
+15427640 1a 9b 1a d3 08 b0 5a 61 02 28 6b ee 00 00 00 00
 15427660 00 50 00 03 00 00 00 40 00 00 00 00 00 00 00 00
 15427700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 *

In my spec file I use the line

 SOURCE_DATE_EPOCH=3D"$(sed -n '/^----/n;s/ - .*$//;p;q' emacs.changes| dat=
e -u -f - +%%s)"
 export SOURCE_DATE_EPOCH

with the changelog which gets added to the spec file.

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

--uTmi/NnKNMfhq1qj
Content-Type: text/x-patch; charset=utf-8
Content-Description: emacs-30.1-pdumper.patch
Content-Disposition: attachment; filename=emacs-30.1-pdumper.patch
Content-Transfer-Encoding: quoted-printable

=46rom: Werner Fink <werner@HIDDEN>
Date: Fri, 11 Jul 2025 07:52:28 +0000
Subject: [PATCH 1/1] Avoid runtime changes during pdump for no build_detail=
s=20

After some debugging with a byte parser function two two
lisp objects ahd be identified, a Lisp Float which are set
by the gc, and Lisp Cons set be the initial lisp timestamp
at startup.  Both are changing at every dump therefore
avoid them or use a fixed value.

For the fixed initial lisp timestamp the environment variable
SOURCE_DATE_EPOCH is used if set.  For this --no-build-details
has to be given on the command line.  Compare with the help
for the configure option --disable-build-details.

Signed-off-by: Werner Fink <werner@HIDDEN>
---
 src/alloc.c   |    4 ++--
 src/timefns.c |   34 ++++++++++++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 2 deletions(-)

--- src/alloc.c
+++ src/alloc.c	2025-07-10 10:54:56.217020919 +0000
@@ -6702,8 +6702,8 @@ garbage_collect (void)
   image_prune_animation_caches (false);
 #endif
=20
-  /* Accumulate statistics.  */
-  if (FLOATP (Vgc_elapsed))
+  /* Accumulate statistics, but not during dump to get reproducible pdmp i=
mages.  */
+  if (FLOATP (Vgc_elapsed) && build_details)
     {
       static struct timespec gc_elapsed;
       gc_elapsed =3D timespec_add (gc_elapsed,
--- src/timefns.c
+++ src/timefns.c	2025-07-11 07:32:33.928031852 +0000
@@ -600,6 +600,40 @@ make_lisp_time (struct timespec t)
 Lisp_Object
 timespec_to_lisp (struct timespec t)
 {
+  if (!build_details)	/* Use provided epoch at dump to get reproducible pd=
mp images */
+    {
+      char *epoch;
+      epoch =3D getenv("SOURCE_DATE_EPOCH");
+      if (epoch)
+        {
+          char *endptr;
+          const char env[] =3D "Environment variable SOURCE_DATE_EPOCH: ";
+          errno =3D 0;
+          t.tv_sec =3D strtoull(epoch, &endptr, 10);
+          if ((errno =3D=3D ERANGE && (t.tv_sec =3D=3D ULLONG_MAX || t.tv_=
sec =3D=3D 0)) ||\
+              (errno !=3D 0 && t.tv_sec =3D=3D 0))
+            {
+              fprintf(stderr, "%s strtoull: %m\n", env);
+              exit(EXIT_FAILURE);
+            }
+          if (endptr =3D=3D epoch)
+            {
+              fprintf(stderr, "%s No digits were found: %s\n", env, endptr=
);
+              exit(EXIT_FAILURE);
+            }
+          if (*endptr !=3D '\0')
+            {
+              fprintf(stderr, "%s Trailing garbage: %s\n", env, endptr);
+              exit(EXIT_FAILURE);
+            }
+          if (t.tv_sec > ULONG_MAX)
+            {
+              fprintf(stderr, "%s value must be smaller than or equal to %=
lu but was found to be: %ld \n", env, ULONG_MAX, t.tv_sec);
+              exit(EXIT_FAILURE);
+            }
+          t.tv_nsec =3D 0ULL;
+        }
+    }
   return Fcons (timespec_ticks (t), timespec_hz);
 }
=20

--uTmi/NnKNMfhq1qj--

--kCFpZlrnZOPlKuGY
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmiIjPEsFIAAAAAAFQAO
cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay7B
kA//QjcFE21LvFX+eIWgREwW55yUxM0pS12VYjw19lVnegV2W59H6ceVT4T/p/z2
ZwYiCcGNwlkShcON+phYjY1fsYwksjsNSPPPEO5LNTkxdHgqVJrkMex9X+3n3MYW
uz2Faq+FVDOHt6AdxfEKXD+uA/LRet3GwMj64Mye5n1I0+9mDSS8EeJOkBFNyqGV
r99edYzPgoAPLaTBOWJETU3COVmNef5QR7kCi+ViKCYAakJu98hLHesKkuc64xzQ
7aPwpYMFnaFtf0fEeKSgRtRJIZevzTfm2J8XnslzhESQt8Qqx/WOAmegRA4vxCP5
Y8vgPFc4dKCvD6F7vRj5WYZvDLr2Wvg1Bz4hhB8DQjIItIK1cqPaRTq25dk36pBq
Sem1PvFhMjJv+XzxyJgZkGd0Z6H2SEXOEWM2U64yOCSR+kZWBN+Dr17T9BjvAjiS
CI6zDkRgEYTLvAoz3XVZ7U7hrUnQkXeO7hgRyzz7p3iJqOMXo6oNdtkGqI9WPy8K
+JK3pUHV6KLViPsUkqmol0CgtztbbC/BV+1l10/BwIOtrQwGWou7Ctle9LhkvTiz
yZvorgg1azZuFCI3XI27hbPL60XdzPNpXT80bRtdFwhthSJk21VoIMEi8UL7mEKl
iklL6WS/vYb+MrJZzAUKFkHTakkXYY9Wu0wkwBTig4dUx1M=
=U8aC
-----END PGP SIGNATURE-----

--kCFpZlrnZOPlKuGY--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Jul 2025 11:28:01 +0000
Resent-Message-ID: <handler.79082.B79082.175378843723195 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79082
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Dr. Werner Fink" <werner@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org, ngraves@HIDDEN, liliana.prikler@HIDDEN
Received: via spool by 79082-submit <at> debbugs.gnu.org id=B79082.175378843723195
          (code B ref 79082); Tue, 29 Jul 2025 11:28:01 +0000
Received: (at 79082) by debbugs.gnu.org; 29 Jul 2025 11:27:17 +0000
Received: from localhost ([127.0.0.1]:60926 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ugiUG-000622-Pp
	for submit <at> debbugs.gnu.org; Tue, 29 Jul 2025 07:27:17 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:55478)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1ugiUE-00061d-0M
 for 79082 <at> debbugs.gnu.org; Tue, 29 Jul 2025 07:27:14 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1ugiU7-0002uT-Fy; Tue, 29 Jul 2025 07:27:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=nzpt7zDudsyS8XkOPJUicY10Ra4iIqvgfXl1Uc3boIE=; b=Sdl/e3q2M8Hc
 ZJITELoWuV1y2iR8ojsQHT7wBgL6Ota50VnCBmsUE1+OmovJXAyFT0XZK0vTfYdtDzeTPQaK7Nl5I
 DyJEG/QdVT9xRHJW0xvwV14wOItE7fOMR4dBlNrmSu8Yg5bOOEcTFH85Gq9M+uMsShIKxmW2PLdCx
 9VURCFttwBAsfHtfMjIEQPssIMT0prV52oozHptLCbl8Jitp1TEbdpYeSdQsa0nzKUny758yyfey6
 EwErEQfuRSG3LnNXl96aIvhlTe0+VQf+AK3wqWYvbpDhe2FKZjE2PepP54JyMRurjXhd3R3pY1pSG
 Cqt4Snd8MrIOKGqDLCOgVw==;
Date: Tue, 29 Jul 2025 14:26:43 +0300
Message-Id: <86qzxzw83w.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <aIiM9TCdXi4ZeylR@HIDDEN> (werner@HIDDEN)
References: <87pldr2e3e.fsf@HIDDEN> <aIeFeHn6cnm-OFAy@HIDDEN>
 <86a54oxszc.fsf@HIDDEN> <aIiM9TCdXi4ZeylR@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 29 Jul 2025 10:57:21 +0200
> From: "Dr. Werner Fink" <werner@HIDDEN>
> Cc: ngraves@HIDDEN, 79082 <at> debbugs.gnu.org, liliana.prikler@HIDDEN
> 
> I know as this was derived from master for 30.1.  In the attachment I've
> skipped that and moved from will_dump_p() to !build_details, switched from
> secure_getnev() to getenv(), and add a comment about SOURCE_DATE_EPOCH.
> 
> > > --- src/timefns.c
> > > +++ src/timefns.c	2025-07-11 07:32:33.928031852 +0000
> > > @@ -600,6 +600,40 @@ make_lisp_time (struct timespec t)
> > >  Lisp_Object
> > >  timespec_to_lisp (struct timespec t)
> > >  {
> > > +  if (will_dump_p())	/* Use provided epoch at dump to get reproducible pdmp images */
> > > +    {
> > > +      char *epoch;
> > > +      epoch = secure_getenv("SOURCE_DATE_EPOCH");
> > 
> > secure_getenv is specific to glibc.  If we want to use it on other
> > platforms, we need to import the Gnulib secure_getenv module.
> > 
> > We should also make sure this change doesn't interfere with the build,
> > since we do have code in Emacs that manipulates time and is used
> > during the build.
> 
> That is the reason to use timespec_to_lisp() as these seems to be called
> only once at start of the internal lisp engine.

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.

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: "Dr. Werner Fink" <werner@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 29 Jul 2025 11:48:02 +0000
Resent-Message-ID: <handler.79082.B79082.17537896426855 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79082
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org, ngraves@HIDDEN, liliana.prikler@HIDDEN
Received: via spool by 79082-submit <at> debbugs.gnu.org id=B79082.17537896426855
          (code B ref 79082); Tue, 29 Jul 2025 11:48:02 +0000
Received: (at 79082) by debbugs.gnu.org; 29 Jul 2025 11:47:22 +0000
Received: from localhost ([127.0.0.1]:32784 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ugine-0001mI-8s
	for submit <at> debbugs.gnu.org; Tue, 29 Jul 2025 07:47:21 -0400
Received: from smtp-out2.suse.de ([195.135.223.131]:54088)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <werner@HIDDEN>) id 1uginZ-0001lr-SV
 for 79082 <at> debbugs.gnu.org; Tue, 29 Jul 2025 07:47:15 -0400
Received: from mydomainname.com (unknown
 [IPv6:2a07:de40:a101:3:21c:c0ff:fea4:1c14])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 4B0ED1F809;
 Tue, 29 Jul 2025 11:47:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
 t=1753789627; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=vU56K4AhAMe8HKawueGBZLGuxVKnTJr2LkE/AVMokfs=;
 b=J/7gU6hQ8eKDPtJPEoJJ0eSFCuDpvEr8Kd6TSVAcm4/OGFBsG3unJ39j1bfhOKgUMHSsWh
 SiMypba1pS+xOg5SMBcCWotEqPWgUyEtC2pT90F+PKBQXk2yMSXnBvcXBFIhXfqknpJFQq
 kHq7VpsC1HWIMtTyZnTWcQcndhBzgRQ=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
 s=susede2_ed25519; t=1753789627;
 h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=vU56K4AhAMe8HKawueGBZLGuxVKnTJr2LkE/AVMokfs=;
 b=1sQ9r/OC8ZYJKkV551mvQeap2PxJAuKmqDnJH2OYlddvETkrzaa7KC7rHp1MyzMKrViA63
 UC6jX/uCj2zmPhBw==
Authentication-Results: smtp-out2.suse.de;
 dkim=pass header.d=suse.de header.s=susede2_rsa header.b=qzS0nbZ9;
 dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=AGMgdt3w
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
 t=1753789626; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=vU56K4AhAMe8HKawueGBZLGuxVKnTJr2LkE/AVMokfs=;
 b=qzS0nbZ94vYx3XCI9ePr3U5lEBhwixS9xtbNZdOn0Tq8HaWMFcKSfM4KyYdckGUmyzQ/Og
 cvrXSUmT8WdYOHaRzUqQDdnOmgOtW189bKmvvAIKTOd9yKcPtmQSuVKo7uCC0L9WYmYmUn
 cdMwI7YRw8ukqH3tWeH6PgQCaHKKdG0=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
 s=susede2_ed25519; t=1753789626;
 h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=vU56K4AhAMe8HKawueGBZLGuxVKnTJr2LkE/AVMokfs=;
 b=AGMgdt3w3VeGg6Bu71nlCyjn8v1lIFOFZiW+a+RbvIfcSE6fc64mT8YmDDJvefcZd12Q+h
 PWBkOPiVvEJqpBCA==
Received: from boole.nue2.suse.org (localhost [127.0.0.1])
 by mydomainname.com (8.18.1/8.18.1/SUSE Linux 0.8) with ESMTPS id
 56TBl3Js017050
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);
 Tue, 29 Jul 2025 13:47:05 +0200
Received: (from werner@localhost)
 by boole.nue2.suse.org (8.18.1/8.18.1/Submit) id 56TBl3uh017049;
 Tue, 29 Jul 2025 13:47:03 +0200
Date: Tue, 29 Jul 2025 13:46:59 +0200
From: "Dr. Werner Fink" <werner@HIDDEN>
Message-ID: <aIi0t30ckGpDyorC@HIDDEN>
References: <87pldr2e3e.fsf@HIDDEN> <aIeFeHn6cnm-OFAy@HIDDEN>
 <86a54oxszc.fsf@HIDDEN> <aIiM9TCdXi4ZeylR@HIDDEN>
 <86qzxzw83w.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="RUFGPcxhYAblAwHJ"
Content-Disposition: inline
In-Reply-To: <86qzxzw83w.fsf@HIDDEN>
X-GPG-Fingerprint: 1B06 BF5A 3829 90FB CBA2  75BE 50E9 0D55 1DC1 6B2E
X-MS-Reactions: disallow
X-Spam-Level: 
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spamd-Result: default: False [0.39 / 50.00]; BAYES_HAM(-3.00)[99.99%];
 HFILTER_HOSTNAME_UNKNOWN(2.50)[]; RDNS_NONE(2.00)[];
 SIGNED_PGP(-2.00)[]; SUSPICIOUS_RECIPS(1.50)[];
 NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_NAME_HAS_TITLE(1.00)[dr];
 R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
 MIME_GOOD(-0.20)[multipart/signed,text/plain];
 NEURAL_HAM_SHORT(-0.20)[-1.000]; MX_GOOD(-0.01)[];
 DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519];
 FREEMAIL_ENVRCPT(0.00)[gmail.com];
 FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[];
 RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:a101:3:21c:c0ff:fea4:1c14:from];
 TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~];
 RCVD_TLS_LAST(0.00)[];
 FREEMAIL_CC(0.00)[ngraves.fr,debbugs.gnu.org,gmail.com];
 SPAMHAUS_XBL(0.00)[2a07:de40:a101:3:21c:c0ff:fea4:1c14:from];
 RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[];
 FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[];
 TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[4];
 MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[suse.de:+];
 DBL_BLOCKED_OPENRESOLVER(0.00)[mydomainname.com:helo, suse.de:dkim,
 boole.nue2.suse.org:mid, reproducible-builds.org:url]
X-Spamd-Bar: /
X-Rspamd-Queue-Id: 4B0ED1F809
X-Rspamd-Action: no action
X-Spam-Flag: NO
X-Spam-Score: 0.39
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)


--RUFGPcxhYAblAwHJ
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Jul 2025 13:46:59 +0200
From: "Dr. Werner Fink" <werner@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Cc: ngraves@HIDDEN, 79082 <at> debbugs.gnu.org, liliana.prikler@HIDDEN
Subject: Re: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility]
 sysinfo call during profile dump

On 2025/07/29 14:26:43 +0300, Eli Zaretskii wrote:
>=20
> 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.
>=20
> 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?

>=20
> > In my spec file I use the line
> >=20
> >  SOURCE_DATE_EPOCH=3D"$(sed -n '/^----/n;s/ - .*$//;p;q' emacs.changes|=
 date -u -f - +%%s)"
> >  export SOURCE_DATE_EPOCH
> >=20
> > with the changelog which gets added to the spec file.
>=20
> 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

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

--RUFGPcxhYAblAwHJ
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmiItLMsFIAAAAAAFQAO
cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay5A
GA/+PF9Bdv760LsTxmUcmbbvBu1Yvu6O72sCDx93nsShei+uHyAld0V0ZSl8dCGj
nGztnqQgrzGW4RHyuQCYmKLh1xjDmmi3lyJEol3uH2yuuH8f9GWaBaBo9eHi/tNV
IwOKpyV6VFnoq8twqjhdqwm10CPjoFKnK7VpeFtbMSv4osz0kYlcJssDwxr8Sl99
DREeQue1Mx0dkc/5xhQ/tagnDPzVAdTCJMg9+WK2JBrUXnBckq8hU63GoZ3daFjj
7GfRvs5yTDzobrgO4NVl5TT2AFQ2RHVwRFBAREAZ/IwX+JsBW6wkif6RNS6jynKo
ricKM92AqbOMk0EPJufxD1haL97DYAtD1FdM6nqihFqGBPDY0ixQ0CFGUDHaj3nd
mDRjisxWNPlCiz647i7Xm6Z50aIuPVt9Wgx4YLz73fhrDRx1CI6Jh+mS077g/5AU
0VNDPwU9gk/XxX868C3hmrsMSp/HHZQ68y2hFihTaMk9zrz+8IvebLElWOEh3ex7
JkLl5S33kZFRcITUS8xIxPD7iCwUVjU2tR3S6iomSF169fbHpZfRVWYEDiBYRmzW
5caKyw6YkB9c7rOXgqMV0dK5PDJo511HFApGGAi/XFQ8QgHmOMoJkEeymDJXu8BN
vYjXtpftX0sjI44NGukxTXsOo4zeQZ6ahrE7UWB0V59Gx+4=
=RZqd
-----END PGP SIGNATURE-----

--RUFGPcxhYAblAwHJ--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 30 Jul 2025 11:15:02 +0000
Resent-Message-ID: <handler.79082.B79082.175387409324675 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79082
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Dr. Werner Fink" <werner@HIDDEN>
Cc: 79082 <at> debbugs.gnu.org, ngraves@HIDDEN, liliana.prikler@HIDDEN
Received: via spool by 79082-submit <at> debbugs.gnu.org id=B79082.175387409324675
          (code B ref 79082); Wed, 30 Jul 2025 11:15:02 +0000
Received: (at 79082) by debbugs.gnu.org; 30 Jul 2025 11:14:53 +0000
Received: from localhost ([127.0.0.1]:39847 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uh4lo-0006Pt-Mv
	for submit <at> debbugs.gnu.org; Wed, 30 Jul 2025 07:14:53 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51640)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uh4ll-0006PT-6f
 for 79082 <at> debbugs.gnu.org; Wed, 30 Jul 2025 07:14:50 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uh4lc-00034O-GF; Wed, 30 Jul 2025 07:14:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=r355Y8Y+watMli0UdPjJN9vJE4oYuPEhsIlXwRnAOrY=; b=f0lbMz6CRnsD
 g1zWMPsgIAUVEmKd4S8kGWRQj6mt/b6MhUOveUG7aTiXzt5vZV4ECuiDhmATUDInF4D+NkicvMDQs
 /9IA7QGuYJKLxZ+zrvocGZTXBbQ/J6pcQ2p8jxlNjiFud98FlrLFGqkHXIAzPz0hw+xkvsBB0RB13
 W/zrtW9p0KQBBARKSekSE0i6ActgLciBMfRPkGJjlvHTy4gswLrvwfGtTiuRjwnJhjfUTM51ml3SQ
 ALLdkPzxt+prgBsSTEPyLVcjOiCtQIO4NjY743HugnNzh0MNkPoeaeRXG2ZvWsrvyrvWxlFvZ3MfK
 +Xo9tte/IE/gMeWh/fuvsg==;
Date: Wed, 30 Jul 2025 14:14:34 +0300
Message-Id: <86ldo6vskl.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <aIi0t30ckGpDyorC@HIDDEN> (werner@HIDDEN)
References: <87pldr2e3e.fsf@HIDDEN> <aIeFeHn6cnm-OFAy@HIDDEN>
 <86a54oxszc.fsf@HIDDEN> <aIiM9TCdXi4ZeylR@HIDDEN>
 <86qzxzw83w.fsf@HIDDEN> <aIi0t30ckGpDyorC@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

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

Last modified: Wed, 30 Jul 2025 11:30:01 UTC

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