GNU bug report logs - #42420
git-fetch origins produce same store output when set recursive is set to true or false

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42420 in the body.
You can then email your comments to 42420 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: pkill9 <pkill9 <at> runbox.com>
To: bug-guix <at> gnu.org
Subject: git-fetch origins produce same store output when set recursive is
 set to true or false
Date: Sat, 18 Jul 2020 23:19:09 +0100

I built a source that uses git-fetch - by default (recursive? #f) - and
the package failed to build, then I remembered it uses submodules, so I
set (recursive? #t) but it failed with the same error. The problem is
that the store path of the source is the same for both, so it didn't
try to rebuild the git checkout with submodules checked out.

After garbage collecting the source so it rebuilds it, I can build the
package.

Message #8 received at 42420 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <marius <at> gnu.org>
To: pkill9 <pkill9 <at> runbox.com>, 42420 <at> debbugs.gnu.org
Subject: Re: bug#42420: git-fetch origins produce same store output when set
 recursive is set to true or false
Date: Sat, 25 Jul 2020 17:23:21 +0200

[Message part 1 (text/plain, inline)]

pkill9 <pkill9 <at> runbox.com> writes:

> I built a source that uses git-fetch - by default (recursive? #f) - and
> the package failed to build, then I remembered it uses submodules, so I
> set (recursive? #t) but it failed with the same error. The problem is
> that the store path of the source is the same for both, so it didn't
> try to rebuild the git checkout with submodules checked out.
>
> After garbage collecting the source so it rebuilds it, I can build the
> package.

Could it be that you did not update the sha256 checksum of the package
after setting (recursive? #t), so Guix thought it already had the
complete checkout in the store?

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 42420 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Marius Bakke <marius <at> gnu.org>
Cc: pkill9 <pkill9 <at> runbox.com>, 42420 <at> debbugs.gnu.org
Subject: Re: bug#42420: git-fetch origins produce same store output when set
 recursive is set to true or false
Date: Sat, 28 Nov 2020 00:23:28 -0500

Hello,

Marius Bakke <marius <at> gnu.org> writes:

> pkill9 <pkill9 <at> runbox.com> writes:
>
>> I built a source that uses git-fetch - by default (recursive? #f) - and
>> the package failed to build, then I remembered it uses submodules, so I
>> set (recursive? #t) but it failed with the same error. The problem is
>> that the store path of the source is the same for both, so it didn't
>> try to rebuild the git checkout with submodules checked out.
>>
>> After garbage collecting the source so it rebuilds it, I can build the
>> package.
>
> Could it be that you did not update the sha256 checksum of the package
> after setting (recursive? #t), so Guix thought it already had the
> complete checkout in the store?

Yes, that just happened to me.  It's confusing, but I don't see how we
can improve on that. pkill, next time this happens, you might want to
force a check on the cached source via 'guix build --source --check'.  I
believe this would flag the discrepancy.

Is there an action to do here, or should we simply close it?

Thanks,

Maxim

Message #16 received at 42420-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 42420-done <at> debbugs.gnu.org, pkill9 <pkill9 <at> runbox.com>,
 Marius Bakke <marius <at> gnu.org>
Subject: Re: bug#42420: git-fetch origins produce same store output when set
 recursive is set to true or false
Date: Sat, 28 Nov 2020 12:04:16 -0500

On Sat, Nov 28, 2020 at 12:23:28AM -0500, Maxim Cournoyer wrote:
> Is there an action to do here, or should we simply close it?

If we have a good idea for how to improve the situation, we should use
it. Otherwise, we can close the bug. It's something that confuses a lot
of people the first time but, once you learn what's happening, it's easy
to avoid in the future.

Message #19 received at 42420-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: 42420-done <at> debbugs.gnu.org, pkill9 <pkill9 <at> runbox.com>,
 Marius Bakke <marius <at> gnu.org>
Subject: Re: bug#42420: git-fetch origins produce same store output when set
 recursive is set to true or false
Date: Sun, 29 Nov 2020 23:06:09 -0500

Hello,

Leo Famulari <leo <at> famulari.name> writes:

> On Sat, Nov 28, 2020 at 12:23:28AM -0500, Maxim Cournoyer wrote:
>> Is there an action to do here, or should we simply close it?
>
> If we have a good idea for how to improve the situation, we should use
> it. Otherwise, we can close the bug. It's something that confuses a lot
> of people the first time but, once you learn what's happening, it's easy
> to avoid in the future.

I don't; it'd involve changing the way fixed-output derivations are
cached, such as keeping metadata about the sources for fixed hash
derivations (e.g., "There's a hash in the store matching what the
sources tells me, but was it produced from the same origin source?"),
and I don't see how that'd be a good thing.  Note that 'guix build
--source --check' can be used when in doubt that the origin really
computes to the in-store item matching its declared hash.

I've just documented so in the hope users will find it in the manual
when they stumble on such a situation; see commit
3462678bc346c2f6ea81245d6842264b6dccd945.

I'm closing the issue for now.

We can try to do more if it comes back too often.

Thank you,

Maxim

Previous Next

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