My thoughts on Slackware, life and everything

Tag: kde5 (Page 1 of 17)

December updates and a Christmas goodie for cable geeks

The silent treatment?

Hi there.
I know I have not been posting a lot the past few months. Sorry for that, really.
The last quarter is always a busy time at work and especially so during Corona; my mother fell ill; I sort of crashed when I ran out of energy; and it was a lot of work to clean up shop after my Plasma5 ‘ktown’ first got adopted as Slackware ‘vtown’ in testing and a bit later replaced the old KDE4 in the core distro. Lots of package recompilations and upgrades to work with the newer stuff in Slackware.

I also worked on (finally) migrating the old ‘bear’ server which was hosted in France, to a newer and more powerful server running in an Amsterdam Data Center. The new server ‘martin’ was mostly ready when I thought, let’s reboot ‘bear’ after applying the latest Slackware security fixes. And then it did not come back up… that was not a comfortable moment, since ‘bear’ not only hosts my own package and git repositories, but also The Slack Docs Wiki, the Slack Docs mailing lists, my own personal Wiki and some private family sites. I opened a support ticket and it turned out that the hard drive had crashed and all data on it were irrecoverable.
Luckily I had just finished making a set of backups and right before that fateful reboot, had discovered that my backup scripts omitted part of the server data… which I had also fixed just in time before  that crash.
It took some additional energy to get the services up and running on ‘martin’ again as soon as possible. I had made some new designs for the new server OS configuration and the new configs were un-tested… I hope not too many people noticed the partial down during the second half of November.
The new server runs fine now, has more disk space especially, so I can finally host the full history of Slackware releases and also the DAW and CINNAMON Live ISO images for which there was no room on ‘bear’.
Thanks again to those people who send me money un a regular basis so that I can pay the monthly rent of ‘martin’!

Despite that stress I have been enjoying myself still, just not in the spotlights. The semi-sudden switch in Slackware from KDE4 to Plasma5 and refreshing its XFCE Desktop had some consequences for my liveslak project. It took some time to work out a new optimal package set for the small XFCE image, and in particular the DAW Live image which is based on a bare Plasma5 Desktop needed attention to make it tick again.

So what’s new in Slackware DAW Live?

Remember: DAW = Digital Audio Workstation.
Read my original article documenting the research into a comprehensive collection of musician/producer oriented free and open source software, and a follow-up article on how to transform a Slackware system into a powerful Digital Audio Workstation.

Art work

I asked you in a previous post to come up with ideas for artwork to use in my Slackware Digital Audio Workstation. Thanks for those who contributed graphics and ideas – all of that creativity has been preserved here on the blog.
I decided to use the image to the left of this paragraph – a Slackware ‘S’ with headphones – as the icon to use for the “Slackware Live DAW” submenu. Contributed by Daedra and slightly colored by me.

I needed a second icon as well, to represent the ‘face’ of the Live user account, and for that I picked one of the contributions from Bob Funk: a Slackware ‘S’ with a TRS jack. You’ll see this one when you boot up the ISO and are asked to login at the SDDM graphical session chooser.

More art work was contributed by Sceptical-C, a friend of mine who doubles as a DJ, musician and producer. His black and white photography are the basis for several Plasma5 wallpapers and one of his photographs is also used as the background in the login and lock screens.

DAW_base package

I decided to move the configuration  of the DAW Live OS’ realtime capabilities out of the liveslak scripts and into a new Slackware package. This package called “daw_base” can be installed on any Slackware computer (preferably Slackware-current with PAM). It configures the OS in such a way that a user who is a member of the Slackware “audio” group is allowed to start applications with real-time scheduling priority. You’ll need that if you want to prevent sound drop-outs (also called XRUNs) during performing, recording and mixing. Some more tweaks are being made, they are documented in the package’s README.1st file. This package also contains the Plasma5 wallpapers which are created from the original Sceptical-C black-and-white artwork.
The package creates a new sub-menu in “Applications > Multimedia” called “Slackware DAW” and collects all my DAW related software in there. The submenus in “Multimedia” for the X42 and LSP plugins are moved into the “Slackware DAW” menu to keep it all closely together. This is very similar to what DAW Live also contains. Just the word “Live” is not present in the name of that menu installed by ‘daw_base‘.

The daw_base package also installs a template file for Slackware’s package manager ‘slackpkg‘. The template called “daw” contains a list of all DAW related software in my package repository and it allows for an easy installation and maintenance of that software collection.

New additions to the musician’s toolkit

Several packages needed a recompilation after the recent Slackware upgrades that are related to the new requirements for XFCE and Plasma5. I used that opportunity to upgrade software to their latest versions instead of recompiling – like Ardour, Mixxx, Jamulus, Guitarix for instance. But I also looked into some new stuff, mostly because people asked me about it. Here they are:

Zrythm.
An intuitive digital audio workstation all in itself. It’s under heavy development and nearing a 1.0.0 release. It supports LV2 plugins, offers a high level of automation, and looks really good. Perhaps an alternative for those who feel Ardour’s learning curve is too steep.

VCV Rack.
VCV Rack by the VCV project is a software emulation of the Eurorack Modular Synthesizer.
The project’s mission statement contains this line which resonated with me: “… the principle behind modular synthesizers is identical to the UNIX philosophy, where stable, minimal modules working together are preferred to a monolithic platform controlled by a single vendor (like portable synthesizer keyboards)“.

