Upgrade to TeXLive 2022.03.21

[Kernald]

This also take advantage of macOS's universal binaries that are now available to add an Apple Silicon compatible toolchain.

Fixes #65 and #82.

[Kernald]

Most seems to still be working just fine - as far as I understand, the only missing thing is regenerating the list of packages and their checksums (as well as checking if the patch for bezos is still required).

[Kernald]

The bezos package is structured quite differently - I assume the patch isn't necessary anymore.

There seem to be an issue with the way @texlive_extra__tlpkg__TeXLive was generated - I'll check that one tomorrow.

[Kernald]

@texlive_extra__tlpkg__TeXLive is all good now (the name was wrong, it ended up as @texlive_extra__tlpkg__TeXLive__ - renamed). But for whatever reason, latexrun can't seem to find lualatex's recorder file.

[Kernald]

Running latexrun in the sandbox in a very similar way as what tool_wrapper.py is doing is working fine. Either a binary is missing somewhere and latexrun is able to find it on my path (I do have LaTeX installed locally - maybe I should remove that temporarily), or something in the exact invocation is different.

[solsjo]

@Kernald

Is this related? https://www.mail-archive.com/bug-guix@gnu.org/msg27542.html

[Kernald]

@Kernald

Is this related? https://www.mail-archive.com/bug-guix@gnu.org/msg27542.html

Looks like it, great find! I'll have a look at that over the next few days.

[solsjo]

@Kernald

Not knowing much anything at all about latex internals I did the following, pretty much fuzzy throwing commands at latex to see what sticked, and at least this made the my_report => pdf work: my_dvi_report => dvi, still fails though, with "still chaning after 10 tries"

diff --git a/BUILD.bazel b/BUILD.bazel
 index 4d6ab75..0178f10 100644
 --- a/BUILD.bazel
 +++ b/BUILD.bazel
 @@ -61,6 +61,14 @@ filegroup(
          "@texlive_texmf__texmf-dist__fonts__type1__public__cm-super",
          "@texlive_texmf__texmf-dist__fonts__type1__public__lm",
          "@texlive_texmf__texmf-dist__scripts__texlive", 
 +       "@texlive_texmf__texmf-dist__tex__latex__l3packages__xparse",
 +       "@texlive_texmf__texmf-dist__tex__luatex__lua-uni-algos",
 +       "@texlive_texmf__texmf-dist__tex__generic__pdftexcmds",
 +       "@texlive_texmf__texmf-dist__tex__generic__infwarerr",
 +       "@texlive_texmf__texmf-dist__tex__generic__ltxcmds",
 +       "@texlive_texmf__texmf-dist__tex__latex__kvoptions",
 +       "@texlive_texmf__texmf-dist__tex__generic__kvsetkeys",
 +       "@texlive_texmf__texmf-dist__tex__latex__l3backend",
          "@texlive_texmf__texmf-dist__tex__generic__config",
          "@texlive_texmf__texmf-dist__tex__generic__hyphen",
          "@texlive_texmf__texmf-dist__tex__generic__tex-ini-files",
 diff --git a/tool_wrapper.py b/tool_wrapper.py
 index e4b128f..b678f74 100644
 --- a/tool_wrapper.py
 +++ b/tool_wrapper.py
 @@ -49,7 +49,7 @@ def setup_env(env, texinputs, tools):
          for tool in tools:
              if "luatex" in tool:
                  shutil.copy(tool, "bin/lualatex")
 -                os.link("bin/lualatex", "bin/luatex")
 +                os.link("bin/lualatex", "bin/luahbtex")
              else:
                  shutil.copy(tool, "bin/" + os.path.basename(tool))

Or I never checked the pdf output, but at least it built without error

[solsjo]

Apparently, the dvi build succeeds after a number of retries, it is hard to understand / know if there is a random seed or if there is some non-hermetic temp artifact that remains somewhere, but a least the dvi also builds (eventually)

[Kernald]

Thanks! I'm working on updating every package for now with your two suggestions applied, I'll look into the DVI case a bit later.

[solsjo]

Ack! Great! Note that I have a poor understanding of latex engines and that I don't really understand why changing the symlink had a good effect. So when we / you do understand why it works it might be a good thing to at least document with a comment. At least for my sake 😅

[Kernald]

This PR is now at a point where every package builds except for hanging. No output is produced for that one, I'm not sure why (I haven't had a chance to look into it just yet, I skipped it while fixing the other packages). To reach this point, I took a few shortcuts that will need addressing (ideally before this is merged) with some packages, e.g. etexcmds is required for a few different packages and should be its own latex_package target with a test file, but for now a few packages are depending on @texlive_texmf__texmf-dist__tex__generic__etexcmds instead.

On top of that, there's still the situation with luahbtex shadowed by lualatex - it might be a correct workaround for now, but I'd very much like to understand why luahbtex doesn't run properly.

[solsjo]

During search for other clues, I bumped into the portable installation (for USB) for texlive, would it make sense to do a portable installation somewhere and inspect the layout and do the same thing in our bin directory.

It is sort of frustrating to debug in the dark.

[Kernald]

Looks like hanging not emitting an output is a legitimate issue with the current test file - \hangpara{2em}{1} indicates that the next paragraph will be offset, but the test actually doesn't define a paragraph at all. Adding some content right after fixes the test.

[solsjo]

@Kernald I went through the documentation for latex and I think I have developed some further understanding. Some binaries consider their invocation name, e.g. luatex can inspect call argument 0 and see that the argument is lualatex. After which it will proceed to act as lualatex. That was what the symlinks were for.

