[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42420: git-fetch origins produce same store output when set recursiv
From: |
Maxim Cournoyer |
Subject: |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hello,
Marius Bakke <marius@gnu.org> writes:
> pkill9 <pkill9@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
- bug#42420: git-fetch origins produce same store output when set recursive is set to true or false,
Maxim Cournoyer <=