SUMMARY In some cases (exact reproducible steps not found yet), Plasma will fail to display any application icon on Fedora Kinoite. On Fedora Kinoite, all files in /usr are set with the UNIX timestamp of 0. Running plasmashell in a terminal will show that line repeatedly: kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated Updating the timestamps on those files and running kbuildsyscoca5 temporarily fixes the issue. This is most likely due to a confusion in: https://api.kde.org/frameworks/plasma-framework/html/theme_8cpp_source.html#l00280 where lastModified is here truly 0 and not left to the default value. An option would be to use 1 instead when looking at a file with a 0 timestamp in the calling code but I have not found where this function is called yet. STEPS TO REPRODUCE 1. Clean icon cache 2. Set an application icon file, desktop entry, etc. timestamp to UNIX time 0 3. plasma-shell --replace OBSERVED RESULT Lots of: kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated Application has no icon. EXPECTED RESULT Applications has an icon. SOFTWARE/OS VERSIONS Fedora Linux 35 & Rawhide Linux/KDE Plasma: 5.22.4 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85 Qt Version: 5.15.2 ADDITIONAL INFORMATION This is similar to https://bugs.kde.org/show_bug.cgi?id=429196 but I could not get this working with the same workaround.
The exact reproducer is to install Fedora Kinoite (35) and choose an UTC timezone. Any other timezone will not display this issue. I'll try to reproduce this on a classic KDE system although I'm afraid it's linked to the timestamp issue.
From Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2021087 The mostly likely issue here is that on Kinoite, all files in /usr are timestamp 0 (thus using the UNIX origin timestamp). The fact that it manifest only on the UTC timezone might be because on other TZ, something in KDE will convert the date into a "local zone" timestamp/date which then won't be 0.
I think I've found the root cause (https://discussion.fedoraproject.org/t/kinoite-installation-with-utc-timezone-breaks-kde/34293/8?u=guiltydoggy). I think a change to the updateHash (https://github.com/KDE/kservice/blob/master/src/sycoca/kbuildsycoca.cpp#L610) to add 1 so that the hash no longer equals 0 may fix the problem, but I don't know what other impacts it may have: hash += fi.lastModified().toSecsSinceEpoch();
Thanks a lot for the debugging. Will try a patch.
https://invent.kde.org/frameworks/kservice/-/merge_requests/87
Sorry, it seems my analysis was mistaken and this patch does not fix the "findInCache with a lastModified timestamp of 0 is deprecated" message, but does fix usability of Kinoite when set to UTC timezone.
I'll make this one about Kinoite with UTC and clone the bug for the other issue.
Other issue in https://bugs.kde.org/show_bug.cgi?id=453876
@Yosuke: good investigative work, thanks.
Fixed by https://invent.kde.org/frameworks/kservice/-/merge_requests/87 Automation did not properly trigger as there was an email mismatch that I have now fixed.
I know this has been closed for a while, but my journal STILL is spammed by "kf.plasma.core: findInCache with a lastModified timestamp of 0 is deprecated" messages. If it's benign, it has no business being logged. But right now it's being written 50+ times per second, judging from journal logs, which is a bug in and of itself, and makes using the journal an unnecessary pain in the butt.
``` ~ % journalctl -b > out.txt ~ % uptime 17:12:54 up 4 days, 1:04, 2 users, load average: 4.16, 4.04, 4.00 ~ % grep 'kf.plasma.core: findInCache with' out.txt | wc -l 553628 ``` Right now it's being written 138,000 times PER DAY on my machine.
The affected code now lives in KSvg for Frameworks 6, FWIW.