IRC channel logs


back to list of logs

<PurpleSym>Is there any reason PAR-MAP starts fast but then slows down significantly to the point where it provides no benefit over single-threaded MAP? Garbage-collection?
<rekado>Debian has a bazel-bootstrap package:
<rekado>I don’t read Debian packages well, but it looks like it’s not just a blob.
<PurpleSym>So, `guix pull`’ing that new CRAN channel works, but any operation (show, search, build) fails with `Too many root sets, zsh: IOT instruction (core dumped)`. I guess there’s too many packages.
<rekado>that’s a garbage collector thing, isn’t it?
<rekado>is it one big file or many?
<PurpleSym>Every package has its own file, rekado, so I can remove the ones which don’t work easily.
<PurpleSym>I guess I’ll try to create one big file manually and see if that works.
<civodul>rekado: re Bazel, neat!
<civodul>we should team up with these folks
<rekado>I was so bold as to edit the Readme of this bioinfo tool:
<rekado>pull request was accepted immediately
<rekado>hmm, the build directory for pigx-sars-cov-2 version 0.0.8 is /tmp/guix-build-pigx-sars-cov-2-2-0.0.8.drv-0
<rekado>an extra -2 in there
<civodul>new version!
<civodul>bug fix: propagation is more efficient than with 2.0
<civodul>seriously though, i don't see what would add an extra "-2"
<rekado>I’m using with-source, so maybe that’s where it comes from
<rekado>gotta check later
<civodul>ah yes, could be
<rekado>today I remembered that we’ve got so much work to do to fix/improve our TeX stuff
<rekado>unearthed a few stashes, but it feels pretty overwhelming
<rekado>same with bazel
<rekado>I guess I can’t wait for someone else to package all these Java things
<rekado>I’m not complaining — the range of packages Guix spans is massive. But it does feel a little lonely on the fringes sometimes.
<civodul>yeah, definitely
<civodul>modular TeX pretty much works for me these days, and people have been adding packages
<civodul>what's missing is meta packages
<rekado>we have a bootstrapping problem with all TeX engines
<rekado>since we’re building from scratch they are made in an environment that lacks (for example) babel or hyphenation packages.
<rekado>this bites us much later.
<rekado>so we have to tie this huge bootstrap loop where we build everything with the broken TeX engines first and then build the engines again in an environment that has babel and the hyphenation packages
<civodul>oh, didn't know there was such a problem
<civodul>that's why modular texlive fails to build the non-English manuals for instance?
<civodul>or was that solved?
*civodul is confused
<rekado>I don’t recall the details, but there’s a bug report that shows how we arrived at this conclusion.
<rekado>here’s the bug report:
<civodul>actually the PDF is 404 these days:
<rekado>the English one is fine
<rekado>German is also missing
<civodul>i think it's 1cde647cc05c640fbfa6f9779a0d7854bb90e153
<civodul>"Use a minimal texlive", and then only English works
<rekado>Spanish is fine
<civodul>ah, interesting
<rekado>but no Chinese or Russian at all (no links)
<civodul>these are expected not to work
<rekado>old: thanks for reviewing the guix-hpc patch! I’ll apply it.
<rekado>civodul: I’ll investigate doc/build.scm
<old>rekado: my pleasure
<rekado>regrettably, we have received a lot of texlive-* package definitions that follow the old naming scheme
*rekado sighs
<rekado>this means that we’ll have even more deprecations
<rekado>I was hoping we could finally leave those behind.
<civodul>rekado: oops, it may be that i applied some of these, apologies if that's the case :-/
<rekado>no worries
<rekado>there’s anyway more work to be done for texlive-*.
<rekado>and a few more deprecations will feel right at home with all the other deprecations we have in (gnu packages tex) ;)
*rekado runs a little script to check if our tex packages are complete
<rekado>output so far: