Bug#340890: feynmf: FTBFS: fmtutil: format `mpost' not available
On Sat, Nov 26, 2005 at 19:20 +0100, Roland Stigge wrote: Package: feynmf Version: 1.08-1 Severity: serious Hi, building the package feynmf in a clean sid build environment (with pbuilder) on i386 results in: [...] mpost fmfsamp1; mpost fmfsamp2; mpost fmfsamp3; mpost fmfsamp4; This is MetaPost, Version 0.641 (Web2C 7.5.4) kpathsea: Running mktexfmt mpost.mem fmtutil: format `mpost' not available. Looks like feynmf misses a build dependency on tetex-extra. For creation of the mpost format, the MetaPost base files like mpost.mp from tetex-extra are needed. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340990: gnat-glade-doc: FTBFS: etex error
On Sun, Nov 27, 2005 at 17:22 +0100, Roland Stigge wrote: /tmp/t2d19264/src/glade_ug.texi:373: Undefined control sequence. argument @pdfimage xe-arch.fig.pdf [...] Output written on glade_ug.dvi (11 pages, 18936 bytes). Transcript written on glade_ug.log. /usr/bin/texi2dvi: etex exited with bad status, quitting. texi2dvi looking for a pdf file. That looks like an incorrect check for pdfTeX. See scetion 4.6 'pdfetex: the new default TEX engine' of TETEXDOC (call 'texdoc TETEXDOC' to read it). This check might be in glade_ug.texi. Or gnat-glade-doc ships an outdated version of texinfo.tex. Including texinfo.tex is not necessary, since the texinfo package provides an uptodate version of that file. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341827: tetex-bin chokes on install while running fmtutil-sys
On Sat, Dec 03, 2005 at 05:02 -0800, Arias Hung wrote: This is a summary of all `failed' messages and warnings: `pdfetex -ini -jobname=latex -progname=latex -translate-file=cp227.tcx *latex.ini' failed `pdfetex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini' failed `pdfetex -ini -jobname=pdftex -progname=pdftex -translate-file=cp227.tcx *pdftex.ini' failed `pdfetex -ini -jobname=pdflatex -progname=pdflatex -translate-file=cp227.tcx *pdflatex.ini' failed `pdfetex -ini -jobname=pdfetex -progname=pdfetex -translate-file=cp227.tcx *pdfetex.ini' failed `pdfetex -ini -jobname=amstex -progname=amstex -translate-file=cp227.tcx *amstex.ini' failed fmtutil failed. Output has been stored in /tmp/tetex.postinst.XXXEf82J Please include this file if you report a bug. Please send us the file /tmp/tetex.postinst.XXXEf82J. This is necessary for debugging. Thanks. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345604: ConTeXt documentation is non-free
On Mon, Jan 02, 2006 at 07:27 +0100, Florian Weimer wrote: Package: tetex-doc Version: 3.0-11 Severity: serious The license is clearly non-free: | All rights reserved. No part of this publication may be reproduced, | stored in a retrieval system, or transmitted in any form or by any | means, electronic, mechanical, photocopying, recording or otherwise, | without prior written permission of the publisher. (from /usr/share/doc/texmf/context/manual/cont-eni.pdf.gz) This sounds bad, indeed. However, I think that the ConTeXt manual is actually covered by the general ConTeXt license in /usr/share/doc/texmf/context/base/mreadme.pdf.gz and /usr/share/doc/texmf/context/base/LICENSE.teTeX, which is free. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345637: fmtutil: xmltex fails leaving tetex-bin unconfigured
Norbert Preining wrote: On Don, 12 Jan 2006, Vincent Lefevre wrote: On 2006-01-02 14:01:17 +0100, Michael Eyrich wrote: Package: tetex-bin Version: 3.0-13 Severity: important fmtutil fails to generate format file: fmtutil: running `tex -ini -jobname=xmltex -progname=xmltex latex xmltex.ini' ... This shold not happen anymore with xmltex 1.9-11.1. Did you two accept the upgrade of config files? Please send us the contents of /etc/texmf/fmt.d/*xmltex* (of all the files with xmltex in the name) The same request for Harald wrt to #346135. These two bugs look like duplicates to me. BTW, did anybody see the original messages for #346135 and #345637 on the mailing list? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337084: tetex-base: latex/dvips/ps2pdf produces buggy pdf files
On Thu, Nov 03, 2005 at 00:00 -0200, Rogério Brito wrote: [...] * use of packages like pxfonts, txfonts, mathpazo or mathptmx. The pxfonts and txfonts have the disadvantage of being extremly tight. In some situations, letters can even touch each other. The good thing of using txfonts is that Base 14 fonts aren't usually included in the final file and, thus, the PDF ends up having a much smaller size, but this may present some problems for some people. Actually, Adobe meanwhile reommends to embed the PDF Base 14 fonts. This is reflected in the default configuraton of teTeX 3: ,[ /etc/texmf/updmap.d/00updmap.cfg ] | pdftexDownloadBase14 true | [...] | dvipdfmDownloadBase14 true ` cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337084: tetex-base: latex/dvips/ps2pdf produces buggy pdf files
[full quote to get back to BTS] On Thu, Nov 03, 2005 at 12:50 +0100, Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: Text-extraction from PDF is really complicated. If one adds a few interesting things (fi, ä, ß) to Frank's test file, one finds that pdftotext (best used via 'less pdf-file') that 'fi' is not found at all, 'ä' is found, 'ß' is found as 'ÿ', even when processed with pdflatex. IIRC there is some stage in the text-extraction where some default encoding (Latin-1 or something similar) is used. pdflatex probably includes the Type3 font with an encoding equivalent to T1. Now the code position of 'fi' in T1 is not defined in Latin-1, the code position of 'ß' in T1 is 'ÿ' in Latin-1, the code position of 'ä' is the same in both. So this fits. I guess that ghostscript changes the encoding of the Type3 font when creating the PDF, which makes text extraction rather meaningless. If one uses Type1 fonts, ghostscript is probably able to use a sensible encoding based on the glyphnames in the font. That sounds all very sensible, *but*: On dctt where this first came up (Thread started by Nils), several people said that they could use the find function on pdf files - I assume they read the question properly and used latex/dvips/ps2pdf. I assume, that those people have cm-super installed. If I enable cm-super on my system, text-extraction works fine even for 'fi' and 'ß'. Even if AR 7 is finally able to decently display bitmap fonts, there are still good reasons to use Type1 fonts. cheerio ralf
Bug#334613: tetex-bin: same problem still exists
On Mon, Nov 07, 2005 at 16:35 +0100, Frank Küster wrote: prefer outlines: `true'. texhash enabled: `true'. download standard fonts (dvips): `false'. download standard fonts (pdftex): `false'. download standard fonts (dvipdfm): `false'. [...] ls -ld /usr/share/texmf/fonts/map/dvips # without trailing / ls /usr/share/texmf/fonts/map/dvips/tetex/ kpsewhich --format=map dvips35.map kpsewhich --show-path map One further question, in addition to the ones Frank posted: The 'download standard fonts' settings above are those from teTeX 2. Hence please post the output of ls -l /etc/texmf/updmap.d/ cheerio ralf
Bug#338597: lmodern is unusable with context from the latest teTeX.
Frank Küster wrote: Konstantinos Koukopoulos [EMAIL PROTECTED] wrote: The CONTEXT distribution that is contained in the above tetex packages requires the lmodern fonts in EC encoding. Unfortunately the lmodern package currently in unstable contains the fonts in cork encoding. It is very likely that Konstantinos has a more recent version locally installed. See below. I don't understand - AFAIK EC is the Cork encoding? Also, I cannot reproduce this bug, which might be due to my lack of knowledge of ConTeXt. What EC and Cork encoding is exactly is quite tricky (see discussion on tex-fonts some months ago). However, I think the relevant thing is that the tfm files for lmodern got renamed at some point from 'cork-lmr10.tfm' to 'ec-lmr10.tfm' etc. The current lmodern package is identical to what's in teTeX 3.0, and i am pretty sure that teTeX 3.0 is 'self consistent', ie, the tfm files in teTeX 3.0 are those needed by ConTeXt as it is in teTeX 3.0. This gives us a big problem with the lmodern package. I don't know how we could update lmodern without updating ConTeXt in the teTeX tree. I am pretty sure, that current lmodern will *not work* with the ConTeXt in teTeX 3.0. :-( ConTeXt ver: 2005.10.27 fmt: 2005.10.29 int: english mes: english I have a different ConTeXt version: ConTeXt ver: 2005.01.31 fmt: 2005.10.25 int: english mes: english Actually, the ConTeXt version of Konstantinos is more recent than teTeX 3.0! cheerio ralf
Bug#338597: lmodern is unusable with context from the latest teTeX.
On Fri, Nov 11, 2005 at 15:26 +0100, Ralf Stubner wrote: This gives us a big problem with the lmodern package. I don't know how we could update lmodern without updating ConTeXt in the teTeX tree. I am pretty sure, that current lmodern will *not work* with the ConTeXt in teTeX 3.0. :-( Fortunately I was (almost) wrong here. ConTeXt as it is in teTeX 3.0 still uses the CM fonts as default. If I process the example file provided by Konstantinos with texexec plus dvips, cmsy10.pfb and cmr12.pfb are included. AFAIK more recent versions of ConTeXt use the LM fonts as default. However, if one explicitly selects the LM fonts in ConTeXt as in teTeX 3.0, this probably won't work in conjunction with more recent versions of the LM fonts, simply because ConTeXt will look for cork-lmr10.tfm, which is no longer present. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344790: [Micha Feigin] Re: Bug#344790: hyperref: off by 1 error with pdf bookmarks and tocdepth
On Fri, Dec 30, 2005 at 01:50 +0200, Micha Feigin wrote:
On Wed, 28 Dec 2005 15:34:17 +0100
Frank Küster [EMAIL PROTECTED] wrote:
Well, we still need the output of \listfiles - or maybe just send the
complete logfile as an attachment, it shouldn't be too big.
attached
Thanks. Just as Frank I can't reproduce your problem with the testfile
you provided. Comparing the log files, the main difference I have found
up to now is the version of beamer.cls and related packagges. You are
using sid, which has beamer version 3.06, while I am using sarge (with
teTeX 3 backport), which has beamer version 3.01.
Does this problematic behaviour depend on you using beamer? I am
attaching a simple testfile using the standard article.cls. This files
gives correct behaviour here with both pdflatex and latex+dvips+ps2pdf.
Does it work on your machine?
cheerio
ralf
\listfiles
\documentclass{article}
\setcounter{tocdepth}{1}
\usepackage{hyperref}
\begin{document}
\tableofcontents
\section{section 1}
\subsection{subsection 1}
\end{document}
Bug#344790: [Micha Feigin] Re: Bug#344790: hyperref: off by 1 error with pdf bookmarks and tocdepth
On Sat, Dec 31, 2005 at 01:06 +0200, Micha Feigin wrote: On Fri, 30 Dec 2005 13:14:49 +0100 Ralf Stubner [EMAIL PROTECTED] wrote: Thanks. Just as Frank I can't reproduce your problem with the testfile you provided. Comparing the log files, the main difference I have found up to now is the version of beamer.cls and related packagges. You are using sid, which has beamer version 3.06, while I am using sarge (with teTeX 3 backport), which has beamer version 3.01. Does this problematic behaviour depend on you using beamer? I am attaching a simple testfile using the standard article.cls. This files gives correct behaviour here with both pdflatex and latex+dvips+ps2pdf. Does it work on your machine? It does seem to be dependent on beamer apparently. With the attached file the bookmarks and table of contents are in sync. Thanks for the info. In that case it might be that this is a bug in beamer, not in hyperref. Currently I don't have steady internet access, so I can't promise when I will be able to look into this issue. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329189: tetex-base: dvips -Poutline not using .pfb fonts
On Mon, Oct 03, 2005 at 23:13 +0200, Arne Ahrend wrote: On Tue, 27 Sep 2005 13:03:42 +0200 Frank Küster [EMAIL PROTECTED] wrote: You don't, by chance, have backups of the old psfonts_t1.map and/or of the updmap log file - either as /var/lib/texmf/web2c/updmap.log, or /tmp/updm*? If you have some of these, please send them - but only the old ones that produced a buggy psfonts_t1.map is of any use. I could not find any such log file and did not keep the original map file. However, I am able to reproduce the problem by completely removing tetex-base, tetex-bin and tetex-extra and reinstalling them. Running of updmap is being reported during the installation, but the resulting /var/lib/texmf/dvips/config/psfonts_t1.map appears to match the one I had prior to reporting this issue. I am not sure if this helps debugging, but the fonts that where initially missing from psfonts_t1.map are the ones from bsr.map, bsr-interpolated.map, omega.map, xypic.map and eurosym.map. This are the map files (and fonts) provided by tetex-extra. I would expect updmap to be called twice. Once during tetex-base configuration and once during tetex-extra configuration. This sounds as if update-updmap was executed during tetex-extra configuration, but not updmap itself. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331667: tetex-bin: pdflatex - Error when creating pdf from doxygen's latex: File `fancyhdr.sty' not found.
Hilmar Preusse wrote:
On 04.10.05 Andrei Emeltchenko ([EMAIL PROTECTED])
wrote:
pdflatex refman.tex This is pdfeTeX, Version 3.14159-1.10b-2.1
(Web2C 7.4.5) entering extended mode
(./refman.tex{/usr/share/texmf/pdftex/config/pdftex.cfg} LaTeX2e
2001/06/01 Babel v3.7h and hyphenation patterns
snip
(/usr/share/texmf/tex/latex/base/book.cls Document Class: book
2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/bk10.clo))
(/usr/share/texmf/tex/latex/base/makeidx.sty)
! LaTeX Error: File `fancyhdr.sty' not found.
Type X to quit or RETURN to proceed, or enter new name. (Default
extension: sty)
Enter file name:
http://packages.debian.org/cgi-bin/search_contents.pl?word=fancyhdr.stysearchmode=searchfilescase=sensitiveversion=stable
That file is in tetex-extra. If this is an FTBFS the package, failing
to build, declares insufficient BDs.
If refman.tex is doxygen's documentation as the bug title suggest, then
even this is not the case. According to
http://packages.debian.org/stable/source/doxygen
doxygen build-deppends on tetex-extra.
cheerio
ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302035: Splitting the teTeX packages
On Wed, Oct 05, 2005 at 12:39 +0200, Frank Küster wrote: Sending this mail to the bug for proper archiving. Thanks, I constantly forget this ... And /usr/share/texmf/tex/latex/dvipdfm/dvipdfm.def looks like a part of graphics ... I don't think so: %% This is file `dvipdfm.def', %% and was *not* generated with the docstrip utility. %% %% It was hand edited from several docstripped def %% files that are distributed with the Graphics Bundle This looks to me as if it was derived from the graphics bundle, but is not part of it. Indeed. This is an interesting case. The graphics bundle contains a dvipdfm.def (CTAN:/macros/latex/required/graphics/dvipdfm.def), but that one is not present in teTeX! The one in TEXMF/tex/latex/dvipdfm/ seems to come from the dvipdfm sources. This seems to be a change with respect to teTeX 2. Looks like a borderline case to me ... cheerio ralf
Bug#332397: tetex-bin: manpage for a2ping missing
On Thu, Oct 06, 2005 at 10:26 +0200, Frank Küster wrote: Usage: a2ping.pl [options] inputfile [[outformat:] outputfile] Run with --doc to read documentation as a UNIX man(1) page. This works, so there must be some internal manpage representation in the sources. $ pod2man /usr/bin/a2ping a2ping.1 gives a usable manpage. What is the place for manpages that are not supplied from upstream? The new-manpages/ directory? cheerio ralf
Bug#329189: tetex-base: dvips -Poutline not using .pfb fonts
On Wed, Oct 05, 2005 at 19:01 +0200, Arne Ahrend wrote: Here is tetex-extra-apt.log === Reading Package Lists... Building Dependency Tree... The following NEW packages will be installed: tetex-extra 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/10.5MB of archives. After unpacking 40.1MB of additional disk space will be used. Selecting previously deselected package tetex-extra. (Reading database ... 57352 files and directories currently installed.) Unpacking tetex-extra (from .../tetex-extra_2.0.2c-8_all.deb) ... Setting up tetex-extra (2.0.2c-8) ... Creating config file /etc/texmf/dvips/config.ams with new version Creating config file /etc/texmf/dvips/config.cm with new version Creating config file /etc/texmf/dvips/config.amz with new version Creating config file /etc/texmf/dvips/config.cmz with new version Running initex. This may take some time. ... Running updmap. This may take some time. ... using config file /var/lib/texmf/web2c/updmap.cfg using output directory /var/lib/texmf/dvips/config Scanning for LW35 support files Scanning for MixedMap entries: Scanning for Map entries: Files generated in /var/lib/texmf/dvips/config: I don't know the postinst scripts of the teTeX 2 packages all that well, but I am wondering why there is no indication of update-updmap actually running. Although update-updmap must have run at some point, otherwise a manual updmap wouldn't have produced a correct map file. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332397: tetex-bin: manpage for a2ping missing
Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: On Thu, Oct 06, 2005 at 10:26 +0200, Frank Küster wrote: Usage: a2ping.pl [options] inputfile [[outformat:] outputfile] Run with --doc to read documentation as a UNIX man(1) page. This works, so there must be some internal manpage representation in the sources. $ pod2man /usr/bin/a2ping a2ping.1 gives a usable manpage. What is the place for manpages that are not supplied from upstream? The new-manpages/ directory? Exactly. Ok, I will add it there and chack this in later. BTW, it looks as if most/all manpages in new-manpages/ are meanwhile in texk/tetex/ and taken from there. I guess the versions in new-manpages/ can be deleted. Should I add sam2p to Suggests (#332301)? cheerio ralf
Bug#332397: tetex-bin: manpage for a2ping missing
On Thu, Oct 06, 2005 at 16:36 +0200, Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: Ok, I will add it there and chack this in later. BTW, it looks as if most/all manpages in new-manpages/ are meanwhile in texk/tetex/ and taken from there. I guess the versions in new-manpages/ can be deleted. Yes, all of them (except tetex-xwarn of course), I checked it. But please take care that the files in the original sources are actually installed. I didn't find a manpage for updmap.cfg, so I left that in, too. In my testbuild, which also revealed a stupid tab vs spaces error of mine, it worked correctly. Actually I think the manpages in texk/tetex/ are already used as, eg, ovp2ovf(1) contains [EMAIL PROTECTED] and not [EMAIL PROTECTED]. Should I add sam2p to Suggests (#332301)? That would be nice, thanks. Revision 207. cheerio ralf
Bug#332673: TeX is unable to find cm-super-t2a.enc file
On Sat, Oct 08, 2005 at 19:15 +0400, Victor Wagner wrote: On 2005.10.08 at 15:28:39 +0200, Norbert Preining wrote: * add some hacks for tetex 2 May be just add a file into source package, like README.TeTeX-2.0 as hint for backporters. It seems that we, who use stable with few backports from unstable have no reason to upgrade to teTeX-3.0 until etch is released. Trying to support teTeX 2 directly in the package is probably not worth it. People you use sarge (like myself) but want to work seriously with (La)TeX ought to consider using the teTeX 3 backports from deb http://people.debian.org/~frank/teTeX-3.0/ sarge main They work very well for me, and it is one of the very few backports I am using. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327480: Please separate the .pfb files of Type1 fonts and make them available to X11
On Mon, Oct 10, 2005 at 14:11 +0200, Hilmar Preusse wrote: On 10.09.05 Hilmar Preusse ([EMAIL PROTECTED]) wrote: Last Remark, TODO: Do we have to provide the Adobe Font metrics of the fonts? If yes the packages providing the sym links has to contain the afm files too, which are not contained in the tar balls provided by teTeX. I am not sure if one /has/ to provide them, but it would definitly be good to do so. BTW, which fonts have no afm files? Right now only the bluesky fonts come to my mind. However, I don't think that it makes sense to make these available to X11. I would be really surprised if any application besides TeX could make proper use of OT1 or OML encoded fonts. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335303: tetex-bin: failed to install: updmap error
On Sun, Oct 23, 2005 at 11:33 +0200, Sebastien Helleu wrote: Package: tetex-bin Version: 3.0-10.1 Severity: grave Justification: renders package unusable Thanks for reporting. From which version did you upgrade? download standard fonts (dvips): `false' download standard fonts (pdftex): `false' download standard fonts (dvipdfm): `false' Interesting, current tetex has 'true' for the last two options. What is the output of 'ls /etc/texmf/updmap.d/'? Did you (maybe automatically) decline some offered updates of configuration files? updmap-sys: Scanning for LW35 support files !!! ERROR: The right location for map files has been changed for this release and the map file `dvips35.map' has not been found in the right location, but in the obsolete location /usr/share/texmf/dvips/config/dvips35.map instead. To fix this, please move this file into an appropriate subdirectory of fonts/map in one of your texmf trees. If the file has been installed by a Debian package, please do not move it. Instead, please report a bug against that package, and send a copy of that bug to debian-tetex-maint@lists.debian.org For more information about the changed search paths, see the release notes section in the teTeX manual. You probably can read this document by executing the command texdoc TETEXDOC else visit the web page http://tug.org/texlive/mapenc.html This looks like a variant of #335210. Does that link $ ls -ld /usr/share/texmf/fonts/map/dvips lrwxrwxrwx 1 root root 20 2005-10-20 18:59 /usr/share/texmf/fonts/map/dvips - /etc/texmf/map/dvips exist on your system? If /usr/share/texmf/fonts/map/dvips is a directory, what's its content? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335303: tetex-bin: failed to install: updmap error
On Sun, Oct 23, 2005 at 13:45 +0200, Sebastien Helleu wrote: On Sun, Oct 23, 2005 at 12:12:51PM +0200, Ralf Stubner wrote: Thanks for reporting. From which version did you upgrade? I think from 3.0-10. Where there any problems with version 3.0-10? What is the output of 'ls /etc/texmf/updmap.d/'? Did you (maybe automatically) decline some offered updates of configuration files? $ ls -l /etc/texmf/updmap.d/ total 16 -rw--- 1 root root 2789 2005-10-22 18:11 00updmap.cfg -rw-r--r-- 1 root root 2787 2005-10-22 18:17 00updmap.cfg.dpkg-dist -rw-r--r-- 1 root root 2623 2005-10-19 16:10 10tetex-base.cfg -rw-r--r-- 1 root root 1314 2005-10-19 16:11 20tetex-extra.cfg.dpkg-new If I answered to some questions about files update, I think I answered yes (to overwrite), but not sure. Hmm, what's the difference between /etc/texmf/updmap.d/00updmap.cfg and /etc/texmf/updmap.d/00updmap.cfg.dpkg-dist? This looks like a variant of #335210. Does that link $ ls -ld /usr/share/texmf/fonts/map/dvips lrwxrwxrwx 1 root root 20 2005-10-20 18:59 /usr/share/texmf/fonts/map/dvips - /etc/texmf/map/dvips exist on your system? Yes this link exists. On Sun, Oct 23, 2005 at 13:49 +0200, Sebastien Helleu wrote: $ dpkg -S dvips35.map tetex-base: /etc/texmf/map/dvips/tetex/dvips35.map [...] $ dpkg -S pdftex35.map tetex-base: /etc/texmf/map/dvips/tetex/pdftex35.map [...] $ ls -l /usr/share/texmf/fonts/map total 4 lrwxr-xr-x 1 root root 22 2005-10-22 18:08 dvipdfm - /etc/texmf/map/dvipdfm lrwxr-xr-x 1 root root 20 2005-10-22 18:08 dvips - /etc/texmf/map/dvips drwxr-xr-x 2 root root 4096 2005-10-22 18:08 fontname lrwxr-xr-x 1 root root 21 2005-10-22 18:08 pdftex - /etc/texmf/map/pdftex Ok, all that looks correct. Maybe the search path for mapfiles is incorrect. What's the output of 'ls -l /etc/texmf/texmf.d' and 'grep TEXFONTMAPS /etc/texmf/texmf.cnf'? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335303: tetex-bin: failed to install: updmap error
On Sun, Oct 23, 2005 at 14:17 +0200, Florent Rougon wrote: Good. Presumably, the problem was located (only) in /etc/texmf/updmap.d/ as suspected by Ralf. Actually, I suspect that there is a similar situation in /etc/texmf/texmf.d/, ie, some configuration files from teTeX 2 are still used. This could cause a wrong search path for mapfiles. What I am wondering is why this problem didn't occur during the original 2.0.2 - 3.0 update. Also, why are dvips35.map and pdftex35.map still available in /etx/texmf/dvips? I thought these files are moved somehwere save on instalation. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100332: New package splitting scheme for teTeX in Debian
On Fri, Oct 21, 2005 at 16:28 +0200, Frank Küster wrote: regarding tetex-bin a) #78926: If possible, it'd be nice if dvips were a seperate package, so that users of printfilters, e.g., don't need tetex-bin installed. [is this really a realistic scenario? How many systems are there that print dvi, but don't produce it?] This might happen on a dedicated print server. However, dvips alone won't be of much use. One would also need fonts, metrics etc and the infrastructure for finding them. Under such circumstances, the overhead of other binaries from tetex-bin becomed negligible IMO (at least for tetex-bin-nox). I expect that teTeX will continue to be the standard package for creating documentation when building a Debian package, and I think that we should try to develop our splitting schemes mainly along the needs of this application. End users will probably just install everything, or switch to tex-live. I think we should already think about the coexistance with TeX Live. I don't know if there are many TeX Live packages that don't include files that are also in teTeX. And how to be sure that the dependencies speciefied by some TeX Live package are fulfilled by the teTeX packages installed? [...] * minimal scheme ^^ tetex-bin is split into tetex-bin-nox and tetex-bin-x11; tetex-bin continues to exist as a dummy package. Besides sorting files with dh_* and writing the necessary control information, the only thing we have to do is connected to mf: we probably need to set up an alternatives system for mf-nowin and mfw. Sounds reasonable to me. For tetex-base, the additional splitting-off of a type1-fonts-x11 package can be added to both following splitting schemes: * minimal scheme ^^^ Just move PSNFSS and the Bluesky fonts to tetex-base (e and d, #324868, #302035) and be done. The MF sources of the EC fonts are also necessary. But all this would increase the already to large tetex-base. I think we need the * advanced scheme ^^^ Alternatively, we could create a tetex-base that is in fact a latex-base: As Ralf has pointed out, tex/latex has a size of 16Mbyte, while 94Mbyte of the total of 135 Mbyte (without doc) are in the fonts directory. Therefore it seems that it doesn't help much to figure out which LaTeX packages are needed in this new base package. Instead, we include in it - the complete tex/latex directory, Actually some directories with font support should go to tetex-extra (lucidabr, txfonts, pxfonts, ...). If one has to split tex/latex anyway, one might also move some large packages that probably aren't used as build-dependence. Incomplete list with decreasing size: custom-bib, koma-script, minitoc, jurabib, memoir, ntgclass ... - everything else that is needed to run LaTeX and plain TeX. (at least that's what the policy says IIRC) - input files for makeindex and bibtex. I'm not sure about all those bst files. I would say bibtex/bst/base and maybe bibtex/bst/ams (I am not sure if those are also a 'required' part of LaTeX) should be in tetex-base. The rest might go to tetex-extra. The difficult part is to keep things together that belong together, like bibtex/bst/revtex4 and tex/latex/revtex4. - PSNFSS fonts, the CM and EC fonts in Metafont and Type1 format, if available. To what extend do we want internationlization? Should people be able to produce documentation in Russian, Greek or Vietnamese with tetex-base alone? In case we end up implementing the advanced scheme for both source packages, we also need to think about dependencies - I think in this case tetex-bin-extra should *depend* on tetex-extra, so that people won't end up with texexec but no context input files, and similar situations. ACK Maybe we should also rename tetex-base (e.g. to tetex-latexbase), but on the other hand I don't expect that many packages that depend on tetex-base only would stop working; the harder part would be to convince package maintainers to drop the tetex-extra dependency. Maybe it would beintersting to get maintainers of (build-)depending packages involved. We aim at making tetex-extra unnecessary as build dependence. Therefore, the maintainers of (build-)depending packages could tell us what they are actually using from tetex-base and tetex-extra. If you like, we can start coding at once, using a branch in the svn repository. Unfortunately I won't have much time in the next 1½ months. :-( cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100332: New package splitting scheme for teTeX in Debian
On Mon, Oct 24, 2005 at 17:27 +0200, Frank Küster wrote: Julian Gilbey [EMAIL PROTECTED] wrote: On Fri, Oct 21, 2005 at 04:28:25PM +0200, Frank K??ster wrote: * advanced scheme ^^^ Additionally, tetex-bin-nox is split into tetex-bin-mini and tetex-bin-extra (or similar), where tetex-bin-mini contains only pdfetex, mf-nowin and dvips plus the needed scripts/binaries smaller than 100K. This would require more work, because finding out which small programs are needed isn't trivial. I agree with this in principle, but not using a size criterion. Rather, those binaries which depend on something in tetex-extra (eg aleph, omega, whatever we put there) should move to tetex-bin-extra and those which don't can stay in tetex-bin. That was also my intention. I used the size just as an additional reason to split like this; but the main point is that in order to produce DVI or PDF from LaTeX sources, you only need pdfetex, mf-nowin and dvips (plus all the helper scripts). The difficulty is how to identify the programs that are not all that necessary. One could start with a 'opt-out' list, though: tetex-bin-x11: xdvi mf(w) tetex-bin-extra: omega, aleph, omfonts, odvicopy, odvitype, otangle, otp2ocp, outocp (Omega) mpost, mpto, makempx (MetaPost) texexec (ConTeXt) pltotf, tftopl, vftovp, vptovf (TFM/VF conversion) ... cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100332: New package splitting scheme for teTeX in Debian
Some additions On Mon, Oct 24, 2005 at 20:40 +0200, Ralf Stubner wrote: tetex-bin-extra: omega, aleph, omfonts, odvicopy, odvitype, otangle, otp2ocp, outocp (Omega) mkocp (Omega) mpost, mpto, makempx (MetaPost) dmp dvitomp (MetaPost) texexec (ConTeXt) pltotf, tftopl, vftovp, vptovf (TFM/VF conversion) texdoctk (get rid of perl/tk in tetex-bin-core) dvipdfm ebb (unsure about those) cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302035: Bug#100332: New package splitting scheme for teTeX in Debian
On Mon, Oct 24, 2005 at 20:28 +0200, Ralf Stubner wrote: On Fri, Oct 21, 2005 at 16:28 +0200, Frank Küster wrote: - PSNFSS fonts, the CM and EC fonts in Metafont and Type1 format, if available. To what extend do we want internationlization? Should people be able to produce documentation in Russian, Greek or Vietnamese with tetex-base alone? I probably should have added that cyrillic support is in principle a required part of LaTeX. Similar for babel. Whether or not this also means Cyrillic and Greek fonts is not easy. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335500: marked as forwarded (missing keywords in listing for octave)
On Tue, Oct 25, 2005 at 06:33 -0700, Debian Bug Tracking System wrote: To: Carsten Heinz [EMAIL PROTECTED] Just a reminder. In the last few days there has been a discussion on comp.text.tex about Carsten Heinz being MIA. Several people have unsuccessfully tried to reach him. It might be, that somebody else might start maintaining his packages. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100332: New package splitting scheme for teTeX in Debian
On Tue, Oct 25, 2005 at 19:51 +0200, Frank Küster wrote: Do you think it should be possible to have combinations like tetex-bin, tetex-base plus ConTeXt from texlive? Would be nice, but not strictly necessary. Or do you think that someone will want tetex-extra on top of some parts of texlive? Unlikely. As far as I can see it, the only coexistence that we should really try to make possible is that one can install fonts or LaTeX packages from texlive if they do not exist in tetex at all. ACK And this won't depend on our splitting scheme, AFAICS. Obviously, I am not sure about this. Let's say I want to install the 'bera' fonts from TeX Live, since they are not in teTeX. AFAIK I would have to install the 'texlive-fontsextra' package for this. Looking at the tpm-file for this collection, I see several fonts that are both in texlive-fontsextra and in (future) tetex-extra: antt, bbm, bbold, belleek, cmbright, doublestroke, eulervm, fpl, rsfs (the latter two should be in tetex-base since they are part of PSNFSS) and sauter. I might have overlooked some. Similar for texlive-latexextra which contains many interesting things but also, eg, beton, ccaption, currvita, dinbrief, dk-bib, enumitem, soul, ... all of which are also in tetex. I am sure I have missed quite a few. I could imagine to put nothing from texlive-fontsextra and texlive-latexextra into tetex-base (fpl and rsfs are tricky then). In that case, those two packages could be installed /instead/ of tetex-extra. But installing instead of tetex-extra is not a good solution since there are many more things in there. I don't know if their is a good solution to install these packages in addition to tetex-extra. At least if we don't want to introduce separate TEXMF trees and live with a slight duplication of files. If one has to split tex/latex anyway, one might also move some large packages that probably aren't used as build-dependence. Incomplete list with decreasing size: custom-bib, koma-script, minitoc, jurabib, memoir, ntgclass ... If someone finds time to sort that out, this would be worth trying. In principle, this is soemthing that I would be willing to do. But I won't have much time in the near future . cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335550: Problems with jadetex (and the list)
Hi Paul, thanks for reporting this problem. For whatever reason it didn't reach our mailing list. I only saw it right now in the web interface. We had that recently with another bugreport. Maybe these messages are simply to large for the mailing list software? Anyway, concerning your bug report. You get the error message: This is a summary of all `failed' messages and warnings: `tex -ini -jobname=jadetex -progname=jadetex latex jadetex.ini' failed The error message from tetex.postinst.XXhnN5lJ is: This is TeX, Version 3.141592 (Web2C 7.5.4) (INITEX) ---! /var/lib/texmf/web2c/latex.fmt was written by pdfetex (Fatal format file error; I'm stymied) Here it is tried to build the jadetex format with the TeX engine. Problem is, that it uses the LaTeX format, which was build with the pdfetex engine. What files do you have in '/etc/texmf/fmt.d/'? What's the content of '/etc/texmf/fmt.d/40jadetex.cnf'? My guess is, that at some point you refused to update the configuration files for jadetex, because current jadetex packages build all their formats with (pdf)etex. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100332: New package splitting scheme for teTeX in Debian
On Thu, Oct 27, 2005 at 15:56 +0200, Frank Küster wrote: mpost, mpto, makempx /usr/bin/makempy (MetaPost) /usr/bin/mptopdf I would suggest that MetaPost is now regarded as a core component of a modern TeX distribution, so I'd suggest keeping it in the core. Hm, well. So far, I have not looked at tetex-bin-core (and the new tetex-base) as core of a modern TeX distribution, but rather as what is needed in a Build-Depends. From this point of view I doubt that MetaPost has its place in -core. What do others think? I am a regular MetaPost user, but I would vote for it going to tetex-bin-extra. The TEXMF/metapost directory allready is in tetex-extra and should stay there. I don't expect anybody to uses it for a Build-Depends. One could try to find out what all the packages build-depending on tetex-extra actually use, but that would be a lot of work. If MetaPost were to go to tetex-bin-core (and TEXMF/metapost to tetex-base), one has to remember to also include TEXMF/tex/context/base/supp-pdf.tex and TEXMF/tex/context/base/supp-mis.tex in tetex-base, otherwise inclusion of MetaPost images with pdfLaTeX would fail. /usr/bin/gsftopk (probably no longer needed, since xdvik links against libt1) Ditto, although you may be right in your comment. How do we check that? Or do we simply keep everything that *might* be called from mktexpk? That sounds like the savest thing to do. /usr/bin/ps2pk (creates a TeX pkfont from a type1 PostScript font) Ditto. But only (as an alternative to gsftopk) if you change mktex.opt, which isn't a conffile. Should it be? Probably yes. ACK /usr/bin/allcm /usr/bin/allec /usr/bin/allneeded (create many CM/EC pk fonts at once) Why throw away these scripts? In order to keep tetex-bin-core as small as possible. Not because of disk space, but in order to keep it simply. I don't think that any sane mind will call allcm in debian/rules before running latex over their documentation. Am I insane myself? These scripts are useful when one installs a system and does not wnat to wait for font creation when 'in production use'. It would be pointless and counterproductive to call them from debian/rules, since more fonts than necessary would be created. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336019: tetex-base: Install fails for update-language
On Thu, Oct 27, 2005 at 14:42 +0200, Michael Piefel wrote: Package: tetex-base Version: 3.0-10 Severity: normal Fresh install fails in postinst with: update-language: cannot read /etc/texmf/language.d/00tex.cnf However, there is a file called 00tetex.cnf Odd. /etc/texmf/language.d/00tex.cnf is part of tex-common, which is installed on your system: Versions of packages tetex-base depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii tex-common 0.8 Common infrastructure for using an ii ucf 2.003 Update Configuration File: preserv What's the output of 'ls -l /etc/texmf/language.d/'? Do you have dlocate installed? If yes, what's the output of 'dlocate -S /etc/texmf/language.d/'? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334410: tetex-bin: incorrect counter names in info page about itemized lists?
On Tue, Oct 18, 2005 at 09:33 +0200, Frank Küster wrote: Unfortunately, latex.info is unmaintained today, and there is little chance to get the many errors in it fixed. There's a new effort for a LaTeX online documentation, but unfortunately I cannot remember the name. I think you are talking about URL:http://www.miwie.org/tex-refs/index.html. cheerio ralf
Bug#334658: tetex-bin: updmap was run as root
On Wed, Oct 19, 2005 at 07:31 +0200, Jean Charles Delépine wrote: Package: tetex-bin Version: 3.0-9 Severity: normal Thanks for reporting. Got #334613 bug on upgrade. /tmp/tetex.updmap.XXQqSsSl said : [...] !!! ERROR! The map file `lm.map' has not been found at all. Either put this file into the right place or remove the reference from the configuration file. An automatic way to disable unavailable map files is to call updmap-sys --syncwithtrees For manual editing, call updmap-sys --edit I ran updmap-sys --syncwithtrees as requeted and then apt-get -f install, The tetex-bin configuration goes fine but : I wondered why this would help at all. So I used a clean pbuilder and did the following: apt-get update apt-get install tetex-base echo Map lm.map /etc/texmf/updmap.d/10local.cfg apt-get install tetex-bin I get the error message about lm.map not found. updmap-sys --syncwithtrees apt-get -f install did indeed help, although both /etc/texmf/updmap.d/10local.cfg and /var/lib/texmf/web2c/updmap.cfg still contain Map lm.map. However, updmap-sys --syncwithtrees creates a fixed /usr/share/texmf/web2c/updmap.cfg. Normally, this is behind /var/lib/texmf/web2c/updmap.cfg in the search path, but not for updmap-sys, which changes some variables like this: # kpsewhich --format=web2c files updmap.cfg /var/lib/texmf/web2c/updmap.cfg # export TEXMFCONFIG=`kpsewhich -var-value TEXMFSYSCONFIG` # export TEXMFVAR=`kpsewhich -var-value TEXMFSYSVAR` # kpsewhich --format=web2c files updmap.cfg /usr/share/texmf/web2c/updmap.cfg Of course, this does not explain why lm.map is mentioned in your updmap.cfg file without being present on the system. Did you have the lmodern package installed at some time? Warning: updmap was run as root; updmap-sys was used instead. If this was done by a Debian package upon installation, upgrade, or removal, please file a bug against that package. Strange. This doesn't happen here. Do you have the environent variable $SHOW_UID_WARNING set? cheerio ralf
Bug#334650: tetex-bin: fmtutil-sys should unset TEXINPUTS
On Wed, Oct 19, 2005 at 11:34 +0200, Frank Küster wrote: I think we had a very long list of TeX-related environment variables that were all unset in th packages of teTeX-2.0.2. And it seems to me as if it would be good to do this again. People might still have problems running latex or whatever, but at least the package installs cleanly. What do the others think? Sounds like the right thing to do. cheerio ralf
Bug#334658: tetex-bin: updmap was run as root
On Wed, Oct 19, 2005 at 14:01 +0200, Jean Charles Delepine wrote: Florent Rougon [EMAIL PROTECTED] écrivait (wrote) : BUT the lmodern package in sid moves 10lmodern.map out of the way when removed (remember /var/lib/lmodern/?), therefore the map file shouldn't be looked for by updmap-sys. Maybe Jean-Charles installed these fonts manually? I installed these fonts this morning while upgrading tetex. With aptitude. Ok, I can now (almost) reproduce this bug with a clean pbuilder plus 'apt-get install lmodern'. Result: tetex-bin is not configured because of lm.map. After 'updmap-sys --syncwithtrees' and 'apt-get -f install' I indeed get the warning about updmap being run as root (actually twice, as expected), but this is from the postinst of lmodern, not of tetex-bin. I think the problem is that lmodern creates 10lmodern.cfg in preinst. So when tetex-bin is configured, there is no lm.map but only lm.map.dpkg-new. Looks more like an lmodern bug to me. However, the behviour of 'updmap-sys --syncwithtrees' is not correct. Should I make a separate bug for this? Jean-Charles: Do you have a file '/usr/share/texmf/web2c/updmap.cfg'? If yes, please rename it and call 'update-updmap', 'mktexlsr' and 'updmap-sys'. After that I think your system should be ok again. cheerio ralf
Bug#334747: tetex-bin: updmap-sys behaves badly with --synctrees and --edit
Package: tetex-bin Version: 3.0-8.0.sarge1 Severity: normal If one uses updmap-sys with --synctrees or --edit (and possible other options), updmap-sys creates a new updmap.cfg in TEXMFSYSCONFIG/web2c. With Debian, this is /usr/share/texmf/web2c, ie, TEXMFMAIN/web2c. While update-updmap creates updmap.cfg in TEXMFSYSVAR/web2c. With Debian this is /var/lib/texmf/web2c. The default search path is $TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFLOCAL,$TEXMFSYSVAR,$TEXMFMAIN Hence normally the file in TEXMFSYSCONFIG/TEXMFMAIN is shadowed by the file in TEXMFSYSVAR. However, updmap-sys sets TEXMFCONFIG=TEXMFSYSCONFIG (=TEXMFMAIN on Debian) TEXMFVAR=TEXMFSYSVAR Effectively TEXMFMAIN comes before TEXMFSYSVAR for updmap-sys. This is bad and difficult to debug, since kpsewhich would still list the file in TEXMFSYSVAR/web2c. The ideal solution would probably be if we were able to use a real, separate TEXMFSYSCONFIG (=/etc/texmf?). For the time being it /might/ work to set TEXMFSYSCONFIG=TEXMFVAR (with appropriate symlinks), but I am not sure. An other solution might be to disable all dangerous options of updmap(-sys). I am not sure if it is possible to use the things from 'debianize-updmap' here. texconfig-sys and fmtutil-sys might cause similar problems. cheerio ralf -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.10-thinkpad Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages tetex-bin depends on: ii debconf [debconf-2 1.4.38Debian configuration management sy ii debianutils2.10.2Miscellaneous utilities specific t ii dpkg 1.10.28 Package maintenance system for Deb ii ed 0.2-20The classic unix line editor ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgcc11:3.4.3-13GCC support library ii libice64.3.0.dfsg.1-14sarge1 Inter-Client Exchange library ii libkpathsea4 3.0-8.0.sarge1path search library for teTeX (run ii libpaper1 1.1.14-3 Library for handling paper charact ii libpng12-0 1.2.8rel-1PNG library - runtime ii libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libt1-55.0.2-3 Type 1 font rasterizer library - r ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii libxaw74.3.0.dfsg.1-14sarge1 X Athena widget set library ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte ii libxmu64.3.0.dfsg.1-14sarge1 X Window System miscellaneous util ii libxpm44.3.0.dfsg.1-14sarge1 X pixmap library ii libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics ii mime-support 3.28-1MIME files 'mime.types' 'mailcap ii perl 5.8.4-8 Larry Wall's Practical Extraction ii sed4.1.2-8 The GNU sed stream editor ii tetex-base 3.0-8 Basic library files of teTeX ii ucf1.17 Update Configuration File: preserv ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- debconf information: tetex-bin/upd_map: true tetex-bin/cnf_name: tetex-bin/fmtutil: true tetex-bin/fmtutil-failed: tetex-bin/userperm: false * tetex-bin/texmf: true tetex-bin/updmap-failed: * tetex-bin/hyphen: ngerman[=naustrian-neue_Rechtschreibung], french[=patois] tetex-bin/oldcfg: true * tetex-bin/use_debconf: false * tetex-bin/groupname: users tetex-bin/groupperm: true * tetex-bin/lsr-perms: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334658: tetex-bin: updmap was run as root
On Wed, Oct 19, 2005 at 15:52 +0200, Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: However, the behviour of 'updmap-sys --syncwithtrees' is not correct. Should I make a separate bug for this? Yes, please. Done. Jean-Charles: Do you have a file '/usr/share/texmf/web2c/updmap.cfg'? If yes, please rename it and call 'update-updmap', 'mktexlsr' and 'updmap-sys'. After that I think your system should be ok again. Ralf, do you know where this file would come from? updmap-sys --syncwithtrees (or updmap-sys --edit) does that. See my first message to this bug and the new bug report for details. One further comment concerning this bug here. As expected, the problems do not occur, when one uses lmodern packages made for teTeX 3, ie, in a clean pbuilder with an additional deb http://people.debian.org/~frn/teTeX-3.0 sid/binary-all/ in /etc/apt/sources.list, 'apt-get install lmodern' works without problems. I *think* this bug can be reassigned to lmodern and closed by the upload of a teTeX 3 compatible package. Florent, Frank, what do you think? cheerio ralf
Bug#334747: updmap-sys --syncwithtrees (was: Bug#334658: lm.map not found while configuring tetex-bin 3)
[moving this to #334747 where I think it belongs. On Wed, Oct 19, 2005 at 17:12 +0200, Florent Rougon wrote: Florent Rougon [EMAIL PROTECTED] wrote: This should fix everything I am aware of, except maybe the possible mess caused if you followed the 'updmap-sys --syncwithtrees' advice. I still have to check exactly what this does. OK. I have checked now, and the only problem it seems to cause is the creation of /usr/share/texmf/web2c/updmap.cfg, which unfortunately shadows /var/lib/texmf/web2c/updmap.cfg when updmap-sys is run, as pointed out by Ralf (thanks!). It seems to me it would be a good idea to call 'rm -f /usr/share/texmf/web2c/updmap.cfg' maybe in tetex-bin's postinst, somewhere before the updmap-sys run. Otherwise, I fear updmap-sys will keep updating /usr/share/texmf/web2c/updmap.cfg instead of /var/lib/texmf/web2c/updmap.cfg. What do you think? The way I see it right now, both 'updmap-sys --syncwithtrees' and 'updmap-sys --edit' create '/usr/share/texmf/web2c/updmap.cfg'. Especially the latter is quite likely to be used at some point by a local admin who hasn't read the Debian specific docs. I don't think that removing '/usr/share/texmf/web2c/updmap.cfg' during tetex-bin's configuration would be enough. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
On Wed, Oct 19, 2005 at 21:23 +0200, Florent Rougon wrote: Ralf Stubner [EMAIL PROTECTED] wrote: The way I see it right now, both 'updmap-sys --syncwithtrees' and 'updmap-sys --edit' create '/usr/share/texmf/web2c/updmap.cfg'. Especially the latter is quite likely to be used at some point by a local admin who hasn't read the Debian specific docs. I don't think that removing '/usr/share/texmf/web2c/updmap.cfg' during tetex-bin's configuration would be enough. Right. I'm not claiming it's enough. Simply, it would help people who fell into the trap of these commands, as long as they don't run them again... In the case where this started, the user would have been back at 'square one', since updmap-sys would again try to use the still incorrect /var/lib/texmf/web2c/updmap.cfg and again suggest 'updmap-sys --syncwithtrees' or 'updmap-sys --edit'. All I am saying is that this file *has* to be removed on the systems where it was created. ACK cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334701: can't install tetex-bin 2.0.2-31 due to /usr/share/man/man1/texi2pdf.1.gz
On Wed, Oct 19, 2005 at 16:36 +0200, Vincent Lefevre wrote: On 2005-10-19 15:49:07 +0200, Frank Küster wrote: No, it isn't, since 334613 is against 3.0-9, and has only been introduced by this upload. I don't know what is happening with 2.0.2, and honestly I won't try to find out, since this version is no longer available in sid. If you like, you can report a separate bug against the testing version, but I won't put time into it. If the unstable packages are going to be fixed before 2.0.2, then this is fine. Sorry, but I am not sure what you are trying to tell here. Since 3.0 is in unstable, we can't easily provide a fixed 2.0.2 package for testing, even if we had the manpower to do so. We can only try to offer workarounds. In your case, I think it would be best to uninstall jadetex and texinfo. After that, update to teTeX 3.0 from unstable, which works fine if jadetex is not present. After that, reinstall jadetex and texinfo. HTH. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
On Wed, Oct 19, 2005 at 23:05 +0200, Florent Rougon wrote: Ralf Stubner [EMAIL PROTECTED] wrote: In the case where this started, the user would have been back at 'square one', since updmap-sys would again try to use the still incorrect /var/lib/texmf/web2c/updmap.cfg and again suggest 'updmap-sys --syncwithtrees' or 'updmap-sys --edit'. I'm not sure I understand whay you mean. I see two cases: - users who encountered #334658 and did not run 'updmap-sys --syncwithtrees' - for these users, the fix I proposed in #334658 must work (I tested it) - users who encountered #334658 and did run 'updmap-sys --syncwithtrees' - if they blindly follow the same procedure without the rest, they will install lmodern 0.92-9, which will run: update-updmap - generates a correct /var/lib/texmf/web2c/updmap.cfg updmap-sys- uses the bad updmap.cfg under TEXMFMAIN Doesn't work. They have to remove the bad updmap.cfg from TEXMFMAIN first. Is that what you meant? But as far as tetex-bin is concerned, if the bad updmap.cfg is removed before the updmap-sys call in tetex-bin.postinst, things should be all right, no? I didn't take lmodern 0.92-9 into account but only thought about yesterdays situation. A user who encountered #334658 and did run 'updmap-sys --syncwithtrees' will have two updmap.cfg files. One in the right place but with wrong content (still mentions lm.map), one in the wrong place (for Debian) but with lm.map commented out. Now a reconfigure of both tetex-bin and lmodern works, but the LM fonts won't be available. If however, tetex-bin would delete the updmap.cfg in /usr/share/texmf/web2c before running updmap-sys, the updmap.cfg in /var/lib/texmf/web2c would be used. This file still references lm.map, so updmap-sys would fail again, suggesting to use --syncwithtrees or --edit. That's what I meant with 'back at square one'. Now, with the new lmodern in unstable, this can't happen anymore, but your second case is still problematic. Maybe the best place to check for additional updmap.cfg files would be update-updmap. And since one could go around in circles with simply removing additional updmap.cfg files, one might have to inform the user about this, present a diff or something like this ... cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
On Thu, Oct 20, 2005 at 11:22 +0200, Florent Rougon wrote: I fully agree. I may implement that in update-updmap as you suggest, That would be great. if I don't feel too dizzy (pretty bad night, ugh...). I don't think we are in a hurry with this. Especially as fmtutil-sys and texconfig-sys might also be affected, it might be necessary to analyze the whole situation more carefully. BTW, I just found out that fmtutil-sys also supports --edit and --enablefmt options (not documented in fmtutil(1) :-(. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334713: [Florian Cramer] Re: tetex-bin: package doesn't install because of missing mfw binary
On Thu, Oct 20, 2005 at 12:40 +0200, Frank Küster wrote: mfw was the name of the mf binary with X11 support, mf-nowin is the name without. In 2.0, /usr/bin/mf was a symlink to /usr/bin/mfw, now it the binary itself is called /usr/bin/mf. I think this is an upstream change, Yes, this is an upstream change. teTeX 2.0.2 compilde from source has mf - mfw mf-nowin mfw teTeX 3.0 compiled from source has mf mf-nowin but restoring the old behavior probably won't hurt anybody. We could also create the reverse symlink (mfw - mf), but then we get problems in case we want to split of a tetex-bin-nowin package and want /usr/bin/mf to be managed with update-alternatives. ACK cheerio ralf
Bug#334747: updmap-sys --syncwithtrees
On Thu, Oct 20, 2005 at 19:46 +0200, Florent Rougon wrote: Ralf Stubner [EMAIL PROTECTED] wrote: That would be great. Done. I chose to abort to make sure the user will see the message and not do the same mistake in the future. Thanks! I haven't tested it yet, but from looking at the source I have one comment. I think '--enable' and '--disable' can be removed from $bad_options for updmap-sys, since these are debianized via Frank's debianze-updmap. BTW, I just found out that fmtutil-sys also supports --edit and --enablefmt options (not documented in fmtutil(1) :-(. Well, that's a gift for us. :) Indeed. :-) cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335055: tetex-bin: Uninstallable: rm: cannot remove `/var/lib/texmf/web2c/*fmt': No such file or directory
merge 335055 335065 thanks On Fri, Oct 21, 2005 at 19:51 +0200, Kurt Roeckx wrote: Setting up tetex-bin (3.0-10) ... rm: cannot remove `/var/lib/texmf/web2c/*fmt': No such file or directory dpkg: error processing tetex-bin (--configure): subprocess post-installation script returned error exit status 1 Thanks for reporting. This is now fixed in our SVN. I'm also seeing problems on upgrades, but the errors are ussually of my screen by the time I look at them, and when trying it again they're succesful. I can only assume they're related. Upgrades from which version? On Sat, Oct 22, 2005 at 02:25 +0800, binghe wrote: Setting up tetex-bin (3.0-10) ... Creating config file /etc/texmf/fmt.d/01tetex.cnf with new version rm: cannot remove `/var/lib/texmf/web2c/*fmt': No such file or directory dpkg: error processing tetex-bin (--configure): subprocess post-installation script returned error exit status 1 Thanks for reporting to you, too. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335055: tetex-bin: Uninstallable: rm: cannot remove `/var/lib/texmf/web2c/*fmt': No such file or directory
On Fri, Oct 21, 2005 at 21:04 +0200, Kurt Roeckx wrote: On Fri, Oct 21, 2005 at 08:52:50PM +0200, Ralf Stubner wrote: You'll need to adjust the severity of 335065 to grave first before merging. Thanks. I'm also seeing problems on upgrades, but the errors are ussually of my screen by the time I look at them, and when trying it again they're succesful. I can only assume they're related. Upgrades from which version? This was first from 2.0.2-31 to 3.0-9, which is supposed to be fixed in -10 (#334613), but I also had problems going from 3.0-9 to 3.0-10, but I'm not sure if it's related to the bug that got fixed in -10 or not, or if it was this one. Strange. Upgrading from 3.0-9 to 3.0-10 works fine here in a clean pbuilder w/ or w/o jadetex installed. Of course, there might be other interactions with TeX related packages that ypu have installed. What packages that depend on one of the tetex packages do you have installed? BTW, anybody encountering bug #335055/#335065 can, as a simple workaround, create an empty file /var/lib/texmf/web2c/foo.fmt before (re)configuring tetex-bin. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335055: tetex-bin: Uninstallable: rm: cannot remove `/var/lib/texmf/web2c/*fmt': No such file or directory
On Sat, Oct 22, 2005 at 15:23 +0200, Kurt Roeckx wrote: On Fri, Oct 21, 2005 at 08:52:50PM +0200, Ralf Stubner wrote: Thanks for reporting. This is now fixed in our SVN. It would be nice if this got uploaded soon, since this is causing problems on the buildds. I am not a DD, so I can't help here. AFAIK Frank, who does the main work on the teTeX packages, is offline over the weekend. The fix is in the SVN, though, (together with a fix for #334660) located at svn.debian.org/svn/pkg-tetex/tetex-bin/trunk/ Maybe one of the other uploaders for teTeX could prepare new packages? I am not experienced enough to judge the situation, but a NMU might also make sense. Sorry for not being able to help more. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335210: tetex-bin: updmap-sys can't find dvips35.map
On Sat, Oct 22, 2005 at 18:08 +0200, Lucas Bonnet wrote: Package: tetex-bin Version: 3.0-10 Severity: important Thanks for reporting. When I apt-get dist-upgrade, or when I call updmap-sys : -- updmap-sys: This is updmap-sys, version 1107552857-debian updmap-sys: using transcript file `/var/lib/texmf/web2c/updmap-sys.log' [...] updmap-sys: Scanning for LW35 support files !!! ERROR! The map file `dvips35.map' has not been found at all. This file is installed by tetex-base. Is tetex-base correctly installed and configured? The file is installed as /etc/texmf/map/dvips/tetex/dvips35.map and is found via the symlink $ ls -ld /usr/share/texmf/fonts/map/dvips lrwxrwxrwx 1 root root 20 2005-10-20 18:59 /usr/share/texmf/fonts/map/dvips - /etc/texmf/map/dvips Does that link exist on your system? Or is there a directory /usr/share/texmf/fonts/map/dvips/? If that is the case, please move its content (what is it?) to /etc/texmf/map/dvips and create the above link. After calling 'mktexlsr', 'updmap-sys' should then work properly. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335210: tetex-bin: updmap-sys can't find dvips35.map
On Sat, Oct 22, 2005 at 19:08 +0200, Lucas Bonnet wrote: It was containing bera.map, a package I installed myself. Seems like I get the same error than Florent mentioned in the link he posted above. Indeed. In principle, it is always better to use /usr/local/share/texmf for additions that are not under dpkg's control. After fixing the link, mktexlsr ran fine. However, updmap-sys didn't. It successively complained about bsr-interpolated.map, bsr.map and eurosym.map. I managed to fix them, as it was just some .dpkg-new hanging around and not being renamed properly, then Hmm, that means that tetex-extra has not been configured correctly. updmap-sys --syncwithtrees and it was ok. Thanks a lot for your help ! ^^ Please, don't use this option (see #334658 and #334747), since this creates the file /usr/share/texmf/web2c/updmap.cfg. Please delete that file. Now would be a good time to configure tetex-extra. Or, if you did this already, call 'update-updmap', 'mktexlsr', and 'updmap-sys'. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400058: texdoctk does not find any documentation
Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: $ kpsewhich --expand-path=\$TEXMFDIST /usr/share/texmf-texlive:/usr/share/texmf-tetex However, it looks as if there are several places in texdoctk where it is assumed that TEXMFDIST referes to a single directory only. Hence I can't offer a patch yet. This sounds as if you planned to work on that. Any news, or no-s? I see two possibilities: * Use hardcoded /usr/share/texmf-tetex or /usr/share/texmf-texlive in texdoctk in tetex and texlive packages, respectively. * make texdoctk support a array of directories to search and populate that tree by parsing kpsewhich's output properly. The first approach would be quite simple, but it would hide documentation installed from 'the other' TeX distribution. The second approach would be more general, but also requires some changes to texdoctk. I had hoped to find some time to work on this during the long train rides I made recently, but this did not happen. :-( cheerio ralf
Bug#400058: texdoctk does not find any documentation
On Wed, Dec 06, 2006 at 21:42 +0100, Frank Küster wrote: I think we can claim that this will solve the bug; it's not a nice solution, but I don't see any drawbacks unless someone expects to be able to copy the texdoctk from a Debian binary package and use it on a different system. That is indeed the only drawback. And I think we can readily ignore that, even if some people don't understand that integrating a TeX distribution into a Linux distribution requires some changes. BTW, I think the changelog entry is not quite correct. This bug is not specific to systems with both tetex and texlive packages installed. Even on a pure tetex or pure texlive system currently no documentation in TEXMFDIST is found. This might even warrant a medium urgency. cheerio ralf
Bug#400058: texdoctk does not find any documentation
Frank Küster wrote: Are you sure? On my system, it works as long as /usr/share/texmf-texlive does not exist. It doesn't matter whether it contains anything, just creating the directory breaks texdoctk. But without it, it works (finds Fundamental/usrguide). You are right. I was thinking only in terms of texdoctk, which has no provision to deal with complicated path definitions, regardless whether or not the directories exists. However, kpathsearch is inteligent enough to not include nonexisting directories in the output of things like 'kpsewhich --expand-path=\$TEXMFDIST'. Good! cheerio ralf
Bug#401903: should not ship /etc/apache2/sites-available/tetex-doc
Frank Küster wrote: Uwe Kleine-Koenig [EMAIL PROTECTED] wrote: Moreover both URL that are mentioned in that file don't work for me: wget -q -O - http://localhost/doc/tetex-doc/texdoc.php gets the php-script uninterpreted. Probably the file should be guarded by IfModule php or something like that? No idea. It does work here, but I don't know what I changed. I remember having problems with this, but I also seem to remember that they resolved themselves by restarting both server and browser. Probably you have libapache-mod-php4 (or libapache-mod-php5) installed? I have not. These packages (actually those for apache2) are only Suggested. Should we move this to Recommends? IMO it would be overkill to recommend PHP and hence Apache on every system using tetex. It would be better to protect the apache configuration with suitable IfModule lines, ie IfModule mod_php4.c Alias ... ... /IfModule IfModule mod_php5.c Alias ... ... /IfModule Unfortunately IfModule takes only a single module name [1], so one has to duplicate everything. [1] http://httpd.apache.org/docs/2.0/mod/core.html#ifmodule cheerio ralf
Bug#400058: texdoctk does not find any documentation
Ralf Stubner wrote: Frank Küster wrote: Are you sure? On my system, it works as long as /usr/share/texmf-texlive does not exist. It doesn't matter whether it contains anything, just creating the directory breaks texdoctk. But without it, it works (finds Fundamental/usrguide). You are right. BTW, I would suspect that the situation texlive plus tetex-doc is much less common than tetex plus some texlive package. Hence the corresponding bug in texlive is probably not really important. cheerio ralf
Bug#402651: texlive-base-bin: texdoctk does not work
On Mon, Dec 11, 2006 at 21:20 +0100, Dieter Schuster wrote:
Package: texlive-base-bin
Version: 2005.dfsg.2-6
Severity: minor
After changing my tex-system from tetex to texlive, the programm
texdoctk does not start anymore. It produces the error messages:
Thanks for your report.
[EMAIL PROTECTED]:~$ texdoctk
Global symbol $distdocpath_tetex requires explicit package name at
/usr/bin/texdoctk line 659.
Global symbol $distdocpath_texlive requires explicit package name at
/usr/bin/texdoctk line 659.
Global symbol $texmfdist_tetex requires explicit package name at
/usr/bin/texdoctk line 743.
Global symbol $texmfdist_texlive requires explicit package name at
/usr/bin/texdoctk line 744.
Global symbol $distdocpath_tetex requires explicit package name at
/usr/bin/texdoctk line 757.
Global symbol $distdocpath_texlive requires explicit package name at
/usr/bin/texdoctk line 758.
Global symbol $distdocpath_tetex requires explicit package name at
/usr/bin/texdoctk line 974.
Global symbol $distdocpath_tetex requires explicit package name at
/usr/bin/texdoctk line 974.
Global symbol $distdocpath_texlive requires explicit package name at
/usr/bin/texdoctk line 975.
Global symbol $distdocpath_texlive requires explicit package name at
/usr/bin/texdoctk line 975.
BEGIN not safe after errors--compilation aborted at /usr/bin/texdoctk line
1407.
I have just compared the diffs for texdoctk in tetex and in texlive. It
seems that the texlive packages miss two parts:
# system variables
-my ($texmfmain,$texmfdist,$texmfdoc,$texmflocal,$texmfhome,
-$texdocpath,$distdocpath,$docdocpath,$localdocpath,$homedocpath,
+my
($texmfmain,$texmfdist_tetex,$texmfdist_texlive,$texmfdoc,$texmflocal,$texmfhome,
+
$texdocpath,$distdocpath_tetex,$distdocpath_texlive,$docdocpath,$localdocpath,$homedocpath,
Here the new variables are introduced. Not containing this raises the
above errors.
I cannot find these additions in texlive, either:
# $texmfdist=`kpsewhich --expand-path=${qq}\$TEXMFDIST${qq}`;
# chomp $texmfdist;
+ $texmfdist_tetex=/usr/share/texmf-tetex;
+ $texmfdist_texlive=/usr/share/texmf-texlive;
$distdocpath_tetex=join('/',$texmfdist_tetex,basename($texdocpath,))
if (length $texmfdist_tetex);
Without the hardcoded paths this thing won't work.
cheerio
ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402994: use new libpaper hook to track system paper size
On Thu, Dec 14, 2006 at 08:23 +0100, Frank Küster wrote: texconfig and therefore the paperconfig hook do *not* control the paper size that is used for typesetting (i.e. when TeX runs and calculates where to put the characters relative to the paper origin). It only takes effect when a PostScript or PDF file is created from the result. ACK. This is an important distinction to make. First of all, texconfig paper $PAPER only allows letter and a4. So either we need to change the hook script to check for that - or we patch texconfig to recognize more paper sizes. The current limitation is pdftex, which can have it's default papersize changed only by changing pdftexconfig.tex and redumping all formats. The different pdftexconfig.tex files needed for a4 and letter are hardcoded into texconfig. Second, the files that are affected are currently not configuration files, which is a bug. But what should we do? If we make them conffiles, users will get configuration file changed by you or a script if the file is changed upon upgrade. Although the statement is true, it won't help people very much who never looked at that file, in particular since the right choice would be to accept the new version from the package - it will be changed again right away by the libpaper hook. How about having the original files in TEXMFDIST and change texconfig such, that it writes the new files to TEXMF(SYS)VAR? That way the user will not have to deal with the files. But if needed, these files can be overruled by a file in TEXMF(SYS)CONFIG. One problem that I see right now is what texconfig(-sys) should do when such a file exists in TEXMF(SYS)CONFIG. Tricky ... One approach would be to separate the papersize setting out of the existing files, let texconfig paper act on the extracted files (which would reside in /var, not /etc) and let the programs read both the main config file and the papersize file. But I'm not sure whether this can be done without code changes to dvips/dvipdfm? dvipdfm allready links against libpaper. For dvips I currently see no possibility to have one configuration file specify another one, that should also be read. cheerio ralf
Bug#402983: texlive-bin: ttf2afm, and all of ttfutils, is missing
On Thu, Dec 14, 2006 at 00:02 +0100, Norbert Preining wrote: In the tpm2deb.cfg it is written: # collection psutils and ttfutils die, should be proper debian packages but at least ttfutils seem to be not to go this way. We should include this in our packages, or create a new binary package texlive-ttf-utils or whatever. ttfutils seems to come from different places: ttf2afm (pdftex, in tetex-bin, texlive should provide it) ttf2pk (freetype1, in freetype1-tools) ttf2tfm (freetype1, in freetype1-tools) ttfdump (no idea where that comes from, no idea what it is) cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402994: use new libpaper hook to track system paper size
Frank Küster wrote: The current limitation is pdftex, which can have it's default papersize changed only by changing pdftexconfig.tex and redumping all formats. The different pdftexconfig.tex files needed for a4 and letter are hardcoded into texconfig. What's the problem? This is the relevant part from texconfig: [...] Good question. I remembered a more complicated setup. Given this code, it would indeed be simple to add further paper sizes. Whether it is worth the effort is another question. How many people use something different from a4 or letter as default paper? Why can't we just add settings for other papersizes here (or let it read them from a separate file)? If one adds more paper sizes, I would do it here and feed the patches upstream. How about having the original files in TEXMFDIST and change texconfig such, that it writes the new files to TEXMF(SYS)VAR? That way the user will not have to deal with the files. But if needed, these files can be overruled by a file in TEXMF(SYS)CONFIG. One problem that I see right now is what texconfig(-sys) should do when such a file exists in TEXMF(SYS)CONFIG. Tricky ... Hm. Doesn't look very elegant to me. No, it's not. I will look at the code used in texconfig and see if something pops up. dvipdfm allready links against libpaper. Err, right. We probably should disable texconfig dvidpdfm paper, then. ACK For dvips I currently see no possibility to have one configuration file specify another one, that should also be read. Will it read multiple config files, e.g. in TEXMFSYSVAR and TEXMFSYSCONFIG/TEXMFDIST? I don't now, but I would be surprised if it does. cheerio ralf
Bug#402983: texlive-bin: ttf2afm, and all of ttfutils, is missing
Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: ttfdump (no idea where that comes from, no idea what it is) It seems to be available only in TeXlive now, not even separately on CTAN. And the project it was once supposed to be part of of doesn't seem to exist, and the developer is MIA: All changes since 1998 have been done by Werner Lemberg. And the purpose of ttfdump is to dump the various table in a TrueType font file in ASCII form. Interesting. Yet another program that does something like this. Up to now I only knew TTX (package fonttools) and showttf (could be build with fontforge, but maintainer does not want to #300111). I guess it does not hurt to have ttfdump in texlive. cheerio ralf
Bug#402983: texlive-bin: ttf2afm, and all of ttfutils, is missing
Norbert Preining wrote: Please note that ttfdump is NOT build in TeX Live 2005, and it is only present in the windows part of the tpm file. So I am not convinced that it builds at all, works at all,... This is true also for texlive-svn, also there is no ttfdump on linux binary. Ok. Thanks for the info. Since there are alternatives available, it does not make sense to think any further about ttfdump. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300111: fonttools from fontforge
Hi Kęstutis, in the closing message to this bug you said that the various fonttools available from URL:http://fontforge.sourceforge.net/fontutils.html are not actively maintained and that most of their feature are already available in fontforge. I don't know about the other tools, but I don't think this is the case for showttf, which does get updates as seen from URL:http://fontforge.cvs.sourceforge.net/fontforge/fontforge/fonttools/. These updates are infrequent, but this is expected given the nature of the tool. The TTF and OTF specifications don't change that rapidly. ;-) In addition, features of showttf are not available in fontforge. For example showttf allows one to take a detailed look into the structure of of the fonts and outlines, the usage of references etc. Also there are some private fields in TTF/OTF fonts which are not exposed by the fontforge GUI, while with showttf one can see their value. Therefore I would really appreciate it if you would include showttf into the Debian packages. Thanks for considering and thanks for maintaining fontforge. cheerio ralf
Bug#402994: use new libpaper hook to track system paper size
On Thu, Dec 14, 2006 at 19:05 +0100, Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: dvipdfm allready links against libpaper. Err, right. We probably should disable texconfig dvidpdfm paper, then. ACK Hm, no. Actually things are more complicated, and I'm not sure whether this is a good idea: dvipdfm reads both the libpaper setting and the setting in its config file, and the config file overrides the system setting. Odd. This makes linking against libpaper kind of useless. You seem to agree, since you have meanwhile removed that code. [...] For dvips I currently see no possibility to have one configuration file specify another one, that should also be read. Will it read multiple config files, e.g. in TEXMFSYSVAR and TEXMFSYSCONFIG/TEXMFDIST? I don't now, but I would be surprised if it does. Debian has patched dvipdfm to read two config files: config and fontmaps. I guess this is now unnecessary and predates updmap support for dvipdfm. But we could add a papersize file instead. Are you talking about dvipdfm or dvips here? BTW, does texlive include any of these patches to dvipdfm? cheerio ralf
Bug#402994: use new libpaper hook to track system paper size
On Thu, Dec 14, 2006 at 15:43 +0100, Ralf Stubner wrote:
How about having the original files in TEXMFDIST and change texconfig
such, that it writes the new files to TEXMF(SYS)VAR? That way the user
will not have to deal with the files. But if needed, these files can be
overruled by a file in TEXMF(SYS)CONFIG. One problem that I see right
now is what texconfig(-sys) should do when such a file exists in
TEXMF(SYS)CONFIG. Tricky ...
Hm. Doesn't look very elegant to me.
No, it's not. I will look at the code used in texconfig and see if
something pops up.
Ok, this is what I have come up so far. The idea is to test where the
file we are changing originally came from. If from TEXMFCONFIG, then it
is placed there again. If from somewhere else, then it is placed in
TEXMFVAR. Up to now I have only patched fmgrConfigReplace() and tested
this with dvipdfm's config file. There are a few other places where
tcfmgr is used to edit files. So the below patch is only a proof of
concept. Comments?
cheerio
ralf
--- /usr/sbin/texconfig 2006-11-28 12:06:47.0 +0100
+++ /home/ralf/bin/texconfig2006-12-15 00:08:18.958355000 +0100
@@ -255,6 +255,18 @@
}
###
+# setupTexmfconfig()
+# get value for MT_TEXMFCONFIG (with caching)
+###
+setupTexmfconfig()
+{
+ case $MT_TEXMFCONFIG in
+) MT_TEXMFCONFIG=`kpsewhich -var-value=TEXMFCONFIG`;;
+*) return;;
+ esac
+}
+
+###
# setupSystexmf()
# get value for MT_SYSTEXMF (with caching)
###
@@ -401,7 +413,13 @@
set x $co; shift
fmgrConfigReplaceID=$1; fmgrConfigReplaceCfgFile=$3;
fmgrConfigReplaceOrigFile=$4
configReplace $fmgrConfigReplaceCfgFile $fmgrConfigReplaceRegex
$fmgrConfigReplaceValue
- ci=`tcfmgr --tmp $tmpdir --cmd ci --id $fmgrConfigReplaceID`
+ # test if fmgrConfigReplaceCfgFile was in TEXMFCONFIG, if not use TEXMFVAR
for output
+ setupTexmfvar # this function defines MT_TEXMVAR, not MT_TEXMFVAR. Typo?
+ setupTexmfconfig
+ moreArgs=
+ echo $fmgrConfigReplaceOrigFile | grep $MT_TEXMFCONFIG /dev/null \
+ || moreArgs=--texmfconfig $MT_TEXMVAR
+ ci=`tcfmgr $moreArgs --tmp $tmpdir --cmd ci --id $fmgrConfigReplaceID`
if test $? != 0; then
echo $progname: fmgrConfigReplace ci failed for
\`$fmgrConfigReplaceFile' 2
(exit 1); return 1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402994: use new libpaper hook to track system paper size
On Fri, Dec 15, 2006 at 08:29 +0100, Frank Küster wrote: Are you talking about dvipdfm or dvips here? About dvipdfm. I haven't looked at dvips, and it doesn't make sense if both behave different. Ok. I was more concerned with dvips here, having put dvipdfm aside as it already used libpaper. So my comments concerning config files referred to dvips. I guess the patch to texconfig that you wrote is the better approach. The approach is flawed, however, since it is very easy to construct situations where files in /etc are automatically changed, which we must not do. Hence it is probably easier to make all files that can be changed via texconfig proper configfiles in /etc, as you already suggested. Then we would need the permission to modify these files in some aspects. We could get this permission either via a debconf message (IMO overkill) or by something like this: The libpaper hock script reads in, say, /etc/default/tetex which contains a variable, say, USE_LIBPAPER. By default this variable is set to 'no', which makes the libpaper hock script excit with a suitable message. If the variable is set to 'yes', the libpaper hock script will adjust the configuration files. Needed documentation: Mention this new mechanism (NEWS.Debian and 'TeX on Debian'). Explain that it might automatically change configuration files and explain the consequences, ie, that people should just accept new upstream versions if they did not make any other changes. Really, really stress that this only configures the default output paper size of the various *programs* but not of the *formats*, and that using things like geometry.sty is the better idea. Nice thing would be that no patches for texconfig or dvips/dvipdfm would be needed. cheerio ralf
Bug#402994: use new libpaper hook to track system paper size
On Thu, Dec 14, 2006 at 22:50 +0100, Frank Küster wrote: I don't think this is for etch, though, at least not with very thorough testing in unstable. Should we start a branch, or only do it when we actually need a further upload targetted at etch? This is not for etch (at least I hope that we won't have enough time for the required testing before etch is released ;-), hence it also is more texlive than tetex material. Concerning a separate branch: It is probably easiest if we create a special branch with things targeted for etch only when another upload is needed. cheerio ralf
Bug#397391: texlive-pdfetex: Documentation for how to get pdf(e|la)tex to use letter-size paper is missing
On Mon, Nov 06, 2006 at 18:13 -0600, Chris Lawrence wrote: I'm still not sure I did this right to make everything within TeXLive happy... I copied pdftexconfig.tex into /etc/texmf/tex/generic/config then hacked it as follows, since none of the obvious approaches (running texconfig in various and sundry ways) seemed to work: What did you try? The proper way to set pdfTeX to letter paper *is* texconfig-sys pdftex paper letter Or texconfig-sys paper letter to also change the defaults for dvips and dvipdfm. That is if you want to change the system-wide default. Use texconfig for per user changes. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397589: texlive-latex-extra does not contain beamer
Frank Küster wrote: Michael Piefel [EMAIL PROTECTED] wrote: Package: texlive-latex-extra Version: 2005.dfsg.2-2 Severity: normal texlive-latex-extra claims to contain beamer, but does not. Ah, interesting. It's texlive-latex-recommended that Recommends: latex-beamer. One part of the fix is going to be: Wait a second. IIRC moving beamer from texlive-latex-extra to texlive-latex-recommended was part of the TPM reorganisation done some time ago. It simply does not make sense to have the (old) prosper in texlive-latex-recommended while the currently used beamer or powerdot are in texlive-latex-extra. Hence I think it is only the description that has to be fixed. cheerio ralf
Bug#397589: texlive-latex-extra does not contain beamer
Frank Küster wrote: Thanks for noticing. So that makes --- tpm2deb.cfg (Revision 1941) +++ tpm2deb.cfg (Arbeitskopie) @@ -529,6 +529,9 @@ blacklist;tpm;pgf;* depends;texlive-full;pgf (= 1.01.dfsg.1-1), latex-beamer (= 3.06.dfsg.1-0.1), latex-xcolor (= 2.09-1) recommends;texlive-pictures;pgf (= 1.01.dfsg.1-1) +# beamer is in collection texlive-latex-extra, but prosper is in +# *-recommended. This doesn't make sense: Let beamer be +# recommended by texlive-latex-recommended recommends;texlive-latex-recommended;latex-beamer (= 3.06.dfsg.1-0.1) recommends;texlive-latex-recommended;latex-xcolor (= 2.09-1) # For this part of the bug. Looks good. As for errors in the description we have texlive-latex-recommended: claims to contain xcolor texlive-latex-extra: claims to contain beamer texlive-pictures: claims to contain pgf Unfortunately I have no idea how these descriptions are created. cheerio ralf
Bug#392517: Please make texlive-doc-en a Recommends
Norbert Preining wrote: About the splitting, see below. Concerning the bug: You are right. So I will change the relation from depends to suggests? or recommends? What do you suggest/recommend for now, without splitting!!?!? IMHO this depends on whether or not the meta package texlive should be used in dependencies or not. (I was the one who suggested to Ralph to not use it for sisu-pdf.) If 'texlive' is meant as a package that is selected by users, then Recommends is fine, since people who want to actively use TeX probably want to have at least parts of these docs. If we say it is okay for other packages to depend on 'texlive' instead of the appropriate 'texlive-*' packages, then I think Suggests would be better. People you use TeX only via automatic code generaters probably don't need all this documentation. I started collecting infos on these packages, here is what I found and what I propose as an idea (I did NOT say that I will implement it ;-) Looks good in principle, though there are a few items I don't know. For these Metafont and Metapost docs, I think they could go in the t-d-e-extra package: metafont-for-beginners -- The metafont-for-beginners package. 52 metafp -- Some Experiences in Running METAFONT and MetaPost. 204 metapost-examples -- Example drawings using metapost. 156 cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393950: latex-hangul-ucs: overrides common TeX configuration
On Wed, Oct 18, 2006 at 18:57 +0200, Frank Küster wrote: We should really try to come up with a setting for TTFONTS that makes sense for all Tex packages that use TrueType fonts. How about TTFONTS = .;$TEXMF/fonts/truetype//;/usr/share/fonts/truetype// ? I can't even tell which those are. dvipdfmx? ttf2pk from freetype1-tools? What else? ttf2tfm comes to mind. cheerio ralf
Bug#394167: texlive-base: please provide eqivalent to prosper
severity 394167 wishlist reassign 394167 prosper merge 394167 349670 392335 thanks Peter Schueller wrote: The prosper package cannot be used with texlive at the moment because it requires tetex-bin which conflicts with texlive. This is true, but it is a known bug of the prosper package. I also could not find prosper.cls in any texlive package. Generally the texlive packages try to make use of allready existing packages in Debian (see lmodern, jadetex, ...). In this particular case I would expect that existing files can use HA-prosper.cls from texlive-latex-recommended. The prosper compatibility mode from beamer.cls (latex-beamer) might also be worth atry. For new files, I would either use beamer.cls or powerdot.cls (texlive-latex-recommended). cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396826: tex-common: Please make section 2.4 of TeX-on-Debian more precise about user settings
Frank Küster wrote: Norbert Preining [EMAIL PROTECTED] wrote: +To override entries in the system wide configuration file +filetexmf.cnf/file, a user only needs to add lines to +ttvarHOME/var/.texmf-config/web2c/texmf.cnf/tt. +Please only add those lines which are absolutely necessary. I'd rather read this in the context, and in html instead of sgml-diff, but I think this could be improved. It looks like it's mixing up two issues: The general (non-Debian-specific) fact that TeX programs read more than one texmf.cnf [...] One problem is that texmf.cnf is only searched along the compiled in TEXMFCNF (not TEXMFCONFIG). At least as long as it is not defined in the environment. So in order for the above to work, one would also need export TEXMFCNF=$HOME/.texmf-config/web2c: (the final colon includes the system wide default). cheerio ralf
Bug#396826: tex-common: Please make section 2.4 of TeX-on-Debian more precise about user settings
On Fri, Nov 03, 2006 at 16:05 +0100, Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: One problem is that texmf.cnf is only searched along the compiled in TEXMFCNF (not TEXMFCONFIG). At least as long as it is not defined in the environment. So in order for the above to work, one would also need export TEXMFCNF=$HOME/.texmf-config/web2c: (the final colon includes the system wide default). --- doc/TeX-on-Debian.sgml(Revision 1926) +++ doc/TeX-on-Debian.sgml(Arbeitskopie) @@ -546,11 +546,25 @@ p prgnupdate-texmf/prgn is only available for root; if a user wants to maintain their own filetexmf.cnf/file, - they can put it into ttvarTEXMFCONFIG/var/web2c/tt and must - manually edit it. Since all filetexmf.cnf/file files - are read, with earlier definitions taking precedence over - later ones, it is best to keep only a minimal set of - definitions in the user-specific file. + they can put it into ttvarTEXMFCONFIG/var/web2c/tt + and must manually edit it. However, in order for it to be + found, they need to set an environment + variable + footnote + The reason for this is that the search + path for filetexmf.cnf/file, which is the file that + defines all search paths for later use, naturally cannot + be specified in the file, but is fixed at compile + time. + /footnote: +example +export TEXMFCNF=$HOME/.texmf-config/web2c: +/example +The final colon includes the system wide default. Since + all filetexmf.cnf/file files are read, with earlier + definitions taking precedence over later ones, it is best + to keep only a minimal set of definitions in the + user-specific file. /p ACK cheerio ralf PS: Thanks for writing this up. Only now I am sitting before my DEbian machine again.
Bug#396826: Bug#396823: marked as done (tetex-bin: How useful is texconfig on a Debian system)
On Fri, Nov 03, 2006 at 10:48 -0800, Debian Bug Tracking System wrote: * Clear up the description about user-specific configuration in TeX-on-Debian, many thanks to Géraud Meyer [EMAIL PROTECTED] (closes: #396823) [preining,frank] ^^ Wrong bug number. #396826 would be correct. How to best reopen #396823 and close #396826? cheerio ralf
Bug#396965: texlive-latex-extra: curve needs ltxtable to work
retitle 396965 ltxtable.sty is missing reassign 396965 texlive-latex-base thanks On Sat, Nov 04, 2006 at 00:04 +0100, Bernard Adrian wrote: Curve, which belongs to this package, can't work. It requires ltxtable.sty (of David Carlisle). Since some contribs of D. Carlisle are in texlive-latex-base, maybe it would be convenient to add ltxtable.sty in that package ? Otherwise, it would be necessary, imho, to add it in texlive-latex-extra. Thanks for your report and analysis. This is indeed a bug in texlive-latex-base where ltxtable.sty is missing, while the documentation ltxtable.pdf is actually installed. This might actually also be an upstream issue, since carlisle.tpm does not mention ltxtable.sty (as opposed to ltxtable.pdf). cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391484: order of texlive and tetex in texmfdist
On Sun, Oct 08, 2006 at 21:46 +0200, Frank Küster wrote: I think this makes sense. On critical systems (like buildds), only teTeX will be installed. Everyone who has (parts of) both will probably want the newer one in front. Should we do this for 0.32? I am in favour of a changed order. cheerio ralf
Bug#392517: Please make texlive-doc-en a Recommends
Michael Biebl wrote: Package: texlive Severity: wishlist The texlive-doc-en package is rather big (~55mb). If you want to install texlive instead of tetex and with other packages starting to depend on texlive | tetex-base, you are forced to install the documentation. It would be great if it was possible to choose if you want to install the documentation or not (either by using a Suggests or a Recommends). The same is true for texlive-fonts-recommended and texlive-latex-recommended. If they are not really required for a working texlive installation, their depedency should probably also degraded to Recommends: Are there any packages that depend on 'texlive'? This package is meant to be a meta package that installs a reasonable subset of TeX Live for those people who want to actively work with TeX. For those people, the two *-recommended packages do make sense. Other packages that just need some bits and pieces of TeX for them to work should explicitly depend on the texlive-* packages, that provide these things. However, I can understand the point concerning texlive-doc-en, especially since there is some highly specialized documentation in there. Here a Recommends or a splitting of the package might be appropriate. Other comments? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392586: tetex-bin: Insecure $ENV{PATH} while running setuid at /usr/bin/epstopdf line 211.
Dr. Tilo Levante wrote:
Package: tetex-bin
Version: 3.0-19
Severity: normal
I use epstopdf in a setuid script (backend for cups, needs access to
some directories), and get the error above.
Solution was to add the line
$ENV{PATH}= /usr/bin:/usr/sbin:/bin:/usr/bin;
in /usr/bin/epstopdf.
Do I understand you correctly that you are calling epstopdf from some
other program? I don't understand why it should be epstopdf's business
to care for a secure environment then. After all, epstopdf is a program
for general use and I might want to use it with a ghostscript binary
outside the above list of directories. This would be needlessly
difficult after such a change. IMO the calling program should set up
PATH in a secure way.
cheerio
ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390129: tetex-base: Does not properly call update-* scripts
Frank Küster wrote: The assumption above is wrong, or at least short-sighted. updmap-sys and fmtutil-sys can only be called when tetex-bin is there. However, we *must* call the update script under all circumstances. Otherwise tetex-bin will be without language information etc. I wonder how this slipped through... I don't understand. Shouldn't tetex-bin call the update-* scripts before generating formats/map files/... [Looking into common.functions.in] It seems it doesn't. IMO that's the bigger problem. But then, calling the update-* scripts should be safe at any time. However, now there is an unconditional call to mktexlsr in tetex-base's postinst jusst before the update-* scripts are called. IMO this is unsafe (tetx-bin might not be installed) an unnecessary (the update-* scripts don't use kpathsearching). cheerio ralf
Bug#390129: tetex-base: Does not properly call update-* scripts
Frank Küster wrote: Ralf Stubner [EMAIL PROTECTED] wrote: I don't understand. Shouldn't tetex-bin call the update-* scripts before generating formats/map files/... [Looking into common.functions.in] It seems it doesn't. IMO that's the bigger problem. I think every package that installs snippets for language.dat, updmap.cfg, etc., should call update-foo. That's the clean way. Agreed in principle (see below). However, I think it is also important that every package that calls fmtutil/updmap/... has to call the apropriate update-* scripts before, which tetex-bin does not at the moment. Just imagine that instead of tetex-base it would have been tetex-bin that got updated together with jadetex recently: tetex-bin's postinst regenerates formats, but the present fmtutil.cnf still represents the state valid before the changes to jadtex.ini. The same failure as with tetex-base would occur. If tetex-bin's postinst would call update-format, the problematic lines would not be present in fmtutil.cnf due to the present .dpkg-new file. But then, calling the update-* scripts should be safe at any time. However, now there is an unconditional call to mktexlsr in tetex-base's postinst jusst before the update-* scripts are called. IMO this is unsafe (tetx-bin might not be installed) Indeed; it will just fail if tetex-bin isn't installed, which I noticed during testing. It's already fixed in my local copy and the upload I made, and I just committed it. Good. A general point: Recently I was thinking whether it would make sense to change the behaviour of 'format providing packages' such as tetex-base or jadetex: Right now they regerenate all formats, even though this is not necessary. Why not have them regenerate only those formats they actually provide? A simple way to achieve this would be to call fmtutil-sys --all --cnffile /etc/texmf/fmt.d/foo.cnf That way these packages would be more self contained and could not get as easily broken by other packages. Of course, the 'binary providing packages' such as tetex-bin would still have to regenerate all formats. cheerio ralf
Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote: Frank Küster wrote: Thiemo Seufer [EMAIL PROTECTED] wrote: So, if I understand that correctly, the bug was fixed by running mktexmf as non-root, and the change of the cache location is only a collateral. No, or I do not understand what you mean. I meant the the earlier security bug you mentioned. To me, the solution for the earlier bug as well as the current one looks like keeping the font cache in /var but maintaining it via a mktexmf user. The problem is that mktexmf is a shell script (=no suid possible) that is started with the rights of the user. So the former solution required all users that wanted to use TeX to have write access below /var/cache/fonts. In addition for buildds the default now-questions- asked installation had to have directories below /var/cache/fonts with world write access. We had a system to restrict these rights to some group, but the debconf question and code were quite complicated and confused many users. cheerio ralf
Bug#390349: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
On Sun, Oct 01, 2006 at 14:48 +0200, Frank Küster wrote: Steve Langasek [EMAIL PROTECTED] wrote: Where does the input for the cache come from? If the input is always from a privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible -- and, I think, vastly preferable -- to have an suid wrapper for mktexmf to manage /var/cache. If the font input comes from user-specified, non-privileged locations, then this can't ever be safely written to a shared location. The input can come from the current directory, the user's own TEXMF tree or any directory specified in the MFINPUTS (etc.) variable. The output goes to the user's own TEXMF tree, though. If the input comes from a tree not defined is SYSTEXMF like some private TEXMF tree, then that tree is used for output as long as it is writable. If not, then the current directory is used (at least that'ss the way I understand mktexnam). However, this system isn't all that secure since the user could easily add the private TEXMF tree to SYSTEXMF. But then, what one can do with mktex* is rather limited, so the real problem is the write access, be it global or limited to some group. cheerio ralf
Bug#390349: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
On Sun, Oct 01, 2006 at 21:13 +0200, Frank Küster wrote: I didn't check the mktexnam code - but I'm a little surprised here. I wasn't aware of the test for SYSTEXMF, but in case the test fails, i.e. the input is from a private TEXMF tree, shouldn't the output go to TEXMFVAR ($HOME/.texmf-var), too? And isn't VARTEXFONTS the fallback in that case too, as it is if the input comes from a system tree? I don't think it would be good, if ouput, which has been produced based on a font in private TEXMF tree, ended up in the system wide font cache. One possible problem are two users that have *differing* fonts but with *equal* names in there private TEXMF trees. There are possibly other reasons why mktexnam (line 138--185) distinguishs system trees from the rest. Julian's idea that I mentioned previously is in line with what you describe in the first paragraph. If I remember right, it goes approximately like this: [...] Interesting. I am not sure, though, how important all this mktex* stuff will be in the future. Right now if we shipped the metrics for the EC fonts in teTeX (TeX Live does that IIRC) and told people to install cm-super, most invocations of mktex* would no-longer be necessary. However, this requires some thorough thinking before implementing it, careful coding, and in any case it is something to introduce upstream. Definitely. I repeat myself: I do not think that we do have any serious problem. The minor problems we have are much less severe in etch than they were in sarge, and I'd rather close this bug, or maybe set it to wishlist until Julian's idea gets implemented. ACK cheerio ralf
Bug#390349: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
On Mon, Oct 02, 2006 at 08:07 +0200, Frank Küster wrote: Okay, you are right, indeed this check is already done. So we could gain some additional security by making sure that the SYSTEXMF variable is not set in the user environment, but only read from the system-wide texmf.cnf. That's non-trivial, though, since the user can alter SYSTEXMF not only via an environment variable but also via a personal texmf.cnf file. And *all* texmf.cnf files that are found will be read. Getting the personal file found could be achieved by setting TEXMFCNF or placing a copy of kpsewhich in HOME/bin, so that HOME/texmf/web2c/texmf.cnf would get found via the SELFAUTOPARENT feature. So besides SYSTEXMF one would also have to control TEXMFCNF and PATH. One could also try to extract SYSTEXMF from the systemwide texmf.cnf file and set an appropriate environment variable, since that would take precedence. But one would have to define that in terms of actual directories, not variables like TEXMFMAIN etc, since a malicious user could redefine those, too. Given all these possibilities, I am quite happy that the possbile threats are not that serious ... cheerio ralf
Bug#390129: Rebuilding only provided formats - will that work?
Frank Küster wrote: Frank Küster [EMAIL PROTECTED] wrote: Hi Ralf, hi Norbert, Still no answer... Sorry, this message got pushed pack to deeply due to some email troubles I had during the last few days. Never reboot the wrong server without thinking :-( Should we just go on and let tetex-base's and tetex-extra's postinst call create_tetex_formats --all --cnffile /etc/texmf/fmt.d/01tetex.cnf I think that would help, too, at least with jadetex and friends. There's an other potential problem here. If a new tetex-base contains a change that requires the LaTeX formats to be regenerated, it might well be that other formats that preload LaTeX during format generation also need to be rebuilt. The same then is also true for a TeXlive based system. Why should they have to be rebuild? It sure would be better if they were rebuild so that they can use the new and shiny features of the new LaTeX :-), but the old format should work just as well. But somehow this seems to be a more general problem. Even a format that does not preload LaTeX might become unusable, and it might even require configuration file changes before it works again. Just imagine that it turns out that some hyphenation patterns are non-free and need to be removed. A package that keeps its own language.dat won't work any more. IIRC hyphenation patterns are also stored within the format. Hence the format using the now non-free patterns should still work. It would of course still use these patterns, even though they are no longer installed. So should we simply ignore such potential problems, and go on with using --cnffile during format renewal? Or rather try to recreate all of them? We should also consider what the effect would have been for jadetex or xmltex users on the previous frequent bugs if we had already only regenerated our own formats. Hm, I guess they mostly were related to changes in tetex-bin, weren't they? Yes, I think the main problems where due to the change in engine and the related 'efmt' - 'fmt' stuff. cheerio ralf
Bug#391348: updmap-sys neglects /usr/local/share/texmf
On Fri, Oct 06, 2006 at 10:20 +0300, Juhapekka Tolvanen wrote: Package: texlive-base-bin Version: 2005.dfsg.1-1 Severity: important I installed fpl-neu from this WWW-site to /usr/local/share/texmf : http://home.vrweb.de/~was/x/FPL/ Then I run commands texhash and updmap-sys --enable Map fp9.map ; updmap-sys. updmap-sys seems to do nothing in /usr/local/share/texmf . If I try to use those new fonts in my LaTeX-docs, after that dvips gives gazillon errors about fonts it can not create. kpathsea: Running mktexpk --mfmode ljfzzz --bdpi 8000 --mag 0+7200/(2*4000) --dpi 7200 fp9r9e This and the log from updmap-sys clearly shows that fp9.map has not been used. Norbert: Does updmap in TeX Live contain Frank's patches to make --enable work the Debian way? Juhapekka: Is fp9.map mentioned in the updmap configuration files, ie, what's the output of egrep fp9.map /etc/texmf/updmap.d/* egrep fp9.map `kpsewhich --format='web2c files' updmap.cfg` ? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391348: updmap-sys neglects /usr/local/share/texmf
On Fri, Oct 06, 2006 at 19:03 +0300, Juhapekka Tolvanen wrote: On Fri, 06 Oct 2006, +13:33:07 EEST (UTC +0300), Ralf Stubner [EMAIL PROTECTED] pressed some keys: This and the log from updmap-sys clearly shows that fp9.map has not been used. Juhapekka: Is fp9.map mentioned in the updmap configuration files, ie, what's the output of egrep fp9.map /etc/texmf/updmap.d/* /etc/texmf/updmap.d/10local.cfg:Map fp9.map egrep fp9.map `kpsewhich --format='web2c files' updmap.cfg` That command gives nothing but exit value 1. There is no output at all. Thanks. So fp9.map didn't make it to the actaully used updmap.cfg. Actually I should have spotted that earlier. The log you posted read: Fri Oct 6 09:59:26 EEST 2006 updmap-sys: This is updmap-sys, version 1122009795-debian updmap-sys: using transcript file `/var/lib/texmf/web2c/updmap-sys.log' updmap is creating new map files using the following configuration: config file: `/etc/texmf/web2c/updmap.cfg' ^^^ That's the wrong file. The one that is generated from the files in /etc/texmf/updmap.d/* is located in /var/lib/texmf/web2c. So if you move the above file to some save place, call update-updmap updmap-sys, then your system should be fine. Of course, it would be interesting to know where the file in /etc/texmf/web2c came from. Did you call 'updmap-sys --edit' or 'updmap-sys --syncwithtrees' at some time? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391348: updmap-sys neglects /usr/local/share/texmf
On Fri, Oct 06, 2006 at 12:01 +0200, Frank Küster wrote: However, --disable does not work, it still gives the same error. That's odd. I just tried updmap-sys --enable Map foo.map = file not found error updmap-sys --disable foo.map = everything fine I did call 'updmap-sys --disable Map foo.map' first, though, which gave me an 'unknown option foo.map'. cheerio ralf
Bug#391348: updmap-sys neglects /usr/local/share/texmf
On Fri, Oct 06, 2006 at 23:14 +0300, Juhapekka Tolvanen wrote: On Fri, 06 Oct 2006, +22:36:51 EEST (UTC +0300), Ralf Stubner [EMAIL PROTECTED] pressed some keys: Of course, it would be interesting to know where the file in /etc/texmf/web2c came from. Did you call 'updmap-sys --edit' or 'updmap-sys --syncwithtrees' at some time? I don't thinks so. At least I can not remember that I had done so. When was the file in /etc/texmf/web2c created? What's the difference to the proper file in /var/lib/texmf? It would be interesting to find out where this file came from. Debain TeX team: Would it make sense to implement a check in the update-* programs that looks for files in /e/t/web2c and prints out a big fat warning in case one is found? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391484: tetex-extra: include pdftricks
On Sat, Oct 07, 2006 at 08:44 +0200, Frank Küster wrote: Benjamin Leipold [EMAIL PROTECTED] wrote: Package: tetex-extra Version: 3.0-23 Severity: wishlist Is there any possibility to include pdftricks int tetex-extra? No, teTeX is dead upstream. However, it's successor, TeXlive, is already present in etch and sid, and pdftricks is available in the texlive-pdfetex package. I thought pdftricks was moved to texlive-pstricks in the recent reorganization. If not, I think this would be the ideal place for pdftricks. Benjamin: Note that you can instll most TeX Live packages alongside your existing teTeX installation. For example texlive-pstricks would give you a newer version of pstricks than what's available in teTeX. In order to make full use of this you would have to change TEXMFDIST, though. Ask for details if you are interested. Maybe it would make sense the reverse the paths in TEXMFDIST? cheerio ralf
Bug#391348: updmap-sys neglects /usr/local/share/texmf
On Sat, Oct 07, 2006 at 11:07 +0200, Ralf Stubner wrote: Debain TeX team: Would it make sense to implement a check in the update-* programs that looks for files in /e/t/web2c and prints out a big fat warning in case one is found? Actually there already exists such a sanity check in update-fontlang which not only prints a message but also exits with an error (only used for update-updmap at the moment, though). It just has not been updated to TEXMFSYSVAR=/etc/texmf. I have submitted a patch (rev 1695). Since this change would have catched this bug, I will also close the bug in the changelog. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391348: updmap-sys neglects /usr/local/share/texmf
On Sat, Oct 07, 2006 at 17:34 +0300, Juhapekka Tolvanen wrote: Here is that old file /etc/texmf/web2c/updmap.cfg : ### This file was automatically generated by update-updmap. Ok, so this file was originally installed in /var/lib/texmf/web2c where it belongs. [...] ### From file: /etc/texmf/updmap.d/10texlive-base.cfg ### From file: /etc/texmf/updmap.d/10texlive-fonts-extra.cfg ### From file: /etc/texmf/updmap.d/10texlive-fonts-recommended.cfg ### From file: /etc/texmf/updmap.d/10texlive-games.cfg ### From file: /etc/texmf/updmap.d/10texlive-latex-base.cfg ### From file: /etc/texmf/updmap.d/10texlive-latex-extra.cfg ### From file: /etc/texmf/updmap.d/10texlive-math-extra.cfg ### From file: /etc/texmf/updmap.d/10texlive-omega.cfg ### From file: /etc/texmf/updmap.d/10texlive-pictures.cfg There are many parts for updmap.cfg from TeX Live packages but non from teTeX packages, so the original file in /var/lib/texmf/web2c was created *after* teTeX had been replaced by TeX Live. ### From file: /etc/texmf/updmap.d/90scalable-cyrfonts-tex.cfg #! Map scalable-cyrfonts-tex.map ### End of file: /etc/texmf/updmap.d/90scalable-cyrfonts-tex.cfg This looks suspicious. Using '#! ' for commenting lines is typical for updmap when called with --sync-with-trees (or --disable). According to your current listing of /etc/texmf/updmap.d/, you no longer have scalable-cyrfonts-tex installed. So maybe this package cause problems with the mapfile generation at some point, which prompted you to call 'updmap-sys --sync-with-trees'. However, since you don't remember this, we will never know for sure. BTW, does anyone know if scalable-cyrfonts-tex is compatible with the new font mechanisms from teTeX 3.0 and TeX Live yet? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388115: tetex-base: postinst fails, can not upgrade
On Wed, Sep 20, 2006 at 11:00 +0200, Hilmar Preusse wrote: Relevant log message seems to be: (/usr/share/texmf-tetex/tex/latex/base/latex.ltx ! LaTeX must be made using an initex with no format preloaded. l.78 ... using an initex with no format preloaded} This happens after fmtutil calls etex -ini -jobname=jadetex -progname=jadetex latex jadetex.ini This *looks* as if 'jadetex.ini' has been updated to the new form, while the fmtutil.cnf snippets have not. Either because these are conffiles and the local admins did not accept the change (not a bug), or because the most recent jadetex upload missed that change (jadetex bug). However, Frans and Sean, please answer these questions: The other errors just seems to be subsequent. 1. Which version of jadetex package do you use? 2. What gives you ls -l /etc/texmf/fmt.d? 3. Please send us files containing jade in its names. Then I can stop guessing ... BTW, did anybody see the original bug report via the mailing list? cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388115: tetex-base: postinst fails, can not upgrade
On Wed, Sep 20, 2006 at 23:46 +0400, Norbert Preining wrote: On Wed, 20 Sep 2006 12:07:33 +0200 Frans Pop [EMAIL PROTECTED] wrote: Looks like the 40jadetex.cnf.dpkg-new is there because jadetex cannot jet be configured and so the old version of the config file is still used. Yes, this is true, it seems to be like this. BUT: Why is the snippet at all included in the fmtutil.cnf file??? The new update-* code ??? added (who was it?) should make sure that the snippets with a .dpkg-new file are *not* included. I wondered about that, too. So could it be that tetex-* doesnt call update-fmtutil at the beginning of the postinst script? this would explain why this happened, at least this is my semi-qualified opinion from the crystal-ball ... Your crystal ball is good. Where did you get it? Anyway, it is indeed the case that tetex-base.postinst does not call update-fmtutil before caling fmtutil-sys, which is probably wrong. Ahh yes Ralf: I assume that the original bug report did go to the maintainer. But this is a bug against tetex-base. An debian-tex-maint is the maintainer of that package. We have had theproblem before. Typically with large messages. Unfortunately the latter are typical when building formats fails and people do what they are told, ie include the log file. Oh well ... What I dont understand is why the NMU is numbered -7? The last jadetex upload wasn't an NMU. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388788: Adding hyphenations of new languages is nothing but a major pain in the hindquarters
On Fri, Sep 22, 2006 at 17:31 +0300, Juhapekka Tolvanen wrote: I also installed packages texlive-lang-french and texlive-lang-italian . A file called /var/lib/texmf/tex/generic/config/language.dat was not properly generated. In what sense was it not properly generated? How did you determin that? I run update-languages by hand. After that it had wrong permissions, beacause root has umask 077. I made it world-readable. Actually this should not matter as long as root can read the file, since it is only used when format files are created, which is almost only done by root. But now running latex looks like this: This is pdfeTeXk, Version 3.141592-1.30.5-2.2 (Web2C 7.5.5) Source specials enabled. entering extended mode LaTeX2e 2003/12/01 Babel v3.8g and hyphenation patterns for english, dumylang, nohyphenation, finnish, ukenglish, loaded. Where is that Italian and French? Later I see this: You did not recreate the format files hence the changes to language.dat did not have any effect. Aargh! What is the canonical way to activate hyphenations and other language support of desired languages for LaTeX and friends? Normally the texlive-lang-* packages do this automatically. That looks like a bug worth investigating. Otherwise, # update-languages followed by # fmutil-sys --all should regenerate all format files with hyphenation enabled based on the configuration files in /etc/texmf/language.d/. If that does not help, then we will need some more informations for debugging. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388399: Processed: Re: Bug#388399: gnuplot: FTBFS
On Fri, Sep 22, 2006 at 12:55 +0200, Frank Küster wrote: reassign 388399 tetex-bin Bug#388399: mktexmf: line 92: mf31966.tmp: Permission denied on alpha, mips and mipsel Bug reassigned from package `gnuplot' to `tetex-bin'. Hm. It's not a general mipsel/alpha/mips problem. At least in the sid chroot on vaughan, a mipsel box, the command (mktextfm ecrm1728) works just fine. I won't have time to investigate this further, but I suspect that the underlying problem is that on the buildds, e.g. in http://buildd.debian.org/fetch.php?pkg=gnuplotver=4.0.0-5arch=alphastamp=1158062374file=logas=raw mktextmf tries to create the file in a TEXMF tree rooted in the current directory (/home/buildd/.texmf-var) instead of the varfonts tree in /tmp. Maybe the home directory just doesn't exist. The strange thing is that mktexmf, which is called here, looks like this: [...] destdir=`echo $MT_MFNAME | sed 's%/[^/][^/]*$%%'` test -d $destdir || $MT_MKTEXDIR $destdir || exit 1 cd $destdir || exit 1 [...] cat mf$$.tmp END ### first failure [...] chmod `kpsestat -xst,go-w .` mf$$.tmp ### second rm -f $mfname mv mf$$.tmp $mfname ### third echo $destdir/$mfname $STDOUT echo $progname: $destdir/$mfname: successfully generated. 2 $MT_MKTEXUPD $destdir $mfname [...] From the succesfull messages at the end of mktexmf we know that $destdir was /home/buildd/.texmf-var/fonts/source/jknappen/ec/, which must have existed otherwise the script would have been terminated before. So at first sight it looks as if $destdir was created but without write permissions. No idea why that could happen. cheerio ralf This may be a problem with the configuration on the buildds, we'd need the output of kpsewhich --format='web2c files' mktex.cnf as well as the file contents of the resulting filename, on the buildd. I'm formally on vacation and only able to write this mail out of sheer luck, and won't be able to work on that in the next days. [full-quote for the BTS]
Bug#388788: Adding hyphenations of new languages is nothing but a major pain in the hindquarters
On Sun, Sep 24, 2006 at 03:18 +0300, Juhapekka Tolvanen wrote: [EMAIL PROTECTED]:/home/juhtolv % tree .texmf* .texmf-var |-- fonts | `-- tfm | `-- jknappen | `-- ec `-- web2c |-- latex.fmt |-- latex.log |-- pdflatex.fmt `-- pdflatex.log As you found out these files where the problem. Here comes the explanation why it is a problem and how this might have happened: All the various commands latex, pdflatex, etex ... are just links to one binary: pdfetex. Based on the nameby which it is called, pdfetex looks for a suitable format file. For example when called as 'latex' it looks for the format file 'latex.fmt'. Normally these format files are created during installation and located in /var/lib/texmf/web2c/. However, if there is a format file in a private tree that comes before the system wide trees, that format will be used. You can check which format file is used via 'kpsewhich latex.fmt'. Now why did you have a format file in you $HOME? You must have called fmtutil under your UID instead of fmtutil-sys as root at one point. While the latter is for system wide changes, the former is used for personal changes. In general it is better and saver not to use the private trees for things like formats and font-map files. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388115: Here's my patch, any comments?
Frank Küster wrote: purge) +update-texmf Shouldn't that be update-texmf || true ? The rest looks fine to me. cheerio ralf
