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.


My Favourites



November 2015
« Oct    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages


KDE 5_15.10 for Slackware-current brings Telepathy

plasma5_startup It’s october, the leaves are falling, we had our first frost this week… and here is yet another KDE 5 release for Slackware to keep you warm and cozy. I am happy with my KDE 5_15.10 update. Again I waited until every KDE source was refreshed: this set contains Frameworks 5.15.0, Plasma 5.4.2 and Applications 15.08.2.

And you know what? The “progress bar issue” which has plagued me ever since the first Plasma 5.4 release could finally be resolved, thanks to  Gérard Monpontet who posted the solution in the comments section of previous Plasma 5 blog post. I love it when the Slackware community helps fixing issues well before they start bothering Pat. Apparently, desktop sessions not only need to be started using a ConsoleKit process but also using a DBus invocation.


But that’s not all; there is a bit more to tell about the October release.

What’s new in KDE 5_15.10?

  • Frameworks 5.15.0 is an enhancement release with no new Frameworks added. You can read the details on
  • Plasma 5.4.2 is a bugfix release and perhaps the last before 5.5.0, because 5.4.3 will only be released if there’s a need for it. See . New this month is that I enabled the compilation of the “plasma-mediacenter” application, which you may or may not like, but at least you can check it out now.
  • Applications 15.08.2 was just released today. It is a bugfix release – but for Slackware it means the sudden appearance of a lot more packages. Because:
  • I have finally enabled KDE Telepathy in my KDE.SlackBuild framework. That’s 14 new packages for you! Only the voice & video GUI is still missing, the KDE Telepathy developers are looking for someone knowledgeable to port the old KDE 4 version to Frameworks 5.
    And to support building them, I had to add yet another 18 packages in the “deps” section. You will find those dependencies all self-contained in a single “telepathy” subdirectory right below “deps”. That way, if you don’t care much for Telepathy you can easily skip these packages. Similarly, the new KDE Telepathy packages are all located in a subdirectory “telepathy” below “kde”. The full list of new Telepathy dependencies is : libotr, libnice, farstream, libaccounts-glib, libaccounts-qt5, signon, signon-plugin-oauth2, signon-ui, libsignon-glib, telepathy-glib, telepathy-farstream, telepathy-haze, telepathy-gabble, telepathy-qt5, telepathy-logger, telepathy-logger-qt5, telepathy-mission-control and telepathy-accounts-signon.
  • I added a new package to “plasma-extra” because I did not want to wait for Plasma 5.5 where this program will likely be included by default. It is called “xembed-sni-proxy” and on startup (automatically when you launch a Plasma 5 desktop session) it will dock into the Plasma system tray area and start listening for XEmbed requests. Tray icons for applications adhering to the “legacy” XEmbed protocol will be displayed seamlessly inside the Plasma tray area, courtesy of xembed-sni-proxy). There is no longer a need for external tray applications like trayer-srg or stalonetray.

Here is a screenshot which shows the (XEmbed) HP system tray icon – snugly placed inside the xembed-sni-proxy tray area. You’ll also notice the reddish avatar at the left – that is KDE Telepathy, its color informing me that it is does not have any account configured yet.


Installing or upgrading Frameworks 5, Plasma 5 and Applications

The remainder of the article is mostly a re-hash, but I include it every time so that you do not have to search through this blog, and have everything together on a single page.

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”, “kdepim”, “plasma”, “plasma-extra”, “applications” and “telepathy”.

Upgrading to this KDE 5 is not difficult, especially if you already are running KDE 5_15.09_02. You will have to remove old KDE 4 packages manually. If you do not have KDE 4 installed at all, you will have to install some of Slackware’s own KDE 4 packages manually.


If you are using slackpkg+, have already moved to KDE 5_15.09_02 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 with the name “ktown_testing” in the configuration file “/etc/slackpkg/slackpkgplus.conf“):
# 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)

