'/usr/local/share/icons/hicolor/scalable/apps/awn-manager.svg': No such file or directory

[Andrew Starr-Bochicchio]

Binary package hint: awn-manager

Version: 0.2.6-6 in Intrepid

When attempting to get this package backported to Ubuntu Hardy (Bug #235875), I came across this issue. awn-manager.svg does not seem to be installed properly. It seems to be a packaging issue as this does not occur in trunk built from source.

This happens when when ever launching awn-manager is attempted, whether by right clicking on the dock or from the command line.

Traceback (most recent call last):
  File "/usr/bin/awn-manager", line 203, in <module>
    awnmanager = AwnManager()
  File "/usr/bin/awn-manager", line 76, in __init__
    icon = theme.load_icon('awn-manager', 128, gtk.ICON_LOOKUP_USE_BUILTIN)
gobject.GError: Failed to open file
'/usr/local/share/icons/hicolor/scalable/apps/awn-manager.svg': No such
file or directory

[Milan Bouchet-Valat (nalimilan)]

This is because the package installs the awn-manager.svg icon to /usr/share/, and not /usr/local/share/. this behavior is right, but the code may be faulty (or maybe the Makefiles).

[Milan Bouchet-Valat (nalimilan)]

Oh, and another remark: the 0.2.6 version is likely to be really old, and a fix may be committed for a while upstream. You may better wait for a new release. Let's see what upstream says.

[Andrew Starr-Bochicchio (andrewsomething)]

Closing the upstream task since as stated in the original report, this is not an issue in trunk.

Also, 0.2.6 is the most recent stable release of AWN and 0.2.6-6 is a direct sync of the current Debian Sid package. This report is referring to the version in Intrepid not Hardy.

[Julien Lavergne (gilir)]

I never see this error in Debian. I suspect it's an Ubuntu / Intrepid or Hardy problem. No need to spam the Debian bug tracker if can't track it on a Debian system.

To be sure, try to put manually a dh_icon or something to force to "icon registration", or try to force the prefix=/usr (but cdbs should do all this).
You can also try this PPA : https://edge.launchpad.net/~awn-core/+archive . It's a simple backport of debian package to Hardy.

I can't access to my computer for a while so you need to track it yourself for now if you want to backport the package, or wait for a few days.

[Andrew Starr-Bochicchio (andrewsomething)]

I can reproduce this with the package from the AWN-Core PPA as well.

avant-window-navigator:
  Installed: 0.2.6-5~ppa1
  Candidate: 0.2.6-5~ppa1
  Version table:
 *** 0.2.6-5~ppa1 0
        500 http://ppa.launchpad.net hardy/main Packages
        100 /var/lib/dpkg/status
     0.2.1-0ubuntu2 0
        500 http://archive.ubuntu.com hardy/universe Packages

awn-manager:
  Installed: 0.2.6-5~ppa1
  Candidate: 0.2.6-5~ppa1
  Version table:
 *** 0.2.6-5~ppa1 0
        500 http://ppa.launchpad.net hardy/main Packages
        100 /var/lib/dpkg/status
     0.2.1-0ubuntu2 0
        500 http://archive.ubuntu.com hardy/universe Packages

Traceback (most recent call last):
  File "/usr/bin/awn-manager", line 203, in <module>
    awnmanager = AwnManager()
  File "/usr/bin/awn-manager", line 76, in __init__
    icon = theme.load_icon('awn-manager', 128, gtk.ICON_LOOKUP_USE_BUILTIN)
gobject.GError: Failed to open file '/usr/local/share/icons/hicolor/scalable/apps/awn-manager.svg': No such file or directory

[Andrew Starr-Bochicchio (andrewsomething)]

>try to force the prefix=/usr (but cdbs should do all this).

That's not the issue. "/usr/share/icons/hicolor/scalable/apps/awn-manager.svg" exists.

The problem is that awn-manager is looking for it in: '/usr/local/share/icons/hicolor/scalable/apps/awn-manager.svg'

Line 68 of awnManager.py is:

        icon_search_path = os.path.join('/usr/local/share', 'icons')

While line 68 of awnManager.py.in is:

       icon_search_path = os.path.join('@DATADIR@', 'icons')

Looking at '/usr/bin/awn-manager' after installation shows that @DATADIR@ has been correctly changed to '/usr/share':

        icon_search_path = os.path.join('/usr/share', 'icons')

I don't understand why it's looking for: '/usr/local/share/icons/hicolor/scalable/apps/awn-manager.svg'

I guess I'll reopen the upstream task as this seems to be a problem with awn-manager itself. It seems as if this should be happening on any copy of AWN configured with the flag '--prefix=/usr'.

[Mark Lee (malept)]

DATADIR is defined by ./configure in one of two ways:
 * Defaults to $PREFIX/share
 * defined by the ./configure flag --datadir=[datadir]

(the line that specifically makes sure that DATADIR is replaced properly is line 212)

I suppose someone should make sure that cdbs isn't explicitly setting --datadir.

[Julien Lavergne (gilir)]

I can't reproduce it with your package and my package. All are fine.
I made one with datadir forced to /usr/share and with the icon cache update. You can try it in my PPA.
IMO, it's a problem on your system, or it's the awn-manager icon not properly update on the system. If you can find someone with the same error with my last debs, I'll search more about this issue.

[Andrew Starr-Bochicchio (andrewsomething)]

I still receive the exact same Traceback with version 0.2.6-7~ppa2 from your PPA.

Also, it isn't only occurring on my system. I was confirming an issue found by a tester in Bug #235875.

[Andrew Starr-Bochicchio (andrewsomething)]

Alright, I think I have something but still not sure where to go with it. It definitely seems to be an issue with the icon cache not being updated correctly in cases where awn-manager had previously been installed to /usr/local/.

While CDBS seems to be calling dh_icons, it only does so on the directory where the icon is being installed to, i.e.
./usr/share/icons/hicolor/'.

But it seems that the old directory needs to be updated as well since the cache is still looking there for the icon.

Running 'sudo gtk-update-icon-cache -ft /usr/local/share/icons/hicolor' has solved this issue for me.

[Mark Lee (malept)]

Given that this problem only happens when someone moves from a built-from-source Awn to a packaged Awn, I'm not sure what Awn itself can do, other than provide the information that Andrew uncovered in our documentation (i.e., the FAQ).

[Andrew Starr-Bochicchio (andrewsomething)]

It seems that this has happened with other programs:

http://blogs.gnome.org/jjongsma/2006/10/15/icon-theme-cache-issues/
http://bugzilla.gnome.org/show_bug.cgi?id=362604

"The GNOME Goal page mentioned above suggests an install-data-hook rule which updates the gtk icon cache after the program’s icons are installed. So the icon cache in /usr/local gets updated when you first install the program to /usr/local. Unfortunately, after uninstalling the application, the icon cache is not updated, so gtk still thinks there are application icons located under /usr/local.

Since /usr/local/ is in the icon theme search path before /usr, when the application is installed to /usr, it will find the stale icon cache in /usr/local and think it found the icon you’ve requested. Unfortunately the icon that it ‘found’ has already been deleted, so it will try to load an icon from /usr/local that doesn’t exist, and the program crashes. The solution is to simply add an uninstall-hook that also updates the gtk icon cache so that you don’t have a stale icon cache after you run `make uninstall`. Something like the following:

gtk_update_icon_cache = gtk-update-icon-cache -f -t $(datadir)/icons/hicolor
install-data-hook: update-icon-cache
uninstall-hook: update-icon-cache
update-icon-cache:
        @-if test -z "$(DESTDIR)"; then
                 echo "Updating Gtk icon cache.";
                 $(gtk_update_icon_cache);
         else
                 echo "*** Icon cache not updated. After install, run this:";
                 echo "*** $(gtk_update_icon_cache)";
         fi
"

[Andrew Starr-Bochicchio (andrewsomething)]

It seems that AWN isn't actually the culprit here. I don't think that we actually update the icon cache at all when building from source, but looking at other programs that I've installed from source I see that this is fairly common (especially GNOME). What must have happened was that a different program made that call for that directory, and then I uninstalled AWN with out updating the cache.

Here's a quick attempt at a fix.

[Julien Lavergne (gilir)]

Try to build and install it from source in two differents prefix; If the problem appear, you can spam malept because it's an upstream problem ;)

[Mark Lee (malept)]

I'll try to commit it later today.

[black (blackborn)]

Is it already committed Mark Lee?

[Mark Lee (malept)]

Fixed in r360.

[Julien Lavergne (gilir)]

Will be fix when the 0.2.8 version or a 0.3.X will be release.

[Julien Lavergne (gilir)]

Fix released in Jaunty (0.3~bzr489-1)