IRC channel logs


back to list of logs

<zimoun>I wrote a blog post where I list why Guix rocks in scientific context:
<zimoun>Yet another one :-)
<civodul>hmm, hash mismatch on python-jaxlib:
<zimoun>civodul: bad luck!
<zimoun>On my side, I am fighting with past Bioconductor release…
<civodul>source that vanished?
<zimoun>Not really, moved to unexpected places.
<zimoun>What is terrible (in addition to missing Disarchive entry blabla), SWH also misses some version.
<zimoun>I am doing a follow up “some years later” about our Nature paper’s example. All in all, it is a good example for demoing – as I did in Pasteur Institute on past Thurday :-
<zimoun>En revanche, ca y est, je tombe aussi sur un hash mismatch! Damned!
<zimoun>Better /gnu/store/5257ay3c3qkiy51yv4frsvmjmh3hxk08-codetools_0.2-16.tar.gz.drv :-)
<zimoun>CRAN package
<civodul>missing Disarchive entries?
<civodul>do you have an example?
<zimoun>many ;-)
<civodul>awesome :-)
<civodul>i’m curious to see what’s failing on our side
<zimoun>And populate Disarchive database.
<zimoun>However, we are doomed with hash mismatch as /gnu/store/5257ay3c3qkiy51yv4frsvmjmh3hxk08-codetools_0.2-16.tar.gz.drv
<civodul>zimoun: but why is this particular tarball neither on ci.guix nor on disarchive.guix?
<civodul>i would expect it to be picked up by the ‘source’ and ‘disarchive’ jobsets, no?
<civodul>maybe it wasn’t there before?
<zimoun>Not on ci.guix because it had probably been GC.
<zimoun>About Disarchive, probably because we are speaking about something from 2020 and we still have holes.
<zimoun>Hopefully, package transformation allows to rewrite on the fly and still build something :-)
<zimoun>For now, it builds GCC@7.4.0…
<zimoun>BTW, civodul the jobset are for codetools_0.2-19 and codetools_0.2-18 when I am interested in codetools_0.2-16 :-)
<rekado>the jaxlib thing is a real problem
<rekado>I mentioned this last time when I worked on it. Something about how we embed a store file name for the computed sources, which depend on the inputs of the package embedding it.
<rekado>when the inputs of the target package change the store file name of the computed sources changes, even though the contents are identical
<rekado>so as seemingly unrelated packages in Guix keep moving ahead, the bundled sources will be recomputed and get a new file name every time
<civodul>rekado: ooh right, i remember you mentioned it before
<civodul>‘bazel-vendored-inputs’ should have #:allow-references '() to avoid mistakes
<civodul>er, #:allowed-references '()
<civodul>anyhow, we need to figure out what store file name gets embedded