0

I am running Debian 10 and using emacs 26.1 to create a PDF from an org file via xelatex. Everything works fine, but recently, the xelatex takes much longer than it used to. When I trace the process I see a lot of lines like the following:

access("/home/loris/texmf/tex/latex/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/demo/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/docker/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/source/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)
access("/home/loris/texmf/tex/latex/mtheme-master/doc/longtable.sty", R_OK) = -1 ENOENT (No such file or directory)

The individual files do not indeed exist, but the paths, such as

/home/loris/texmf/tex/latex/mtheme-master

do. Thus, it seems like a recursive search for, in this case, longtable.sty, is slowing down the whole process. The file is actually available here:

/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty

So it looks like the search order for packages is incorrect. Can anyone tell me where this might be configured? None of the $TEXMF* variables seem to be defined in my enviroment.

7
  • 1
    check your config file (one listed by kpsewhich --all texmf.cnf for the setting of TEXINPUTS(.xetex) your /home/loris/texmf/tex tree should be guarded by !! so that it is only searched when you use mktexlsr not any every file access Commented Mar 26, 2020 at 10:07
  • In /usr/share/texlive/texmf-dist/web2c/texmf.cnf I have TEXMFHOME = ~/texmf and this is indeed included in $TEXMF without ```!!``. This is the Debian default. Is this incorrect?
    – loris
    Commented Mar 26, 2020 at 10:38
  • 1
    normally texmf home doesn't have !! because its small and lets you drop files there without having to update the hashed list, and the big search trees are elsewhere, but you seem to have a big search tree installed there so .... Commented Mar 26, 2020 at 10:40
  • Actually the tree isn't that big (11 directories in total according to tree) and the slow down has occurred several months after the last change in ~/texmf.
    – loris
    Commented Mar 26, 2020 at 10:52
  • without !! kpsewhich essentially works like the unix find command and unless there are a few thousand files it's not usually worth the bother of using !! and hashing the file list. So it maybe something else, you could try it and see,, otherwise I can't really help as that was my only guess, sorry Commented Mar 26, 2020 at 11:22

1 Answer 1

0

As I mention in my comment, the problem in my case was caused by accessing the org file via both sshfs and VPN. These extra layers seem to cause a dramatic slow down.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .