Tag Archives: kde5

Replacing ConsoleKit2 with elogind – first steps

Well ūüôā This was a short reprieve.
I created a new batch of Plasma5 packages for Slackware-current as KDE-5_20.06. Be sure to read the upgrade instructions very carefully to prevent a total breakage, because this month’s batch is non-standard. More detail about the upgrade steps (like: remove ConsoleKit2 first!) to follow is in the bottom section of this post.

Why a new ‘ktown‘ release so soon after lamenting in my previous post that there would not be a new release for a while?

It is simple and complex at the same time, really.
I was fed up with monthly releases, they felt like a chore I could not get rid of. But the addition of PAM presented opportunities and since I had already declared that no public release should be expected for a while, I suddenly had time to research privately into a nagging problem that was always on the backburner: Wayland sessions in KDE Plasma5 for Slackware. I had this running somewhat, a couple of years ago but it is totally broken for Slackware today.
The Wayland implementation in KDE Plasma5 depends on a session API called “login1” which was originally defined and implemented by systemd and is for the most part (read: the relevant part) implemented in ConsoleKit2 as well. In the current state of software development, unfortunately ConsoleKit2 is blocking a successful Wayland implementation in Slackware; fixing this demands another core change in Slackware (next to PAM).
As if adding PAM was not ‘bad’ enough, we also need the spawn of systemd. Yes, I looked into elogind as a replacement for ConsoleKit2. The elogind sofware – exactly like eudev which we already have in Slackware – is a component of the systemd codebase, which has been isolated, sanitized, with changes away from the name ‘systemd’ and the code has been made fully independent of systemd.
I talked to Patrick about whether he would consider getting rid of ConsoleKit2. For me this was the only motive to continue dabbling with the ‘ktown’ scripts anyway. And he agreed, so I coded some scripting updates, and tested, and failed and failed. That did bad things to my mood, so I checked all my work-in-progress into a git branch and decided to leave it there for a while, simply because I did not have the time anymore, personal life demanded priority.
Some people noticed the new ‘elogind’ git branch, cloned it and continued the experiment. The resulting debugging effort resolved the dead-end I had been facing. And voila, a new package set was the result, with elogind added and thanking ConsoleKit2 for services rendered.
At the same time (thanks Patrick!) Pat Volkerding modified ‘/etc/rc.d/rc.M’ inside the sysvinit-scripts package, and ‘/etc/pam.d/login’ inside the util-linux package of Slackware-current so that they are now compatible with both ConsoleKit2 and elogind:

Thu Jun 18 22:01:29 UTC 2020
a/sysvinit-scripts-2.1-noarch-33.txz: Rebuilt.
  rc.M: add support for elogind. Thanks to alienBOB.
a/util-linux-2.35.2-x86_64-3.txz: Rebuilt.
  /etc/pam.d/login: support pam_elogind.so. Thanks to alienBOB.

followed one day later by the omitted fix to the ‘startx‘ script and a safeguard for those of you who can not read instructions and failed to remove the ConsoleKit2 package:

Fri Jun 19 19:59:04 UTC 2020
a/sysvinit-scripts-2.1-noarch-34.txz: Rebuilt.
  rc.M: check for elogind first so that we can ignore a stale CK2 package.
x/xinit-1.4.1-x86_64-2.txz: Rebuilt.
  When using elogind, start the session on the current console.
  Thanks to alienBOB.

This eased my job considerably. Consider the new ‘ktown’ release as a prep test for inclusion into Slackware.

Elogind and Wayland

Yes, Plasma5 Wayland sessions work now, thanks to the earlier PAM inclusion and now the elogind addition. You can start a Plasma Wayland session via SDDM (runlevel 4) by selecting it in the session drop-down menu.
And you can start a Plasma Wayland session at the console (runlevel 3) by executing the “startkwayland” command.

Note that with elogind as the session/seat manager instead of ConsoleKit2, you’ll see some new behaviour.
A quite obvious change: if you run ‘startx’ or ‘startkwayland’ at the console, you won’t see a VT (virtual terminal) switch. In the past, your console TTY would usually be tty1 but your graphical session would start on tty7 and you would automatically be switched from tty1 to tty7. This is no longer true – the graphical session will re-use your console TTY.
SDDM is still starting on tty7 but only because I make it do so via its configuration file.

Elogind adds a couple of commands which allow you to inspect the nature and status of the logged-in users and their sessions & seats. Check out “man loginctl”. To understand more about the elogind configuration options, read “man logind.conf”.