And doublecheck that you have not inadvertently blacklisted my packages in “/etc/slackpkg/blacklist“! Check for the existence of a line in that blacklist file that looks like “[0-9]+alien” and remove it if you find it!

Recommended reading material

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

A note on Frameworks

The KDE Frameworks are extensions on top of Qt 5.x and their usability is not limited to the KDE Software Collection. There are other projects which rely (in part) on the KDE Frameworks, and if you are looking for a proper Frameworks repository which is compatible with Slackware package managers such as slackpkg+, then you can use these URL’s to assure yourself of the latest Frameworks packages for Slackware-current (indeed, this is a sub-tree of my KDE 5 “testing” repository):

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

Wine 1.7.52 with additional patch set

I uploaded a new set of Wine packages. I know that Wine HQ itself is offering Wine packages for Slackware (see this link) but being the control freak that I am, I want to know exactly what I am using. I am using my own build script.

My Wine package needs some explanation. As you know, Wine traditionally was meant to run Windows software – 32bit Windows software. Therefore it will run fine on 32bit Slackware but if your computer is equipped with 64bit Slackware, you need to enhance it with multilib capabilities to make this 32bit software work on a 64bit OS.

Microsoft caved in at some point and started offering 64bit versions of their Windows OS. The 64bit MS Windows can run 32bit software out of the box… a wise move since a lot of Windows software is still 32bit binary code. They made this work transparently by adding something akin to our multilib. Microsoft calls it WoW64 or “Windows on Windows 64″.

The Wine package I provide for the 64bit Slackware therefore mimicks this WoW64 configuration and offers both a 32bit “wine” and a 64bit “wine64″ environment. You still need multilib to make this work on Slackware64 but you will be able to run 64bit Windows binaries just as easily as 32bit Windows programs.

Now, recent versions of my package have been enhanced again. You may recall that I offer a “pipelight” package which allows you to use MS Windows browser plugins with your Slackware Firefox. Pipelight uses a patched version of Wine. This patch set was orginally called “Wine Compholio” but as more and more people saw how useful these patches were for regular Wine users, an effort was made to formalize these patches and make them more widely known – and used. Nowadays, this patch set is known as “wine-staging” and on 25 September the team announced their integration into WineHQ, making wine-staging a structural part of the Wine development process. I have decided to apply the wine-staging patch set to my Wine package by default since the 1.7.51 release. Fedora does this too for their package.

And with my 1.7.52 package I have added a second patch set which should bring near-native performance to Direct 3D 9 applications in Wine. This patch set is called “direct3d9” and leverages the new “d3dadapter” of the mesa package (provided by the Gallium Nine state tracker of Mesa). The d3dadapter library has been enabled in the mesa package of Slackware-current. My wine.SlackBuild script checks for this library and applies the direct3d9 patch set if that library is found. The wine-1.7.52 packages for Slackware 14.1 and -current are therefore different.

I noticed that there is some overlap between the wine-staging the direct3d9 patch sets. After applying wine-staging there are some chunks of the direct3d9 patches that fail to apply. I do not know if this will have any adverse effects when running Windows applications. I checked with other distros and found that Arch Linux is also applying both patch sets in their “wine-staging-d3dadapter” and don’t seem to be bothered by failing patch-chunks. If you are on Slackware-current and want to (re-)compile Wine without the direct3d9 patch set, you can simply run the SlackBuild script like so:

USE_NINE=NO ./wine.SlackBuild

I would like to hear from you if these patch sets are making a difference in running your Windows games and other programs.

Cheers, Eric


Handbrake 0.10.2 (but only for slackware-current)

handbrake_logo Nearly a year after my rant about Handbrake’s switch from GTK+2 to a bleeding edge version of GTK+3, I am about to give up on my attempts to build the required GTK+3 static libraries into the handbrake package. Unlike the situation with applications that use Qt or WxWidgets for their GUI, creating a private run-time for GTK is like wading through the pools of hell. GTK wants caches, configuration files and stuff all over the place. My handbrake with private GTK+3 crashes because it might still be trying to use the older GTK+3 libraries on my Slackware 14.1 computer.

