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 387 other subscribers

My Favourites



August 2018
« Jul    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current




Temporarily Inactive

The Alien Pastures blog will be quiet for a little while due to personal circumstances.

Be good.


New set of Live ISOs

blueSW-64pxI have uploaded a fresh set of ISOs for the Slackware Live Edition. They are all based on my ‘liveslak‘ scripts and contain the latest Slackware-current dated “Sat Jun 23 04:57:41 UTC 2018“).
The available ISO variants on (remember to add support for CACert to your system if you see certificate warnings!) are:

  • Full unmodified Slackware (32bit and 64bit).
  • Stripped-down XFCE (32bit as well as 64bit), this ISO will fit on a CDROM medium.
  • Slackware with MATE 1.20 instead of KDE4 (64bit). Thanks to Willy Sudiarto Raharjo for the packaging.
  • Slackware with Plasma 5 instead of KDE4 (64bit) to showcase the Plasma 5.13.1 release. This ISO also contains LibreOffice 6.0.4 and VLC 3.0.3 among many others.

The new liveslak version 1.2.0 has a couple of updates, most related to changes in package lists and work to keep the XFCE ISO below 700 MB, but there is one update that I should mention. I have added – but have not yet tested myself – the possibility to create a configuration file “/liveslak/slackware_os.cfg” and in that file, define some of the variables you would otherwise have to set through boot commandline parameters. Those variables are:


This time the ‘testing’ branch in my ‘kown’ repository is focusing on the new Plasma Desktop 5.13, so there is no Wayland support in it now. For a future ‘testing’ release I’ll most likely re-visit Wayland but I want Patrick to add Plasma 5 to Slackware first so I can do my own stuff in just the ‘latest’ branch again and use ‘testing’ for actual tests.

Refreshing your USB stick instead of re-formatting

If you already use a Slackware Live USB stick that you do not want to re-format, you should use the “-r” parameter to the “” script. The “-r” or refresh parameter allows you to refresh the liveslak files on your USB stick without touching your custom content. If you want to modify other parameters of your USB stick, use the script ““. It’s main feature is that it can update the kernel on the USB stick, but it also can replace the Live init script. As with most (if not all) of my scripts, use the “-h” parameter to get help on its functionality.

Historical info on liveslak

More detail about the features of Slackware Live Edition can be found in previous posts here on the blog.

Have fun!

Qt 5.11.1 and Plasma 5.13.1 in ktown ‘testing’ repository

A couple of days ago I recompiled ‘poppler’ and the packages in ‘ktown’ that depend on it, and uploaded them into the repository as promised in my previous post.
I did that because Slackware-current updated its own poppler package and mine needs to be kept in sync to prevent breakage in other parts of your Slackware computer. I hear you wonder, what is the difference between the Slackware poppler package and this ‘ktown’ package? Simple: my ‘poppler’ package contains support for Qt5 (in addition to the QT4 support in the original package) and that is required by other packages in the ‘ktown’ repository.

But that was not all I updated this week. I have refreshed my ‘testing’ repository on ktown  with bugfix releases for Qt and Plasma. Both were introduced earlier this month in my repository with their ‘point releases’ 5.11.0 and 5.13.0 respectively, and within a week updates became available to squash reported bugs. Both releases are according to their schedules, so nothing alarming there. Business as usual. But since stability is a good thing, I decided not to adhere to my usual montly cycle of pushing updates to my repository.

Therefore I have built new packages for ‘qt5’ version 5.11.1 and for the full ‘plasma’ set (version 5.13.1) and uploaded them to my ‘testing‘ repository.

On this occasion I took the plunge myself and upgraded my laptop’s Plasma Desktop to these ‘testing’ packages. Works well!

I also took the opportunity to check how dependent the Frameworks would be on the new Qt5 release, since I have rebuilt all of the Frameworks packages in ‘testing’ against this 5.11 release of Qt5. As it turns out, there is only one Frameworks package that needs a recompilation when switching from Qt 5.9 to 5.11 and that is the ‘kdeclarative‘ package. If you use all the Frameworks package from ‘latest‘ repository instead of ‘testing’ then the Plasma Shell will not start and you will end up with a black desktop and only the application windows that were started because of session-restore will be visible. As you may know, the Plasma Shell can be restarted from the commandline in case of issues (crashes, graphical artefacts etc) with the command “plasmashell –replace” at a terminal command prompt. What happens if your kdelarative package is compiled against the wrong Qt5 is this:

eha@baxter:~$ plasmashell –replace
org.kde.kwindowsystem: Loaded plugin “/usr/lib64/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugi” for platform “xcb”
org.kde.plasmaquick: Applet preload policy set to 1
plasmashell: relocation error: /usr/lib64/ symbol _ZN15QQmlPropertyMap15allocatePrivateEv version
Qt_5 not defined in file with link time reference

This can be fixed by replacing the ‘kdelarative’ package in Frameworks with a version that was compiled against the Qt5 your system is using.

So, in future Frameworks updates I will likely only have to recompile ‘kdeclarative’ for the ‘testing’ repository and create hard-links for all the other packages. I already am using hard-linking for all the packages that are identical in both ‘latest’ ad ‘testing’ to conserve space.

