bug#72061: Discrepancy when running ‘guix pull’ from different machines

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

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):

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

Digging into the derivation graph reveals the difference below in the
derivation that builds the grafted avahi:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1794 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 254 bytes --]


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’.

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Ludovic Courtès]

Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

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

--8<---------------cut here---------------start------------->8---
$ setarch -R guix time-machine -q  --commit=0ff72d105 -- build avahi -d
/gnu/store/fy39r2y8dg2ycdzvnbqyfd1kpandnpxb-avahi-0.8.drv
--8<---------------cut here---------------end--------------->8---

The “wrong” one:

--8<---------------cut here---------------start------------->8---
$ setarch -R guix time-machine -q  --commit=0ff72d105 -- build avahi -d
/gnu/store/vhj8f01bwddshnc75ar5z62ndcij4pgy-avahi-0.8.drv
--8<---------------cut here---------------end--------------->8---

Ludo’.

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Ludovic Courtès]

Ludovic Courtès <ludo@gnu.org> skribis:

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

--8<---------------cut here---------------start------------->8---
$ 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>
--8<---------------cut here---------------end--------------->8---

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’.

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

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:

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

--8<---------------cut here---------------start------------->8---
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"])
--8<---------------cut here---------------end--------------->8---

compared to:

--8<---------------cut here---------------start------------->8---
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"])
--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---
,["/gnu/store/32kpijl743qn7v337i19dd1hph1rd6x7-avahi-0.8-builder","/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import"]
,["/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import","/gnu/store/z1kanbslzb2lrr1hj922a50zkxl9jz28-avahi-0.8-builder"]
--8<---------------cut here---------------end--------------->8---

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

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Konrad Hinsen]

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

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

Hi Konrad,

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

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

[...]

> 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

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Konrad Hinsen]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

HI Simon,

> Could you share the channels.scm file?

Attached.

> 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 #2: channels.scm --]
[-- Type: application/octet-stream, Size: 1548 bytes --]

(list (channel
       (name 'guix-science)
       (url "https://github.com/guix-science/guix-science.git")
       (branch "master")
       (commit "12eba5aa0c5cbf357c476ef7872e0d562d054eff")
       (introduction
        (make-channel-introduction
         "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc"
         (openpgp-fingerprint
          "CA4F 8CF4 37D7 478F DA05  5FD4 4213 7701 1A37 8446"))))
      (channel
       (name 'flat)
       (url "https://github.com/flatwhatson/guix-channel.git")
       (branch "master")
       (commit "b62ba3214ed0f781e2d6015044ae8a4a1bd5c7d7")
       (introduction
        (make-channel-introduction
         "33f86a4b48205c0dc19d7c036c85393f0766f806"
         (openpgp-fingerprint
          "736A C00E 1254 378B A982  7AF6 9DBE 8265 81B6 4490"))))
      (channel
       (name 'nonguix)
       (url "https://gitlab.com/nonguix/nonguix")
       (branch "master")
       (commit "9fe6f0751bf5770ef4b2afa7bca0b7e51e1382fd")
       (introduction
        (make-channel-introduction
         "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
         (openpgp-fingerprint
          "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"))))      
      (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (branch "master")
       (commit "325fed4c1514bffd084355455710fcc3f1c8da2c")
       (introduction
        (make-channel-introduction
         "9edb3f66fd807b096b48283debdcddccfea34bad"
         (openpgp-fingerprint
          "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

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:

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


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

> 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

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Konrad Hinsen]

Hi Simon,

> 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)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (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.

> 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

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Simon Tournier]

Hi Konrad,

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

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

--8<---------------cut here---------------start------------->8---
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?
--8<---------------cut here---------------end--------------->8---

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


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

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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.

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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

bug#72061: Discrepancy when running ‘guix pull’ from different machines

[Konrad Hinsen]

Hi Simon,

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

> Again IIUC, the picture looks like:
> ...

That looks correct.

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

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