Re: xfig can't find fonts
* Steve Langasek [Fri, 09 Jun 2006 03:21:01 -0700]:
Hey, Steve.
> tags 366948 -fixed
> thanks
> This bug isn't actually fixed. The NMUed gsfonts-x11 package does run the
> correct update commands for the new directory, but the reason gsfonts-x11 is
> breaking people's fonts is that it's failing to clean up after itself in the
> *old* directory -- leaving a fonts.dir file in place referring to
> non-existent fonts and generally making a mess of the font path.
Okay, I spent a while to dig out what's happening, since I wasn't really
familiar with all the xfonts-utils and debhelper saga, but now I have a
pretty clear idea of where the bug is, or so I think. :)
In any case:
- gsfonts-x11 (both 0.19 and 0.19.0.1) effectively leaves behind in
/usr/lib/X11/fonts/Type1/fonts.{scale,dir}. I haven't had the time
to see if this is what effectively was making xfig fail, but I can
believe so, and in any case these leftovers constitute a bug, yes.
- Steve, despite you talk about horribly broken maintainer scripts in
gsfonts-x11, I fail to see anything wrong with them. preinst is the
most scary of them, but only acts in versions <= 0.7, and as for
postinst and postrm, they just contain the dh_installxfonts snippet.
- that gsfonts-x11 leaves stuff in X11R6/fonts.dir is consistent with
the changes introduced in #364530: update-fonts-dir only acts in one
directory at a time (checked as well with another package, xfonts-jmk
maintained by Russ Albery). However, changes from #364530 _did_
change update-fonts-scale to act on both X11R6/$1 and X11R7/$1, so
leaving stuff in X11R6/fonts.alias smells fishy.
And, as it happens (or at least, as it happened on tests I did on my
system), update-fonts-scale fails to update the fonts.alias file in
directories that have become _empty_. See the two attached patches
to see how does this happen; either of them (or similar) should be
applied to the xfonts-utils package.
> It looks like this also needs a separate bug on dh_installxfonts, which
> fails to handle this possibility in its current maintainer script snippets;
> but it still requires gsfonts-x11 to clean up after what the old version of
> the package may have left behind.
- the issue for fonts.dir is still unresolved, indeed. Either
dh_installxfonts is changed to invoke update-fonts-dir not only once,
but twice (once with --x11r7-layout and one without), or to change
update-fonts-dir to act like update-fonts-scale. Since it was decided
not to do the latter, and I ignore the reasons for that, I won't
give an opinion about this.
I propose the following snnippet to be sent to control@:
clone 366948 -1
reassign -1 xfonts-utils 1:1.0.0-4
retitle -1 update-scale-fonts: fails on empty dirs
tags -1 = patch
tag 366948 + fixed
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Presuntos Implicados - Hazme la noche
--- update-fonts-scal
+++ update-fonts-scale-1
@@ -147,6 +147,7 @@
if [ -z "$XDIR" ] || ! [ -d "$XDIR" ]; then
continue
fi
+ true >"$XDIR/fonts.scale.update-tmp"
for SCALEFILE in "$ETCDIR"/*.scale "$ETC7DIR"/*.scale; do
[ -e "$SCALEFILE" ] || continue
# Only write fonts to the .scale file that actually exist, so
--- update-fonts-scale
+++ update-fonts-scale-2
@@ -176,6 +176,10 @@
>>"$XDIR/fonts.scale.update-new"
mv "$XDIR/fonts.scale.update-new" "$XDIR/fonts.scale"
rm "$XDIR/fonts.scale.update-tmp"
+ else
+ # No font in the processed *.scale file was in the current
+ # directory, so remove fonts.scale.
+ rm -f "$XDIR/fonts.scale"
fi
done
else
Reply to: