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

Previous Next

Full log

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

Previous Next

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