On 5 June 2013 11:16, Harishankar <v.harishan...@gmail.com> wrote: > > I don't get any apt-get install errors. I also tried deleting > the .mypaint/ folder from my home folder but it still doesn't work. > > [...] > > I am using amd64 distribution have also enabled multi-arch support on my > system. I am running Gnome Shell.
Still unable to reproduce with a fresh minimal gnome-shell install on an amd64 vm with i386 multiarch support. MyPaint runs just fine and finds its icons. Sources are presumably OK. It looks as though you have the right packages installed, and these should contain the icons. Please verify that /usr/share/icons/* is populated with lots of icon files with the prefix "mypaint-". $ find /usr/share/icons/hicolor -name 'mypaint*' -o -name 'brush-blend-mode*' | sort $ dpkg -L mypaint-data | grep /usr/share/icons | sort these two commands should produce identical lists of files, although one lists the folders and the other does not. If the find incantation does not list any files, please purge and reinstall mypaint-data and mypaint. Have you ever deployed MyPaint manually, to a prefix other than /usr, on this system? If so, please check every folder prefix listed in the "Icon search path:" in your initial report using the "find" incantation above. These files should be checked for readability by your desktop user and/or removed. If any of these prefixes contain icons in the hicolor theme, the corresponding hicolor/icon-theme.cache must also be a) up to date and b) readable to the desktop user: see https://gitorious.org/mypaint/mypaint/blobs/master/README for details. Actually you can delete it as well; it's just a cache of what icons are present or absent in its corresponding folder. >From your icon search order, which is a normal one for MyPaint, you might want to check for an outdated cache in '/home/hari/.icons', '/home/hari/.local/share/icons', '/usr/share/gnome/icons', and '/usr/local/share/icons' because those are the ones that'll shadow the /usr/share/icons location. (I *can* reproduce the error message by running with a copy of manually backed-up /usr/share/icons/hicolor/icon-theme.cache created by the hicolor-icon-theme's post-install hooks at a time when mypaint-data was not installed. But that's not very interesting considering that I wrote that test in the first place :) Anyway, if you don't have a shadowing and outdated cache file, could you please verify that these postinst hooks are running correctly by deinstalling and reinstalling mypaint-data and mypaint a few times and checking to see if the /usr/share/icons cache file's timestamp changes?) Finally, are you configured in such away as to prevent GTK from using the hicolor theme as a fallback? If so, please revert this configuration. FYI, mypaint checks for mypaint.{svg,png} and mypaint-tool-brush.{svg,png} during that check. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org