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
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
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.
Well, hard to say, as you can see, is it not clearly failing in koji (for whatever reason)?
This is preventing nightview from building as well.
http://kojipkgs.fedoraproject.org//work/tasks/3103/5303103/build.log
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
Oh, the i686 arch failed this time. :-(
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.
Nope, looks like it is still there: http://kojipkgs.fedoraproject.org//work/tasks/5259/5305259/build.log
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.
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.
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
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. :/
... and the rawhide build just succeeded. I got nothing.
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?
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
it's built http://koji.fedoraproject.org/koji/taskinfo?taskID=5334931 this build includes tom's patch.
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
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).
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.
(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?
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
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
(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.
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
Created attachment 799208 [details] strace output versions are: urw-fonts-2.4-17.fc20.noarch ghostscript-9.07-12.fc20.s390
Tim, could you look at this once more, please? Seems I can easily reproduce it.
(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.
(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?
(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?
or should %posttrans scriptlet be used instead?
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.
version? this should be fixed in 2.11.0-1.fc20.
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.
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.
Sorry, I should drop my issue. Type 1 fonts was disapled on my box.
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.
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
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.
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?
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.
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.
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. :-(
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.
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.
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.
Building sendmail fails with "Error: /invalidfont in /findfont" on at least Rawhide (again?).
(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>
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
(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.
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.
(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 ...
(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.
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?
(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.
(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.
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
I have done 4 good builds of zenon in a row so far with this test build, so it is looking good so far.
I have done several more builds this morning, all of them successful.
I rebuilt sendmail in mock three times and all passed.
Thanks for testing. I've built the fixed package for rawhide.
Is this bug not going to get fixed in the actual reported version of Fedora it's broken in?
(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.
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?
(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?
(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.
Created attachment 914656 [details] snip from /var/log/cups/error_log Result of "lpr some-ascii-file.txt"
I have added an attachment. (Please excuse any faux pas: I have never used bugzilla before, except to read reports.) attachment 91465 [details]
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?
(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.
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
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
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).
(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.
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.
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.
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.
and, if that is the case, you need to run fc-cache -f manually to force updates.
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.
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.
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.