IRC channel logs
2023-10-24.log
back to list of logs
<rekado>guix weather says that the server only has 1/2 of the necessary substitutes <rekado>never mind; now I get both substitutes <civodul>i did not enable the “auto-bake” feature of Cuirass on this machine <rekado>I’m rebuilding tensorflow again because the python bindings don’t work :-/ <rekado>sorry for the extra load on guix.bordeaux.inria.fr :) <zimoun>Scroling notes from recent ExaScale meeting, I read: « Can me make spack / easybuild / guix-hpc interoperate? ». Hum? I am not completely sure how it would be possible… <flypaper-ultimat>what would interoperate mean in this context? A recipe for one would work for the other or something? <flypaper-ultimat>or something like linking libraries created by A to a binary created by B? <rekado>I often get asked this question and it usually means to mix packages from one with the other. <rekado>spack can use libraries from the host system and arbitrary compilers, and it doesn’t distribute binaries; does that mean that it could be used with tools and libraries from Guix? <rekado>it would only work if it were to use libraries *exclusively* from Guix, avoiding any libs that may be available on the system (including other packages built with spack) <rekado>I don’t think there’s a good way around ABI incompatibility unless we were to build a custom linker with 23rd century technology <flypaper-ultimat>I wonder why you would want this though, because you'd lose all the advantages guix right? I'm not too familiar with spack, but do they do e.g. things to remove randomness in build processes? <rekado>I think you wouldn’t just lose the advantages of Guix but also the advantages of Spack <rekado>the motivation seems to be the desire to use packages from wherever they exist <rekado>oh, Guix doesn’t have a tensorflow 2 package? Spack does! But I don’t want to commit to using Spack for all my Guix things. Wouldn’t it be great if Guix could use the Tensorflow 2 from Spack then…? <rekado>that said, I do sometimes recommend the use of Guix even if it doesn’t reach all the way to the tip of the leaf package in question. <rekado>e.g. to use Guix for the foundation: Python, GCC toolchain, bunch of libraries, some Python packages, etc. And then build software on top of that in a “guix shell -C” environment. <rekado>that’s better than throwing out all of Guix just because some Python module isn’t available yet. <flypaper-ultimat>w.r.t building in a `guix shell -C`; ah cool, havent thought about going about it that way. <zimoun>yeah, I also recommand something similar. To be precise, create an environment for building on the top of it: “guix time-machine -qC pins.scm -- shell -C -m deps.scm”, and then write down all the steps (à la labnotebook :-)) <rekado>many people at the MDC do this without knowing that this is what they do. We provide an rstudio-server launcher that comes with most libraries and tools that they might need. Inside this environment they can use install.packages. <rekado>this works pretty well, most of the time <zimoun>Why not replace apt by guix in r2u. ;-) <rekado>the guy is also really dismissive of Guix ¯\_(ツ)_/¯ <rekado>it’s funny to me how far people will go to defend a clearly documented segfault in their code <rekado>apparently, Protobuf 3.21.9 goes with python-protobuf 4.21.9