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

OpenSubmitted by Mark H Weaver.
Details
2 participants
  • Ludovic Courtès
  • Mark H Weaver
Owner
unassigned
Severity
minor
M
M
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 anenormous amount of time building the new guix master branch based onoutdated bootstrap/*/guile-2.0.9.tar.xz.
The issue is that if you simply "git pull" from a build directory witholder versions of bootstrap/*/guile-2.0.9.tar.xz, although the variousplaces where the hashes are stored are updated, those new hashes arenever checked against the existing files. Therefore, you can proceed tobuild an entire system based on an outdated bootstrap guile, and withhashes that don't match what's on hydra and what other people arebuilding.
It would be good if the hashes were checked even if they are alreadypresent in the build directory.
Mark
M
M
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 thisproblem in the recent merge of core-updates. The reason is that thebootstrap guile for MIPS was updated without changing its versionnumber, whereas the Intel ones were 2.0.7 before the update.
Mark
L
L
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 Guiletarballs, because it doesn’t try to download it (see ‘build-guix’ inguix/build/pull.scm.) That’s rare in practice, but still a seriouslimitation as you note. :-/
There are other things to do in ‘guix pull’, such as authentication, andimproved bandwidth usage. For the latter an option would be to resortto git, and perhaps for the former too.
Ludo’.
M
M
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 talkingabout "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
L
L
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. Onlybuild-aux/download.scm checks the hash, so indeed, if the file is staleor 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’.
M
M
Mark H Weaver wrote on 13 Apr 2014 05:29
(no subject)
(address . control@debbugs.gnu.org)
87k3atewk8.fsf@yeeloong.lan
severity 15890 wishlistseverity 17208 wishlistseverity 17150 minorseverity 17202 minorthanks
?