Contribution List export to pdf fails with LaTeXRuntimeException

1

Hello all,

In our indico instance (https://events.ni4os.eu), PDF generation fails for all contribution lists with a LaTeXRuntimeException. PDF generation works fine for timetables.

LaTeX has been installed following the instructions in https://docs.getindico.io/en/stable/installation/latex/

For example, export to PDF for the following contribution list fails, and creates the attached output.log:

In output.log the first error is:

“! LaTeX3 Error: File ‘xparse-generic.tex’ not found.”

However, xparse-generic.tex is present on the system, and xelatex succeeds when it is executed manually on the same tex file under /opt/indico/tmp/ .

Any help would be greatly appreciated.

output.log (37.5 KB)

2

Debugging this type of LaTeX issue is usually extremely hard, so the first thing I’d try is reinstalling texlive from scratch (rm -rf /opt/texlive/ and /tmp/install-tl-* too if it still exists, then re-run the commands from our texlive install guide) to make sure it’s fully up to date.

Also, when did you install texlive? They have rolling releases so it’s impossible for us to recreate the same environment you have, but knowing if a recent change broke something would already help.

In case you are on CentOS or any other system with SELinux enabled also check if this is causing any problems (try setting it to permissive temporarily).

PS: The timetable PDFs do not use LaTeX - that’s why they work even if nothing latex-related is enabled at all.

3

Initially I had installed texlive 20200803. I removed it, and installed from scratch texlive 20200916. I also set SELinux to permissive, and upgraded Indico from version 2.2.8 to version 2.3. The error persisted between and after all these changes.

OS is CentOS 7.8.

Because it seemed weird that xelatex succeeded when run manually, I made a wrapper for xelatex, that prints to a file the parameters and environment and then calls xelatex. I found that when xelatex is called by Indico, this additional environment parameter is set:

TEXMFCNF=/opt/indico/.venv/lib/python2.7/site-packages/indico/legacy/pdfinterface:

I tested xelatex from the command line with this parameter set and it failed, with the same errors as in output.log.

4

Hello, I have exactly the same issue… week old installation, CentOS7.8, Indico 2.2.8, texlive 20200913. The same error. My dirty workaround was not to populate TEXMFCNF env variable by modify line 137 of file

/opt/indico/.venv/lib/python2.7/site-packages/indico/legacy/pdfinterface/latex.py

from

env=dict(os.environ, TEXMFCNF='{}:'.format(os.path.dirname(__file__)))

to

env=dict(os.environ, TEX='{}:'.format(os.path.dirname(__file__)))
1 Like
5

I think your workaround simply prevents the custom config file from being used, and thus removes a last line of defense against malicious LaTeX code trying to read local files (like a config file containing a password) that managed to get through our LaTeX sanitization.

Not sure how to solve it so far… let’s see if people more familiar with LaTeX have an idea… or maybe it’s a bug in texlive…

1 Like
6

This is a bug in TeXLive. See my Stack Exchange post and the mailing list thread linked there for details.

As a workaround until updated TeXLive packages are available you can apply this patch (details):

diff --git a/indico/legacy/pdfinterface/latex_templates/inc/document.tex b/indico/legacy/pdfinterface/latex_templates/inc/document.tex
index c3fea25f31..21bc90be27 100644
--- a/indico/legacy/pdfinterface/latex_templates/inc/document.tex
+++ b/indico/legacy/pdfinterface/latex_templates/inc/document.tex
@@ -1,3 +1,4 @@
+\expandafter\let\csname file_input:n\endcsname\input
 \JINJA{block document_class}
     \documentclass[a4paper, 15pt]{article}
 \JINJA{endblock}
7

We have applied the patch and it works.

Thank you for the support!

8

FYI, we installed the latest texlive release 20201005, and it resolves the issue without the need for a workaround.

9

Good to hear - no need for us to include this workaround in a release then.