Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#16326 - [fontforge] Problem opening SVG fonts

Attached to Project: Arch Linux
Opened by Patrick McCarty (pnorcks) - Wednesday, 23 September 2009, 08:06 GMT
Last edited by Eric Belanger (Snowman) - Friday, 25 September 2009, 10:33 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I am unable to open SVG fonts (distributed with LilyPond) with Fontforge. When I attempt this, Fontforge displays a dialog box with title "Couldn't open font" and this error message:
"
emmentaler-11.svg is not in a known format (or is so badly corrupted as to be unreadable)
"

Additional info:
* package version(s)
20090914-1

Steps to reproduce:
1) Locate an SVG font. Fontforge creates several of these during LilyPond's build process, so I used the "emmentaler-11.svg" font.
2) Open with "fontforge emmentaler-11.svg"
3) The dialog box with error is shown.

Workaround:
I compiled fontforge 20090914-2 with makepkg using the same PKGBUILD, and the problem goes away. Looking at the strace logs, I suspect that Pango is a runtime dependency, but I can't tell for sure.
This task depends upon

Closed by  Eric Belanger (Snowman)
Friday, 25 September 2009, 10:33 GMT
Reason for closing:  Fixed
Additional comments about closing:  fontforge-20090914-2
Comment by Patrick McCarty (pnorcks) - Wednesday, 23 September 2009, 08:11 GMT
Forgot to mention that I'm running x86_64, if that makes a difference.
Comment by Eric Belanger (Snowman) - Wednesday, 23 September 2009, 19:05 GMT
run namcap on the working package and post the output here. That'll tell us if there is a missing (make)depends.
Comment by Patrick McCarty (pnorcks) - Thursday, 24 September 2009, 21:50 GMT
Hmm, namcap doesn't report any warnings or errors for the working package or the current package in [extra].

I've just compared the output of LD_DEBUG=all for both packages. Interestingly, the package in [extra] prints these five lines:

file=libSM.so.6 [0]; needed by /usr/lib/libgdraw.so.4 [0]
file=libICE.so.6 [0]; needed by /usr/lib/libgdraw.so.4 [0]
file=libXi.so.6 [0]; needed by /usr/lib/libgdraw.so.4 [0]
file=libX11.so.6 [0]; needed by /usr/lib/libgdraw.so.4 [0]
file=libxkbui.so.1 [0]; needed by /usr/lib/libgdraw.so.4 [0]

but my self-compiled (working) package prints these analogous lines:

file=libSM.so.6 [0]; needed by fontforge [0]
file=libICE.so.6 [0]; needed by fontforge [0]
file=libXi.so.6 [0]; needed by fontforge [0]
file=libX11.so.6 [0]; needed by fontforge [0]
file=libxkbui.so.1 [0]; needed by fontforge [0]

I suspect this is the problem. I can't tell from the config.log what could cause these linking discrepancies though. Do you think this is a problem with the upstream configure script?
Comment by Eric Belanger (Snowman) - Friday, 25 September 2009, 10:33 GMT
As I thought, it was missing makedepends: 'libxml2' 'pango'

Loading...