Bug#329189: tetex-base: dvips -Poutline not using .pfb fonts
Thanks for the detailed info.
Arne Ahrend <ahrend@gmx.de> wrote:
> 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).
Yes.
> Replacing the PIDs (10453 and 28306) in the updmap STDERR logs I
> provided last night with XXXXX the diff shrinks down to
Good idea.
> --- 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
> --rw-r--r-- 1 root root 33657 2005-10-08 00:28 psfonts_t1.map
[...]
> +-rw-r--r-- 1 root root 33657 2005-10-08 00:56 psfonts_t1.map
It seems you got the same files here. Previously, your successful setup
generated a bigger psfonts_t1.map (46 Ko or so). Are you sure you diffed
the right files?
> 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.
I think the different order has nothing do to with how you called
updmap. If you look closely at the two places where you had different
orders between the two runs, you'll see that every time, the commands
whose order is swapped are elements of a pipeline. They are not started
exactly at the same time, but run simultaneously afterwards.
>> 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.
Ah, but you forgot to pass 'configure' as the first parameter to
tetex-extra.postinst. Without it, updmap is not run and it is no wonder
why this doesn't fix anything.
> /usr/bin/which updmap gives
> /usr/bin/updmap
Good.
> Output of apt-get install tetex-extra:
> ======================================
[...]
> Running fmtutil succeeded.
> Updmap found in PATH: /usr/bin/updmap
Good.
> Running updmap. This may take some time. ...
> Running updmap succeeded.
OK.
> 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.
Yes (but so strange that I still doubt it can be true!). I just wanted
to be really sure it wasn't a PATH issue. :-)
> 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.)
OK.
--
Florent
Reply to: