Testers needed for the Plasma5 20.0 release

#Lysia release is really close now. So we managed to spin the latest RC for our Plasma5 (KDE) edition. @oberon did a great job to tweak the most out of it.

Our KDE edition provides the powerful, mature and feature-rich Plasma 5.18 desktop environment with a unique look-and-feel, which we completely re-designed in 2020.

  • full set of Breath2-themes includes light and dark versions
  • animated splash-screen
  • Konsole profiles
  • Yakuake skins and many more little details.

We have rounded off text editor Kate with some additional color schemes and offer Plasma-Simplemenu as an alternative to the traditional Kickoff-Launcher.

With a wide selection of latest KDE-Apps 20.04 and other applications Manjaro-KDE aims to be a versatile and elegant environment ready for all your everyday needs.


Tell us what you think and give us constructive feedback. We expect to release this weekend if no regressions are found by then.


@philm are those of us that received the last 2 sets of testing updates going to automatically get the updates from this RC build? If not no biggy. Thanks

I am afraid of the "unstable" because I am a novice, but excellent news!
In itself it is a great satisfaction to be able to configure everything in our own way and thus be more productive. If someone uploads screenshoots of the changes, I will be grateful.

1 Like

Nvm it got fixed, Hope for the best for KDE 20.0.0 update

There's just the default profile. The animated splash-screen is awesome. :slight_smile:

Edit: I could not remove the pager while the panel was docked on the left screen edge, had to move the panel to the default position to do that.

Very good work, this .iso has some really good defaults and polished to shine! :slight_smile:

