Category Archives: Science

Fun and games in -current when ABIs break

Oh my.
It was not an April Fools joke when the ChangeLog.txt of slackware-current mentioned the following (I left out the non-relevant package updates):


Sun Apr 1 02:53:26 UTC 2018
l/icu4c-61.1-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.
l/poppler-0.63.0-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.

All of us  who follow Slackware’s development know that “shared library version bump” means ABI breakage. I.e. a lot of 3rd-party binaries will suddenly not find required library versions anymore. In particular icu4c and poppler are nasty beasts. Slackware’s own packages had been carefully updated and recompiled where needed of course, so there was no breakage in the distro itself. But many people do not run a bare Slackware installation… a lot of software is usually installed on top. And that is the software which will be affected by an incompatible change like this one on April 1st.

What’s this  version bump all about? How is it possible that it affects your computer so deeply?

Most programs depend on other programs. Software developers hate to re-invent the wheel if they can avoid it. Lots of lower-level or widely used functionality has been put into software libraries. Think of network access functionality, text rendering, encryption etc – smart people have created useful, efficient and robust software and stuffed that code into libraries. Your own program can link against these libraries at run-time and access the functionality they have to offer and your program needs.
If many programs link to the same libraries, that reduces the memory footprint because a library has to be loaded into memory only once even if many programs are using it. These libraries are therefore called ‘shared libraries‘ or ‘shared objects‘ (hence the extension ‘.so‘) or also dynamic libraries. For this dynamic linking to work, programs use binary interfaces at runtime that were established when the program was compiled and linked.
A shared library version only needs to change if the Application Binary Interface (ABI) changes. When that happens, all binaries that depend on the library need to be recompiled to adjust to the new ABI.
Among others, an ABI depends on the machine architecture, and on the toolchain (compiler, linker) used to generate the binary code from its sources. An ABI guarantees binary compatibility: the program will work on every machine with the same ABI, without a need for recompilation.

When will an ABI usually change?

One case is when the library’s API (Application Programming Interface, i.e. the way in which access to the library routines is defined in its source code) changes. This mostly occurs in software that is not yet stable and where its programmers add new functionality or revise the methods of calling the library’s functionality. Mature software on the other hand has a well-defined API which is rarely subject to change.

Another case is when the toolchain is updated. Slackware’s toolchain has been very stable and ABI changes have seldomly been introduced. As an example, Patrick talks about the a.out to ELF migration and the libc5 to glibc migration in a 2012 interview.

So why does well-established software like icu4c and poppler change their ABI almost on every minor release, thereby pissing off a really large crowd? You tell me. Arrogance or sloppiness, but let’s attribute it to bad project management. Because it probably could have been avoided in many if not all cases.

Anyway, some of you upgraded first to this new batch of updates in -current, then found out that some 3rd party packages stopped working, and then started looking for a cause.
Folks: if you are running slackware-current, you always check the ChangeLog.txt first. And if you spot a “shared library version bump” you stop right there and assess the situation. Some friends on LinuxQuestions were a bit more vocal about the way they had found themselves at a dead Plasma5 screen… others understood the situation better and and realized they had to wait for 3rd party packagers to update their repositories instead of assuming ill will.
If you are unable to cope with this kind of occasional breakage, use a stable Slackware release. That’s what all of us have been telling you all along.

My packages have been affected as well:

  • Plasma 5 stopped working,
    The fix is to recompile several packages among which a number of big ones: qt5, qt5-webkit and calligra. That means, you will have to have patience. The 64bit repository has been updated in the meantime. After upgrading from my ‘ktown’ repository your Plasma5 will again be fully functional. The 32bit repository updates will hopefully follow tomorrow have been uploaded now. I had to restart the 32bit qt5 compilation because of an internal compiler error halfway.
    The updated Plasma5 will even have some new functionality – since i slipped in the KMymoney program which otherwise would have been introduced at the April update of ‘ktown‘.
  • LibreOffice stopped working.
    The 64bit packages have been recompiled. They have been updated actually since there was a micro source version bump from to yesterday – my luck! The 32bit packages have to wait until after ‘ktown‘ updates have been completed and then I will upload them. New libreoffice packages for -current are now available.
  • Pale Moon stopped working.
    I was able to recompile the packages inbetween the Plasma5 compilation because it only takes little time. The updated palemoon packages are already in my repository.
  • Calibre stopped working.
    This will have to wait until after all the other updates New calibre packages for -current are now available..

