IRC channel logs
2023-10-17.log
back to list of logs
<rekado>when I unpack the dependencies in the jaxlib build directory and point bazel to them it still insists on downloading at least one of them <rekado>I’m now installing nix to take a look at their jaxlib source artifact. <rekado>used the exact same source blob as nixpkgs does, and the problem is the same. So that’s not the problem. <rekado>the boards are the same as I understand it. <rekado>but we don’t have suitable rack-enclosures <civodul>we’re considering buying one at work, so i’ll need to make sure we get something that actually works <rekado>IIRC there is no remote management because it’s just two honeycomb boards <tomu>Hi! I'm a PhD student who'd like to use guix and maybe guix workflow language to help me do my research <tomu>I've been reading the GWL manual and I can see how to declare which packages each stage of the pipeline needs, but is it possible to also declare what version? I can imagine myself wanting for example to produce results using different versions of a particular package for example. <efraim>I've never used GWL but I assume you'd need to have package definitions for those other versions of the packages. <rekado>version numbers don’t mean much in the world of Guix. Guix captures more than just the version of a single package. <rekado>I feel I’m close to giving up on bazel again <rekado>do any of you have an idea how to debug it? <rekado>the problem is that bazel deletes a perfectly fine (I assume) directory containing things from a previous run of bazel. <rekado>I need to figure out why it isn’t satisfied with the directory it already has, because it ends up trying to download the thing from the internet <rekado>that first DEBUG line is where my build falls apart <rekado>Instead I get “INFO: Repository xla instantiated at:”, which is read from the source directory’s WORKSPACE file <rekado>and so it ends up running the tf_http_archive rule, which makes it try to download xla. <rekado>turns out I just needed to pass “--nofetch” to force it to accept my sources. It still claims the sources aren’t “up-to-date”, but I finally got past this hurdle. <efraim>I know in these situations I would've been yelling at the computer "I already gave you the sources!" <rekado>it’s really quite frustrating because the bazel docs themselves say not to rely on “--nofetch” <rekado>now it’s failing because it has detected that our linux-libre-headers-5.15.49/include/linux/errno.h is included but not declared in Bazel <rekado>there’s again no simple way to allow these headers <rekado>the closest I found is a really long and cumbersome declaration of a custom platform <civodul>i’ll bring painkillers for you in Montpellier :-) <rekado>This introductory sentence in the Bazel documentation is not encouraging: “To configure the C++ toolchain, repeatedly build the application and eliminate each error one by one as described below.” <civodul>at least the algorithm to get it to work is simple <zimoun>…simple but not necessary convergent. ;-)