Bug 442011 - kbuildsycoca: No desktop entries on Kinoite with UTC timezone
Summary: kbuildsycoca: No desktop entries on Kinoite with UTC timezone
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kservice
Classification: Unclassified
Component: general (show other bugs)
Version: 5.94.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Timothée Ravier
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-04 19:47 UTC by Timothée Ravier
Modified: 2022-05-17 16:08 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timothée Ravier 2021-09-04 19:47:33 UTC
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.
Comment 1 Timothée Ravier 2021-11-09 18:51:13 UTC
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.
Comment 2 Timothée Ravier 2021-11-15 20:25:54 UTC
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.
Comment 3 Yosuke Matsumura 2022-04-29 20:34:57 UTC
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();
Comment 4 Timothée Ravier 2022-05-12 11:28:22 UTC
Thanks a lot for the debugging. Will try a patch.
Comment 6 Yosuke Matsumura 2022-05-15 21:21:25 UTC
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.
Comment 7 Timothée Ravier 2022-05-16 08:41:07 UTC
I'll make this one about Kinoite with UTC and clone the bug for the other issue.
Comment 8 Timothée Ravier 2022-05-16 08:48:48 UTC
Other issue in https://bugs.kde.org/show_bug.cgi?id=453876
Comment 9 Ahmad Samir 2022-05-16 18:04:38 UTC
@Yosuke: good investigative work, thanks.
Comment 10 Timothée Ravier 2022-05-17 13:03:52 UTC
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.