On Sat, 08 Oct 2005 14:43:01 +0200
Florent Rougon <[EMAIL PROTECTED]> wrote:
> Let me make sure I understand what you are saying:
>
> Simply changing the line 'if updmap 2> $tempfile; then' into
> 'if /bin/sh /usr/bin/updmap 2> $tempfile; then' in
> tetex-extra.postinst and running 'tetex-extra.postinst configure'
> gives you a different (more complete) psfonts_t1.map than running that
> command without the change?
Yes.
Well, I did not run 'tetex-extra.postinst configure' separately, but
at Franks suggestion plunged in a modfied postinst script[1] to apt-get install.
I have the impression that I should no longer call this a "tetex bug". Calling
an executable shell script FILE starting with #!/bin/sh should be equivalent to
calling
/bin/sh FILE (and afaIk the latter is exactly what the kernel does in this
case).
By the way, my i386 installation also shows the bug, and a manual run of updmap
helps there, too.
(I must unknowingly have repaired the psfonts_t1.map file by an updmap call
over the years.)
Replacing the PIDs (10453 and 28306) in the updmap STDERR logs I provided last
night with XXXXX the diff
shrinks down to
--- tetex-extra.updmap.err 2005-10-08 17:21:28.000000000 +0200
+++ tetex-extra.updmap.err-with-x-in-updmap 2005-10-08 17:22:08.000000000
+0200
@@ -87,9 +87,9 @@
++ tail -1
+ dvipsPreferOutline=true
++ cfgval dvipsDownloadBase35
+++ cat /var/lib/texmf/web2c/updmap.cfg
++ sed -n 's/^dvipsDownloadBase35[ =][ =]*//p'
++ tail -1
-++ cat /var/lib/texmf/web2c/updmap.cfg
+ dvipsDownloadBase35=false
++ cfgval pdftexDownloadBase14
++ cat /var/lib/texmf/web2c/updmap.cfg
@@ -749,9 +749,9 @@
+ transLW35 /usr/share/texmf/dvips/tetex/pdftex35.map
+ case $mode in
+ cat /usr/share/texmf/dvips/tetex/pdftex35.map
-+ cat /tmp/updmap.XXXXX/a /tmp/updmap.XXXXX/b
+ egrep -v '(^%|PaintType)'
+ grep .
++ cat /tmp/updmap.XXXXX/a /tmp/updmap.XXXXX/b
+ transLW35 /usr/share/texmf/dvips/tetex/dvipdfm35.map
+ case $mode in
+ cat /usr/share/texmf/dvips/tetex/dvipdfm35.map
@@ -832,18 +832,18 @@
+ true
+ cd /var/lib/texmf/dvips/config
+ ls -l dvipdfm.map dvipdfm_dl14.map dvipdfm_ndl14.map pdftex.map
pdftex_dl14.map pdftex_ndl14.map ps2pk.map psfonts.map psfonts_pk.map
psfonts_t1.map builtin35.map download35.map
--rw-r--r-- 1 root root 8985 2005-10-08 00:28 builtin35.map
--rw-r--r-- 1 root root 13102 2005-10-08 00:28 download35.map
--rw-r--r-- 1 root root 10500 2005-10-08 00:28 dvipdfm_dl14.map
-lrwxrwxrwx 1 root root 17 2005-10-08 00:28 dvipdfm.map -> dvipdfm_ndl14.map
--rw-r--r-- 1 root root 11127 2005-10-08 00:28 dvipdfm_ndl14.map
--rw-r--r-- 1 root root 36801 2005-10-08 00:28 pdftex_dl14.map
-lrwxrwxrwx 1 root root 16 2005-10-08 00:28 pdftex.map -> pdftex_ndl14.map
--rw-r--r-- 1 root root 35227 2005-10-08 00:28 pdftex_ndl14.map
--rw-r--r-- 1 root root 37768 2005-10-08 00:28 ps2pk.map
-lrwxrwxrwx 1 root root 14 2005-10-08 00:28 psfonts.map -> psfonts_t1.map
--rw-r--r-- 1 root root 25532 2005-10-08 00:28 psfonts_pk.map
--rw-r--r-- 1 root root 33657 2005-10-08 00:28 psfonts_t1.map
+-rw-r--r-- 1 root root 8985 2005-10-08 00:56 builtin35.map
+-rw-r--r-- 1 root root 13102 2005-10-08 00:56 download35.map
+-rw-r--r-- 1 root root 10500 2005-10-08 00:56 dvipdfm_dl14.map
+lrwxrwxrwx 1 root root 17 2005-10-08 00:56 dvipdfm.map -> dvipdfm_ndl14.map
+-rw-r--r-- 1 root root 11127 2005-10-08 00:56 dvipdfm_ndl14.map
+-rw-r--r-- 1 root root 36801 2005-10-08 00:56 pdftex_dl14.map
+lrwxrwxrwx 1 root root 16 2005-10-08 00:56 pdftex.map -> pdftex_ndl14.map
+-rw-r--r-- 1 root root 35227 2005-10-08 00:56 pdftex_ndl14.map
+-rw-r--r-- 1 root root 37768 2005-10-08 00:56 ps2pk.map
+lrwxrwxrwx 1 root root 14 2005-10-08 00:56 psfonts.map -> psfonts_t1.map
+-rw-r--r-- 1 root root 25532 2005-10-08 00:56 psfonts_pk.map
+-rw-r--r-- 1 root root 33657 2005-10-08 00:56 psfonts_t1.map
+ verboseMsg
+ true
+ echo
I assume these are the essential differences between /bin/sh -x /usr/bin/updmap
and updmap (modified to have -x on line one in /usr/bin/updmap), the different
invocations apparently cause certain cat commands to move by a few lines.
> If so, presumably both ways run a different updmap program. Quite
> strange, but if only this change does what you say, I cannot see any
> other cause (this is very surprising because the first thing
> tetex-extra.postinst does is set a sane PATH; it doesn't export it,
> though, but that cannot explain why the 'updmap' and
> '/bin/sh /usr/bin/updmap' calls give different results here).
I added -x to the first line of /usr/bin/updmap to get verbose mode and
reproduce the bug at the same time, so it was _that_ updmap and no other.
But I have retested it with an
echo "Updmap found in PATH: $(/usr/bin/which updmap)"
line in postinst and got confirmation, see below.
> 2. Check whether running the 'tetex-extra.postinst configure' in
> either setup several times in a row always gives the same result.
After reproducing the bug several invocations of
sh -x /var/lib/dpkg/info/tetex-extra.postinst >
/tmp/tetex-extra-postinst.lg 2>&1
do not repair it.
> 3. Tell us what you obtain from '/usr/bin/which updmap' (as root).
> Check also in the script: insert
>
> echo "Updmap found: $(/usr/bin/which updmap)"
>
> just before the if...fi block that calls updmap.
/usr/bin/which updmap gives
/usr/bin/updmap
Output of apt-get install tetex-extra:
======================================
Reading Package Lists...
Building Dependency Tree...
The following NEW packages will be installed:
tetex-extra
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0B/10.5MB of archives.
After unpacking 40.1MB of additional disk space will be used.
USING /root/control-overrides/tetex-extra_2.0.2c-8_all.deb/
Selecting previously deselected package tetex-extra.
(Reading database ... 60532 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 fmtutil succeeded.
Updmap found in PATH: /usr/bin/updmap
Running updmap. This may take some time. ...
Running updmap succeeded.
> 4. Try the failing case with 'export PATH=...' instead of 'PATH=...',
> to see if it works better (this will affect PATH searching in
> updmap itself and in the other programs run from the postinst
> script).
Exporting the PATH in postint and/or in /usr/bin/updmap does not change
behaviour.
And we know that invoking updmap as /bin/sh /usr/bin/updmap works around the
bug.
> 5. Tell us what 'ls -l /bin/sh' says.
lrwxrwxrwx 1 root root 4 2005-09-18 14:56 /bin/sh -> bash
I have also changed the link to dash, but that had no impact; everything seems
to work as
always with dash as well and it reproduced the bug. Same goes for replacing the
link with a copy
of bash. (I have of course changed it back to a link to bash afterwards.)
Kind regards,
Arne
[1] http://lists.debian.org/debian-devel/2004/05/msg00944.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
