Installing KDE onto TrueOS


Try plugging in an external microphone first before you give up. A lot of systems only present options like “mic” when an actual microphone is detected.

Also make sure your laptop actually has a microphopne built-in. I got bit by that once where I just bought a new laptop but for the life of me I could not get the webcam/microphone to work - turns out I accidentally bought the “business” model which had disabled/removed all those “distracting” features.


KDE was/is nice GUI desktop, best fit for *linux distributions. I think that Open SUSE incorporates KDE/Plasma in the most elegant and clean way, nowadays. But, I am *Linux dropout, so I don’t care much for KDE now.
Same here in my Dell-M4600, the cam shines but no presence of any mic. If I need to communicate with some kind of video chat tool, I’ll pretend to be deaf and use sign language - lol


I’m not sure why KDE would fit better with either Linux or FreeBSD so long as it’s working properly. It’s true that pretty much any DE other than Lumina risks breaking due to Linux-isms creeping into the the code and a lack of focus on FreeBSD during their development and testing, but as long as they work, they’re pretty much OS-agnostic so long is it’s a *nix system. In some respects, the DE defines the OS experience far more than the kernel and base programs do (at least for a desktop system), and that’s largely going to be the same no matter what OS they’re running on top of.

But use whatever you like. There are plenty of DE options available for a range of tastes. No DE is going to please everyone.


According to recent quarterly updates for FreeBSD there has been some momentum within the KDE project to make plasma 5 a first class citizen on FreeBSD.


I hope it won’t make you give up on Lumina.

Installed most recent UNSTABLE and compared to summer, progress seems to be great.
Last UNSTABLE feels like being pretty stable as well, haven’t had any issues wit it yet.
(UEFI install)


Aside from the fact that I expect that the TrueOS developers (and Ken in particular) are quite invested in Lumina from having spent as much time on it as they have, Lumina is something that the TrueOS developers have control over and can do what they want with. They don’t have to worry about whether KDE or any other Linux-centric DE works well on FreeBSD or whether it will continue to do so. They don’t have to worry about whether any upstream changes to the DE fit with what they want. They also don’t have the problem of the 3rd party DE working with FreeBSD 11 but not 12 (and thus not TrueOS), since that sort of problem does happen with some software.

Aside from the amount of time and effort required to work on Lumina, having Lumina is mostly all upsides for the developers, and they’re obviously able to spend the time to make it work, since they’re already doing it.

As a longtime KDE user, I very much want KDE to be a first class citizen on FreeBSD, and I’d much prefer to use it than have to switch to Lumina, but I also don’t see any reason for the Lumina guys to stop what they’re doing, and I wouldn’t expect them to, even if we somehow reached the point that KDE was just as well supported on FreeBSD as Linux.


the PITA (Pain In The Arse) with gnome and kde.

They are designing with linux in mind, and integrating it into the SystemD life support system.

There will come a point when it can’t be ported


If FreeBSD were truly treated as a first-class citizen by the KDE folks like jmaloney has said that some progress has been made towards, then that would be avoided, because the KDE folks would be operating in a manner that ensured that KDE worked on both Linux and FreeBSD. However, if the KDE folks can’t be convinced to make sure that KDE works on unixes other than Linux, I agree that at some point, we probably will be screwed when it comes to running KDE on anything other than Linux. I’m sure that it will always be possible to make it work, but if systemd were integrated tightly enough into KDE, then the work required to make it work on FreeBSD could definitely exceed that of what’s reasonable. And given how long KDE 5 has been around, the fact that it’s not in ports yet (much as they have been doing work towards that) would definitely imply that the amount of manpower towards making KDE work on FreeBSD is pretty low (and/or the KDE guys have done a lot of Linux-specific stuff already that’s making it a huge pain).


In the next few years, see how many ports drop, because they will rely on the crapware called SystemD.

I do hope jmaloney is right, for once (hello joe). choices are good


I was going to ask @jmaloney for a link, but I found it.


That does have some good info, but since he mentioned the quarterly report, I think that this is what he was referring to:

Probably the biggest thing there is that FreeBSD is now a tier-1 platform in KDE’s CI system, which should seriously reduce the odds of KDE breaking on FreeBSD.


This is may be very stupid but I just installed KDE Plasma 5 on TrueOS and it seems to work fine.
I just followed the instructions from Area51. But my /usr/local/etc/pkg/repos/area51.conf looks like this:

FreeBSD: { enabled: false }
    area51: {
    url: ""
    priority: 2
    enabled: true

And then I ran sudo pkg install kde5 and startkde, both from xterm.
KDE was added to the TrueOs login manager and so far so good.


I have enough unexplained events in Lumina with TrueOS-UNSTABLE release, from known sources.
Now, someone is trying Plasma 5 in TrueOS/FreeBSD, from Area51, which most likely will bring more unexplained events into TrueOS with KDE - hehe.


Well for me Lumina is unstable so I have not used TrueOS since Chrome crashes after about 60 seconds after launch; most of the time Firefox crashes before it launches . QTerminal crashes after about five minutes if I do sudo pc-updatemanager pkgupdate so I don’t have anything to lose. Plasma5 is as stable on TrueOS as on Linux (KDE Neon) so now I can use my TrueOS installation. Neither Plasma or QTerminal, Firefox or Chrome crashes anymore.

But, no, I would not recommend anyone to run Area51 unless your installation is as unstable as mine.



If on UNSTABLE, from a terminal type --> sudo pkg info | grep gcc-ecj <-- and report either way


Along the same lines as @RodMyers, it sounds like you have other issues with your systems rather than anything with Lumina, since Lumina does not effect applications at all. If an app like Firefox or chromium is crashing, then something associated with that utility is having trouble, not the desktop that happens to be running at the time.
In particular, Rod is referring to a known issue where installing the GCC compiler instantly start causing GTK-based applications to behave erratically and crash frequently - in part becuase of the “gcc-ecj” plugin, and in part because a number of applications (such as the ones that are crashing) are written on/for Linux and if they see the gcc libraries installed they will automatically link/use them instead of the FreeBSD libraries with the same name!!

So the moral of this story is that if you are having crashes or system instability like this, please report it! More often than not, we can track down the problem and/or give you a solution (example: the “gcc-ecj” issue should be fixed on UNSTABLE).


I switched to UNSTABLE since I had the problems described in my previous post on STABLE. So I figured my problems would be addressed sooner on the UNSTABLE branch. I could try to switch back to STABLE if it is helpful.

Output from sudo pkg info | grep gcc-ecj:

gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java


that is the cause of your crashing

in the terminal type --> sudo pkg delete gcc-ecj

note what will be removed. if you can live with what will be removed, type --> y <-- and remove it


I’m not sure about this because I didn’t test this. But, nonetheless:

Maybe, it’s possible to add a ${…LIB…} variable to the default process environment for executables with origin from the Linux-world. This could possibly mitigate the problems with dynamic linking and GCC.


Yes, we have been looking into solutions like that but are trying to find one that does not require patching every single GTK application port. If that is the only way to fix this, then we are going to have to get the FreeBSD porting community involved in the patches and wait on them to fix it, simply because there are so many ports that do this and we don’t want to maintain our own special “blend” of patches to ports (we try to keep port differences between FreeBSD/TrueOS to a minimum when possible).