Open YaLTeR opened 3 years ago
@jakobjakobson13 this looks like the updated texlive SDK is missing something with russian.
(since it was rebuilt with the newer version of the SDK)
any idea?
I have no actually idea, but something similar happened when I compiled latex document with lualatex on two different luatex versions without cleaning up the auxiliary files. It then always took two or three attempts (I don't recall exactly) to compile your latex file.
something similar happened when I compiled latex document with lualatex on two different luatex versions without cleaning up the auxiliary files
Doesn't look like Setzer leaves any auxiliary files in my case.
I won't be able to look into it until next weekend. Could you in the meantime check if you get the error message as well with other tex editors from flathub? That could help to narrow the problem down.
What other editor should I try?
Just for the record the only change in this package with the previous are:
I tried this, and it works:
(I basically cut and paste your code above and added the last two lines)
In a new document:
In a new document:
Could you check your directory for a log file and if one exits, post it?
There's nothing in the directory apart from the .tex file and a .pdf file which looks like this:
There's nothing in the directory apart from the .tex file and a .pdf file which looks like this:
Okay, could you check then if the tex file compiles with texworks (from flathub)?
I can't seem to compile with it, all engines are grayed out and it says the engines aren't configured correctly.
After installing the texlive extension I get a similar looking output in texworks:
Package polyglossia Warning: No hyphenation patterns were loaded for `russian'
(polyglossia) I will use \language=\l@nohyphenation instead on i
nput line 17.
! Undefined control sequence.
\adddialect ...####1####2####3####4{}\fi }\bbl@cs
{languages}\endgroup
l.17 }
?
As your file worked on my computer with the following programs
Kennung: org.cvfosammmm.Setzer
Ref: app/org.cvfosammmm.Setzer/x86_64/stable
Architektur: x86_64
Zweig: stable
Version: 0.4.1
License: GPL-3.0-or-later
Ursprung: flathub
Sammlung: org.flathub.Stable
Installation: system
Installiert: 6,7 GB
Laufzeitumgebung: org.gnome.Platform/x86_64/3.38
Sdk: org.gnome.Sdk/x86_64/3.38
Commit: 6cb19660bcfd7ea2a9e6aabd265d55e1a65d948f71e3825e0aa25ea5db5a8d30
Parent: 60deb0fafcae735433d32b3540086728ead3ead7b18e8d57a38d257d9dfa1f8b
Subject: Enable aarch64 build now there is a texlive (f0663214)
Date: 2021-04-10 02:09:10 +0000
and
Kennung: org.tug.texworks
Ref: app/org.tug.texworks/x86_64/stable
Architektur: x86_64
Zweig: stable
Version: 0.6.6
License: GPL-2.0+
Ursprung: flathub
Sammlung: org.flathub.Stable
Installation: system
Installiert: 114,6 MB
Laufzeitumgebung: org.kde.Platform/x86_64/5.15
Sdk: org.kde.Sdk/x86_64/5.15
Commit: b57b068a614ba9fe04ef72a2604dfff7031bf0ffadac71bf8b8ee9719042ab3d
Parent: 9f05563debb63d4e3efe526d4d493272ea97286d60e8230296267cabae3e716c
Subject: Update to Texworks 0.6.6 (776ed18a)
Date: 2021-03-12 09:14:23 +0000
I'm running out of ideas. As the last idea I would suspect that some old configuration file has corrupted your system.
You could try the command flatpak remove org.cvfosammmm.Setzer --delete-data
to delete Setzer WITH its configuration files, reinstall it and test your document afterwards again.
So I just removed ~/.texlive2020/
and Setzer was able to build the document fine. I have that folder because I need to compile another document using a full-fledged texlive installation (in a toolbox in my case). I guess there's some conflict where Flatpak texlive picks it up even though it shouldn't?
I guess there's some conflict where Flatpak texlive picks it up even though it shouldn't?
Well, I guess that depends on your point of view: Do you want to decouple the flatpak texlive completely from the user/system texlive configuration or not? The first case makes the addition of unofficial packages and classes quite difficult whereas the second case gives you the option of tweaking your installation with the potential of serious compatibility issues such as yours.
In the end, I'm not sure about the best way to handle this and if you have a good idea, please let me know.
I guess to me it would make more sense to decouple flatpak texlive because flatpak apps are supposed to be self-contained, and I would expect the bundled texlive to already contain most packages. This has a major benefit of never breaking due to the host texlive being incompatible with the flatpak texlive, even when using different versions of the flatpak texlive (e.g. some older app which hasn't got a runtime bump).
A common pattern for flatpak apps is to put their own mirrors of config, cache and share to ~/.var/app/a.b.c/
, perhaps texlive could also be restricted to ~/.var/app/org.cvfosammmm.Setzer/cache/texlive2020
? Then you can still add packages without compatibility issues.
I guess to me it would make more sense to decouple flatpak texlive because flatpak apps are supposed to be self-contained, and I would expect the bundled texlive to already contain most packages. This has a major benefit of never breaking due to the host texlive being incompatible with the flatpak texlive, even when using different versions of the flatpak texlive (e.g. some older app which hasn't got a runtime bump).
This behavior should be achieved by the deletion of the following two lines:
"--env=TEXMFCACHE=$XDG_CACHE_HOME",
"--env=TEXINPUTS=.:~/texmf/:",
But I'm not the maintainer, so I'm not the person to discuss it with.
I suggest you change the title to something like "Use only the bundled TexLive and ignore texmf files in home". I think I agree with the "decouple approach". Perhaps you can add in the README that adding those two lines allows to use TexLive packages installed in the home directory (and warn about possible conflicts).
Fedora 34 Silverblue, Wayland.
I have a fairly standard document in Russian which I compile with XeLaTeX, nothing unusual. After the last update I'm getting these weird errors:
The first three line numbers don't change even when removing lines above them.
Here's the start of the document:
Downgrading to before last Flathub commit fixed the issue.