IRC channel logs
2023-10-27.log
back to list of logs
<rekado>we have a problem with PiGx, namely that we cannot benefit from any of the existing “run on cloud” features directly <rekado>the dominance of Docker (as a synonym for “containers”) stifles computing diversity <civodul>more than 120 people registered for the event in Montpellier :-) <efraim>oh, civodul, rekado: Todd from Spack wanted to appologize again for calling you "religious" <civodul>efraim: are you at some free software event? <civodul>there’s no gratis live stream, is there? <rekado>the religion epithet seems to come with the GNU label; I appreciate all attempts to sever that link. <rekado>civodul: from what I could tell there’s only a ticket for remote attendance granting access to the stream. <rekado>ACTION prepares to install Guix System on the office workstation <civodul>pressure quickly vanishes once you’re there IME <rekado>personally, I found the pressure to be biggest when there are very few people, because I really want them to get the most out of attending. <rekado>120 is big enough to just be some number to me. <jonsger>120 persons would result in a quite decent group picture :) <rekado>hmm, I’m surprised to see that building without “--no-grafts” results in a full rebuild of jaxlib, jax, tensorflow, … <rekado>I would have expected the grafts to be cheap <rekado>I wonder if that’s related to my use of computed-file <rekado>but I suppose we’re embedding the output in the builder of the package using it <rekado>it does (invoke "tar" "xf" "/gnu/store/1iykz1fg1nfrvxf72az33akg2bi3z2k2-jaxlib-vendored-inputs-0.4.18.tar.xz") <rekado>and that store location differs dependent on whether jaxlib-vendored-inputs-0.4.18.tar.xz was computed with grafts or without, even though the output is fixed <rekado>so I guess I’d have to move it to inputs and access it indirectly by label <civodul>the thing that ‘bazel-vendored-inputs’ returns is fixed-output, so its output file name shouldn’t be a function of its inputs <rekado>bazel-vendored-inputs is given all of the current package’s inputs, and those change with grafts. <civodul>but the #:hash bit doesn’t change, does it? <rekado>no, the hash is unchanged. But the builder for python-jaxlib embeds the newbstore name for jaxlib-vendored-inputs-0.4.18.tar.xz <rekado>the derivations for jaxlib-vendored-inputs declare the same hash but have different output names. <rekado>I’ve got a really weird problem with tensorflow-probability <rekado>when I do this “from tensorflow_probability.python.internal.backend import jax” it eventually ends up doing “from tree import _tree” <rekado>when this is done on its own in a “guix shell python python-dm-tree” the library can be loaded without problems <rekado>but when it’s loaded via that chain starting with “from tensorflow_probability.python.internal.backend import jax” it *fails* to load _tree.so <rekado>it complains about an undefined symbol <rekado>ImportError: /gnu/store/j7gz6swkxanwma08f9x5g8gz2dqi8qfs-profile/lib/python3.10/site-packages/tree/_tree.so: undefined symbol: _ZN4absl12lts_2022062316strings_internal9CatPiecesB5cxx11ESt16initializer_listISt17basic_string_viewIcSt11char_traitsIcEEE <rekado>any ideas what might cause this? <rekado>I ran python3 with “-vv” to see what files it loads, but I haven’t got a clue what could cause one and the same library to complain about missing symbols in one case and not in the other. <rekado>when I do “from tree import _tree” *first* in the same environment it loads the library without issue. <rekado>but when I do “from tensorflow_probability.python.internal.backend import jax” right after that it complains about a different library: ImportError: /gnu/store/p6vj54z3zsis12qfcghdvinm82a7fmcb-abseil-cpp-20220623.1/lib/libabsl_cord_internal.so.2206.0.0: undefined symbol: _ZN4absl12lts_20220623lsERSoNS0_11string_viewE <rekado>these are both related to abseil, so my vague guess is that … something’s not right with that package.