And with my laptop’s upgrade to ‘testing’, my Chromium browser stops complaining about missing browser integration support. Remember that Plasma 5.13 has a new package ‘plasma-browser-integration’ which introduces desktop controls (in your system tray for instance) to manage certain aspects of browser behavior (Chrome, Chromium, Firefox). I installed and activated the Plasma extension from the Chrome Web Store into Chromium and now I have a control widget in my system tray whenever music or a video is playing in a browser tab. Also, Plasma search (Alt-F2) is able to find individual browser tabs now.

Again I promise to generate a Plasma Live ISO, containing the latest Qt5 and Plasma5… this time I hope to be able to keep that promise. The last ISO was more than 2 months ago and is due a refresh.

Ktown in June ’18 – Plasma 5.13 in the ‘testing’ repo

It’s that time of the month again. KDE tarballs have all been refreshed, and so this presents the opportunity to release a new package set for the Plasma 5 Desktop Environment… but then I found out that the new Plasma 5.13 depends on a minimum Qt5 version number of 5.10. Currently I have Qt 5.9.5 in my repository, and this is a LTS release (Long Term Support). The next LTS release will be 5.12 and this will not be available before end of 2018. Also, the current Plasma 5.12 has Long Term Support and the new Plasma 5.13 has not.
I expect that Slackware will likely adopt LTS versions of Qt5 and the KDE software once it is time to replace KDE4, so that puts me in an awkward position. I have been maintaining Plasma 5 packages in this repository for almost 4 years now, with the hope of getting this included into Slackware. Should my repository remain compatible with Patrick’s estimated goals or should I ‘deviate’ and stick with the bleeding edge like I have always done?

The decision I made eventually is that I am not going to upgrade Qt and Plasma to the newest releases yet. At least, not in the ‘latest‘ repository. On the other hand, the ‘testing‘ repository is alive again, and that contains the new Qt 5.11.0 and Plasma 5.13.0. So you have a choice now. If you go with the ‘testing‘ repository, the new Qt 5.11.0 may cause breakage in packages that have a direct dependency on Qt5. That was  why I had to recompile Frameworks and Plasma against Qt 5.11 but could leave the Applications unmodified even though those had been compiled with Qt 5.9 on the system. You are warned.

The KDE-5_18.06 release of ‘ktown‘ for Slackware-current offers the KDE Frameworks (5.47.0), Plasma (still 5.12.5 like last month) and Applications (18.04.2) on top of Qt5 5.9.6 (which was released recently).
You can and should check out the README file for more details and for installation/upgrade instructions.
And KDE-5_18.06_testing has the KDE Frameworks (5.47.0), Plasma (5.13.0), Applications (18.04.2) with Qt5 5.11.0. It has a similar README.

News about this month’s package content:

  • In the deps section I updated the qt5  package to 5.9.6. In the ‘testing‘ repository I also had to update the PyQt5 package because of the new qt5 5.11 in ‘testing‘.
  • Frameworks and Applications updates are focusing on improved stability. No news here.
  • The Plasma in my ‘latest‘ repository has not been updated as explained in the article header. But in ‘testing‘ you get Plasma 5.13.0. See for all the news and videos regarding this release.
  • The kdeconnect-framework package in plasma-extra was updated.
  • In applications-extra I have updated the okteta, krita and kstars packages.

If you are using slackpkg with the slackpkg+ extension, you need to update slackpkg+ before any other package. The recent modifications to slackpkg broke the extension and you need the most recent version of slackpkg+.
And 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 will try and get a new Slackware Live PLASMA5 ISO image built and released with the new Plasma 5.13 on it, so you can check out the new features. I will have to check the other stuff in the ISO first and recompile anything that got broken because of Qt 5.11.
But don’t hold your breath… I am pretty much occupied with attempting to move 20 years of scripts and data from my ageing server to the ‘new’ box (well new… it’s 9 months old already). Having two servers running 24/7 is hurting my wallet because of the electricity bill. And this migration’s complexity (lots of custom stuff) made me delay the move time and time again. Now, I am focused and determined to finish the job.


Security updates for Java and Flash


Adobe released the June updates for their Flash Player plugins.
The Slackware packages for version of the flashplayer-plugin (NPAPI plugin for Mozilla based browsers) and the chromium-pepperflash-plugin (PPAPI plugin for Chromium based browsers have been uploaded to my repository already.
Upgrade please, if you are still in need of Flash.

And another ‘controversial’ technology had security updates in the last few weeks:


icedteaThere have been new releases for the IcedTea framework: the version 2.6.14 compiles Java 7 and version 3.8.0 compiles Java 8.
The new Java7 is OpenJDK 7u181_b01 and for Java8 I have OpenJDK 8u171_b11. These releases sync OpenJDK to the April 2018 security fixes for Java.
Again, please do upgrade your OpenJDK or OpenJRE packages.

Note that the “rhino” package (implementation of the JavaScript engine used by OpenJDK) is an external dependency for OpenJDK 7, you can find a package in my repository.

If you want to compile OpenJDK (Java 7 or 8) yourself you will need apache-ant as well.

Note about java usage:

My Java 7 and Java 8 packages (e.g. openjdk7 and openjdk… or openjre7 and openjre) can not co-exist on your computer because they use the same installation directory. You must install either Java 7 or Java 8.

Remember that I release packages for the JRE (runtime environment) 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.

Here is where you can download the Slackware packages for Flash (flashplayer-plugin and chromium-pepperflash-plugin) and Java (openjre/openjdk and openjre7/openjdk7):