Description of problem: I'm trying to update the pvs-sbcl package, but the documentation is failing to build, with lualatex: This is LuaTeX, Version 1.10.0 (TeX Live 2019) restricted system commands enabled. (./language.tex LaTeX2e <2018-12-01> luaotfload | main : initialization completed in 0.057 seconds (/usr/share/texlive/texmf-dist/tex/latex/base/book.cls Document Class: book 2018/09/03 v1.4i Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/bk12.clo luaotfload | db : Font names database not found, generating new one. luaotfload | db : This can take several minutes; please be patient. luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: "File not found: lmroman12-regular.". /usr/share/texlive/texmf-dist/tex/latex/base/bk12.clo:54: Font \TU/lmr/m/n/12=[ lmroman12-regular]:+tlig; at 12pt not loadable: metric data not found or bad. <to be read again> relax l.54 \normalsize The texlive-lm package is installed, and does indeed contain the necessary font metrics: -rw-r--r--. 1 root root 110400 Nov 25 2016 /usr/share/texlive/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf A web search for this issue turned up reports of some versions of luaotfload being broken. Indeed, that seems to be the case in Rawhide. $ luaotfload-tool -v -u -p -f luaotfload | db : Updating the font names database forcefully. luaotfload | db : Scanning TEXMF for fonts... luaotfload | db : Scanning system fonts... luaotfload | db : Scanning 430 collected font files ... $ luaotfload-tool --cache=show luaotfload | ------------------------------------------------------------------- : luaotfload | cache : Luaotfload cache: writable path luaotfload | cache : location: /builddir/.texlive2019/texmf-var/luatex-cache/generic/fonts/ luaotfload | cache : [raw] 0 luaotfload | cache : [compiled] 0 luaotfload | cache : [other] 0 luaotfload | cache : [total] 0 luaotfload | cache : Luaotfload cache: readable path luaotfload | cache : location: /builddir/.texlive2019/texmf-var/luatex-cache/generic/fonts luaotfload | cache : [raw] 0 luaotfload | cache : [compiled] 0 luaotfload | cache : [other] 0 luaotfload | cache : [total] 0 luaotfload | ------------------------------------------------------------------- : I cannot find any invocation of luaotfload-tool that results in the cache being populated. There is no sign of a luaotfload cache in /var/lib/texmf, either. Here is a small test case. Create a file, named test.tex, with these contents: \documentclass[12pt]{book} \begin{document} This is a test. \end{document} Now, in Rawhide, run "lualatex test.tex". You will get the same error I reported above. Version-Release number of selected component (if applicable): texlive-base-20190410-1.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. Install texlive-base and texlive-lm 2. Create test.tex with the contents shown above 3. Run "lualatex test.tex" Actual results: Failure due to missing font metrics. Expected results: Success, since the font metrics are in fact available. Additional info:
According to the thread rooted here: https://tug.org/pipermail/tex-live/2019-May/043690.html updates to lualibs and luaotfload were uploaded to CTAN a couple of weeks ago. The changes to luaotfload can be seen here: https://github.com/u-fischer/luaotfload/blob/master/NEWS but none of them really jump out at me as being likely to be related to this bug report.
If I run lualatex over the test.tex file shown above on my Fedora 30 machine, to generate the font cache, then I see this: $ luaotfload-tool --find lmroman12-regular luaotfload | resolve : Font "lmroman12-regular" found! luaotfload | resolve : Resolved file name "/usr/share/texlive/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf" If I then copy the luatex-cache directory from the Fedora 30 machine into a Rawhide mock chroot, running that same command inside the mock chroot does this: $ luaotfload-tool --find lmroman12-regular luaotfload | db : Version mismatch; expected -1, got 5. luaotfload | db : Force rebuild. luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: "Font lmroman12-regular not found.". luaotfload | resolve : sequence of 3 lookups yielded nothing appropriate. luaotfload | resolve : Cannot find "lmroman12-regular" in index. luaotfload | resolve : Hint: use the --fuzzy option to display suggestions. That's interesting. Why is version -1 expected? That message seems to be coming from /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua, where -1 is the value of names.version. Is that the "names" defined on line 204? I've never gotten around to learning lua. :-(
The version -1 thing appears to be a red herring. On Fedora 30, /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua has this at line 3683: names.version = 5 --- increase monotonically but the Rawhide version has this instead, at line 3741: -- MK Changed to rebuild with case insensitive fallback. -- Negative version to indicate generation by modified code. names.version = -1 --- decrease monotonically -- /MK so apparently that was deliberate.
The function read_font_names, line 1815 of /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua, always reports 0 new fonts. I turned on some logging, and see this: luaotfload | db : Scanning 426 collected font files ... luaotfload | db : Loading font ..ts/opentype/public/lm-math/latinmodern-math.otf luaotfload | db : Failed to read basic information from "latinmodern-math.otf": "the file cannot be opened for reading" luaotfload | db : Loading font ..ts/opentype/public/lm/lmromancaps10-oblique.otf luaotfload | db : Failed to read basic information from "lmromancaps10-oblique.otf": "the file cannot be opened for reading" luaotfload | db : Loading font ../fonts/opentype/public/lm/lmroman17-regular.otf luaotfload | db : Failed to read basic information from "lmroman17-regular.otf": "the file cannot be opened for reading" ... This indicates that read_font_file always returns false, due to some problem opening files for reading. Some extra logging added by yours truly shows that calls into readers.getinfo on line 2455 of /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua. That in turn indicates that loadfont returned nil. Here are the last few lines of the loadfont function: local ok, result = xpcall(loadfontdata,message,specification) if ok then return result end -- return loadfontdata(specification) end If I change that xpcall into a direct "loadfontdata(specification)", I see this: luaotfload | db : Scanning 426 collected font files ... luaotfload | db : Loading font ..ts/opentype/public/lm-math/latinmodern-math.otf ...texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua:2036: attempt to call a nil value (upvalue 'stripstring') Here is the line in question: local tag = lower(stripstring(readstring(f,4))) And there is our problem: stripstring is not defined. This is line 79 of /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua: local stripstring = string.nospaces where, in contrast, this is what that line reads in the Fedora 30 version of the file: local stripstring = string.strip If I change it back to string.strip, then the next run shows this: luaotfload | db : Scanning 426 collected font files ... luaotfload | db : Loading font ..ts/opentype/public/lm-math/latinmodern-math.otf ...texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua:1041: attempt to call a nil value (field 'to16dot16') That line reads as follows: fontversion = number.to16dot16(fontversion), I see that /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-reference.lua has definitions of both string.nospaces and number.to16dot16. Why doesn't fontloader-font-otr.lua have them?
So fontloader-font-otr.lua doesn't have those functions because they are defined in lualibs 2.64. The version in texlive-lualibs is too old; it does not define those functions, and possibly others. If texlive-lualibs is updated, everything should magically work again.
Good detective work. texlive-2018-26.fc31 is building now with the latest lualibs. Everything else in texlive also needs to be updated, but I haven't had enough time to do that yet.
I'm not surprised. That's got to be a huge job. You have my sympathy.
texlive-2018-26.fc31 is built in rawhide. Please retry.
That does indeed fix the luatex issue. Sadly, I have now hit some other issue, namely this: ./language.tex:59: Undefined control sequence. <argument> ...x \ifdim \paperheight >0pt\relax \pdfpagewidth =\paperwidth \pdfpageheigh... l.59 \begin{document} ? ./language.tex:59: Emergency stop. That looks a lot like https://tex.stackexchange.com/questions/315025/lualatex-texlive-2016-standalone-undefined-control-sequence, but standalone.sty is not in use in this case. The \pdfpagewidth control sequence does not appear in the PVS sources. I see the following files in my mock chroot's /usr/share/texlive that contain the above sequence of tokens: - texmf-dist/tex/latex/graphics-def/xetex.def - texmf-dist/tex/latex/graphics-def/pdftex.def Since the input file in question does not load xetex.def, I conclude by process of elimination that it is complaining about pdftex.def. Incidentally, speaking of standalone.sty, the version in Rawhide in 0 bytes long. That doesn't seem right. Searching for 0 byte files also turns up /usr/share/texlive/licenses/collection.txt. I think *this* bug is fixed. If you like, I can file new bugs for whichever of the above seem worth filing bugs over.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.