IRC channel logs


back to list of logs

<rekado>PurpleSym: something isn’t working right with that rstudio upgrade
<rekado>I got a report of an error in building js-panmirror
<rekado>“Error: Cannot find module './MergeChain'”
<PurpleSym>rekado: Hm, works fine here with Guix proper at commit 37c2e94cec6cb8b5e0e93e7b6c712c3b187ca5db.
<PurpleSym>(Apart from the fact that it is not reproducible, but -.-r
<rekado>okay, I’ll try to get more info to reproduce this
<rekado>PurpleSym: I can actually reproduce this on our cluster
<rekado>PurpleSym: channels file is here
<rekado>I’ll try to reproduce this on my laptop
<rekado>I cannot reproduce this on my laptop
<rekado>but the very same derivation (/gnu/store/438j5b8nk6j982r6qznw0sspfmm45ay6-js-panmirror-2022.12.0+353.drv) fails on the cluster.
<rekado>fuse-box contains fewer files on the cluster
<rekado>the source code is identical on both systems
<PurpleSym>I can build it with that channel file too on my local system.
<PurpleSym>What’s missing?
<rekado>here’s the diff:
<rekado>I don’t see where this diff could come from
<PurpleSym>Yeah, looks totally random.
<PurpleSym>Do these files exist in the respective Node packages? I.e. does node-chain-able have ChainedMap.js for example?
<rekado>I just ran guix build --check node-fuse-box and the output does in fact differ.
<rekado>but in a weird way: there’s one *more* file missing now
<rekado>trying node-chain-able
<rekado>it contains ChainedMap.js and builds reproducibly
<rekado>trying --with-input=node=node@10
<rekado>I’m always worried about using “guix gc” to check for corruption on the cluster, because “guix gc” will delete “stale” things without asking as it’s traversing gc roots
<rekado>we have lots of stale looking roots due to the fact that user home directories are unreachable from the server running guix-daemon
<rekado>I wished I could disable this automatic deletion.
<rekado>with node@10 it’s even worse…
<rekado>perhaps it’s due to the way node links files…?
<rekado>this already happens at the configure phase
<PurpleSym>I remember there were filesystem related issues previously.
<PurpleSym>Not with node, but different packages failing due to being built on a tmpfs or something like that.
<rekado>it’s strange
<rekado>the /gnu directory is local (exported via NFS, but that shouldn’t matter) and /tmp is not a tmpfs either.
<rekado>I don’t see anything special that could matter here
<rekado>we have the problem with node-fliplog already
<rekado>that’s the input to fuse-box that requires chain-able
<rekado>the problem seems to lie in the upgrade to node-chain-able-1.0.1
<rekado>I just built the old node-fliplog and it contains all files that belong to chain-able
<rekado>when I plug in this good node-fliplog variant into the build of node-fuse-box the files are again not included
<PurpleSym>At was v1.0.1 of chain-able before too. The only change to that package is adding a dependency to package.json.
<rekado>must be the build system change
<rekado>I’m changing too many variables at once
<rekado>it works for me when I add a post-install phase to explicitly copy chain-able files to /lib/node_modules/fuse-box/node_modules/chain-able
<rekado>this lets me build js-panmirror
<rekado>I tried doing this to fliplog directly, but that had no impact on fuse-box
<reed42>Does anyone have experience using guix for declarative ML workflows? Any anecdotes with research or production would be useful. In particular, I'm curious if anyone has tips for using guix with dataset versioning.