[gentoo-dev] LaTeX documentation

[gentoo-dev] LaTeX documentation

[Andrey Grozin]

Hello *,

Many packages have documentation in LaTeX, and latex is being run (often 
when USE=doc). This may cause a sandbox violation, if a font not yet 
generated on this particular computer is encountered: latex calls metafont 
to generate it, and metafont wants to write it to /var/cache/fonts (and 
its subdirectories). The worst thing is that this bug is unpredictable: if 
only commonly-used fonts are encountered, they are already in 
/var/cache/fonts, and everything is OK; on some other computer, the same 
package can produce a sandbox violation.

There are two methods commonly used to fight against this situation in 
ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The second 
method is, probably, better. The packages still using addwrite are:

app-doc/doxygen
app-office/kletterwizard
app-text/noweb
dev-lisp/cl-mcclim
dev-python/pyopenssl
dev-tex/feynmf
dev-tex/memoir
media-gfx/asymptote
media-libs/t1lib
media-libs/allegro
sci-chemistry/moldy
sci-mathematics/pari
sci-visualization/pyxplot

Probably, it would be a good idea to change these ebuilds.

The packages using the VARTEXFONTS method are

app-emulation/wine
app-text/jadetex
app-text/linuxdoc-tools
dev-lang/R
dev-tex/listings
dev-tex/texpower
dev-tex/envlab
dev-tex/bibtex2html
dev-tex/xcolor
dev-tex/latex2rtf
dev-tex/mh
media-libs/libcaca
media-libs/libdvdcss
media-libs/aubio
media-libs/libfishsound
sci-mathematics/octave
sci-visualization/gnuplot

Two of them convertex just recently: app-text/jadetex between 3.13-r1 and 
3.13-r2, and dev-tex/listings between 1.3 and 1.4. Good for them.

Most disturbingly, there are a number of packages which (probably) run 
latex and do neither addwrite nor VARTEXFONTS. An incomplete list of such 
suspect packages is (for now, I only considered packages not directly 
related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive and not 
TeX/LaTeX packages in app-text):

app-backup/bacula
app-emacs/pymacs
app-emacs/slime
app-emulation/xen-tools
app-i18n/canna
app-misc/tdl
app-misc/fdutils
dev-ada/xmlada
dev-ada/asis-gcc
dev-ada/asis-gpl
dev-embedded/avrdude
dev-haskell/lhs2tex         (*)
dev-lang/mlton
dev-lang/mmix
dev-libs/beecrypt
dev-libs/libtomcrypt
dev-lisp/gcl
dev-lisp/cl-cffi
dev-lisp/cl-cgi-utils
dev-lisp/cl-iterate/cl-iterate-1.4  (**)
dev-lisp/cl-tclink                  (***)
dev-lisp/cl-xml-psychiatrist
dev-lisp/clisp
dev-python/python-xlib
dev-python/pyx
dev-tcltk/tkzinc
dev-tinyos/tos
dev-util/bnfc
dev-util/ragel
dev-util/darcs
games-board/freedoko
media-gfx/sane-backends
media-sound/musescore           (****)
media-video/dirac
net-analyzer/ns
net-analyzer/sonar
net-dialup/mgetty
sci-biology/wise
sci-libs/netcdf
sci-libs/pgplot
sci-mathematics/axiom
sci-mathematics/ginac
sci-mathematics/nusmv
sci-misc/gri
sci-misc/nco
sys-block/btrace
sys-cluster/mpich2
sys-cluster/pvfs2
sys-cluster/charm
sys-power/apcupsd
sys-power/powersave

(*) By the way, here a .pdf file is installed using dodoc, and hence will 
be bzip2ed - not a goog idea

(**) but not later versions

(***) The only place where the USE flag "doc" is used commented out???

(****) USE flag "doc" never used??

These are (potentially) bombs waiting to blow up an unsuspecting user. 
They should be carefully checked.

By the way, while investigating this question, I found quite a few 
packages which still depend on virtual/tetex, while, probably, 
virtual/latex-base would be better (in some of them, the USE flag tetex 
then should become latex). Some suspects are:

app-doc/doxygen
app-emacs/slime
app-misc/tdl
app-misc/fdutils
app-misc/muttprint
app-misc/chesstask
app-office/eqe
app-office/texmaker
app-office/grisbi
app-office/kletterwizard
app-text/a2ps
app-text/dvipdfmx
app-text/noweb
app-text/active-dvi
app-text/evince
app-text/pdfjam
app-text/passivetex
app-text/kbibtex
app-vim/latexsuite
dev-ada/asis-gpl
dev-embedded/avrdude
dev-haskell/lhs2tex
dev-lang/mmix
dev-libs/libtomcrypt
dev-lisp/cl-mcclim
dev-lisp/cl-cgi-utils
dev-lisp/cl-iterate
dev-lisp/clisp
dev-lisp/cl-tclink
dev-lisp/cl-cffi
dev-perl/Template-Latex
dev-python/pyx
dev-python/epydoc
dev-tcltk/tkzinc
dev-tinyos/tos
dev-util/bnfc
dev-util/ragel
dev-util/darcs
games-board/freedoko
kde-base/kdvi
kde-base/kopete
media-gfx/asymptote
media-libs/vflib
media-libs/allegro
media-sound/musescore
net-analyzer/ns
net-analyzer/sonar
net-dialup/mgetty
sci-biology/wise
sci-chemistry/moldy
sci-electronics/gnucap
sci-geosciences/gpsbabel
sci-libs/libcore
sci-libs/pgplot
sci-libs/itpp
sci-mathematics/pari
sci-mathematics/nusmv
sci-misc/gri
sci-physics/jaxodraw
sci-physics/paw
sci-physics/cernlib
sci-physics/cernlib-montecarlo
sci-physics/geant
sci-visualization/pyxplot
sys-block/btrace
sys-cluster/mpich2
sys-cluster/charm
sys-power/apcupsd
sys-power/powersave
www-apps/mediawiki
www-servers/boa
x11-plugins/pidgin-latex

(I have not checked in detail, maybe, some of them indeed need tetex).

What do you think?

Andrey
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] LaTeX documentation

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

Hi,

> There are two methods commonly used to fight against this situation
> in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The
> second method is, probably, better.

Packages should definitely go for the VARTEXFONTS one as I'll probably
drop forced global writable /var/cache/fonts at some point in the
texmf-update script (not that its a security issue but I really dont
like having it like that); if its not world writable and a package
needs to build some fonts and isn't run as root (default nowadays?) the
addwrite will not allow it to write there afaik and it will fail.
Nice you have such a list, please assign a bug to tex@g.o for that and
I'll see what I can do to convert them (perhaps adding the maintainers
in case they want to know what's up and are willing to help).
See:
https://bugs.gentoo.org/show_bug.cgi?id=204433
http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/bf2e58fe200c0676/b72be3596cd2eb31


> Most disturbingly, there are a number of packages which (probably)
> run latex and do neither addwrite nor VARTEXFONTS. An incomplete list
> of such suspect packages is (for now, I only considered packages not
> directly related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive
> and not TeX/LaTeX packages in app-text):
[...]
> These are (potentially) bombs waiting to blow up an unsuspecting
> user. They should be carefully checked.

Yeah or maybe they dont need any unusual fonts; its probably sane to
set VARTEXFONTS regardless. Probably it'd be worth adding a latex
eclass that would just contain:
VARTEXFONTS=${T}/fonts
and inherit it from any package calling latex to avoid code duplication
(like e.g. the mono eclass do).
What do you think ?


> By the way, while investigating this question, I found quite a few 
> packages which still depend on virtual/tetex, while, probably, 
> virtual/latex-base would be better 

Yep, it would be cool to kill virtual/tetex because it does not make
much sense nowadays. Some might be false positives but please also file
a bug for tex@g.o with that list and cc the maintainers to see what can
be done.


Regards,

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] LaTeX documentation

[Denis Dupeyron]

On Tue, May 13, 2008 at 12:31 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>  Yeah or maybe they dont need any unusual fonts; its probably sane to
>  set VARTEXFONTS regardless. Probably it'd be worth adding a latex
>  eclass that would just contain:
>  VARTEXFONTS=${T}/fonts
>  and inherit it from any package calling latex to avoid code duplication
>  (like e.g. the mono eclass do).
>  What do you think ?

As long as we can't easily remove eclasses I'd rather we don't make a
new one for such trivial needs. Unless I've missed something and they
can easily be removed nowadays.

Also, overloading the environment with global variables should be
avoided when possible. In that case I'd recommend the VARTEXFONTS
variable be passed with the emake command or whatever needs latex in
the ebuild.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] LaTeX documentation