Running a Wayland session using the proprietary NVIDIA driver is possible – who’d have thought. For a long while, there was an unsurmountable incompatibility between Wayland protocol implementations and the proprietary drivers of Nvidia which historically support only X.Org. But Nvidia added EGLStreams support to their driver a few years back which opened a lot of possibilities.

EGLStreams¬†is one of the two APIs through which a Wayland compositor can talk to a GPU driver. The other API is GBM and this is the API used by all of the Linux kernel’s GPU drivers. All Wayland compositors support GBM, but support for Nvidia’s EGLStreams is limited (momentarily) to the Wayland compositors in KDE and Gnome.

Taken from https://community.kde.org/Plasma/Wayland/Nvidia you should prepare as follows.

  • Qt5 >= 5.15 is a requirement, luckily we already have that in Slackware.
  • X.Org release >= 1.20 is needed for EGLStreams support in XWayland, which means that all X Window clients which are started in your Wayland session will also have accelerated graphics rendering. Again, Slackware’s version of xorg-server is sufficiently new.
  • You need to enable modesetting in the kernel for the Nvidia driver. You can easily check (as root) whether kernel modesetting is enabled by running “cat /sys/module/nvidia_drm/parameters/modeset”. The command’s output should be “Y”.
    If you get a “N”, then you need to add the string “nvidia-drm.modeset=1” to the kernel’s boot commandline e.g. via the ‘append’ parameter in (e)lilo.conf or syslinux.cfg.
    For grub you can add that append-string to the GRUB_CMDLINE_LINUX_DEFAULT definition in the file “/etc/default/grub”, so that when you run “grub-mkconfig -o /boot/grub/grub.cfg” it will be added in every declaration block (thanks to willysr).
  • KWin needs to use EGLStreams for accelerated graphics support, as explained above, or else it will default to GBM and you won’t be happy with the¬† 1 FPS refresh rate on your monitor!
    You need to set the environment variable¬†KWIN_DRM_USE_EGL_STREAMS to the value of “1“.
    One way to do this is to create a profile script (e.g. “/etc/profile.d/kwin.sh”). Add the single line:


    and make that script executable. Or define this environment variable through any other means that you prefer, for instance if you are not using a bash-compatible shell.

After having played for a bit in a Plasma Wayland session on my desktop computer with a Nvidia card and using their proprietary driver, I can say that there are still some graphical quirks & glitches but I saw no showstoppers.

What else can you expect in KDE-5_20.06?

This June ktown release contains the KDE Frameworks 5.71.0, Plasma 5.19.1 and Applications 20.04.2. All this on top of the Qt 5.15.0 which recently got updated in Slackware-current.

I added the package autoconf-archive which was needed to recompile dbus. I added elogind (make sure to ‘removepkg ConsoleKit2’ first!) , and added two recompiled Slackware packages picking up elogind support: dbus and polkit.
I recompiled accountsservice to pick up elogind support as well, and recompiled polkit-qt5, libdbusmenu-qt5, qca-qt5 against the new Qt5 which was upgraded in Slackware since last month’s ‘ktown’ release.
And I recompiled grantlee-qt4 because I had forgotten to do so after the 2018 mass rebuild in Slackware… no-one noticed.

Frameworks 5.71.0 is an incremental stability release, see: https://kde.org/announcements/kde-frameworks-5.71.0. The Frameworks package which picks up elogind support is: solid.

Plasma 5.19.1 is the second increment of the 5.19 cycle, which means that I skipped the .0 release. See https://kde.org/announcements/plasma-5.19.1 and if you want to read more about the goals for 5.19 you should check out https://kde.org/announcements/plasma-5.19.0 .
There is a new package in Plasma: kwayland-server. The packages which pick up elogind support are: plasma-workspace, powerdevil, kscreenlocker.

In plasma-extra I rebuilt sddm-qt5 to pick up elogind support and added plasma-wayland-protocols as dependency for the new kwayland-server in Plasma.

Applications 20.04.2 is an incremental bug fix release, see also https://kde.org/announcements/releases/2020-06-apps-update/

For applications-extra, I tried (and failed) to update krita (I got boost related errors) but I did update kmymoney.

KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.

Where to get KDE Plasma5 for Slackware

NOTE: I will delay the release for a couple of hours to allow everybody to read this post and avoid updating blindly which would break graphical login sessions!

