IRC channel logs


back to list of logs

<PurpleSym>rekado_: nbconverts test fail now :(
<PurpleSym>*nbconvert’s tests
<rekado_>it built fine for me
*rekado_ runs ./pre-inst-env guix build --check --no-grafts python-nbconvert
<rekado_>could it be a problem with running tests in parallel?
<rekado_>I just built it successfully again on my laptop
<rekado_>PurpleSym: which of the tests fails?
<PurpleSym>rekado_: Some latex tests. Full log is here: Not sure why \maketitle causes xelatex to fail :/
<PurpleSym>(I used `guix time-machine -- build python-nbconvert`)
<PurpleSym>Maybe it’s the warning before: Math formula deleted: Insufficient symbol fonts.
<rekado_>what version of Guix is this?
<rekado_>I’m on commit bee797fa930e9357dcdf878526e75363f81ac4e7 and cannot reproduce this.
<PurpleSym>Let me check that commit.
<PurpleSym>Yeah, same problem.
<PurpleSym>The CI also fails to build it currently:
<rekado_>I wonder why I don’t see this on my laptop
<rekado_>perhaps this relates to TeX Live packages not being reproducible
<rekado_>I’ll try building this very same derivation on with “--cores=1”
<rekado_>yeah, I get test failures there
<rekado_>the “math formula deleted” thing looks familiar, though
<PurpleSym>Yep, same error.
<rekado_>also interesting that this problem is not easily reproducible: “Asymptote only succeeds building randomly on Berlin. On my machine, itsystematically fails”
<rekado_>these errors must come from the TeX formats
<rekado_>the error message "Insufficient symbol fonts" is only found in the compiled fmt files.
<rekado_>these files on are identical to those I have on my laptop
<rekado_>I guess the best way to figure this out is to compare the complete texlive-union and see if there are any differences
<rekado_>I seem to have almost exactly the same files (because most are substituted)
<rekado_>the texlive-union itself differs, but that’s because of a single log file with a timestamp
<rekado_>so … perhaps it’s some weird TeX runtime difference that depends on hardware…?
<rekado_>I’ll look at the sources to see what this “Insufficient symbol fonts” error really means
<rekado_>yuck, I hate reading TeX code
<zimoun>I am trying to add Julia packages. And I am blocked. I get an error from Julia itself: ERROR: LoadError: could not load library "libz" with the Julia internal trace: dlopen(::String, ::UInt32; throw_error::Bool) at /tmp/guix-build-julia-1.5.3.drv-0/…
<zimoun>then indeed find $(guix build julia) -type f -exec grep '/tmp/guix-build-julia-1.5.3.drv-0' {} \; returns several items, e.g., Fichier binaire /gnu/store/…-julia-1.5.3/bin/.julia-real and so on.
<zimoun>Well, I have tried to recompile the julia package and zlib in the LD_LIBRARY_PATH… still an error.
<zimoun>Since building the julia package is ~2h, the trial-error strategy to find what is wrong will take ages. ;-)
<zimoun>An idea about what I miss? Something about wrapper?
<rekado_>PurpleSym: I’m running xelatex through strace now… I want to learn what files it attempts to read.
<rekado_>zimoun: looks like the dlopen calls need to be patched.
<rekado_>the fact that the build directory remains in the output is wrong
<PurpleSym>rekado_: Sounds like an adventure. Anything I can do to support that journey? Do you have a minimal reproducer already? I’m not much of a TeXpert unfortunately.
<rekado_>no reproducer yet.
<rekado_>it’s puzzling. No idea why the behavior would differ.
<zimoun>rekado_: thanks for explaning. I will open a bug report because I will not have time to investigate more. Too much cakes in the oven. ;-)
<PurpleSym>Just tried `guix time-machine --commit=bee797fa930e9357dcdf878526e75363f81ac4e7 -- environment -C python-nbconvert` and it fails to build texlive-configuration :/
<PurpleSym>(no --ad-hoc, because I wanted to run the tests manually)
<PurpleSym>Besides the final Permission denied there’s also collisions between texlive-union and texlive-bin in the log.
<rekado_>FWIW this also fails on my laptop
<rekado_>I suppose that’s because of the profile hook
*rekado_ tries a patch
<PurpleSym>And on my laptop building python-nbconvert succeeds. What?!
<rekado_>would be an idea to try building this on a headless VM, see if the presence of a GPU makes a difference.
<rekado_>the problem with the profile hook is that updmap.cfg already exists; that’s why copy-file fails
<PurpleSym>I can actually reproduce the issue with `/gnu/store/dcbjfkl7jvd8jswnlyiips175bzhp95b-texlive-union-51265/bin/xelatex latex_document.tex`, where latex_document.tex is
<PurpleSym>That’s the xelatex from the failing test.
<rekado_>fixed the hook in 56e4d7204b
<rekado_>PurpleSym: I can reproduce this on but not on my laptop
<PurpleSym>Yep, same minimal reproducer is working on my laptop too. Weird.
<rekado_>trying some strace’ing now …
<rekado_>(I’m not proud of always reaching to strace…)
<rekado_>it seems to be using different fonts
<rekado_>on ci. it loads /gnu/store/dcbjfkl7jvd8jswnlyiips175bzhp95b-texlive-union-51265/share/texmf-dist/fonts/tfm/public/amsfonts/euler/cmsy6.tfm
<rekado_>but on my laptop it loads /gnu/store/dcbjfkl7jvd8jswnlyiips175bzhp95b-texlive-union-51265/share/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm
<rekado_>maybe the euler fonts are borked
<rekado_>and the reason why it picks different fonts… might be different dir list?
<rekado_>I think that’s it
<PurpleSym>Yeah, dito.
<rekado_>it accesses the share/texmf-dist/fonts/tfm/ directory in different order
<rekado_>so on it gets the amsfonts first
<rekado_>whereas on my laptop it stats the cm directory before the amsfonts dir
<PurpleSym>Again, same here.
<rekado_>so we have two problems
<rekado_>one is that the order is not deterministic; the other is that texlive-amsfonts has broken fonts.
<rekado_>texlive-amsfonts is a complicated package that attempts to build all the fonts from source
<rekado_>I have no idea how the fonts are *supposed* to be built; I read a lot of non-authoritative documentation and filled the blanks by guessing
<rekado_>the amsfonts look very different
<PurpleSym>Hm, my Gentoo host does not even have cmsy6.tfm in /euler/, just eu*.
<rekado_>like they are a completely diffent format
<rekado_>perhaps pltotf doesn’t do the right thing
<rekado_>let’s check tlpdb
<rekado_>yeah, amsfonts is not supposed to have these tfm files at all
<rekado_>annoyingly, we can fix this on the “master” branch
<rekado_>but for the build of nbconvert we could replace amsfonts with our patched version
<rekado_>sorry, “cannot”
<PurpleSym>Ew, yeah, that’s core-updates-worthy :(
<rekado_>another problem here is that the fonts ended up in the wrong directory
<rekado_>cmsy6.tfm should be distributed by the amsfonts package, but not in /share/texmf-dist/fonts/tfm/public/amsfonts/euler/
<rekado_>sorry, ignore that
<rekado_>one letter difference: texmf-dist/fonts/tfm/public/amsfonts/cmextra/cmbsy6.tfm
<rekado_>different font
<rekado_>okay, I have a patched version; will use that with nbconvert
<rekado_>pushed it
<rekado_>this should fix the build on
<rekado_>now it would be nice if this also fixed bug 39101
<PurpleSym>Would grafts be an abuse in this case?
<PurpleSym>Build successfull, by the way. Thanks!
<rekado_>I don’t know; using grafts here seems … okay, no?
<rekado_>glad we figured this out so quickly!
<rekado_>I was dreading a long, confusing TeX debug session :)
<PurpleSym>I’d argue in favor of grafting, because the replacement only removes files (right?) and the issue is highly annoying to debug and manifests in non-deterministic failures.
<rekado_>PurpleSym: do you want to make the commit?
<PurpleSym>I don’t feel confident enough to do that tbh. I have never touched anything related to grafting and texlive is not really my area.
<rekado_>(neither have I)
<rekado_>I’ll do it later today
<PurpleSym>Oh, I was assuming you did. Sorry.
<rekado_>so… I prepared that new HA guix setup. Now I’d like to copy all store items from the old store to the new one.
<rekado_>I also took the opportunity to use the default localstatedir in the new store
<rekado_>not sure if I can just copy the old store’s db and copy files
<rekado_>or if I should use “guix copy” instead
<rekado_>my attempts to use “guix copy” have failed so far
<rekado_>I’m getting a backtrace.
<rekado_>any idea what this means?
<rekado_>perhaps that’s because both stores only listen on TCP
<rekado_>that was indeed the problem
*rekado_ submits a bug report
<civodul>ah, #f again
<rekado_>#f is the new NULL
<civodul>fortunately, it's not a billion dollar mistake, because fewer people write Scheme
<rekado_>perhaps we should add syntax to check return types automatically
<civodul>we could use contracts in some places
<civodul>but i think the compiler could help us, too
<civodul>it's smart enough to detect some mistakes, i think
<zimoun`>civodul: contracts?
***zimoun` is now known as zimoun
<efraim>years ago I was told 'cp -a' was fine for copying over the store
<civodul>hey zimoun :-)
<civodul>"contracts" as found in Racket
<civodul>essentially run-time type checks upon procedure entry and exit
<zimoun>civodul: thanks
<zimoun>Question about Guile test. If a function raises an error, it is possible to use ’match’ or ’catch’ and write a ’test-assert’? And since ’test-error’ seems catching all kind of error, what is the way to do?
<zimoun>well, maybe it is a quesion for #guile ;-)
<zimoun>Pair-progamming with jeko and we had this question. :-)
<civodul>zimoun: test-error is kinda broken AFAIK
<civodul>instead, i explicitly catch or guard against exceptions
<civodul>rekado_: i posted patches for
<zimoun>civodul, thanks. We should have missed about catch so.