Bug 921706 - ghostscript: /invalidfont in /findfont, --nostringval-- Helvetica
ghostscript: /invalidfont in /findfont, --nostringval-- Helvetica
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fontconfig (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: ZedoraTracker 919935
  Show dependency treegraph
 
Reported: 2013-03-14 13:57 EDT by Rex Dieter
Modified: 2014-07-25 06:05 EDT (History)
18 users (show)

See Also:
Fixed In Version: fontconfig-2.10.93-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-10 22:04:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace output (369.83 KB, text/plain)
2013-09-18 04:51 EDT, Dan Horák
no flags Details
snip from /var/log/cups/error_log (15.62 KB, text/plain)
2014-07-04 05:07 EDT, Hankenstein
no flags Details

  None (edit)
Description Rex Dieter 2013-03-14 13:57:33 EDT
Working on enblend FTBFS on rawhide,
https://koji.fedoraproject.org/koji/taskinfo?taskID=5122547

According to root.log:
ghostscript-9.06-7.fc19

and pdf generation via fig2dev is failing

Shouldn't some Helvetica font or alias always work?

------------------------------------------

make pdf MAKEINFO=/bin/true
fig2dev -L pdf photographic-workflow.fig photographic-workflow.pdf
Error: /invalidfont in /findfont
Operand stack:
   --nostringval--   Helvetica
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1894   1   3   %oparray_pop   1893   1   3   %oparray_pop   --nostringval--   1877   1   3   %oparray_pop   1771   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1852   2   4   %oparray_pop
Dictionary stack:
   --dict:1167/1684(ro)(G)--   --dict:0/20(G)--   --dict:113/200(L)--   --dict:36/200(L)--
Current allocation mode is local
Last OS error: Not a directory
GPL Ghostscript 9.06: Unrecoverable error, exit code 1
Comment 1 Rex Dieter 2013-03-14 16:25:31 EDT
More,
http://koji.fedoraproject.org/koji/getfile?taskID=5123051&name=build.log


/usr/bin/gnuplot laplacian-of-gaussian.gp
Error: /invalidfont in /findfont
Operand stack:
   Symbol-Oblique   Symbol
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1894   1   3   %oparray_pop   1893   1   3   %oparray_pop   --nostringval--   1877   1   3   %oparray_pop   1771   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1852   2   4   %oparray_pop
Dictionary stack:
   --dict:1166/1684(ro)(G)--   --dict:0/20(G)--   --dict:82/200(L)--   --dict:175/256(L)--
Current allocation mode is local
Last OS error: Not a directory
GPL Ghostscript 9.06: Unrecoverable error, exit code 1
Comment 2 Tim Waugh 2013-03-15 13:20:15 EDT
Yes, it should always have "Helvetica" available: ghostscript requires fontconfig, which provides configuration to alias Helvetica to one of the urw-fonts we do have, and ghostscript also requires urw-fonts.

However, it works fine for me locally:

[tim@localhost ~]$ gs -sDEVICE=nullpage -dBATCH -c '(Helvetica) findfont'
GPL Ghostscript 9.06 (2012-08-08)
Copyright (C) 2012 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Can't find (or can't open) font file /usr/share/ghostscript/9.06/Resource/Font/NimbusSanL-Regu.
Can't find (or can't open) font file NimbusSanL-Regu.
Can't find (or can't open) font file /usr/share/ghostscript/9.06/Resource/Font/NimbusSanL-Regu.
Can't find (or can't open) font file NimbusSanL-Regu.
Querying operating system for font files...
Loading NimbusSanL-Regu font from /usr/share/fonts/default/Type1/n019003l.pfb... 3531264 2179962 2945236 1487296 1 done.
[tim@localhost ~]$ rpm -q ghostscript urw-fonts fontconfig
ghostscript-9.06-7.fc19.x86_64
urw-fonts-2.4-14.fc19.noarch
fontconfig-2.10.91-3.fc19.x86_64

and in any case, the problem isn't that it can't find it: that should simply substitute "Courier" (which is the same actual font) for fonts that it can't find:

Can't find (or can't open) font file foo.
Didn't find this font on the system!
Substituting font Courier for foo.
Loading NimbusMonL-Regu font from /usr/share/fonts/default/Type1/n022003l.pfb... 3553160 2190997 4512296 3128920 1 done.
Comment 3 Rex Dieter 2013-03-25 12:42:40 EDT
Well, hard to say, as you can see, is it not clearly failing in koji (for whatever reason)?
Comment 4 Tom "spot" Callaway 2013-04-25 15:53:41 EDT
This is preventing nightview from building as well.
Comment 6 Tim Waugh 2013-04-26 10:35:12 EDT
I think this might be fixed now?  I just tried a scratch build and it was fine:

