***verne.freenode.net sets mode: +o ChanServ
<civodul>zimoun: do you mind if i change things right there? <civodul>two comments: should we include the bit about tarballs? (i'd say no, or it would need much more discussion, but that's beyond the scope) <civodul>should we include the bit about implicit dependencies? not sure, but it's also hard to understand without more context <zimoun>I have read it. Cool! Naive question: how do you do the correct quote ' lkie here e’s ? <zimoun>I would say yes for both :-) Implicit dependencies is second line in the reference link. And I think it is comprehensible. Well, about tarball, I am too close, so yes you have probably right, it is better to skip <civodul>the paragraph about python 2.4 vs. gcc and implicit dependencies is a bit too dense/hard to follow IMO <civodul>for instance, it's not clear what the python vs. gcc problem is <civodul>and it's perhaps not clear to outsiders how that relates to implicit dependencies <zimoun>well, I am trying to put my outsider glasses. :-) <zimoun>To me, it is clear. But I am biaised. :-) Yes, let remove it. <civodul>(i do agree that it's an important question, though!) <zimoun>Do you push? Then I will send an email to guix-hpc and guix-devel <zimoun>Konrad have 2 minors remarks, one about link of Numpy 1.5.2 *zimoun commute, back in ~1 hour <civodul>you took Konrad's input into account somehow, right? <zimoun>it is not pushed because I was waiting another if he has. <zimoun>civodul: I have just pulled and everything is ok :-) <zimoun>Well, I write and send the email right now. Good? <zimoun>civodul: the hash used by vault-fetch comes from (revision-directory revision) and the revision comes from lookup-revision, so somehow Guix does not compute the hash and Guix trust SWH, verifying then the integrity. Right? <civodul>zimoun: yes, Guix always verifies the integrity of the thing it downloads <civodul>so we don't need to trust the server or the method used to produce the result <zimoun>yes but we are not sure that SWH always returns the expected Git content. I mean it is the same issue than the tarball <civodul>that's OK: if SWH (or git, or tar, etc.) returns garbage, this is detected and an error is raised <zimoun>yes so it is the exact same problem for Git-reference and for Tarball. Guix sends to SWH an hash (commit-hash or checksum) and SWH returns content then Guix checks the integrity. I do not see why tarball is more problematic than git. <zimoun>we are not sure to fallback even for git-reference <civodul>the fallback code that was broken is no longer broken, right? :-) <zimoun>but I have investigating to do stats about coverage and this kind of stuff <civodul>you mean: "not broken", "no, broken", or "no longer broken"? :-) <civodul>did your coverage script eventually complete? <zimoun>no because it is one request every 30 sec so it could take 116 hours to complete <zimoun>my point about falling back is: Guix asks for a revision which contains a path with "cryptic" hash and this path-url is used to download and then integrity check.