The export inputenc-luatex-utf8_pdf5_texF has been succeeding for a
while and was likely fixed by a TeX Live update. Compiling manually
and looking at the output looks good.
The unicode tests would often fail when tested in parallel because
we were not exporting to unique file names. From what I understand,
a variant similar to the following race condition occurred:
1. Thread A exports to file blah.pdf.
2. Thread B exports to file blah.pdf.
3. Thread A confirms file blah.pdf exists.
4. Thread A deletes exported file blah.pdf to clean up.
5. Thread B fails to find file blah.pdf and reports a failure.
Runs the compare via the command line, and then compares the output to the
expected result. Required adding a script to do the comparison, so that
the timestamps on changes in the lyx file are ignored.
The new JSS cls has been failing on an updated TeX Live 2020 for a
while, both with the template they provide and with LyX's template.
I expect this will be fixed eventually but for now it's best to
invert it as a "texissue".
With an updated TeX Live 2020 an assertion is given. The assertion
was reported on the LuaTeX ML [1], and will be converted into the
following error as of LuaTeX svn commit r7385:
! the word doesn't start with a character
The error could likely be worked around with a change to the
document but since the document compiles without error with XeTeX I
did not change anything since I do not understand the issue.
[1]
https://www.mail-archive.com/search?l=mid&q=20201030030430.4y4i6bdpwx633qs7%40vbox-VirtualBox
Export to all formats seems to work well after removing the "ps2pdf"
option to the hyperref package.
Accordingly we uninvert the tests for the other formats. All ctests
pass on an updated TeX Live 2020.
This is mostly for shapepar support, in a rare situation. Fixing this would create a lot of special cases in output_docbook.cpp, i.e. fixing the issue (which will barely happen in real life) would make maintenance much harder.