IRC channel logs


back to list of logs

<rekado>successfully built /gnu/store/ysaqnv55p7894xsp83ikmlsfc0wp7a6x-tensorflow-2.13.1.drv
<civodul>wo0t! our hero!
<rekado>this produces two outputs; the “python” output doesn’t actually contain the ready-to-use Python package, but the generated source files
<rekado>so there will also be a python-tensorflow package that actually builds them
<rekado>the tensorflow build system needs patchelf, because it doesn’t embed the correct locations to libraries built earlier
<rekado>it’s a bit messy
<rekado>for python-tensorflow I still need to package a few things; next up is
<rekado>ugh, it also needs keras, which also needs bazel to be built
<civodul>the package definition is a bit intimidating
<civodul>the current ‘python-keras’ doesn’t build with Bazel, is that because it’s an old version?
<rekado>yes, it’s pretty old
<rekado>I opened back then
<rekado>now that we’ve got tensorflow I’ll try building keras
<rekado>not good that an update of Guix caused the build of python-jaxlib to fail
<rekado>this error looks like the vendored sources are incomplete. This should not depend on any of the updates in Guix.
<civodul>this corresponds to the ‘rust-team’ merge
<civodul>i have no idea why this would break jaxlib
<efraim>outside of rust and crates I touched librsvg and python-cryptography
<efraim>if that helps narrow it down
<efraim>ACTION thinks there may have been more actually, python-orjson
<rekado>it’s no problem. I’m just a little worried that maybe the bazel-vendored-input derivation might not actually be deterministic.
<rekado>the merge seems to cause a rebuild of bazel, which causes these vendoring derivations to be rebuilt.
<rekado>one obvious problem is that I’m passing all package inputs to the *-vendored-inputs derivation.
<rekado>this leads to more rebuilds than there should be