IRC channel logs

<rekado>I just built the tarball on my laptop and compared it with the tarball on a server

<rekado>the problem afflicting the JDK is gone, but the same kind of problem exists for Python

<rekado>it contains explicit references to the Python interpreter and to store locations of numpy.

<rekado>it contains, for example, a long list of copy commands from the store to the build directory

<rekado>and clearly when these inputs change (e.g. numpy gets a new version) all these store locations become invalid

<rekado>it should instead copy them from a variable location that’s determined by the GUIX_PYTHONPATH

<rekado>and finally there’s the problem of different symbolic link names

<rekado>e.g. a/external/bazel_tools -> GUIX_BUILD_TOP/tmp/install/da29c37699eb912d8e37b36e26505c2a/embedded_tools

<rekado>vs b/external/bazel_tools -> GUIX_BUILD_TOP/tmp/install/e259099aa6a70f43be0a5cf965aa0e57/embedded_tools

<rekado>Symbolic links a/external/bazel_tools and b/external/bazel_tools differ

<rekado>Files a/external/local_config_python/BUILD and b/external/local_config_python/BUILD differ

<rekado>Files a/external/local_execution_config_python/BUILD and b/external/local_execution_config_python/BUILD differ

<rekado>this explains both the error when bazel runs (because expected files are not found and thus not copied) and the hash mismatch.

<rekado>the origin of these generated locations is this bazel script: https://github.com/openxla/xla/blob/main/third_party/py/python_configure.bzl

<rekado>this is fetched when bazel is run

<rekado>this is awful

<rekado>I don’t see nixpkgs doing anything about this. They must have some other solution.

<civodul>uh

<rekado>for the JDK I fixed this by patching external/local_jdk/BUILD.bazel so that it contains a placeholder “@GUIX_JAVA_HOME@” instead of the actual location to the JDK.

<rekado>after the generated tarball is unpacked at build time I’m replacing that placeholder

<rekado>(nixpkgs also don’t do this AFAIK)

<rekado>for Python I could attempt to do the same, but it’s more than just Python itself. It’s also numpy and potentially any number of Python packages.

<rekado>more generally bazel-vendored-inputs needs to get a sanity check to ensure that no store references exist in the output

<rekado>same problem for local_config_sh (contains location of bash) and local_config_cc (contains many references to glibc, gcc, binutils, etc)

<rekado>perhaps this can be avoided by creating a union of all inputs when bazel-vendored-inputs is built.

<rekado>this would leave just *one* reference to the “build environment”, which we could replace with a placeholder

<rekado>this complicates downstream packages somewhat, because they’d have to arrange for their “build environment” to be made available at a single prefix in the same manner (e.g. via union directory)

<rekado>I’m stuck because (package-native-inputs this-package) gives me the wrong directory for the JDK

<rekado>the native-inputs field contains `(,openjdk11 "jdk") but package-native-inputs gives me the default output of the openjdk11 package.

<rekado>so far no success with the union directory approach. Perhaps bazel resolves links. There are still dozens of direct store references in the generated local_config_{cc,python}.

<rekado>nixpkgs seems to delete all of these local_ directories completely. This suggests that they provide alternatives to these toolchain directories.

IRC channel logs

2024-01-11.log