GNU logs - #77716, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#77716: Corrupted store after Guix deploy
Resent-From: Tomas Volf <~@wolfsden.cz>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 10 Apr 2025 21:34:01 +0000
Resent-Message-ID: <handler.77716.B.174432080028281 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 77716 <at> debbugs.gnu.org
From: Tomas Volf <~@wolfsden.cz>
Date: Thu, 10 Apr 2025 23:32:53 +0200
Message-ID: <87iknb66t6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=37.205.8.62; envelope-from=~@wolfsden.cz;
 helo=wolfsden.cz
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello,

I just finished Guix deploy.  The command has finished successfully,
without any warnings or errors.  However when I checked the store, I can
see that some paths are corrupted:

--8<---------------cut here---------------start------------->8---
$ guix gc --verify=3Dcontents
reading the store...
checking path existence...
checking hashes...
path `/gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden' was modified! e=
xpected hash `b40d36eb683b0143cb192e37ba18f1bb31a437016e8a2f82a3623942b39c9=
3b8', got `b3ecf9df08d6bd70dc2482ff68d606802aa8d1623b8efd8bcd0485bbe670cd4c'
path `/gnu/store/my2g20c7spa8ixpnr92s302wj97cxl86-nonguix' was modified! ex=
pected hash `4e478e5e311d2a1205b01681de5d4fd2aaba7e9367bdf83ac2c74b3a18322b=
c5', got `9b8c244c6a1592c1a067bb0f1682b087322258c52dd91a95da7f2d7fbb03a7c3'
--8<---------------cut here---------------end--------------->8---

I know there already are some issues in the similar spirit, but
consensus there seems to be that missing/wrong sync is to blame.  So I
am making a new bug, because this one is not affected by (possible) sync
issues.  I did not even reboot (yet), I have verified the store *before*
rebooting.

Indeed, the guix hashes do differ:

Laptop:

--8<---------------cut here---------------start------------->8---
$ guix hash -r /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
1f4kkjrl4fb2lf12z2kf04vs8cdvy4cbldrf375l609vd3mkc3dl
--8<---------------cut here---------------end--------------->8---

Remote:

--8<---------------cut here---------------start------------->8---
$ guix hash -r /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
0k6df3kbp184rn5zv3ivcb8shal00vb6izw24kf71gfn13gzkv5k
--8<---------------cut here---------------end--------------->8---

I have checked the files themselves (sha256sum), and they are the same
on both machines.  However I have noticed couple of differences listed
below:

The permissions on the very top level directory differ (which one are
correct?):

Laptop:

--8<---------------cut here---------------start------------->8---
$ ls -al /gnu/store/ | grep 1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
drwxr-xr-x   1 root          root              16 Jan  1  1970 1bjf1lza4i7f=
c1jh8qzb1n9xnv3rfi17-wolfsden
--8<---------------cut here---------------end--------------->8---

Remote:

--8<---------------cut here---------------start------------->8---
$ ls -al /gnu/store/ | grep 1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
dr-xr-xr-x  1 root root           16 Jan  1  1970 1bjf1lza4i7fc1jh8qzb1n9xn=
v3rfi17-wolfsden
--8<---------------cut here---------------end--------------->8---



The target of symbolic link in the store item differs.

Laptop:

--8<---------------cut here---------------start------------->8---
$ ls -l /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile/si=
te/
total 4
lrwxrwxrwx 1 root root 61 Jan  1  1970 3.0 -> /gnu/store/rmwi813mcsg8d5ilzq=
0rxwqd8dp558r5-wolfsden-989d91d/
--8<---------------cut here---------------end--------------->8---

Remote:

--8<---------------cut here---------------start------------->8---
$ ls -l /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile/si=
te/
total 4
lrwxrwxrwx 1 root root 60 Jan  1  1970 3.0 -> /gnu/store/rmwi813mcsg8d5ilzq=
0rxwqd8dp558r5-wolfsden-989d91d
--8<---------------cut here---------------end--------------->8---