And probably other stuff is broken too but I have not yet spotted that. If you find breakage, please report it so that I can recompile the package.

Plasma5 Wayland works on Slackware

Last year August 2016 I experimented with Wayland, the alternative to the X Window system. My goal was to see if it is possible to run a Plasma5 desktop session on a Wayland compositor instead of using X.Org.
There was one big showstopper at the time. Kwin_wayland has a dependency on the ‘logind’ DBus API and at that time last year, this API was only provided by systemd-logind. Luckily, someone treated the logind component of systemd similarly to its udev component. Where Slackware already uses “eudev” which is a standalone udev source extracted from the systemd source, there’s also “elogind” which is the standalone logind sourcecode, extracted from systemd sourcecode. With some difficulty I managed to create a Slackware package for elogind and everything compiled. I just could not get a working Wayland session.
As it turns out today, that failure to get Wayland working was an omission on my side… more on that later.

Shortly after, IBM told me I would lose my job, I found another job at ASML and life was hectic and remained so. I never got another opportunity to research the root cause of my Wayland failure.
Now that I have a week off, I decided to revisit the old Wayland disaster. After last year’s frustration over the need for elogind, I talked to the ConsoleKit2 developer and to the KWin developer, to see if CK2 could be extended with the required logind DBus API (parts of that API were already incorporated) and to get CK2 accepted as an alternative to systemd-logind on systems that don’t ship with systemd. Both wishes were fulfilled this summer, so I could drop elogind from my package set. I still needed to recompile / upgrade some other packages to add wayland support to them, but the fact is: Slackware does not need PAM or systemd to get Wayland working.

Therefore, my KDE 5_17.10_testing repository contains mostly what you already know and love: KDE Frameworks 5.39.0, Plasma 5.11.0 and Applications 17.08.2. All based on Qt 5.9.2. Just with 17 differences in the package list.

Why does Wayland work now, while it did not last year?
Well, that was entirely my perception of things. Probably would have worked last year as well, if only I had recognized the signs. Last year, and yesterday as well, all the puzzle pieces seemed to be OK, but their integration failed. The signs (using strace and gdb to find out why the Wayland session would not start) were telling me that KWin was trying to find a logind provider on the DBus and no-one was answering. It took a sudden insight this morning, the realization that there is one difference between Slackware and all those other distros. And I have been using a workaround for ages, and I just did not think about that.
It’s PAM.
When you login on a system running PAM, a login session is registered on the bus using either ConsoleKit2 or systemd-logind. Our PAM-free Slackware needs an additional “ck-launch-session” command in front of the “dbus-launch” command to connect a new ConsoleKit2 session to the bus and let KWin find it there… when I fixed that, my Wayland session just sprang into existence!

How to start a Plasma5 Wayland session

  • Runlevel 3 (console): run the ‘startkwayland‘ command as your regular user.
  • Runlevel 4 (SDDM): select “Plasma (Wayland)” from the session dropdown and then proceed to login.


Of course… nothing works 100% the first time. So what have I ran into? Note that I have been running Wayland for a couple of hours only, so I can say little about its stability.

  • Dropbox does not start, unless you ‘unset’ the QT_QPA_PLATFORM variable first. This is caused by the fact that Dropbox uses its own internal Qt5 libraries and it does not come with Wayland support.
  • Gnome-keyring does not start for some reason, so you can not auto-login to skypeforlinux for instance
  • HP-tray was eating 100% CPU at some point and draining my battery. I had to kill the process.
  • Yakuake does not work (I know, it is not part of my ‘ktown’ package set)
  • Unlike an X.Org session, the Wayland session does not require an additional <Ctrl> keypress to switch to a virtual console. Therefore, when I wanted to invoke krunner with <Alt><F2>, instead I was switched to the second virtual console, tty2. Upon returning to the Wayland session (which was running on VT4 as opposed to VT7 for X.Org) the krunner window was waiting for me. Apparently both the OS and KWin process the <Alt><FunctionKey> combos.

