Description of problem: In /usr/share/applications/kde4/knetattach.desktop there is a line Exec=knetattach and a corresponding menu entry shows up in menus if kdebase-runtime is installed. But 'knetattach' is now in /usr/libexec/kde4/knetattach (it used to be /usr/bin/knetattach in F8) and attempts to start from menu end up with missing program. It runs without any problems when a full path is used. Version-Release number of selected component (if applicable): kdebase-runtime-4.0.5-2.fc9
That sounds like an upstream bug to me.
And IMHO the problem is that it's in libexec in the first place. libexec is for internal KDE executables, not for stuff which ends up in desktop files.
It's the intention to install it in libexec. The kde upstream wants to avoid the file conflict with mixed KDE3/KDE4. The line Exec=knetattach is correct. KDE attempt to search the program in standard path /usr/libexec/kde4/:/usr/bin. I cannot reproduce this bug here. Could you please try again? Thanks
Maybe he's trying to run it under GNOME or something?
it only works under KDE, so if someone atempt to start it under other desktop enviroment it wont work. We should either make it only showed in KDE or move it back to /usr/bin.
Maybe /usr/libexec/kde4/ is in a "standard path" in some situations but it is definitely not in this "standard" when you have a GNOME desktop and where knetattach shows up in a "standard" menu. As I said before - even if /usr/libexec/kde4/ is not in PATH running /usr/libexec/kde4/knetattach at least starts without any issues (from a terminal window opened on a GNOME desktop too).
it's fixed in kdebase-runtime-4.1.1-2