Description of problem: While running recent rawhide updates I got this complaint: gtk-update-icon-cache: Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : File exists A result was NOT an updated icon-theme.cache. This was an effect of running the following package script: touch -c /usr/share/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then /usr/bin/gtk-update-icon-cache -q /usr/share/icons/hicolor || : fi (In this particular case it came from tigervnc-1.4.2-2.fc23.x86_64 but that hardly relevant; I have seen similar scripts in many places). A stale .icon-theme.cache was likely a result of some older update which went screwy and runnning 'gtk-update-icon-cache -f ....' had a salutary effect. Could not gtk-update-icon-cache take care of leftovers by itself or should every package spec which happens to run this to be edited to use '-q -f' options? Version-Release number of selected component (if applicable): gtk3-3.15.7-1.fc23 How reproducible: easily Steps to Reproduce: just touch a relevant .icon-theme.cache and try to run gtk-update-icon-cache without --force Additional info: I see a similar problem reported some years ago as bug 500163 and purportedly fixed upstream. If this is really the case then it resurfaced.
the fix from 2009 only applied with --force. I've now made it apply regardless - pushed upstream, will hit fedora in the near future.
gtk3-3.14.12-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gtk3-3.14.12-1.fc21