latest latex version fails to produce pdf

[markus2330]

@lukashartl is it possible that we lack some Doxygen/LaTeX dependency?

Build for master and all PRs where I tried, e.g. #4440 #4448, fail but I cannot reproduce it locally: the pdf (2378 pages) builds successfully.

I tried to disable l1 and restarted a job but it doesn't seem to be specific to l1.

[atmaxinger]

That's funny, because it worked yesterday evening after the downtime.

[markus2330]

@atmaxinger Thanks for sharing!

13h ago, triggered by libelektra-monthly, the first job failed on master with that error message.

Merging 799fecd94dcb482ea9338facaf63d39f8e5ab5bd, which looks like it could cause such an issue was already 5 days ago. In #4410 all build jobs were successful. So it is probably not the cause?

Looking at https://build.libelektra.org/blue/organizations/jenkins/libelektra/activity my best guess at the moment is: It might be caused by a problematic Doxygen/LaTeX upgrade around 15h ago?

[atmaxinger]

Okay, so locally on my system, building the PDF also works.

But if I build it in the same docker image that Jenkins uses, it fails - in that way it's reproducable. Somehow while generating the PDF it seems to go into an interactive mode and awaits user input, but Jenkins can't deliver it so it fails.

This is the full list of inputs it awaits before it repeats itself:

! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing { inserted.
<to be read again> 
                   _
l.854 \end{DoxyRetVals}
                       

? 
! Missing } inserted.
<inserted text> 
                }
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing { inserted.
<to be read again> 
                   _
l.854 \end{DoxyRetVals}
                       

? 
! Missing } inserted.
<inserted text> 
                }
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing { inserted.
<to be read again> 
                   _
l.854 \end{DoxyRetVals}
                       

? 
! Missing } inserted.
<inserted text> 
                }
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing { inserted.
<to be read again> 
                   _
l.854 \end{DoxyRetVals}
                       

? 
! Missing } inserted.
<inserted text> 
                }
l.854 \end{DoxyRetVals}
                       

? 
! Missing $ inserted.
<inserted text> 
                $
l.854 \end{DoxyRetVals}
                       

? 
! Missing \endcsname inserted.
<to be read again> 
                   \def 
l.854 \end{DoxyRetVals}
                       

? 

[atmaxinger]

Okay, funny thing ...

The error seems to be located in the generated latex file group__keyname.tex on line 853. What's funny is, that the locally generated file (right) has different content than that one generated in the Docker container (left). (Yes, both were built from the current master branch)

[markus2330]

Thank you very much for investigating! :detective:

Looks very much like that the one version of Doxygen produces a syntax-error in its output.

What are the Doxygen versions locally and in the Docker container?

I have Doxygen 1.9.1 (Debian stable), where the docu builds successfully.

Is the problem already reported upstream (in Doxygen)?

To fix the problem, we shouldn't base doc.Dockerfile on Debian sid (scripts/docker/debian/sid/doc.Dockerfile) but rather on Debian stable (or something else stable). This makes failures due to dist-upgrades much less likely. I think the reason why the container is based on sid is obsolete long time ago (there was some feature in Doxygen we needed not available in Debian stable at that time.)

[atmaxinger]

Yes it works with debian stable (bullseye) in the docker container! I will create a PR for it.

[markus2330]

I made a report in https://github.com/doxygen/doxygen/issues/9567 but unfortunately without any minimal example etc.

@atmaxinger if you can provide more info in this issue, please do so directly in the issue. (Some questions above you did not answer, e.g., the local and the sid version of Doxygen)

Not reporting such issues can bite yourself badly: then we might get a broken Doxygen in the next Debian stable release.

[atmaxinger]

I'm working on a minimal sample. The Doxygen version is 1.9.4. Currently trying to find out which .c-file is responsible for creating group__keyname.latex and which Doxygen paramters are used by the build.

[markus2330]

@atmaxinger there is actually no urgency the triage (finding a minimal working example) can also be done later by someone doing FLOSS. It is actually a very nice exercise.

Hint for who will do it: group__keyname is probably related with the the group defined in src/libs/elektra/keyname.c

[atmaxinger]

I actually already created a sample. You can run run.sh to reproduce it on Debian Sid, on Debian Bullseye it works fine.

HOWEVER it seems more to do with LaTeX than Doxygen, as the files generated by Doxygen on Bullseye also show the same behaviour with pdflatex on Debian Sid.

EDIT: Added a working ZIP file with Doxyfile in it

elektra-sample.zip

[markus2330]

Great job, please report to https://github.com/doxygen/doxygen/issues/9567

[markus2330]

Next points to check are if other LaTeX compilers also fail (XeLaTeX and LuaLaTeX).

Furthermore, we could try to simplify LATEX_CMD_NAME, which probably does not need to be set by us, see also https://github.com/doxygen/doxygen/issues/9567

[kodebach]

I suspect this is an issue with one of the texlive packages on Debian Sid rather than a pdflatex issue. The question is just which of the packages is the problem, so that we can report the problem.

I generated the LaTeX files (for the elektra-sample.zip example) with doxygen in a debian:sid Docker Container. Running pdflatex fails in the container, as described above. But if I know run pdflatex on my Manjaro host system on the exact same files, everything works fine. Both systems use the same version of pdflatex:

# debian:sid
pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian)
kpathsea version 6.3.4
Copyright 2022 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.37; using libpng 1.6.37
Compiled with zlib 1.2.11; using zlib 1.2.11
Compiled with xpdf version 4.04

# Manjaro host
pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022/Arch Linux)
kpathsea version 6.3.4
Copyright 2022 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.37; using libpng 1.6.37
Compiled with zlib 1.2.12; using zlib 1.2.12
Compiled with xpdf version 4.03

The zlib and xpdf versions are different, but AFAICT that shouldn't matter since the problem is not with the generation of the PDF, but the parsing of LaTeX.

[markus2330]

@kodebach you might be right about the cause but it is irrelevant: still it is better to first exclude possibilities that are easy to check (latex compiler) and then continue to investigate possibilities more difficult to check. Your method did not exclude the possibility that it is the fault of the latex compiler. E.g. it is possible that one patch applied by Debian causes the problem (or Manjaro fixes the problem), so even exact same version information does not tell the whole story.

Anyway, there is absolutely no urgency in this issue (blockers of new-backend on the other hand are urgent right now) and this issue is nice for FLOSS, so please let us withhold any further investigations or bug triaging :wink:

[kodebach]

This issue blocks all PRs so I would say it is actually urgent. But yes it's nice for FLOSS so let's leave it.

Maybe we should disable PDF generation for now, or at least move it to a later stage in the Jenkins pipeline so we can ignore the failure and still have all other checks run.

[atmaxinger]

This issue blocks all PRs so I would say it is actually urgent.

Strongly disagree here. This issue has been fixed by not using Debian Sid to generate the PDF - #4456. PRs into master should work fine now.

[kodebach]

Okay sorry, I missed that because the PRs linked in the top post still fail. But it seems they were not rerun after the fix

[github-actions[bot]]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:

[github-actions[bot]]

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: