Main menu:


Please consider a small donation:



Or you can donate bitcoin:


Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank


FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.


Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 422 other subscribers

My Favourites



March 2019
« Feb    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current



Plasma5 – April 18 edition for Slackware

One of my previous posts discussed “ABI breakage” and how that affects software to the point where it breaks and you need to recompile stuff to un-break it. Well… last week was most likely another, bigger, surprise to many of you. The Slackware-current ChangeLog.txt update of “Thu Apr 19 01:04:06 UTC 2018” started with:

Hi folks, and welcome to the third ever Slackware Mass Rebuild (and the
longest ChangeLog entry in project history). There were two primary
motivations for rebuilding everything in the main tree. The first was to
switch to the new C++ ABI. The second was to get rid of all the .la files

That was fun, seeing 1365 lines of ChangeLog and realizing how long the upgrade would take!
But in the end, this was a painless migration. WIth a simple “slackpkg update ; slackpkg upgrade slackpkg” to upgrade the slackpkg package itself. Don’t forget to check the new /etc/slackpkg/mirrors file to see if your mirror is still configured there! Followed by “slackpkg update ; slackpkg install-new ; slackpkg upgrade aaa_elflibs ; slackpkg upgrade-all” and a lot of patience. That’s about all there was to it and after a reboot the Slackware-current system would run as well as ever. A big accomplishment and hats off to Patrick Volkerding who used the past months to (mostly under the radar) update all the SlackBuild scripts and write wrappers to enable him to recompile all of Slackware from scratch, while gaining a lot on the efficiency and time management front. Kudos!

Ah well, a painless migration you heard me say…
Unless you have a ton of 3rd party software bolted onto your Slackware – like my Plasma5… because that came out pretty much broken. On the Slackware forum as well as here on the blog I already advised to hold off with upgrading for a day or so to give me the opportunity to at least recompile Plasma5.

And it so happened that the KDE developers already had all-new source code tarballs waiting for us. I compiled that on the freshly rebuilt Slackware-current and yesterday evening I uploaded my new set of Plasma5 packages to the ‘ktown‘ repository.
The KDE-5_18.04 release of ‘ktown‘ for Slackware-current offers the latest KDE Frameworks (5.45.0), Plasma (5.12.4) and Applications (18.04.0). The Qt5 was upgraded to 5.9.5. Read the README file for more details and for installation/upgrade instructions. Enjoy the latest Plasma 5 desktop environment.

So, what’s new?

  • I had to deal with a couple of packages that were broken after the massive upgrade in Slackware, so I took the opportunity to upgrade gpgme, mlt, poppler and qt5 to a newer version; and I added QScintilla to extend the package (already available in Slackware) with support for Qt5.
  • In plasma-extra the kdeconnect-framework package was updated.
  • Applications 18.04.0 is the start of a new round of improvements. Two new packages are available starting with 18.04: kamoso which is a webcam recorder, and a backup program kbackup. The instant messenger client Kopete was ported to KF5 and is contained in the source distribution, but I was unable to compile it. Perhaps more luck next month.
    Finally, the hex editor okteta moved to the ‘applications-extra’ section because its developer no longer wants to be tied to Application release windows.
  • In applications-extra I have upgraded the kdiagram and krita packages.

If you want to read more about the history of Plasma5 development for Slackware, with lots more detail, check out my older blog posts. If you think a git log is easier to read, check out my ktown git repository instead 🙂

If you are using slackpkg with the slackpkg+ extension, don’t forget to run “slackpkg install ktown” to get any new packages installed, because “slackpkg install-new” will not catch new packages in 3rd-party repositories like ‘ktown’.

I hope to get a new PLASMA5 variant of the Slackware Live ISO image out soon, containing all this new stuff! This depends on my ability to recompile LibreOffice 6.0.3 for 64bit. I ran into a bit of a snag there with gpgme-related compilation errors I have as of yet not been able to fix. Also, VLC3 needs a rebuild since that broke too… and I have not been able to find the time to address that.

Enjoy the new batch!


Comment from Gérard Monpontet
Posted: April 21, 2018 at 17:48

Thanks Eric, work here 😉

Just a little thing, ‘kholidays’, is in frameworks; now.

Comment from Gérard Monpontet
Posted: April 21, 2018 at 18:00

Ok,’kholidays’ is in frameworks, but two versions appear here, (17.12.3 and 5.45.0) , in gslapt 😉

Comment from Gérard Monpontet
Posted: April 21, 2018 at 18:08

Sorry for the noise, Eric, it’s because, my gslapt is on wayland mirror 😉