http://kojipkgs.fedoraproject.org//work/tasks/4768/5304768/build.log
Comment 7 Tim Waugh 2013-04-26 10:42:13 EDT
Oh, the i686 arch failed this time. :-(
Comment 8 Tim Waugh 2013-04-26 11:06:07 EDT
Hmm, but this scratch build completed fine on all arches:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5304858

I think whatever problem there is/was must be something to do with the build roots.
Comment 9 Tom "spot" Callaway 2013-04-26 12:44:38 EDT
Nope, looks like it is still there:

http://kojipkgs.fedoraproject.org//work/tasks/5259/5305259/build.log
Comment 10 Tim Waugh 2013-04-29 05:45:56 EDT
There's no ghostscript bug here.  It might be urw-fonts possibly?  The error indicates the font is actually missing on the filesystem.  Otherwise it's a task for rel-eng I think.
Comment 11 Jerry James 2013-04-30 14:26:24 EDT
I just tracked a cvc4 build error down to this bug (although it is "Times-Roman" this time, instead of "Helvetica".)  There seems to be a race condition somewhere, as I sometimes get good builds in mock, and sometimes get this failure.  I've kept one good and one bad mock buildroot around for comparison.  Here is what I know:

1. The installed packages are identical in the two cases: same versions, etc.
2. On the successful builds, ghostscript reads the urw-fonts files and does its work.  On the failed builds, ghostscript never reads any urw-fonts file.
3. On the failed builds, at the step where the good builds read a urw-fonts file, the failed build instead tries (and fails) to find files named NimbusRomNo9L-Regu and NimbusMonL-Regu.  It looks all over the filesystem for those 2 files before throwing an /invalidfont error.
4. The contents of /usr/share/fontconfig, /usr/share/fonts, and /etc/fonts are identical in the two cases.
5. The string "/usr/share/fonts/default/Type1" appears in 2 files in /var/cache/fontconfig in the successful build, but appears in 0 files in the failed build.

Which leads me to suspect that something in the urw-fonts %post script can fail sometimes, but since it is written like this:

{
   umask 133
   mkfontscale /usr/share/fonts/default/Type1 || :
   `which mkfontdir` /usr/share/fonts/default/Type1 || :
   fc-cache /usr/share/fonts
} &> /dev/null || :

any such failure is sent to /dev/null, and doesn't cause RPM to complain, so I have no way of knowing.  As a test, I reran each of those commands by hand in the failed buildroot, removed the contents of /var/cache/fontconfig, and reran the fig2dev command.  It worked then.
Comment 12 Jerry James 2013-05-01 10:05:05 EDT
The spec file does not have "Requires(post): which".  Is there any possibility that, in a mock build, urw-fonts is installed before which?  If so, that could cause the failure.

But the use of which is nonsensical anyway.  It's going to return the mkfontdir it finds on $PATH.  But since it is on $PATH, you can just say:

mkfontdir /usr/share/fonts/default/Type1
Comment 13 Tom "spot" Callaway 2013-05-02 12:32:00 EDT
I don't think it is an ordering issue with "which" and urw-fonts. I can see which getting installed in the "base" transaction, before it does the second pass to install the BuildRequires.

Whatever the issue is, it seems to be very... random. An f19 build of nightview succeeded, but not yet in rawhide. :/
Comment 14 Tom "spot" Callaway 2013-05-02 13:14:14 EDT
... and the rawhide build just succeeded. I got nothing.
Comment 15 Jerry James 2013-05-02 13:50:28 EDT
Rawhide build of cvc3 just worked, too.  Either the actual cause of this bug went away on its own very recently, or something funny is going on with "which" in Rawhide.

Do we need the urw-fonts change for F-19, too?
Comment 16 Jerry James 2013-05-02 14:13:46 EDT
There's a 3rd possibility of course: we both got lucky on our Rawhide builds and the real bug is still lurking.

Spot, can you push your change to F-19, though, so we can see if that helps?  The F-19 cvc3 build just failed:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5325941
Comment 17 Ngo Than 2013-05-06 09:26:28 EDT
it's built http://koji.fedoraproject.org/koji/taskinfo?taskID=5334931

this build includes tom's patch.
Comment 18 Fedora Update System 2013-05-06 09:58:50 EDT
urw-fonts-2.4-15.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/urw-fonts-2.4-15.fc19
Comment 19 Fedora Update System 2013-05-06 14:32:15 EDT
Package urw-fonts-2.4-15.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing urw-fonts-2.4-15.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7495/urw-fonts-2.4-15.fc19
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2013-05-14 00:50:50 EDT
urw-fonts-2.4-15.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Jerry James 2013-08-30 13:35:32 EDT
(In reply to Jerry James from comment #16)
> There's a 3rd possibility of course: we both got lucky on our Rawhide builds
> and the real bug is still lurking.

That appears to have been the case.  I'm getting this same failure with the clisp package and Times-Italic.  Once again, removing everything in /var/cache/fontconfig and executing the urw-fonts %post script line by line results in ps2pdf working normally in the build root.  When I first entered the build root, there were 4 cache files in /var/cache/fontconfig.  After rerunning the fc-cache line, there are 5 cache files: the same 4 as before, plus this one:

b79f3aaa7d385a141ab53ec885cc22a8-le64.cache-4

And sure enough, that is the only one of the 5 that has urw-fonts names in it.

I admire all of the effort that was put into hiding errors that occur in the %post script, but that effort unfortunately throws away the information needed to figure out what is going on here.  Could that be undone, please?
Comment 22 Mario Blättermann 2013-09-04 15:21:02 EDT
Yes, the problem still persists. While attempting to build libpostscriptbarcode (bug #1003280) from source instead of taking a monolithic package, I get the following error message:

GPL Ghostscript 9.07: Unrecoverable error, exit code 1
Error: /undefinedfilename in --.findfont--
Operand stack:
   Helvetica   18   Helvetica   Font   Helvetica   4173399   Helvetica   --nostringval--   Helvetica   NimbusSanL-Regu   (/usr/share/ghostscript/9.07/Resource/Font/NimbusSanL-Regu)   (/usr/share/ghostscript/9.07/Resource/Font/NimbusSanL-Regu)   (r)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1884   1   3   %oparray_pop   1883   1   3   %oparray_pop   1867   1   3   %oparray_pop   1755   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1789   2   5   %oparray_pop   --nostringval--   false   1   %stopped_push   --nostringval--   1836   3   5   %oparray_pop   --nostringval--   false   1   %stopped_push   1829   4   5   %oparray_pop   findresource   %errorexec_pop   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1778   7   6   %oparray_pop   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %loop_continue   --nostringval--   --nostringval--   false   1   %stopped_push
Dictionary stack:
   --dict:1173/1684(ro)(G)--   --dict:0/20(G)--   --dict:82/200(L)--   --dict:24/24(ro)(L)--   --dict:82/200(L)--   --dict:20/27(ro)(G)--   --dict:1173/1684(ro)(G)--
Current allocation mode is local
Current file position is 40427
GS error at build/make_packaged_resource line 58.
make: *** [build/packaged_resource/Resource/Category/uk.co.terryburton.bwipp] Error 1
Comment 23 Fedora End Of Life 2013-09-16 12:38:39 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 24 Dan Horák 2013-09-18 04:47:28 EDT
(In reply to Mario Blättermann from comment #22)
> Yes, the problem still persists. While attempting to build
> libpostscriptbarcode (bug #1003280) from source instead of taking a
> monolithic package, I get the following error message:

Mario, your GS traceback looks a different, so it could be a different problem.
Comment 25 Dan Horák 2013-09-18 04:48:59 EDT
Currently I have couple of packages that fail to build on s390(x) because of this problem, eg. sendmail fails with

...
~/build/BUILD/sendmail-8.14.7
+ popd
+ make -C doc/op op.pdf
make: Entering directory `/builddir/build/BUILD/sendmail-8.14.7/doc/op'
rm -f op.pdf
ps2pdf op.ps op.pdf
Error: /invalidfont in /findfont
Operand stack:
   Times-Italic@0   --nostringval--   Times-Italic
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1884   1   3   %oparray_pop   1883   1   3   %oparray_pop   1867   1   3   %oparray_pop   1755   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   1836   3   4   %oparray_pop
Dictionary stack:
   --dict:1167/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--   --dict:59/120(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 5612
GPL Ghostscript 9.07: Unrecoverable error, exit code 1
make: Leaving directory `/builddir/build/BUILD/sendmail-8.14.7/doc/op'
make: *** [op.pdf] Error 1
Comment 26 Dan Horák 2013-09-18 04:51:15 EDT
Created attachment 799208 [details]
strace output

versions are:
urw-fonts-2.4-17.fc20.noarch
ghostscript-9.07-12.fc20.s390
Comment 27 Dan Horák 2013-10-03 05:49:26 EDT
Tim, could you look at this once more, please? Seems I can easily reproduce it.
Comment 28 Tim Waugh 2013-10-03 07:10:28 EDT
(In reply to Mario Blättermann from comment #22)
> Yes, the problem still persists. While attempting to build
> libpostscriptbarcode (bug #1003280) from source instead of taking a
> monolithic package, I get the following error message:
> 
> GPL Ghostscript 9.07: Unrecoverable error, exit code 1
> Error: /undefinedfilename in --.findfont--

This is a different problem: /undefinedfilename is quite different to /invalidfont.
Comment 29 Tim Waugh 2013-10-03 07:11:42 EDT
(In reply to Dan Horák from comment #27)
> Tim, could you look at this once more, please? Seems I can easily reproduce
> it.

If you follow the steps in comment #21, does the problem go away?
Comment 30 Dan Horák 2013-10-03 08:41:53 EDT
(In reply to Tim Waugh from comment #29)
> (In reply to Dan Horák from comment #27)
> > Tim, could you look at this once more, please? Seems I can easily reproduce
> > it.
> 
> If you follow the steps in comment #21, does the problem go away?

yes, rerunning the %post scriptlet removes the traceback and build completes

Is it possible to disable the fontcache feature via eg. environment variable? Or is there other way how to fix the installation ordering?
Comment 31 Dan Horák 2013-10-03 08:43:44 EDT
or should %posttrans scriptlet be used instead?
Comment 32 Tim Waugh 2013-10-16 10:15:28 EDT
I'm pretty sure, having seen this first-hand now, the issue is that fc-cache is not scanning the new /usr/share/fonts/default/Type1 directory after installation because it mistakenly thinks its cache is up to date.

In other words, the problem needs to be fixed in fc-cache so that it spots the new directory and acts accordingly.

Changing component.
Comment 33 Akira TAGOH 2013-10-16 23:39:44 EDT
version?

this should be fixed in 2.11.0-1.fc20.
Comment 34 Dan Horák 2013-10-17 02:38:10 EDT
yeah, it seems to be fixed, I got sendmail-8.14.7-5.fc20 built on s390 which I wasn't (or better koji wasn't) able to build for a long time.
Comment 35 Dmitrij S. Kryzhevich 2013-10-22 23:44:47 EDT
Something similar here.

I'm trying to make a PNG image from PS file with following command:
$ convert -background '#ffffff' -flatten -density 500 forces.ps forces.png

The output:
================================================================
Error: /invalidfont in /findfont
Operand stack:
   Symbol-Oblique   Symbol
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1884   1   3   %oparray_pop   1883   1   3   %oparray_pop   --nostringval--   1867   1   3   %oparray_pop   1755   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1836   2   4   %oparray_pop
Dictionary stack:
   --dict:1176/1684(ro)(G)--   --dict:0/20(G)--   --dict:83/200(L)--   --dict:175/256(L)--
Current allocation mode is local
Last OS error: Not a directory
Current file position is 15028
GPL Ghostscript 9.10: Unrecoverable error, exit code 1
Error: /invalidfont in /findfont
Operand stack:
   Symbol-Oblique   Symbol
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1884   1   3   %oparray_pop   1883   1   3   %oparray_pop   --nostringval--   1867   1   3   %oparray_pop   1755   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1836   2   4   %oparray_pop
Dictionary stack:
   --dict:1176/1684(ro)(G)--   --dict:0/20(G)--   --dict:83/200(L)--   --dict:175/256(L)--
Current allocation mode is local
Last OS error: Not a directory
Current file position is 15028
GPL Ghostscript 9.10: Unrecoverable error, exit code 1
================================================================

I did try to use #21 and it's helped. But only once. The nex time I rerun this command I got the same error. Next time fontconfig cache rebiulding did not helped. I tries this several times. So, the issue somehow related to fontconfig cache but not exactly it.
Comment 36 Dmitrij S. Kryzhevich 2013-10-22 23:54:45 EDT
Sorry, I should drop my issue. Type 1 fonts was disapled on my box.
Comment 37 Akira TAGOH 2013-10-23 00:19:01 EDT
I've filed three bugs for scriptlet in packages to improve this issue somewhat (Bug#1021754, Bug#1021755, and Bug#1021757). once those gets fixed, that should makes much better.
Comment 38 Sandro Mani 2014-04-16 18:05:11 EDT
Joining the party... Happens in the %check stage of python-pillow when running test_file_eps.py

Error: /invalidfont in /findfont
Operand stack:
   Symbol-Oblique   Symbol
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1902   1   3   %oparray_pop   1901   1   3   %oparray_pop   --nostringval--   1885   1   3   %oparray_pop   1771   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1854   2   4   %oparray_pop
Dictionary stack:
   --dict:1179/1684(ro)(G)--   --dict:0/20(G)--   --dict:82/200(L)--   --dict:175/256(L)--
Current allocation mode is local
Last OS error: Not a directory
Current file position is 15021
Comment 39 Jerry James 2014-05-14 10:54:32 EDT
Sorry, but this has either not been fixed or something happened to make it come back.  Yesterday morning, I built zenon in mock and it worked fine.  In the afternoon, I tried to build it in koji and it failed with this error.  Now it fails in mock every single time.  See:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6847476

for a failing example.  Examining it in mock shows the familiar symptom:

<mock-chroot>[root@diannao ~]# strings /var/cache/fontconfig/0251a5afa6ac727a1e3-le64.cache-4
/usr/share/fonts/default
/usr/share/fonts/default/ghostscript
<mock-chroot>[root@diannao ~]# fc-cache
<mock-chroot>[root@diannao ~]# strings /var/cache/fontconfig/0251a5afa6ac727a1e3-le64.cache-4
/usr/share/fonts/default
/usr/share/fonts/default/Type1
/usr/share/fonts/default/ghostscript

So something is still preventing /usr/share/fonts/default/Type1 from being added to the cache list.  Here's an interesting tidbit: running "fc-cache /usr/share/fonts/default/Type1" does NOT fix the problem.
Comment 40 Jerry James 2014-05-14 11:21:32 EDT
I thought it odd that "fc-cache /usr/share/fonts/default/Type1" didn't fix the problem, so I did some experimenting.  It turns out that running "fc-cache /usr/share/fonts/default" (without the "/Type1") DOES fix the cache.  So I built my own local urw-fonts package to use in mock building, and changed the scripts to read:

%post
{
   umask 133
   mkfontscale %{fontdir} || :
   mkfontdir %{fontdir} || :
   fc-cache %{_datadir}/fonts/default
} &> /dev/null || :

%postun
{
   if [ "$1" = "0" ]; then
      fc-cache %{_datadir}/fonts/default
   fi
} &> /dev/null || :

And now zenon builds successfully.  Is this a bug in the urw-fonts scripts, or a bug in fc-cache?
Comment 41 Eric Renfro 2014-05-19 08:10:47 EDT
I am having this exact same issue. However, from #40, no matter of running fc-cache fixes any issues for me in the current state.
Comment 42 Jerry James 2014-05-19 11:31:34 EDT
Eric, have you tried in a mock environment, or are you talking about a real or virtual Rawhide machine?

I've tried several more zenon builds.  If I used my "fixed" urw-fonts package, the builds work.  If I don't, the builds fail.  I also tried adding this to %prep in zenon.spec:

# Workaround for bz 921706
fc-cache %{_datadir}/fonts/default

And that also works.  I guess I will build zenon with that workaround for now until somebody can figure out to really fix this bug for good.
Comment 43 Jerry James 2014-05-19 12:04:47 EDT
Well, crud, that worked locally but failed when building with koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6863975

Eric, you are vindicated.  It looks like we are still in Heisenbug land, where the installation of fontconfig and urw-fonts sometimes lands /usr/share/fonts/default/Type1 in the cache, and sometimes doesn't. :-(
Comment 44 Jerry James 2014-05-19 13:06:21 EDT
After several more mock builds, I can tell you that adding any one of the following (not all of them at once!) to %prep sometimes results in a good build and sometimes doesn't.  In other words, none of these has any effect.  We still sometimes have /usr/share/fonts/default/Type1 in the cache, and sometimes don't.  

- fc-cache /usr/share/fonts/default/Type1
- fc-cache /usr/share/fonts/default
- fc-cache -f /usr/share/fonts/default/Type1
- fc-cache -fr /usr/share/fonts/default/Type1
- fc-cache -f /usr/share/fonts/default
- fc-cache -fr /usr/share/fonts/default
- fc-cache -fr
- fc-cache

Since fc-cache is being run by a nonprivileged user, the new cache data is being written to /builddir/.cache/fontconfig.  And, after most of the commands above, that contains the correct directory:

strings /var/lib/mock/fedora-rawhide-x86_64/root/builddir/.cache/fontconfig/0251a5afa6ac727a1e32b7d4d4aa7cf0-le64.cache-4
47zS
/usr/share/fonts/default
/usr/share/fonts/default/Type1
/usr/share/fonts/default/ghostscript

But then ghostscript fails anyway, as though it can't see /usr/share/fonts/default/Type1.  So fc-cache sometimes fails to add /usr/share/fonts/default/Type1 to the system cache after urw-fonts has been installed, and the fontconfig system sometimes ignores the presence of /usr/share/fonts/default/Type1 in user caches when it isn't present in the system cache.
Comment 45 Jerry James 2014-05-19 18:35:40 EDT
I made another custom urw-fonts package to try to get more information.  This time, I added this to %post:

export FC_DEBUG=1209

That's 1 + 8 + 16 + 32 + 128 + 1024, by the way.  Then I changed the fc-cache invocation to this:

fc-cache %{_datadir}/fonts/default 2>&1 | tee /tmp/urw-install.txt

and added "Requires(post): coreutils".  Since then, I've done a mock build of zenon a dozen times, and it worked.  Every.  Single.  Time.

So apparently attempting to add debug output to gain insight into the problem is enough to make the problem go away.  This must be a timing issue of some kind, and the debug output slows something critical down just enough to make the timing work out right.  I hate that kind of bug.
Comment 46 Akira TAGOH 2014-05-19 23:58:12 EDT
Thanks for debugging. you don't need to set FC_DEBUG. fc-cache -v should works enough. I have no idea at this moment how that race condition issue comes from.
Comment 47 Robert Scheck 2014-05-21 11:35:15 EDT
Building sendmail fails with "Error: /invalidfont in /findfont" on at least 
Rawhide (again?).
Comment 48 Akira TAGOH 2014-05-23 07:06:43 EDT
(In reply to Jerry James from comment #44)
> Since fc-cache is being run by a nonprivileged user, the new cache data is
> being written to /builddir/.cache/fontconfig.  And, after most of the
> commands above, that contains the correct directory:
> 
> strings
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/.cache/fontconfig/
> 0251a5afa6ac727a1e32b7d4d4aa7cf0-le64.cache-4
> 47zS
> /usr/share/fonts/default
> /usr/share/fonts/default/Type1
> /usr/share/fonts/default/ghostscript
> 
> But then ghostscript fails anyway, as though it can't see
> /usr/share/fonts/default/Type1.  So fc-cache sometimes fails to add
> /usr/share/fonts/default/Type1 to the system cache after urw-fonts has been
> installed, and the fontconfig system sometimes ignores the presence of
> /usr/share/fonts/default/Type1 in user caches when it isn't present in the
> system cache.

That sounds like another issue. does changing the order of <cachedir> in /etc/fonts.conf help? i.e. changing

<cachedir>/var/cache/fontconfig</cachedir>
<cachedir prefix="xdg">fontconfig</cachedir>

to:

<cachedir prefix="xdg">fontconfig</cachedir>
<cachedir>/var/cache/fontconfig</cachedir>
Comment 49 ARno 2014-05-26 07:27:13 EDT
A workaround that works for me:
1. Open /etc/fonts/infinality/infinality.conf
2. Comment the following tag that ban Type 1 fonts:
<selectfont> 
		<rejectfont> 
			<pattern> 
				<patelt name="fontformat" > 
					<string>Type 1</string> 
				</patelt> 
			</pattern> 
		</rejectfont> 
	</selectfont>
3. I ran fc-cache but not sure if necessary

=> My document now compiles (I had the problem when using the command psgrid from the PSTricks packages).

From: https://bugs.gentoo.org/show_bug.cgi?id=436500#c2
Comment 50 Jaroslav Škarvada 2014-06-02 11:10:52 EDT
(In reply to ARno from comment #49)
I do not have infinality in the build root and it is failing, so it doesn't seem to be this case.
Comment 51 Jaroslav Škarvada 2014-06-02 11:31:13 EDT
It's quite good reproducible with sendmail (I would say 90% reproducibility) in both koji and mock, e.g. I used the following:

$ mock -r fedora-rawhide-x86_64 ./sendmail-8.14.9-2.fc21.src.rpm

When the problem happen, it is not possible to rebuild the cache by hand as it seems already up-to-date:

# fc-cache -v /usr/share/fonts/default/Type1
/usr/share/fonts/default/Type1: skipping, existing cache is valid: 35 fonts, 0 dirs
/var/cache/fontconfig: cleaning cache directory
/builddir/.cache/fontconfig: not cleaning non-existent cache directory
/builddir/.fontconfig: not cleaning non-existent cache directory
fc-cache: succeeded

This is the same command (without -v) that is issued in the spec file. But the following command rebuilds the cache successfully:

# fc-cache -v /usr/share/fonts/default
/usr/share/fonts/default: skipping, existing cache is valid: 0 fonts, 1 dirs
/usr/share/fonts/default/ghostscript: skipping, existing cache is valid: 4 fonts, 0 dirs
Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts, 2 dirs
/var/cache/fontconfig: cleaning cache directory
/builddir/.cache/fontconfig: not cleaning non-existent cache directory
/builddir/.fontconfig: not cleaning non-existent cache directory
fc-cache: succeeded

And then everything work as expected.
Comment 52 Jerry James 2014-06-02 14:58:48 EDT
(In reply to Akira TAGOH from comment #48)
> That sounds like another issue. does changing the order of <cachedir> in
> /etc/fonts.conf help? i.e. changing
> 
> <cachedir>/var/cache/fontconfig</cachedir>
> <cachedir prefix="xdg">fontconfig</cachedir>
> 
> to:
> 
> <cachedir prefix="xdg">fontconfig</cachedir>
> <cachedir>/var/cache/fontconfig</cachedir>

Sorry to be slow replying.  That does not help.  I just did a mock build with the lines switch as indicated (in a custom fontconfig package build; that was the only change).  The zenon build still failed with the ghostscript complaint recorded above.  Now I see this inside the mock root:

# ls /var/cache/fontconfig
# ls /builddir/.cache/fontconfig
0251a5afa6ac727a1e32b7d4d4aa7cf0-le64.cache-4
3830d5c3ddfd5cd38a049b759396e72e-le64.cache-4
87f5e051180a7a75f16eb6fe7dbd3749-le64.cache-4
b79f3aaa7d385a141ab53ec885cc22a8-le64.cache-4
CACHEDIR.TAG
cfde08ab28ad1d91784abb10973575e3-le64.cache-4
# strings /builddir/.cache/fontconfig/0251a5afa6ac727a1e32b7d4d4aa7cf0-le64.cache-4
/usr/share/fonts/default
/usr/share/fonts/default/ghostscript
# strings /builddir/.cache/fontconfig/b79f3aaa7d385a141ab53ec885cc22a8-le64.cache-4
/usr/share/fonts/default/Type1
URW Gothic L
Book
/usr/share/fonts/default/Type1/a010013l.pfb
Type 1
sha256:ef6cd71620433f650ab4b8022318b261858f4a82ddf87059ad515d355ff2f1cf
URWGothicL-Book
URW Gothic L
Demi
/usr/share/fonts/default/Type1/a010015l.pfb
Type 1
...
Comment 53 Jerry James 2014-06-02 15:04:01 EDT
(In reply to Jaroslav Škarvada from comment #51)
> # fc-cache -v /usr/share/fonts/default
> /usr/share/fonts/default: skipping, existing cache is valid: 0 fonts, 1 dirs
> /usr/share/fonts/default/ghostscript: skipping, existing cache is valid: 4
> fonts, 0 dirs
> Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts,
> 2 dirs
> /var/cache/fontconfig: cleaning cache directory
> /builddir/.cache/fontconfig: not cleaning non-existent cache directory
> /builddir/.fontconfig: not cleaning non-existent cache directory
> fc-cache: succeeded
> 
> And then everything work as expected.

But if the guesses in comment 40 through comment 46 are correct, that only worked because the -v slowed fc-cache down enough to let something else happen first.  If we can figure out what that mysterious something else is, we'll finally have a clue how to solve this bug for good.
Comment 54 Jerry James 2014-06-02 15:40:34 EDT
Running fc-cache -v inside the urw-fonts %post script yields this output on a failing zenon build:

/usr/share/fonts/default/Type1: caching, new cache contents: 35 fonts, 0 dirs
/var/cache/fontconfig: cleaning cache directory
/builddir/.cache/fontconfig: not cleaning non-existent cache directory
/builddir/.fontconfig: not cleaning non-existent cache directory
fc-cache: succeeded

as opposed to this output on a successful build:

/usr/share/fonts/default/Type1: skipping, existing cache is valid: 35 fonts, 0 dirs
/var/cache/fontconfig: cleaning cache directory
/builddir/.cache/fontconfig: not cleaning non-existent cache directory
/builddir/.fontconfig: not cleaning non-existent cache directory
fc-cache: succeeded

Does that give a clue as to what is going wrong?
Comment 55 Jaroslav Škarvada 2014-06-02 16:06:19 EDT
(In reply to Jerry James from comment #53)
> But if the guesses in comment 40 through comment 46 are correct, that only
> worked because the -v slowed fc-cache down enough to let something else
> happen first.  If we can figure out what that mysterious something else is,
> we'll finally have a clue how to solve this bug for good.

No, I ran it in the buildroot which is "in the wrong state" after failed:
$ mock -r fedora-rawhide-x86_64 ./sendmail-8.14.9-2.fc21.src.rpm
I am not changing the urw-fonts scriptlets.

If fc-cache is ran in such buildroot (by entering it by e.g. mock -r fedora-rawhide-x86_64 --shell), it seems there is no difference if using '-v' or not. The following command fixes the cache:

# fc-cache /usr/share/fonts/default
and then the ps2pdf works, but the:
# fc-cache /usr/share/fonts/default/Type1
doesn't fix the cache (this is the same path as used in the urw-fonts scriptlets) which seems suspicious to me.
Comment 56 Akira TAGOH 2014-06-02 23:11:56 EDT
(In reply to Jerry James from comment #52)
> Sorry to be slow replying.  That does not help.  I just did a mock build
> with the lines switch as indicated (in a custom fontconfig package build;
> that was the only change).  The zenon build still failed with the
> ghostscript complaint recorded above.  Now I see this inside the mock root:

That was a suggestion for a workaround in case both system cache dir and user cache dir contains different caches. not for this broken cache issue.
Comment 57 Akira TAGOH 2014-06-03 08:15:12 EDT
Okay. just made a testing package for this issue. the patch may needs to be polished more but please let me know if it works for all of your mock build.

http://koji.fedoraproject.org/koji/taskinfo?taskID=6920997
Comment 58 Jerry James 2014-06-03 22:52:31 EDT
I have done 4 good builds of zenon in a row so far with this test build, so it is looking good so far.
Comment 59 Jerry James 2014-06-04 11:05:54 EDT
I have done several more builds this morning, all of them successful.
Comment 60 Jaroslav Škarvada 2014-06-04 11:21:05 EDT
I rebuilt sendmail in mock three times and all passed.
Comment 61 Akira TAGOH 2014-06-05 06:22:50 EDT
Thanks for testing. I've built the fixed package for rawhide.
Comment 62 Eric Renfro 2014-06-15 11:03:14 EDT
Is this bug not going to get fixed in the actual reported version of Fedora it's broken in?
Comment 63 Eric Renfro 2014-06-15 11:10:19 EDT
(In reply to Eric Renfro from comment #62)
> Is this bug not going to get fixed in the actual reported version of Fedora
> it's broken in?

I mean.. It broke from an update in F20, and is still broke today, yet this ticket is closed as if it's only going into rawhide for f21. So this is a bit concerning.
Comment 64 Hankenstein 2014-07-04 03:05:47 EDT
I'm using fedora 19.  Trying to print ascii files to my HP laserjet produced only blank pages, apparently because of ghostscript crashing.  Searching for
clues, I came across this report. 

After installing urw-fonts from rawhide, the problem disappeared (for me).  Should I enter a new report?
Comment 65 Tim Waugh 2014-07-04 04:31:16 EDT
(In reply to Hankenstein from comment #64)
> I'm using fedora 19.  Trying to print ascii files to my HP laserjet produced
> only blank pages, apparently because of ghostscript crashing.  Searching for
> clues, I came across this report. 

Why do you say "apparently because of ghostscript crashing"? Was there an error message in the error_log file?
Comment 66 Hankenstein 2014-07-04 04:47:05 EDT
(In reply to Tim Waugh from comment #65)

> Why do you say "apparently because of ghostscript crashing"? Was there an
> error message in the error_log file?

Exactly so.  ("Crash" was wrong, sorry.) The main bit of it seemed to be:
... backendWaitLoop(snmp_fd=6, addr=0xb8ff29ec, side_cb=0xb77a0760)
... Error: /invalidfont in /findfont
... Operand stack:
...  Helvetica

I can supply some portion of error_log if needed. (Please tell me if I should redact something -- its permissions are -rw------- .) 

I then found this report, and ran
gs -sDEVICE=nullpage -dBATCH -c '(Helvetica) findfont'

which (didn't actually "crash" but) produced some output similar to Comment 2 above.
Comment 67 Hankenstein 2014-07-04 05:07:57 EDT
Created attachment 914656 [details]
snip from /var/log/cups/error_log

Result of "lpr some-ascii-file.txt"
Comment 68 Hankenstein 2014-07-04 05:10:03 EDT
I have added an attachment.  (Please excuse any faux pas: I have never used bugzilla before, except to read reports.)

attachment 91465 [details]
Comment 69 Tim Waugh 2014-07-04 05:30:49 EDT
That's the same as this bug then, no need for a new report.

I've re-opened it and changed the version to 19 since it affects both Fedora 19 and Fedora 20 (according to comment #63).

tagoh: is this just a case of backporting the fix and issuing updates with bodhi?
Comment 72 Akira TAGOH 2014-07-07 06:52:10 EDT
(In reply to Tim Waugh from comment #69)
> That's the same as this bug then, no need for a new report.
> 
> I've re-opened it and changed the version to 19 since it affects both Fedora
> 19 and Fedora 20 (according to comment #63).
> 
> tagoh: is this just a case of backporting the fix and issuing updates with
> bodhi?

Sure. will do.
Comment 73 Fedora Update System 2014-07-08 05:56:23 EDT
fontconfig-2.11.0-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/fontconfig-2.11.0-2.fc20
Comment 74 Fedora Update System 2014-07-08 05:56:53 EDT
fontconfig-2.10.93-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/fontconfig-2.10.93-2.fc19
Comment 75 Fedora Update System 2014-07-08 22:28:55 EDT
Package fontconfig-2.11.0-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fontconfig-2.11.0-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8185/fontconfig-2.11.0-2.fc20
then log in and leave karma (feedback).
Comment 76 Hankenstein 2014-07-09 10:59:05 EDT
(In reply to Fedora Update System from comment #74)
> fontconfig-2.10.93-2.fc19 has been submitted as an update for Fedora 19.
> https://admin.fedoraproject.org/updates/fontconfig-2.10.93-2.fc19

I am sorry to say that installing this took me back to the original situation: any attempt to print an ascii file results in blank pages.  The cups error log looks the same.  /usr/bin/gs cannot find Helvetica.  

Prior to installing fontconfig-2.10.93-2.fc19, I had fixed the problem by installing urw-fonts from rawhide.  (So I had installed
urw-fonts-2.4-19.fc21.noarch.)

Ah, thought I, I'll just reinstall urw-fonts-2.4-19.fc21.noarch, 
but this time that didn't work. So at the moment I can't print ascii files. 

I will investigate some more, and try somehow to get back the f19 version of urw-fonts, and start again.  Right now I don't know how to do that.
Comment 77 Hankenstein 2014-07-09 11:25:18 EDT
So I downgraded urw-fonts back to fc19, and reinstalled 
fontconfig-2.10.93-2.fc19.  Still gs couldn't find Helvetica. 
Then I went back to the rawhide urw-fonts. 
No luck.

I then downgraded font-config, to 2.10.93-2, urw-fonts to 2.4-18.fc19,
checked that gs still couldn't find Helvetica,  then tried
urw-fonts-2.4-19.fc21 again. 

I ran out of any clue about what I'm doing long ago.  But I've no
ideas now about how to get back to a situation where I can print any 
ascii files.
Comment 78 Eric Renfro 2014-07-09 18:31:06 EDT
This does not appear to resolve the problem for me either. Still have the problem on all my home computers after applying the proposed update.
Comment 79 Akira TAGOH 2014-07-09 23:46:59 EDT
check your cache file then. if fontconfig figures out if the cache doesn't need to be updated, i.e. no changes of the mtime on the filesystem, it may looks like not-yet-fixed. this update doesn't help for that and not expecting to do something.
Comment 80 Akira TAGOH 2014-07-09 23:48:17 EDT
and, if that is the case, you need to run fc-cache -f manually to force updates.
Comment 81 Hankenstein 2014-07-10 03:49:22 EDT
Something that seemed to sort this out for me was erasing fontconfig-infinality, which also removed freetype-infinality.  If I reinstall these, I have the original problem.  (I had forgotten I once installed these -- sorry!)  I also ran fc-cache -f at various points.

I am now using  fontconfig-2.10.93-2.fc19 and urw-fonts-2.4-18.fc19.noarch, and I no longer have any problem with them.  I'll bestow "karma" as soon as I figure out how to do that.
Comment 82 Fedora Update System 2014-07-10 22:04:42 EDT
fontconfig-2.11.0-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 83 Fedora Update System 2014-07-25 06:05:38 EDT
fontconfig-2.10.93-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.