So I said to myself: “fuck it” and build Handbrake 0.10.2 for Slackware-current exclusively. The development version of Slackware does have a GTK+3 which is contemporary enough and with some tweaks, I was able to compile a (hopefully) working handbrake GUI.


It is of course possible to compile the commandline version of Handbrake on Slackware 14.1 because that does not require GTK+3 as a dependency. Come to think of it, perhaps I should adapt the handbrake.SlackBuild with a switch parameter that will allow you to skip the “ghb” GUI program and only compile “HandBrakeCLI“.

I wonder if anyone will step up and write a Qt-based wrapper about the HandBrakeCLI program. That would be really welcome, because I do not think that the Handbrake developers will ever produce a Qt based GUI variant. They attempted that once if I remember correctly, but nothing good came from that.

When I have some spare time I will prod further at getting Handbrake to use a private GTK+3 run-time, but don’t hold your breath. I have a program that compiled with zero errors, but it crashes on the GTK component libraries. I am not sure if I ever find out how to overcome that… I am not aware of anyone else ever successfully creating a GTK+3 based GUI program on Linux that used its own private library versions.

Anyway, have fun with handbrake if you are running Slackware-current.

You can get the package from my “restricted” repository. The package contains software which is under patent dispute (the MP3 and AAC audio encoders) so I can not host the package on the Slackware server.


Update for VeraCrypt, new flaws in TrueCrypt

veraCrypt Recently TrueCrypt has been in the news again, because of a couple of new critical security issues that were found for its Windows version. You can read more in these articles at Engadget, Threatpost and  Extremetech. Windows computers with TrueCrypt installed can be taken over completely by a non-privileged user, and the computer does not even have to have mounted any TrueCrypt container.

These recently uncovered flaws were not found in last year’s code audit of TrueCrypt sources. Apparently this omission is due to the complexity of Windows drivers and “the kind of vulnerabilities that exist in many software on Windows and they are caused by lack of proper parameter validation in kernel mode code” according to Mounir Idrassi (VeraCrypt developer) in Threatpost.

Despite the fact that these new vulnerabilities are not affecting Linux, it is highly unwise to keep using TrueCrypt on Linux. The code is no longer maintained, it already has security issues and good alternatives exist.

The aforementioned VeraCrypt is a fork of the TrueCrypt code which is actively maintained, and the recent flaws found (to be disclosed next week) in TrueCrypt have already been patched in VeraCrypt 1.15 last weekend.

VeraCrypt is a drop-in replacement for TrueCrypt if you let it handle your encrypted container in “truecrypt mode”:

veracryptI have built new packages for VeraCrypt 1.15, updating it from the previous 1.13 which I had in my repository. You can get the packages (for Slackware versions 13.37 and newer) here: or at its primary mirror location

Users of slackpkg+ merely have to run “slackpkg update && slackpkg upgrade veracrypt“, assuming that the repository mirror you are using is up to date.

Cheers! Eric


Update for Chromium 45

chromium_iconGoogle updated their Chrome/Chromium with mention of some security fixes. I had to finish compiling LibreOffice first, and also it takes a while for the official chromium source tarball to appear on Google’s servers. But the weekend started uneventful so it was easy to build you some new packages for the chromium browser inbetween baking some tasty sourdough bread. Accompanied by packages for the widevine plugin (a closed-source non-free plugin which allows you to watch Netflix in particular).

The security fixes in chromium 45.0.2454.101 have CVE numbers:

  • [$TBD][530301] High CVE-2015-1303: Cross-origin bypass in DOM. Credit to Mariusz Mlynski.
  • [$TBD][531891] High CVE-2015-1304: Cross-origin bypass in V8. Credit to Mariusz Mlynski.

Get my chromium (and widevine plugin) packages in one of the usual locations:

Have fun! Eric