Stale bootstrap/*/guile-2.0.9.tar.xz files are not detected

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Mark H Weaver
Owner
unassigned
Submitted by
Mark H Weaver
Severity
minor

Debbugs page

Mark H Weaver wrote on 31 Mar 2014 21:20
(address . bug-guix@gnu.org)
8761munpip.fsf@yeeloong.lan
I just realized that my x86_64 and Loongson 3A systems have spent an
enormous amount of time building the new guix master branch based on
outdated bootstrap/*/guile-2.0.9.tar.xz.

The issue is that if you simply "git pull" from a build directory with
older versions of bootstrap/*/guile-2.0.9.tar.xz, although the various
places where the hashes are stored are updated, those new hashes are
never checked against the existing files. Therefore, you can proceed to
build an entire system based on an outdated bootstrap guile, and with
hashes that don't match what's on hydra and what other people are
building.

It would be good if the hashes were checked even if they are already
present in the build directory.

Mark
Mark H Weaver wrote on 31 Mar 2014 21:40
(address . 17150@debbugs.gnu.org)
871txinol0.fsf@yeeloong.lan
I wrote:
Toggle quote (4 lines)
> I just realized that my x86_64 and Loongson 3A systems have spent an
> enormous amount of time building the new guix master branch based on
> outdated bootstrap/*/guile-2.0.9.tar.xz.

Upon further investigation, I see that only MIPS was affected by this
problem in the recent merge of core-updates. The reason is that the
bootstrap guile for MIPS was updated without changing its version
number, whereas the Intel ones were 2.0.7 before the update.

Mark
Ludovic Courtès wrote on 1 Apr 2014 00:19
(name . Mark H Weaver)(address . mhw@netris.org)(address . 17150@debbugs.gnu.org)
8761mu57ui.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (12 lines)
> I just realized that my x86_64 and Loongson 3A systems have spent an
> enormous amount of time building the new guix master branch based on
> outdated bootstrap/*/guile-2.0.9.tar.xz.
>
> The issue is that if you simply "git pull" from a build directory with
> older versions of bootstrap/*/guile-2.0.9.tar.xz, although the various
> places where the hashes are stored are updated, those new hashes are
> never checked against the existing files. Therefore, you can proceed to
> build an entire system based on an outdated bootstrap guile, and with
> hashes that don't match what's on hydra and what other people are
> building.

Right, ‘guix pull’ doesn’t survive updates of the bootstrap Guile
tarballs, because it doesn’t try to download it (see ‘build-guix’ in
guix/build/pull.scm.) That’s rare in practice, but still a serious
limitation as you note. :-/

There are other things to do in ‘guix pull’, such as authentication, and
improved bandwidth usage. For the latter an option would be to resort
to git, and perhaps for the former too.

Ludo’.
Mark H Weaver wrote on 1 Apr 2014 00:51
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 17150@debbugs.gnu.org)
87lhvqm179.fsf@yeeloong.lan
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (19 lines)
> Mark H Weaver <mhw@netris.org> skribis:
>
>> I just realized that my x86_64 and Loongson 3A systems have spent an
>> enormous amount of time building the new guix master branch based on
>> outdated bootstrap/*/guile-2.0.9.tar.xz.
>>
>> The issue is that if you simply "git pull" from a build directory with
>> older versions of bootstrap/*/guile-2.0.9.tar.xz, although the various
>> places where the hashes are stored are updated, those new hashes are
>> never checked against the existing files. Therefore, you can proceed to
>> build an entire system based on an outdated bootstrap guile, and with
>> hashes that don't match what's on hydra and what other people are
>> building.
>
> Right, ‘guix pull’ doesn’t survive updates of the bootstrap Guile
> tarballs, because it doesn’t try to download it (see ‘build-guix’ in
> guix/build/pull.scm.) That’s rare in practice, but still a serious
> limitation as you note. :-/

Hmm, yes, I suppose that "guix pull" is more relevant for typical users,
but actually that's not what I was talking about above. I was talking
about "git pull" followed by "make".

Toggle quote (4 lines)
> There are other things to do in ‘guix pull’, such as authentication, and
> improved bandwidth usage. For the latter an option would be to resort
> to git, and perhaps for the former too.

Yes, it seems to me that git is a good tool for this job.

Mark
Ludovic Courtès wrote on 1 Apr 2014 11:50
(name . Mark H Weaver)(address . mhw@netris.org)(address . 17150@debbugs.gnu.org)
87eh1hl6pb.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (25 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> I just realized that my x86_64 and Loongson 3A systems have spent an
>>> enormous amount of time building the new guix master branch based on
>>> outdated bootstrap/*/guile-2.0.9.tar.xz.
>>>
>>> The issue is that if you simply "git pull" from a build directory with
>>> older versions of bootstrap/*/guile-2.0.9.tar.xz, although the various
>>> places where the hashes are stored are updated, those new hashes are
>>> never checked against the existing files. Therefore, you can proceed to
>>> build an entire system based on an outdated bootstrap guile, and with
>>> hashes that don't match what's on hydra and what other people are
>>> building.
>>
>> Right, ‘guix pull’ doesn’t survive updates of the bootstrap Guile
>> tarballs, because it doesn’t try to download it (see ‘build-guix’ in
>> guix/build/pull.scm.) That’s rare in practice, but still a serious
>> limitation as you note. :-/
>
> Hmm, yes, I suppose that "guix pull" is more relevant for typical users,
> but actually that's not what I was talking about above. I was talking
> about "git pull" followed by "make".

Ah, sorry! Ah yes, I see what the problem is. Only
build-aux/download.scm checks the hash, so indeed, if the file is stale
or modified later, Guix doesn’t notice.

Perhaps we should add a ‘check-hash’ rule or something in the makefile,
that automatically triggers before installation or something?

Ludo’.
Mark H Weaver wrote on 13 Apr 2014 05:29
(no subject)
(address . control@debbugs.gnu.org)
87k3atewk8.fsf@yeeloong.lan
severity 15890 wishlist
severity 17208 wishlist
severity 17150 minor
severity 17202 minor
thanks
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 17150
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