Vanilla KDE 19.05.23

After installing Vanilla-KDE (see Plasma is Great!) I found something which is not good:

When starting Discover I get the text:
No applications back-ends found, please report to your distribution

Texts in Octopi when re-installing Discover:

Installing selected packages...

warning: discover-git-5.16.80.r7242.g9a973871-1 is up to date -- reinstalling
resolving dependencies...

:: There are 2 providers available for xdg-desktop-portal-impl:

:: Repository extra

looking for conflicting packages...
Packages (10) bubblewrap-0.3.3-1 geoclue-2.5.3-1 geocode-glib-3.26.1-1 ostree-2019.2-1 pipewire-0.2.5+3+g371da358-1
xdg-dbus-proxy-0.1.1-1 xdg-desktop-portal-1.2.0-2 xdg-desktop-portal-gtk-1.2.0-1
discover-git-5.16.80.r7242.g9a973871-1 flatpak-1.3.4-2
Total Download Size: 11.69 MiB
Total Installed Size: 35.85 MiB
Net Upgrade Size: 25.47 MiB

:: Retrieving packages...

(1/10) ostree-2019.2-1-x86_64
(2/10) bubblewrap-0.3.3-1-x86_64
(3/10) xdg-dbus-proxy-0.1.1-1-x86_64
(4/10) pipewire-0.2.5+3+g371da358-1-x86_64
(5/10) geocode-glib-3.26.1-1-x86_64
(6/10) geoclue-2.5.3-1-x86_64
(7/10) xdg-desktop-portal-gtk-1.2.0-1-x86_64
(8/10) xdg-desktop-portal-1.2.0-2-x86_64
(9/10) flatpak-1.3.4-2-x86_64
(10/10) discover-git-5.16.80.r7242.g9a973871-1-x86_64
checking keys in keyring
checking package integrity
checking for file conflicts
checking available disk space

:: Processing package changes...

(1/10) installing ostree
(2/10) installing bubblewrap
(3/10) installing xdg-dbus-proxy
(4/10) installing pipewire
Created symlink /etc/systemd/user/ -> /usr/lib/systemd/user/pipewire.socket.
(5/10) installing geocode-glib
(6/10) installing geoclue
Optional dependencies for geoclue
(7/10) installing xdg-desktop-portal-gtk
Optional dependencies for xdg-desktop-portal-gtk
evince: Print preview
(8/10) installing xdg-desktop-portal
(9/10) installing flatpak
(10/10) reinstalling discover-git

:: Running post-transaction hooks...

Updating linux50 initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux50.preset: 'default'
-> -k /boot/vmlinuz-5.0-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.0-x86_64.img
==> Starting build: 5.0.18-1-MANJARO
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.0-x86_64.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux50.preset: 'fallback'
-> -k /boot/vmlinuz-5.0-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.0-x86_64-fallback.img -S autodetect
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.0-x86_64-fallback.img
Updating icon theme caches...
Reloading system manager configuration...
Creating system user accounts...
Creating temporary files...
Arming ConditionNeedsUpdate...
Updating the desktop file MIME type cache...

Command finished OK!

When starting Discover now, it works - no more error message.

you need
flatpak fwupd packagekit-qt5
and snapd if you want snap integration but need to install discover-snap from aur.
may be in future appimagelauncher libappimage.


I just installed Vanilla KDE in a VM . Updated it through the teminal and rebooted before looking at Discover . No issues with it , I'll try running the next set of updates through Discover itself just to see what happens .

We added the needed packages for a future release.


Since I installed it, now 5 days ago, I experienced a higher CPU use than normal. Conky showed around 15% CPU when idle, where it was around 2-3%. Fan spins at a slightly higher rpm value which makes it a bit noisy.
I then restored the "old" unstable KDE release but CPU staid at the same level, which made me think it is not the different edition causing that.
Looking at top and htop didn't really show me something with a higher than normal CPU use, until I saw that Conky itself was in the top 10. Didn't recall ever seeing it so high in the list.
In the conkyrc file I had added some lines from a previous conkyrc file and I put "#-signs" in front of those lines. After a Conky restart CPU use was back to normal. Aha!
Then one by one I left the #-sign and found this line to be the culprit:

#Plasmashell:  ${exec plasmashell --version | cut -c 13-19}

So, next step was restoring the vanilla-KDE backup, which means I am using it again.

1 Like