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:
- UPGRADE TO THE LATEST slackware-current first.
- Then, REMOVE the ConsoleKit2 package.
- Next, install or upgrade the KDE5 package set.
- 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).- 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
I thought you wouldn’t stop, thanks, l’ami Eric.
Eric, this is such exciting news! My heart leaped with joy to see you were able to make another ktown release after all. Secondly, I can already the groans now from the ‘slippery slope’ folks to systemd but I see it differently: unlike the rush to monolithic that ‘had’ to be that way by others, you and Pat are proving they were wrong, that these new features actually CAN be implemented in a Unix-like one-thing-well fashion.
Looking forward to taking it for a spin.
Cheers!
Dear Eric,
thanks for the update. Most of the xinit scripts use exec ck-launch-session … to start ConsoleKit2. This is necessary for some parts, e.g. for device management and remote share access in Thunar. With ConsoleKit2 not being present anymore, will this still be possible, e.g. using elogind?
Greetings
Lioh
Hi Lioh,
Our xinit scripts (for XFCE, FVwm, Fluxbox etc) in /etc/X11/xinit/ all end with lines like this:
if [ -z “$DESKTOP_SESSION” -a -x /usr/bin/ck-launch-session ]; then
ck-launch-session STARTSESSIONCOMMAND
else
dbus-launch –exit-with-session STARTSESSIONCOMMAND
fi
… where STARTSESSIONCOMMAND starts the actual Desktop Environment or Window Manager. If the ConsoleKit2 package is removed, you see that the “else” clause will be executed, and this will exactly be what you need for elogind. Nothing else is required.
Some things beyond KDE will probably have to recompiled as well, but I am focusing on people who are willing to work with KDE Plasma5. For instance, if you would want to switch to elogind but do not need KDE4 or KDE5, then you may have to recompile XDM (the xdm package). Also, xorg-server can work with elogind if it is recompiled to pick up the library. But all of that is not blocking you from using this right now – I have also been running XFCE sessions, not just Plasma5, and that still works normally.
I have installed elogind, upgraded dbus and polkit, recompiled xdm and xorg-server (not sure if that was necessary, though), edited the xinit script accordingly and everything worked as expected, also on a non-Plasma desktop. Thanks for the work.
Thank you very much, mr. AlienBob. I don’t use plasma myself, but really appreciate your work for users who want to get an out-of-the-box DE experience.
Oh wow. I had just only seen the line in -current changelog and I started to wonder. Only now I see this post and I’m amazed 🙂
It’s a huge step forward and definitely the inclusion of Plasma5 in -current must be imminent.
And with the big showstopper of NVIDIA compatibility being solved.
Thanks Eric (and Pat too, of course)
I had your ktown git repo cloned and was going through the builds there to get onboard with testing elogind but you moved a little faster than me. 🙂 Gonna have to revert and go the official route now, but I’d rather have it that way.
I guess it would be prudent to blacklist ConsoleKit. I don’t know how long Pat will keep it around in current but I’d imagine if it got back in it would make a mess.
Thanks for making a release Eric, I’m looking forward to testing it.
No need to blacklist ConsoleKit2.
The ConsoleKit2 package was added in Slackware 14.2 so if you remove it from -current then it will not be installed again by either of “slackpkg install-new” or “slackpkg upgrade-all” commands.
Thanks for the clarification on the blacklist. I’m up and running on plasma/wayland and looking through things. There have been a few changes I have noticed.
First the touchpad settings had to be redone. I noticed my changes to scrolling and the speed of the cursor was slower. Had to go into the system settings and change the configuration. I also noteed that the touchpad settings page is different in X11 vs wayland. I’m new to wayland so i’ll have to figure out these differences as I go.
The notifications looked “glitchy” and stacked across the screen instead of down. I noticed that xfce4-notifyd was in control of notifications when I went to the system settings. I had fixed this in the past by creating a link named $HOME/.local/share/dbus-1/services/org.kde.plasma.Notifications.service pointing to /usr/share/dbus-1/services/org.plasma.Notifications.service. This prioritizes plasma’s notification services, instead of xfce4’s, since they both provide the dbus org.freedesktop.Notifications service and xfce4 seems to be used over plasma’s when both are installed on the system. This “fix” seems to still work, and the plasma notifications work properly and look better in wayland IMO.
I keep the panel at the top of the screen. When using yakuake in wayland, the top line of yakuake is underneath the panel, and so its cut off. This is not the case in X11, where yakuake shows up properly and is not obscured by the panel. This is a know bug, and should be fixed in the next release, according to this: https://bugs.kde.org/show_bug.cgi?id=408468
When running startx from runlevel 3 for the X11 plasma session, I get kicked back to tty1 and have to switch back manually with Ctrl+Alt+F7. This is not the case when starting wayland.
When closing the wayland session (log out of plasma when in runlevel 3), there are a few Kcrash errors spewed on the console in regards to trying to start various plasma applications as the wayland session is shutting down. The session still ends properly and all the programs exit cleanly but that seems odd to see those messages.
Not too sure what to make of the last two issues yet. I’ll need to mess around with things some more and if I find anymore issues or fixes to these I’ll make sure to discuss it for anyone else testing this out.
The updated xinit slackware package has corrected the problem with switching back to tty1 when starting the X server. I’m still not sure why I get KCrash reports when logging out of plasma, back to my console in runlevel 3. If its an X11 session then it reports KCrash of plasmashell, if its wayland then theres multiple KCrash reports at logout for plasmashell, powerdevil, latte-dock, and maybe one or two more programs.
Also noticed that the latte-dock will completely freeze up at some point in a wayland session. and that I tried to reverse the trackpad scrolling in wayland but it would scroll in different directions in firefox than it would in something like a KDE system setttings menu.
I think I’ve had enough of testing wayland for now. Too many problems that break my workflow for now. I’ll probably revisit it as the KDE devs release fixes to these issues, but for now I’ll stick with Plasma + elogind running on X11, which is running just fine.
Cheers,
Bob
Thank you Eric for this upgrade. As usual, it is a rock solid release and the upgrade instructions, though not trivial, are very clear.
I just fail to grasp why ktown has package deps/util-linux since the package in current has now picked up support for elogind in /etc/pam.d/login. But I may be missing something.
I forgot to remove util-linux… will do that now.
At first, I was not sure whether Pat would update sysvinit-scripts and util-linux in Slackware so I built a util-linux myself.
If you have a crash when you start from the console (startx) or from sddm (init4), comment this line /etc/pamd.d/login
#-session optional pam_elogind.so,
not sure for you maybe it’ my config. 🙂
I would advise against that… the line must actually be there or else you will have problems logging into a graphical session.
Your crash may be caused by left-over experiments with your own version of a elogind package, or perhaps you still have a ConsoleKit2 somewhere?
consolekit2 is uninstaled since one week.
Maybe it’s my config, but all work here, no session problem (with startx and sddm) 🙂
No, turns out Pat forgot to patch startx in the xinit package and I did not spot the omission. Updates arriving soon in Slackware-current. For now, change:
if [ -x /usr/lib/systemd/systemd -o -x /lib/systemd/systemd ]; then
to
if [ -x /lib/elogind/elogind -o -x /lib64/elogind/elogind ]; then
in /usr/bin/startx .
Ok, i have found the problem, it’s because i start sddm from a root console, it seem that the problem is not present on init4. 😉
Thank you very Eric for this!
At first I couldn’t log in on a X11 session and only on a wayland session.
Turned out that the new-config part of slackpkg doesn’t look in /usr/share/sddm/script so both Xsession.new and Xsetup.new had to be moved to their respective non-.new filename. Once that was done, both wayland and X11 started fine.
I tried wayland and I found the mouse extremely slow to react and move.
Also some applications in the status and notifications bar do not present their menus when clicked on under wayland (dropbox, skype, and teams for example, non of which are core slackware anyway.). Native kde ones work fine.
For the moment I will stay on X11 for most productivity stuff but will keep testing wayland and its potential.
The README warns about the *.new scripts in /usr/share/sddm/scripts/ that have to be renamed manually, but it is a lot of text to digest. I will add it to the article above as well.
If the mouse is extremely show in Wayland, could it be that everything is slow? Could be caused by not setting KWIN_DRM_USE_EGL_STREAMS to “1”. I observed that same behavior.
Just a side note: maybe it’s better to do the upgrade from a tty. I made the mistake to upgrade from within Plasma and forgot that the Screenlocker depends on ConsoleKit2 (which I had removed). So either disable screenlocker before or better don’t upgrade from a running Plasma session. But I guess that’s recommended anyhow.
That is why the README instructs you to switch to runlevel 3 first…
I have upgraded, per your instructions, my bare metal -current installation. I am not using nvidia, so performed none of those steps. when using either the “startkwayland” or “startx” command, I get the Plasma startup screen, then a black screen and mouse cursor, but no desktop. The cursor is quite responsive. No drag or delay at all. On wayland, I have to turn off the computer to get back to the command line, but on xorg, Cntr-Alt-Bkspc still works.
After I’ve typed “startx”, this is all that is on the screen:
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
Build Operating System: Slackware 15.0 Slackware Linux Project
Current Operating System: Linux slack.t2flongears.lan 5.4.47 #1 SMP Thu Jun 18 13:15:42 CDT 2020 x86_64
Kernel command line: BOOT_IMAGE=dev004:\EFI\Slackware\vmlinuz-generic-5.4.47 root=/dev/sdb2 ro ro
Build Date: 30 April 2020 07:58:09PM
Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/var/log/Xorg.0.log”, Time: Fri Jun 19 20:03:14 2020
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
/usr/bin/plasma_session: error while loading shared libraries: libphonon4qt5experimental.so.4: cannot open shared object file: No such file or directory
(II) Server terminated successfully (0). Closing log file.
xinit: connection to X server lost
What have I done (or failed to do) this time?
Install phonon alien package:
https://alien.slackbook.org/ktown/current/latest/x86_64/deps/phonon-4.11.1-x86_64-1alien.txz
Hi. I followed upgrade instructions to the letter, including all caveats on this page, but can’t start X from runlevel 3 or 4. libelogind.so.0 can’t be found by dbus-launch, bluetoothd, etc. Perhaps the slackware.uk mirror wasn’t totally up to date. I’ll keep trying.
Sorry. Using slackpkg+ and forgot to run ‘slackpkg install ktown. My bad, as usual.
Hi Eric,
First of all a heartfelt THANK YOU! I know you planned to stop packaging Plasma so I really appreciate this gesture for which I am really grateful.
I upgraded everything and I’m now writing you from a Wayland session. This is great!!
There are some bugs and artifacts, though, which I hope will slowly get fixed.
I casually switched to a text console and got bitten by the brokenness of the graphical session switching. Thankfully you put a notice stating that I could use a loginctl command. That was very useful. I would add to that notice that such command could be issued with your regular user, not root, just for the sake of clarification.
I would state some artifacts I saw on Wayland but first I would try going back to X11 to see whether these are Wayland or other issues. I will reboot and start Plasma with an X session and then will comment again.
Once more, THANK YOU!!
Well, here I am back into X11.
The tty and graphical session switching is gone. Typing that loginctl command is no longer needed. Maybe because in the meanwhile I applied Pat’s Fri Jun 19 19:59:04 UTC 2020 update.
All graphical artifacts are gone in X11. A change that I observed in both Wayland and X11 sessions is that GTK apps no longer inherit the color scheme of Plasma. This was the usual behavior, even though it was somewhat inconstant before (some days GTK apps just used their own colors).
I also noticed both in Wayland and in X11 that the laptop’s function key which is used to switch between screens is no longer operational, as it used to be previously. Other function keys (such as volume control) remain operative.
In Wayland:
– I use the KDE traditional cascading menu. This menu appears with artifacts. (OK in X11)
– In Audacious Qt: the Blur Scope appears completely transparent instead of a black background.
– The boot screen leaves an artifact after booting the desktop. This disappears after switching apps with Alt+Tab.
– I usually use my laptop with a large TV screen mirroring it. Now the TV screeen is no longer mirrored and this screen ignores the previous setttings (background, etc.) I had for a secondary screen. I had to unify outputs in System Settings.
Thanks again for this fantastic update.
Just another bit of info:
after starting wayland, the mouse pointer responsive as usual but it appeared much bigger. Somehow its size became smaller afterwards. Go figure.
Using X Server 1.20.8 on updated today slackware64-current. Upgraded the 5/kde and /deps packages per the README, removed ConsoleKit2 and installed elogind although I boot to level 3 and startx (initrc.plasma).
Problem is no sound in X. Pavucontrol tells me no output or input devices found. Alsa not installed. Audio device: NVIDIA Corporation GK104 HDMI Audio Controller
$ sudo lsmod | grep nvidia
nvidia_drm 49152 3
nvidia_modeset 1118208 12 nvidia_drm
nvidia 20434944 639 nvidia_modeset
drm_kms_helper 204800 1 nvidia_drm
drm 536576 6 drm_kms_helper,nvidia_drm
ipmi_msghandler 61440 2 ipmi_devintf,nvidia
i2c_core 81920 4 drm_kms_helper,nvidia,i2c_i801,drm
$ sudo lsmod | grep snd
snd_hda_codec_realtek 122880 1
snd_hda_codec_hdmi 57344 1
snd_hda_codec_generic 86016 1 snd_hda_codec_realtek
ledtrig_audio 16384 2 snd_hda_codec_generic,snd_hda_codec_realtek
snd_hda_intel 45056 0
snd_intel_nhlt 16384 1 snd_hda_intel
snd_hda_codec 147456 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core 94208 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep 16384 1 snd_hda_codec
snd_pcm 114688 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer 36864 1 snd_pcm
snd 90112 8 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
soundcore 16384 1 snd
~$ modinfo nvidia
filename: /lib/modules/5.4.47/kernel/drivers/video/nvidia.ko
alias: char-major-195-*
version: 440.44
supported: external
license: NVIDIA
~$ uname -a
Linux Senior.Envision 5.4.47 #1 SMP Thu Jun 18 13:15:42 CDT 2020 x86_64 Intel(R) Core(TM) i7-7740X CPU @ 4.30GHz GenuineIntel GNU/Linux
Upgraded to the latest firmware et al from todays Changelog, installed the alsa-libs and all is working. Thought I didn’t need alsa libs with pulseaudio. Sorry for the noise.
Running the latest packages (X11 only so far) on two machines, smooth sailing. Awesome work! 🙂
Btw, KDE 5 is a massive upgrade for people with HiDPI screens. Thanks again!
Thanks Eric, the new plasma packages with elogind is working fine for me.
However, I noticed some warning messages when I removed the ConsoleKit2 packages. The output of the “removepkg ConsoleKit2” command showed some warnings about some files/directories not getting removed? I did not save the output, but I remember seeing “NEW” displayed with the warnings the output several times.
After rebooting and logging in again I noticed that the following ConsoleKit2 file remain on my system:
/etc/ConsoleKit/
/etc/ConsoleKit/seats.d/
/etc/ConsoleKit/seats.d/00-primary.seat
/etc/rc.d/rc.consolekit
I think removepkg failed to remove these files and directories because the last two files were “*.new” files as seen in the removed package listing of ConsoleKit2:
/etc/ConsoleKit/seats.d/00-primary.seat.new
/etc/rc.d/rc.consolekit.new
Removepkg did not remove the two files that originally ended in “.new”, and did not remove the non-empty directories.
So I am guessing it is safe to remove these orphaned ConsoleKit2 files.
These two files are indeed orphaned files from ConsoleKit2 package. You can delete them.
Thanks, I dd end up removing them.
Hi Eric,
Just a quick note for a BIG Thanks Eric.
I feel happy Pat and Slackware mainstream is receiving your input and contributions.
Are you going to update Slackware traditional ISOs to update my live slack USB?
Thanks
Hi Francisco,
I will generate a new set of Live ISOs soon enough.
Hi Eric,
Thanks Eric for the new set of Live ISOs.
I installed (setup2hd) to a Laptop and installed current addons at the end of the process after downloaded those .sxz files.
Installed each one (unsquashfs -f -dest /setuphd /path..to..sxz..addon/addon.sxz)
In this order: 1) 0060-alien-current-xxxx.sxz 2) 0060-alienrest-current-xxxx.sxz
FYI, I got this warning message installing on step 2) above.
create_inode: failed to create character device /setup2hd/usr/doc/ffmpeg-4.3, because file exists.
Rebooted all went smooth without problems.
After the first slackpkg update + install-new + upgrade-all two installed ffmpeg packages were detected by slackpkg. I was offered an option to delete one, I deleted the one with the lower version.
After this, and the slackpkg upgrade process, all is working fine no more warnings reported.
Thanks again for this release, Francisco.
Since switching to elogind yesterday, starting in runlevel 4 I’m presented with the Virtual Keyboard at login. This seems to happen after sddm detects multiple failed login attempts. Here’s a snippet from /var/log/sddm.log:
[11:33:17.576] (WW) DAEMON: Authentication information: “Last failed login: Sat Jun 20 11:25:49 EDT 2020”
[11:33:17.576] (WW) DAEMON: Authentication information: “There were 17 failed login attempts since the last successful login.”
[11:33:17.576] (II) HELPER: Starting: “/usr/share/sddm/scripts/Xsession \”dbus-run-session /usr/bin/startplasma-x11\””
[11:33:17.580] (II) HELPER: Adding cookie to “/home/rherbert/.Xauthority”
[11:33:17.595] (II) DAEMON: Session started
I’m able to enter my password with my physical keyboard, and can log in without further problems. This is repeated per session; if I log out of KDE-Plasma, the Virtual Keyboard is shown again. This isn’t a show-stopper for me as far as using KDE is concerned.
Thanks.
Oh, gawd!!! Always solving my own problems after posting. 🙁 All it took was adding this to the now bare-bones /etc/sddm.conf:
[General]
InputMethod=
Sorry!
Excellent job on this release!
Thanks to me bothering to check here before attempting to upgrade, I had absolutely no problems.
I also managed to try out Wayland out for the first time. Since I haven’t run into any major annoyances with X11 compatibility yet, I think I’ll continue using Wayland.
Thanks for the reply.
Sorry I didn’t notice the bit in the README (probably due to the excitement!)
Regarding the mouse bit, I did set the KWIN_DRM_USE_EGL_STREAMS to 1 in the kwin.sh as instructed in the article. and it is really only the mouse. keyboard actions are as expected.BUT I actually misread the article as I am running the nouveau driver not the proprietary nvidia one.
using GBM (i.e., not setting the KWIN_… environment variable worked until the machine hard crashed on loading something. plasma was reloading all the application that were running before I restarted so something in there didn’t like wayland but I don’t know for sure what (although acroread is probably a good candidate).
I have tried to start the plasma session without restarting the previous session and I still get a complete hard crash within 20 seconds of the wayland plasma session starting. So it was not Adobe reader the culprit!
A couple of times I think kwin crashed as I ended up with a blank screen, and windows but not background or desktop or menu panels.
I am not sure where to look for hints as to what is going on though
Thanks so much for your hrad work and devotion to this project. I’ve been using your KDE releast packages for years and always look forward to updates.
I’ve a bit of an issue this time around, however. Using the absolute latest Slackware64-current and your KDE 5_20.06 I get a graphically corrupted and unusable desktop when using plasma or plasma failsafe. If I switch to Wayland with SDDM, just about everything works. I’m not ready to switch over to Wayland at this time. Am I missing something?
-thanks again.
-ED
Just (cosmetic), in ‘sddm-qt5’ package ‘man’ is in /usr/share .
Thanks once again for an excellent release! All is running smoothly here, except for one minor irritation. I’ve started having problems with notifications, as outlined in this thread: https://www.linuxquestions.org/questions/slackware-14/notifications-in-the-latest-kde5-plasma-ktown-packages-4175670133/ (defaults to the Xfce daemon!)
I’ve not experienced this before.
The thread provides a “band-aid” fix, which works, but I note that other distributions (notably Fedora) ran into this some time ago. I haven’t found any other mention of it, so I don’t know if they found a “proper” fix or not.
This is one xfce4-notifyd, bug, it’s fixed, on news (R.Workman) package xfce4-notifyd here:
http://slackware.uk/people/rlworkman/current/x86_64/
Thanks for the pointer, Gerard, but it didn’t work here. I updated the xfce4-notifyd package, and all seemed well at first. Logged out of Plasma and into xfce, then out of xfce and back in to Plasma and no audio out at all! The system was only showing HDMI, no analogue devices.
I suspect other things need updating in Xfce as well. I rarely use Xfce, so I may just uninstall it until 15 comes along. All my systems have slowly become something of a “patchwork quilt” whilst awaiting 15. I really want to do a fresh install on them all, but I’ve been hanging on for 15 to do it.
A reboot has sort of restored things, but I’m going to have to re-apply the “band-aid”!
—
Pete
Pete, is this the XFCE from Robby Workman? The XFCE notifications are not showing up here and I use the XFCE of Slackware-current.
Hi Eric,
No, its the stock Slackware-current installation. I’ve just tried adding Robby’s notifyd package, as suggested by Gerard, but it didn’t help. It does vary slightly between my machines (two desktops and two laptops) and seems to be triggered by logging in to Xfce. If I do that, unless I restart, when I log back in to Plasma I get no analogue sound out at all. It doesn’t even show any devices, only HDMI ones.
On all the machines bar one, if I look at the “notifications” page under system settings in Plasma, its all greyed out, and there is an info flag showing that states that notifications are being handled by Xfce’s notify daemon. The one odd machine out than started doing the same after I logged into Xfce!
If I add the band-aid suggested in that thread on LinuxQuestions, normal service is resumed, but only for that individual user. It is not a system-wide fix.
I think Gerard is right in that something in Xfce is taking over Plasma’s notify daemon and not releasing it back again. Or maybe, Plasma is not reclaiming it once Xfce has got hold of it. Why this behaviour should change with the latest update is outside of my competence to explain.
Quite honestly, my machines have now had so many patches and updates applied to them over the last couple of years, its a miracle they still work at all! 😉 I suspect quite a few things will get sorted when I can do a clean install of 15!
Cheers!
Sorry, this xfce4-notifyd Robby’s package is for xfce4-4.14, i have omit to said that, I use the entire package of Robby, including upower and without the pakages which are the same name and version as those of Eric Robby .
Thanks, Gerard! I guessed that it probably needed something else from Robby’s Xfce to work properly!
I don’t use Xfce much. I used to, at one time, on an under-powered laptop that struggled with Plasma5, but these days most machines have such an excess of computing power that such precautions are no longer needed.
I may try removing Xfce altogether until Slackware 15 is released. My systems have had so many patches and updates applied over the last year or so that I’m surprised they still function! Roll on 15, so I can do a clean re-install!
Thanks for this!
It took me some time making it work, but I finally got it. I have your packages updated with slackpkg+, but still the only way I was able to make it was removing completely kde and then installing your packages from scratch. I guess I missed something or added something I was not aware of. Anyeay, it finally worked.
And running Plasma with Wayland works pretty weel so far, but I have found one strange behaviour so far: using Chromium (your package chromium-83.0.4103.106-x86_64-1alien), when trying to access a second level folder in the bookmarks, it doesn’t work fine when using the mouse. I can do it using keyboard, but when trying to hit it with the mouse, the first level folder works fine, but when open the second level, the pointer lose the focus. It is really weird and, so far, I’ve only seen it with Chromium. And this is not happening to me on Plasma with X11.
Have you seen this?
Thanks again!!
I have some issues with loginctl. When I use startx to start my X session everything works as expected, but when I use xdm I got an error like:
loginctl reboot
Failed to reboot system via elogind: Interactive authentication required.
I have tried to recompile xdm but without success. Are there any additional compile flags necessary in order to make it work?
@lioh,
Robby Workman is prodiving a xdm package with elogind support. It’s available at:
https://rlworkman.net/pkgs/current/x86_64/xdm-1.1.11-x86_64-1_rlw.txz
Hello.
I am a novice user in Linux and passionate about the Slackware distribution and I admire your work regarding the ktown packages, as they make it easy to update the KDE environment safely and quickly.
However, in that last update, I encountered some problems. I strictly followed the instructions (README on the Ktown page and those on this page), but I can’t access the graphical environment.
Believing that I could have forgotten some configuration detail, I tried the same process on another physical machine, a notebook, and two virtual machines, and for the first virtual machine I used the Slackware64-Current iso from the website https://slackware.nl/ slackware / slackware64-current-iso /, dated 2020.06.19, and for the second virtual machine, I used the ISO Slackware64-Current from https://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso /, date of the day 2020.06.19.
However, in all cases I got the same result:
dbus[19550]: Unable to set up transient service directory: XDG_RUNTIME_DIR “var/run/user/1000″ is owned by uid 1000, not our uid 0
error name=”org.freedesktop.DBus.Error.ServiceUnknown”,
error message=”The name org.freedesktop.locale1 was not provided by any .service files”, signature=”s”, contents=(“The name org.freedesktop.locale1 was not provided by any .service files”) )
QStandardPaths: wrong ownership on runtime directory /tmp, 0 instead of 1000
QStandardPaths: wrong ownership on runtime directory /tmp, 0 instead of 1000
QStandardPaths: wrong ownership on runtime directory /tmp, 0 instead of 1000
unable to open lockfile /run/user/0/wayland-2.lock check permission
repeating until …
unable to open lockfile /run/user/0/wayland-32.lock check permission
FATAL ERROR: could not create Wayland server
“/usr/bin/kwin_wayland” (“–xwayland”, “–libinput”, “–exit-with-session=/usr/lib64/startplasma-waylandsession”) exited with code 1
startplasmacompositor: Shutting down …
startplasmacompositor: Done.
In addition to the aforementioned attempts, I redid the attempt to update, downgrading to the previous version (including reinstalling consolekit2) to try to find the error again (I believe it was not the correct steps, but, anyway, I tried anyway).
If you can help me to identify this flaw and a possible solution, I am very grateful.
Thank you.
Most likely with mysterious errors and inexplicable errors like yours, this is caused by incompletely upgrading to the required set of packages.
Did you upgrade dbus to the package in my ‘ktown’ repository? Likewise for the polkit package?
Did you check all the installed *.new files and ensured that the new content is being used (slackpkg new-config will help you there)?
I am also wondering about several occurrences of user “0” aka root, in your error output, ending with “unable to open lockfile /run/user/0/wayland-32.lock check permission”. How are you starting an X session? How are you starting Wayland? And logged-in as what user?
This is huge, thank you Eric!
I know I should get some sleep, but ater finally reding your post (and instructions and warnings) I can’t wait till tomorrow to upgrade 🙂
Fingers crossed!
I will mention the issue that I had and got fixed
“Qt5 >= 5.15 is a requirement, luckily we already have that in Slackware.”
Unfortunately my qt5 was stuck at 5.13.x because I had it blacklisted as an [alien] version along with other AlienBob stuff. No problemo – I zapped 5.13 and “slackpkg install-new” found the missing 5.15 and installed it and “voila!”, plasma is running again.
We might keep an eye out for such as Slackware -current picks up AlienBob stuff.
Eric, in the ‘sddm-qt5’ package, ‘man’ is in /usr/share ;/
package dep ‘rttr’ have two differents /usr/doc/rttr-0-9-6/ and /usr/doc/rttr-0.9.6/ and also, /usr/doc/index.html
Hi Gérard,
I will do something about your reports about package quality only if I get the patches to fix. I will not have time otherwise.
Ok, Eric, it’s just suggestion.
Hi Eric, thanks for these release.
Do you remember we were having some issues related to polkit.
Investigating around, found that gentoo and other non-systemd distros solved as you did using elogind.
Im testing this new released, and seems to have solved multiple-users shutdown issue.
Maybe, my question now is: may pat introduce elogind?
kind regards from argentina!
You can see a few things happening:
I added elogind to my ktown repository; Robby Workman added elogind to his XFCE repository, and Patrick modified some of the Slackware scripts so that both Robby’s and my own packages can be installed on top of Slackware without any modification of the OS required.
I leave the predictions about what this means to you.
I have installed everything, following the instructions, and everything works well.
The only change is that previous sections are not restored exactly as they were (everything is in desktop 1). But I think that this comes from the new version of KDE5, and not from elogind.
I’m not 100% this is related to the update, but I appears to be. My Steam icon in the System Tray no longer has a menu. I have the both the sni-qt-compat32 and libdbusmenu-qt-compat32 installed. I tried removing those packages to see if it make a difference. It doesn’t. Any ideas?
Thanks Chris
Hi Guys, Eric,
I had just upgraded from ktown 5 19_12 to 20_6. Followed the instructions in README for slackpkg+. For context I have a clean install from liveslack usb from April. After upgrading the system when i boot the machine into runlevel 3 , I can not login. I get ‘/bin/login: error while loading shared libraries : libpam.so.0: cannot open shared object file: No such file or directory’. Any help fixing the issue is appreciated.
have you installed ‘pam’ slack current package ?
If I remove Consolekit2 then Calibre cannot mount my Kobo :
Devices possibly connected: KoboTouch, KoboTouchExtended,
Trying to open KoboTouch … Udisks mount call failed:
Traceback (most recent call last):
File “site-packages/calibre/devices/usbms/device.py”, line 547, in do_mount
File “site-packages/calibre/devices/udisks.py”, line 194, in mount
File “site-packages/calibre/devices/udisks.py”, line 58, in mount
File “site-packages/dbus/proxies.py”, line 70, in __call__
File “site-packages/dbus/proxies.py”, line 145, in __call__
File “site-packages/dbus/connection.py”, line 651, in call_blocking
DBusException: org.freedesktop.UDisks.Error.PermissionDenied: Not Authorized
Gwenhael, yes Calibre is one of the few packages that have a hard dependency on either elogind or ConsoleKit2, so it will have to be rebuilt to the particular package which is present on your computer.
Eric, a huge THANK YOU for all your work and persistence. Like others, I also think systemd is anti-UNIX, but by modularising things like eudev, PAM, and elogin we can cherry-pick the best bits we like in a very contained fashion which is EXACTLY the principal that draws us towards the wonderful Slackware collective. I get sad when people say that Slackware is dead/dying because they just don\’t get to see the bleeding edge stuff like this which is where most Slackers are now living. Hopefully we can get a 15.0 release this year and it will snatch the wigs off all the Slackware haters. Fingers crossed.
Thanks Eric! Updates went well and everything works. I have no idea if this is related, but your restricted VLC package segfaults now.
Eric, Does this mean that Slackware is being prepared to migrate from SysV to Systemd?
Hi Néstor,
You obviously have not been following Slackware for the past couple of years, yes?
Also you don’t seem to really understand the meaning of this blog article. Perhaps it is a language problem, so let me explain:
Slackware will stick to the init process it has always had, which is a BSD-style init with System V init compatibility. See http://www.slackware.com/config/init.php .
We cherry-pick the parts of systemd which are relevant for a systemd-free OS which still likes to use modern software and thus cannot depend on un-maintained core software. This is why we adopted eudev in favor of udev and now we may replace ConsoleKit2 with elogind.
These parts are not related to the systemd init implementation, we are not interested in that.
Eric, LoL
You’re right, I disconnected from slackware for 3 years, and upon seeing these updates I come back.
I have always considered Slackware to be one of the best Linux distributions I have ever used.
First Slackware then Debian. But now I am testing Devuan because I am more comfortable with System V init.
Thanks for your response, it is always nice to read your articles, as well as those of Willy Sudiarto.
Infinite thanks.
A couple of days ago I post about an issue I was having regard the Steam icon in the System Tray. Click on the icon is suppose to show a menu. Prior to this update it was. That said I found the solution. Starting Steam from Konsole, I found that on clicking the icon (left or right) resulted in the following error:
“LIBDBUSMENU-GLIB-WARNING **: 17:29:35.161: About to Show called on an item wihtout submenus. We’re ignoring it.”
I little bit of research found that the possible solution was to add libdbusmenu-gtk. I know there is a libdbusmenu-gtk in ktown, so I decided to create a compat32 package from the x86 libdbusmenu-gtk I found in your repository. After installing this new package the menu on the Steam icon in the tray is again functional and the errors no long appear.
No sure what trigger this problem I know that libdbusmenu-gtk has been in ktown for a while now. At least the problem has been fixed.
I decided to also remove both libdbusmenu-qt-compat32 and sni-qt-compat32 and test some more. No adverse effects, so for now I will leave these removed. Steam is the only 32-bit program I use anyway.
I really need to proof read before posting.
Hello,
ok I have to ask it 🙂 I know that the answer will be “because”, “it’s hard coded this way”, etc. but I cannot help it……
why elogind is in /lib64/elogind and not in /usr/sbin ?
Sorry! 🙂
elogind is not meant to be run as a (root) user, so it makes no sense to have it in any (s)bin directory.
VLC is fine. It seems I also forgot “slackpkg install-new”…..sorry for the noise. 🙁
Hi Eric,
I’m sure you are aware, but the recent change in Slackware-current to ffmpeg-4.3.X seems to have broken a few things in plasma5 that depend on ffmpeg – most notably Kdenlive.
Strangely, although kdenlive complains that x264 is not available for mp4 or mkv, it *does* show it being available under the “lossless” section in rendering!
Maybe we need another ffmpeg-compat ?
Regards,
—
Pete
Hi Pete,
This is -current, it means that 3rd party packages can break when Slackware libraries are updated. I do have “compat” packages for things like boost, icu4c, poppler, because their upgrades will break core functionality. But I am not going to add a “ffmpeg-compat”. Until I release a new batch of Plasma5 packages it would perhaps be best if you recompile Kdenlive yourself.
Hi Eric,
I used to compile kdenlive back in the days of kde4, and it was a nightmare! I hesitate to take this path again, as I seem to recall that a lot of kdenlive’s dependencies also use ffmpeg (mlt? Freior? – its a while since I did it!). I could end up in dependency hell again! 😉
I think for the moment, I will just install the appimage, as suggested by Regnad below. I’ve already recompiled a lot of my multimedia stuff to work with ffmpeg-4.3.x, so going back to an earlier version isn’t really an option.
I do very much appreciate your efforts to get Slackware into the 21st century, but just wish that Patrick would get a move on integrating Plasma5 into Slackware. It would avoid hiccups such as this….
—
Pete
Update: I tried rebuilding kdenlive, which compiled fine but didn’t solve the problem – still no mp4, mp3 or matroska available in render. I thought it might be mlt at fault, so I tried rebuilding that, but the compile failed with the following error:
“graph.cpp: In function ‘void paint_line_graph(QPainter&, QRectF&, int, float*, double, int)’:
graph.cpp:156:15: error: aggregate ‘QPainterPath curvePath’ has incomplete type and cannot be defined
156 | QPainterPath curvePath;
| ^~~~~~~~~
make[2]: *** [: graph.o] Error 1
make[2]: Leaving directory ‘/tmp/mlt-6.20.0/src/modules/qt’
make[1]: *** [Makefile:5: all] Error 1
make[1]: Leaving directory ‘/tmp/mlt-6.20.0/src/modules’
make: *** [Makefile:9: all] Error 1
mlt failed to build.”
I have no idea what is wrong there! Back to the appimage for the time being, I guess!
You would require this patch to compile mlt against Qt 5.15: https://github.com/mltframework/mlt/commit/f58b44d7.patch
Er, OK! Remember that I am NOT a programmer! I can see a patches folder in the mlt directory, but I can’t see anywhere in the slackbuild where these patches are applied. I would expect to see them applied after the source tarball is unpacked but before the configure and compile begins. However, I can’t see anything. Does that mean the patches in that folder are no longer needed, or have I missed something?
Sorry if this is a silly question, but I haven’t done any serious programming since the days of 6502 assembler!
—
Pete
WooHoo! Got it fixed! Yes, mlt was the culprit. I took the coward’s way out and applied the patch manually (very simple)! Mlt then built and installed itself using your “alldeps.Slackbuild mlt”.
I now have a fully functional kdenlive again!
Thanks for your help and support!
—
Pete
Hi Eric,
I don’t know if someone else have the same problem, but using wayland brings some strange behaveours in libreffice
When I past unformatted text ( (ctrl+maiu+alt+v) it paste text in Chinese and no way I can change the language, but this doesn’t happen in “normal” plasma session.
I’m not able to understand why.
Cheers.
Michelino
My suggestion would be to search whether anyone else has already reported your issue, or else open a new bug report on https://bugs.kde.org/ . I think Wayland is not yet ready for use as your daily driver. I do not use it myself. The move to elogind was to show that Wayland can work, but that it needs ConsoleKit2 to be replaced with elogind. The fact that Patrick modified the Slackware init scripts to support either of CK2 or elogind does not mean that the decision to replace one with the other has already been taken.
My Plasma5 packages on ‘ktown’ are the testing ground for that eventual decision.
Yep, I know, I was using Wayland just to test purpose.
I wasn’t able to find another who had the same problem, so I think I’ll file a new bug report on bugs.kde.org.
Thanks!
@pete christy
I sometimes fix my kdenlive problems by installing the kdenlive appimage.
I just copy it to /opt, make it executable with chmod +x and make a link to it.
I also remove the kdenlive package.
I find that this works and gets me going again.
Thanks for this suggestion! It is something I have thought about. Compiling kdenlive can quickly descend into dependency hell, as I discovered back in the kde4 days! I’ve already re-compiled a lot of my multimedia programs around ffmpeg-4.3.x, so going back to an earlier version is not an option.
Cheers,
—
Pete
Hi Eric,
espeak-ng and pcaudiolib were added today to -current so I think they could be removed safely.
Thanks!
The TTF font packages were added too. All will happen in due time.
Hi Eric,
I built a brand new system on top of a slackware-current updated to yesterday branch , and installed your Plasma5 KDE-5_20.06. All works fine then Libreoffice.
I tried your package first, then I built 6.4.5 from sbo, then 6.3.6 but always same result: I saw splashscreen then all freeze and nothing in X respond anymore.
I tied to launch from konsole but no error messages… any ideas about? thanks in advance
Works fine for me, and i get no complaints from other people. I can not tell you what is wrong on your computer, unfortunately.
Ok, I’ll work on, thanks for your reply,
Best Devis
Would it be cleaner to replace elogind with greetd and seatd if only limitation is on wayland? Found elogind gave a lot of surprises in power management with wrong and obscure sequences.
Bit late to the show, motifx? Also, did you experience these issues on Slackware?