[Python-apps-team] Bug#710864: #710864: any updates?

Andrew Chadwick a.t.chadwick at gmail.com
Wed Jun 5 17:06:04 UTC 2013


On 5 June 2013 11:16, Harishankar <v.harishankar at 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



More information about the Python-apps-team mailing list