My thoughts on Slackware, life and everything

Tag: systemd

Challenges with TigerVNC in Slackware 15.0

The 1.12.0 version of TigerVNC which is present in Slackware 15.0, is quite different from earlier versions such as the 1.6.0 version in Slackware 14.2 and even the previous iterations of this software in Slackware-current ( up to 1.11). It has ‘evolved‘ in a way that it has become dependent on systemd, or so the developers claim.

And indeed, the most prominent change is that the old ‘vncserver‘ script has been rewritten and should not be run directly any longer. In previous versions, as a user you could run ‘vncserver :1‘ to start a VNC server on port “5900 + 1” aka TCP Port 5901, and if needed you could kill that VNC server session with ‘vncserver -kill :1‘.
Fast forward to current-day. You are now expected to start the VNC server via the new command ‘vncsession‘ which will look in a couple of places to find out who you are and what desktop session you want to start. No longer will it install a “${HOME}/.vnc/xstartup” script for you to customize, instead it will look first in ‘/usr/share/xsessions‘ for *.desktop files like graphical login managers also do (SDDM, LightDM). Slackware applied a patch here for convenience, so that the names of sessions to look for also include "/etc/X11/xinit/Xsession", "/etc/X11/Xsession", "${HOME}/.vnc/xstartup", "${HOME}/.xinitrc", "/etc/X11/xinit/xinitrc" in that order.

The new TigerVNC expects to be launched from a systemd service and it can no longer be started as a non-root user.

Accepting that as a given (we can argue all we want with these developers but it looks that they are not interested), I looked for a way to make life easy for me and other VNC users on Slackware and other non-systemd distros.
In this article I will describe the solution I came up with. It’s a hack, I don’t think it is the best, but it works for me and only needs a one-time configuration by the root user. Let me know in the comments section how you were affected and dealt with the changes in TigerVNC!

  • The new TigerVNC uses a user-to-displayport mapping file, ‘/etc/tigervnc/vncserver.users‘ with lines that contain “port=user” mappings.
    For instance, a line containing “:9=alien” means that a VNC server session which is started for user “alien” will be running at VNC port “:9” which corresponds to TCP port 5909.
  • If a VNC session can only be started as root, then I will use ‘sudo‘ to allow regular users to start a ‘/usr/local/sbin/vncsession-start‘ wrapper script.
  • I have written that wrapper script ‘/usr/local/sbin/vncsession-start‘ which checks your username via the ${SUDO_USER} variable, looks up the VNC display mapping for that useraccount in ‘/etc/tigervnc/vncserver.users‘ and starts the vncsession program with the user and port as parameters.

What needs to be done?

Wrapper script:
The script ‘/usr/local/sbin/vncsession-start‘ for which I took inspiration out of the tigervnc repository looks like this:

#!/bin/bash
USERSFILE=/etc/tigervnc/vncserver.users
if [ ! -f ${USERSFILE} ]; then
echo "Users file ${USERSFILE} missing"
exit 1
fi
VNCUSER=${1:-"$SUDO_USER"}
if [ -z "${VNCUSER}" ]; then
echo "No value given for VNCUSER"
exit 1
fi
DISPLAY=$(grep "^ *:.*=${VNCUSER}" "${USERSFILE}" 2>/dev/null | head -1 | cut -d= -f1 | sed 's/^ *//g')
if [ -z "${DISPLAY}" ]; then
echo "No display configured for user ${VNCUSER} in ${USERSFILE}"
exit 1
fi
exec /usr/sbin/vncsession ${VNCUSER} ${DISPLAY}

Don’t forget to make that script executable:

# chmod +x /usr/local/sbin/vncsession-start

Sudo:
I then create a ‘sudoers‘ rule in the file ‘/etc/sudoers.d/vncsession‘ (the filename does not really matter as long as it’s in that directory and has “0440” permissions) with the following single line of content:

%vnc ALL = (root) NOPASSWD: /usr/local/sbin/vncsession-start

This sudoers rule expects that your VNC users are a member of group ‘vnc‘, so create that group and add your account(s) to it. In this example I add my own account ‘alien‘ to the new group ‘vnc‘:

# groupadd vnc
# gpasswd -a alien vnc