[Andrey Grozin]

Alexis Ballier wrote:
> > These are (potentially) bombs waiting to blow up an unsuspecting
> > user. They should be carefully checked.
> Yeah or maybe they dont need any unusual fonts; its probably sane to
> set VARTEXFONTS regardless.
If LaTeX has been never used on this particular computer (just installed 
as a dependency), even cmr10 will lead to sandbox violation.

Andrey
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] LaTeX documentation

[Ulrich Mueller]

>>>>> On Mon, 12 May 2008, Andrey Grozin wrote:

> There are two methods commonly used to fight against this situation
> in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The
> second method is, probably, better.

Why? This would mean that all fonts must be regenerated each time the
package is built. And it doesn't even help if they are already present
in /var/cache/fonts, since the directory is then also ignored for
reading.

And Metafont can be quite expensive in computing time. That's why
there is a font cache, in the first place. ;-)

Ulrich
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] LaTeX documentation

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Mon, May 12, 2008 at 09:23:29PM +0000, Andrey Grozin wrote:
[...] 
> Most disturbingly, there are a number of packages which (probably) run 
> latex and do neither addwrite nor VARTEXFONTS. An incomplete list of such 
> suspect packages is (for now, I only considered packages not directly 
> related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive and not 
> TeX/LaTeX packages in app-text):
[...]
> media-gfx/sane-backends
[...] 
> What do you think?

sane-backends had font generation disabled, but I changed it to the
VARTEXFONTS method for now. Wouldn't it be better to populate this
temporary directory with links to existing cached fonts or something like
this? I don't know much about latex internals, but computing the fonts
always because one _might_ be written sounds like a bad idea.

Bye, Patrick

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] LaTeX documentation

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Tue, 13 May 2008 16:57:02 +0200
Patrick Kursawe <phosphan@gentoo.org> wrote:

> On Mon, May 12, 2008 at 09:23:29PM +0000, Andrey Grozin wrote:
> [...] 
> > Most disturbingly, there are a number of packages which (probably)
> > run latex and do neither addwrite nor VARTEXFONTS. An incomplete
> > list of such suspect packages is (for now, I only considered
> > packages not directly related to TeX/LaTeX, i.e., not in dev-tex or
> > dev-texlive and not TeX/LaTeX packages in app-text):
> [...]
> > media-gfx/sane-backends
> [...] 
> > What do you think?
> 
> sane-backends had font generation disabled, but I changed it to the
> VARTEXFONTS method for now. Wouldn't it be better to populate this
> temporary directory with links to existing cached fonts or something
> like this? I don't know much about latex internals, but computing the
> fonts always because one _might_ be written sounds like a bad idea.

Normally VARTEXFONTS is for writting fonts one needs to generate;
however, with the usual default configurations files I've seen,
overriding it will make the various apps needing 'em not see the
default font cache directory. I've committed a new tl-core ebuild with
default configuration files that will let it see the old font cache
directory even if VARTEXFONTS is changed, but will of course write to
VARTEXFONTS.
This should be what you were asking for ;)

Regards,

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] LaTeX documentation

[Alexis Ballier]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Tue, 13 May 2008 14:20:31 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Mon, 12 May 2008, Andrey Grozin wrote:
> 
> > There are two methods commonly used to fight against this situation
> > in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The
> > second method is, probably, better.
> 
> Why? This would mean that all fonts must be regenerated each time the
> package is built. And it doesn't even help if they are already present
> in /var/cache/fonts, since the directory is then also ignored for
> reading.


Per my other mail its a non issue now ;)

However, if an ebuild needs some fonts not in the font cache or the
texmf tree(s) it'll generate it in VARTEXFONTS, and since they're not
merged into the filesystem, it will do that each time the package is
built.

My opinion is that it is not so important because merging them will
cause headaches:
- How to detect when some fonts have been generated ?
- Should we merge them in src_install so that it's in the package
contents ? it'll get removed when the package is gone
- In some pkg_ functions so that it doesnt get removed; is this safe
for binpkgs ? that'll leave stray files, but that's more or less the
point of doing it like that.
- Where should we merge them ? hardcoding /var/cache/fonts is a no-no
as, even if for now it's forced to be there by texmf-update, it would
be a good idea not to do so and allow people to change the location. We
can ask for the value with kpsewhich; but is that a good idea to install
files in locations based on user defined config files ?

Regards,

Alexis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]