I have 3 bugs to report on KDE x64 current. See attachments.

The first one is related to some packages that were built outputting their executables into /usr/lib64 instead of /usr/bin.

The second one (maybe an upstream issue) is dolphin's internal search not always finding text inside files.

The third one is dolphin's internal search crashing kdeinit5 when searching from the /.

Thanks for the hard work. Building KDE is something, I know!

Attached Thumbnails

     

1) these binaries have nothing to do in /usr/bin, they are just backends for plasma ( baloo_file_extractor, drkonqi, xdg-desktop-portal-kde, etc...)

2) Dolphin consider these files as "PAK archive" not "ASCII text". (see screenshot 1)
edit : because the first line of each file starts with the word "PACKAGE"

3) No issue here. Are you running plasma-x11 or plasma-wayland ? (see screenshot 2)

Attached Thumbnails

   

1 members found this post helpful.

AFAIK, /usr/lib64 should not have executable files but only libraries (hence the name). And Kubuntu is coherent in this regard (I checked it). To fix this is just a matter of changing variables in the building script.

I haven't tried this on Kubuntu, but maybe is an upstream issue/limitation, yeah.

X11. You can easily replicate this issue using Slackware live.

Thanks!

This is where Ubuntu put drkonqi binary (e.g.), same for Debian:
And archlinux :
And it's the same for all this kind of binary

My thought : upstream issue must be reported upstream

Slackware Live is not officialy supported by Slackware®
Anyway, no issue here with a Slackware installation with x11

Yeah, BUT on Debian and Ubuntu, they use this "/usr/lib/x86_64-linux-gnu" structure concept (I guess for multi-multilib), so translating on Slackware-ish, this would be "/usr/libexec"

I tell you this as a long term Ubuntunian which I am.

In my humble opinion, there: /usr/libexec is where should go Plasma5 backends, services and alike on Slackware.

It's quite strange to find /usr/lib64/xdg-desktop-portal-kde which is a DBUS service, after all...

Yes, looks like we have some issues on packaging Plasma5, at least.

If Arch does the same packaging mistakes, this is another story.

About issue 3: this has been fixed recently and as far as i can see the latest slackware live if from 2021-09-08, so it probably doesn't contain the fix yet.

2 members found this post helpful.

About issue 2, Doplhin uses Freedesktop's shared mime database to detect file types (https://specifications.freedesktop.o...ec-latest.html)
We can fix it just by adding a definition for Slackware package logs, like this one:
Save it as /usr/share/mime/packages/application-vnd-slackware-package-log.xml and then run
Now Dolphin will correctly detect those files as text files, so they will be included in searches and opened by default with a text editor (see attached picture)

Attached Thumbnails

 

and here it is

issue 1 : not an issue, except for Ubuntu & LuckyCyborg 😊
Joking aside, I don't really have the expertise to determine whether this is the case or not.

issue 2 : fixed

issue 3 : fixed

Yeah, on Kubuntu some of these executable files are inside /usr/bin, some are inside /usr/lib/x86_64-linux-gnu/libexec (see attachments).

Regarding dolphin's search not finding inside files, I appreciate the effort, but I was not thinking about fixing the issue for any specific file type. The idea would be make it read inside all file types. But it seems like an upstream issue anyway, so never mind.

I've just tested Slackware current again and indeed searching from / isn't crashing kdeinit5 anymore.

Thank you, guys!

Attached Thumbnails

   

Comparing the cmake files in Plasma to the ones we had for Slackware 14.2's KDE4, I see that we never previously declared -DKDE_INSTALL_LIBEXECDIR=lib$LIBDIRSUFFIX. And, I also see the issue came up for discussion on Alien BOB's blog a couple years ago.

I'm not opposed to removing those lines and letting the binaries be installed to the upstream default locations. It looks like that would generally be /usr/lib${LIBDIRSUFFIX}/libexec.

I doubt there would be any functional difference, but at least the executables would be out of the library path directory. Probably it would be best to recompile all of Plasma just to be sure that nothing would still look for the files in the old locations.

Any thoughts about this, folks?

Mr. Volkerding, I see that Slackware already uses /usr/libexec and there are lots of binaries from various packages, starting with the almighty Xorg: /usr/libexec/Xorg and its wrapper.

How about to be used -DKDE_INSTALL_LIBEXECDIR=libexec or -DKDE_INSTALL_LIBEXECDIR=/usr/libexec ?

True, at my limited experience I am unable to evaluate the impact to multilib of this setup, but looks like multilib somehow already survive even with those many binaries on /usr/libexec .

2 members found this post helpful.

It's more about of consistency, as long as there are no real functional issues.
So I agree with /usr/libexec

I know. Call me Perfectionist - you will not be the first.

Some time i write in some part something similar to /usr/share ,,, all plasma apps make

/usr/share/APP

instead of all go into


/usr/share/plasma/APPS or similar , i remeber in kde4 we have all stuff under

/usr/share/kde4

but now a million of new folders with shared objects from plasma , instead all in one place , im no sure if we can do similar like kde4 and put all shared things under /usr/share/plasma

I'd rather not specify a new location. If this one is no good, then let's fall back on the upstream default.