Discrepancy when running ‘guix pull’ from different machines

  • Open
  • quality assurance status badge
Details
4 participants
  • Konrad Hinsen
  • Ludovic Courtès
  • Ludovic Courtès
  • Simon Tournier
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important

Debbugs page

L
L
Ludovic Courtès wrote on 11 Jul 06:59 -0700
Discrepancy when running ‘guix pull’ from different machines
(address . bug-guix@gnu.org)
87bk34113k.fsf@inria.fr
While running:

guix pull -q --commit=0ff72d105

on two different machines, we found that the resulting derivation would
be different. The “right one” (same as on ci.guix is):

Toggle snippet (11 lines)
$ readlink $(readlink my.0ff72d105)
/gnu/store/1g1zhh3864xzh0csqrzf5c1qkbd3q5pp-profile
$ guix gc --derivers $(readlink -f my.0ff72d105)
/gnu/store/b6zvsh8z7fmx5bpw21wqhnl82kfag5s1-profile.drv
$ guix gc -R $(guix gc --derivers $(readlink -f my.0ff72d105)) |grep guix-0ff72d105
/gnu/store/sarff52m9zavyyadllixk9brjqfacn57-guix-0ff72d105-modules-builder
/gnu/store/ys9rcn7d9xp4d2wwcy6i21gm6rmviv31-guix-0ff72d105-builder
/gnu/store/6l3xi9lcib99lpdq6z7x5bahm4ppxw45-guix-0ff72d105-modules.drv
/gnu/store/w3h8kvag0dbw9y6qq35r3fb87b1xpykd-guix-0ff72d105.drv

On the other machine, where substitutes would consequently be
unavailable, we’d get:

Toggle snippet (9 lines)
$ readlink fernando.0ff72d105.drv
/gnu/store/hl1di1dq6mcd7jl0phk5bi12yqcc9dif-guix-0ff72d105.drv
$ guix gc -R /gnu/store/hl1di1dq6mcd7jl0phk5bi12yqcc9dif-guix-0ff72d105.drv |grep guix-0ff72d105
/gnu/store/p04znrg5frzj6gpiafpx7cgr4n7jly5s-guix-0ff72d105-modules-builder
/gnu/store/sc7y5i9pi5w2cpba0xmk7pzqckn642bp-guix-0ff72d105-modules.drv
/gnu/store/p4bh6x0r8qy9lpg77p52cjzxjzhp0mwr-guix-0ff72d105-builder
/gnu/store/hl1di1dq6mcd7jl0phk5bi12yqcc9dif-guix-0ff72d105.drv