Notice that for the Laptop, the target ends in `/', for the Remote it
does not.



Additionally it is interesting that in addition I have exactly on more
corrupted path, and that is another channel:

--8<---------------cut here---------------start------------->8---
$ guix gc --verify=3Dcontents
reading the store...
checking path existence...
checking hashes...
path `/gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden' was modified! e=
xpected hash `b40d36eb683b0143cb192e37ba18f1bb31a437016e8a2f82a3623942b39c9=
3b8', got `b3ecf9df08d6bd70dc2482ff68d606802aa8d1623b8efd8bcd0485bbe670cd4c'
path `/gnu/store/my2g20c7spa8ixpnr92s302wj97cxl86-nonguix' was modified! ex=
pected hash `4e478e5e311d2a1205b01681de5d4fd2aaba7e9367bdf83ac2c74b3a18322b=
c5', got `9b8c244c6a1592c1a067bb0f1682b087322258c52dd91a95da7f2d7fbb03a7c3'
--8<---------------cut here---------------end--------------->8---



I have copied the store item back using `rsync -a ...', and this is what
diffoscope has to say (the same as above):

--8<---------------cut here---------------start------------->8---
2025-04-10 21:06:56 W: diffoscope.comparators.xml: Vulnerable version of py=
expat detected; disabling comparison of XML documents. Install defusedxml o=
r upgrade your pyexpat.
--- /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
+++ /tmp/xxxx/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
=E2=94=9C=E2=94=80=E2=94=80 /gnu/store/lm25j7769nfzgfmx8gh28zarrlczgh8r-cor=
eutils-9.1/bin/stat {}
=E2=94=82 @@ -1,8 +1,8 @@
=E2=94=82
=E2=94=82    Size: 16        	Blocks: 0          IO Block: 4096   directory
=E2=94=82  Device: 0,25	Links: 1
=E2=94=82 -Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ =
   root)
=E2=94=82 +Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/ =
   root)
=E2=94=82
=E2=94=82  Modify: 1970-01-01 00:00:01.000000000 +0000
=E2=94=82   --- /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share
=E2=94=9C=E2=94=80=E2=94=80 +++ /tmp/xxxx/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-=
wolfsden/share
=E2=94=82 =E2=94=82   --- /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfs=
den/share/guile
=E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 +++ /tmp/xxxx/1bjf1lza4i7fc1jh8qzb1n9=
xnv3rfi17-wolfsden/share/guile
=E2=94=82 =E2=94=82 =E2=94=82   --- /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3r=
fi17-wolfsden/share/guile/site
=E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 +++ /tmp/xxxx/1bjf1lza4i7fc=
1jh8qzb1n9xnv3rfi17-wolfsden/share/guile/site
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82   --- /gnu/store/1bjf1lza4i7fc1jh8q=
zb1n9xnv3rfi17-wolfsden/share/guile/site/3.0
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 +++ /tmp/xxxx/1bj=
f1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile/site/3.0
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82=E2=94=84 symlink
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 @@ -1 +1 @@
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 +destination: /gnu/store/rmwi813mcs=
g8d5ilzq0rxwqd8dp558r5-wolfsden-989d91d
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 -destination: /gnu/store/rmwi813mcs=
g8d5ilzq0rxwqd8dp558r5-wolfsden-989d91d/
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 /gnu/st=
ore/lm25j7769nfzgfmx8gh28zarrlczgh8r-coreutils-9.1/bin/stat {}
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 @@ -1,8 +1,8 @@
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 +  Size: 60        	Block=
s: 8          IO Block: 4096   symbolic link
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 -  Size: 61        	Block=
s: 8          IO Block: 4096   symbolic link
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82  Device: 0,25	Links: 1
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82  Access: (0777/lrwxrwxrwx=
)  Uid: (    0/    root)   Gid: (    0/    root)
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82
=E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82  Modify: 1970-01-01 00:00=
:01.000000000 +0000
--8<---------------cut here---------------end--------------->8---

Any idea what might have happen?

I cannot really reproduce it now, not sure it the issue went away with
newer Guix or whether it was random flap.  I just wonder whether the
other end should not checksum the entries before putting them into the
store and reject them if the hash is wrong.

Tomas

--=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Tomas Volf <~@wolfsden.cz>
Subject: bug#77716: Acknowledgement (Corrupted store after Guix deploy)
Message-ID: <handler.77716.B.174432080028281.ack <at> debbugs.gnu.org>
References: <87iknb66t6.fsf@HIDDEN>
X-Gnu-PR-Message: ack 77716
X-Gnu-PR-Package: guix
Reply-To: 77716 <at> debbugs.gnu.org
Date: Thu, 10 Apr 2025 21:34:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 77716 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
77716: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77716
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#77716: Corrupted store after Guix deploy
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 21 Apr 2025 15:19:02 +0000
Resent-Message-ID: <handler.77716.B77716.174524871429203 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Tomas Volf <~@wolfsden.cz>
Cc: 77716 <at> debbugs.gnu.org
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <87iknb66t6.fsf@HIDDEN> (Tomas Volf's message of "Thu, 10
 Apr 2025 23:32:53 +0200")
References: <87iknb66t6.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Mon, 21 Apr 2025 16:47:12 +0200
Message-ID: <87o6wp8tcf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hello,

Tomas Volf <~@wolfsden.cz> writes:

> The permissions on the very top level directory differ (which one are
> correct?):
>
> Laptop:
>
> --8<---------------cut here---------------start------------->8---
> $ ls -al /gnu/store/ | grep 1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
> drwxr-xr-x   1 root          root              16 Jan  1  1970 1bjf1lza4i=
7fc1jh8qzb1n9xnv3rfi17-wolfsden
> --8<---------------cut here---------------end--------------->8---
>
> Remote:
>
> --8<---------------cut here---------------start------------->8---
> $ ls -al /gnu/store/ | grep 1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
> dr-xr-xr-x  1 root root           16 Jan  1  1970 1bjf1lza4i7fc1jh8qzb1n9=
xnv3rfi17-wolfsden
> --8<---------------cut here---------------end--------------->8---
>
>
>
> The target of symbolic link in the store item differs.
>
> Laptop:
>
> --8<---------------cut here---------------start------------->8---
> $ ls -l /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile/=
site/
> total 4
> lrwxrwxrwx 1 root root 61 Jan  1  1970 3.0 -> /gnu/store/rmwi813mcsg8d5il=
zq0rxwqd8dp558r5-wolfsden-989d91d/
> --8<---------------cut here---------------end--------------->8---
>
> Remote:
>
> --8<---------------cut here---------------start------------->8---
> $ ls -l /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile/=
site/
> total 4
> lrwxrwxrwx 1 root root 60 Jan  1  1970 3.0 -> /gnu/store/rmwi813mcsg8d5il=
zq0rxwqd8dp558r5-wolfsden-989d91d
> --8<---------------cut here---------------end--------------->8---
>
> Notice that for the Laptop, the target ends in `/', for the Remote it
> does not.

