Bugzilla – Bug 204719
inkscape is missing icons
Last modified: 2006-10-26 15:15:37 UTC
When using inkscape from Beta 4 or factory, several icons are missing, at least when KDE is selected as default desktop. This is either a packaging bug or a missing dependency. Version information: # rpm -qi inkscape Name : inkscape Relocations: (not relocatable) Version : 0.43 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Output of missing icons (stderr log) attached.
Created attachment 98274 [details] Error output listing missing icons on startup
Sorry, that should of course read Alpha 4
Does running SuSEconfig solve the problem?
Nope, Problem presists. The icons don't appear to be part of the package either, at least not as seperate files. Are they compiled into some resource file?
Information provided.
They are likely part of the icon theme. Is gnome-icon-theme and/or tango-icon-theme installed?
yes: tango-icon-theme-0.7.2-12 gnome-icon-theme-2.15.92-4 Both were not auto-dependencies of inkscape, though. They got installed later.
*** Bug 207430 has been marked as a duplicate of this bug. ***
This looks like either a build issue or a corrupt package since: ** (process:26407): WARNING **: Could not open units file '${datarootdir}/inkscape/ui/units.txt': No such file or directory indicates it can't find other items as well (and rpm -ql inkscape | grep units.txt shows a file for me). Works fine under both GNOME and KDE for me (both installed).
${datarootdir} is an unexpanded autotools variable, indicating a build system bug in inkscape. It seems to be fixed by now, "strings" does not find any occurances of "datarootdir" in /opt/gnome/bin/inkscape. Instead, it finds an occurance of /opt/gnome/share/inkscape/ui which indicates that the underlying problem is fixed by now.
Sorry, I really managed to confuse my 10.1 and 10.2 systems. Comment 10 is wrong because of that, please ignore it. => Reopening. inkscape is still broken, there are unexpanded autotools variables all over the place: % strings /opt/gnome/bin/inkscape | grep datarootdir ${datarootdir}/inkscape/extensions ${datarootdir}/pixmaps ${datarootdir}/locale ${datarootdir}/inkscape/templates ${datarootdir}/inkscape/screens ${datarootdir}/inkscape/tutorials ${datarootdir}/inkscape/markers ${datarootdir}/inkscape/palettes ${datarootdir}/inkscape/icons ${datarootdir}/inkscape/gradients ${datarootdir}/inkscape/patterns ${datarootdir}/inkscape/ui ${datarootdir} That way the binary will not be able to find any of its resources. (It's caused by autoconf 2.60, it expands ${datadir} to ${datarootdir} by default which did not exist in earlier autoconf versions. This requires build scripts to be adjusted.)
The bug is in inkscape's configure.ac between lines 706 and 728: The test does not handle ${datarootdir} at all. Known upstream: http://sourceforge.net/search/?ml_name=inkscape-devel&type_of_search=mlists&group_id=93438&words=datarootdir https://sourceforge.net/tracker/?func=detail&atid=604308&aid=1521963&group_id=93438 But none of the three patches is good, they are all removing the bad code instead of fixing it.
It's totally broken, the default config.h when just running ./configure without arguments contains: #define INKSCAPE_DATADIR "${datarootdir}" #define INKSCAPE_LIBDIR "NONE/lib" #define PACKAGE_LOCALE_DIR "${datarootdir}/locale" Any volunteers to fix this for autoconf 2.60 without breaking it for earlier autoconf versions? If not, you can work around this bug by explicitly adding --datadir=/opt/gnome/share to the ./configure invocation. It's not a fix, but prevents the buggy code path from being used.
I'm puzzled why I can't replicate this on alpha4.
Should I go ahead and add --datadir=/opt/gnome/share to the ./configure for the time being?
"strings" shows that the latest Factory build (inkscape-0.44.1-2) still has ${datarootdir} compiled into the binary. (Unfortunately it's not installable because of bug 209601.) So I'd say "Yes". A workaround is better than a broken inkscape.
I have submitted inkscape with the --datadir=/opt/gnome/share workaround.
Created attachment 100635 [details] Patch This should be a real fix. But I recommend keeping just the workaround for now and not using this patch. The patch doesn't fix binreloc detection (broken as well for the same reason, but unused on Linux) - I'll try to fix that as well and submit the patch upstream.
still missing in alpha5
Since we have a workaround, Andreas I would say you should just file your fix upstream and we'll close this out for 10.2.