A note about NVIDIA: I know that there are issues between the binary driver and Wayland. Please do your research if you use the binary Nvidia blob. My laptop has an Intel GPU which runs on the open source kernel driver, and has no issues.

Note: check out the KDE page which documents the Wayland issues:

What’s needed to make Plasma5 work with Wayland in Slackware

We need Wayland support in the core of the OS as well as in the dependencies for Plasma5. Also we need a version of ConsoleKit2 that works with Kwin_wayland. Which means:

  • add a wayland-protocols package (wayland is no longer sufficient)
  • add an upgraded ConsoleKit2
  • recompile Slackware’s mesa using a slightly modified SlackBuild script (change the package tag from ‘alien’ to ‘wayland’)
  • write a xorg-server.SlackBuild script based on the code in the x11.SlackBuild framework of Slackware, and recompile xorg-server with that script (change the package tag from ‘alien’ to ‘wayland’)​
  • recompile libxkbcommon (change the package tag from ‘alien’ to ‘wayland’)
  • recompile qt5 (change the package tag from ‘alien’ to ‘wayland’)​

With the ‘deps’ taken care of, proceed to Frameworks:

  • recompile kwayland and plasma-framework (change the package tag from ‘alien’ to ‘wayland’)

And finally the Plasma packages that use Wayland in some way or other:

  • recompile kinfocenter, kscreenlockerkwayland-integrationlibkscreen2, plasma-desktopplasma-integration, plasma-workspacepowerdevil and kwin (change the package tag from ‘alien’ to ‘wayland’)

You will have noticed that the packages I tagged with ‘wayland‘ instead of the usual ‘alien‘ tag, are the ones that picked up Wayland support as compared with their originals. This makes it quite easy for you to switch back to the original packages (mesa and xorg-server in Slackware and the other 13 in ‘ktown’) if you are done with your testing. The remaining ‘alien’ packages (wayland-protocols and ConsoleKit2) can be kept without penalty.

A final note about this updated xorg-server package. My version of that package is a 4-into-1 package; it contains xorg-server-xephyr, xorg-server-xnest and xorg-server-xvfb as well. If you decide to remove the testing packages and want to go back to Slackware’s non-wayland version of xorg-server, you must also re-install the other three xorg-server-x* packages.

Installing or upgrading Frameworks, Plasma and Applications

Please use the README file in the ‘latest’ repository for the installation & upgrade instructions. I reserved the README.testing in the ‘testing’ repository to highlight the differences between the two repositories.

Where to get these ‘testing’ packages for Plasma Wayland

Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/testing/ subdirectory). Only “bear” has the packages for now, the mirrors should follow within 24 hours. If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too. There is now only one source tree to create both ‘latest‘ and ‘testing‘ repositories.


There will probably not be a Plasma5 Live ISO image based on the ‘testing’ repository with working Wayland support. My ‘bear’ server just does not have the disk space to host an additional 4 GB ISO file. Nevertheless, you can tranfer the existing Plasma5 Live ISO to USB stick, change the ‘latest‘ ktown repository to ‘testing‘ in the slackpkg+ configuration file “/etc/slackpkg/slackpkgplus.conf” and run “slackpkg update ; slackpkg install ktown ; slackpkg upgrade ktown” to get the 4 new packages and upgrade the 13 other packages. If you do not use slackpkg with slackpkg+ then simply look at the short list of packages to be installed or upgraded, higher up on this page.

Have fun! Eric

July 17 updates – Plasma 5, Live ISOS and more

Slackware turned 24 today, 17 July.

