Description of problem: Updated the system today and started to get: Jan 11 21:25:33 horizon.localdomain krunner[27070]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line Jan 11 21:25:33 horizon.localdomain krunner[27070]: kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" Jan 11 21:25:34 horizon.localdomain plasmashell[1838]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line Jan 11 21:25:34 horizon.localdomain plasmashell[1838]: kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" Jan 11 21:25:35 horizon.localdomain krunner[27070]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line Jan 11 21:25:35 horizon.localdomain krunner[27070]: kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" Jan 11 21:25:36 horizon.localdomain plasmashell[1838]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line Jan 11 21:25:36 horizon.localdomain plasmashell[1838]: kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" Jan 11 21:25:37 horizon.localdomain krunner[27070]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line Jan 11 21:25:37 horizon.localdomain krunner[27070]: kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" Version-Release number of selected component (if applicable): qemu-common-5.1.0-8.fc33.x86_64 plasma-workspace-5.20.5-1.fc33.x86_64 How reproducible: Every log in. Steps to Reproduce: 1.Just need to log in on a KDE session with virt packages installed. 2. 3. Additional info: Had to add a dummy Exec=/bin/true line there to avoid the loop/logging.
This is considered a bug in KDE. The desktop file is required in order to get icons to display, but there is no appropriate binary that is executable as a desktop app. Adding a fake Exec=/bin/true is wrong. KDE needs to remove the warning https://bugs.launchpad.net/qemu/+bug/1868221 https://bugs.kde.org/show_bug.cgi?id=430157
Thanks for sharing that. Briefly looking at the specification [1], I see in Table 3: "Program to execute for this action, possibly with arguments. See the Exec key for details on how this key works. *The Exec key is required if DBusActivatable is not set to true* in the main desktop entry group. Even if DBusActivatable is true, Exec should be specified for compatibility with implementations that do not understand DBusActivatable. " DBusActivatable is not specified, so it seems the key is actually required to be present? 1.https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables
(In reply to Marcelo Ricardo Leitner from comment #2) > 1.https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry- > spec-latest.html#exec-variables This is a better point in the doc: 1.https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions-keys
That quoted text belongs to "Extra actions" concept, which are defined by the "[Desktop Action XXX]" section, as opposed to the "[Desktop Entry]" part, so that's not applicable.
Ah sure, good point. A similar text is also present in [1] "Recognized desktop entry keys" -> "Table 2. Standard Keys" -> Exec, which AFAICU it's for "[Desktop Entry]" sections: "... The Exec key is required if DBusActivatable is not set to true. ..." 1.https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
Hmm, yes, I missed that before. I don't know what the best answer is though, because I think it is wrong to point to an bogus executable just to satisfy the spec, and there's no QEMU binary that's point & click launchable.
(In reply to Marcelo Ricardo Leitner from comment #0) > Additional info: > Had to add a dummy Exec=/bin/true line there to avoid the loop/logging. My original report here had two parts that I thought one led to another. - The .desktop that KDE is not liking much - The .desktop probe loop, causing log flood, and that I thought was originated by the above But not. I updated my system on Jan 18th and apparently it fixed the looping effect. $ rpm -qf /usr/share/applications/qemu.desktopqemu-common-5.1.0-9.fc33.x86_64 qemu-common-5.1.0-9.fc33.x86_64 $ rpm -qf /usr/share/applications/qemu.desktop | xargs rpm -V $ So I'm using the original .desktop file, the log msg is still there but shown only once and I'm not seeing the log loop/high CPU usage as before. $ journalctl --since=today |grep qemu Jan 24 10:31:49 horizon.localdomain sudo[221023]: mrl : TTY=pts/37 ; PWD=/home/mrl ; USER=root ; COMMAND=/usr/bin/yum reinstall qemu-common Jan 24 10:32:07 horizon.localdomain kded5[1685]: kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line Jan 24 10:32:07 horizon.localdomain kded5[1685]: kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" Attached is a list of package changes in between. There were some KDE related updates, but I couldn't pinpoint a particular bug for the above. With this, lets lower the priority. Now it's just a warning without major side effects :)
Created attachment 1750236 [details] pkg changes since the loop was reported Just for reference, in case anyone wants to track down what specificly was the looping/high CPU usage on KDE side.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.