Now, there is a another way way of doing so via the cli commands instead, i.e. --progname,

so call luatex like so: $ luatex --progname=lualatex ... is the same as $ lualatex ... where lualatex is a symlink to luatex, same goes for luahbtex.

The following patch seems to generate pdf's in a stable manner. however dvi still fails.

mypatch.patch.zip

When enabling debug messages and verbose output for latexrun, I notice that the bibtex and latex-commit task output seems stable.

task latex_commit::example/my_report.tex: stable
scanning for bib commands in latex.out/my_dvi_report.aux
hashing /home/ubuntu/.cache/bazel/_bazel_ubuntu/fffa911f23665d399267772f4476408c/sandbox/linux-sandbox/2/execroot/bazel_latex/example/references.bib
hashing latex.out/my_dvi_report.bbl
hashing latex.out/my_dvi_report.blg
task bibtex::example/my_report.tex: stable
fixed-point not reached
error: files are still changing after 10 iterations; giving up

The following arguments were provided:
['latexrun', '--latex-cmd=luahbtex', '--verbose-cmds', '--debug', '--latex-args=--progname=lualatex --output-format=dvi --shell-escape --jobname=my_dvi_report', '--bibtex-cmd=biber', 'example/my_report.tex']
content in dir:
['.texlive2022', 'tool_wrapper.py', 'my_dvi_report.dvi', 'bazel-out', 'external', 'latex.out', 'bin', 'example', 'texmf']

https://github.com/aclements/latexrun/blob/master/latexrun#L168

I hope some further debugging can resolve that.

I also noted a bug that I might have introduced. It is not possible to supply --latex-args mutliple times.

The bug is not fixed in the above patch, but I atleast remedy it. so all --latex-args must be supplied in the same string or we update latexrun with another patch so that it supports append operation of the --latex-args command.

Note, the pdf output was atleast stable for three separate runs with bazel clean in-between.

Hope that helps somewhat.

[solsjo]

Tests still fail. @Kernald you mentioned that running locally works.

Perhaps we should compare the verbose output for a local latexrun with the output for the bazel-latex latexrun.

[Kernald]

Tests still fail. @Kernald you mentioned that running locally works.

I kind of lied unknowingly :-/ After a clean, it sometimes fails - still changing after 10 iterations. I got it to fail on glossaries-extra_test once, as well as my_dvi_report.dvi twice until everything built just fine. I'm really not sure what's causing this.

As a sidenote, I won't have much time to work on that over the coming days.

[solsjo]

No worries!

[solsjo]

I suspect that there is some output from either the new toolchain, or updated packages that intermittently?? outputs either file/log or updates the output with timestamp/other info.

I read that mklatex has diagnostics support which could help identify what parts of the output that changes.

latex does not converge

I might give that a try, or update latexrun with such output (if it doesn't have that.

[solsjo]

@Kernald, I noticed that the lualatex.fmt file seems to be the file that changes, invalidating the hash in latexrun.

My plan was to generate the lualatex.fmt file with the -ini mode and then call lualatex with --fmt, to see if that would remedy the issue.

I never got that far, but it seems just generating the lualatex.fmt with --ini mode prior to running the compiliation makes the compilations go pass.

If you have time, apply the patch and see how it works out in the github actions pipeline: patch2.patch.zip

[solsjo]

It does at least seemingly run glossaries and babel_english/dutch and all the examples after bazel clean --expunge

[Kernald]

@Kernald, I noticed that the lualatex.fmt file seems to be the file that changes, invalidating the hash in latexrun.

I vaguely remember reading that such a file was included in a package in TeXLive 2021, it might be worth checking if we can reuse a pre-built one?

If you have time, apply the patch and see how it works out in the github actions pipeline: patch2.patch.zip

I'll try that as soon as possible, thanks!

[Kernald]

This seems promising @solsjo, thanks! Cirrus CI is using l.gcr.io/google/bazel:latest which still bundles Python 3.5, without f-strings, so this needed a bit of tweaking - we should probably start depending on rules_python eventually to use a specific version rather than relying on the system version. Not a priority at this stage though, using format is fine.

The Ubuntu failures on CI aren't related (see #93), and this works just fine both locally on my Linux machine, on Cirrus CI, and (parly?) on macOS on GitHub Actions. I'll try on a arm64 macOS a bit later, for completeness, but this is getting close to be mergeable! Thanks a lot for the debugging you've done here! :tada:

[Kernald]

Confirming, this also works just fine on a arm64 macOS - much faster than through Rosetta too! (208s vs 299s)

[Kernald]

While this is probably ready, I'll quickly make a pass to close every issue I can/merge any unrelated PR, to tag a last release with TeXLive 2019, before merging this and tagging a new release.

[solsjo]

@Kernald Thanks! ☺️ Regarding the Docker image in the cirrus.yml is stale. See the svg pull-request

The docker image of use should be:

image: gcr.io/bazel-public/bazel:latest

The other docker is stuck at Bazel 3.5

[Kernald]

Oh, nice catch! I didn't even think of checking the Bazel version in the image. #100 is fixing that independently.

Speaking of #87, would you like to rebase it on master once #100 is merged and try to get that one merged before merging this (TeXLive 2022)?

[solsjo]

Cool! Nah, take in the 2022, it's the most bang for the buck.

I've done some local experiments cherry-picking the svg PR on top of this and it works. 🙂 Some refactoring is needed to the latex.bzl and tool wrapper.

However, the platforms support might require some extra work. As will making sure that Ghostscript isn't rebuilt on unrelated changes. Because it takes some 300-400s to compile.