IRC channel logs


back to list of 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:
<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.
<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.