Bug#688845: texlive-fonts-extra: Please demote all additional Depends to Recommends
Fabian Greffrath fab...@greffrath.com writes: *But I would like to suggest to split t-f-e into two parts, one without external dependencies and one with them.* [...] I think the t-f-e package is somehow special in this regard, since its dependencies are really exhaustive. I don't see any other texlive package with that many dependencies on external (i.e. not texlive-*) packages. Okay, this is a valid argument to package t-f-e differently and still keep the rest. However, this is only going to happen if you (which, 98% sure, means YOU, Fabian), start the coding and implement the splitting in the current setup with tpm2source-bin.pl, tpm2deb-bin.pl and tpm2deb.cfg. Preferrably without introducing new directives in the tpm2deb.cfg-syntax. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688845: texlive-fonts-extra: Please demote all additional Depends to Recommends
Fabian Greffrath fab...@greffrath.com writes: Did you check that *none* of the other files distributed by TeX Live in the texlive-fonts-extra package require any of the font packages that it depends on? No, and I am even sure that some other files in texlive-fonts-extra *do* require some of the fonts that it depends on. But I think that it can be expected from users --if they want to use a font from texlive-fonts-extra in TeX-- to make sure to install that actual font package as well. Furthermore, recommended packages will be installed alongside t-f-e by default; the main difference being that it's allowed to remove them without having to remove t-f-e as well. That's a point, but we should carefully think about this, and also think about which road we're getting onto when we make this change. Are there other packages where people will ask us to demote many Depends to Recommends? Do we want to do that? What is the criterion for a Depends, then? If we follow your argument, shouldn't all but the -base packages have _only_ Recommends? Isn't such a TeXLive package more like the old task packages, then? Am I right that those have been abandoned, and if yes why? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697353: binutils: FTBFS with texinfo from experimental
Norbert, did you notice this? Any ideas? Frank Paul Wise p...@debian.org writes: Source: binutils Version: 2.23.1-1~exp3 Severity: normal X-Debbugs-CC: debian-tex-ma...@lists.debian.org binutils 2.23.1-1~exp3 FTBFS with texinfo 4.13.92.dfsg.1-1 from experimental. There are some warnings that seem to cause the FTBFS: guest@morrison:~/cross$ apt-cache policy texinfo texinfo: Installed: 4.13.92.dfsg.1-1 Candidate: 4.13.92.dfsg.1-1 Version table: *** 4.13.92.dfsg.1-1 0 1900 http://http.debian.net/debian/ experimental/main amd64 Packages 100 /var/lib/dpkg/status 4.13a.dfsg.1-10 0 1700 http://http.debian.net/debian/ testing/main amd64 Packages 1800 http://http.debian.net/debian/ unstable/main amd64 Packages guest@morrison:~/cross$ apt-get --build -oDpkg::Build-options=-b source binutils Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'binutils' packaging is maintained in the 'Bzr' version control system at: http://bazaar.launchpad.net/~doko/binutils/pkg-2.23-debian Please use: bzr branch http://bazaar.launchpad.net/~doko/binutils/pkg-2.23-debian to retrieve the latest (possibly unreleased) updates to the package. Skipping already downloaded file 'binutils_2.23.1-1~exp3.dsc' Skipping already downloaded file 'binutils_2.23.1.orig.tar.gz' Skipping already downloaded file 'binutils_2.23.1-1~exp3.diff.gz' Need to get 0 B of source archives. dpkg-source: info: extracting binutils in binutils-2.23.1 dpkg-source: info: unpacking binutils_2.23.1.orig.tar.gz dpkg-source: info: applying binutils_2.23.1-1~exp3.diff.gz dpkg-buildpackage: source package binutils dpkg-buildpackage: source version 2.23.1-1~exp3 dpkg-buildpackage: source changed by Matthias Klose d...@debian.org dpkg-buildpackage: host architecture amd64 dpkg-source --before-build binutils-2.23.1 fakeroot debian/rules clean QUILT_PATCHES=/home/guest/cross/binutils-2.23.1/debian/patches \ quilt --quiltrc /dev/null pop -a -R || test $? = 2 ... cd builddir-single env CC=gcc CXX=g++ CFLAGS=-g -O2 \ ../configure --with-sysroot=/ --enable-shared --enable-plugins --prefix=/usr --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-pkgversion=GNU Binutils for Debian --enable-targets=x86_64-linux-gnux32 --enable-ld=default --enable-gold ... checking for makeinfo... makeinfo ... make[1]: Entering directory `/home/guest/cross/binutils-2.23.1/builddir-single' ... checking for makeinfo... makeinfo ... gcc -g -O2 -o sysinfo sysinfo.o syslex_wrap.o ./sysinfo -d ../../binutils/sysroff.info sysroff.h Making info in doc make[4]: Entering directory `/home/guest/cross/binutils-2.23.1/builddir-single/binutils/doc' restore=: backupdir=.am$$ \ rm -rf $backupdir mkdir $backupdir \ if (makeinfo --split-size=500 --split-size=500 --version) /dev/null 21; then \ for f in binutils.info binutils.info-[0-9] binutils.info-[0-9][0-9] binutils.i[0-9] binutils.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi \ if makeinfo --split-size=500 --split-size=500 -I ../../../binutils/doc -I ../../../binutils/../libiberty -I ../../../binutils/../bfd/doc -I ../../bfd/doc -I ../../../binutils/doc \ -o binutils.info `test -f 'binutils.texi' || echo '../../../binutils/doc/'`binutils.texi; \ then \ rc=0; \ else \ rc=$?; \ $restore $backupdir/* `echo ./binutils.info | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc ../../../binutils/doc/binutils.texi:4378: warning: @itemx should not begin @table ../../../binutils/doc/binutils.texi:4386: @itemx must follow @item ../../../binutils/doc/binutils.texi:4390: @itemx must follow @item ../../../binutils/doc/binutils.texi:4396: @itemx must follow @item ../../../binutils/doc/binutils.texi:4400: @itemx must follow @item ../../../binutils/doc/binutils.texi:4410: @itemx must follow @item ../../../binutils/doc/binutils.texi:2385: warning: Node next `ranlib' in menu `readelf' and in sectioning `size' differ ../../../binutils/doc/binutils.texi:2463: warning: Node prev `size' in menu `readelf' and in sectioning `ranlib' differ ../../../binutils/doc/binutils.texi:2687: warning: Node next `strip' in menu `elfedit' and in sectioning `c++filt' differ ../../../binutils/doc/binutils.texi:3221: warning: Node next `nlmconv' in menu `windres' and in sectioning `windmc' differ ../../../binutils/doc/binutils.texi:3326: warning: Node next `windmc' in menu `dlltool' and in sectioning `windres' differ ../../../binutils/doc/binutils.texi:3326: warning: Node prev `windmc' in menu `windres' and in sectioning `nlmconv' differ ../../../binutils/doc/binutils.texi:3487: warning: Node next `windres' in menu `windmc' and in sectioning `dlltool' differ ../../../binutils/doc/binutils.texi:3487: warning: Node prev `windres' in menu `nlmconv' and in sectioning `windmc'
Bug#534641: Processed: Re: mendexk: mendex fails to process styling macro specifier in indexentry
tags 534641 upstream thanks Hisashi Morita hisas...@workbook.org writes: The reason I assumed this issue is relevant to texlive-binaries is as follows: $ which mendex /usr/bin/mendex $ dpkg -L texlive-binaries | grep bin/mendex /usr/bin/mendex $ dpkg-query -W texlive-binaries texlive-binaries2012.20120628-4 I see, mendexk still exists in unstable, and I wasn't aware that we have taken over the file. But since the bug was reported long ago, it seems it existed also in the standalone mendexk package, and is a upstream issue. Would you please take the time to contact the upstream authors? I don't think we'll have time to do this. TIA, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534641: Processed: Re: mendexk: mendex fails to process styling macro specifier in indexentry
ow...@bugs.debian.org (Debian Bug Tracking System) writes: Processing commands for cont...@bugs.debian.org: reassign 534641 texlive-binaries 2012.20120628-4 Bug #534641 [mendexk] mendexk: mendex fails to process styling macro specifier in indexentry I have no idea what this is about and why it should be a bug in texlive-binaries. mendexk does not even depend on texlive-binaries. Hisashi-san (or is it Morita-san?), could you please describe in detail what you did, that is - provide a minimal (La)TeX input file that produces the mendexk/makeindex input - name the commands you use to produce the output files Thanks, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695340: auctex: xdvi does not understand synctex
Davide G. M. Salvetti sa...@debian.org writes: `TeX-evince-sync-view' uses D-BUS to communicate with Evince. This is worth investigating, if we could use evince for DVI files with SyncTeX support. I will try something as soon as I have some more time, do the same yourself, please. Just a side note: I find xdvi very comfortable, you can navigate, zoom and do whatever you like with keystrokes - no need to use the mouse. Evince, at least as far as I found out some time ago, is very mousy with little useful keyboard shortcuts. Therefore I wouldn't like evince to be auctex's default dvi viewer. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631271: texlive-binaries: xdvi no longer uncompresses .gz and .bz2 files
Samuel Bronson naes...@gmail.com writes: Control: severity -1 important Control: block -1 by 583188 Control: tag -1 + confirmed Control: found -1 texlive-binaries/2012.20120628-4 Vincent Lefevre vinc...@vinc17.net writes: Package: texlive-binaries Version: 2009-8 Severity: normal xdvi no longer uncompresses .gz and .bz2 files. For instance: $ xdvi /usr/share/doc/texmf/latex/styles/preview.dvi.gz xdvi.bin: Fatal error: /usr/share/doc/texmf/latex/styles/preview.dvi.gz: Not a DVI file. Considering the number of .dvi.gz files shipped in Debian, I think this is actually fairly important. I don't think it is important, because it doesn't make much sense to type a commandline as the one above, when it is much easier to just type texdoc preview However, there _are_ issues with that: When see is used as the command for viewing in texdoc, which is the sensible default, this does not work because of a known bug. I'm not sure where, maybe it's only on a gnome desktop because I get View comand: (gnome-open /tmp/texdoc.qrsrFG/preview.dvi; rm -f /tmp/texdoc.qrsrFG/preview.dvi; rmdir /tmp/texdoc.qrsrFG) ** (evince:8177): WARNING **: Error stating file '/tmp/texdoc.qrsrFG/preview.dvi': No such file or directory IIRC gnome-open returns before the viewer has opened the file. The other problem is that (at least on stable), no system-wide texdoc.cnf is installed, and if you create one at the place you'd expect, /etc/texmf/texdoc/texdoc.cnf, it is simply ignored. Anyway, I'd much rather have these issues fixed than patch xdvi's code. However, patches are of course welcome. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694324: Bug#694323: [gsfonts] Fonts include copyrighted adobe fragment all right reserved
Hi Bastien, hi Norbert, Norbert Preining prein...@logic.at writes: The Debian orig.tar.gz doesn't seem to contain the source archive's contents. I'm not familiar with font generation, but it seems to me that, in order to be able to generate corrected Type1 files with a fixed fontforge version, we would need the contents of lm2.003.mt1.zip, e.g.: It is not a question of fontforge... THe lines mentioned come from pfcommon.dat which was inherited from metatype1. If this is right, then it is wrong to block the bug by the fontforge bug, isn't it? Bastien, I'm not sure enough about this to remove the blocking myself, please do it. Does that mean we have one more RC bug, namely that the sources are incomplete? debian/copyright says: No. I don't consider the metatype sources necessary, because afterwards the fonts went through manual hinting and fixing. How ist that done? I thought it was done with fontforge scripts - I understand this is not the case? Did they really open the font files in interactive fontforge, adjust and safe? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694323: Bug#694324: Fonts include copyrighted adobe fragment all right reserved
bastien ROUCARIES roucaries.bast...@gmail.com writes: Package: tex-gyre Version: 2.004.1-4 Severity: serious control: block -1 by 694308 This package include copyrighted font hinting from adobe. Do I understand correctly that we're not supposed to do anything, but just wait until fontforge is fixed? Hm, I'm wondering: Although lmodern's readme says , | The package consists of the files in the directories conforming | to the TeX Directory Structure (v. 1.1), splitted into three archives: | | lm2.003-bas.zip -- basic set; the directories contain: | [...] | lm2.003mt1.zip -- Latin Modern source font files for the METATYPE1 package ` The Debian orig.tar.gz doesn't seem to contain the source archive's contents. I'm not familiar with font generation, but it seems to me that, in order to be able to generate corrected Type1 files with a fixed fontforge version, we would need the contents of lm2.003.mt1.zip, e.g.: $ ls fonts/source/public/lm/lmr10* fonts/source/public/lm/lmr10.mp fonts/source/public/lm/lmr10.mph fonts/source/public/lm/lmr10.mpm fonts/source/public/lm/lmr10.mpg fonts/source/public/lm/lmr10.mpl $ cat fonts/source/public/lm/lmr10.mp This file belongs to the Latin Modern package. The work is released under the GUST Font License. See the MANIFEST-Latin-Modern.txt and README-Latin-Modern.txt files for the details. For the most recent version of this license see http://www.gust.org.pl/fonts/licenses/GUST-FONT-LICENSE.txt or http://tug.org/fonts/licenses/GUST-FONT-LICENSE.txt % LATIN MODERN font: a driver file for lmr10 input fontbase; vardef cm_pal = cmr10 enddef; input comm_mac; % common defs, CM params input comm_mph; % common header input lmr10.mpm; % metric data input lmr10.mph; % PS-oriented header beginfont input lmr10.mpg; % ``frozen'' glyphs input comm_mpg; % common glyphs (mainly diacritics) if known generating: % optimize proofing time input lmr10.mpl;% ligatures and kerns fi endfont EOF $ Does that mean we have one more RC bug, namely that the sources are incomplete? debian/copyright says: The following TeX Live packages were downloaded from http://www.ctan.org/tex-archive/systems/texlive/tlnet/archive/ and merged into one orig.tar.gz file: lm.tar.xz lm.doc.tar.xz lm-math.tar.xz lm-math.doc.tar.xz These are files prepared by TeXLive, not the original lmodern authors. In this directory, there is an additional lm.source.tar.xz file. It seems to me we should include its contents, too, shouldn't we? Does the same apply to TeX-Gyre? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690697: texlive-base: [INTL:ja] New Japanese translation
Norbert Preining prein...@logic.at writes: 皆様 On Mi, 17 Okt 2012, victory wrote: Here's Japanese po-debconf template translation (ja.po) file that reviewed by several Japanese Debian developers and users. 了解です。ギット・レポシトリーにアップしました。 宜しくお願いします ノルベルト You guys have seen #683127? Regards, Frank
Bug#691690: texlive-extra-utils: missing dependencies
forcemerge 691690 686675 stop Ian Bruce ian_br...@fastmail.net writes: It turns out that the required files are /usr/bin/pdflatex , and /usr/share/texlive/texmf-dist/tex/latex/pdfpages/pdfpages.sty , from the packages texlive-latex-base , and texlive-latex-recommended , respectively. Shouldn't these packages be listed as dependencies of texlive-extra-utils ? Norbert wrote earlier: , | The problem you *might* referring to is that it does not depend | on texlive-latex-base although it needs latex and pdfpages. | But this has nothing to do with pdflatex. ` Norbert, I haven't followed git logs so closely, have you already addressed this? Upstream only has Depends, no Suggests or Recommends, do they? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688041: Please confirm
Thomas Kremer bugs.deb...@xorg.c-informatik.de writes: By a new configuration option in all/debian/tpm2deb.cfg selected ... be automated in the scripts tpm2deb-source.pl and all/deb/tpm2debcommon.pm. Those scripts have access to any dependency Are as commonplace as possible. You're mistaking abstraction for commonplace. I have outlined the solution, not written the code. If that solution is already denied, the code cannot possibly have a chance. We're not at all opposed to a solution. We're just opposed to people who suggests solutions as abstract as this: No info about which packages you would put where, and no code. But in case you'd think otherwise I added this part as a solution, that would be suboptimal but still better than the current state. The -others package would have a warning that maintainers should make dependencies on that package only with the specific version number and request that the font they are depending on should be exposed as a separate package. Ah, good point. Ever looked into a FTBS bug reassigned to TeXLive? Package maintainers usually don't know which build-deps they need for building their documentation with LaTeX, they just try out. So every change here might bring funny new work into the boring life of the TeXLive maintainers... Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688041: Please confirm
Thomas Kremer bugs.deb...@xorg.c-informatik.de writes: Now, if you insist on keeping the debian package == Tex Live collection correspondence, We do not insist. We already have implemented docsplitting. no matter what inconveniences might occur from that decision, then you can close this bug as wontfix, since any solution can only contradict with that axiom. That way at least you won't have yet another bug report rotting in the BTS. Either you or someone else interested in this bug comes with a solution that works ... ( and that includes 1. a scheme for splitting, or in other words combining collections to a couple of Debian packages, and 2. a proposal on how to implement and maintain that (when new fonts are added frequently!) ) ... or this problem - be it a bug or not - will never be solved. Since you've already talked for two weeks and not produced a single line of code or splitting logic, I don't see a better alternative than closing this bug. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483217: marked as done (texlive-latex-base: Files by Donald Arseneau: Lacking license statement, or nosell and such)
ow...@bugs.debian.org (Debian Bug Tracking System) writes: Your message dated Thu, 11 Oct 2012 15:57:58 +0900 Many thanks for this. * chapterbib.sty: no license information there is a README that states: They are all released under a very simple permissive license in the MIT/BSD style: They may be freely used, transmitted, reproduced, or modified provided that [the copyright and permission] notice is left intact. I didn't notice this, or maybe it wasn't present (in teTeX, CTAN, ...) when I first checked. I have no idea why so many of the files have a license statement inside that it seems I didn't notice. Well. + * relsize.sty: public domain, nothing else % This software is contributed to the public domain. When I wrote this, I was under the impression that, since public domain doesn't exist in many jurisdictions, the term needs clarification. I don't think we need to insist on this, in particular not if Donald is from the US (which I don't know). Again, thank you very much, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688382: texlive-base: missing conffiles after squeeze-wheezy upgrade
Norbert Preining prein...@logic.at writes: Maybe one can completely drop the ucf file? Maybe the files were never added to the ucf database and this crept in somehow? I'm not competely sure without checking out older versions, but I _think_ that they are conffiles in squeeze, but they were managed by ucf in the later versions of TeXLive 2009 (2010?) in unstable and probably wheezy. Therefore one could argue we should rather leave in the code for people that did irregular upgrades to unstable or testing. However, I don't care much about anyone running testing or unstable early in the release cycle and then stopping to track updates - TL 2012 is in sid for months now. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689515: texlive-latex-base: Option a4paper in includeclass does not work with pdflatex.
Norbert wrote
I just say
\usepackage{geometry}
alternatively, for a system-wide and solution for every document,
paperconfig -p a4
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688845: Acknowledgement (texlive-fonts-extra: Please demote all additional Depends to Recommends)
Fabian Greffrath fab...@greffrath.com writes: Furthermore, AFAICT the additional font packages pulled in by texlive-fonts-extra contain fonts in TTF or OTF formats and are thus only useful for xetex and the like, not for standard plain pdflatex. One can use TTF with pdftex. Not that I know how it works, but I have been assured it does. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683943: luatex: fontconfig overridden by OSFONTDIR in default settings
Reuben Thomas r...@sc3d.org writes: On 19 August 2012 20:43, Frank Kuester fr...@kuesterei.ch wrote: As far as I read the text quoted above, OSFONTDIR is _not_ meant for this. It is meant to access fonts outside the TEXMF trees, and if an engine has a better way to achieve this, I don't see how this engine should require the variable to be unset. I would be very happy with this interpretation; I was trying, to see things from the implementors' point of view. In particular it seems logical to me that a TeX mechanism (OSFONTDIR kpathsea variable) should override a platform/build-specific mechanism (fontconfig). Why override? Why not simply add an other possibility? The behaviour I've described is how it currently works (or at least, seems to), ... in luatex... and that in itself is something not to change lightly. Definitely. As to how it is intended to work, given the lack of authoritative documentation, I can only suggest you consult the source code (for comments) or failing that its author(s)/maintainer(s). Since this seems to be something that affects many engines, I'd rather ask on the texlive or tex-k lists first. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683943: luatex: fontconfig overridden by OSFONTDIR in default settings
Reuben Thomas r...@sc3d.org writes: On 12 August 2012 11:31, Frank Kuester fr...@kuesterei.ch wrote: Anyway, what I am not sure about is what we should do about this. The documentation in texmf.cnf says: % OSFONTDIR is to provide a convenient hook for allowing TeX to find % fonts installed on the system (outside of TeX). An empty default % value would add // to the search paths, so we give it a dummy value. OSFONTDIR = /usr/share/fonts I am not sure whether luatex is correct in taking this as an alternative to fontconfig. As far as I can tell, that is what OSFONTDIR is for. As far as I read the text quoted above, OSFONTDIR is _not_ meant for this. It is meant to access fonts outside the TEXMF trees, and if an engine has a better way to achieve this, I don't see how this engine should require the variable to be unset. So, other than the behavior you describe, is there any other source for your assertion that OSFONTDIR is meant to tell an engine don't use fontconfig? Is it written anywhere? The mkluatexfontdb script, which presumably is trying to mimic the behaviour of luatex, also has this behaviour. That's not really an argument, since it's probably been written by people who are familiar with the current luatex behavior more than with what other engines do, did and should do. So it could be that we would need to have a OSFONTDIR.luatex variable instead that is empty? I don't think that would work, because an empty variable would make it search no paths (not the same as unsetting the variable, which as far as I can tell is impossible in kpathsea). I think you're right, you can't unset a variable in kpathsea. Which, to me, seems like one argument more why a program should never rely on a variable being unset... If that is correct, then OSFONTDIR should not be set, but per-engine versions should be set for whichever engines need it. As far as I can tell, the only engines not using fontconfig are tex and ptex. And do those other engines treat OSFONTDIR like luatex does it? I already wrote that I couldn't find any information on this in the luatex documentation, the same is true for the pdftex manual I now searched in. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684409: texlive-lang-french: missing dependencies for facture class
Gabriel Kerneis kern...@pps.jussieu.fr writes: the texlive-lang-french provides (among others) the facture class. To be used, this class requires the following packages: - texlive-xetex, for the xetex/xelatex binary - texlive-latex-extra, for makecmds.sty - etoolbox, for etoolbox.sty - texlive-generic-extra, for fltpoint.sty. I'm not sure whether these should be mandatory or only recommanded dependencies, but it would help a lot not having to look for them one by one. They are for sure not mandatory, since not everyone who installs texlive-lang-french wants to use the facture class. Unless you convince me that most or at least really many french TeX users use it, I think that even Recommends is too much. The question is rather whether we make it a Suggests - or nothing at all, because we usually take our dependency information from upstream, but they won't introduce the Suggests concept, I'm sure. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683943: luatex: fontconfig overridden by OSFONTDIR in default settings
Reuben Thomas r...@sc3d.org writes:
On 8 August 2012 20:53, Frank Kuester fr...@kuesterei.ch wrote:
Hm, I just installed luatex and texlive-base in a chroot and get:
root@riesling:/# kpsewhich --var-value=OSFONTSDIR
It's OSFONTDIR, not OSFONTSDIR.
I see, and must apologize. Was a bit in a hurry when I answered to your
two bug reports.
Anyway, what I am not sure about is what we should do about this. The
documentation in texmf.cnf says:
% OSFONTDIR is to provide a convenient hook for allowing TeX to find
% fonts installed on the system (outside of TeX). An empty default
% value would add // to the search paths, so we give it a dummy value.
OSFONTDIR = /usr/share/fonts
I am not sure whether luatex is correct in taking this as an alternative
to fontconfig. I also didn't find anything about OSFONTDIR in
luatexref-t.pdf or the Debian documentation. On the contrary,
http://wiki.contextgarden.net/Fonts_in_LuaTeX suggests to use this
variable.
The other question is which other engines use OSFONTDIR. Note that some
other variables reference it, and need the dummy setting for speed:
T1FONTS = .;$TEXMF/fonts/type1//;$OSFONTDIR//
AFMFONTS = .;$TEXMF/fonts/afm//;$OSFONTDIR//
TTFONTS = .;$TEXMF/fonts/{truetype,opentype}//;$OSFONTDIR//
OPENTYPEFONTS = .;$TEXMF/fonts/{opentype,truetype}//;$OSFONTDIR//
So it could be that we would need to have a OSFONTDIR.luatex variable
instead that is empty?
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683944: texlive: Please set TEXMFCNF by default
Reuben Thomas r...@sc3d.org writes:
On 8 August 2012 20:56, Frank Kuester fr...@kuesterei.ch wrote:
Reuben Thomas r...@sc3d.org writes:
root@riesling:/# grep TEXMFCNF /usr/share/texlive/texmf/web2c/texmf.cnf
%TEXMFCNF = {\
%TEXMFCNF =
{$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}{,{/share,}/texmf{-local,}/web2c}
TEXMFCNF =
/etc/texmf/web2c;/usr/share/texlive/texmf/web2c;/usr/share/texlive/texmf-dist/web2c;/usr/local/share/texmf/web2c
Yes, this is what I get.
Is this different on your system?
No, it's exactly the same. But you imply this shows no problem, so
perhaps I wasn't clear: the problem is that TEXMFCNF does NOT contain
~/.texmf-config/web2c by default.
Sorry, I was confused, but your wording was a bit unclear - you don't
want the variable to be set, but to be set differently. And you also
didn't say which type of configuration you mean:
% TEXMFCONFIG, where texconfig/updmap/fmtutil store configuration data.
TEXMFCONFIG = ~/.texmf-config
This is already catered for. What you probably mean is to have your own
per-user texmf.cnf, don't you?
In earlier days, this wouldn't work at all, anyway, but I guess it is
possible in TeXLive 2012. Back then, you would have to change each
variable in your environment.
I don't know, however, whether adding ~/.texmf-config to TEXMFNCF can
have undesired side effects, or rather that only parts of the settings
would work, as it was earlier. Norbert?
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683567: [tex-live] Bug#683567: texlive-pictures: Dependency error while using latex package adjustbox from this package
Hi Norbert, k...@freefriends.org (Karl Berry) writes: 1. I moved adjustbox to collection-latexextra. I guess we don't need to do anything about this, because as soon as we start developing for jessie you will update the orig.tar.gzs? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#373605: [latex-b...@latex-project.org] Re: babel/3875
notforwarded 373605
stop
---BeginMessage---
Synopsis: Problematic interaction of [french]{babel} with listings.sty
Responsible-Changed-From-To: johannes-javier
Responsible-Changed-By: gnats
Responsible-Changed-When: Wed, 08 Aug 2012 11:24:28 +0200
Responsible-Changed-Why:
Now maintaining babel.
State-Changed-From-To: open-closed
State-Changed-By: gnats
State-Changed-When: Wed, 08 Aug 2012 11:24:28 +0200
State-Changed-Why:
Not a babel bug. listing doesn't protect : (as babel does)
and fails if a lstlisting environment is open at a page break.
---End Message---
Bug#683567: texlive-pictures: Dependency error while using latex package adjustbox from this package
forwarded 683567 TeXLive Mailing List tex-l...@tug.org
stop
Dear TeX Live Team,
we got a report about a missing dependency between collections:
Saulo Soares de Toledo saulotol...@gmail.com writes:
Latex package adjustbox is inside texlive-pictures
While trying use \usepackage{adjustbox}, we receive the error
collectbox.sty not found. This happens because this file, required by
adjustbox, is at package texlive-latex-extra
texlive-pictures should depends of texlive-latex-extra then.
s/texlive/collection/g
Do you generally fix such issues, or would that result in a mess of
mutual and circular dependencies?
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683943: luatex: fontconfig overridden by OSFONTDIR in default settings
Reuben Thomas r...@sc3d.org writes: Package: texlive-luatex Version: 2012.20120611-3~ubuntu12.04.1 Severity: normal As far as I can tell, luatex uses fontconfig to find fonts if no OSFONTDIR is configured (at least, the binary is linked against libfontconfig!). OSFONTDIR is, however, set in the default configuration to /usr/share/fonts. Hm, I just installed luatex and texlive-base in a chroot and get: root@riesling:/# kpsewhich --var-value=OSFONTSDIR root@riesling:/# Also, root@riesling:/# grep OSFONTSDIR /etc/texmf/web2c/texmf.cnf root@riesling:/# Is this different on your system? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683944: texlive: Please set TEXMFCNF by default
Reuben Thomas r...@sc3d.org writes:
Package: texlive
Version: 2012.20120611-3~ubuntu12.04.1
Severity: wishlist
In order to make per-user settings for TeXLive, the user has to both
discover that they should be placed in ~/.texmf-config, and then set
an environment variable TEXMFCNF. Please consider setting this by
default:
Hm, I just installed luatex and texlive-base in a chroot and get:
root@riesling:/# kpsewhich --var-value=TEXMFCNF
/etc/texmf/web2c:/usr/share/texlive/texmf/web2c:/usr/share/texlive/texmf-dist/web2c:/usr/local/share/texmf/web2c
root@riesling:/#
Or could this be inherited from the (stable) host system? Also,
root@riesling:/# grep TEXMFCNF /usr/share/texlive/texmf/web2c/texmf.cnf
%TEXMFCNF = {\
%TEXMFCNF =
{$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}{,{/share,}/texmf{-local,}/web2c}
TEXMFCNF =
/etc/texmf/web2c;/usr/share/texlive/texmf/web2c;/usr/share/texlive/texmf-dist/web2c;/usr/local/share/texmf/web2c
root@riesling:/#
Is this different on your system? I am not sure, however, how the new
multiple-configuration-files mechanism in TeXLive 2012 works. Norbert?
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#273093: Unpredictable behavior when two packages want to divert the same file
Russ Allbery r...@debian.org writes: Jonathan Nieder jrnie...@gmail.com writes: To be clear, which of the following is this report proposing? * Packages should not divert a file unless that file is divertable. To make a file divertable, the maintainer of the package shipping it adds a comment to debian/control mentioning the filename and which packages are allowed to divert it. I don't think the bug report was asking for more formality around the coordination with the package maintainer part. I remember having opened the bug report, but not what was the real problem I had come across, nor my opinions on a solution. I don't think today that policy should require such a formalism. However, it is good practice to consult the maintainer of the diverted package. Therefore, in particular in team-maintained packages, I do think that a list I expect this and that file to be diverted, please ask before doing anything else somewhere in the debian directory might be a good idea. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659772: landscape sciposter + hyperref + latex + dvips = center-mirrored image
Heiko Oberdiek heiko.oberd...@googlemail.com writes: The PostScript language allows the setting of the page size: operator `setpagedevice', entry `PageSize', but entry `Orientation' is only intended for roll-fed media. Also there is no easy way to extract these data without a PostScript interpreter. At least there are DSC-comments that allows the specification of the page size and orientation. Thus there are several ways for specifying (partly also version dependent) and some will work on somewhere and others somewhere else. Even worse if the width is greater than the height. That seems to be the main problem here. In other words, this is neither a bug in one of the involved packages, nor in dvips. However, I fancy, it could be worked around if sciposter had some code for interaction with hyperref? Is this true? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#406526: Copyright file of texlive-bin is still problematic
Hi all, | texlive2012/texlive-bin/trunk$ head -10 debian/copyright | Copyright information for the texlive bundle | | Table of contents: | | 1. Copyright and License of the debian-specific adaptions | 2. License of the TeX live distribution as a compilation work | 3. LPPL | | | 1. Copyright and License of the debian-specific adaptions This is not sufficient, since we need to give the licenses of all the individual components. OTOH, I doubt that anything is under LPPL in texlive-bin. I'm pretty sure that we had better copyright files in earlier days, at least for tetex-bin, but most probably also for texlive-bin. Does anyone remember the history of changes? The current stable copyright file isn't better. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659772: landscape sciposter + hyperref + latex + dvips = center-mirrored image
reassign 659772 texlive-science
stop
jaa...@ro.ru writes:
1. Create a fresh file, say, q.tex, with the following contents:
\documentclass[landscape]{sciposter}
\usepackage{hyperref}
\begin{document}
abcABC
\end{document}
2. Run
latex q dvips -o q.ps q.dvi
3a. Run
gv q.ps
or
evince q.ps
Observe that the abcABC is center-mirrored in the right lower
corner. It should not be.
The whole page is turned, as you can see if you add a title or more
text.
3b. Run
xdvi q.dvi
or
evince q.dvi
Observe that the image is normal, not mirrored. So, most probably,
the error happens in dvips.
In addition, xdvi issues a ghostscript error message.
I would be grateful if anyone with more insight into the interplay
between sciposter, hyperref, latex, and dvips could repair this issue.
I'm pretty sure this is a problem of an incompatibility of sciposter and
hyperref. Since hyperref is more general, I'm reassigning this to
texlive-science which contains sciposter.
This does not at all mean this bug will be solved by the Debian
maintainers of TeXLive. This is clearly beyond what we can care for.
Please ask the author of sciposter, or ask on a general TeX Mailing
list.
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627171: texlive-binaries: mktexpk (and mktexnam) don't cope with unset $HOME
Dear Stuart, more than a year ago you reported this bug: Stuart Prescott stuart+deb...@nanonanonano.net writes: Some buildds now have $HOME unset and this leads to breakages in the compilation of various bits of documentation on the buildd; it may be a combination of reduced permissions on the buildd as well as $HOME being unset that causes font selection problems. [...] For reference, these logs come from the buildd failures of pyxplot 0.8.4-2 when building the documentation; while the documentation ends up in an arch:all package, building it also acts as a test suite. The complete logs are available at: https://buildd.debian.org/status/logs.php?pkg=pyxplotver=0.8.4-2 While this problem is clearly quite unlikely to ever hit a regular user of latex or pdflatex, it's a nuisance on the buildds (and quite hard to debug too), so better handling of this situation would be great. Unfortunately, we ignored this issue since than. Is it still a problem? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681061: lintian: False positive: unneeded-build-dep-on-quilt
Package: lintian Version: 2.5.10 Severity: normal In source package texlive-bin, the error tag unneeded-build-dep-on-quilt is found by quilt. However, we do use quilt in debian/rules: $ grep -i quilt debian/rules # this is for dh_quilt_patch (--with quilt) which reads this # variable and sets QUILT_PATCHES accordingly export QUILT_PATCH_DIR=debian/quilt export QUILT_PATCHES=debian/quilt dh $@ --with quilt --with autoreconf --builddirectory Work dh_quilt_unpatch Regards, Frank -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.20.1-16 The GNU assembler, linker and bina ii diffstat 1.53-1produces graph of changes introduc ii dpkg-dev 1.15.8.12 Debian package development tools ii file 5.04-5+squeeze2 Determines file type using magic ii gettext0.18.1.1-3GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libipc-run-perl0.89-1Perl module for running processes ii libparse-debianchangel 1.1.1-2.1 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.54-2module to manipulate and access UR ii locales2.11.3-3 Embedded GNU C Library: National L ii man-db 2.5.7-8 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-17squeeze3 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.7-8on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483217: texlive-latex-base: 483217: status?
Hilmar Preusse hill...@web.de writes: On 29.06.12 Arne Wichmann (a...@anhrefn.saar.de) wrote: begin quotation from Norbert Preining (in 20120627143050.ge25...@gamma.logic.tuwien.ac.at): On Mi, 27 Jun 2012, Arne Wichmann wrote: Hi, Given that, the relevant files should be removed from debian, as they are not DFSG-free. Am I wrong there? Yes you are. Could you please enlighten me about my misunderstanding? Please keep in mind that a few of the to be removed files are essential parts of a basic (La)TeX installation, i.e. we can't remove them w/o getting another set of bugs why is file xyz.sty gone? Moreover, nobody actually believes that Donald ever had the intention to make these files non-free. These statements are just very old and written at a time were people didn't care about license details. We do care now, but Donald doesn't care enough to spend time on that. I'm not sure, though, that the system would break without those files. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679942: Needs to be updated for emacs24
forcemerge 679942 679712 thanks Juhapekka Tolvanen juht...@iki.fi writes: Package: auctex Version: 11.86-10 Severity: normal Wishlist. I just installed emacs24. It seems good enough so I'd like to deinstall emacs23, but I can not do it, because auctex package has erroneous Depends: -field: emacs23. It's not erroneous, because as it is currently packaged for Debian, the maintainer scripts need to know each emacsen flavor they should check for. I think, however, that a more automatic packaging would be nice. And I think current upstream auctex does find all emacsen in the path. Maybe you can just use this mechanism, Davide? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674888: /usr/share/texlive/texmf-dist/bibtex/bst/sort-by-letters/frplainnat- letters.bst: Unknown keywords used in frplainnat-letters.bst
Norbert Preining prein...@logic.at writes: Dear Thomas, as written in the information message of reportbug (if you used it), this mailing list is not a LaTeX Help Desk. We see your bug, but we have no capacity to react on it. We see our main responisibility an packaging TeX Live. So your options are: - reporting this to upstream TeX Live mailing list you will get the same answer, namely to contact upstream the original authors, because the README file is what is shipped on CTAN - contact the up-upstream author, i.e., the author of the original package. If he uploads a fixed version it will find its way into TeX Live and eventually into Debian. - ask on general LaTeX user lists or newsgroups Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674090: texlive-binaries: updmap cannot find TLUtils.pm
Sanjoy Mahajan san...@olin.edu writes:
However, when I try to install the newest version, I get:
# aptitude install texlive-base/unstable
The following packages will be upgraded:
texlive-base{b} [2011.20120424-1 - 2012.20120516-1]
The following partially installed packages will be configured:
maxima-doc maxima-emacs maxima-share tex-common texlive-binaries
1 packages upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
Need to get 14.2 MB of archives. After unpacking 374 kB will be freed.
The following packages have unmet dependencies:
texlive-base : Depends: texlive-common (= 2012.20120516-1) but
2011.20120424-1 is installed.
Depends: texlive-doc-base (= 2012.20120516) but
2011.20120424-1 is installed.
try
aptitude install texlive-base/unstable texlive-common/unstable
texlive-doc-base/unstable
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673022: texlive-base: cannot upgrade to 2011.20120509-1
Norbert Preining prein...@logic.at writes:
Only two quick answers
The only clear text in that garbled output is $DebCnfFile. This string
occurse in /usr/share/texlive-bin/debianize-fmtutil, which is sourced by
fmtutil. AFAIS it should only be called when the argument to fmtutil
isn't --all, but --enable Map.
Huuu? fmtutil does not understand map!
--enablefmt, of course
exec fmtutil ${1+$@}
exec sh -x /usr/bin/fmtutil ${1+$@}
AFAIU it happens only on upgrade ... so that does not help.
If I remember correctly, the upgrade was not yet successful. When trying
again (aptitude safe-upgrade, dpkg --configure or whatever), this should
give more output.
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673022: texlive-base: cannot upgrade to 2011.20120509-1
Yves-Alexis Perez cor...@debian.org writes:
So it did happen again for 2012.20120516-1, same symptoms. I tried to
upgrades, and each time the failing is for different commands again
(/tmp files attached) so my guess is that, like before, it'll end up
with a success, when it'll have âÂÂfailedâ all the stuff it needs to
do
(it doesn't seem to retry to do them at the next run).
Output of fmtutil-sys --all attached too.
fmtutil: running `mf-nowin -ini -jobname=mf -progname=mf
-translate-file=cp227.tcx mf.ini' ...
øÃâÃ
PÂXPÂX$DebCnfFile
verøÃâÃ
PÂXPÂX
The only clear text in that garbled output is $DebCnfFile. This string
occurse in /usr/share/texlive-bin/debianize-fmtutil, which is sourced by
fmtutil. AFAIS it should only be called when the argument to fmtutil
isn't --all, but --enable Map. However, this /might/ point to a real
bug in our scripts: Have the mechanisms for fmt.d also changed, i.e. is
a stacked approach used there, too? Then, maybe, the code to find the
right config file for --enable Map is buggy.
However, this shouldn't be relevant here. I didn't really check the
code, though.
Could you maybe edit /usr/bin/fmtutil-sys and do the following change:
exec fmtutil ${1+$@}
exec sh -x /usr/bin/fmtutil ${1+$@}
and try again?
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673022: texlive-base: cannot upgrade to 2011.20120509-1
[resending since the message with non-printable characters was rejected]
Yves-Alexis Perez cor...@debian.org writes:
So it did happen again for 2012.20120516-1, same symptoms. I tried to
upgrades, and each time the failing is for different commands again
(/tmp files attached) so my guess is that, like before, it'll end up
with a success, when it'll have “failed” all the stuff it needs to do
(it doesn't seem to retry to do them at the next run).
Output of fmtutil-sys --all attached too.
fmtutil: running `mf-nowin -ini -jobname=mf -progname=mf
-translate-file=cp227.tcx mf.ini' ...
[stuff removed]$DebCnfFile
The only clear text in that garbled output is $DebCnfFile. This string
occurse in /usr/share/texlive-bin/debianize-fmtutil, which is sourced by
fmtutil. AFAIS it should only be called when the argument to fmtutil
isn't --all, but --enable Map. However, this /might/ point to a real
bug in our scripts: Have the mechanisms for fmt.d also changed, i.e. is
a stacked approach used there, too? Then, maybe, the code to find the
right config file for --enable Map is buggy.
However, this shouldn't be relevant here. I didn't really check the
code, though.
Could you maybe edit /usr/bin/fmtutil-sys and do the following change:
exec fmtutil ${1+$@}
exec sh -x /usr/bin/fmtutil ${1+$@}
and try again?
Regards, Frank
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672876: texlive-binaries: updmap always fails
Norbert Preining prein...@logic.at writes: # updmap --syncwithtrees YOu should never do that on Debian ... .never ... There used to be a patch that disabled that action. Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
