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

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

[pkill9]

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.

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

[Marius Bakke]

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

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Maxim Cournoyer]

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

[Leo Famulari]

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.

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

[Maxim Cournoyer]

Hello,

Leo Famulari <leo@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