Comment from Helios
Posted: April 21, 2018 at 18:48

Thank you very much.

I have found some old libpoppler in kile and calligra.(visualcompare)

Comment from Ginni Rometty
Posted: April 21, 2018 at 23:56

you an asshole to my people grow up. People that code are real. treat them nice.

Comment from Darth Vader
Posted: April 22, 2018 at 01:06

Eric, basically he blame you for “pushing” the Qt5 builds for Slackware, which in his very opinion, in the final “polluted” the “innocent minds” of SBO contributors, resulting in his business issues.

Folks, doing business on some software downloaded or built from whatever scripts downloaded from Internet, who are distributed with NO GUARANTEE of properly work or whatever, and without being able to manage them yourself or your own employees, it is plain ridiculous.

Even the Slackware itself comes with NO GUARANTEE. Use in your business at your very own risk.

Comment from Jen
Posted: April 22, 2018 at 02:45

Yeah, after another beer and having read the thread on LQ, that still doesn’t make sense. Maybe I need a third beer? ¯\_(ツ)_/¯

Comment from Jen
Posted: April 22, 2018 at 02:56

The response from “Ginni,” that is.

Comment from Helios
Posted: April 22, 2018 at 11:06

cryfs is also linked with the old version of boost

Comment from Phil
Posted: April 22, 2018 at 13:53

Looks like digikam needs a bit of TLC. Am getting digikam: symbol lookup error: /usr/lib64/ undefined symbol: _ZN5Exiv213XmpProperties10registerNsERKSsS2_

Comment from Wicksey
Posted: April 22, 2018 at 14:30

Can I just take this opportunity to reiterate my thanks to you, Eric, for the hours and hours you give so that users like me can enjoy and benefit from an excellent distribution. It is hugely appreciated. Kudos. Ta.

Comment from alienbob
Posted: April 22, 2018 at 15:11

To address all the reports about packages in ‘ktown’ that still had issues:

Sun Apr 22 12:54:32 UTC 2018
current/deps/cryptopp: updated.
current/deps/cryfs: rebuilt.
current/kde/applications-extra/calligra: rebuilt.
current/kde/applications-extra/digikam: rebuilt.
current/kde/applications-extra/kile: updated.

Soon coming to a repository near you.

Comment from Darth Vader
Posted: April 22, 2018 at 16:58

Thanks, Eric!

Now everything looks OK on Plasma.

And specially thanks for the LibreOffice and VLC3 updates.

Comment from Gérard Monpontet
Posted: April 22, 2018 at 17:41

With all, RE thank you, Eric 😉

Comment from ArTourter
Posted: April 23, 2018 at 00:12

Thanks Eric for all your work.

Just one note regarding the changes to -current, Patrick is now building his packages without any .la files. Most of your packages follow this but some of them this do.