It should be obvious, but these packages will not work on Slackware 14.2. The old (KDE 5_17.11) Plasma5 packages that were still in my ‘ktown’ repository for Slackware 14.2 were removed last month because they were un-maintained and had security issues.

Download the KDE-5_20.06 for Slackware-current from the usual location at https://slackware.nl/alien-kde/current/ or one of its mirrors like http://slackware.uk/people/alien-kde/current/ .

Check out the README file in the root of the repository for detailed installation or upgrade instructions.

BIG FAT WARNING: Read these README instructions carefully! In short:

  1. UPGRADE TO THE LATEST slackware-current first.
  2. Then, REMOVE the ConsoleKit2 package.
  3. Next, install or upgrade the KDE5 package set.
  4. Change to directory /usr/share/sddm/scripts/ and move the Xession.new & Xsetup.new files into place (remove the .new extension) after carefully checking that you are not overwriting your own customizations in the Xsession & Xsetup scripts. Note: because “slackpkg new-config” only looks inside the /etc/ directory it will miss the two scripts in /usr/share/sddm/scripts/.
    You’ll still have to manually check /etc/ for some critical *.new files that need to be put into place if you are not using slackpkg (which does this *.new check at the end of its run).
  5. Finally, REBOOT.

Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ and this month’s development takes place in the ‘elogind‘ branch..

A new Plasma5 Live ISO will be available soon at https://slackware.nl/slackware-live/latest/ (rsync://slackware.nl/mirrors/slackware-live/latest/) with user/pass being “live/live” as always.

Have fun! Eric

Slackware introduces PAM into its core

Remember the date! On May 18th of 2020, PAM got added to the Slackware-current core. In case that makes you worry, wonder or causes you to ponder leaving Slackware behind, don’t let this change scare you. PAM has come a long way, it is safe and in Slackware, it is not getting in your way. You won’t have to change a single thing to your computer except installing three new packages (slackpkg install-new) before you reboot. Adding PAM should finally remove the self-imposed writer’s block in Patrick’s mind and open the path to long-awaited renewals in the KDE and XFCE areas.
Ever since these packages were added to /testing, I have been using PAM on my own desktop and laptop, both running Slackware64-current with KDE Plasma5 on top, and the desktop computer also running on Nvidia’s binary drivers. Not a single issue was found here.
Read the announcement:

Mon May 18 19:17:21 UTC 2020
Greetings! After three months in /testing, the PAM merge into the main tree
is now complete. When updating, be sure to install the new pam, cracklib, and
libpwquality packages or you may find yourself locked out of your machine.
Otherwise, these changes should be completely transparent and you shouldn’t
notice any obvious operational differences. Be careful if you make any changes
in /etc/pam.d/ – leaving an extra console logged in while testing PAM config
changes is a recommended standard procedure. Thanks again to Robby Workman,
Vincent Batts, Phantom X, and ivandi for help implementing this. It’s not
done yet and there will be more fine-tuning of the config files, but now we
can move on to build some other updates. Enjoy!

I have already updated my own repositories that are touched by PAM:

    The ‘latest’ and ‘testing’ repositories are now identical and contain the PAM-ified packages.
    It won’t matter which of the two you had configured, you’ll get the PAM-fied packages regardless. If you already were using the PAM from Slackware’s testing combined with my ktown ‘testing’ repository, then there’s nothing you have to change.
    If you did not use PAM before, you will have to do a reinstall of the following ‘ktown’ packages which are the only ones that want to use PAM: kscreenlocker, plasma-workspace and sddm-qt5. And don’t forget to install the new kwallet-pam package.
    I have added ‘compat32’ versions of cracklib, libpwquality and pam, the three packages that got added to Slackware-current today.

And for completeness’ sake, I have also updated the “icu4c-compat” package in my regular repository, just like I did for “boost-compat” last week. Note that these two “compat” packages have no relation to the multilib “compat32” packages!
The boost-compat, icu4c-compat and poppler-compat packages in my regular repository contain older versions of the boost/icu4c/poppler libraries and some of your 3rd party packages (libreoffice!!!) may still need them until their packager does a recompile.

Enjoy! Eric

Ktown Plasma5 packages for Slackware 14.2 will go offline soon

Hi all,

As you know, my ‘ktown’ project, providing an extensive and functional Plasma5 package set for Slackware, is mostly targeting the Slackware ‘in-progress’ version called “Slackware-current”.

