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:
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):
(*) 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:
(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
05-12-2008, 10:31 PM
Alexis Ballier
LaTeX documentation
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.
05-13-2008, 08:20 AM
"Denis Dupeyron"
LaTeX documentation
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
05-13-2008, 11:26 AM
Andrey Grozin
LaTeX documentation
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
05-13-2008, 12:20 PM
Ulrich Mueller
LaTeX documentation
>>>>> 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
05-13-2008, 02:57 PM
Patrick Kursawe
LaTeX documentation
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
05-13-2008, 05:20 PM
Ali Polatel
LaTeX documentation
Andrey Grozin yazmış:
> Hello *,
>
Hey
> 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:
>
> dev-python/python-xlib
> dev-python/pyx
Both set VARTEXFONTS="${T}"/fonts now.
>
> What do you think?
I think you should relax and smoke some weed :P
>
> Andrey
--
Regards,
Ali Polatel
05-13-2008, 09:27 PM
Alexis Ballier
LaTeX documentation
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.
05-13-2008, 09:38 PM
Alexis Ballier
LaTeX documentation
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.
05-13-2008, 11:08 PM
LaTeX documentation
Alexis Ballier <aballier@gentoo.org> writes:
> - 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.
Cache being cache, I'd say that it should be done in the ebuilds
installing the fonts in pkg_* functions. I'd say not in src_* because
packaging up the cache is not what one wants in almost all cases, you
wouldn't want a buggy TeX version creating broken packages when you can
avoid that.
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
LaTeX documentation
