Support reproducible builds

  • Open
  • quality assurance status badge
Details
9 participants
  • andi
  • Bernhard M. Wiedemann
  • Thompson, David
  • Jan Nieuwenhuizen
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mark H Weaver
  • Vagrant Cascadian
  • Andy Wingo
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 7 Apr 2015 13:48
(address . bug-guile@gnu.org)(name . Mark H Weaver)(address . mhw@netris.org)
87twws88hr.fsf@gnu.org
Currently .go files embed randomly-generated symbols stemming from
‘syntax-session-id’, which prevents reproducible builds (see

One way to fix it would be to allow users to specify a random seed used
when generating session ids, and to make that available as a
command-line option to ‘guild compile’. (GCC does something similar
with its ‘-frandom-seed’ option.)

Probably, ‘syntax-session-id’ would have to be a SRFI-39 parameter and
we would need a ‘fresh-syntax-session-id’ procedure that would take a
seed as a parameter. In turn, ‘fresh_syntax_session_id’ would need to
take that extra argument, and it would need to be changed to not read
directly from /dev/urandom.

WDYT?

Ludo’.
M
M
Mark H Weaver wrote on 4 Feb 2016 03:41
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20272@debbugs.gnu.org)
87d1sdqjs2.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (9 lines)
> Currently .go files embed randomly-generated symbols stemming from
> ‘syntax-session-id’, which prevents reproducible builds (see
> <https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00159.html>.)
>
> One way to fix it would be to allow users to specify a random seed used
> when generating session ids, and to make that available as a
> command-line option to ‘guild compile’. (GCC does something similar
> with its ‘-frandom-seed’ option.)

We could add this, but it is not analogous to the -frandom-seed option
where it is okay to give it the same value everywhere. Users would need
to ensure that distinct session-ids are used for every invocation of
Guile.

More precisely, users of this feature would need to observe the
following restriction, or else unspecified behavior may result:

If A.go is generated by a Guile session with session-id A, and
B.go is generated by a Guile session with session-id B, and
they are both loaded into a Guile session with session-id C, then
A, B, and C must all be distinct session-ids.

One more thing: even with a deterministic session-id, the multi-threaded
compiling of *.go files recently added to Guix will lead to
non-deterministic outputs. I'm not sure how to make this work
deterministically with concurrency. Even if we switched to a fixed
number of concurrent processes with one thread each, when process A
attempts to load a .go file that is produced by process B, it is not
deterministic whether it will be there. If it is there, the macros in
that .go file will contain B's session-id, and if not, they will contain
A's session-id.

Toggle quote (2 lines)
> Probably, ‘syntax-session-id’ would have to be a SRFI-39 parameter

This might adversely affect the efficiency of our macro expander on
platforms with slow thread local variables, and I'm not sure what it
would buy us. If the idea is that it would allow us to build things in
multiple threads, I think that won't work anyway, for the reasons given
above.

I'm not entirely sure I've not made a mistake in my thinking, however.

Regards,
Mark
L
L
Ludovic Courtès wrote on 4 Feb 2016 10:35
(name . Mark H Weaver)(address . mhw@netris.org)(address . 20272@debbugs.gnu.org)
878u30g6mj.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (16 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Currently .go files embed randomly-generated symbols stemming from
>> ‘syntax-session-id’, which prevents reproducible builds (see
>> <https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00159.html>.)
>>
>> One way to fix it would be to allow users to specify a random seed used
>> when generating session ids, and to make that available as a
>> command-line option to ‘guild compile’. (GCC does something similar
>> with its ‘-frandom-seed’ option.)
>
> We could add this, but it is not analogous to the -frandom-seed option
> where it is okay to give it the same value everywhere. Users would need
> to ensure that distinct session-ids are used for every invocation of
> Guile.

With GCC the common idiom is to use ‘-frandom-seed=$source_file’.

However, it would be best if ‘guild compile’ would choose the seed
deterministically by default somehow, because we cannot expect all users
to add the new flag and use properly.

What about having ‘guild compile’ use the canonical file name of the
source being compiled (or a hash thereof) as the seed?

Toggle quote (8 lines)
> More precisely, users of this feature would need to observe the
> following restriction, or else unspecified behavior may result:
>
> If A.go is generated by a Guile session with session-id A, and
> B.go is generated by a Guile session with session-id B, and
> they are both loaded into a Guile session with session-id C, then
> A, B, and C must all be distinct session-ids.

Right.

I wonder if we could detect collisions. Ideally each .go could record
its session ID, but that’s probably not feasible in 2.0.

Toggle quote (10 lines)
> One more thing: even with a deterministic session-id, the multi-threaded
> compiling of *.go files recently added to Guix will lead to
> non-deterministic outputs. I'm not sure how to make this work
> deterministically with concurrency. Even if we switched to a fixed
> number of concurrent processes with one thread each, when process A
> attempts to load a .go file that is produced by process B, it is not
> deterministic whether it will be there. If it is there, the macros in
> that .go file will contain B's session-id, and if not, they will contain
> A's session-id.

Hmm, OK. Well, let’s keep this use case aside for now.

Toggle quote (8 lines)
>> Probably, ‘syntax-session-id’ would have to be a SRFI-39 parameter
>
> This might adversely affect the efficiency of our macro expander on
> platforms with slow thread local variables, and I'm not sure what it
> would buy us. If the idea is that it would allow us to build things in
> multiple threads, I think that won't work anyway, for the reasons given
> above.

I was just thinking that it would be a convenient interface for (scripts
compile) to specify the session ID to use.

I think the first thing to do is to change ‘fresh_syntax_session_id’ so
that they can use a user-specified seed, when available, instead of
‘scm_i_random_bytes_from_platform’.

WDYT?

Thanks for working on it! :-)

Ludo’.
M
M
Mark H Weaver wrote on 11 Feb 2016 08:09
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20272@debbugs.gnu.org)
87vb5vn2nw.fsf@netris.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (4 lines)
> Currently .go files embed randomly-generated symbols stemming from
> ‘syntax-session-id’, which prevents reproducible builds (see
> <https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00159.html>.)

I've given this more thought, and I think I have a way that avoids
session-ids altogether.

Currently, we include both the session-id and a global gensym counter in
the names of freshly generated marks and labels in psyntax.scm.
Instead, let them include the module name and a per-module counter.

More later...

Mark
M
M
Mark H Weaver wrote on 12 Feb 2016 17:29
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20272@debbugs.gnu.org)
87a8n5vqn0.fsf@netris.org
Mark H Weaver <mhw@netris.org> writes:

