possible doc race condition - ideas or insight?

[Mike Miller]

All,

I've noticed a build failure of Octave 4.0.0 (with Texinfo 6 patches) on
one of the Ubuntu autobuilders [1]. The error message

  kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+3/600 --dpi 603 
ecti1095
  mkdir: cannot create directory '././home/buildd/.texmf-var/fonts/pk/ljfour': 
File exists
  mktexpk: /usr/share/texlive/texmf-dist/web2c/mktexdir 
/home/buildd/.texmf-var/fonts/pk/ljfour/jknappen/ec failed.
  kpathsea: Appending font creation commands to missfont.log.
  (Operator Index) [953] [954]) [955] [956] )
  (see the transcript file for additional information)
  !pdfTeX error: pdfetex (file ecrm1095): Font ecrm1095 at 603 not found
   ==> Fatal error occurred, no output PDF file produced!

looks to me like some kind of simultaneous access failure. I have not
been able to reproduce this myself, but I suspect a race condition
between the dvips and texi2pdf (which calls pdfetex) programs.

I won't pretend to understand much about the TeX software suite, but it
seems to be compiling fonts and caching the results in the user's home
directory as needed. I believe these font caches are a result of the
recent upgrade to a new texinfo.tex, needed to support GNU Texinfo 6.

All I've been able to verify myself are that the octave.ps and
octave.pdf targets do both create font caches (with the same two fonts)
in ~/.texmf-var/fonts (the directory may be different on another distro)
if I make those targets individually. But I have not yet triggered the
failure shown above with my own parallel builds.

Anyone understand more about this problem? Any opinions if we should do
anything about this? A couple of options might be

 * make octave.pdf order-depend on octave.ps to force serial execution
 * set either the TEXMFVAR or VARTEXFONTS environment variables similar
   to the --build-dir option
 * ignore it

[1]: 
https://launchpadlibrarian.net/212257965/buildlog_ubuntu-wily-i386.octave_4.0.0-3_BUILDING.txt.gz

Thanks,

-- 
mike