To celebrate I have created some goodies for you. Nothing you can eat or drink…

First, Plasma 5 updates.

I have uploaded the July ’17 set of Plasma 5 packages for Slackware 14.2 and -current to the ‘ktown’ repository. KDE 5_17.07 contains: KDE Frameworks 5.36.0, Plasma 5.10.3 and Applications 17.04.3. All based on Qt 5.9.0 for Slackware-current and Qt 5.7.1 for Slackware 14.2.
NOTE: I will no longer be releasing Plasma 5 packages for 32bit Slackware 14.2.

What’s new this time

Apart from the usual upgrades to the Frameworks, Plasma and Applications subsets, there is only one interesting piece of news: I added ‘kile’ to the applications-extra directory. Kile is a LaTex editor and the port to the KDE Frameworks 5 is well underway. I based the package on a git snapshot of its repository. One more KF5 application in “applications-extra”.
The goal of the KDE community is that the Applications 17.12 release (i.e. end of this year) will not have any application that is still kdelibs4 based. Everything in Plasma 5 Desktop should then finally be based on KF5.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

As always, the accompanying README file contains full installation & upgrade instructions.

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas. If you want to read them, here they are:

Where to get the new packages for Plasma 5

Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ and  /14.2/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.


A Plasma5 Live ISO image will follow shortly on in case you want to try it out first (check the timestamp of the ISO on the web page). I am currently testing it, looks fine. Here is a screenshot showing the QtAv player (a proper QT5 and QML based video player so that you can forget about kplayer or gmplayer):

What else is in stock

The PLASMA5 Live ISO is crammed with all my relevant big packages (libreoffice, vlc and friends) and I refreshed a few of these packages:

  1. A package is available for the latest MKVToolnix 13.0.0 – Slackware 14.2 and -current.
  2.  I built the latest Calibre 3.4.0 for Slackware 14.2 and -current, adding several internal modules which I omitted in my first Calibre 3 release. As a consequence, Calibre now also depends on unrar for which I also compiled the latest release (5.5.6) into a Slackware package.
  3. Podofo is another dependency for Calibre that received a long overdue update, and my repository now contains version 0.9.5.

And I am also preparing Live ISO images for the variants SLACKWARE (64bit and 32bit), XFCE (64bit and 32bit) and MATE. They should go online at the same time as the PLASMA5 ISO.

Have fun! Eric

Palemoon browser

The Pale Moon browser was forked off the Mozilla Firefox codebase a couple of years ago, before Firefox switched to the Australis User Interface. Since then, the project has steadily been diverging from the Firefox codebase, optimizing its Gecko layout engine and rebranding that to ‘Goanna’ (which is the name of just another lizard). The community has a large vote in the direction the Pale Moon browser’s features are taking.

People are drawn to Pale Moon because it promises to be a browser that is leaner than the modern-day Firefox. Pale Moon has the look and feel of Firefox like it was years ago, which has a certain appeal. Firefox and Chrome are both plagued by code bloat. The Australis UI ruined Firefox for many people. Also, Pale Moon supports the old Mozilla Sync (Weave 1.x). You can easily setup your own private sync server at home.
Yet, Pale Moon promises to give you a contemporary user experience regardless.

On (SBo) you will find two different scripts to create a Pale Moon package. One, called palemoon, will wrap the official binaries into a Slackware package. The other, called PaleMoon, is a build-from-source which attempts to stay close and true to the Pale Moon project’s official recommendations about the use of compilers (GCC 4.x but not newer) and optimizations (compiler flags are “-O2 -msse2 -mfpmath=sse”). The Pale Moon developers have decided that these conditions are necessary to compile their sources into a stable browser (i.e. one that is not prone to crashing all the time on sites that are heavy on media or JavaScript).

The lead developer of Pale Moon is also very strict about the use of his official branding by 3rd party source builds that are re-distributed as unofficial binaries. Builds that do not conform to these policies, must use unofficial branding (a monochrome logo, and the name “New Moon”). The scripts on do not re-distribute binaries so they are not affected by these policies.