Here is a list the packages with .la file in /usr/lib64/ that are installed on my system (mostly ktown but also a few for your sborepo and restricted:

/var/log/packages# grep *alien -lo -Ee “usr/lib64/.[^/]*\.la$”

Hope this helps



Pingback from Links 23/4/2018: Second RC of Linux 4.17 and First RC of Mesa 18.1 | Techrights
Posted: April 23, 2018 at 10:42

[…] [Slackware] Plasma5 – April 18 edition for Slackware […]

Comment from Kyril
Posted: April 23, 2018 at 15:32

Is it possible to include this qt5 path for this bug?

It’s hard to work without this fix with KRDC

Comment from alienbob
Posted: April 23, 2018 at 21:34

Well… it is a two-year old bug, so I am not exactly in a hurry to fix it, now that you mention it.
I’ll think of it next time qt5 needs a recompile.

Edit: on second thought after having read a related bug report – the developers state “This is an intrusive patch that adds QPA apis. It won’t be backported to Qt 5.9“. I will skip this one. Sorry.

Comment from alienbob
Posted: April 25, 2018 at 09:32

I fixed the kopete compilation issue and uploaded a package for it to my repository.
If you are using slackpkg+ and have my repository configured as ‘ktown’ all you need to do is “slackpkg update ; slackpkg install ktown” to get the new package(s).

Comment from Darth Vader
Posted: April 25, 2018 at 13:58

Eric, maybe you want to update the GPGME again?

As you probably know, Patrick Volkerding updated it to version 1.11.1

Comment from alienbob
Posted: April 25, 2018 at 19:45

Yeah, but no time. Too busy with work.

Comment from Hubert Phava
Posted: April 26, 2018 at 17:00

Hi Eric…
My scenario is: 64–current syncronized wih all Pat’s new things, your multilib and ktown packages. Nvidia prop drivers ( 64-390.48 version).
When I fire “startx”, a little bit time after i have one of my 8 cores-cpu at 100%, due to a kwin_x11 –session (htop monitored).
If i kill it, all becomes fine with no fans screaming in my computer case. After killing that, obviously some other kwin_x11 sessions remain in bacground.
Other issue: every time “kscreenlocker_greet” starts after some minutes, i receive a black screen with something similar to “kscreenlocker had crashed; flip over a console and give *loginctl –unlock* and return to graphic session ( ok, i dont’ remember the right words but the above is a good approx. The program “loginctl” des not exist in my system….
Any suggestion?
Till now i have give a “chmod -x kscreenlocker_greet” as a workaround.
Thanks (again and again…) for your work…

Comment from alienbob
Posted: April 26, 2018 at 19:16

Hubert Phava, what repository URL are you using for my ktown? The error message about “loginctl” should never occur with my “latest” repository. It is triggered by the existence of the login1 service, which is only offered by systemd-logind and elogind. Those are not in my repository.

The CPU stress issue and kscreenlocker crashes also hint at a software incompatibility, whether it is the Nvidia driver or the Plasma5 software I can not tell.

Comment from Hubert Phava
Posted: April 26, 2018 at 19:31

I use the “latest” repo from your ktown, downloaded with wget and installed with “upgradepkg –install-new –reinstall” in init1 mode. Done this from your very first plasma release and no problems at all, with screensaver till now.
Boh…. I’ll try nvidia-beta stuff…
Thanks Eric

Comment from alienbob
Posted: April 26, 2018 at 21:11

Hubert, did you follow my ktown README from release to release where I tell you what packages to remove (when relevant)? You may have ended up with obsoleted cruft.

Comment from alienbob
Posted: April 26, 2018 at 21:54

Darth Vader, tonight I found time. I updated gpgme and patched a bug out of powerdevil.

Comment from Darth Vader
Posted: April 26, 2018 at 23:24

Thank you for your efforts, Eric!

Comment from Hubert Phava
Posted: April 26, 2018 at 23:41

Eric: your ktown-Readme hab been my bile till my first installation of your packages.
Now, setting the -x flag to kscreenlocker_greet seems to be a good choice: i have a blank screen and no crashes


Comment from Gustavo Brondani Schenkel
Posted: April 27, 2018 at 01:58

Eric, I got the same ‘loginctl unlock-sessions’ mention by Hubert Phava. I only use packages from Slackware itself and from your ktown, with the exception of VirtualBox and slackpkg+. I left my virtual machine(virtualbox), which runs Slackware Current, upgrading while I went to work, and I just came back and saw that message.
I did ‘slackpkg update’ > ‘install-new’ > ‘upgrade-all’ and went work, and didn’t run yet the ‘clean-system’ neither ‘install ktown’. I will do now, only posting as notation. Cheers and ty for your hard work!

Comment from Gustavo Brondani Schenkel
Posted: April 27, 2018 at 05:51

I ran ‘slackpkg clean-system'(lots to be removed) >> ‘install ktown'(some to install) and the previous message didn’t showed again, appears was either a obsolete package or a missing one.

Comment from alienbob
Posted: April 27, 2018 at 23:41

Gustavo – I assume your problem was the same as with Hubert – a left-over package (perhaps elogind, or else ConsoleKit2 from my wayland-testing repository). When you removed that, the loginctl error was gone and so were the incompatibilities.

Comment from alienbob
Posted: April 27, 2018 at 23:45

I noticed in the logs of the Freenode ##slackware channel that people are wondering why I release a package for Falkon without the SlackBuild script.
Those people are wrong.
I always release my packages along with their build scripts.
For the Plasma5 packages in ‘ktown’ I use an evolved version of the kde.SlackBuild script which you can find in Slackware itself. That single SlackBuild script generates all of the KDE packages.

If you want to know more about how that script works, read an older article of mine:

If you can’t read or you’re simply can’t be arsed to take the time to read, but still want to compile falkon, simply run:

# ./kde.SlackBuild applications-extra:falkon

Comment from Robby
Posted: April 30, 2018 at 15:08

Hi Eric,

Somewhere between Mar 21st (the last time I used Kdenlive) and now, I’ve lost the ability to render to mp4 (h264). Prior to the last 2 kde updates, I was building melt and kdenlive myself. I’m updated with slackware-current, and latest kde and multilib.

melt -query “video_codecs” shows:

– h261
– h263
– h263p
– h264_nvenc
– h264_vaapi
– nvenc
– nvenc_h264
– nvenc_hevc

… but no h264 and

ffmpeg -formats shows:

D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp2 MP2 (MPEG audio layer 2)
DE mp3 MP3 (MPEG audio layer 3)
E mp4 MP4 (MPEG-4 Part 14)

and ffmpeg -codecs shows:

DEV.L. mpeg4 MPEG-4 part 2 (decoders: mpeg4 mpeg4_v4l2m2m mpeg4_vdpau mpeg4_cuvid ) (encoders: mpeg4 mpeg4_v4l2m2m )
D.V.L. msmpeg4v1 MPEG-4 part 2 Microsoft variant version 1
DEV.L. msmpeg4v2 MPEG-4 part 2 Microsoft variant version 2
DEV.L. msmpeg4v3 MPEG-4 part 2 Microsoft variant version 3 (decoders: msmpeg4 ) (encoders: msmpeg4 )

I’m not sure if Kdenlive is using melt or ffmpeg for the encoding support … but I’ve rebuilt x264 from SBO, and mlt/kdenlive from your build scripts and problem still occurs: when trying to render to mp4 I get a red x next to mp4 render option. Also Settings -> Config Wizard shows:

“the following codecs were not found on your system: aac, libx264, libx265”

Here are my libs:

ls -al /usr/lib64/libx264*
lrwxrwxrwx 1 root root 14 Apr 30 12:34 /usr/lib64/ ->*
-rwxr-xr-x 1 root root 1011272 Apr 30 12:34 /usr/lib64/*

Sorry for the long message. Any ideas?

Comment from alienbob
Posted: April 30, 2018 at 15:56

Robby – I think that the slackware ffmpeg package lacks support for x264 and x265. It’s supported by my own ffmpeg packages. Could it be that your computer has reverted to the stock ffmpeg packages?

Comment from Robby
Posted: April 30, 2018 at 16:37

Grrrr Argh Whah! Not only possible but actual! I forgot to put ffmpeg in my slapt-get exclusion list. Thanks Eric!

Comment from Eduardo
Posted: May 24, 2018 at 00:28

Hi Eric, I just would like to tell you that today’s -current update updated poppler and thus kile, texstudio and other packages cannot use texlive. Can you rebuild your poppler package if possible? Thanks!

Comment from alienbob
Posted: May 24, 2018 at 07:50

Eduardo, see my repository:

Comment from Darth Vader
Posted: May 24, 2018 at 12:27

Master Eric-wan Kenobi, speaking of Devil, in your latest build is something strange:

Looks like that the SDDM read the config file from “/etc/sddm.conf” WHILE the associated KCM handle “/etc/kde/sddm.conf”, so it has zero effect. 😉

I talk about your fresh build, to be announced.

Comment from alienbob
Posted: May 24, 2018 at 16:46

Darth, that would be strange.
Straight from the commit comes this comment:

SDDM reads files in alphabetical order from /usr/lib/sddm/sddm.conf.d/,
then /etc/sddm.conf.d/ and /etc/sddm.conf. The latest occurence takes precedence.

Comment from alienbob
Posted: May 24, 2018 at 16:50

Hmmm on the other hand, the cmake script for plasma packages defines “KDE_INSTALL_SYSCONFDIR=/etc/kde” so perhaps that overrides that “/etc/” default… investigation is needed.

Comment from Darth Vader
Posted: May 24, 2018 at 20:09

Yes, the SDDM do its job as expected. SO, it really reads the “/etc/sddm.conf”, and I guess that’s what this pull request expects too.

BUT, the Login Manager (for SDDM) page from the System Settings will read and write the config file “/etc/kde/sddm.conf”, which is ignored by SDDM at all.

So, whatever configurations you make on System Settings will not be used by SDDM at all.

Comment from Darth Vader
Posted: May 24, 2018 at 20:17

How I found that?

I have the habit to create a new fresh user in my “playground” computer, when I upgrade your Plasma5.

However this computer is also used by family (and contains nothing important, if we ignore my younger son claims overs his precious cartoons), then I have the habit to use the auto-login to that particular user.

So, I proceeded today as root (if have importance), intending to switch the auto-login to the brand new user.

And followed a WTF moment…

Comment from alienbob
Posted: May 24, 2018 at 21:30

OK I fixed the sddm-kcm package and it will appear in the repository soon.

Comment from Darth Vader
Posted: May 24, 2018 at 22:39

OK, thank you!

Write a comment