Digging into the derivation graph reveals the difference below in the
derivation that builds the grafted avahi:
diff -ubBr --show-c-function --label \#\<buffer\ 32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder\> --label \#\<buffer\ z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder\> /tmp/buffer-content-tBGXyv /tmp/buffer-content-XM8vEv
--- #<buffer 32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder>
+++ #<buffer z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder>
@@ -23,11 +23,11 @@
(("/gnu/store/ill8bkp6wshj15nc4fxk4wgln15rgyi6-libevent-2.1.12" . "/gnu/store/s6jj1mrdhi2l2860zd9n609qfhlgjc1m-libevent-2.1.12")
("/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib" . "/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib")
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35" . "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35")
+ ("/gnu/store/36my0g0j72b3vbz0gj1l8f0lmmgfkv3w-glib-2.72.3" . "/gnu/store/m26kdkgr4c09wc0djn2pgcz9jl7j2rw1-glib-2.72.3")
("/gnu/store/2w976k6g70gkfih9wwhalqsni209vcqz-gdbm-1.23" . "/gnu/store/z655ilai81pbzbm35zwfqc64ha7wl37k-gdbm-1.23")
("/gnu/store/x2a1qx3syync9q4ka1gh8g0svrcq86k6-libdaemon-0.14" . "/gnu/store/br5achyfqqgw6yzx82s5v9h7llcf7q4q-libdaemon-0.14")
("/gnu/store/h4kvisn532l7ndqniqnj30yd26vksasq-dbus-1.14.0" . "/gnu/store/hjc4rdifbl890j03xy2gsa7y2sqcg0mi-dbus-1.14.0")
("/gnu/store/fw1wywd34vh33l4dq182ds5d7jdz45j5-expat-2.5.0" . "/gnu/store/94rdaacvsqf05zhw88w92y8bkvgxdfpl-expat-2.5.0")
- ("/gnu/store/36my0g0j72b3vbz0gj1l8f0lmmgfkv3w-glib-2.72.3" . "/gnu/store/m26kdkgr4c09wc0djn2pgcz9jl7j2rw1-glib-2.72.3")
("/gnu/store/sjy64dvx18yc5p29zywmg01k3g53p643-libcap-2.64" . "/gnu/store/ba5ri728kpa5fv314fav2id0nc3l0hsk-libcap-2.64")
("/gnu/store/9vw5slrffp27rzy2i2plnw7xfqjyk7m4-bash-minimal-5.1.16" . "/gnu/store/5mzqf6fz9bz30ybgx7jrqw424qbg9rbk-bash-minimal-5.1.16")))
(map
That is, the ordering of grafts in the ‘mapping’ variables created by
‘graft-derivation/shallow’ would be different.

This would suggest something’s happening in a non-deterministic or
stateful fashion.

To be continued…

Ludo’.
L
L
Ludovic Courtès wrote on 11 Jul 07:41 -0700
Re: bug#72061: Discrepancy when running ‘guix p ull’ from different machines
(address . 72061@debbugs.gnu.org)
877cds0z4l.fsf@gnu.org
Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

Toggle quote (20 lines)
> Digging into the derivation graph reveals the difference below in the
> derivation that builds the grafted avahi:
>
> diff -ubBr --show-c-function --label \#\<buffer\ 32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder\> --label \#\<buffer\ z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder\> /tmp/buffer-content-tBGXyv /tmp/buffer-content-XM8vEv
> --- #<buffer 32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder>
> +++ #<buffer z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder>
> @@ -23,11 +23,11 @@
> (("/gnu/store/ill8bkp6wshj15nc4fxk4wgln15rgyi6-libevent-2.1.12" . "/gnu/store/s6jj1mrdhi2l2860zd9n609qfhlgjc1m-libevent-2.1.12")
> ("/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib" . "/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib")
> ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35" . "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35")
> + ("/gnu/store/36my0g0j72b3vbz0gj1l8f0lmmgfkv3w-glib-2.72.3" . "/gnu/store/m26kdkgr4c09wc0djn2pgcz9jl7j2rw1-glib-2.72.3")
> ("/gnu/store/2w976k6g70gkfih9wwhalqsni209vcqz-gdbm-1.23" . "/gnu/store/z655ilai81pbzbm35zwfqc64ha7wl37k-gdbm-1.23")
> ("/gnu/store/x2a1qx3syync9q4ka1gh8g0svrcq86k6-libdaemon-0.14" . "/gnu/store/br5achyfqqgw6yzx82s5v9h7llcf7q4q-libdaemon-0.14")
> ("/gnu/store/h4kvisn532l7ndqniqnj30yd26vksasq-dbus-1.14.0" . "/gnu/store/hjc4rdifbl890j03xy2gsa7y2sqcg0mi-dbus-1.14.0")
> ("/gnu/store/fw1wywd34vh33l4dq182ds5d7jdz45j5-expat-2.5.0" . "/gnu/store/94rdaacvsqf05zhw88w92y8bkvgxdfpl-expat-2.5.0")
> - ("/gnu/store/36my0g0j72b3vbz0gj1l8f0lmmgfkv3w-glib-2.72.3" . "/gnu/store/m26kdkgr4c09wc0djn2pgcz9jl7j2rw1-glib-2.72.3")
> ("/gnu/store/sjy64dvx18yc5p29zywmg01k3g53p643-libcap-2.64" . "/gnu/store/ba5ri728kpa5fv314fav2id0nc3l0hsk-libcap-2.64")
> ("/gnu/store/9vw5slrffp27rzy2i2plnw7xfqjyk7m4-bash-minimal-5.1.16" . "/gnu/store/5mzqf6fz9bz30ybgx7jrqw424qbg9rbk-bash-minimal-5.1.16")))
> (map

It can be reproduced like so by computing the grafting derivation of
avahi.

The “right” one:

Toggle snippet (4 lines)
$ setarch -R guix time-machine -q --commit=0ff72d105 -- build avahi -d
/gnu/store/fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv

The “wrong” one:

Toggle snippet (4 lines)
$ setarch -R guix time-machine -q --commit=0ff72d105 -- build avahi -d
/gnu/store/vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv

Ludo’.
L
L
Ludovic Courtès wrote on 11 Jul 07:42 -0700
control message for bug #72061
(address . control@debbugs.gnu.org)
875xtc0z2u.fsf@gnu.org
severity 72061 important
quit
L
L
Ludovic Courtès wrote on 11 Jul 08:33 -0700
Re: bug#72061: Discrepancy when running ‘guix p ull’ from different machines
(address . 72061@debbugs.gnu.org)
87wmlsymd7.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (11 lines)
> The “right” one:
>
> $ setarch -R guix time-machine -q --commit=0ff72d105 -- build avahi -d
> /gnu/store/fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv
>
>
> The “wrong” one:
>
> $ setarch -R guix time-machine -q --commit=0ff72d105 -- build avahi -d
> /gnu/store/vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv

Turns out the “right” one uses ‘builtin:git-download’, the “wrong” one
doesn’t:

Toggle snippet (26 lines)
$ guix time-machine -q --commit=0ff72d105 -- repl
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> (define set-builders! (record-modifier (@@ (guix store) <store-connection>) 'built-in-builders))
;;; <stdin>:2:0: warning: possibly unused local top-level variable `set-builders!'
scheme@(guix-user)> (define s (open-connection))
;;; <stdin>:3:0: warning: possibly unused local top-level variable `s'
scheme@(guix-user)> (set-builders! s (delay '("download")))
$1 = #<promise #<procedure 19cdf418 at <unknown port>:4:17 ()>>
scheme@(guix-user)> ,use(gnu packages avahi)
scheme@(guix-user)> ,run-in-store (lower-object avahi)
error: #{ %make-platform-procedure/abi-check}#: unbound variable
hint: Did you forget a `use-modules' form?

$2 = #<derivation /gnu/store/fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv => /gnu/store/4gzpnfm6pw7cwwgrmswrsibbzdxz1j1w-avahi-0.8 7fad68382af0>
scheme@(guix-user)> (run-with-store s (lower-object avahi))
$3 = #<derivation /gnu/store/vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv => /gnu/store/64f62b0klc3mrncad6x79cwfd3smmf8z-avahi-0.8 7fad68d15230>

QED.

Presumably whether ‘builtin:git-download’ is used changes the DAG
traversal order, which could explain this discrepancy.

It does mean that all the users running an old guix-daemon find
themselves having no substitutes for ‘guix pull’. Ouch.

Ludo’.
S
S
Simon Tournier wrote on 12 Jul 02:32 -0700
87bk33hs5r.fsf@gmail.com
Hi Ludo,

Thank you for the pedestrian report; I have learnt new stuff! :-)


On Thu, 11 Jul 2024 at 17:33, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (6 lines)
> Presumably whether ‘builtin:git-download’ is used changes the DAG
> traversal order, which could explain this discrepancy.
>
> It does mean that all the users running an old guix-daemon find
> themselves having no substitutes for ‘guix pull’. Ouch.

Is it not only for grafts?


Well, in addition, some input derivations are not the same:

Toggle snippet (5 lines)
2 candidates:
./fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv:3: ,[("/gnu/store/0q4nrqmh6ymhs4hmg9vmxa8zqx1y3d2z-dbus-1.14.0.drv",["out"])
./fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv:18: ,("/gnu/store/fflyi1qg7j9kz0b062p6xf0904rc8xkm-dbus-1.14.0.drv",["out"])

compared to:

Toggle snippet (5 lines)
2 candidates:
./vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv:9: ,("/gnu/store/6p17vdziv9vcp8l4c8v0xqj855gf257g-dbus-1.14.0.drv",["out"])
./vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv:17: ,("/gnu/store/j6g0pchbj39pbg9b9bh7wafsd8kysvv3-dbus-1.14.0.drv",["out"])

Although the two derivations:

/gnu/store/0q4nrqmh6ymhs4hmg9vmxa8zqx1y3d2z-dbus-1.14.0.drv
/gnu/store/6p17vdziv9vcp8l4c8v0xqj855gf257g-dbus-1.14.0.drv

builds: /gnu/store/hjc4rdifbl890j03xy2gsa7y2sqcg0mi-dbus-1.14.0.

And similarly for the two others ’dbus’ derivations; they build the same
outputs.

Please also note that the two derivations do not have the same order for
the builder part:

Toggle snippet (4 lines)
,["/gnu/store/32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder","/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import"]
,["/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import","/gnu/store/z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder"]

And the two builder scripts are not the same because the item
"/gnu/store/36my0g0j72b3vbz0gj1l8f0lmmgfkv3w-glib-2.72.3" is line 26 for
one and line 30 for the other.


Cheers,
simon
K
K
Konrad Hinsen wrote on 24 Jul 01:05 -0700
Discrepancy when running ‘guix pull’ from different machines
(address . 72061@debbugs.gnu.org)
m1o76ncj08.fsf@fastmail.net
Hi everyone,

Jumping in with a possibly related problem reported by a participant of
the Reproducible Research MOOC.

He gets an error when running an example from one of our exercises:

guix time-machine --channels=channels.scm -- shell --container --network --manifest=manifest.scm -- jupyter lab
guix-science/build-system/node.scm:119:2: error: #{ %make-build-system-procedure/abi-check}#: unbound variable
hint: Did you forget a `use-modules' form?

It's this error message that led me to this thread. He gets the same
error message when running some of our other examples.

I asked for his channels and did a "guix pull" on my machine with the
exact same ones. But there's no problem for me, everything works fine.

Inspired by the reference to "old guix-daemon", I asked him to update
his daemon. After that, he still gets the error message but the
time-machined "shell" command is run nevertheless - and produces another
error that it doesn't produce on my machine.

Are there any diagnostics we can do to explore this issue?

Cheers,
Konrad
S
S
Simon Tournier wrote on 24 Jul 05:30 -0700
Re: bug#72061: Discrepancy when running ‘guix p ull’ from different machines
87msm7dlae.fsf@gmail.com
Hi Konrad,

On Wed, 24 Jul 2024 at 10:05, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

Toggle quote (5 lines)
> guix time-machine --channels=channels.scm -- shell --container --network --manifest=manifest.scm -- jupyter lab
> guix-science/build-system/node.scm:119:2: error: #{ %make-build-system-procedure/abi-check}#: unbound variable
> hint: Did you forget a `use-modules' form?
>

[...]

Toggle quote (2 lines)
> Are there any diagnostics we can do to explore this issue?

Could you share the channels.scm file?

Because the mention of ’guix-science’ means third-party channels, I
guess. And maybe there is something tricky when mixing different
specific pinned channels.


Cheers,
simon
K
K
Konrad Hinsen wrote on 24 Jul 12:35 -0700
m1ikwud1n6.fsf@fastmail.net
HI Simon,

Toggle quote (2 lines)
> Could you share the channels.scm file?

Attached.

Toggle quote (4 lines)
> Because the mention of ’guix-science’ means third-party channels, I
> guess. And maybe there is something tricky when mixing different
> specific pinned channels.

I thought about that as well, but the behavior should still be the same
on every machine, right? For me, the attached channels.scm works fine.

Cheers,
Konrad.
Attachment: channels.scm
S
S
Simon Tournier wrote on 26 Aug 09:38 -0700
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ed6bi6ht.fsf@gmail.com
Hi Konrad,

CC: Ludo, do you think it comes from the commit c14b8636fb: “records: Do
not inline the constructor.”?


On Wed, 24 Jul 2024 at 21:35, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

Toggle quote (4 lines)
>> Could you share the channels.scm file?
>
> Attached.

Thanks. Do you know what the current Guix revision? It should have no
effect but who knows. :-)

I mean, guix-daemon had been updated. Has the Guix command launching
“guix time-machine” been updated too?


Toggle quote (7 lines)
>> Because the mention of ’guix-science’ means third-party channels, I
>> guess. And maybe there is something tricky when mixing different
>> specific pinned channels.
>
> I thought about that as well, but the behavior should still be the same
> on every machine, right? For me, the attached channels.scm works fine.

Yes. But there is a "Computing Guix derivation“ in the middle. :-)

If I read correctly, this error message:

Toggle quote (4 lines)
> guix time-machine --channels=channels.scm -- …
> guix-science/build-system/node.scm:119:2: error: #{ %make-build-system-procedure/abi-check}#: unbound variable
> hint: Did you forget a `use-modules' form?

comes from the macro ’define-record-type*’; see module (guix records).

(symbol-append (string->symbol " %")
(syntax->datum #'ctor)
'-procedure/abi-check)))

That’s weird, because all seems correctly included, i.e., the variable
should be bounded. Well, the revisions from the channels.scm file
reads:

guix-science: 12eba5aa0c5cbf357c476ef7872e0d562d054eff
CommitDate: Wed May 22 17:40:02 2024 +0200

guix: 325fed4c1514bffd084355455710fcc3f1c8da2c
CommitDate: Tue Jul 16 10:28:05 2024 -0500

And the file guix/records.scm had been modified by:

records: Do not inline the constructor.
c14b8636fbac9826115f4524d500536d54c15625
CommitDate: Sat May 4 19:14:24 2024 +0200
Change-Id: Ifd7b4e884e9fbf21c43fb4c3ad963126ef5cb476

Is the current failing Guix running a revision older than May?


Cheers,
simon
K
K
Konrad Hinsen wrote on 2 Sep 08:31 -0700
(name . Ludovic Courtès)(address . ludo@gnu.org)
m11q22gjgx.fsf@fastmail.net
Hi Simon,

Toggle quote (3 lines)
> Thanks. Do you know what the current Guix revision? It should have no
> effect but who knows. :-)

The "channels.scm" attached to my last message describes Guix at the
time "guix time-machine" was launched. It's not the channels file used
in the time machine command! That one is quite short:

==================================================
(list (channel
(name 'guix)
(branch "master")
(commit
"7b0863f07a113caef26fea13909bd97d250b629e")
(introduction
(make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
"BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))))
==================================================

So to reproduce (or not) the error, you would do

guix pull -C channels.scm

with the file I attached in my last message, and then

guix time-machine –commit=7b0863f07a113caef26fea13909bd97d250b629e –

because that's really all it takes. But on my machine, that works fine,
whereas on someone else's machine it didn't.

Toggle quote (2 lines)
> Is the current failing Guix running a revision older than May?

It's the one defined in channels.scm, meaning commit
325fed4c1514bffd084355455710fcc3f1c8da2c, from July 16th 2024. So, no,
not older than May.

Cheers,
Konrad
S
S
Simon Tournier wrote on 2 Sep 13:04 -0700
(name . Ludovic Courtès)(address . ludo@gnu.org)
87plplq0t9.fsf@gmail.com
Hi Konrad,

On Mon, 02 Sep 2024 at 17:31, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

Toggle quote (4 lines)
> The "channels.scm" attached to my last message describes Guix at the
> time "guix time-machine" was launched. It's not the channels file used
> in the time machine command! That one is quite short:

In your previous message, you wrote:

Toggle snippet (7 lines)
He gets an error when running an example from one of our exercises:

guix time-machine --channels=channels.scm -- shell --container --network --manifest=manifest.scm -- jupyter lab
guix-science/build-system/node.scm:119:2: error: #{ %make-build-system-procedure/abi-check}#: unbound variable
hint: Did you forget a `use-modules' form?

So IIUC, the channels.scm file you provided is not the same channels.scm
file here. You provided all the revisions to get this Guix and from
this Guix you tries to reach another revision (named channels.scm in the
above but just reads 7b0863f07a113caef26fea13909bd97d250b629e).

Right?

Again IIUC, the picture looks like:

The hypothetical commit introducing the potential breakage:

records: Do not inline the constructor.
c14b8636fbac9826115f4524d500536d54c15625
CommitDate: Sat May 4 19:14:24 2024 +0200
Change-Id: Ifd7b4e884e9fbf21c43fb4c3ad963126ef5cb476

The Guix revision (newer than the record modification):

guix: 325fed4c1514bffd084355455710fcc3f1c8da2c
CommitDate: Tue Jul 16 10:28:05 2024 -0500

guix-science: 12eba5aa0c5cbf357c476ef7872e0d562d054eff
CommitDate: Wed May 22 17:40:02 2024 +0200

And the revision time-machine going in the past:

guix: 7b0863f07a113caef26fea13909bd97d250b629e
CommitDate: Wed Jan 3 16:38:57 2024 -0500


Toggle quote (6 lines)
>> Is the current failing Guix running a revision older than May?
>
> It's the one defined in channels.scm, meaning commit
> 325fed4c1514bffd084355455710fcc3f1c8da2c, from July 16th 2024. So, no,
> not older than May.

On my machine, it passes too:

Toggle snippet (8 lines)
$ guix time-machine -C channels.scm \
-- time-machine --commit=7b0863f07a113caef26fea13909bd97d250b629e \
-- describe
guix 7b0863f
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 7b0863f07a113caef26fea13909bd97d250b629e

Well, I do not know how to debug that. :-) Especially without an access
to the machine and considering the person, from the MOOC, is probably
new to Guix.

Assuming ’guix describe’ returns all the channels as mentioned earlier,
this is how to check that the current Guix contains the variable.

Toggle snippet (8 lines)
$ thisguix=$(type -P guix)
$ realguix=$(readlink -f $thisguix)
$ themodules=$(guix gc --references $realguix | grep guix-module-union)

$ find -L $themodules -type f -name "*.scm" -exec grep -l 'procedure/abi-check' {} \;
/gnu/store/ljgzk92h0hd09bli5iccg8yfp3gf1hb4-guix-module-union/share/guile/site/3.0/guix/records.scm

If nothing is returned, then it would mean that something had been
twisted when compiling (pulling) this current Guix. In that case, what
would be the output of:

$realguix describe
guix gc --references $realguix
guix gc --references $themodules

?

Else, if the file is returned, it means the error is from elsewhere,
e.g., how the Guile modules are loaded or other. In that case, it would
require to investigate the derivations.


Well, the hash ljgzk92h0hd09bli5iccg8yfp3gf1hb4 can be different, I
guess.


Cheers,
simon
K
K
Konrad Hinsen wrote on 3 Sep 05:47 -0700
(name . Ludovic Courtès)(address . ludo@gnu.org)
m15xrc52f6.fsf@fastmail.net
Hi Simon,

Toggle quote (7 lines)
> So IIUC, the channels.scm file you provided is not the same channels.scm
> file here. You provided all the revisions to get this Guix and from
> this Guix you tries to reach another revision (named channels.scm in the
> above but just reads 7b0863f07a113caef26fea13909bd97d250b629e).
>
> Right?

Yes!

Toggle quote (3 lines)
> Again IIUC, the picture looks like:
> ...

That looks correct.

Toggle quote (4 lines)
> Well, I do not know how to debug that. :-) Especially without an access
> to the machine and considering the person, from the MOOC, is probably
> new to Guix.

Indeed.

Toggle quote (3 lines)
> Assuming ’guix describe’ returns all the channels as mentioned earlier,
> this is how to check that the current Guix contains the variable.

OK, I'll see if I can explain that in MOOC-level terms ;-)

Thanks,
Konrad.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 72061@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72061
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