I have released an update of the ‘liveslak‘ scripts. I needed the tag for a batch of new ISO images for the Slackware Live Edition. These are based on the latest Slackware-current dated “Wed Nov 22 05:27:06 UTC 2017“) i.e. yesterday and that means, the ISOs are going to boot into the new 4.14.1 kernel.
The new liveslak version 184.108.40.206 has a few updates. Most are not worth mentioning but these are:
The PLASMA5 ISO image features Wayland support. You can login to a regular X.Org Plasma5 session but you can also choose the “Plasma – Wayland” session from the SDDM dropdown menu. In order to keep the ISO size below the DVD medium maximum size, I had to leave the optional ‘wine’ module out of the ISO. You can still download the wine module from the ‘bonus‘ location.
FYI, this was the command to generate that PLASMA5 ISO:
If you already use a Slackware Live USB stick that you do not want to re-format, you should use the “-r” parameter to the “iso2usb.sh” script. The “-r” or refresh parameter allows you to refresh the liveslak files on your USB stick without touching your custom content. If you want to modify other parameters of your USB stick, use the script “upslak.sh“. It’s main feature is that it can update the kernel on the USB stick, but it also can replace the Live init script. As with most (if not all) of my scripts, use the “-h” parameter to get help on its functionality.
More detail about the features of Slackware Live Edition can be found in previous posts here on the blog.
Last year August 2016 I experimented with Wayland, the alternative to the X Window system. My goal was to see if it is possible to run a Plasma5 desktop session on a Wayland compositor instead of using X.Org.
There was one big showstopper at the time. Kwin_wayland has a dependency on the ‘logind’ DBus API and at that time last year, this API was only provided by systemd-logind. Luckily, someone treated the logind component of systemd similarly to its udev component. Where Slackware already uses “eudev” which is a standalone udev source extracted from the systemd source, there’s also “elogind” which is the standalone logind sourcecode, extracted from systemd sourcecode. With some difficulty I managed to create a Slackware package for elogind and everything compiled. I just could not get a working Wayland session.
As it turns out today, that failure to get Wayland working was an omission on my side… more on that later.
Shortly after, IBM told me I would lose my job, I found another job at ASML and life was hectic and remained so. I never got another opportunity to research the root cause of my Wayland failure.
Now that I have a week off, I decided to revisit the old Wayland disaster. After last year’s frustration over the need for elogind, I talked to the ConsoleKit2 developer and to the KWin developer, to see if CK2 could be extended with the required logind DBus API (parts of that API were already incorporated) and to get CK2 accepted as an alternative to systemd-logind on systems that don’t ship with systemd. Both wishes were fulfilled this summer, so I could drop elogind from my package set. I still needed to recompile / upgrade some other packages to add wayland support to them, but the fact is: Slackware does not need PAM or systemd to get Wayland working.
Therefore, my KDE 5_17.10_testing repository contains mostly what you already know and love: KDE Frameworks 5.39.0, Plasma 5.11.0and Applications 17.08.2. All based on Qt5.9.2. Just with 17 differences in the package list.
Why does Wayland work now, while it did not last year?
Well, that was entirely my perception of things. Probably would have worked last year as well, if only I had recognized the signs. Last year, and yesterday as well, all the puzzle pieces seemed to be OK, but their integration failed. The signs (using strace and gdb to find out why the Wayland session would not start) were telling me that KWin was trying to find a logind provider on the DBus and no-one was answering. It took a sudden insight this morning, the realization that there is one difference between Slackware and all those other distros. And I have been using a workaround for ages, and I just did not think about that.
When you login on a system running PAM, a login session is registered on the bus using either ConsoleKit2 or systemd-logind. Our PAM-free Slackware needs an additional “ck-launch-session” command in front of the “dbus-launch” command to connect a new ConsoleKit2 session to the bus and let KWin find it there… when I fixed that, my Wayland session just sprang into existence!
How to start a Plasma5 Wayland session
Runlevel 3 (console): run the ‘startkwayland‘ command as your regular user.
Runlevel 4 (SDDM): select “Plasma (Wayland)” from the session dropdown and then proceed to login.
Of course… nothing works 100% the first time. So what have I ran into? Note that I have been running Wayland for a couple of hours only, so I can say little about its stability.
Dropbox does not start, unless you ‘unset’ the QT_QPA_PLATFORM variable first. This is caused by the fact that Dropbox uses its own internal Qt5 libraries and it does not come with Wayland support.
Gnome-keyring does not start for some reason, so you can not auto-login to skypeforlinux for instance
HP-tray was eating 100% CPU at some point and draining my battery. I had to kill the process.
Yakuake does not work (I know, it is not part of my ‘ktown’ package set)
Unlike an X.Org session, the Wayland session does not require an additional <Ctrl> keypress to switch to a virtual console. Therefore, when I wanted to invoke krunner with <Alt><F2>, instead I was switched to the second virtual console, tty2. Upon returning to the Wayland session (which was running on VT4 as opposed to VT7 for X.Org) the krunner window was waiting for me. Apparently both the OS and KWin process the <Alt><FunctionKey> combos.
A note about NVIDIA: I know that there are issues between the binary driver and Wayland. Please do your research if you use the binary Nvidia blob. My laptop has an Intel GPU which runs on the open source kernel driver, and has no issues.
What’s needed to make Plasma5 work with Wayland in Slackware
We need Wayland support in the core of the OS as well as in the dependencies for Plasma5. Also we need a version of ConsoleKit2 that works with Kwin_wayland. Which means:
add a wayland-protocols package (wayland is no longer sufficient)
add an upgraded ConsoleKit2
recompile Slackware’s mesa using a slightly modified SlackBuild script (change the package tag from ‘alien’ to ‘wayland’)
write a xorg-server.SlackBuild script based on the code in the x11.SlackBuild framework of Slackware, and recompile xorg-server with that script (change the package tag from ‘alien’ to ‘wayland’)
recompile libxkbcommon (change the package tag from ‘alien’ to ‘wayland’)
recompile qt5 (change the package tag from ‘alien’ to ‘wayland’)
With the ‘deps’ taken care of, proceed to Frameworks:
recompile kwayland and plasma-framework (change the package tag from ‘alien’ to ‘wayland’)
And finally the Plasma packages that use Wayland in some way or other:
recompile kinfocenter, kscreenlocker, kwayland-integration, libkscreen2, plasma-desktop, plasma-integration,plasma-workspace, powerdevil and kwin (change the package tag from ‘alien’ to ‘wayland’)
You will have noticed that the packages I tagged with ‘wayland‘ instead of the usual ‘alien‘ tag, are the ones that picked up Wayland support as compared with their originals. This makes it quite easy for you to switch back to the original packages (mesa and xorg-server in Slackware and the other 13 in ‘ktown’) if you are done with your testing. The remaining ‘alien’ packages (wayland-protocols and ConsoleKit2) can be kept without penalty.
A final note about this updated xorg-server package. My version of that package is a 4-into-1 package; it contains xorg-server-xephyr, xorg-server-xnest and xorg-server-xvfb as well. If you decide to remove the testing packages and want to go back to Slackware’s non-wayland version of xorg-server, you must also re-install the other three xorg-server-x* packages.
Installing or upgrading Frameworks, Plasma and Applications
Please use the README file in the ‘latest’ repository for the installation & upgrade instructions. I reserved the README.testing in the ‘testing’ repository to highlight the differences between the two repositories.
Where to get these ‘testing’ packages for Plasma Wayland
Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/testing/ subdirectory). Only “bear” has the packages for now, the mirrors should follow within 24 hours. If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too. There is now only one source tree to create both ‘latest‘ and ‘testing‘ repositories.
There will probably not be a Plasma5 Live ISO image based on the ‘testing’ repository with working Wayland support. My ‘bear’ server just does not have the disk space to host an additional 4 GB ISO file. Nevertheless, you can tranfer the existing Plasma5 Live ISO to USB stick, change the ‘latest‘ ktown repository to ‘testing‘ in the slackpkg+ configuration file “/etc/slackpkg/slackpkgplus.conf” and run “slackpkg update ; slackpkg install ktown ; slackpkg upgrade ktown” to get the 4 new packages and upgrade the 13 other packages. If you do not use slackpkg with slackpkg+ then simply look at the short list of packages to be installed or upgraded, higher up on this page.
KDE Software Compilation 4.11 has been released – the major components being Plasma Workspaces, KDE Applications, and the basis on which those are built, the KDE Platform. The new KDE SC 4.11 is more of an intermediate release cycle while the developers concentrate on the technical transition to “KDE Frameworks 5” (the evolution of the current KDE Platform).
The release of KDE Platform 4.11 has a focus on stability, bugfixes and performance improvements. Basically, the platform libraries have been feature-frozen since 4.9 already. New features are being implemented for the future KDE Frameworks 5.0. (with an exception made for further optimizations to the Nepomuk framework which went into the stable release).
From a packaging point of view, the most prominent change is a further splitting of the big packages into multiple smaller individual program packages. This time, the affected “meta packages” are kdeadmin, kdetoys, kdesdk and kdenetwork.
It looks like Slackware-current (and therefore Slackware 14.1) is sticking with KDE 4.10.5 because that is rock stable and an upgrade to 4.11.0 may introduce compatibility issues we do not want when Slackware 14.1 is somewhat visible on the horizon already. This means that those of you who feel adventurous and want to run the latest KDE always, will need to visit this blog on a regular basis to stay informed about updates in the KDE 4.11 series for Slackware 14.1/current. What are you waiting for? Plan an upgrade from your trusted Slackware 14.0 to -current (and eventually to 14.1) right now!
And since “The Plasma Workspaces 4.11 will receive long term support as the team focuses on the technical transition to Frameworks 5. This then presents the last combined release of the Workspaces, Applications and Platform under the same version number” (quote from the release announcement) I can’t really tell you how future versions of KDE are going to be numbered. For now, the KDE 4.12 roadmap is available at the usual place, telling us that KDE 4.12 should be released in December of this year.
New KWalletManager user interface; changes to Okular
What’s new in KDE 4.11?
For those interested in the in-depth information, my tip is to check out the feature plan page for the KDE 4.11 series. Highlighted changes are the expansion of the use of Qt Quick (the application framework which includes the interpreter language QML), faster Nepomuk indexing (many people keep complaining about Nepomuk… but really guys, give the “evil triplet” of Nepomuk/Akonadi/Strigi the change they deserve), many Kontact improvements, and the start of support for the Wayland compositor in KWin (the window manager of KDE) as well as OpenGL improvements.
Speaking of Wayland support. I feel compelled to mention this interesting article explaining how the next release of X.Org could become a real alternative to Wayland by implementing the new DRI3 and Present extensions – it shows that X.Org development is very much alive!
How to upgrade to KDE 4.11 ?
You will find all the installation/upgrade instructions that you need in the accompanying README file. That README also contains basic information for KDE recompilation using the provided SlackBuild script. Earlier blogposts have more information on rebuilding from source and upgrading from Slackware’s own KDE. Another post explains the inner workings of KDE.SlackBuild for all you re-compilers.
You are strongly advised to read and follow these installation/upgrade instructions!
Where to find packages for KDE 4.11 ?
Download locations are listed below (you will find the sources in ./source/4.11.0/ and packages in /current/4.11.0/ subdirectories). Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!