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



January 2015
« Dec    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages


Waiting for KDE 5 (Plasma 5)?

The KDE community released the source code to Plasma 5.2.0 today, and some of you are dying to see what it looks like.


You just need to wait a little longer.
I have built all the packages, and I am doing a final quality check. Then I’ll have to write a proper README generate the repository files (time-consuming).

One note in advance:

The Plasma 5.2.0 desktop packages (completed with Frameworks 5.6.0 and Applications 14.12.1 accompanied by some of the “old” KDE 4.14.x libraries) are built to replace your current KDE 4.x desktop! My KDE 5 preview, posted in August 2014, was meant to be co-installed with an existing KDE 4 desktop and was built so that its configuration files would be written to different directories than your existing KDE 4 configuration. This allowed the curious among you to have a sneak peak of KDE 5 with the option of completely removing it again afterwards, with no pain. The new KDE 5 release I will be presenting tomorrow, means that you have to choose: do you want to stick with KDE 4 or migrate to KDE 5 (Plasma 5.2.0)?

If you are not willing to swap a stable KDE 4 desktop environment for an adventure with KDE 5 (stable enough, with exciting new features, but may have bugs or missing features that are deal-breakers for you), it may be better to wait a bit and let the early adopters tell their story of the upgrade before you decide to join them.