I decided that I was curious enough to write a SlackBuild of my own, and see what I thought of Pale Moon. I took inspiration from Slackware’s mozilla-firefox.SlackBuild and then did two things crucially different from the official recommendations. I used the default gcc compiler of the Slackware release I built the package on (Slackware 14.2 has gcc-5.3.0 and -current had 5.4.0 at the time when I ran the compilation… of course, now -current has gcc-7.1.0). And the optimization I chose is “-Os”; a conservative optimization with a focus on smaller code size, instead of better speed.

The resulting package seems to be stable, and it is not crashing on web sites where other 3rd party builds seem to falter. See this LQ thread for more details about problematic web sites which my binary shows without issue. Also – judging from the forum posts – it appears that many crashes are triggered when running Pale Moon in KDE4 with the oxygen theme selected for your GTK+2 programs. I fixed that instability by applying a patch to oxygen-gtk2 that can be found in its code repository but was never included in an official release. That patched oxygen-gtk2- package is available in my SlackBuild repository, and is also included in my ‘ktown‘ repository for the Plasma 5 desktop environment. I urge you to upgrade your Slackware package to this version.

Moonchild, the lead developer, gave his approval to use official branding in a series of private conversations we had, but being a Windows person he wants his Linux developer to check my package out. I told him that I will have a Pale Moon package in my repository, or none at all – I will not use unofficial “New Moon” branding. My package should give you a stable browsing experience – if not, let me know and do not bother the Pale Moon developers. So, if you see the palemoon package disappear from my repository, you’ll know that I have fallen out with the project and am not agreeing to their requests.
So far so good of course – this is Slackware, and we offer a nice & stable OS to run this browser on. I hope that some of you will find your new favorite browser in Pale Moon.

KDE 5_15.04 for Slackware-current: back to work

qt-kde-620x350An update to my KDE 5 packages was overdue. Ever since the “big upgrade” in Slackware-current a week ago on 21 April 2015, there have been some stability issues in the Plasma 5 desktop. The instability was caused by the version bumps of various libraries that the KDE software is depending on – you can not dynamically link to a software library that’s no longer there because it has been replaced with a library bearing a new version number. I felt I had to recompile everything just to be sure there was no hidden “breakage” left, and so I took the opportunity to wait for the newest Plasna release and present you wilth all-new packages.

My April release of KDE 5_15.04 consists of Frameworks 5.9.0, Plasma 5.3.0 and Applications 15.04.0 plus the latest updates of the KDE 4 Long Term Support (LTS) packages kdelibs, kdepimlibs, kdepim, kdepim-runtime and kde-workplace. Also there’s been a bit of a shake-up in the “deps” directory containing the direct dependencies for this release.

About Plasma 5

Slackware-current will stick with KDE 4.14.3 plus the latest LTS updates. KDE 5, or Plasma 5 as many people like to call it, is not yet fit for the average user. It is fairly stable, has some nice new concepts but if you are not the curious or tinkering kind, you will be better off with Slackware’s KDE 4.14.3.

If you are curious and like to tinker, and don’t care if some functionality is temporarily missing from Plasma 5 that you were used to in KDE 4, then my Plasma 5 packages will be a nice and interesting update for your Slackware-current computer (32-bit or 64-bit). The KDE 5 matures with every release of its components. In particular, the new Plasma 5.3.0 is a “new features” release working its way towards full Wayland support (no, we do not use that yet, and X.Org is also fully supported). And the April ’15 release of the KDE Applications brings the number of applications that have been ported to KF5 (KDE Frameworks 5) to a grand total of 72.

New to the Applications starting with 15.04 is KDE Telepathy (an Instant Messaging & Voice Over IP client on top of the telepathy communications framework) and Kdenlive, the non-linear video editor. BOth are filling a void in the KDE desktop that has existed for many years. I have to tell you that I have not yet built packages for them, but I will look at them for a future iteration. It would only have delayed the release of my packages at this moment.

