Description of problem: The spec file for the ghostscript package creates the following three files in /etc/ghostscript/8.71: cidfmap.local CIDFnmap.local Fontmap.local The files under /etc/ghostscript are important because they are the only ones marked as %config(noreplace), and so if you make customizations to the system-wide files in /usr/share/ghostscript/8.71/Resource/Init, they may be clobbered if the upstream version of the file changes. The system-wide cidfmap and CIDFnmap files contain lines like these at the end: % must be at the bottom of line to allow people overriding everything. (cidfmap.local) .runlibfileifexists % must be at the bottom of line to allow people overriding everything. (CIDFnmap.local) .runlibfileifexists No such line exists at the end of the global Fontmap file. As a result, making customizations in the obvious place (the /etc/ghostscript/8.71/Fontmap.local file that the package helpfully creates for you) results in your customizations never being read in by gs. Version-Release number of selected component (if applicable): 8.71-6.fc11.x86_64, 8.71-9.fc13.x86_64, and presumably also the current versions in F12 and Rawhide Steps to Reproduce: 1. yum install ghostscript strace 2. strace gs >/tmp/gstrace 2>&1 3. search for Fontmap in /tmp/gstrace with your favorite editor and note that several locations including /etc/ghostscript and /etc/ghostscript/8.71 are searched for a file called Fontmap, but Fontmap.local is never tried One way to tackle this would be to patch the upstream Fontmap file to add something like this to the end of the global file: (Fontmap.local) .runlibfileifexists I recommend this solution. Another approach would be to discontinue creating the /etc/ghostscript/8.71/Fontmap.local file and instead create one named Fontmap. However, all systems with ghostscript already installed may still have the Fontmap.local file present and be confused when they try to use it.
The patch to get ghostscript to read Fontmap.local was dropped after ghostscript-8.15.4-3.fc7. I think that was just a mistake at the time -- those files were reorganised upstream. Thanks for reporting it.
ghostscript-8.71-15.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/ghostscript-8.71-15.fc12
ghostscript-8.71-14.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/ghostscript-8.71-14.fc13
ghostscript-8.71-15.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ghostscript-8.71-15.fc14
ghostscript-8.71-15.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ghostscript'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ghostscript-8.71-15.fc14
Ghostscript-8.71-15.fc14 won't print anymore in Rawhide. $ /usr/lib/cups/filter/pstoraster Fontmap entry for Fontmap.local ends prematurely! Giving up. It DOES work, however, if you change (CIDFnmap.local) .runlibfileifexists to (Fontmap.local) .runlibfile in /usr/share/ghostscript/8.71/Resource/Init/Fontmap or remove the line entirely.
I mean change (Fontmap.local) .runlibfileifexists to (Fontmap.local) .runlibfile
(In reply to comment #6) > Ghostscript-8.71-15.fc14 won't print anymore in Rawhide. > > $ /usr/lib/cups/filter/pstoraster > Fontmap entry for Fontmap.local ends prematurely! Giving up. > > It DOES work, however, if you change > > (CIDFnmap.local) .runlibfileifexists > to > (Fontmap.local) .runlibfile > > in /usr/share/ghostscript/8.71/Resource/Init/Fontmap > > or remove the line entirely. For me "asy -tex pdflatex xxx.asy" failed as above, fixed by commenting out the mentioned line. AFAIU, the message means that the file is tuncated, i.e., just an empty file won't do. If it is shipped/used, it should be correct.
Created attachment 443320 [details] runlibfileifexists patch from OpenSUSE I don't think the current runlibfileifexists patch in Fedora actually works due to the way fontmap files are loaded by gs_fonts.ps. I found OpenSUSE's runlibfileifexists patch also modifies gs_fonts.ps to handle fontmap files that use runlibfileifexists. http://www.mirrorservice.org/sites/download.opensuse.org/update/11.3/rpm/src/ghostscript-library-8.70-15.1.1.src.rpm/ghostscript-8.60-runlibfileifexists.dif?extract=true
This wont print in FC13 either: ghostscript i686 8.71-15.fc13 updates-testing 4.5 M ghostscript-cups i686 8.71-15.fc13 updates-testing 44 k I found another bugzilla on this: https://bugzilla.redhat.com/show_bug.cgi?id=630423 Maybe someone merge these bugs?
On F13, I have ghostscript.i686 8.71-15.fc13 @updates-testing ghostscript-cups.i686 8.71-15.fc13 @updates-testing ghostscript-devel.i686 8.71-15.fc13 @updates-testing ghostscript-fonts.noarch 5.50-23.fc12 @anaconda-InstallationRepo-200911081854.i386/12 I ran $ gs -q -dNOPAUSE -dNODISPLAY -dBATCH -dDELAYBIND -g2448x3168 -r288 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -c 0 0 translate -sTraceFile=/sdb3/home/jd/.scribus//ps.out -sExportFiles=/tmp/Document--XXX /usr/lib/scribus/import.prolog /tmp/XXX.pdf -c flush cfile closefile quit Fontmap entry for Fontmap.local ends prematurely! Giving up. So, even with the latest patches in 8.71-15, the bug remains. FYI: $ ls -l /etc/ghostscript/8.71/Fontmap.local -rw-r--r-- 1 root root 0 Sep 3 05:06 /etc/ghostscript/8.71/Fontmap.local Zero length file. Why so?? The updates were installed a few days ago.
This is probably wrong (ghostscript-8.71-15.fc14): > ls -l /etc/ghostscript/8.71/ total 0 -rw-r--r--. 1 root root 0 Sep 3 14:15 cidfmap.local -rw-r--r--. 1 root root 0 Sep 3 14:15 CIDFnmap.local -rw-r--r--. 1 root root 0 Sep 3 14:15 Fontmap.local
Fix for this issue breaks also /usr/bin/ps2pdf command and it's currently impossible to build nasm package. When I revert from ghostscript-8.71-15.fc15 to ghostscript-8.71-14.fc15 everything is OK. Fix suggested in comment #6 also helps.
*** Bug 630423 has been marked as a duplicate of this bug. ***
*** Bug 632042 has been marked as a duplicate of this bug. ***
ghostscript-8.71-16.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc14
ghostscript-8.71-16.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc13
ghostscript-8.71-16.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc12
(In reply to comment #9) > I don't think the current runlibfileifexists patch in Fedora actually works due > to the way fontmap files are loaded by gs_fonts.ps. > > I found OpenSUSE's runlibfileifexists patch also modifies gs_fonts.ps to handle > fontmap files that use runlibfileifexists. Thanks Edward, I think you hit the nail on the head there. I've included the extra part of the patch in these respun packages.
New packages work for me in F14.
(In reply to comment #17) > ghostscript-8.71-16.fc13 has been submitted as an update for Fedora 13. > https://admin.fedoraproject.org/updates/ghostscript-8.71-16.fc13 I confirm that it is fixed in F13. Thanx all!
ghostscript-8.71-16.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
ghostscript-8.71-16.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
ghostscript-8.71-16.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
In ghostscript-8.71-16.fc12 the "file" command no longer works correctly if -dSAFER is set. I haven't tried using it much lately, so the problem may have crept in one or two releases earlier. Example showing the problem: [stern@iolanthe PS]$ rpm -qf `which gs` ghostscript-8.71-16.fc12.i686 [stern@iolanthe PS]$ ls -l spiral.ps -rw-rw-r-- 1 stern stern 2854 1999-03-02 14:50 spiral.ps [stern@iolanthe PS]$ gs GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>(spiral.ps) (r) file GS<1>^C [stern@iolanthe PS]$ gs -dSAFER GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>(spiral.ps) (r) file Error: /invalidfileaccess in --file-- Operand stack: (spiral.ps) (r) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- %loop_continue --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1150/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- Current allocation mode is local Last OS error: 11 Current file position is 21 GS<2>^C
Ah, that might be the cause of bug #642427.
Yes, it looks that way. I originally ran across this problem in a similar setting; a "run" command that had worked previously now fails. Over the weekend I found an old copy of the 8.71-7 release. It did not have this problem. I don't know where to find any intermediate releases, but probably you can test them just as easily as I can.
The cause is that we use a different (more secure) build default in ghostscript now which is equivalent to the command line option "-P-". To allow reading files from the current directory, use the command line option "-P" (or "-I.").