Interesting.

There are several code paths to add a store item to the store.  One is
through (guix store =E2=80=A6), use by =E2=80=98guix offload=E2=80=99.  One=
 is through =E2=80=98guix
substitute=E2=80=99, which restores nars it downloaded.  One is through a b=
uild
via guix-daemon (C++ code).

Could you tell how these two differing things were obtained?

On each machine, run =E2=80=98guix build --log-file /gnu/store/1bjf1lza4i7f=
c1jh8qzb1n9xnv3rfi17-wolfsden=E2=80=99.  If
there=E2=80=99s a local log file, it was built locally or offloaded; otherw=
ise
it was substituted.

Could you also report the guix-daemon versions that are running on each
machine?

An interesting puzzle.  :-)

Thanks,
Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

Subject: bug#77716: Corrupted store after Guix deploy
Resent-From: Tomas Volf <~@wolfsden.cz>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 21 Apr 2025 18:35:02 +0000
Resent-Message-ID: <handler.77716.B77716.17452605015940 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: 77716 <at> debbugs.gnu.org
From: Tomas Volf <~@wolfsden.cz>
In-Reply-To: <87o6wp8tcf.fsf@HIDDEN> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Mon, 21 Apr 2025 16:47:12 +0200")
References: <87iknb66t6.fsf@HIDDEN> <87o6wp8tcf.fsf@HIDDEN>
Date: Mon, 21 Apr 2025 20:34:52 +0200
Message-ID: <87tt6h748j.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Hello,
>
> Tomas Volf <~@wolfsden.cz> writes:
>
>> The permissions on the very top level directory differ (which one are
>> correct?):
>>
>> Laptop:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ ls -al /gnu/store/ | grep 1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
>> drwxr-xr-x   1 root          root              16 Jan  1  1970 1bjf1lza4=
i7fc1jh8qzb1n9xnv3rfi17-wolfsden
>> --8<---------------cut here---------------end--------------->8---
>>
>> Remote:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ ls -al /gnu/store/ | grep 1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden
>> dr-xr-xr-x  1 root root           16 Jan  1  1970 1bjf1lza4i7fc1jh8qzb1n=
9xnv3rfi17-wolfsden
>> --8<---------------cut here---------------end--------------->8---
>>
>>
>>
>> The target of symbolic link in the store item differs.
>>
>> Laptop:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ ls -l /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile=
/site/
>> total 4
>> lrwxrwxrwx 1 root root 61 Jan  1  1970 3.0 -> /gnu/store/rmwi813mcsg8d5i=
lzq0rxwqd8dp558r5-wolfsden-989d91d/
>> --8<---------------cut here---------------end--------------->8---
>>
>> Remote:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ ls -l /gnu/store/1bjf1lza4i7fc1jh8qzb1n9xnv3rfi17-wolfsden/share/guile=
/site/
>> total 4
>> lrwxrwxrwx 1 root root 60 Jan  1  1970 3.0 -> /gnu/store/rmwi813mcsg8d5i=
lzq0rxwqd8dp558r5-wolfsden-989d91d
>> --8<---------------cut here---------------end--------------->8---
>>
>> Notice that for the Laptop, the target ends in `/', for the Remote it
>> does not.
>
> Interesting.
>
> There are several code paths to add a store item to the store.  One is
> through (guix store =E2=80=A6), use by =E2=80=98guix offload=E2=80=99.  O=
ne is through =E2=80=98guix
> substitute=E2=80=99, which restores nars it downloaded.  One is through a=
 build
> via guix-daemon (C++ code).
>
> Could you tell how these two differing things were obtained?
>
> On each machine, run =E2=80=98guix build --log-file /gnu/store/1bjf1lza4i=
7fc1jh8qzb1n9xnv3rfi17-wolfsden=E2=80=99.  If
> there=E2=80=99s a local log file, it was built locally or offloaded; othe=
rwise
> it was substituted.

Definitely, I am pretty sure I know how these were acquired.  It is my
personal Guix channel, and I am not using any substitutes other then the
official ones.  On my local system (the "Laptop" above), I have executed
the following:

=2D-8<---------------cut here---------------start------------->8---
guix pull --no-offload -C wolfsnet/files/channels-base.sex
=2D-8<---------------cut here---------------end--------------->8---

During that, Guix was pulled using this channels file:

=2D-8<---------------cut here---------------start------------->8---
(cons* (channel
        (name 'guix)
        (url "https://git.wolfsden.cz/.git/guix")
        (introduction
         (make-channel-introduction
          "028e445a2028068e3c83996daa281057f19141a0"
          (openpgp-fingerprint
           "B783 49B3 8C14 7D36 2988  68A4 2FBF EE7D B67F C1A9"))))
       (channel
        (name 'wolfsden)
        (url "https://git.wolfsden.cz/.git/wolfsden")
        (introduction
         (make-channel-introduction
          "49d7c72d2c3ae36ae8cf045dc7c00da29801af2c"
          (openpgp-fingerprint
           "B783 49B3 8C14 7D36 2988  68A4 2FBF EE7D B67F C1A9"))))
       (channel
        (name 'nonguix)
        (url "https://gitlab.com/nonguix/nonguix")
        (introduction
         (make-channel-introduction
          "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
          (openpgp-fingerprint
           "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"))))
       (filter (negate guix-channel?) %default-channels))
=2D-8<---------------cut here---------------end--------------->8---

Since 'wolfsden has no substitutes on official servers, the store item
was built locally (on "Laptop").  After that, I did `guix deploy' onto
"Remote".  Since I am using the channel in few places in the system
definition, it was copied over to "Remote" as part of the deploy.

