From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Nicolas Graves Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Jul 2025 14:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 79082@debbugs.gnu.org Cc: Liliana Marie Prikler X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17532798238040 (code B ref -1); Wed, 23 Jul 2025 14:11:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Jul 2025 14:10:23 +0000 Received: from localhost ([127.0.0.1]:50544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ueaAo-00025a-OT for submit@debbugs.gnu.org; Wed, 23 Jul 2025 10:10:23 -0400 Received: from lists.gnu.org ([2001:470:142::17]:44732) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ueaAl-0001zV-Av for submit@debbugs.gnu.org; Wed, 23 Jul 2025 10:10:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ueaAY-0004uQ-CU for bug-gnu-emacs@gnu.org; Wed, 23 Jul 2025 10:10:10 -0400 Received: from 3.mo562.mail-out.ovh.net ([46.105.33.63]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ueaAS-0002hd-96 for bug-gnu-emacs@gnu.org; Wed, 23 Jul 2025 10:10:04 -0400 Received: from director2.derp.mail-out.ovh.net (director2.derp.mail-out.ovh.net [79.137.60.36]) by mo562.mail-out.ovh.net (Postfix) with ESMTPS id 4bnGGt6Mcjz1yLR; Wed, 23 Jul 2025 14:09:42 +0000 (UTC) Received: from director2.derp.mail-out.ovh.net (director2.derp.mail-out.ovh.net. [127.0.0.1]) by director2.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Wed, 23 Jul 2025 14:09:42 +0000 (UTC) Received: from mta7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.54.155]) by director2.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4bnGGt51w9z1xwp; Wed, 23 Jul 2025 14:09:42 +0000 (UTC) Received: from ngraves.fr (unknown [10.1.6.9]) by mta7.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTPSA id 128E5C2B5C; Wed, 23 Jul 2025 14:09:41 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-112S006c79d6d69-fbdc-4807-8180-3553bcd5f016, 7A0F58A941BE3D65D27E2BB666FBE78C399DFECA) smtp.auth=ngraves@ngraves.fr X-OVh-ClientIp: 90.92.117.144 From: Nicolas Graves Date: Wed, 23 Jul 2025 16:09:41 +0200 Message-ID: <87pldr2e3e.fsf@ngraves.fr> MIME-Version: 1.0 Content-Type: text/plain X-Ovh-Tracer-Id: 17088345838881202852 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdejjeelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfggtgesthdtredttddttdenucfhrhhomheppfhitgholhgrshcuifhrrghvvghsuceonhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrqeenucggtffrrghtthgvrhhnpeeugefgtdekvdeujefhfeeggfevjeehfffgjedvteeuheffheegueffhfdttdehheenucfkphepuddvjedrtddrtddruddpledtrdelvddruddujedrudeggeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepnhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrpdhnsggprhgtphhtthhopedvpdhrtghpthhtoheplhhilhhirghnrgdrphhrihhklhgvrhesghhmrghilhdrtghomhdprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhgpdfovfetjfhoshhtpehmohehiedvmgdpmhhouggvpehsmhhtphhouhht DKIM-Signature: a=rsa-sha256; bh=QPWuTIhpBLnhYPhwPpPzI/F6pCN3Qv/qPpRj/EbUBk8=; c=relaxed/relaxed; d=ngraves.fr; h=From; s=ovhmo4487190-selector1; t=1753279783; v=1; b=xSP5s6cQvyZ/kB7jLsyvaPoNOWknW9WjklLzWqL8/UtlA5F1+o3AsPvjbDlfJiE1vP4s82W5 sJMcQX0BMiwBB1oY8Ja+ihtw2OUnunmWVGBhpMHDoT9HkYYiEfM/gTS173fC6ID36q/eenLMl0n wpJerumiAtdThi70KDkeIot6PmF12XdwwbZ8ZSnyPI9KzcCBRD6+NWZzHTCjiCd7oV+mpL1+Tmd uP+U6ouHe4NiscVYZmiAIepUrknsYMUgssk1rypEMWWdfSvMqhDkjvTPm0jpNkgmfRFeF50ZzUt a7RQ9vvR0KUZSmfAmLGyhE82bjQXM78r1SntwpWjA5PNg== Received-SPF: pass client-ip=46.105.33.63; envelope-from=ngraves@ngraves.fr; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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@30.1, 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 From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: "Dr. Werner Fink" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Jul 2025 14:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Graves Cc: 79082@debbugs.gnu.org, Liliana Marie Prikler Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.175371200727027 (code B ref 79082); Mon, 28 Jul 2025 14:14:02 +0000 Received: (at 79082) by debbugs.gnu.org; 28 Jul 2025 14:13:27 +0000 Received: from localhost ([127.0.0.1]:56312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ugObW-00071r-Nb for submit@debbugs.gnu.org; Mon, 28 Jul 2025 10:13:27 -0400 Received: from smtp-out1.suse.de ([2a07:de40:b251:101:10:150:64:1]:60602) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ugObT-00071C-TF for 79082@debbugs.gnu.org; Mon, 28 Jul 2025 10:13:24 -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 94C02211EA; Mon, 28 Jul 2025 14:13:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1753711995; 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=fjEa7n3vgvB37oG+11mAeOFnAdul5ISCmybZnISueNk=; b=vNriORFnVVfTFAtxqGVd+lyE+Eeor1soNDr1h5LPjnVXlGS23jev7Bo1tiR/bPjNdCaQKU PGRn6eoY+ZosXnSZs09+wyK99yBTCopPO5LAuITge0EOE2SBG/I10hYKOYRhe97pinJ5iu wtaqxwj6gm3m8GHyDTvkCdZdtrGeHvg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1753711995; 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=fjEa7n3vgvB37oG+11mAeOFnAdul5ISCmybZnISueNk=; b=yLoF7uxM9/hvX0ZbrnbSDtko1+XvRmf+QVaf2UIdn6PGf7zTH8uM8DcYNZwgOuOoqyiL0e F8u3Z3lzh5NrdTBA== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=vNriORFn; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=yLoF7uxM DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1753711995; 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=fjEa7n3vgvB37oG+11mAeOFnAdul5ISCmybZnISueNk=; b=vNriORFnVVfTFAtxqGVd+lyE+Eeor1soNDr1h5LPjnVXlGS23jev7Bo1tiR/bPjNdCaQKU PGRn6eoY+ZosXnSZs09+wyK99yBTCopPO5LAuITge0EOE2SBG/I10hYKOYRhe97pinJ5iu wtaqxwj6gm3m8GHyDTvkCdZdtrGeHvg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1753711995; 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=fjEa7n3vgvB37oG+11mAeOFnAdul5ISCmybZnISueNk=; b=yLoF7uxM9/hvX0ZbrnbSDtko1+XvRmf+QVaf2UIdn6PGf7zTH8uM8DcYNZwgOuOoqyiL0e F8u3Z3lzh5NrdTBA== 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 56SEDDvr002363 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 28 Jul 2025 16:13:15 +0200 Received: (from werner@localhost) by boole.nue2.suse.org (8.18.1/8.18.1/Submit) id 56SEDDoB002360; Mon, 28 Jul 2025 16:13:13 +0200 Date: Mon, 28 Jul 2025 16:13:08 +0200 From: "Dr. Werner Fink" Message-ID: References: <87pldr2e3e.fsf@ngraves.fr> 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@ngraves.fr> X-GPG-Fingerprint: 1B06 BF5A 3829 90FB CBA2 75BE 50E9 0D55 1DC1 6B2E X-MS-Reactions: disallow X-Spam-Level: X-Spam-Flag: NO X-Rspamd-Queue-Id: 94C02211EA X-Rspamd-Action: no action X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spamd-Result: default: False [-1.11 / 50.00]; BAYES_HAM(-3.00)[100.00%]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; SIGNED_PGP(-2.00)[]; RDNS_NONE(2.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; ARC_NA(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[debbugs.gnu.org,gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:email] X-Spam-Score: -1.11 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --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" To: Nicolas Graves Cc: 79082@debbugs.gnu.org, Liliana Marie Prikler 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@30.1, 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 --- 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-- From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Jul 2025 14:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Dr. Werner Fink" Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.17537147285426 (code B ref 79082); Mon, 28 Jul 2025 14:59:02 +0000 Received: (at 79082) by debbugs.gnu.org; 28 Jul 2025 14:58:48 +0000 Received: from localhost ([127.0.0.1]:56436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ugPJP-0001PS-Ny for submit@debbugs.gnu.org; Mon, 28 Jul 2025 10:58:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41164) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ugPJM-0001P5-H6 for 79082@debbugs.gnu.org; Mon, 28 Jul 2025 10:58:45 -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 ) id 1ugPJF-0005dg-GL; Mon, 28 Jul 2025 10:58:37 -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=AVlEjtvUINAPqqtdK49VmfOxUQGhwsWsC+zQj6zymmg=; b=fGM6er0S/qJd MpSLzZXqz6qUz5t8UVmqU4KTaqkr8FxHHZOMJU3lC6kVa1xv0INl1GDheYFQPxE3x7dGSKBYsXCLS RNr0GQxhK4uvPfKBiQ+t8loet1/8rhEBVclwaq+TQ4EIBi+IKDQnFR0stTOHCa1c2UkLHhuyz7Aup m0EJVbq1cgg8zoXC+SbHQxXtBMzCXCJYJhrPQmZt7CbYDruIGYTu/t9EDBvCPHFFhYfPxZ150V8T/ VGp79269lqVExzWeQ2JRq2KGbmOPG5AsxLF5jaTntnWYgrF486NqKD+Aa4wnTW0/eSakWr8QDs2HL g9Ade71TIER40vDH86z8TA==; Date: Mon, 28 Jul 2025 17:58:15 +0300 Message-Id: <86a54oxszc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (werner@suse.de) References: <87pldr2e3e.fsf@ngraves.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 79082@debbugs.gnu.org, Liliana Marie Prikler > Date: Mon, 28 Jul 2025 16:13:08 +0200 > From: "Dr. Werner Fink" > > > 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@30.1, 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. From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: "Dr. Werner Fink" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Jul 2025 08:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@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 ) id 1ugg9T-0004Rs-CM for submit@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 ) id 1ugg9Q-0004RU-7Q for 79082@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" Message-ID: References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> 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@gnu.org> 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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" To: Eli Zaretskii Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com 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 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 --- 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-- From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Jul 2025 11:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Dr. Werner Fink" Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@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 ) id 1ugiUG-000622-Pp for submit@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 ) id 1ugiUE-00061d-0M for 79082@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (werner@suse.de) References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 29 Jul 2025 10:57:21 +0200 > From: "Dr. Werner Fink" > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > > 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? From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: "Dr. Werner Fink" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Jul 2025 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@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 ) id 1ugine-0001mI-8s for submit@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 ) id 1uginZ-0001lr-SV for 79082@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" Message-ID: References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> 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@gnu.org> 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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" To: Eli Zaretskii Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com 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-- From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jul 2025 11:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Dr. Werner Fink" Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@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 ) id 1uh4lo-0006Pt-Mv for submit@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 ) id 1uh4ll-0006PT-6f for 79082@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (werner@suse.de) References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 29 Jul 2025 13:46:59 +0200 > From: "Dr. Werner Fink" > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@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. From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: "Dr. Werner Fink" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jul 2025 12:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.175387820520283 (code B ref 79082); Wed, 30 Jul 2025 12:24:02 +0000 Received: (at 79082) by debbugs.gnu.org; 30 Jul 2025 12:23:25 +0000 Received: from localhost ([127.0.0.1]:40148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh5q8-0005H4-MB for submit@debbugs.gnu.org; Wed, 30 Jul 2025 08:23:25 -0400 Received: from smtp-out1.suse.de ([2a07:de40:b251:101:10:150:64:1]:60436) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uh5q4-0005GW-Gn for 79082@debbugs.gnu.org; Wed, 30 Jul 2025 08:23:21 -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 057D021A65; Wed, 30 Jul 2025 12:23:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1753878194; 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=I0iqEI4OydXG8htxW7t7xUsKR1d8bmvLVZ+Sm+K8JqY=; b=yg4TrAv95RbJWSPPK0Yn1aMHjCxDZsY34wpboFIr7cie4LeqLhrsNFfcPhQGi/g5nMXgQC W8smdJFLtHwL29mr59ZVB9b6lnwk/u/ZkC9ZcuOApMHIORHjrnzIMFY15YL+VNWi0j/PcY Az/rphenrbBLGbn2F6aol17kpWdk3nA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1753878194; 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=I0iqEI4OydXG8htxW7t7xUsKR1d8bmvLVZ+Sm+K8JqY=; b=tXOfZ7Ka4QVa4oqWOgbAqxZXiLXVfumrHNExR7WXUTe8BdmDWOwHh5qpNOTnBy53ssQYjE XD4QcFtd3VlEN9DA== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=yg4TrAv9; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=tXOfZ7Ka DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1753878194; 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=I0iqEI4OydXG8htxW7t7xUsKR1d8bmvLVZ+Sm+K8JqY=; b=yg4TrAv95RbJWSPPK0Yn1aMHjCxDZsY34wpboFIr7cie4LeqLhrsNFfcPhQGi/g5nMXgQC W8smdJFLtHwL29mr59ZVB9b6lnwk/u/ZkC9ZcuOApMHIORHjrnzIMFY15YL+VNWi0j/PcY Az/rphenrbBLGbn2F6aol17kpWdk3nA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1753878194; 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=I0iqEI4OydXG8htxW7t7xUsKR1d8bmvLVZ+Sm+K8JqY=; b=tXOfZ7Ka4QVa4oqWOgbAqxZXiLXVfumrHNExR7WXUTe8BdmDWOwHh5qpNOTnBy53ssQYjE XD4QcFtd3VlEN9DA== 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 56UCNBpH026113 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 30 Jul 2025 14:23:13 +0200 Received: (from werner@localhost) by boole.nue2.suse.org (8.18.1/8.18.1/Submit) id 56UCNBdQ026110; Wed, 30 Jul 2025 14:23:11 +0200 Date: Wed, 30 Jul 2025 14:23:06 +0200 From: "Dr. Werner Fink" Message-ID: References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> <86ldo6vskl.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uw/50PqteA6KazAL" Content-Disposition: inline In-Reply-To: <86ldo6vskl.fsf@gnu.org> 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)[]; FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; 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)[]; RCVD_TLS_LAST(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; ARC_NA(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[ngraves.fr,debbugs.gnu.org,gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:email] X-Spamd-Bar: / X-Rspamd-Queue-Id: 057D021A65 X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --uw/50PqteA6KazAL Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jul 2025 14:23:06 +0200 From: "Dr. Werner Fink" To: Eli Zaretskii Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com Subject: Re: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump On 2025/07/30 14:14:34 +0300, Eli Zaretskii wrote: > > Date: Tue, 29 Jul 2025 13:46:59 +0200 > > From: "Dr. Werner Fink" > > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > >=20 > > 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. > >=20 > > 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 > 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? I've used a C helper function with static int sigsegv; //static const unsigned char bytarr[] =3D {0x68, 0x65, 0x6d, 0x0a, 0x62, 0= x79, 0x20, 0x55, 0x54, 0x46, 0x2d, 0x38, 0x2e, 0x00}; static const unsigned char bytarr[] =3D {0x61, 0x02, 0x28, 0x6b, 0xee}; static const size_t bytlen =3D sizeof(bytarr)/sizeof(bytarr[0]); static size_t memmatch(const void* mem, size_t mem_len, const void* patter= n, size_t pattern_length, size_t* pattern_index) { eassert(*pattern_index < pattern_length); size_t idx =3D 0;=20 register size_t index =3D *pattern_index; for (; idx < mem_len;) { if (((const unsigned char*)mem)[idx++] =3D=3D ((const unsigned cha= r*)pattern)[index]) { ++index; if (pattern_length =3D=3D index) { break; // ++idx; } } else if (index) { index =3D 0; // reset } } *pattern_index =3D index; return idx; } in dump_write() to trigger SIGSEGV or run direct in gdb with break/watch po= ints and with the help of emacs-30.1/src/.gdbinit I've determined the Lisp Float= and the Lisp Cons which changes on every run of temacs at pdump. The first as = well as the second bytarr is simply taken form the diffs of two od dump outputs.= With the first something like 'by UTF-8.' and the second a very large usigned in= teger which had me reminded in gdb on seconds past epoch. The rest was a diligent= but routine piece of work. Werner --=20 "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr --uw/50PqteA6KazAL Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmiKDqssFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay4q uhAAkeEXEOqbTkA4WEye2o1SmG98Qd9TvxPYIppce73waWCqVeqJfkKHLprohIf+ WgQQrzX0SxNozmlTDfCzzYNPNKjALXr/1jifhceFiyo0OKjiZoO+9xWFBfMbJ/fk cpoDo0cR96OH1qquiThdHmK/73iNdWi8PRqNO3t3Xy4duoqJJdAWsbdpNCteFZ08 gPzr6/Fi/2DtC8rfFvwFzRzRnY3tHiIXQnq6LpzvEzvpEMDZH0FzTe8J4669ijV5 H88McHYhs2nskzhuPpHSZwZWCYV6DNV2s92gr2u28Eiy07CGtrq8oo0zRPLRQh5t mUBZRzQQ8kssJLrD/9tFMOVnErQGgVRDZ/EiYzWtjVUWSktqNyLm5qdWFp2L/HGF yV9Ox/bApJaGVc7ZVqmUwo3PHarUnbCGCvEvPaE8c0ni13bFxSDJyR+WggQL1Cg3 HmQQfk3oHrIH4B9EtfGtlIsDvIdNhvuTPZYWqqYFiiUqJ5itiR9wncEMMlIe7bXl cDjOMiSONILyHyYmWOepCAW4cmhrGWpa7KQNgFJDjrQGA6tEV8LjMpBTmLFVPkDu zxsQWR+/IpNXJ1rWEVqCczEFXBXXN6dsjHiAC1G+rDwP/zekTBODE37TPtsFDYBf KBwhrVG2DtxAC8fL3Z9bAdrgl//G7eEc7iITqtwuLViGDPs= =6K9k -----END PGP SIGNATURE----- --uw/50PqteA6KazAL-- From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: "Dr. Werner Fink" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jul 2025 12:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.175387877822836 (code B ref 79082); Wed, 30 Jul 2025 12:33:02 +0000 Received: (at 79082) by debbugs.gnu.org; 30 Jul 2025 12:32:58 +0000 Received: from localhost ([127.0.0.1]:40216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh5zN-0005wE-U6 for submit@debbugs.gnu.org; Wed, 30 Jul 2025 08:32:58 -0400 Received: from smtp-out2.suse.de ([2a07:de40:b251:101:10:150:64:2]:52174) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uh5zL-0005vQ-3G for 79082@debbugs.gnu.org; Wed, 30 Jul 2025 08:32:55 -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 C68AF1F807; Wed, 30 Jul 2025 12:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1753878769; 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=UzvlRQuGJELgIdiLubVpCEM4C3VL2YymF66Xlt4WQ74=; b=TKUV5Rk0Jp9p2iuKQ2F64Z9VOV5o1P7JTp6gj1WWYlt3Su725rsF+iUaK4L6iG+mXJHFao aipilbz/OuRNeLfSmKrTHL1LZ+ntLpTRR+c2V7/67qPUl1zDhV67f/KTrH7CmhH1ZMpaRn VzdH9dQvsXUCg3Nso8z46VuzleXz3Rk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1753878769; 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=UzvlRQuGJELgIdiLubVpCEM4C3VL2YymF66Xlt4WQ74=; b=GwfdxaEU9FOS997VtbVufgqUNnO1Dy1yYgPzUT4F11pSvonWnhHH/iWq/Ns6YZOFZgIUpF jCM28vsobL7HqfBw== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=kTKR201P; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=p2TRtQ7Z DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1753878768; 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=UzvlRQuGJELgIdiLubVpCEM4C3VL2YymF66Xlt4WQ74=; b=kTKR201PysOvQ/nt2Ar0CjACyr3o1R1Dg05m9B2WhesmgLeSTF5lUlE8O4TvS3+wHv/V/T NRknJSaCQKnzZ21yFLrZLCg/+12RmxsAnKzyeozAbfvbI4xRLa2ssjmSudWMNK2EIibutq xuBhvPevrU7qKkZFiNRE78sVzFGC/ag= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1753878768; 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=UzvlRQuGJELgIdiLubVpCEM4C3VL2YymF66Xlt4WQ74=; b=p2TRtQ7ZQOdUrCTQTPSCujHGamMHljm9jvL1WMjlynEyPFjX0AnZ3toJwzZ4/eEWemtXBY qy6m0icer92H6cCQ== 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 56UCWkjV027237 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 30 Jul 2025 14:32:48 +0200 Received: (from werner@localhost) by boole.nue2.suse.org (8.18.1/8.18.1/Submit) id 56UCWkxL027236; Wed, 30 Jul 2025 14:32:46 +0200 Date: Wed, 30 Jul 2025 14:32:39 +0200 From: "Dr. Werner Fink" Message-ID: References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> <86ldo6vskl.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LHn7iqQreuRMak1O" Content-Disposition: inline In-Reply-To: <86ldo6vskl.fsf@gnu.org> 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)[99.99%]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; RDNS_NONE(2.00)[]; SIGNED_PGP(-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,text/plain]; 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)[]; RCVD_TLS_LAST(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; ARC_NA(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[ngraves.fr,debbugs.gnu.org,gmail.com]; RCVD_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim] X-Spamd-Bar: / X-Rspamd-Queue-Id: C68AF1F807 X-Spam-Score: 0.39 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --LHn7iqQreuRMak1O Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jul 2025 14:32:39 +0200 From: "Dr. Werner Fink" To: Eli Zaretskii Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com Subject: Re: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump On 2025/07/30 14:14:34 +0300, Eli Zaretskii wrote: > > Sorry but this is the defacto standard to get reproducible builds, see > >=20 > > https://reproducible-builds.org/docs/source-date-epoch/ > >=20 > > 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. >=20 > Then I guess this will only work on Posix systems with Bash. Too bad. You can use every shell like interpreter which is able to determine an integer value and set an environment variable. It would be nice if GNU Emacs upstream would fix the problem with the two changing values of the gc statistics and lisp engine startup time. If with my proposal or any other way I simply do not care but the configure option --disable-build-details should do its job. Werner --=20 "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr --LHn7iqQreuRMak1O Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmiKEOcsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay4D Pg//Srq+74dPXdusQkCj3EK55QiYRqckE4HFKVBodEuIJAgDF4qYyQhdjL8kX+9J X6R/SiF55pAqCRUiHaBvVps6h4lY838G6CPVDu+jBnid2Glrjtr9r6lTkawABfOZ /mxsn/fO7xHU2G1BIjznywQQ1N0vkybG838PF8usGjl776OuKerDW5XVYbWauqKR 1FPJL9mhb9a7NC2fDcCo6vWlU2a3Z1kFnedL+xqM37tKYANu5pTSDymixQmIaX6S H1gVKkm3ehL/d1oa13HrEnPOrvB1KNnoQ/uhAdLOFGnTCVLt+GPCXcWvkegvXCNY w7u175wgfGE83FFDOQyTAA3zxUSEydiT4FuMKHeN8/XjVsoaB9BQBhtafpV0v2x+ CiPBBbl2bQ/yh1pGdRg6gPmDAe0io5IHEgZySssHOjbk40DI65DLiV5zyQYVTtyn VYkU7yL7YSUAsBrR6+J6i64kmR50lA8vbT+6/2+fUrLTMomnGQQ67ijcRLGO85IA HNPSB4/OWdQyIW1hGP0uFBvzFCw9/a3C/hhEGK6lCSsqoG10qnM8SE+2nPfHEDlj VF8MnAQJvdXXWzt9fTG2fKq8uAtoeq5tmVhvsxH0ixnKxlbVKmTqweTGp7V4pAiv 4hFiBv/xoDvDMlgry6bRywn2P3jAi4qpYYQc2fK37xwdHiM= =hM3S -----END PGP SIGNATURE----- --LHn7iqQreuRMak1O-- From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jul 2025 12:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Dr. Werner Fink" Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.175387955726645 (code B ref 79082); Wed, 30 Jul 2025 12:46:02 +0000 Received: (at 79082) by debbugs.gnu.org; 30 Jul 2025 12:45:57 +0000 Received: from localhost ([127.0.0.1]:40306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh6Bw-0006vh-Bs for submit@debbugs.gnu.org; Wed, 30 Jul 2025 08:45:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39548) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh6Bq-0006vK-Q0 for 79082@debbugs.gnu.org; Wed, 30 Jul 2025 08:45:53 -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 ) id 1uh6Bg-0007yb-Fg; Wed, 30 Jul 2025 08:45: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=t268S5UfFhLQS1TBNQqB1ZEUgfYyM5ih/4HGHFlpowU=; b=GlRAMIHn0ae0 JgSUd+bPblDxR7RZML3HEvReqqdTUB/iiueYKJkzXK7D8epx4PBGPgC+BvruIJe/D0FlW/tkPD3ln 19Ku5Wo1MyQhNwcYLw8TCyxoNktEKuNd5sR9ae96mqoKvYM0E5GZqXIcXzi/UaTb9fBxom9I2nUMr 1tFhfkuKNaTzK+xBZn4NR9+CY8/KleKKlWn5Wquzmy3qwe1l+6pEqDxPXVGK1BlWqlaEPxM5s+PUt 20ebYwm5ycwrkRvoSKxM+Bjr7Cl0e0mQUlA2orDIZR5HkaV3JUBG/2Ok4h4qFlZ5bqYc3RFawHDtM WTpf47D/uFjnfL5LclZzEg==; Date: Wed, 30 Jul 2025 15:45:36 +0300 Message-Id: <86y0s5vocv.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (werner@suse.de) References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> <86ldo6vskl.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 30 Jul 2025 14:23:06 +0200 > From: "Dr. Werner Fink" > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > > On 2025/07/30 14:14:34 +0300, Eli Zaretskii wrote: > > > Date: Tue, 29 Jul 2025 13:46:59 +0200 > > > From: "Dr. Werner Fink" > > > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@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? > > I've used a C helper function with > > static int sigsegv; > //static const unsigned char bytarr[] = {0x68, 0x65, 0x6d, 0x0a, 0x62, 0x79, 0x20, 0x55, 0x54, 0x46, 0x2d, 0x38, 0x2e, 0x00}; > static const unsigned char bytarr[] = {0x61, 0x02, 0x28, 0x6b, 0xee}; > static const size_t bytlen = sizeof(bytarr)/sizeof(bytarr[0]); > static size_t memmatch(const void* mem, size_t mem_len, const void* pattern, > size_t pattern_length, size_t* pattern_index) > { > eassert(*pattern_index < pattern_length); > size_t idx = 0; > register size_t index = *pattern_index; > for (; idx < mem_len;) { > if (((const unsigned char*)mem)[idx++] == ((const unsigned char*)pattern)[index]) { > ++index; > if (pattern_length == index) { > break; // ++idx; > } > } else if (index) { > index = 0; // reset > } > } > *pattern_index = index; > return idx; > } > > in dump_write() to trigger SIGSEGV or run direct in gdb with break/watch points > and with the help of emacs-30.1/src/.gdbinit I've determined the Lisp Float and > the Lisp Cons which changes on every run of temacs at pdump. The first as well > as the second bytarr is simply taken form the diffs of two od dump outputs. With > the first something like 'by UTF-8.' and the second a very large usigned integer > which had me reminded in gdb on seconds past epoch. The rest was a diligent but > routine piece of work. Thanks. I'm not sure I understood your technique, but it's imperative to know what Lisp values depend on build time, and then we could discuss how best to avoid dumping them. From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jul 2025 12:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Dr. Werner Fink" Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.175387985028046 (code B ref 79082); Wed, 30 Jul 2025 12:51:02 +0000 Received: (at 79082) by debbugs.gnu.org; 30 Jul 2025 12:50:50 +0000 Received: from localhost ([127.0.0.1]:40330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uh6Gf-0007IG-6L for submit@debbugs.gnu.org; Wed, 30 Jul 2025 08:50:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49986) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh6Gb-0007HX-6N for 79082@debbugs.gnu.org; Wed, 30 Jul 2025 08:50:46 -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 ) id 1uh6GR-0000oy-P0; Wed, 30 Jul 2025 08:50:35 -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=uYgCwwAfm/ZulXN3smzUX1NlE2ezHtw5fXHe8y4sIrA=; b=sJB2vd82Z5WJ wqwN684Kl/JZnGnVS+K3sl63hMOnBflDX2k02TdxxiDevfsDIIO/h5H8brsSCWslnUG9A1oZRRxzX 0gibLKe6DxSucyt2rCGNbGIYsCaNSPQkfpcPGMWKyZp8UmZGOYkqZAZcimsj8EP0LD5Vi7o2IEglE xH0ONRk2EkZ1rzJVrfhuhQOibzI5V9xwW8lQTR+OfzQ67lKIGxm9Y5/VgjqirZRUkaebTasDCGbVr brXbMq82CSP1hWG/nT/ZaYV3mKo6cdkSzLzNZr+S41hfKNRFKJWLZjE/UUNWQp+9DO3F89uqgcR+r s6frGWxtkQgv0Y1xNHDoVg==; Date: Wed, 30 Jul 2025 15:50:03 +0300 Message-Id: <86v7n9vo5g.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (werner@suse.de) References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> <86ldo6vskl.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 30 Jul 2025 14:32:39 +0200 > From: "Dr. Werner Fink" > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > > It would be nice if GNU Emacs upstream would fix the problem with the > two changing values of the gc statistics and lisp engine startup time. > If with my proposal or any other way I simply do not care but the > configure option --disable-build-details should do its job. I understand, but I cannot in good faith uphold changes about whose correctness I have doubts, as I explained in previous messages. We should not overwrite every time value by a single fixed value, because this could easily break the build, if it doesn't already. From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: "Dr. Werner Fink" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Sep 2025 14:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.175734124822119 (code B ref 79082); Mon, 08 Sep 2025 14:21:02 +0000 Received: (at 79082) by debbugs.gnu.org; 8 Sep 2025 14:20:48 +0000 Received: from localhost ([127.0.0.1]:51459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvcjf-0005kg-AX for submit@debbugs.gnu.org; Mon, 08 Sep 2025 10:20:47 -0400 Received: from smtp-out2.suse.de ([195.135.223.131]:59156) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uvcjY-0005kH-2V for 79082@debbugs.gnu.org; Mon, 08 Sep 2025 10:20:42 -0400 Received: from boole.nue2.suse.org (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 138D575966; Mon, 8 Sep 2025 14:20:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1757341233; 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=6I7V43mph9tGLBQSSjA3XU0tBdOq0Nl2NcWiJbcd7RU=; b=yB/A5CR2G52DGdtRz3ZPiT7AGZmcf1bJYiSChUbNdX5q3gPAFvBPTr7fIf6g7RChce1t70 cmI88JGlwolXgufKfqKIJOfRQK+Vju3MgVo4sbvckT+zSsGNVjzgU11PisF7vmEvpJGy/o AppGX9QEuXFacCvBAAgakNfOoySGHS4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1757341233; 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=6I7V43mph9tGLBQSSjA3XU0tBdOq0Nl2NcWiJbcd7RU=; b=HDCF3z5cvUX2ra1NYrfsJvEto8PTWvkK9fUM08jQ4S5glrWFCLETARWLeX3L3BEzWXVFpO QsbD1sNXTSJ/hZCA== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="yB/A5CR2"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=HDCF3z5c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1757341233; 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=6I7V43mph9tGLBQSSjA3XU0tBdOq0Nl2NcWiJbcd7RU=; b=yB/A5CR2G52DGdtRz3ZPiT7AGZmcf1bJYiSChUbNdX5q3gPAFvBPTr7fIf6g7RChce1t70 cmI88JGlwolXgufKfqKIJOfRQK+Vju3MgVo4sbvckT+zSsGNVjzgU11PisF7vmEvpJGy/o AppGX9QEuXFacCvBAAgakNfOoySGHS4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1757341233; 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=6I7V43mph9tGLBQSSjA3XU0tBdOq0Nl2NcWiJbcd7RU=; b=HDCF3z5cvUX2ra1NYrfsJvEto8PTWvkK9fUM08jQ4S5glrWFCLETARWLeX3L3BEzWXVFpO QsbD1sNXTSJ/hZCA== Received: from boole.nue2.suse.org (localhost [127.0.0.1]) by boole.nue2.suse.org (8.18.1/8.18.1/SUSE Linux 0.8) with ESMTPS id 588Dorqv008596 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 8 Sep 2025 15:50:55 +0200 Received: (from werner@localhost) by boole.nue2.suse.org (8.18.1/8.18.1/Submit) id 588DorsY008595; Mon, 8 Sep 2025 15:50:53 +0200 Date: Mon, 8 Sep 2025 15:50:45 +0200 From: "Dr. Werner Fink" Message-ID: References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> <86ldo6vskl.fsf@gnu.org> <86v7n9vo5g.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/YXjqgiceGQUDMP2" Content-Disposition: inline In-Reply-To: <86v7n9vo5g.fsf@gnu.org> 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 [1.69 / 50.00]; BAYES_HAM(-3.00)[99.99%]; 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]; HFILTER_HELO_IP_A(1.00)[boole.nue2.suse.org]; HFILTER_HELO_NORES_A_OR_MX(0.30)[boole.nue2.suse.org]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; 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)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_TRACE(0.00)[suse.de:+]; 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]; DNSWL_BLOCKED(0.00)[2a07:de40:a101:3:21c:c0ff:fea4:1c14:from]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:email] X-Spamd-Bar: + X-Rspamd-Queue-Id: 138D575966 X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: 1.69 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --/YXjqgiceGQUDMP2 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Sep 2025 15:50:45 +0200 From: "Dr. Werner Fink" To: Eli Zaretskii Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com Subject: Re: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump On 2025/07/30 15:50:03 +0300, Eli Zaretskii wrote: > > Date: Wed, 30 Jul 2025 14:32:39 +0200 > > From: "Dr. Werner Fink" > > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > >=20 > > It would be nice if GNU Emacs upstream would fix the problem with the > > two changing values of the gc statistics and lisp engine startup time. > > If with my proposal or any other way I simply do not care but the > > configure option --disable-build-details should do its job. >=20 > I understand, but I cannot in good faith uphold changes about whose > correctness I have doubts, as I explained in previous messages. We > should not overwrite every time value by a single fixed value, because > this could easily break the build, if it doesn't already. Just to be noted: No bug reports so far. It simply works. Werner --=20 "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr --/YXjqgiceGQUDMP2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmi+3zUsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay6D AA//SgW/4ouxdRaGx6oSaEvK4p0csTnI64Cym9lspMtffDoTUUZd1nJscuBoYbj2 7rEjqRtOmOXv2U4//4J+H+KoXaCw+cViggIRvkzsmgQBFZEhbnyCUAsjXRnn0oIv CtugukSDou+Tu4ngNdKTp2hjvkT2bkbS0es5s37cQB2sMLtVscZTWuRGivvjrLWD iEIYcMZ8uJJsDd4obCfdCejUR29XhM0rBx7yfcOY2kKcXKc2Vlf6wyXJ4SXSEVOk Tr0hXhxMx4+Y/N/XOcf0hndu4q4EIOxgMFMpehuHGalcngW1VrlpJ2EVGMM1E4hi zWWwfAk/2jyyHhW4uE9bY7II43WMWvcDXjwkRWe/EsMR07QfaQXD9NWgdf17Vpih IzwH4tkWiXZehzAOPT3cpv+BZACNLRcLQ8ePYe0s5SNWXCY94CTT5T6kuOGQ48ma dTRFulzx0Qv8FPOIZSW9ZZoRgoccf0iQIYBCCUAxG6NSC1sqQaealC0fPya/Ks8l TS/8Bz7rmdMtA1e2cVnzKwmY3Wvr7eeIfEdc5g3MCgwAlRZ5IMniaEQJCpdUv8JY 9M8IiKIDiw2xXEHzvFKdH9lV1rbm1ZUGvxX90541oFc1eGPossTfZU+kjAEH9hs0 GJG1ebEf2pqNxv4wnNMG1oNRnduRrTdEnkttoasYg36zvJc= =GbEZ -----END PGP SIGNATURE----- --/YXjqgiceGQUDMP2-- From unknown Thu Sep 18 18:33:00 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Sep 2025 15:23:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Dr. Werner Fink" Cc: 79082@debbugs.gnu.org, ngraves@ngraves.fr, liliana.prikler@gmail.com Received: via spool by 79082-submit@debbugs.gnu.org id=B79082.17573449514015 (code B ref 79082); Mon, 08 Sep 2025 15:23:03 +0000 Received: (at 79082) by debbugs.gnu.org; 8 Sep 2025 15:22:31 +0000 Received: from localhost ([127.0.0.1]:51703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvdhN-00012Y-NW for submit@debbugs.gnu.org; Mon, 08 Sep 2025 11:22:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55678) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvdh8-00011p-5j for 79082@debbugs.gnu.org; Mon, 08 Sep 2025 11:22:24 -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 ) id 1uvdgz-00027Y-TP; Mon, 08 Sep 2025 11:22:05 -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=kN0fokWl9D/twpIkXAa9K4zSpGqRiVw1qjBsNKLffSA=; b=nzI+KSDMnL1L 26EzKNeGbEPIVQ24c41fjkLrmyo7sP3nc0YxBg0+nvnUc0PXiWXAoyugPcCt1/rVRgliYFgyS7xqG Zp1AtD/carJdpRZODcAUY+/wU2ffimyTiZuLqMUrzuc+X5h5d5ltGikDtpYDcPQElSjEMI7Cc8TYr bs6/TRXFunh2AkKcVnHYuL28QiGIiyLRoo+OYPe7wWkCdsrISYXdJ67gshhxhiDWvNWTC4Y72hYnM 8Ta4lS3Q09jlLwPMpgIdyLnhOJ1H6mQO7dZboInpaeFgFQ4EpGN0nNJGk7pij+wm8uBq/pMce87ZF qsh99VF7bR/mFJ8Q+NSB0Q==; Date: Mon, 08 Sep 2025 18:21:59 +0300 Message-Id: <86o6rlc6lk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (werner@suse.de) References: <87pldr2e3e.fsf@ngraves.fr> <86a54oxszc.fsf@gnu.org> <86qzxzw83w.fsf@gnu.org> <86ldo6vskl.fsf@gnu.org> <86v7n9vo5g.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 8 Sep 2025 15:50:45 +0200 > From: "Dr. Werner Fink" > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > > On 2025/07/30 15:50:03 +0300, Eli Zaretskii wrote: > > > Date: Wed, 30 Jul 2025 14:32:39 +0200 > > > From: "Dr. Werner Fink" > > > Cc: ngraves@ngraves.fr, 79082@debbugs.gnu.org, liliana.prikler@gmail.com > > > > > > It would be nice if GNU Emacs upstream would fix the problem with the > > > two changing values of the gc statistics and lisp engine startup time. > > > If with my proposal or any other way I simply do not care but the > > > configure option --disable-build-details should do its job. > > > > I understand, but I cannot in good faith uphold changes about whose > > correctness I have doubts, as I explained in previous messages. We > > should not overwrite every time value by a single fixed value, because > > this could easily break the build, if it doesn't already. > > Just to be noted: No bug reports so far. It simply works. Thanks, noted.