From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aFbAF1gLhV/2OgAA0tVLHw (envelope-from ) for ; Tue, 13 Oct 2020 02:05:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id MOaKE1gLhV97KAAAB5/wlQ (envelope-from ) for ; Tue, 13 Oct 2020 02:05:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8CD0D94053C for ; Tue, 13 Oct 2020 02:05:11 +0000 (UTC) Received: from localhost ([::1]:58728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS9ga-0005fS-Nd for larch@yhetil.org; Mon, 12 Oct 2020 22:05:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS9gU-0005f4-8a for guix-patches@gnu.org; Mon, 12 Oct 2020 22:05:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33050) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kS9gT-0007Sw-VL for guix-patches@gnu.org; Mon, 12 Oct 2020 22:05:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kS9gT-00057O-Pg for guix-patches@gnu.org; Mon, 12 Oct 2020 22:05:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#43745] [PATCH 04/27] gnu: ocaml-migrate-parsetree: Update to 1.7.3. Resent-From: Julien Lepiller Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 13 Oct 2020 02:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43745 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: zimoun Cc: 43745@debbugs.gnu.org Received: via spool by 43745-submit@debbugs.gnu.org id=B43745.160255464219598 (code B ref 43745); Tue, 13 Oct 2020 02:05:01 +0000 Received: (at 43745) by debbugs.gnu.org; 13 Oct 2020 02:04:02 +0000 Received: from localhost ([127.0.0.1]:44596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS9fW-000561-CW for submit@debbugs.gnu.org; Mon, 12 Oct 2020 22:04:02 -0400 Received: from lepiller.eu ([89.234.186.109]:45736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS9fR-00055W-41 for 43745@debbugs.gnu.org; Mon, 12 Oct 2020 22:04:00 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id 10ecfdd3; Tue, 13 Oct 2020 02:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=dkim; bh=5MWmVsyVxauS Zx1/OkgbzBgxd2hs7xDSQl6ZdOGpRQQ=; b=g023x3DQgd/bc4VEIfNy0srApKMF NTsjoXfBbyAaBhBuNRu6DDJ4lA1ZQjXPaeCB2A6G32FbqaJOEYF7Q31dl/COXuLY q6NBU52NASyAfGtAkRRCvLMiBgfUIQyOqgDzPl0wjStXdaBGrkRlu5SLUs5tktZO KqbryCoKtjItXVwoID0ZeGghMgA4uhOQNjSfaUA/PuXKifoassuHtnBOSVOf42I6 cM+aXn/XQyFj6RqTT5Iv31IUJoJ5RoHcy8L6qFXr7ZnKeiD1X6BradNE5u/1MiX6 LhZ3QFjvW2QdfO9Dl6GvXIyPljQT7WJ8qyL8pqKJ0Pc7GD0+bWsF2SpI5g== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id 0dd0e75d (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Tue, 13 Oct 2020 02:03:54 +0000 (UTC) Date: Tue, 13 Oct 2020 04:03:45 +0200 From: Julien Lepiller Message-ID: <20201013040345.73b2367d@tachikoma.lepiller.eu> In-Reply-To: <86wnzvnjig.fsf@gmail.com> References: <20201001153909.296c8d3e@tachikoma.lepiller.eu> <20201001134133.32105-1-julien@lepiller.eu> <20201001134133.32105-4-julien@lepiller.eu> <86wnzvnjig.fsf@gmail.com> X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=lepiller.eu header.s=dkim header.b=g023x3DQ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: 7YcL9NRowEQ2 Le Tue, 13 Oct 2020 00:53:43 +0200, zimoun a =C3=A9crit : >=20 > On Thu, 01 Oct 2020 at 15:41, Julien Lepiller > wrote: > > * gnu/packages/ocaml.scm (ocaml-migrate-parsetree): Update to 1.7.3. > > --- > > gnu/packages/ocaml.scm | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) >=20 > LGTM but '--check' returns: >=20 > --8<---------------cut here---------------start------------->8--- > guix build: error: derivation > `/gnu/store/fgkmww5s1srlh8frn1jbzz952mkn4pvi-ocaml-migrate-parsetree-1.7.= 3.drv' > may not be deterministic: output > `/gnu/store/3pb3cz6s0p37p4737gm6cj50p1vh02q8-ocaml-migrate-parsetree-1.7.= 3' > differs --8<---------------cut > here---------------end--------------->8--- >=20 > Could you open a bug report when you will merge to master? >=20 >=20 > All the best, > simon Thank you! I've been investigating this, but I don't really understand what's happening. So, I've created myself an environment in which I could compile the sources of migrate-parsetree: cd s1 /my/guix/repo/pre-inst-env guix environment -C ocaml-migrate-parsetree dune build @install exit mv s1 s2 copy sources to s1 again (to prevent issues due to recorded build paths), and build again. This allows me to keep and compare all the intermediate build products. =46rom diffoscope and _build/log, I found the first differing file that is a cmo file. I note that the build is not in order, but arguments are always sorted. This is expected, as dune runs with 4 cores. Next, I've created this very simple file (one line), called test.ml: module Ast_402 =3D Migrate_parsetree__Ast_402 (this is the first line of Ast_402.ml-gen, which is the file that builds the first differing cmo. Then, I build it using: OCAMLC=3Docamlc.opt -w @1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats-short-paths -keep-locs -w -49 -nopervasives -nostdlib -g -bin-annot -no-alias-deps -opaque -o a.cmo -c -implem test.ml using exactly the same options as dune, excluding a -I (include). This creates a.cmo, a.cmt and a.cmi. Then, using sha256sum, I can see if the files differ. Removing these files and trying again gives me always the same result. However, if I instead move them to b.cm{o,t,i}, the next time I build a.cmo, there is a difference between a.cmo and b.cmo, as well as the cmt files (but not the cmi files): ${OCAMLC} sha256sum a.cmo de1caa8b636e97e3e7c964ea84ea52bc532d80653afd13a5a106687886255861 a.cmo rm a.cm* ${OCAMLC} sha256sum a.cmo de1caa8b636e97e3e7c964ea84ea52bc532d80653afd13a5a106687886255861 a.cmo ... mv {a,b}.cmo; mv {a,b}.cmt; mv {a,b}.cmi ${OCAMLC} sha256sum a.cmo 8cfd4b3d214d924f8229bd3697cc3eace58d4e20eb7cb27c27e7b670fa9809e6 a.cmo rm a.cm* ${OCAMLC} sha256sum a.cmo 8cfd4b3d214d924f8229bd3697cc3eace58d4e20eb7cb27c27e7b670fa9809e6 a.cmo ... and with every additional files (c.cmo, d.cmo, ...) I get a different hash, but as long as I keep the same files there, nothing changes. The hash also changes if I create additional files, such as: touch e.cmi (the cmi file seems to be the only one whose presence changes the content of the cmo and cmt files). So, my hypothesis is that dune is building files out of order, but lets ocaml read the generated cmi files. Since the build is not in order, when it builds the same file in two different builds, the cmi are not the same and the result is different. Since dune will always use all my cores, I used a trick I learned from LFS: echo 0 > /sys/devices/system/cpu/cpu1/online (and similar for every other core, except cpu0) This way, I have a single-core machine and, hopefully, dune runs sequentially. This time, --rounds=3D2 passed (after removing the existing store item of course).