In order to have ‘/usr/local/sbin‘ in the $PATH when using ‘sudo‘, you must un-comment the following line in the file ‘/etc/sudoers‘ (remove the “#” at the beginning of the line):

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

TigerVNC:
The VNC user mappings have to be added on separate lines in ‘/etc/tigervnc/vncserver.users‘. Note that each user requires a different port mapping:

:1=kenny
:2=bob
:9=alien

In order to have a sane out-of-the-box behavior for our VNC users, edit the global defaults file ‘/etc/tigervnc/vncserver-config-defaults‘ which by the way can be overruled per-user by a similarly formatted file named ‘${HOME}/.vnc/config‘ (the user would have to create it):

session=plasma
# securitytypes=vncauth,tlsvnc
# geometry=2000x1200
# localhost
# alwaysshared

The above session type “plasma” is valid because a file ‘/usr/share/xsessions/plasma.desktop‘ exists. The TigerVNC default session type “gnome” does not exist in Slackware.

Tell new VNC users to run ‘vncpasswd‘ before starting their first VNC server session, so that their sessions are at least somewhat protected.

That’s all.
Now, if you want to start a VNC server session, all you need to run as a regular user is:

$ sudo vncsession-start

and then connect to the VNC session with any ‘vncviewer‘ program. Look for my article about NoVNC if you want to give your users a web-based access to their VNC sessions. In that case you can make it mandatory for the VNC session to only bind to localhost address so that VNC sessions can not be accessed un-encrypted over the network. You can enforce this by adding a line only containing “localhost” to ‘/etc/tigervnc/vncserver-config-mandatory‘.

Good to know, it is no longer possible – but there is no longer a need – to kill the VNC server when you are done with it as was required in the past. Logging out from your graphical desktop will terminate your login session and stop the VNC server.

An additional bonus of my ‘vncsession-start‘ script is that root can run it for any user, and this makes it easy for instance to start the users’ VNC sessions in your computer’s ‘/etc/rc.d/rc.local‘ script. You just need to add the following command to start a VNC session for user ‘alien‘ – as long as a port mapping has been configured for ‘alien‘ of course:

/usr/local/sbin/vncsession-start alien

Caveat:
A TigerVNC session can only be started for/by a user if that user is not already running an interactive desktop session. This means that the root user cannot use “vncsession-start alien” to snoop my existing login session, the program will simply refuse to launch.

Thoughts?
Eric

Gentoo eudev adopted by Eudev Project

A recent LinuxQuestions thread discusses the depreciation of the eudev fork which was created by Gentoo a few years back in order to keep systemd at bay. This step by Gentoo sparks some serious doubts among LQ members about what Slackware should do – is the inclusion of systemd near, now that eudev is dead?

Short recap: In November 2015 Slackware replaced its no longer maintained original udev with this new eudev (a standalone extract of udev out of the systemd sources but modified so that every dependency on systemd is removed). This change was actually my chance to announce the liveslak project as a ‘celebration to say farewell to udev‘.
In November of 2020, a similar event happened when Slackware replaced ConsoleKit2 with elogind – a standalone copy of the logind code extracted from systemd and with all dependencies to systemd removed. Both events were meant to keep Slackware free of systemd, at least for a while… who can stem the flow of water.

But there is good news. Yesterday, a collaboration between Alpine, Devuan and Gentoo contributors has announced their adoption of eudev and a new repository has been created where the new project will further develop eudev: https://github.com/eudev-project/eudev/blob/master/README.md . Let’s give these folk our best wishes!

Eric

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:

    export KWIN_DRM_USE_EGL_STREAMS=1

    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.

Deps:
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:
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:
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.

Plasma-extra;
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;
Applications 20.04.2 is an incremental bug fix release, see also https://kde.org/announcements/releases/2020-06-apps-update/

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

Telepathy:
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

liveslak 1.1.6 released

blueSW-64pxIt has been a while since I released the last ‘liveslak‘. Usually these releases seem to co-incide with Plasma5 releases in my ‘ktown’ repository.
Today is no different, and liveslak 1.1.6 has been released to produce a new set of Live ISO images.

You will find the usual versions of Slackware Live Edition based on liveslak 1.1.6 and using Slackware-current dated “Thu Jan 26 21:33:41 UTC 2017“. There are variants for a full Slackware (in 64bit and 32bit), Plasma5, MATE and Dlackware (a newcomer). Also the 700MB small XFCE variant (in 32bit and 64bit).

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.

 

New in the ISOs

The new ISOs are based on the latest slackware-current with Linux kernel 4.4.38.

The SLACKWARE variant contains exactly that: the latest slackware-current and nothing else. Ideal for testing.

The XFCE variant contains a stripped down Slackware with a minimalized package set but still quite functional. The small size is also accomplished by excluding all documentation and man pages, and the localizations for the languages that are not supported in the boot menu. This ISO is small enough that you can burn it to a ’80 minutes’ CDROM (700 MB).

The MATE variant (a Slackware OS with KDE 4 replaced by Mate) contains packages from the repository at http://slackware.uk/msb/current/ which is Mate 1.17.

The DLACK variant contains Dlackware – this is Slackware (minus KDE4) with PAM and Systemd bolted on, and with Gnome 3.22 as the Desktop Environment. If you have been curious as to how PAM and Systemd would affect Slackware, this is your chance to experience all of this first-hand without having to install it to your harddrive. This DLACK ISO has been created from the repository at http://pkgs.dlackware.com/mirrors/slackware/dlack/current/3.22/x86_64/. Thanks to bartgymnast for creating the packages and letting me help him getting the packages to a quality level where I was comfortable using them in a Live ISO.

The PLASMA5 variant (Slackware with KDE 4 replaced by Plasma 5) comes with the latest Plasma 5 release “KDE-5_17.01” as found in my ktown repository. Additionally you will find several packages from my regular repository: chromium (with flash and widevine plugins), vlc,ffmpeg, libreoffice, qbittorrent, openjdk and more. This ISO also contains the LXQT and Lumina Desktop Environments. Both are light-weight DE’s based on Qt5 so they look nice & shiny.
One word of caution when using the Lumina DE:

  • The network applet is not enabled by default, and you may have to enable the network manually. I used “nmtui” in a terminal window but you can try enabling the networkmanager-applet instead. I did not find out how, yet.

The changes between liveslak scripts 1.1.5 and 1.1.6

  • Most obvious update is the addition of a new supported variant: DLACK, installs Dlackware (i.e. Slackware with PAM, Systemd & Gnome3 instead of KDE4).
  • More fixes to get rid of hardcoded ‘/mnt‘ paths in the version of the Slackware installer files which are used by ‘setup2hd’. Installation to hard disk should finally work properly.
  • Added packages from the restricted repository (ffmpeg, handbrake, lame etc) to the PLASMA5 ISO.
  • various updates in package content for the XFCE, PLASMA5, MATE ISOs.

Multilib considerations

I added a live module to enable multilib support out of the box in the PLASMA5 variant of Slackware Live. Inside the ISO that module-file is called “/liveslak/system/0020-slackware_multilib-current-x86_64.sxz”.
I host a copy of that module online as “0050-multilib-current-x86_64.sxz” so that you can download it and add it to the ‘addons‘ or ‘optional‘ subdirectory of your non-plasma5 liveslak.
Multilib is something you’d need for Wine, so I also added a live module for Wine (including the 32bit OpenAL libraries) as a separate module in the ‘optional‘ subdirectory of the PLASMA5 ISO and made copy of it available in the aforementioned ‘bonus’ directory online.
This is how I created that live module for wine: by installing the 32bit OpenAL libraries on top of my 64bit wine package for Slackware (which contains both 32bit and 64bit wine):

# SCRATCHDIR=$(mktemp -t -d makesxz.XXXXXX)
# installpkg --root $SCRATCHDIR wine-1.9.23-x86_64-1alien.txz
# installpkg --root $SCRATCHDIR OpenAL-compat32-1.17.1-x86_64-1aliencompat32.txz 
# ./makemod $SCRATCHDIR ./optional/0060-wine-1.9.23-current-x86_64.sxz 
# rm -r $SCRATCHDIR

Remember, the modules in the ‘optional‘ subdirectory of liveslak can be loaded into the live OS on boot when you use the “load=” boot parameter in syslinux or grub. Loading the optional wine module for instance, needs this as additional boot parameter: “load=wine” and if you would be using a non-plasma5 based Live OS and have added the multilib module in the ‘optional‘ subdirectory also, then the boot parameter needs to load both multilib and wine: “load=multilib,wine”.
Of course, if you place both modules in the ‘addons‘ subdirectory instead, they will always be loaded on boot unless you want to prohibit that using the “noload=multilib,wine” boot parameter in syslinux or grub.

Download the ISO images

The ISO variants of Slackware Live Edition are: SLACKWARE, XFCE, PLASMA5, MATE and DLACK. These ISO images (with MD5 checksum and GPG signature) have been uploaded to the master server (bear) and should be available on the mirror servers within the next 24 hours.

Download liveslak sources

The liveslak project can be found in my git repository: http://bear.alienbase.nl/cgit/liveslak/ . That’s all you need to create a Slackware Live ISO from scratch. Documentation for end users and for Live OS developers is available in the Slack Docs Wiki.

Have fun! Eric

On LKML: an open letter to the Linux World

I wish I were better with words. There’s thoughts that strike a note in your heart and mind,  but I would not be able to express these thoughts on paper so that they deliver the needed punch. That was my first thought when I read this open letter on the Linux Kernel Mailing List (LKML): https://lkml.org/lkml/2014/8/12/459 . The text is written by a longtime Debian user who feels deeply betrayed by its board of leadership. The emotions he penned down are exactly mine. Thank you, Christopher Barry. This was of course not the first eloquently written rant, but I hope it sparks a discussion in Kernel Land about what is happening in User Land, and whether they can afford to keep looking the other way (with the public exception of Linus and some others).

One word. One demon. systemd.

What relation does Christopher’s rant have to Slackware? After all, it’s Debian that got the flak, and in the comments section people indicate they intend to switch to Gentoo… forgetting that Slackware is a good systemd-free alternative (but hey! this automatic dependency resolution thingie that makes life so comfortable in Gentoo is not part of Slackware either).

Last week I asked the SDDM developers to reconsider their decision no longer to support ConsoleKit because Slackware does not have systemd or logind and thus we need to keep using ConsoleKit. The answer could be expected: “answer is no because ConsoleKit is deprecated and is not maintained anymore” and therefore I had to patch it in myself.

Of course, the ConsoleKit successor systemd-logind, written by the same team that gave us all the *Kit crap, depends on PAM which we also do not have in Slackware. One of the fellow core developers in Slackware, who is intimately familiar with the KDE developers community, has heard from multiple sources that KDE is moving towards a hard dependency on systemd (probably because they are going to need the functionality of systemd-logind). We all know what that means, folks! It will be the day that I must stop delivering you new KDE package releases for Slackware. That’ll be the day.

Eric

© 2024 Alien Pastures

Theme by Anders NorenUp ↑