Additionally I am using the "current" Guix as the (guix) field of the
guix-configuration, but I am pretty sure that is not relevant here, so I
am including it just for completeness (in case I am wrong).

=2D-8<---------------cut here---------------start------------->8---
(define (%current-guix)
  (let ((guix-bin (car (command-line))))
    (unless (string-suffix? "/bin/guix" guix-bin)
      (error "Does not look like guix binary" guix-bin))
    (let* ((guix-profile (string-drop-right guix-bin 9))
           (guix-profile (canonicalize-path guix-profile)))
      (package
        (name "custom-guix")
        (version "1")
        (source #f)
        (build-system trivial-build-system)
        (arguments
         (list
          #:builder
          #~(symlink #$guix-profile #$output)))
        (home-page #f)
        (synopsis #f)
        (description #f)
        (license #f)))))

[..]

(operating-system
        ...
        (services
          (modify-services %base-services
            (guix-service-type
             config =3D> (guix-configuration
                        (inherit config)
                        (channels %channels)
                        (guix (%current-guix)))))))
=2D-8<---------------cut here---------------end--------------->8---

To sum up, to the "broken" system ("Remote") the store item got via
`guix deploy'.

>
> Could you also report the guix-daemon versions that are running on each
> machine?

Sadly I am not sure how to tell now :/.  My laptop got updated and the
VM got shut down.  I will be sure to gather this information next time.
Maybe it would be useful to include this information in the log files
for the builds.  All I can say now is that guix-daemon on both was
"reasonably recent", definitely under 2 months old, probably under
month.

>
> An interesting puzzle.  :-)

I am glad you have found this interesting. :)

Tomas

=2D-=20
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJCBAEBCgAsFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmgGj80OHH5Ad29sZnNk
ZW4uY3oACgkQL7/ufbZ/wakdahAArzOksm76LIjrbW6LSXvyUXGueyN5ivw0P0XS
XqvknwNM/ddt8LI7ZSX1N7VB2jSVBjr8PEuwmUO1sZQ95p5gFcaSl5ZxaE+aZjsF
v5hN2LVQz49tqURYs1V/Cfrb3IsXkUZMFYDR7tW6uIIK89VPqvv6NTEyoYH1tliX
QqtRCZc0iPPrVmSz/rHfCpjArX76OdI/xSHUM2d2lXwJF9n8+XV1MbVkPSeFPjTh
trVKg5eK2PakOkMEwSxSVHciohTC/3ivcA+NCfKH3wJpmvWDUOHY+SmBDYqByjMp
+YbfzPjoRbNlvR6LJ7nNQko+grAEWyO1iL0U3EvguA7Vvqmiewp2BFDbgFHb9MjD
OccyUdFj0sxEAOljeXtVar/MP1y83T2GNWn+DTLEzmEJwV+UMmSdnlYiH//hlnK0
mTMFE/bKIwVNSjCkvhcttQ5FutB3n+Tjbh4F+VnIaNXu+kjxqi5zJ6uaPqiSZXpG
8u2XgUOSHF0HYtvVvjSXizUThCwpDZq8RU/xql8ojROPmOtCHRHOrFLsRniYIxz3
fz1+kguyKw5EScmLMu3bZO6sjfWxRn9VptAT8wkfGW/gmxNd1fPmH0LSSRXGE0fO
YAny2Ez6i4FCsxhWUc5BE8Okqm5AodCgGTDsKNof2xP4Y54dqT45bJE8oL0Um8hc
G1MXfPA=
=rOpT
-----END PGP SIGNATURE-----
--=-=-=--

Last modified: Mon, 21 Apr 2025 18:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.