Remember, there is no choosing between KDE 4 and Plasma 5 – KDE 4 will be mostly replaced (I say “mostly” because there are still a lot of KDE 4 applications in this release).

What’s new in KDE 5_15.04?

The highlights of this 5_15.04 March release are:

  • KDE Frameworks have been updated to 5.9.0 (includes a new Framework: ModemManagerQt which is the former libmm-qt5 which has been promoted from Plasma to Frameworks and renamed)
  • KDE Plasma has been updated to 5.3.0 (new features release)
  • KDE Applications have been updated to 15.04.0 (increasing the number of KF5 ports to 72)
  • KDE Extragear has been emptied: all the extragear packages are now available in slackware-current itself. Report any breakage that you encounter!!
  • The “deps” directory for this release contains updates to stock Slackware packages: PyQt, eigen2, phonon, phonon-gstreamer, sip, xapian-core, and there’s three new “deps” packages as well since my previous release: PyQt5, cfitsio and grantlee-qt5. You’ll notice that several other “deps” packages have been upgraded or at least rebuilt.
  • Gone from the “deps” because they are now part of Slackware-current:  LibRaw, akonadi, attica, cmake, eigen3, exiv2, grantlee, harfbuzz, libfakekey, libodfgen, librevenge, libssh, libwpd, orc, poppler, qt, shared-desktop-ontologies, soprano, strigi.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

The recent mass-update in Slackware-current will make this upgrade to KDE 5_15.04 particularly difficult. Remember: “don’t drink and drive“!

As always, the accompanying README file contains full installation & upgrade instructions. Note that the packages are available in several subdirectories below “kde”, instead of directly in “kde”. This makes it easier for me to do partial updates of packages. The subdirectories are “kde4”, “kde4-extragear”, “frameworks” “plasma”, “plasma-extra” and “applications”.

Upgrading to this KDE 5 is non-trivial. You will have to remove old KDE packages manually. If you do not have KDE installed at all, you will have to install some of Slackware’s own KDE 4 packages manually. I can not guarantee that there will be no deal-breakers for you (missing functionality or persistent crashes).


If you are using slackpkg+, have already moved to KDE 5_15.01 or newer and are adventurous, you can try upgrading using the following set of commands. This should work but feel free to send me improved instructions if needed (assuming in this example that you tagged my KDE 5 repository “ktown_testing”):
# slackpkg update
# slackpkg install ktown_testing (to get the newly added packages from my repo)
# slackpkg install-new (to get the new official Slackware packages that were part of my deps previously)
# slackpkg upgrade ktown_testing (upgrade all existing packages to their latest versions)
# slackpkg upgrade-all (upgrade the remaining dependencies that were part of my repo previously)
# removepkg sddm-theme-breeze (gone after KDE 5_15.01)
# removepkg libmm-qt5 (gone after KDE 5_15.03)

My observations after upgrading

There were a couple of things I had to go through to get the Plasma 5 desktop into an OK state:

  • At first start, the screen remained black even though I could see the “wmsystemtray” was visible and the mouse pointer was definitely a KDE pointer. I killed the X server (Ctrl-Alt-BackSpace) and started again. This time the desktop came up as anticipated.
  • I had added Konsole  to the Favourites menu earlier. Both Konsole and Systemsettings icons in the Favourites were non-functional and missing their icons. I had to remove and re-add them.
  • KDEConnect was added to my system tray earlier. After the upgrade to KDE 5_15.04 I could see an empty square where I assume KDEConnect wanted to dock – but it did not respond to clicking. I had to right-click on the system tray and disable KDEConnect from being shown, click Apply, and then make the KDEConnect widget show again.
  • The default desktop background and the start/lock screen are quite a bit flashier. I like the changes in the theming.
  • Still no suspend/hibernate buttons. And the shutdown/reboot options will only appear if you edit the “/usr/bin/startkde” script – removing the call to “kwrapper” as explained here.

Where to get the new packages for Plasma 5

Download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.

Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric