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

  • Done
  • quality assurance status badge
Details
4 participants
  • Leo Famulari
  • Marius Bakke
  • Maxim Cournoyer
  • pkill9
Owner
unassigned
Submitted by
pkill9
Severity
normal

Debbugs page

pkill9 wrote 5 years ago
(address . bug-guix@gnu.org)
20200718231909.646cbf7d@runbox.com
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.
Marius Bakke wrote 5 years ago
(name . pkill9)(address . pkill9@runbox.com)(address . 42420@debbugs.gnu.org)
878sf7vct2.fsf@gnu.org
pkill9 <pkill9@runbox.com> writes:

Toggle quote (9 lines)
> 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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl8cTmkACgkQoqBt8qM6
VPqChQgAmEo3rfiBVE4cGo0Kr//D8l+o6OYWMbaL8zZ+0N2UCcma1F4sMxjmJYNM
qOG4kpGZlnfRD1aLA82OJd86rFe1msnx/FkFhW46Bc7qyJWmMLVkgQgdZxkmwQFi
sETM4ldpMiC4i9TmjCX3R2NoJad54b1/1uZgEQLxHiHeWmvxC39dDzP9BSgRakQg
Let19IwDk9nvlhDnKTppIAUdWebpVeNNng3wjOkZTJndD7KaMmQlz6nUh+syUC2O
1HL8tcsctoOJ5RPhXGiD7JcUxyPCx+Tdfo4xoCFh+dUA7GJuB74WlQaTlcDK0+aN
20tfSw97iJGWektO7qDkBWBtR66P8Q==
=hujc
-----END PGP SIGNATURE-----

Maxim Cournoyer wrote 4 years ago
(name . Marius Bakke)(address . marius@gnu.org)(name . pkill9)(address . pkill9@runbox.com)(address . 42420@debbugs.gnu.org)
87czzynjfz.fsf@gmail.com
Hello,

Marius Bakke <marius@gnu.org> writes:

Toggle quote (15 lines)
> 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
Leo Famulari wrote 4 years ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 42420-done@debbugs.gnu.org)(name . pkill9)(address . pkill9@runbox.com)(name . Marius Bakke)(address . marius@gnu.org)
X8KDEGHXrMRwk1sm@jasmine.lan
On Sat, Nov 28, 2020 at 12:23:28AM -0500, Maxim Cournoyer wrote:
Toggle quote (2 lines)
> 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.
Closed
Maxim Cournoyer wrote 4 years ago
(name . Leo Famulari)(address . leo@famulari.name)(address . 42420-done@debbugs.gnu.org)(name . pkill9)(address . pkill9@runbox.com)(name . Marius Bakke)(address . marius@gnu.org)
87czzvmqtq.fsf@gmail.com
Hello,

Leo Famulari <leo@famulari.name> writes:

Toggle quote (8 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 42420@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 42420
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help