A short intermezzo first. My first experience with modular synths was as part of the audience when attending a concert by Pere Ubu, 1981 in De Effenaar in EIndhoven. Alan Ravenstine handled a huge contraption full of patch wires that produced all sorts of weird and interesting sounds. It’s what gave Pere Ubu their uniquely distinctive sound. I read later that he worked with EML modular synthesizers a lot but at the time I didn’t know. Damn impressive, but I decided that industrial sounds were more to my liking. This was during the early rise of Electronic Body Music, and that got me hooked for a while. If you can find the documentary “I dream of WIres” I recommend you watch it. The web site http://idreamofwires.org/ is dedicated to documenting the history of electronic music. An excerpt of a little more than 20 minutes is freely available, it contains an interview with Pere Ubu synth players Alan Ravenstine and Robert Wheeler.

Anyway – back in May 2019, a blog comment by ‘Hank’ already referenced VCV Rack with a question whether I would perhaps consider it for inclusion to my DAW software collection. At the time, my focus was on other things and a modular synthesizer is not the easiest instrument to work with, so I let that pass. But some recent youtube footage sparked my interest and here is the result – a Christmas present of sorts for you: packages for VCV Rack, and three free and open source plugins that expand the collection of available modules in Rack: vcvrack, vcvrack-audible-instruments, vcvrack-befaco and vcvrack-bogaudio.

Note that my VCV Rack package ‘vcvrack‘ contains the Fundamental plugin already. The software is quite useless without it so I decided to bundle it, just like the dev’s binary distribution. It is the only plugin which is automatically loaded by VCV Rack. If you install any other plugin, you need to execute one manual command to add the plugin to your user-directory: this will create a symbolic link to the ZIP file containing the modules and Rack will then automatically find and unzip this plugin and make it available to you.

$ ln -s /usr/share/vcvrack/Pluginname.zip ~/.Rack/plugins-v1/

All ZIP files in the VCV Rack system directory (/usr/share/vcvrack/) are module plugins – this is the format for distributing them.

Here is a Youtube tutorial series that you can use as an introduction to modular synthesis and VCV Rack in particular:

Enjoy! Eric

KDE Plasma 5 August 2020 release for Slackware

New Plasma5 packages for Slackware-current are ready for download & installation. I skipped July (holiday season) and so here is KDE-5_20.08 aka my August 2020 release. Be sure to read the upgrade instructions very carefully to prevent  breakage, because starting with my June batch the goal is to remove Slackware’s ConsoleKit2 and replace it with elogind!.

It would not harm if you (re-)read my previous blog article about Plasma5, “Replacing ConsoleKit2 with elogind – first steps“. It has a lot more detail about the reasons for this move as well as guidance on using the Wayland Window Manager (as a test) instead of regular X.Org. Note that Wayland sessions still need a lot of maturing and X.Org will remain Slackware’s default choice.

A repeat from that article: 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.

What news is there to tell about KDE-5_20.08?

This August ktown release contains the KDE Frameworks 5.72.0, Plasma 5.19.4 and Applications 20.04.3. All this on top of the Qt 5.15.0 in Slackware-current.

Deps:
The ‘deps’ section got a bit smaller again this month:

  • pcaudiolib, espeak-ng, hack-fonts-ttf, noto-fonts-ttf, and noto-cjk-fonts-ttf were moved into the actual Slackware distro. Things are progressing nicely in that regard.
  • flite has been removed since Pat decided we will go with just espeak-ng.
  • a new package ‘pipewire’ was added as a dependency for krfb and xdg-desktop-portal-kde.
  • The elogind-aware dbus package was upgraded to match the Slackware version.
  • Finally, qca-qt5 was upgraded and I recompiled mlt (to fix the broken kdenlive) and speech-dispatcher.

Frameworks:
Frameworks 5.72.0 is an incremental stability release, see: https://kde.org/announcements/kde-frameworks-5.72.0. A new ‘kdav’ source tarball got added but that is actually the same package you’ll find in KDEPIM. Next batch, the actual kdav package will be built from Frameworks sources.

Plasma:
Plasma 5.19.4 is a further increment of the 5.19 cycle (5.19.5 will be the last, in September). See https://kde.org/announcements/plasma-5.19.4 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 .

Plasma-extra;
In plasma-extra In plasma-extra I rebuilt sddm-qt5 to install man pages correctly, and upgraded plasma-wayland-protocols and wacomtablet.

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

Applications-extra:
For applications-extra, I updated digikam, krita, libktorrent and ktorrent, and skanlite.
Note that the size of the digikam source tarball ‘blew up’ due to the addition of new neural network facial recognition data files, but the actual package ‘only’ grew from 97 to 108 MB.

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

KDE Sources:
Not so visible but important nevertheless is this month’s contribution of Patrick Volkerding who validated all the KDE slack-desc files and enhanced/polished a lot of them. He also cleaned out the ‘patches’ directory and removed all the obsolete patches that are not being applied anymore. As you also will have noticed, Pat is slowly picking packages out of my ‘deps’ and adding them to Slackware. Even espeak-ng which I had not expected to happen.

Where to get KDE Plasma5 for Slackware

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 in May 2020 because they were un-maintained and had security issues.

Download the KDE-5_20.08 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 if you do not yet have elogind installed (i.e. if you did not install the ktown June 2020 release previously)!
In short:

  1. UPGRADE TO THE LATEST slackware-current first.
  2. Then, REMOVE the ConsoleKit2 package if you had not installed my June ktown batch before.
  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 took place in the ‘elogind‘ branch. I will fold these elogind developments back into the master branch soon.

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

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

Slackware introduces PAM into its core

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

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

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

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

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

Enjoy! Eric

Ktown Plasma5 packages for Slackware 14.2 will go offline soon

Hi all,

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

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

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

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

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

Good luck! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