For a short while after an official stable Slackware release, I keep providing ‘ktown’ packages for the most recent stable Slackware version (which is 14.2 at the time of writing) but once the stable and development releases of Slackware start to diverge too much, I stop updating the Plasma5 packages for the stable release. After all, ‘ktown’ is meant to be the bleeding edge playground for a future Slackware release.

I recently noticed that people are still downloading and installing my ageing ‘ktown’ packages for Slackware 14.2. Those packages have not been touched since end of 2017, they may contain security holes, and they do not represent the state of development of the KDE software today.

Therefore I am giving you a heads-up that this weekend¬†end of May 2020, I am going to remove all the old packages on ‘ktown’ for Slackware 14.2 (that’s https://slackware.nl/alien-kde/14.2/latest/).

If you want to run KDE Plasma5, you should migrate to Slackware-current.

Good luck! Eric

Updated packages in the past weeks: Plasma5, gcc_multilib, openjdk7 and more

I do regular updates of packages in my repository. I focus on the software that is popular, or relevant to Slackware. For the software with a high visibility I usually write a blog post to alert people to the new stuff.
During the last couple of weeks I have not been writing so much about updates due to personal circumstances, some of it has to do with the Corona outbreak.

I was also affected the death of Erik Jan Tromp (Slackware’s alphageek) early March just after I visited him for a final time in his apartment in Leeuwarden.

Anyway, here is a summary of what was refreshed during these weeks.

The new KDE-5_20.03¬†batch is now available for download from my ‘ktown‘ repository. As always, please remove KDE4 first (check the README for instructions if you still need those). These packages will not work on Slackware 14.2.
This March release contains the KDE Frameworks 5.68.0, Plasma 5.18.3 and Applications 19.12.3. All this on top of Qt 5.13.2.

The most interesting event this month is of course the addition of qt5 and its dependencies to Slackware-current itself. I could remove several packages from my own ktown ‘deps’ section: OpenAL (renamed to openal-soft in Slackware), SDL_sound (integrated to Slackware’s sdl package), brotli, hyphen, libxkbcommon, socat, qt5, qt5-webkit, wayland, wayland-protocols and woff2.
I also updated the sip package so its version matches again with that in Slackware (the ktown version has Qt5 support which the Slackware version still needs to pick up). The qca-qt5 package was updated to the latest version.

Frameworks 5.68.0 is an incremental stability release, see: https://www.kde.org/announcements/kde-frameworks-5.68.0.php.

Plasma 5.18.3 is the fourth incremental release of 5.18 LTS (Long Term Support). See https://www.kde.org/announcements/plasma-5.18.0.php for the full announcement including several video’s portraying the strong points of KDE’s desktop environment and https://www.kde.org/announcements/plasma-5.18.3.php for information on these latest updates.

In plasma-extra I updated latte-dock.

Applications 19.12.3 is a stability and bugfix update for the 19.12 cycle. Remember that I still call this ‘Applications‘ but KDE folk prefer the new name ‘Releases‘. See https://kde.org/announcements/releases/2020-03-apps-update/

In applications-extra I updated kstars and added a new package: labplot.

KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.

PAM support

My ‘ktown’ has two sub-repositories. The ‘latest‘ sub-repository is always meant to be used with the official Slackware-current packages. and the ‘testing‘ sub-repository is where I test stuff that is not yet ready to be adopted by the larger population.

Since last month, Slackware’s own ‘/testing’ area contains a set of packages that add PAM support to Slackware. My regular ktown aka ‘latest’ repository content is meant for an up-to-date Slackware-current without PAM. The ‘testing’ repository on the other hand is compiled against a pam-ified Slackware and can be used if you have added the new ‘testing’ PAM packages of Slackware-current to your system.
The packages that picked up PAM support are: kscreenlocker and plasma-workspace (in the ‘plasma’ directory),¬† and sddm-qt5 (in ‘plasma-extra’). A new package has been introduced as well: kwallet-pam (in the ‘plasma’ directory).

Where to get KDE Plasma5 for Slackware

Download the KDE-5_20.03 from the usual location at https://slackware.nl/alien-kde/current/ or one of its mirrors like http://slackware.uk/people/alien-kde/current/ .
Check out the README file in the root of the repository for detailed installation or upgrade instructions.

Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ .

A new Plasma5 Live ISO is available at https://slackware.nl/slackware-live/latest/ (rsync://slackware.nl/mirrors/slackware-live/latest/) with user/pass being “live/live” as always.

While I was working on new Plasma5 packages, Pat Volkerding released packages for gcc 9.3.0 for Slackware-current. When I told him I did not have the time to compile multilib versions for the new gcc because I was busy, Pat responded by updating the gcc-multilib.SlackBuild script and compiling a set of multilib gcc packages for me. So what you download from my multilib repository was actually built by Pat this time.

For those who still use the older Java7, I updated my openjdk7/openjre7 packages to 7u251_b02 with the help of IcedTea 2.6.21 release. This is a security bugfix release, as these Java releases always are I guess.
I get questions from time to time why I do not release packages for Java 11, and my answer always is: I do not see the need. I build my packages using IcedTea framework and when they add support for newer Java versions than 8, I will release packages for that too.

There were several Chromium 80 updates in rapid succession during the last month, and the most recent version you can get from my repository now is 80.0.3987.132. I realize that there’s even a slightly newer release available but there’s only so much time to work on Slackware.

The advantage of having Qt5 in Slackware nowadays, is that it becomes a lot easier to compile a Calibre package for slackware-current. Nevertheless, the calibre package for Slackware 14.2 is still big because my Calibre packages contain all the dependencies inside and the version for Slackware 14.2 includes qt5 libraries.

I am regularly updating packages that are part of my ‘Digital Audio Workstation’ collection.
During the past weeks I updated the MuseScore package (Musescore can create, playback and print music scores) and along with that I updated the Qt5 based JackQtl graphical interface to the Jack2 audio server.
For my own laptop and desktop, I am now starting qjackctl in Plasma5 on login and all my ALSA and Pulseaudio sound pipes through Jack into my speakers now, without the need to change anything to Slackware’s default ALSA and Pulseaudio configurations.

Have fun! Eric

New ISOs for Slackware Live (liveslak 1.3.5)

I have uploaded a set of fresh Slackware Live Edition ISO images. They are based on the liveslak scripts version 1.3.5. The ISOs are variants of Slackware-current “Tue Feb 18 05:20:50 UTC 2020” with the 5.4.20 kernel but without PAM.
The PLASMA5 variant is my february release of ‘ktown‘ aka¬† KDE-5_20.02 .


Download these ISO files preferably via rsync://slackware.nl/mirrors/slackware-live/ (or its mirror rsync://slackware.uk/people/alien-slacklive/ but allow that 24 to sync up) because that allows easy resume if you cannot download the file in one go.

Liveslak sources are maintained in git. The 1.3.5 release has some improvements to the ‘setup2hd’ hard disk installer:

  • Include disk partitioning (cgdisk and/or cfdisk) in the setup2hd.
  • Create a non-root user and set the root password through dialogs.
  • Attempt to speed up the rsync from the squashfs files to the hard drive.

The Plasma5 variant has a nice customized “About the distro” dialog:

Please be aware of the following change in the Plasma5 Live Edition. The size of the ISO kept growing with each new release. Partly because KDE’s Plasma5 ecosystem keeps expanding, and in part because I kept adding more of my own packages that also grew bigger. I had to reduce the size of that ISO to below what fits on a DVD medium.
I achieved this by removing (almost) all of my non-Plasma5 packages from the ISO.
The packages that used to be part of the ISO (the ‘alien’ and ‘alien restricted’ packages such as vlc, libreoffice, qbittorrent, calibre etc) are now separate downloads.
You can find 0060-alien-current-x86_64.sxz¬†and 0060-alienrest-current-x86_64.sxz in the “bonus” section of the slackware-live download area. They should now be used as “addons” to a persistent USB version of Slackware Live Edition.

Refreshing the persistent USB stick with the new Plasma5 ISO

If you – like me – have a persistent USB stick with Slackware Live Edition on it and you refresh that stick with every new ISO using “iso2usb.sh -r <more parameters>”, then with the new ISO of this month you’ll suddenly be without my add-on packages.
But if you download the two sxz modules I mentioned above, and put them in the directory “/liveslak/addons/” of your USB stick, the modules will be loaded automatically when Slackware Live Edition¬†boots and you’ll have access to all my packages again.

What was Slackware Live Edition and liveslak again?

If you want to read about what the Slackware Live Edition can do for you, check out the official landing page for the project, https://alien.slackbook.org/blog/slackware-live-edition/ or any of the articles on this blog that were published later on.

Extensive documentation on how to use and develop Slackware Live Edition (you can achieve a significant level of customization without changing a single line of script code) can be found in the Slackware Documentation Project Wiki.

Have fun!