Few things still deserve fix / look:

  1. After first boot - it still takes about minute or more of looking at black screen on HDD (on SSD it's little faster, but still a lot of black screen for no apparent reason)...That's real shame, because it's only KDE edition which acts that way to my knowledge, and no other DE Manjaro edition does same...

    There must be something wrong with initial setup of Manjaro KDE specific things, please fix it.

  2. It makes so much more sense to use as default:



    Not sure on options though, but with just changing extension - it's insanely much faster to make packages, especially if it's some big build, like WPS office for example.

    Surely package file size is somewhat bigger, but speed is not even close in comparison! :slightly_smiling_face:

  3. @oberon more of a question, than anything...As someone heavily invested in audio, i've noticed that KDE editions, compared to let's say your previous Deepin one has:

    fs.inotify.max_user_watches = 16384

    According to realtimeconfigquickscan this is one of those things that can't be good for audio, unless...(Manjaro Deepin for example had no 50-max_user_watches.conf present)

    Checking checking sysctl inotify max_user_watches... >= 524288 - good

    Is there any particular reason to use this value specifically in KDE? If not, maybe we could follow other editions which are little more audio friendly by default?

    Rest of settings from this script and audio/video use in general may be questionable for average user, no doubts, but that particular settings i'm not sure :slight_smile:

  4. Why Balena Etcher again...? We have established previously in lounge that it's not safe :expressionless:


No ! we build package for aur and pamac not use compression by default : is much faster

Oh, i always build myself with makepkg -s to review changes manually and all that...
As i don't really trust AUR that much and like to prep my packages for doomsday. :upside_down_face:

I thought it's exactly same for pamac, but if it's conflicting then it's fine..

This morning, I installed a kde-based system using architect using test repositories to test the RC branch. At the moment, everything is fine, if there are problems, I will let you know, thanks.

1 Like

I have no idea why the kde profile has this file. It has been there for years and none of the others has it. I will just remove it.


Clean install to VirtualBox. I can try on real HW, if a new ISO is not imminent.

1 Like

Absolutely nothing to report.
Everything works after multiple attempts at perfection.
Really great work.

1 Like

VM was fine, but on real HW, I could not get the ISO to boot to a graphical environment.

  • With Free Drivers, I saw SDDM start, I saw a cursor, and the Enjoy the Simplicity splash screen, and it hung there, and I had to hard power-off. I could not get to a TTY.
  • With Non-free Drivers, it seemed as if I got less far. I saw [ OK ] Started TLP System Startup/Shutdown and it appeared to hang, but from there I was able to Ctrl Alt F4 to a TTY where I could systemctl poweroff.
$ inxi -Fxxxz
System:    Host: marco-T61 Kernel: 5.4.34-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.3.0 
           Desktop: KDE Plasma 5.18.4 tk: Qt 5.14.2 wm: kwin_x11 dm: SDDM Distro: Manjaro Linux 
Machine:   Type: Laptop System: LENOVO product: 64574UU v: ThinkPad T61 serial: <filter> Chassis: type: 10 
           serial: <filter> 
           Mobo: LENOVO model: 64574UU serial: <filter> BIOS: LENOVO v: 7LETC1WW (2.21 ) date: 07/01/2008 
Battery:   ID-1: BAT0 charge: 0 Wh condition: 62.9/84.2 Wh (75%) volts: 4.8/10.8 model: Panasonic 42T4620 
           type: Li-ion serial: <filter> status: Unknown 
CPU:       Topology: Dual Core model: Intel Core2 Duo T7300 bits: 64 type: MCP arch: Core Merom rev: B 
           L2 cache: 4096 KiB 
           flags: lm nx pae sse sse2 sse3 ssse3 vmx bogomips: 7982 
           Speed: 1401 MHz min/max: 800/2001 MHz boost: enabled Core speeds (MHz): 1: 798 2: 798 
Graphics:  Device-1: NVIDIA G86M [Quadro NVS 140M] vendor: Lenovo ThinkPad T61 driver: nvidia v: 340.108 
           bus ID: 01:00.0 chip ID: 10de:0429 
           Display: x11 server: X.Org 1.20.8 driver: nvidia compositor: kwin_x11 resolution: 1680x1050~60Hz 
           OpenGL: renderer: Quadro NVS 140M/PCIe/SSE2 v: 3.3.0 NVIDIA 340.108 direct render: Yes 
Audio:     Device-1: Intel 82801H HD Audio vendor: Lenovo ThinkPad T61/R61 driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 chip ID: 8086:284b 
           Sound Server: ALSA v: k5.4.34-1-MANJARO 
Network:   Device-1: Intel 82566MM Gigabit Network vendor: Lenovo ThinkPad T61/R61 driver: e1000e v: 3.2.6-k 
           port: 1840 bus ID: 00:19.0 chip ID: 8086:1049 
           IF: enp0s25 state: down mac: <filter> 
           Device-2: Intel PRO/Wireless 4965 AG or AGN [Kedron] Network driver: iwl4965 v: in-tree:d port: 2000 
           bus ID: 03:00.0 chip ID: 8086:4230 
           IF: wls3 state: up mac: <filter> 
Drives:    Local Storage: total: 111.79 GiB used: 54.42 GiB (48.7%) 
           ID-1: /dev/sda vendor: PNY model: CS1311 120GB SSD size: 111.79 GiB speed: 1.5 Gb/s serial: <filter> 
           rev: 1122 scheme: MBR 
Partition: ID-1: / size: 101.32 GiB used: 54.42 GiB (53.7%) fs: ext4 dev: /dev/sda1 
           ID-2: swap-1 size: 8.34 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2 
Sensors:   System Temperatures: cpu: 61.0 C mobo: 55.0 C gpu: nvidia temp: 67 C 
           Fan Speeds (RPM): fan-1: 3007 
Info:      Processes: 180 Uptime: 2m Memory: 3.78 GiB used: 1.37 GiB (36.2%) Init: systemd v: 245 Compilers: 
           gcc: 9.3.0 Shell: bash v: 5.0.16 running in: yakuake inxi: 3.0.37 


This specifies an upper limit on the number of watches that can be created per real user ID

Listen uses inotify by default on Linux to monitor directories for changes. It's not uncommon to encounter a system limit on the number of files you can monitor. For example, Ubuntu Lucid's (64bit) inotify limit is set to 8192.

The issue

When dropbox or guard says like:

  • Unable to monitor filesystem Please run: echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches and restart Dropbox to correct the problem.
  • No space left on device - Failed to watch "…": The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource. (Errno::ENOSPC)

Is it safe to raise that value and what would be the consequences of a too high value?

Yes, it's safe to raise that value and below are the possible costs [source]:

  • Each used inotify watch takes up 540 bytes (32-bit system), or 1 kB (double - on 64-bit) [sources: 1, 2]
  • This comes out of kernel memory , which is unswappable.
  • Assuming you set the max at 524288 and all were used (improbable), you'd be using approximately 256MB/512MB of 32-bit/64-bit kernel memory.
    • Note that your application will also use additional memory to keep track of the inotify handles, file/directory paths, etc. -- how much depends on its design

To see current value do

cat /proc/sys/fs/inotify/max_user_watches

But we probably want it highish. I see recommends at ex: 524288
From my limited research I might be comfortable with either 1/2 (262114) or 1/4 (131072) as well.
Based on some bug reports - 128k seems to be ceiling .. or floor.. for some. Though I guess it all depends on amount of stored data. If the above is to believed though, maybe setting a maximum of 128/256mb for kernel to monitor files is enough until proven otherwise.

(and yes though - whatever decided, this shouldnt be a DE-specific consideration.)


This lot of course was on the 19.0 ISO, so nothing has changed in that regard. It did exactly the same thing in Live environment but once installed, all Breath2 Konsole themes are available. EDIT - you can actually try them in live environment too. right click in the konsole terminal window and edit the profile.

@oberon & @bogdancovaciu I am not overly impressed with the latest iteration of the Breath2 Konsole themes. Feel free to carry on butchering them as I said all along you can do what you like with them but it would have been nice to have been involved in the discussions if there were any about such changes.

I'll keep my own going forward stored in my local folder for use with whichever distribution I see fit. I know there were compromises with it but on balance the new version has introduced far worse issues instead. You can deal with the mess yourselves because I won't be contributing anything further since you failed to ask for my input over the changes to my work.


just run it in live ISO or VM and see for yourself.

I found this, too, and tried to reproduce thre problem.
For me auto-updateb in dolphin works fine also without the file...

1 Like

I am sorry for the bad procedure. My fault, I should have contacted you first.
Yesterday someone in the team noticed that alsamixer was completely unusable with breath2 terminal colours and @bogdancovaciu kindly offered to take a look at the schemes. He didn't even know it was your contribution - my fault again that I didn't communicate that.
In any case apparently he found a few more issues with the way the colours where defined and uploaded his fix to the repo which I just quickly checked and packaged. To me the result looked great and more or less like before in general...
Sorry again for the bad miscommunication!
I'd hope that there could still be an exchange between the two of you about the problems of thre color-scheme and what was - or apparently still is - broken...
Thank you


I am testing the 20.0 release in a vm, so i don't know how this is of relevance?

No, not here.

Did you test RC2 or RC3? The first shipped with a broken kernel ...

Forum kindly sponsored by