Toggle quote (13 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Currently .go files embed randomly-generated symbols stemming from
>> ‘syntax-session-id’, which prevents reproducible builds (see
>> <https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00159.html>.)
>
> I've given this more thought, and I think I have a way that avoids
> session-ids altogether.
>
> Currently, we include both the session-id and a global gensym counter in
> the names of freshly generated marks and labels in psyntax.scm.
> Instead, let them include the module name and a per-module counter.

I've attached a preliminary implementation of this idea, but I'm not yet
confident in its correctness.

Mark
Attachment: 0001-PRELIMINARY-psyntax-Remove-uses-of-syntax-session-id.patch
A
A
Andy Wingo wrote on 20 Jun 2016 17:46
(name . Mark H Weaver)(address . mhw@netris.org)
877fdjhnho.fsf@pobox.com
On Thu 04 Feb 2016 03:41, Mark H Weaver <mhw@netris.org> writes:

Toggle quote (5 lines)
>> Probably, ‘syntax-session-id’ would have to be a SRFI-39 parameter
>
> This might adversely affect the efficiency of our macro expander on
> platforms with slow thread local variables

I think you shouldn't worry about this. The VM keeps a pointer to the
current thread, and accesses the dynamic state / dynamic stack from
there. There are no pthread_getkey calls when accessing parameters in
the normal case.

Andy
A
A
Andy Wingo wrote on 20 Jun 2016 17:48
(name . Mark H Weaver)(address . mhw@netris.org)
8737o7hndq.fsf@pobox.com
On Fri 12 Feb 2016 17:29, Mark H Weaver <mhw@netris.org> writes:

Toggle quote (18 lines)
> Mark H Weaver <mhw@netris.org> writes:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Currently .go files embed randomly-generated symbols stemming from
>>> ‘syntax-session-id’, which prevents reproducible builds (see
>>> <https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00159.html>.)
>>
>> I've given this more thought, and I think I have a way that avoids
>> session-ids altogether.
>>
>> Currently, we include both the session-id and a global gensym counter in
>> the names of freshly generated marks and labels in psyntax.scm.
>> Instead, let them include the module name and a per-module counter.
>
> I've attached a preliminary implementation of this idea, but I'm not yet
> confident in its correctness.

Looks pretty good to me but I think we should put it off until after
2.0.12, just so we can get the release out the door. WDYT?

Andy
L
L
Ludovic Courtès wrote on 20 Jun 2016 18:08
tags
(address . request@debbugs.gnu.org)
87a8if3krv.fsf@gnu.org
tag 20272 important,patch
thanks
A
A
Andy Wingo wrote on 23 Jun 2016 21:22
Re: bug#20272: Support reproducible builds
(name . Mark H Weaver)(address . mhw@netris.org)
8737o3n20y.fsf@pobox.com
On Mon 20 Jun 2016 17:48, Andy Wingo <wingo@pobox.com> writes:

Toggle quote (10 lines)
>>> Currently, we include both the session-id and a global gensym counter in
>>> the names of freshly generated marks and labels in psyntax.scm.
>>> Instead, let them include the module name and a per-module counter.
>>
>> I've attached a preliminary implementation of this idea, but I'm not yet
>> confident in its correctness.
>
> Looks pretty good to me but I think we should put it off until after
> 2.0.12, just so we can get the release out the door. WDYT?

On the other hand, maybe including it in 2.0.12 is the right thing;
dunno. What do you think?

Andy
L
L
Ludovic Courtès wrote on 11 Oct 2016 09:56
(no subject)
(address . request@debbugs.gnu.org)
87r37n1fph.fsf@gnu.org
severity 24659 important
severity 20272 important
thanks
J
J
Jan Nieuwenhuizen wrote on 3 Nov 2016 07:54
bug#20272: Support reproducible builds
(address . 20272@debbugs.gnu.org)
87bmxxnjd7.fsf@gnu.org
Hi!

[sent to guile-devel yesterday, probably should have gone here]

I have rebased Mark's patch to master and added a fix on top of that,
needed on 2.1 to pass make check.

Also, I found that to pass make check these patches depend on
(yesterday's) latest master commit

Use atomics for async interrupts

that patch seems to depend on (at least git rebase-wise)

Deprecate user asyncs
Deprecate arbiters
Fold 2.1.4 news into 2.2 news

Having these 6 patches on top op 2.1.4 has guile produce deterministic
.go files...mostly.

My client code is seems to be happy with this, however Guix tells me
that some files are still not deterministic:

lib/guile/2.2/ccache/ice-9/peg/cache.go
lib/guile/2.2/ccache/system/repl/coop-server.go
lib/libguile-2.2.so.0.0.0

and in Guix's debug output (only after I removed this hoping to get
guile-next reproducible, guix informed me about the plain output
nondeterminism?)

lib/guile/2.2/ccache/ice-9/peg/cache.go.debug
lib/guile/2.2/ccache/web/server/http.go.debug

Any ideas on what's causing this remaining nondeterminism?

Greetings,
Jan.
Attachment: 0001-PRELIMINARY-psyntax-Remove-uses-of-syntax-session-id.patch
From ff6ddce535d5cc02a6574fe3baf238cf6533d218 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Tue, 1 Nov 2016 15:10:01 +0100
Subject: [PATCH 2/2] psyntax: fix gen-label for unset module.

* module/ice-9/boot-9.scm (generate-unique-id!): New function.
(module-generate-unique-id!): Use it.
* module/ice-9/psyntax.scm (gen-label): Use it to cater for unset
module.
* module/ice-9/psyntax-pp.scm: Regenerate.
---
module/ice-9/boot-9.scm | 3 ++-
module/ice-9/psyntax-pp.scm | 2 +-
module/ice-9/psyntax.scm | 6 ++++--
3 files changed, 7 insertions(+), 4 deletions(-)

Toggle diff (51 lines)
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index f1d684d..e18818e 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -374,12 +374,13 @@ a-cont
(define (module-ref module sym)
(let ((v (module-variable module sym)))
(if v (variable-ref v) (error "badness!" (pk module) (pk sym)))))
-(define module-generate-unique-id!
+(define generate-unique-id!
(let ((next-id 0))
(lambda (m)
(let ((i next-id))
(set! next-id (+ i 1))
i))))
+(define module-generate-unique-id! generate-unique-id!)
(define (resolve-module . args)
#f)
diff --git a/module/ice-9/psyntax-pp.scm b/module/ice-9/psyntax-pp.scm
index 207d534..c47df7f 100644
--- a/module/ice-9/psyntax-pp.scm
+++ b/module/ice-9/psyntax-pp.scm
@@ -301,7 +301,7 @@
(simple-format
#f
"l-~s~s"
- (module-generate-unique-id! mod)
+ (if mod (module-generate-unique-id! mod) (generate-unique-id! #f))
(module-name mod)))))
(gen-labels
(lambda (ls)
diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm
index 8fa0ff3..7e5c863 100644
--- a/module/ice-9/psyntax.scm
+++ b/module/ice-9/psyntax.scm
@@ -634,8 +634,10 @@
(define (gen-label)
(let ((mod (current-module)))
(simple-format #f "l-~s~s"
- (module-generate-unique-id! mod)
- (module-name mod))))
+ (if mod
+ (module-generate-unique-id! mod)
+ (generate-unique-id! #f))
+ (module-name mod))))
(define gen-labels
(lambda (ls)
--
2.10.1
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.nl
J
J
Jan Nieuwenhuizen wrote on 14 Nov 2016 22:44
(address . 20272@debbugs.gnu.org)
87shqtwxcb.fsf@gnu.org
Jan Nieuwenhuizen writes:

I have been building quite some versions of Guile the past week. There
re a couple of .go files that keep giving me problems wrt
nondeterminism:

web/server/http.go

(define *timer* (gettimeofday)) seemed suspect, but seems harmless.

rnrs/arithmetic/fixnums.go

make-implementation-restriction-violation seemed suspect, but commenting
it out does not seem to help.

After commenting out all of http.scm and fixnums.scm, yesterday I had 3
Guix builds on two machines (GuixSD and one Ubuntu+Guix) that were
bit-identical, but one build showed differences in

system/repl/commands.go

Apparently most of the time this file builds deterministicly, but some
times it does not!? Ideas?

In the mean time, one more obviously correct and trivial patch attatched
that removes a build time stamp.

Greetings,
Jan
From 2050673bffaa0ba18fabb8e92c3bc388f40bcea5 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Fri, 4 Nov 2016 16:12:55 +0100
Subject: [PATCH] Reproducible build: Set buildstamp to EPOCH.

* libguile/Makefile.am (libpath.h): Set buildstamp to EPOCH.
---
libguile/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Toggle diff (15 lines)
diff --git a/libguile/Makefile.am b/libguile/Makefile.am
index 31cff75..4471d16 100644
--- a/libguile/Makefile.am
+++ b/libguile/Makefile.am
@@ -743,7 +743,7 @@ libpath.h: $(srcdir)/Makefile.in $(top_builddir)/config.status
>> libpath.tmp
@echo ' { "LIBS", "@GUILE_LIBS@" }, \' >> libpath.tmp
@echo ' { "CFLAGS", "@GUILE_CFLAGS@" }, \' >> libpath.tmp
- @echo ' { "buildstamp", "'`date -u +'%Y-%m-%d %T'`'" }, \' >> libpath.tmp
+ @echo ' { "buildstamp", "'`date -u -d@0`'" }, \' >> libpath.tmp
@echo '}' >> libpath.tmp
$(AM_V_GEN)mv libpath.tmp libpath.h
--
2.10.1
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.nl
L
L
Ludovic Courtès wrote on 14 Dec 2016 17:25
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 20272@debbugs.gnu.org)
87twa6iikd.fsf@gnu.org
Hello Jan!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (22 lines)
> I have been building quite some versions of Guile the past week. There
> re a couple of .go files that keep giving me problems wrt
> nondeterminism:
>
> web/server/http.go
>
> (define *timer* (gettimeofday)) seemed suspect, but seems harmless.
>
> rnrs/arithmetic/fixnums.go
>
> make-implementation-restriction-violation seemed suspect, but commenting
> it out does not seem to help.
>
> After commenting out all of http.scm and fixnums.scm, yesterday I had 3
> Guix builds on two machines (GuixSD and one Ubuntu+Guix) that were
> bit-identical, but one build showed differences in
>
> system/repl/commands.go
>
> Apparently most of the time this file builds deterministicly, but some
> times it does not!? Ideas?

Did you look at these differences with diffoscope? That would be
useful.

Toggle quote (3 lines)
> In the mean time, one more obviously correct and trivial patch attatched
> that removes a build time stamp.

I’ve committed something similar but that honors ‘SOURCE_DATE_EPOCH’.
So by default there’s no difference compared to the previous behavior,
but if ‘SOURCE_DATE_EPOCH’ is given, then it is used as the build date.

Thanks!

Ludo’.
L
L
Ludovic Courtès wrote on 15 Dec 2016 00:32
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 20272@debbugs.gnu.org)
87vaumgk80.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (27 lines)
> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> I have been building quite some versions of Guile the past week. There
>> re a couple of .go files that keep giving me problems wrt
>> nondeterminism:
>>
>> web/server/http.go
>>
>> (define *timer* (gettimeofday)) seemed suspect, but seems harmless.
>>
>> rnrs/arithmetic/fixnums.go
>>
>> make-implementation-restriction-violation seemed suspect, but commenting
>> it out does not seem to help.
>>
>> After commenting out all of http.scm and fixnums.scm, yesterday I had 3
>> Guix builds on two machines (GuixSD and one Ubuntu+Guix) that were
>> bit-identical, but one build showed differences in
>>
>> system/repl/commands.go
>>
>> Apparently most of the time this file builds deterministicly, but some
>> times it does not!? Ideas?
>
> Did you look at these differences with diffoscope? That would be
> useful.

I built it with ‘guix build --rounds=2 -K’ and got 17 differing .go
files. I looked at srfi/srfi-9/gnu.go with ediff + hexl-mode in Emacs
and found a dozen of “t-XYZ” and “tmp-XYZ” identifiers with a different
value for XYZ (an integer).

To be continued…

Ludo’.
L
L
Ludovic Courtès wrote on 15 Dec 2016 00:42
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 20272@debbugs.gnu.org)
87mvfygjs1.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (34 lines)
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>>
>>> I have been building quite some versions of Guile the past week. There
>>> re a couple of .go files that keep giving me problems wrt
>>> nondeterminism:
>>>
>>> web/server/http.go
>>>
>>> (define *timer* (gettimeofday)) seemed suspect, but seems harmless.
>>>
>>> rnrs/arithmetic/fixnums.go
>>>
>>> make-implementation-restriction-violation seemed suspect, but commenting
>>> it out does not seem to help.
>>>
>>> After commenting out all of http.scm and fixnums.scm, yesterday I had 3
>>> Guix builds on two machines (GuixSD and one Ubuntu+Guix) that were
>>> bit-identical, but one build showed differences in
>>>
>>> system/repl/commands.go
>>>
>>> Apparently most of the time this file builds deterministicly, but some
>>> times it does not!? Ideas?
>>
>> Did you look at these differences with diffoscope? That would be
>> useful.
>
> I built it with ‘guix build --rounds=2 -K’ and got 17 differing .go
> files. I looked at srfi/srfi-9/gnu.go with ediff + hexl-mode in Emacs
> and found a dozen of “t-XYZ” and “tmp-XYZ” identifiers with a different
> value for XYZ (an integer).

To demonstrate non-reproducibility (with the attached patch, which is a
rebased version of Mark’s), just build the same module twice: once with
its dependency evaluated, and then with its dependency compiled. The
results differ:

Toggle snippet (22 lines)
ludo@pluto ~/src/guile$ rm -f module/srfi/srfi-9/gnu.go module/srfi/srfi-9.go
ludo@pluto ~/src/guile$ make -C module srfi/srfi-9/gnu.go
make: Entering directory '/home/ludo/src/guile/module'
GUILEC srfi/srfi-9/gnu.go
wrote `srfi/srfi-9/gnu.go'
make: Leaving directory '/home/ludo/src/guile/module'
ludo@pluto ~/src/guile$ mv module/srfi/srfi-9/gnu.go{,.v1}
ludo@pluto ~/src/guile$ make -C module srfi/srfi-9.go
make: Entering directory '/home/ludo/src/guile/module'
GUILEC srfi/srfi-9.go
wrote `srfi/srfi-9.go'
make: Leaving directory '/home/ludo/src/guile/module'
ludo@pluto ~/src/guile$ make -C module srfi/srfi-9/gnu.go
make: Entering directory '/home/ludo/src/guile/module'
GUILEC srfi/srfi-9/gnu.go
wrote `srfi/srfi-9/gnu.go'
make: Leaving directory '/home/ludo/src/guile/module'
ludo@pluto ~/src/guile$ mv module/srfi/srfi-9/gnu.go{,.v2}
ludo@pluto ~/src/guile$ diff -u module/srfi/srfi-9/gnu.go.{v1,v2}
Ciferecaj dosieroj module/srfi/srfi-9/gnu.go.v1 kaj module/srfi/srfi-9/gnu.go.v2 estas malsamaj

In gnu.go.v2 the integers appended to generated symbols are lower
because fewer symbols had to be generated.

Ludo’.
Attachment: 0001-psyntax-Remove-uses-of-syntax-session-id.patch
L
L
Ludovic Courtès wrote on 21 Dec 2016 00:00
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 20272@debbugs.gnu.org)
87eg12fbog.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (5 lines)
> To demonstrate non-reproducibility (with the attached patch, which is a
> rebased version of Mark’s), just build the same module twice: once with
> its dependency evaluated, and then with its dependency compiled. The
> results differ:

[...]

Toggle quote (3 lines)
> In gnu.go.v2 the integers appended to generated symbols are lower
> because fewer symbols had to be generated.

This is fixed by introducing a “per-module gensym” (patch attached; to
be applied on top of the previous one). That way, the sequence number
in generated identifiers only depends on the module being compiled, not
on whether other modules are being interpreted or not.

The ‘module-gensym’ procedure I added adds a hash of the module name in
the identifier, to distinguish from symbols introduced by ‘gensym’.
This makes symbols 3–4 characters longer; perhaps we could avoid it.

Thoughts?

Thanks,
Ludo’.
Attachment: file
L
L
Ludovic Courtès wrote on 22 Dec 2016 00:53
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
871sx0vnyn.fsf@gnu.org
With the attached patch I can build ‘stable-2.0’ with --rounds=2 and
there are no discrepancies.

I’ll apply it next week if there are no objections.

Next I’ll adjust it for ‘master’.

Thanks,
Ludo’.
Attachment: 0001-psyntax-Generate-identifiers-in-a-deterministic-fash.patch
L
L
Ludovic Courtès wrote on 30 Dec 2016 22:00
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
87mvfd874q.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (5 lines)
> With the attached patch I can build ‘stable-2.0’ with --rounds=2 and
> there are no discrepancies.
>
> I’ll apply it next week if there are no objections.

Pushed as 458ae248ab353af24e27b8fb3e5fe7a8b78ae219!

Ludo’.
A
A
Andy Wingo wrote on 28 Feb 2017 14:26
(name . Ludovic Courtès)(address . ludo@gnu.org)
87efyio399.fsf@pobox.com
On Thu 22 Dec 2016 00:53, ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (5 lines)
> +(define (module-generate-unique-id! m)
> + (let ((i (module-next-unique-id m)))
> + (set-module-next-unique-id! m (+ i 1))
> + i))

This introduces a race condition when expanding from multiple threads at
once. Any plan here?

Andy
L
L
Ludovic Courtès wrote on 5 Mar 2017 21:49
(name . Andy Wingo)(address . wingo@pobox.com)
8737er5tzd.fsf@gnu.org
Hi!

Andy Wingo <wingo@pobox.com> skribis:

Toggle quote (10 lines)
> On Thu 22 Dec 2016 00:53, ludo@gnu.org (Ludovic Courtès) writes:
>
>> +(define (module-generate-unique-id! m)
>> + (let ((i (module-next-unique-id m)))
>> + (set-module-next-unique-id! m (+ i 1))
>> + i))
>
> This introduces a race condition when expanding from multiple threads at
> once. Any plan here?

Good point! We could grab a per-module mutex for that, though that’s
again a fat mutex.

Thoughts?

Ludo’.
A
A
Andy Wingo wrote on 6 Mar 2017 21:13
(name . Ludovic Courtès)(address . ludo@gnu.org)
87varm9nar.fsf@pobox.com
Hi,

On Sun 05 Mar 2017 21:49, ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (17 lines)
> Andy Wingo <wingo@pobox.com> skribis:
>
>> On Thu 22 Dec 2016 00:53, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> +(define (module-generate-unique-id! m)
>>> + (let ((i (module-next-unique-id m)))
>>> + (set-module-next-unique-id! m (+ i 1))
>>> + i))
>>
>> This introduces a race condition when expanding from multiple threads at
>> once. Any plan here?
>
> Good point! We could grab a per-module mutex for that, though that’s
> again a fat mutex.
>
> Thoughts?

I would use atomic boxes if possible, but they are in another module :/
Even mutexes aren't directly available in boot-9 any more... Alternately
we can make a new primitive for module-generate-unique-id! which can
obviously use C. That's probably the easiest option, sadly!

Andy
L
L
Ludovic Courtès wrote on 7 Mar 2017 20:55
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
87innksvyf.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (9 lines)
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> With the attached patch I can build ‘stable-2.0’ with --rounds=2 and
>> there are no discrepancies.
>>
>> I’ll apply it next week if there are no objections.
>
> Pushed as 458ae248ab353af24e27b8fb3e5fe7a8b78ae219!

Applied as commit 84a740d86a5afd235f1b47ac66c88db010b1d56b in master (2.1).

I haven’t yet done a --rounds=2 build of master, but hopefully that’ll
be fine!

Ludo’.
Closed
A
A
andi wrote on 1 Jun 2020 22:54
Re: Archived problem report bug#20272 (Support reproducible builds)
(address . control@debbugs.gnu.org)
20200601205441.hpzvn4fuzoqoxra7@wrt
unarchive 20272
A
A
Andreas Rammhold wrote on 1 Jun 2020 22:45
Re: Support reproducible builds
(address . 20272@debbugs.gnu.org)
20200601204550.4mevbvzltq5pqzru@wrt
I've just stumpled upon this as within Nixpkgs we have a pending [PR]
that references this issue. Since it reads as if it should be solved in
Guile 2.1+ but still occurs for us in nixpkgs when using parallel builds
(aka using multiple cores in a single build) I thought it might be a
good to get in touch.

Updating our expression to Guile 3.0.2 did not fix the reproducibility
issues either (when built using multiple cores).

I've just now tried a Guix 1.1.0 QEMU image and invoked `guix build
--round=2 -K guile --check -c 8` and it also wasn't reproducible. A
bunch of .go files showed differences between the builds.

Am I missings something?

Would gladly help if there is something I can do.

A
A
Andreas Rammhold wrote on 2 Jun 2020 14:25
Support reproducible builds
(address . 20272@debbugs.gnu.org)
20200602122524.tknz2vuhskmiu56j@wrt
I've just stumpled upon this as within Nixpkgs we have a pending [PR]
that references this issue. Since it reads as if it should be solved in
Guile 2.1+ but still occurs for us in nixpkgs when using parallel builds
(aka using multiple cores in a single build) I thought it might be a
good to get in touch.

Updating our expression to Guile 3.0.2 did not fix the reproducibility
issues either (when built using multiple cores).

I've just now tried a Guix 1.1.0 QEMU image and invoked `guix build
--round=2 -K guile --check -c 8` and it also wasn't reproducible. A
bunch of .go files showed differences between the builds.

Am I missings something?

Would gladly help if there is something I can do.

M
M
Maxim Cournoyer wrote on 8 Oct 2020 18:19
(name . Ludovic Courtès)(address . ludo@gnu.org)
87o8lcu1v8.fsf@gmail.com
unarchive 20272
reopen 20272
severity 20272 important
thanks

Hello!

I've hit a .go non-reproducibility issue fairly trivially on
core-updates. I think it sufficed to change a core library file (e.g.,
commit 7102c18678dc02d5ee6c77a9a70ae344482af841 which touched (guix
build utils)) and then attempting to build something with --rounds=2
flagged it:

Toggle snippet (15 lines)
./pre-inst-env guix build --rounds=2 mit-krb5 -K --no-substitutes

building /gnu/store/74fh18318l4f9zmkl3y3klyasnc1jqc2-module-import-compiled.drv...
building /gnu/store/40wzfd27s4i50rc1q86dqks986ff8fq2-module-import-compiled.drv...
building /gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv...
building /gnu/store/0i3sqm9cl2rbbikfas2y28wibnmqr1pa-module-import-compiled.drv...
[ 1/ 2] Loading './guix/build/utils.scm'...
[ 2/ 2] Compiling './guix/build/utils.scm'...
building /gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv...
building /gnu/store/40wzfd27s4i50rc1q86dqks986ff8fq2-module-import-compiled.drv...
output ‘/gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled’ of ‘/gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv’ differs from ‘/gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled-check’ from previous round
build of /gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv failed
View build log at '/var/log/guix/drvs/dl/zy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv.bz2'.

And here's the diffoscope output:

Toggle snippet (257 lines)
diffoscope /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled{,-check}
--- /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled
+++ /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled-check
? --- /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled/guix
??? +++ /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled-check/guix
? ? --- /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled/guix/build
? ??? +++ /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled-check/guix/build
? ? ? --- /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled/guix/build/utils.go
? ? ??? +++ /gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled-check/guix/build/utils.go
? ? ?? xxd not available in path. Falling back to Python hexlify.
? ? ? @@ -160,24 +160,24 @@
? ? ? 0c00d7670000056d6163726fa4030c00d86700000c2473632d64697370617463
? ? ? 68a4030c00d9130213d806110003a4030c00da130213d806110003a4030c00db
? ? ? 67000003616e79a4030c00dc67000008656163682d616e79a4030c00dd13db13
? ? ? dc8ca4030c00de13db13dd8ca4030c00df6700000d73796e7461782d6f626a65
? ? ? 6374a4030c00e0670000036c6574a4030c00e167000003746f70a4030c00e213
? ? ? e1110001a4030c00e36700000772696263616765a4030c00e46700000564756d
? ? ? 6d79a4030c00e567000003646972a4030c00e667000004626f6479a4030c00e7
? ? ? -13e413e513e6120003a4030c00e86700001c6d2d464a755571696c6e676c6268
? ? ? -583061673059366664342d393236a4030c00e913e813e1110002a4030c00ea13
? ? ? -e913e213e2120003a4030c00eb6600001c6c2d464a755571696c6e676c626858
? ? ? -3061673059366664342d393331a4030c00ec6600001c6c2d464a755571696c6e
? ? ? -676c6268583061673059366664342d393332a4030c00ed6600001c6c2d464a75
? ? ? -5571696c6e676c6268583061673059366664342d393333a4030c00ee13eb13ec
? ? ? +13e413e513e6120003a4030c00e86700001c6d2d6f367468526661366a7a7135
? ? ? +6f7150556b335877534f2d393236a4030c00e913e813e1110002a4030c00ea13
? ? ? +e913e213e2120003a4030c00eb6600001c6c2d6f367468526661366a7a71356f
? ? ? +7150556b335877534f2d393331a4030c00ec6600001c6c2d6f36746852666136
? ? ? +6a7a71356f7150556b335877534f2d393332a4030c00ed6600001c6c2d6f3674
? ? ? +68526661366a7a71356f7150556b335877534f2d393333a4030c00ee13eb13ec
? ? ? 13ed120003a4030c00ef13e313e713ea13ee120004a4030c00f013e308080812
? ? ? 0004a4030c00f16700000178a4030c00f213f1120001a4030c00f313e9120001
? ? ? -a4030c00f46600001c6c2d464a755571696c6e676c6268583061673059366664
? ? ? -342d393238a4030c00f513f4120001a4030c00f613e313f213f313f5120004a4
? ? ? +a4030c00f46600001c6c2d6f367468526661366a7a71356f7150556b33587753
? ? ? +4f2d393238a4030c00f513f4120001a4030c00f613e313f213f313f5120004a4
? ? ? 030c00f713e213ef13f013f6110004a4030c00f86700000768796769656e65a4
? ? ? 030c00f913f8130613071308110004a4030c00fa13df13e013f713f9120004a4
? ? ? 030c00fb67000004696e6974a4030c00fc13df13fb13f713f9120004a4030c00
? ? ? fd67000006676574637764a4030c00fe13df13fd13f713f9120004a4030c00ff
? ? ? 13fe110001a4030c010013fc13ff110002a4030c0101140100110001a4030c01
? ? ? 026700000c64796e616d69632d77696e64a4030c010313df14010213f713f912
? ? ? 0004a4030c0104670000066c616d626461a4030c010513df14010413f713f912
? ? ? @@ -199,23 +199,23 @@
? ? ? 75747075742d706f7274a4030c012267000009737562737472696e67a4030c01
? ? ? 236700001066696c652d73797374656d2d666f6c64a4030c01246600000e607e
? ? ? 6127202d3e20607e61277e25a4030c012567000008726561646c696e6ba4030c
? ? ? 01266700001263757272656e742d6572726f722d706f7274a4030c0127660000
? ? ? 13692f6f206572726f723a207e613a207e617e25a4030c012867000008737472
? ? ? 6572726f72a4030c01296700000d7761726e2d6f6e2d6572726f72a4030c012a
? ? ? 13db13db13db110003a4030c012b6700000465787072a4030c012c6700000466
? ? ? -696c65a4030c012d13e414012b14012c120003a4030c012e6700001d6d2d464a
? ? ? -755571696c6e676c6268583061673059366664342d31313733a4030c012f1401
? ? ? +696c65a4030c012d13e414012b14012c120003a4030c012e6700001d6d2d6f36
? ? ? +7468526661366a7a71356f7150556b335877534f2d31313733a4030c012f1401
? ? ? 2e13e1110002a4030c013014012f13e213e2120003a4030c01316600001d6c2d
? ? ? -464a755571696c6e676c6268583061673059366664342d31313738a4030c0132
? ? ? -6600001d6c2d464a755571696c6e676c6268583061673059366664342d313137
? ? ? -39a4030c01336600001d6c2d464a755571696c6e676c62685830616730593666
? ? ? -64342d31313830a4030c0134140131140132140133120003a4030c013513e314
? ? ? +6f367468526661366a7a71356f7150556b335877534f2d31313738a4030c0132
? ? ? +6600001d6c2d6f367468526661366a7a71356f7150556b335877534f2d313137
? ? ? +39a4030c01336600001d6c2d6f367468526661366a7a71356f7150556b335877
? ? ? +534f2d31313830a4030c0134140131140132140133120003a4030c013513e314
? ? ? 012d140130140134120004a4030c013614012f120001a4030c01376600001d6c
? ? ? -2d464a755571696c6e676c6268583061673059366664342d31313735a4030c01
? ? ? +2d6f367468526661366a7a71356f7150556b335877534f2d31313735a4030c01
? ? ? 38140137120001a4030c013913e313f2140136140138120004a4030c013a13e2
? ? ? 14013513f0140139110004a4030c013b13df13ad14013a13f9120004a4030c01
? ? ? 3c6700000571756f7465a4030c013d13df14013c14013a13f9120004a4030c01
? ? ? 3e13df13b714013a13f9120004a4030c013f14013d14013e110002a4030c0140
? ? ? 13df14010414013a13f9120004a4030c01416700000461726773a4030c014213
? ? ? df14014114013a13f9120004a4030c014313df132d14013a13f9120004a4030c
? ? ? 014413df14012614013a13f9120004a4030c0145140144110001a4030c014666
? ? ? @@ -231,21 +231,21 @@
? ? ? 0c01576700000c6469726563746f726965733f53a4030c015814015709038ca4
? ? ? 030c01596700000e6661696c2d6f6e2d6572726f723f53a4030c015a14015909
? ? ? 048ca4030c015b14015614015814015a110003a4030c015c6700000a70726f63
? ? ? 65647572653fa4030c015d67000004736f7274a4030c015e6600001466696e64
? ? ? 2d66696c65733a207e613a207e617e25a4030c015f6600001166696e642d6669
? ? ? 6c6573206661696c6564a4030c016067000008737472696e673c3fa4030c0161
? ? ? 13db13db110002a4030c016267000003657870a4030c016313e4140162120002
? ? ? -a4030c01646700001d6d2d464a755571696c6e676c6268583061673059366664
? ? ? -342d31323834a4030c016514016413e1110002a4030c016614016513e2120002
? ? ? -a4030c01676600001d6c2d464a755571696c6e676c6268583061673059366664
? ? ? -342d31323839a4030c01686600001d6c2d464a755571696c6e676c6268583061
? ? ? -673059366664342d31323930a4030c0169140167140168120002a4030c016a13
? ? ? +a4030c01646700001d6d2d6f367468526661366a7a71356f7150556b33587753
? ? ? +4f2d31323834a4030c016514016413e1110002a4030c016614016513e2120002
? ? ? +a4030c01676600001d6c2d6f367468526661366a7a71356f7150556b33587753
? ? ? +4f2d31323839a4030c01686600001d6c2d6f367468526661366a7a71356f7150
? ? ? +556b335877534f2d31323930a4030c0169140167140168120002a4030c016a13
? ? ? e3140163140166140169120004a4030c016b140165120001a4030c016c660000
? ? ? -1d6c2d464a755571696c6e676c6268583061673059366664342d31323836a403
? ? ? +1d6c2d6f367468526661366a7a71356f7150556b335877534f2d31323836a403
? ? ? 0c016d14016c120001a4030c016e13e313f214016b14016d120004a4030c016f
? ? ? 13e214016a13f014016e110004a4030c017013df13ad14016f13f9120004a403
? ? ? 0c017113df14013c14016f13f9120004a4030c017213df13b714016f13f91200
? ? ? 04a4030c0173140171140172110002a4030c017413df14010414016f13f91200
? ? ? 04a4030c017513df14014114016f13f9120004a4030c0176670000026966a403
? ? ? 0c017713df14017614016f13f9120004a4030c0178670000013da4030c017913
? ? ? df14017814016f13f9120004a4030c017a67000006454e4f454e54a4030c017b
? ? ? @@ -266,75 +266,75 @@
? ? ? 21656e7669726f6e6d656e74207661726961626c6520607e612720756e736574
? ? ? 7e25a4030c019867000006736574656e76a4030c019966000027656e7669726f
? ? ? 6e6d656e74207661726961626c6520607e61272073657420746f20607e61277e
? ? ? 25a4030c019a6700000b7365617263682d70617468a4030c019b660000045041
? ? ? 5448a4030c019c67000006657175616c3fa4030c019d67000005627265616ba4
? ? ? 030c019e67000006617070656e64a4030c019f670000046c65742aa4030c01a0
? ? ? 67000006706861736573a4030c01a1670000086d6f642d73706563a4030c01a2
? ? ? -13e41401a01401a1120003a4030c01a36700001d6d2d464a755571696c6e676c
? ? ? -6268583061673059366664342d32303636a4030c01a41401a313e1110002a403
? ? ? -0c01a51401a413e213e2120003a4030c01a66600001d6c2d464a755571696c6e
? ? ? -676c6268583061673059366664342d32303731a4030c01a76600001d6c2d464a
? ? ? -755571696c6e676c6268583061673059366664342d32303732a4030c01a86600
? ? ? -001d6c2d464a755571696c6e676c6268583061673059366664342d32303733a4
? ? ? +13e41401a01401a1120003a4030c01a36700001d6d2d6f367468526661366a7a
? ? ? +71356f7150556b335877534f2d32303636a4030c01a41401a313e1110002a403
? ? ? +0c01a51401a413e213e2120003a4030c01a66600001d6c2d6f36746852666136
? ? ? +6a7a71356f7150556b335877534f2d32303731a4030c01a76600001d6c2d6f36
? ? ? +7468526661366a7a71356f7150556b335877534f2d32303732a4030c01a86600
? ? ? +001d6c2d6f367468526661366a7a71356f7150556b335877534f2d32303733a4
? ? ? 030c01a91401a61401a71401a8120003a4030c01aa13e31401a21401a51401a9
? ? ? -120004a4030c01ab1401a4120001a4030c01ac6600001d6c2d464a755571696c
? ? ? -6e676c6268583061673059366664342d32303638a4030c01ad1401ac120001a4
? ? ? +120004a4030c01ab1401a4120001a4030c01ac6600001d6c2d6f367468526661
? ? ? +366a7a71356f7150556b335877534f2d32303638a4030c01ad1401ac120001a4
? ? ? 030c01ae13e313f21401ab1401ad120004a4030c01af13e21401aa13f01401ae
? ? ? 110004a4030c01b013df14019f1401af13f9120004a4030c01b1670000077068
? ? ? 617365732aa4030c01b213df1401b11401af13f9120004a4030c01b3130213c1
? ? ? 06110003a4030c01b4130213c106110003a4030c01b56700000e256d6f646966
? ? ? 792d706861736573a4030c01b613df1401b51401af13f9120004a4030c01b714
? ? ? 01b2110001a4030c01b867000007667265652d6964a4030c01b96700001d6d2d
? ? ? -464a755571696c6e676c6268583061673059366664342d32303738a4030c01ba
? ? ? -1401b913e1110002a4030c01bb1401ba120001a4030c01bc6600001d6c2d464a
? ? ? -755571696c6e676c6268583061673059366664342d32303830a4030c01bd1401
? ? ? +6f367468526661366a7a71356f7150556b335877534f2d32303738a4030c01ba
? ? ? +1401b913e1110002a4030c01bb1401ba120001a4030c01bc6600001d6c2d6f36
? ? ? +7468526661366a7a71356f7150556b335877534f2d32303830a4030c01bd1401
? ? ? bc120001a4030c01be13e313f21401bb1401bd120004a4030c01bf13e213f014
? ? ? 01be110003a4030c01c013df137d1401bf13f9120004a4030c01c11401b81401
? ? ? c0120002a4030c01c21401c113db110002a4030c01c313db13db1401c2110003
? ? ? a4030c01c46700000e6f6c642d70686173652d6e616d65a4030c01c513e41401
? ? ? a01401c4120003a4030c01c61401ba13e213e2120003a4030c01c76600001d6c
? ? ? -2d464a755571696c6e676c6268583061673059366664342d32303833a4030c01
? ? ? -c86600001d6c2d464a755571696c6e676c6268583061673059366664342d3230
? ? ? -3834a4030c01c96600001d6c2d464a755571696c6e676c626858306167305936
? ? ? -6664342d32303835a4030c01ca1401c71401c81401c9120003a4030c01cb13e3
? ? ? +2d6f367468526661366a7a71356f7150556b335877534f2d32303833a4030c01
? ? ? +c86600001d6c2d6f367468526661366a7a71356f7150556b335877534f2d3230
? ? ? +3834a4030c01c96600001d6c2d6f367468526661366a7a71356f7150556b3358
? ? ? +77534f2d32303835a4030c01ca1401c71401c81401c9120003a4030c01cb13e3
? ? ? 1401c51401c61401ca120004a4030c01cc13e21401cb13f01401be110004a403
? ? ? 0c01cd13df137c1401cc13f9120004a4030c01ce670000077265706c616365a4
? ? ? 030c01cf13df1401ce1401bf13f9120004a4030c01d01401b81401cf120002a4
? ? ? 030c01d11401d013db13db110003a4030c01d213db13db1401d1110003a4030c
? ? ? 01d3670000096e65772d7068617365a4030c01d413e41401a01401c41401d312
? ? ? -0004a4030c01d51401ba13e213e213e2120004a4030c01d66600001d6c2d464a
? ? ? -755571696c6e676c6268583061673059366664342d32303930a4030c01d76600
? ? ? -001d6c2d464a755571696c6e676c6268583061673059366664342d32303931a4
? ? ? -030c01d86600001d6c2d464a755571696c6e676c626858306167305936666434
? ? ? -2d32303932a4030c01d96600001d6c2d464a755571696c6e676c626858306167
? ? ? -3059366664342d32303933a4030c01da1401d61401d71401d81401d9120004a4
? ? ? +0004a4030c01d51401ba13e213e213e2120004a4030c01d66600001d6c2d6f36
? ? ? +7468526661366a7a71356f7150556b335877534f2d32303930a4030c01d76600
? ? ? +001d6c2d6f367468526661366a7a71356f7150556b335877534f2d32303931a4
? ? ? +030c01d86600001d6c2d6f367468526661366a7a71356f7150556b335877534f
? ? ? +2d32303932a4030c01d96600001d6c2d6f367468526661366a7a71356f715055
? ? ? +6b335877534f2d32303933a4030c01da1401d61401d71401d81401d9120004a4
? ? ? 030c01db13e31401d41401d51401da120004a4030c01dc13e21401db13f01401
? ? ? be110004a4030c01dd13df135c1401dc13f9120004a4030c01de6700000a6164
? ? ? 642d6265666f7265a4030c01df13df1401de1401bf13f9120004a4030c01e014
? ? ? 01b81401df120002a4030c01e11401e013db13db13db110004a4030c01e213db
? ? ? 13db1401e1110003a4030c01e36700000e6e65772d70686173652d6e616d65a4
? ? ? 030c01e413e41401a01401c41401e31401d3120005a4030c01e51401ba13e213
? ? ? -e213e213e2120005a4030c01e66600001d6c2d464a755571696c6e676c626858
? ? ? -3061673059366664342d32303939a4030c01e76600001d6c2d464a755571696c
? ? ? -6e676c6268583061673059366664342d32313030a4030c01e86600001d6c2d46
? ? ? -4a755571696c6e676c6268583061673059366664342d32313031a4030c01e966
? ? ? -00001d6c2d464a755571696c6e676c6268583061673059366664342d32313032
? ? ? -a4030c01ea6600001d6c2d464a755571696c6e676c6268583061673059366664
? ? ? -342d32313033a4030c01eb1401e61401e71401e81401e91401ea120005a4030c
? ? ? +e213e213e2120005a4030c01e66600001d6c2d6f367468526661366a7a71356f
? ? ? +7150556b335877534f2d32303939a4030c01e76600001d6c2d6f367468526661
? ? ? +366a7a71356f7150556b335877534f2d32313030a4030c01e86600001d6c2d6f
? ? ? +367468526661366a7a71356f7150556b335877534f2d32313031a4030c01e966
? ? ? +00001d6c2d6f367468526661366a7a71356f7150556b335877534f2d32313032
? ? ? +a4030c01ea6600001d6c2d6f367468526661366a7a71356f7150556b33587753
? ? ? +4f2d32313033a4030c01eb1401e61401e71401e81401e91401ea120005a4030c
? ? ? 01ec13e31401e41401e51401eb120004a4030c01ed13e21401ec13f01401be11
? ? ? 0004a4030c01ee13df135a1401ed13f9120004a4030c01ef670000096164642d
? ? ? 6166746572a4030c01f013df1401ef1401bf13f9120004a4030c01f11401b814
? ? ? 01f0120002a4030c01f21401f113db13db13db110004a4030c01f313db13db14
? ? ? -01f2110003a4030c01f46600001d6c2d464a755571696c6e676c626858306167
? ? ? -3059366664342d32313130a4030c01f56600001d6c2d464a755571696c6e676c
? ? ? -6268583061673059366664342d32313131a4030c01f66600001d6c2d464a7555
? ? ? -71696c6e676c6268583061673059366664342d32313132a4030c01f76600001d
? ? ? -6c2d464a755571696c6e676c6268583061673059366664342d32313133a4030c
? ? ? -01f86600001d6c2d464a755571696c6e676c6268583061673059366664342d32
? ? ? +01f2110003a4030c01f46600001d6c2d6f367468526661366a7a71356f715055
? ? ? +6b335877534f2d32313130a4030c01f56600001d6c2d6f367468526661366a7a
? ? ? +71356f7150556b335877534f2d32313131a4030c01f66600001d6c2d6f367468
? ? ? +526661366a7a71356f7150556b335877534f2d32313132a4030c01f76600001d
? ? ? +6c2d6f367468526661366a7a71356f7150556b335877534f2d32313133a4030c
? ? ? +01f86600001d6c2d6f367468526661366a7a71356f7150556b335877534f2d32
? ? ? 313134a4030c01f91401f41401f51401f61401f71401f8120005a4030c01fa13
? ? ? e31401e41401e51401f9120004a4030c01fb13e21401fa13f01401be110004a4
? ? ? 030c01fc13df135b1401fb13f9120004a4030c01fd670000136d616b652d636f
? ? ? 6e646974696f6e2d74797065a4030c01fe131b1401fd06110003a4030c01ff13
? ? ? 1b1401fd06110003a4030c02006700000d26696e766f6b652d6572726f72a403
? ? ? 0c020167000006266572726f72a4030c02026700000770726f6772616da4030c
? ? ? 020367000009617267756d656e7473a4030c02046700000b657869742d737461
? ? ? @@ -361,73 +361,73 @@
? ? ? 747573207e613b206f757470757420666f6c6c6f77733a7e257e257e7b20207e
? ? ? 617e257e7da4030c0224660000072e585858585858a4030c0225670000127769
? ? ? 74682d7468726f772d68616e646c6572a4030c02266700000b72656e616d652d
? ? ? 66696c65a4030c02276700000f7265676578702f657874656e646564a4030c02
? ? ? 2867000004666f6c64a4030c02296700000c6c6973742d6d617463686573a403
? ? ? 0c022a67000007646973706c6179a4030c022b67000006636f6e636174a4030c
? ? ? 022c6700000b6c65742d6d617463686573a4030c022d670000015fa4030c022e
? ? ? -6700001d6d2d464a755571696c6e676c6268583061673059366664342d323932
? ? ? +6700001d6d2d6f367468526661366a7a71356f7150556b335877534f2d323932
? ? ? 38a4030c022f14022e13e1110002a4030c023014022f120001a4030c02316600
? ? ? -001d6c2d464a755571696c6e676c6268583061673059366664342d32393330a4
? ? ? +001d6c2d6f367468526661366a7a71356f7150556b335877534f2d32393330a4
? ? ? 030c0232140231120001a4030c023313e313f2140230140232120004a4030c02
? ? ? 3413e213f0140233110003a4030c023513df14022d14023413f9120004a4030c
? ? ? 02361401b8140235120002a4030c023714023613dc8ca4030c023814023713dc
? ? ? 8ca4030c023913db1402388ca4030c023a13db1402398ca4030c023b13db1402
? ? ? 3a8ca4030c023c67000005696e646578a4030c023d6700000476617273a4030c
? ? ? 023e13e414023c132414023d13e6120005a4030c023f14022f13e213e213e213
? ? ? -e2120005a4030c02406600001d6c2d464a755571696c6e676c62685830616730
? ? ? -59366664342d32393333a4030c02416600001d6c2d464a755571696c6e676c62
? ? ? -68583061673059366664342d32393334a4030c02426600001d6c2d464a755571
? ? ? -696c6e676c6268583061673059366664342d32393335a4030c02436600001d6c
? ? ? -2d464a755571696c6e676c6268583061673059366664342d32393336a4030c02
? ? ? -446600001d6c2d464a755571696c6e676c6268583061673059366664342d3239
? ? ? +e2120005a4030c02406600001d6c2d6f367468526661366a7a71356f7150556b
? ? ? +335877534f2d32393333a4030c02416600001d6c2d6f367468526661366a7a71
? ? ? +356f7150556b335877534f2d32393334a4030c02426600001d6c2d6f36746852
? ? ? +6661366a7a71356f7150556b335877534f2d32393335a4030c02436600001d6c
? ? ? +2d6f367468526661366a7a71356f7150556b335877534f2d32393336a4030c02
? ? ? +446600001d6c2d6f367468526661366a7a71356f7150556b335877534f2d3239
? ? ? 3337a4030c0245140240140241140242140243140244120005a4030c024613e3
? ? ? 14023e14023f140245120004a4030c024713e214024613f0140233110004a403
? ? ? 0c024813df14022c14024713f9120004a4030c0249670000012ba4030c024a13
? ? ? df14024914024713f9120004a4030c024b13df0b14024713f9120004a4030c02
? ? ? 4c13dd13dc8ca4030c024d13db14024c8ca4030c024e13db14024d8ca4030c02
? ? ? 4f13db14024e8ca4030c025067000003766172a4030c025113e414023c132414
? ? ? 025014023d13e6120006a4030c025214022f13e213e213e213e213e2120006a4
? ? ? -030c02536600001d6c2d464a755571696c6e676c626858306167305936666434
? ? ? -2d32393436a4030c02546600001d6c2d464a755571696c6e676c626858306167
? ? ? -3059366664342d32393437a4030c02556600001d6c2d464a755571696c6e676c
? ? ? -6268583061673059366664342d32393438a4030c02566600001d6c2d464a7555
? ? ? -71696c6e676c6268583061673059366664342d32393439a4030c02576600001d
? ? ? -6c2d464a755571696c6e676c6
This message was truncated. Download the full message here.
V
V
Vagrant Cascadian wrote on 24 Nov 2020 05:44
87o8jngy7r.fsf@yucca
On 2020-10-08, Maxim Cournoyer wrote:
Toggle quote (22 lines)
> I've hit a .go non-reproducibility issue fairly trivially on
> core-updates. I think it sufficed to change a core library file (e.g.,
> commit 7102c18678dc02d5ee6c77a9a70ae344482af841 which touched (guix
> build utils)) and then attempting to build something with --rounds=2
> flagged it:
>
> --8<---------------cut here---------------start------------->8---
> ./pre-inst-env guix build --rounds=2 mit-krb5 -K --no-substitutes
>
> building /gnu/store/74fh18318l4f9zmkl3y3klyasnc1jqc2-module-import-compiled.drv...
> building /gnu/store/40wzfd27s4i50rc1q86dqks986ff8fq2-module-import-compiled.drv...
> building /gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv...
> building /gnu/store/0i3sqm9cl2rbbikfas2y28wibnmqr1pa-module-import-compiled.drv...
> [ 1/ 2] Loading './guix/build/utils.scm'...
> [ 2/ 2] Compiling './guix/build/utils.scm'...
> building /gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv...
> building /gnu/store/40wzfd27s4i50rc1q86dqks986ff8fq2-module-import-compiled.drv...
> output ‘/gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled’ of ‘/gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv’ differs from ‘/gnu/store/czbmygd6id8qk3bfb0rcjjkmpn5bh7f1-module-import-compiled-check’ from previous round
> build of /gnu/store/dlzy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv failed
> View build log at '/var/log/guix/drvs/dl/zy98gvyddjg3zrv5f1l3nvgjvaxjmf-module-import-compiled.drv.bz2'.
> --8<---------------cut here---------------end--------------->8---

I'm not *positive* this is the same issue, but disabling parallelism
building the Debian package of guix appears to fix reproducibility of
almost all of the .go files... (the one exception is gnu/ci.go embeds
the build path, and just filed a bug for that: #44835)


Notice the somewhat arbitrary list of different gnu/packages/*.scm files
and arbitrary order:

./usr/lib/i386-linux-gnu/guile/3.0/site-ccache/gnu/packages/admin.go

strings --all --bytes=8 {}
Offset 1402, 20 lines modified Offset 1402, 20 lines modified
1402 -4AI[4-AI[-4AI[ 1402 -4AI[4-AI[-4AI[
1403 Guile·3.0.4 1403 Guile·3.0.4
1404 arguments 1404 arguments
1405 native-inputs 1405 native-inputs
1406 propagated-inputs 1406 propagated-inputs
1407 sunxi-tools-source 1407 sunxi-tools-source
1408 gnu/packages/admin.scm 1408 gnu/packages/admin.scm
1409 gnu/packages/aidc.scm
1409 gnu/packages/algebra.scm 1410 gnu/packages/algebra.scm
1410 gnu/packages/anthy.scm 1411 gnu/packages/anthy.scm
1411 gnu/packages/android.scm 1412 gnu/packages/android.scm
1412 gnu/packages/animation.scm
1413 gnu/packages/aidc.scm
1414 gnu/packages/agda.scm 1413 gnu/packages/agda.scm
1414 gnu/packages/adns.scm
1415 arguments 1415 arguments
1416 native-inputs 1416 native-inputs
1417 propagated-inputs 1417 propagated-inputs
1418 sunxi-tools-source 1418 sunxi-tools-source
1419 file-name 1419 file-name
1420 build-system 1420 build-system
1421 supported-systems 1421 supported-systems


While building in serial rather than parallel is a significant slowdown,
it seems like being able to build reproducibly might be worth the cost,
at least for certain guix variants, such as the package used for
guix-daemon... I'll likely disable parallel building for the next guix
upload to Debian, at least. :)


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCX7yPyAAKCRDcUY/If5cW
qkdIAP49bmwNpjh2L95bZjVim7j3usQJqhg5pYSsc3Bn62T7OwD+KXCnSs096N/l
XXDe7oqXnYrK95yhpxB06lc9IkdINwA=
=1pfX
-----END PGP SIGNATURE-----

B
B
Bernhard M. Wiedemann wrote on 17 Nov 2023 21:28
Support reproducible builds
(address . 20272@debbugs.gnu.org)
ccd6847e-9cb4-4c87-9c02-822e36803e66@suse.de
Parallel builds with guile-3.0.9 still introduce non-determinism
I tested with openSUSE's guile-newt package
and found (with filterdiff[1])
filterdiff strings */site-ccache/newt/checkboxtree.go
produced among others
newtCheckboxTree
-/usr/lib64/libnewt
+config
+%libnewt
dynamic-link
dynamic-func
[...]
newt/bindings.scm
newt/checkboxtree.scm
-newt/config.scm
ice-9/boot-9.scm
make-checkboxtree
so it is not just a simple ordering issue, but certain entries are
missing or replaced.
Is there an equivalent of objdump for .go files to see what is in there?
Attachment: OpenPGP_signature.asc
T
T
Thompson, David wrote on 8 Apr 19:27 +0200
(name . Bernhard M. Wiedemann)(address . bwiedemann@suse.de)(address . 20272@debbugs.gnu.org)
CAJ=Rwfbf98_4hvYQ6nFdRc4dpUK_UwmGe4FVjfx_BF4=yxnf4w@mail.gmail.com
On Fri, Nov 17, 2023 at 3:29?PM Bernhard M. Wiedemann
<bwiedemann@suse.de> wrote:
Toggle quote (3 lines)
>
> Parallel builds with guile-3.0.9 still introduce non-determinism

I recently learned that the cross-module inlining optimization pass is
a source of nondeterminism. If module A imports module B, inlining of
procedures from B into A may occur *if* B has already been compiled.
Depending on the value of n in `make -j $n` you will likely get a
different build.

While working on Guile Hoot, I encountered a bug on my machine that
Andy Wingo couldn't reproduce on his. Turns out it was because my
`make -j6` build was different from his `make -j32` build. I don't
recall the details but apparently Guile's bootstrap process takes
great care to avoid sequencing issues like this.

I don't know what the solution might be, though. I want parallel *and*
reproducible builds!

- Dave
B
B
Bernhard M. Wiedemann wrote on 9 Apr 06:02 +0200
(name . Thompson, David)(address . dthompson2@worcester.edu)(address . 20272@debbugs.gnu.org)
6cc5e9ca-81b8-40a3-a4e5-6afc26671d7d@suse.de
On 08/04/2024 19.27, Thompson, David wrote:
Toggle quote (2 lines)
> I don't know what the solution might be, though. I want parallel *and*
> reproducible builds!
For openSUSE we are using -j1 builds everywhere until a better solution
is found.
Toggle quote (2 lines)
> If module A imports module B, inlining of
> procedures from B into A may occur *if* B has already been compiled.
So this means, module A would need to wait for compilation of B to
finish, so that it always inlines it.
This could be implemented either in Makefile or guile.
Ciao
Bernhard M.
Attachment: OpenPGP_signature.asc
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 20272@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 20272
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch