With Debian's packages, as of version 2023, some math characters
get replaced. For instance, consider

\documentclass{article}
\pagestyle{empty}
\begin{document}
$x'$ ; $\oplus$ ; $\ominus$ ; $\otimes$ ; $\ell$ ; OK.
\end{document}

I get the following:

────────────────────────
x0 ; ⊕ ;

; ⊗ ; ` ; OK.
────────────────────────

instead of

────────────────────────
x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.
────────────────────────

No issue in Debian/stable (12.2). And several users say that an
up-to-date TeX Live 2023 is fine too. (I'll try, but the installation
is still ongoing.)

So this is either a Debian-specific bug or the issue has recently been
fixed upstream.

I forgot to say that these are the characters obtained with
pdftotext (the issue is not with the glyphs, but with the
textual part).

Hi Vincent,

Sorry, I'm failing to reproduce:

hille@sid:~$ pdflatex a
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian)
(preloaded format=pdflatex)
  restricted \write18 enabled.
entering extended mode
(./a.tex
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./a.aux) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
(./a.aux)
)</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/te
xmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
Output written on a.pdf (1 page, 36600 bytes).
Transcript written on a.log.
hille@sid:~$ pdftotext a.pdf
hille@sid:~$ cat a.txt
x′ ; ⊕ ; ⊖ ; ⊗ ; ℓ ; OK.

, which looks good, IMHO. Could you add \listfiles to the top of your
document and post the logfile here?

Hilmar

This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./a.tex
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./a.aux) [1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./a.aux)

 *File List*
 article.cls    2023/05/17 v1.4n Standard LaTeX document class
  size10.clo    2023/05/17 v1.4n Standard LaTeX file (size option)
l3backend-pdftex.def    2023-04-19 L3 backend support: PDF output (pdfTeX)
 ***********

 )</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></us
r/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/share
/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texli
ve/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
Output written on a.pdf (1 page, 34719 bytes).
Transcript written on a.log.
zira:~> pdftotext a.pdf
zira:~> cat a.txt
x0 ; ⊕ ;

; ⊗ ; ` ; OK.


Here's the log file:

This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex 2023.11.21)  24 NOV 2023 01:04
entering extended mode
 restricted \write18 enabled.
 %&-line parsing enabled.