If you are using slackpkg+ to manage your 3rd party packages and have added my “testing” repository or , then please double-check your /etc/slackpkg/slackpkgplus.conf file and make sure that you remove one of the following:

  1. (or
  2. (or

Having the first in your slackpkg+ configuration means that your KDE 4.14.3 will be migrated to Plasma 5.2.0. Keeping the  second repository will ensure that you keep KDE 4.14.3 installed.

If you want to know when KDE 5 will be added to the Slackware core distro… my guess is that that will at least take another year. The stable Slackware release which we are working towards, will likely see its ageing KDE be refreshed with the latest KDE 4.14.3 enhanced with the LTS (Long Term Support) versions of kdelibs, kdepim* and kde-workspace, but not with KDE 5.

Also, remember that this release of KDE 5 is meant to be run on slackware-current. If you are running Slackware 14.1 or even one of the older stable releases, then KDE 5 is something you will only be reading about. By the way, I still have KDE 4.13.3 for Slackware 14.1 of course, if you think Slackware’s own KDE 4.10.5 is getting stale.

The git history of my development process towards a “stable enough for daily work” Plasma 5 desktop is here:

I hope to have packages no later than tomorrow, and proper instructions in a blog article no later than thursday.


Java update: openjdk 7u75 available

icedtea A new release of IcedTea  is available. Version 2.5.4 of the “Java build framework” will create OpenJDK 7 “Update 75 Build 13” (resulting in a Slackware package openjdk-7u75_b13).

The release announcement can be found on the distro-pkg-dev mailing list. It has a long long list of improvements and bugfixes – probably caused by the large hiatus between this and the previous release.

A list of  CVE’s is associated with the new release. Here is the skinny – all security fixes mentioned in the post:

  - S8046656: Update protocol support
  - S8047125, CVE-2015-0395: (ref) More phantom object references
  - S8047130: Fewer escapes from escape analysis
  - S8048035, CVE-2015-0400: Ensure proper proxy protocols
  - S8049253: Better GC validation
  - S8050807, CVE-2015-0383: Better performing performance data handling
  - S8054367, CVE-2015-0412: More references for endpoints
  - S8055304, CVE-2015-0407: More boxing for DirectoryComboBoxModel
  - S8055309, CVE-2015-0408: RMI needs better transportation considerations
  - S8055479: TLAB stability
  - S8055489, CVE-2014-6585: Better substitution formats
  - S8056264, CVE-2014-6587: Multicast support improvements
  - S8056276, CVE-2014-6591: Fontmanager feature improvements
  - S8057555, CVE-2014-6593: Less cryptic cipher suite management
  - S8058982, CVE-2014-6601: Better verification of an exceptional invokespecial
  - S8059485, CVE-2015-0410: Resolve parsing ambiguity
  - S8061210, CVE-2014-3566: Issues in TLS


The new Java is properly detected by Oracle’s Java version tester at :


Note about usage:

Remember that I release packages for the JRE (runtime) and the JDK (development kit) simultaneously, but you only need to install one of the two. The JRE is sufficient if you only want to run Java programs (including Java web plugins). Only in case where you’d want to develop Java programs and need a Java compiler, you are in need of the JDK package. Get them here.

The Java package (openjre as well as openjdk) has one dependency: rhino provides JavaScript support for OpenJDK.

Optionally: If you want to use Java in a web browser (which supports NPAPI plugins – this excludes Chrome & Chromium but you’ll be OK with all Mozilla [-compatible] browsers) then you’ll have to install my icedtea-web package too. While Oracle’s JDK contains a browser plugin, that one is closed-source and therefore Icedtea offers an open source variant which does a decent job.

If you want to compile this OpenJDK package yourself, you need to install apache-ant additionally. Note that the previous requirements of xalan & xerces packages have been dropped; ant will provide all required build functionality on its own now.

Have fun! Eric

Updates for chromium, widevine, flash

Chromium and Widevine:

chromium_iconChrome  Stable Channel saw version 40 of the browser being released yesterday (to be precise, version 40.0.2214.91). Apart from this being a major upgrade (39 to 40), lots of bugs were fixed, many of those being security fixes (62 in total). See the blog page for all details.I have not looked at the new version extensively but Chrome/Chromium 40 comes with an improved bookmarks manager which lets you search your bookmarks, not only by URL or title, but also by page content.

The new Chrome contains a new Flash Player too, more about that further down on this page.

And a new Chrome browser means, the Chromium source code for the same version is being made available. I built new packages for my chromium and chromium-widevine-plugin packages, both have version 40.0.2214.91.

Note that the Widevine plugin reports itself as version “” in chrome://plugins – I decided to use the matching chromium version and not the actual widevine version when creating the plugin package. For newcomers: Widevine is a Content Decryption Module (CDM) used by Netflix to stream video to your computer in a Chromium browser window. With my chromium and chromium-widevine-plugin packages you no longer need Chrome, or Firefox with Pipelight, to watch Netflix.

Also note (to the purists among you): even though support for Widevine CDM plugin has been built into my chromium package, that package is still built from Open Source software only. As long as you do not install the chromium-widevine-plugin package, your system will not be tainted by closed-source code.

Flash browser plugins:

adobe_flash_8s600x600_2 I have packaged the new Flash from Adobe. a security fix, as plugins for chromium (PPAPI) and for mozilla-compatible browsers (NPAPI).

The new Slackware package for chromium-pepperflash-plugin has version This version is newer than what the Adobe page lists as their most recent version for Chrome (… I guess Google did a surprise release of version 40 instead of another 39.x.x.x and Adobe did not notice. But it is the real thing.

The new Slackware package for flashplayer-plugin has version

For my pipelight package, you can easily update the Windows plugins it installed for you earlier (including the Windows Flash player if you use that) by running (as root) the script:

# pipelight-plugin --update

Let me remind you again of some mirror sites across the globe:


Using git while working on KDE 5

Even though I caught a bad cold (luckily, it was not the flu as I feared at first) I managed to do a lot of prepping for new KDE 5 packages (Frameworks, Plasma, Applications) since last week.

The way I tackled KDE updates in the past, was to update the sources, check the continued need of patches used for prior releases, and then start compiling and checking the build logs for errors – and responding to errors with fixes to the scripts, new patches or even new or updated dependencies. The core of the KDE.SlackBuild framework would remain largely unchanged, and it never took lots of going back and forth to recompile packages and get rid of errors or missing dependencies. KDE 4 has always been very easy to update (well, easy – experience helps a lot, plus the fact that I wrote the KDE.SlackBuild framework and know its ins and outs).

Working with the first test release of KDE 5, last summer, was a bit of a challenge, but I took it like I did with every change to a new release cycle of KDE 4 (4.11 -> 4.12 etc…): finding all available documentation on the available sources, their inter-dependencies as well as their other needs, and reading the comments and patch proposals on the KDE packagers mailing list. Going from KDE 4 to 5 was a heck of a lot more work than I initially anticipated (the hardest part was figuring out the tiering concept of the Frameworks, and of course there was a lot of cursing at the immaturity of the Plasma sources) but I considered that first release for Slackware as nothing more than a play-test. The preview packages were designed not to mess up your existing KDE 4 configuration, and easily un-installable. For me the important thing with this proof of concept was to convince myself that the updates to the KDE.SlackBuild framework were sound and I understood and was able to respond to the new reality of fragmented release cycles.

This last week, I have been targeting a more serious outcome. The upcoming KDE 5 packages for Slackware which I will be releasing sometime later this month, are meant to replace your good old KDE 4 installment, and therefore I need to deliver something that you can work with on a daily basis – a full set of applications in a functional Desktop Environment.

For that reason, I decided to call upon git to guide me through the process of making changes to the build framework. I needed to be able to reproduce my previous build environments in order to back-track after encountering errors or dead ends, and take a fork from there and try again. Putting the whole KDE.SlackBuild tree in a git repository was something I did in advance – see my previous post on KDE 5 – and since then, I have been pushing my changes to the repository continuously.

Definitely, this has saved me from finding myself in a dead end. What sometimes happened was that some application would compile into a package one time, and fail to compile the next iteration. Usually the cause would be an update of a dependency, the introduction of a patch to another package and more of that vague stuff. My git updates enabled me to inspect all updates I had done since a previous compilation attempt, and revert or adapt some of the changes I had made. In some other cases, the changes I could track graphically in the ktown cgit web interface showed cause and effect with more ease than back in the time when I would keep multiple directory trees of past attempts. A time saver!

I am currently compiling the last couple of packages that are part of the Applications. If they succeed, it means that the KDE.SlackBuild is ready and I have a full set of packages. If you ask whether they produce a wonderful Desktop Environment… I do not know yet :-) That will be the next step: when all packages are conceptually OK, I will fire up an X session in the virtual machine and see if the stuff I compiled works at all. If I get into a functional KDE 5 environment, that will be cause for celebration. But I expect that I will have issues in the VM (with sddm and/or kwin). If I see failure, I will try installing the packages on a real computer and see how it fares there.

I won’t release any packages until I am fully satisfied, but feel free to tinker with the KDE.SlackBuild in advance.


Monthly Flash Player security updates

Pepper Flash for Chromium:

chromium_iconChrome was updated because of a Flash security bulletin from Adobe. The new Slackware package for chromium-pepperflash-plugin has version



Linux Flash for Mozilla-compatibles:

adobe_flash_8s600x600_2 The “legacy” Linux NPAPI plugin for Mozilla-compatible browsers was updated as well – never leaving version 11. My Slackware package for the flashplayer-plugin went “up” to (micro version update).



Windows Flash for Mozilla-compatibles provided by Pipelight:

pipelight-logoFor my pipelight package, you can easily update the Windows plugins it installed for you earlier (including the Windows Flash player if you use that) by running (as root) the script:

# pipelight-plugin --update

A new package is not required therefore.