*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>(I used `guix time-machine -- build python-nbconvert`) <PurpleSym>Maybe it’s the warning before: Math formula deleted: Insufficient symbol fonts. <rekado_>I’m on commit bee797fa930e9357dcdf878526e75363f81ac4e7 and cannot reproduce this. <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 ci.guix.gnu.org with “--cores=1” <rekado_>the “math formula deleted” thing looks familiar, though <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 ci.guix.gnu.org 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 <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_>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_>I suppose that’s because of the profile hook <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 <rekado_>PurpleSym: I can reproduce this on ci.guix.gnu.org but not on my laptop <PurpleSym>Yep, same minimal reproducer is working on my laptop too. Weird. <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_>and the reason why it picks different fonts… might be different dir list? <rekado_>it accesses the share/texmf-dist/fonts/tfm/ directory in different order <rekado_>so on ci.guix.gnu.org it gets the amsfonts first <rekado_>whereas on my laptop it stats the cm directory before the amsfonts dir <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 <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_>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_>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_>one letter difference: texmf-dist/fonts/tfm/public/amsfonts/cmextra/cmbsy6.tfm <rekado_>okay, I have a patched version; will use that with nbconvert <rekado_>this should fix the build on ci.guix.gnu.org <rekado_>now it would be nice if this also fixed bug 39101 <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_>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_>perhaps that’s because both stores only listen on TCP *rekado_ submits a bug report <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` is now known as zimoun
<efraim>years ago I was told 'cp -a' was fine for copying over the store <civodul>essentially run-time type checks upon procedure entry and exit <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 <zimoun>civodul, thanks. We should have missed about catch so.