**a
(./a.tex
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2023/05/17 v1.4n Standard LaTeX file (size option)
)
\c@part=\count185
\c@section=\count186
\c@subsection=\count187
\c@subsubsection=\count188
\c@paragraph=\count189
\c@subparagraph=\count190
\c@figure=\count191
\c@table=\count192
\abovecaptionskip=\skip48
\belowcaptionskip=\skip49
\bibindent=\dimen140
)
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
File: l3backend-pdftex.def 2023-04-19 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count193
\l__pdf_internal_box=\box51
)
(./a.aux)
\openout1 = `a.aux'.

LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    Checking defaults for TS1/cmr/m/n on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 4.
LaTeX Font Info:    ... okay on input line 4.
LaTeX Font Info:    External font `cmex10' loaded for size
(Font)              <7> on input line 5.
LaTeX Font Info:    External font `cmex10' loaded for size
(Font)              <5> on input line 5.
 [1

{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./a.aux)
 ***********
LaTeX2e <2023-06-01> patch level 1
L3 programming layer <2023-08-29>
 ***********


 *File List*
 article.cls    2023/05/17 v1.4n Standard LaTeX document class
  size10.clo    2023/05/17 v1.4n Standard LaTeX file (size option)
l3backend-pdftex.def    2023-04-19 L3 backend support: PDF output (pdfTeX)
 ***********

 )
Here is how much of TeX's memory you used:
 428 strings out of 474928
 8156 string characters out of 5762151
 1917791 words of memory out of 5000000
 22058 multiletter control sequences out of 15000+600000
 558069 words of font info for 36 fonts, out of 8000000 for 9000
 1141 hyphenation exceptions out of 8191
 35i,5n,50p,133b,100s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></us
r/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/share
/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texli
ve/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
Output written on a.pdf (1 page, 34719 bytes).
PDF statistics:
 28 PDF objects out of 1000 (max. 8388607)
 16 compressed objects within 1 object stream
 0 named destinations out of 1000 (max. 500000)
 1 words of extra memory for PDF output out of 10000 (max. 10000000)

It seems that the cause of the issue is that at package installation,
the current TEXINPUTS is taken into account. So it uses my own
glyphtounicode.tex file (needed as a workaround to a Ghostscript
bug) instead of the one from the package.

The issue disappears if I remove my glyphtounicode.tex file and
do "apt install --reinstall texlive-base".

Now /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex
correctly appears in /var/lib/texmf/web2c/pdftex/pdflatex.log.

If I understand correctly, /var/lib/texmf/web2c/pdftex/pdflatex.fmt is
generated by fmtutil, but its man page does not say that $TEXINPUTS is
used.

	sudo fmtutil-sys -all

would also do it.

Because, as you were told already, this is an inherent and historic TeX
variable.

And because you decided to break your system by setting up env vars as
root, without knowing their impact. That is a guaranteed recipe for
shooting yourself.

Best regards

Norbert

On 24.11.2023 03:50, Vincent Lefevre wrote:

Hi,

Well, fmtutil in turn calls the TeX interpreters / compilers, which then
read $TEXINPUTS and find your file. I'd say: you broke your system
somehow, I tend to close the bug.

H.

I didn't break anything. Any user, including root, may have his own
environment variables for his own use. This should never interfer
with package installation.

Why not unsetting TEXINPUTS in the postinst script?

No. That is simply not true. Not root.

I told you this already, please read.
Because root might set TEXINPUTS on *purpose*.
How should the package installation distinguish a falsely set TEXINPUTS
from a correctly set TEXINPUTS?


Norbert

Could you cite documentation saying that root must not set
arbitrary environment variables?

Note: The setting of TEXINPUTS in my case was not on purpose
(well, actually keeping the usual settings, such as LS_COLORS,
was actually there on purpose). But this could have been done
really on purpose. And this would have broken the package
installation.

I never said that. But if they are set, root must be aware of the
consequences, and the envvars might have effect on how packages work.

root can make / ro and break installation.
root can set their own shell to fish with probably interesting
consequences.
root can do soo many things to break package installation

Best regards

Norbert

This is not documented at all. So, in doubt, root must not set *any*
environment variable, except those clearly documented. Note that root
may not know which packages will be installed (for instance, texlive
may be brought by a dependency). So, really, any environment variable
that is non standard and unrelated to the package installation system
could be problematic, even though the user could have thought it
would be private.

Here, this is not how packages work, but how packages are installed.

I would expect installation to fail, not to silently yield an
incorrect installation. Note that there may be reasons that /
may be ro, such as disk errors at mount time.

You could have cited zsh, which is not a POSIX shell either.
AFAIK, various users use zsh as their root shell.

If chsh allows non-POSIX shells to be selected, this should
really be supported.

Hi Vincent,

Since I am not using Debian, nor developing for Debian, I think I stop
arguing here. No need to discuss my opinion on that matter further.
Feel free to bring it up to the TC, or d-d, or whereever you feel is the
correct place.

Norbert

On 25.11.2023 01:20, Vincent Lefevre wrote:

Hi,

The specific file (glyphtounicode.tex) is only read during format
generation AFAICT. So, if we unset the TEXINPUTS variable the fmtutil
will again read the default and you will loose your custom file. So
either leaving TEXINPUTS or clearing it will not get /your/ expected
results. I guess you need a correctly fixed glyphtounicode.tex, which
contains a correct fix, w/o breaking other things.

Currently I don't understand, why a file glyphtounicode.tex sitting in
/usr/local/share/texmf/tex/generic/pdftex/ is ignored during format
generation, but this is not the topic of this bug.

Hilmar

On 27.11.2023 01:06, Norbert Preining wrote:

Hello Norbert,

Many, many thanks for stepping in, I did not find the time to help here.
For now I'd rather contact debian-mentors and ask for their opinion. I
did not find any statement in the policy.

Hilmar

Control: severity -1 wishlist
Control: retitle -1 fmtutil should ignore TEXINPUTS set in root env

No, not in the past (before TeX Live 2021 -- my setting was predating
this version). For instance, see

https://superuser.com/questions/165073/is-it-possible-to-remove-ligatures-from-copied-text/325396#325396

https://github.com/latex3/latex2e/issues/465
both on the TeX Live side and on the Ghostscript side (where bugs
related to the ToUnicode CMap have eventually been fixed -- only
in Debian/unstable for one of them, though, and perhaps backports),
so that I could eventually get rid of glyphtounicode.tex completely.

In any case, package installation must give the same result whether
it comes from of a new installation or a later installation, where
environment variables could be set in /etc/profile or whatever
(this is not specific to TEXINPUTS, but applies to other arbitrary
environment variables as well).

Any config or workaround to bugs must occur at use time (e.g. when
running pdflatex on a .tex file), or by patching & rebuilding a
package.

Note: One may assume that a user would also like to test a local
TeX Live in /opt (possibly with an updated glyphtounicode.tex file),
and TEXINPUTS could be set on purpose in this context. This should
affect only the local installation, not Debian package installation.

Note also that the environment may also affect the build of packages,
and that's why tools like debuild sanitizes the environment. This
should be the case even more for the installation of packages when
needed.

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.