IRC channel logs


back to list of logs

<rekado>gah, still no success
<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.
<civodul>hey, the HoneyCombs that you host, are they rackable like those at ?
<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
<civodul>that should be acceptable
<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>here’s the nix build log:
<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. ;-)
<rekado>I think the reason why nixpkgs don’t need “--nofetch” is because of this patch: