IRC channel logs


back to list of logs

<rekado_>twitter blocked the account again; had to solve a captcha again to unlock it.
<rekado>PurpleSym: I just noticed that your commit d57341234d66ba71618ed401d8bb0a5986dc22db added texlive to python-nbconvert.
<rekado>that’s probably not a good idea.
<rekado>I’ll try to undo this and use the modular texlive instead.
<rekado>a user here complains about not being able to upgrade because the big texlive package downloads too slowly and then the TLS connection is cancelled…
<PurpleSym>Hm, okay. How would I depend on texlive?
<rekado>via texlive-union or texlive-tiny
<PurpleSym>Okay, for texlive-union I’d have to know which tex packages are required, right?
<rekado>texlive-tiny doesn’t work here, but I’ll try to figure out what’s missing
<PurpleSym>Thank you very much!
<zimoun>rekado: I have seen you moved one Bioconductor package from bioinformatics.scm. Cool! It reminds me this janitor work and I would like to complete before the next Bioconductor release (end of May). Do you prefer a block of ~50 or 5 chunks of 10?
<rekado>zimoun: whichever you find more convenient!
<zimoun>Ok. Keep you in touch with X-Debuggs-CC soon. :-)
<rekado>thank you!
<rekado>it’s really tedious to figure out what latex packages are needed, because nbconvert dutifully deletes the generated .tex file…
<PurpleSym>rekado: It looks like there are templates in $out/share/jupyter/nbconvert/templates/latex
<PurpleSym>Here’s a list of \usepackage:
<PurpleSym>Hm, no, that’s too short.
<rekado>PurpleSym: excellent, thank you!
<rekado>I’ve got maybe two thirds of these already
<zimoun>I do not know if I have something wrong on my workstation machine. My last ’guix pull’ from 9edb3f6 to 570b3d3 (646 commits) took ~17min on a relative powerful machine with a relative strong network.
<rekado>perhaps building the individual Guix derivations hasn’t finished yet
<zimoun>I do not know. It is hard to trace… Now, it is done. :-) And precompiling Julia package is also really slow. ;-)
<rekado>PurpleSym: phew, finally done
<rekado>I just addded the guix-science substitute server to the default servers here at the MDC and it’s terribly slow :(
<rekado>this is probably the same problem as the one civodul and I investigated earlier
<rekado>downloads slow to a crawl and then the TLS connection dies.
<rekado>this is for the download of mathjax, a mere 16MB
<rekado>writing to the disk while downloading is likely the reason why substitutes essentially no longer work at the MDC
<rekado>it’s a great optimization otherwise, but combined with slow storage it’s fatal
<rekado>I’ll have to change this asap. Move off of NFS. It’s been a weird ride.
<civodul>rekado: this connectivity issue is weird; would be nice to see if the slowdown can be reproduced with wget
<PurpleSym>rekado: So, nothing I can change at my end to improve your download situation?
<rekado>civodul: no, it can’t.
<rekado>civodul: “guix download” is very fast
<rekado>the problem is likely due to interleaving of unpacking / deduplication work while downloading
<rekado>PurpleSym: no, I don’t think so.
<rekado>that’s alright though; I now have real motivation to build this HA cluster with NFS export of the file system
<rekado>i.e. guix-daemon on one node, local file system, exported over both HA cluster nodes in active/passive configuration.
<civodul>rekado: ah sure, the throughput displayed while substituting includes decompression/unpacking; still, it shouldn't slow down
<civodul>is this lzip?
<civodul>you could also try: wget -O - ... | lzip -d | guix archive -x /tmp/subst
<civodul>to see how it compares
<efraim>Deduplication from the daemon or from zfs?
<civodul>efraim: from the daemon
<rekado>the 0ad-data download (from our last test) is an lzip download.
<rekado>this time it’s a zstd download
<civodul>oh right, i had forgotten about that 0ad-data test
<civodul>i tend to easily forget about unpleasant events :-)
<civodul>woud be good to get to the bottom of it tho
<rekado>thes NFS thing isn’t going anywhere
<rekado>but I’m going to do my best to get all our users off this ride :)
<civodul>congrats on Guile-AWS + Guile-DRMAA, BTW! i hadn't seen the announcements
<civodul>define-ffi-module is just crazy
<rekado>the FFI helper is super neat. I probably wouldn’t have attempted to write the bindings if I had had to use the plain FFI.
<rekado>but it wasn’t quite as smooth as I had expected
<rekado>so in the future I might just try to use the FFI directly
<civodul>ok, that sort of confirms my intuition, both on the wonders of such an automated tool and on its shortcomings
<rekado>it did give me the courage to attempt my first foray into the cold world of C bindings
<civodul>i guess it's much better than starting from a blank page
<rekado>yeah, it felt manageable