https://bugs.kde.org/show_bug.cgi?id=510287
FlyingSock <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #41 from FlyingSock <[email protected]> --- I hit this on Gentoo (kservice 6.29.0, Plasma 6.7.5) and (using claude) found the cause on my system: a third-party menu fragment in applications-merged that lists a system AppDir. What follows is claude's summary of the issue: In my case it was /etc/xdg/menus/applications-merged/cisco-secure-client.menu, left behind by Cisco's installer. Its relevant lines: <Menu> <AppDir>/usr/share/applications</AppDir> <DirectoryDir>/usr/share/desktop-directories</DirectoryDir> <Name>Applications</Name> ... What happens: 1. <DefaultAppDirs/> expands to /usr/share/applications, /usr/local/share/applications, ~/.local/share/applications, in that order, so the user dir comes last and wins. 2. The fragment is merged in after that and repeats /usr/share/applications. foldNode() in vfolder_menu.cpp drops the earlier duplicate AppDir and keeps the later one, so the scan order becomes /usr/local/share, ~/.local/share, /usr/share. 3. loadApplications() -> addApplication() -> m_serviceFactory->addEntry(): the file read last wins, so /usr/share/applications/foo.desktop replaces ~/.local/share/applications/foo.desktop. This is visible in the debug log: QT_LOGGING_RULES='kf.service.*=true' kbuildsycoca6 --noincremental 2>&1 | grep 'Looking up applications' With the fragment: Looking up applications under "/usr/local/share/applications/" Looking up applications under "/home/<user>/.local/share/applications/" Looking up applications under "/usr/share/applications/" Without it: Looking up applications under "/usr/share/applications/" Looking up applications under "/usr/local/share/applications/" Looking up applications under "/home/<user>/.local/share/applications/" It reproduces in a clean environment (fresh XDG_DATA_HOME/XDG_CACHE_HOME, XDG_CONFIG_DIRS pointing at a copy of /etc/xdg/menus): with the fragment the sycoca keeps the system Exec line, and without it the override's Exec line wins. It also explains comment #38: kmenuedit writes the env vars to the user file, but the system file then replaces it in the sycoca, so the dialog shows the old values. And it fits the "works on one machine but not the other" reports (comments #0 and #29), since it depends on which fragments are installed. As far as I can tell kservice follows the menu spec here: later <AppDir> elements take priority on collisions, and for duplicates "the last duplicate in the file should be used when establishing the order in which to scan the directories". So one fragment can quietly demote every user override. Possible mitigations: have kbuildsycoca warn when a merged file moves an AppDir behind XDG_DATA_HOME/applications, or ignore AppDirs in merged files that are already covered by <DefaultAppDirs/>. For the other reporters, this shows whether you're affected (no output means no such fragment): grep -H '<AppDir>' /etc/xdg/menus/applications-merged/*.menu ~/.config/menus/applications-merged/*.menu On my system it printed: /etc/xdg/menus/applications-merged/cisco-secure-client.menu: <AppDir>/usr/share/applications</AppDir> Removing the leftover fragment and running kbuildsycoca6 --noincremental fixed it for me (editing the file to just remove the AppDir line would also work if you need the rest of the file). -- You are receiving this mail because: You are watching all bug changes.
