Re: xdvipdfmx:fatal: Unable to find TFM file "latt1095".

[Jonas Hahnfeld]

Hi Dan,

Am Samstag, den 21.11.2020, 10:23 -0500 schrieb Dan Eble:
> In a clean build directory in a newly created Docker container, this fails:
> 
>     $ ~/lilypond-src/autogen.sh —ci
>     $ make -j7 CPU_COUNT=7
>     $ make -j7 CPU_COUNT=7 doc
>     
> 
> This seems to be the key problem:
> 
>     xdvipdfmx:fatal: Unable to find TFM file "latt1095".
> 
> Afterward, I can see this:
> 
>     $ find ~ -name '*latt1095*'
>     /home/user/.texlive2019/texmf-var/fonts/pk/ljfour/lh/lh-t2a/latt1095.603pk
>     /home/user/.texlive2019/texmf-var/fonts/pk/ljfour/lh/lh-t2a/latt1095.600pk
>     /home/user/.texlive2019/texmf-var/fonts/source/lh/lh-t2a/latt1095.mf
>     /home/user/.texlive2019/texmf-var/fonts/tfm/lh/lh-t2a/latt1095.tfm
> 
> I don't know where to go from here.  The full notation.texi2pdf.log is 
> attached.

I noticed the same some time ago, in fact it also occurred with GUB
during one of the releases. My *guess* is that there is a race between
multiple texi2pdf invocations that produce the file if it's not there.
I think this was somehow introduced by an update of cyrillic.itexi
(https://gitlab.com/lilypond/lilypond/-/merge_requests/361, was the
only change that stood out when I first saw it failing) which talks
about "latt", but I didn't investigate. I seem to recall that reverting
that commit locally solved the problem when manually removing the cache
to reproduce it. James also brought this up recently in 
https://gitlab.com/lilypond/lilypond/-/merge_requests/498#note_442234945

Just as pointers to confirm that there is a problem, but no idea how to
solve it.

Jonas

signature.asc
Description: This is a digitally signed message part