The function postprocess_desktop_entries (called from kde.eclass kde_pkg_preinst) moves .desktop file entries from ${PREFIX}/share/applnk to ${PREFIX}/share/applications/kde. In the case of kmenuedit-3.5.7 and several other packages - use for F in /usr/kde/3.5/share/applications/kde/*.desktop; do echo -n "$F: "; (cat $F|wc -l); done and look for low line count to find out which ones - the Makefile produces an invalid .desktop file in the applnk directory which then overwrites the valid one in the applications/kde.The result in this special case is that you can't call the kmenueditor from the K symbol's context menu any more. I don't know what the point of postprocess_desktop_entries is at all, otherwise I'd try to come up with some kind of fix. Perhaps just making sure no file is clobbered in the mv action would be enough...? Reproducible: Always
As a quick band aid I've added the following check for an existing desktop file (which is hopefully good) in the destination directory before moving a potentially broken one from its legacy location there: if [[ ! -f ${D}${PREFIX}/share/applications/kde/$(basename ${entry}) ]]; then ... fi This fixes kmenuedit and at least shouldn't make anything worse. Carlo, please double-check this solution. Leaving this bug open for review.
Created attachment 120508 [details] tested kde packages
I tested the fix: I copied /usr/kde/3.5/share/applications/kde to kde.bak, re-emerged all my kde packages (see 'tested kde packages' attachment), and diff'ed the kde with kde.bak directory. Outcome: before re-emerging, the following desktop files were broken (i.e. three lines long, with only 'Encoding' and 'Hidden' attributes set): kappfinder.desktop from kappfinder-3.5.7 keditbookmarks.desktop from konqueror-3.5.7 kmenuedit.desktop from kmenuedit-3.5.7 kpager.desktop from kpager-3.5.7 kpersonalizer.desktop from kpersonalizer-3.5.7 ktip.desktop from ktip-3.5.7 Then there is panel_appearence.desktop from kcontrol-3.5.7, which is five lines long and might or might nor be broken. After re-emerging, the desktop files associated with kappfinder kmenuedit kpager kpersonalizer ktip are fixed, all other desktop files in /usr/kde/3.5/share/applications/kde are unchanged. That leaves four (possible) problems: 1) keditbookmarks.desktop, for which verbose counterpart exists 2) panel_appearence.desktop, same thing 3) Why are these three-liners created in the first place? Do they serve some purpose? Is this an upstream bug? 4) Are there any more cases of this problem in the rest of the kde packages?
(In reply to comment #3) > 1) keditbookmarks.desktop, for which verbose counterpart exists Make that: 1) keditbookmarks.desktop, for which _no_ 'verbose' counterpart exists
So I took a look at $WORKDIR/kmenuedit-3.5.7/kmenuedit/Makefile and found the source of the three-liner desktop files in this task: install-data-local: uninstall.desktop $(mkinstalldirs) $(DESTDIR)$(kde_appsdir)/System $(INSTALL_DATA) $(srcdir)/uninstall.desktop $(DESTDIR)$(kde_appsdir)/Sys tem/kmenuedit.desktop KDE docs have to say this about it: http://developer.kde.org/documentation/other/makefile_am_howto/en/_uninstalling_a_desktop_file_.html So cleanest solution would perhaps be to check if the .desktop file is a three-liner before moving it, and throw a warning or error if a file is going to be clobbered when trying to move it.
Created attachment 120515 [details] kde-functions.eclass patch to filter uninstall.desktop files Made a patch... still rather hackish, as the slightest change to the uninstall.desktop file upstream will break it.
Thanks for the patch, Andreas. Your help is greatly appreciated. After consulting with other kde herd members, we agree that this is not the best solution but we currently don't have a better one either. To prevent more problems for other users, I've applied your patch after extensive testing.
Sweet, got a script to find out what packages I have installed broken? Guess I timed the upgrade to 3.5.7 in a very bad time :)
Created attachment 120629 [details] broken_desktop_files Very quick and dirty script to find "uninstall" desktop files.
Ok, no follow-ups on this so this is fixed until they change the "uninstall" format.
