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



March 2015
« Feb    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages


Thinking about working on KDE 5 again (frameworks, plasma, applications)

qt-kde-620x350During these final days of my relatively long Christmas holiday, I have started looking at the KDE 5 build scripts again. KDE 4 has seen its final release sometime ago, and Patrick shows no signs of updating the KDE in slackware-current, so in order to bring some fresh excitement to KDE users on Slackware, I am pondering an update of the “testing” repository aka the KDE5 repository.

In December, the KDE community released the first tarballs of the “Applications” which is the first step to completion of the new KDE 5 desktop. Remember: the Frameworks 5 came first (a set of modular libraries that expand the functionality of Qt5), Plasma 5 builds a desktop workspace on top of the Frameworks, so that had to come next, and finally there are the Applications which are now ported from the KDE 4 Development Platform to Frameworks 5 slowly.

In particular that recent release of Applications 14.12 (the notation used here is gave me some headaches. Most of these applications are familiar from KDE 4, and only a few are now ready for the Plasma 5 desktop workspace (Kate and KWrite, Konsole, Gwenview, KAlgebra, Kanagram, KHangman, Kig, Parley, KApptemplate and Okteta). It is impossible for me to separate the KDE 5 applications from the KDE 4 applications. Their names have not changed, and whereas I needed to rename a few packages in Frameworks and Plasma in order to prevent a clash with package names in the KDE 4 set, I do not want to do the same for the Applications. After all, when running Plasma 5 you do not want to see both KDE 4 and Plasma 5 versions of the Konsole application in your desktop menu – just the Plasma 5 version. Also, compiling these “Applications 14.12″ will cause a lot of KDE 4 packages to be overwritten – for example, marble-4.14.3 with marble-14.12.0 et cetera. That is a one-way road. I can not think of a clean method of separating the old and the new.

In my “preview” of KDE 5, I was able to offer the KDE 5 packages as co-installable to KDE 4 because it was not yet more than Frameworks and Plasma packages – it needed the presence of KDE 4.x in order to provide a meaningfull Plasma 5 workspace. That meant, you could install KDE 5, play around with it for a bit, and then un-install the packages if you had seen enough, without this process touching or destroying the configuration of your KDE 4 environment. That was a good thing, because Plasma 5 was quite unstable at that time, and the whole exercise was not meant to probide an actual day-to-day work environment.

We are now 5 months further in time, and the current state of Frameworks/Plasma 5 combined with the new set of Application releases, should provide a stable platform that is slowly migrating from KDE 4 to 5.

That is why I decided to not stretch my luck and try another co-installable version of KDE 5 but instead go all the way and provide a full upgrade from KDE 4.14.3 to Frameworks/Plasma/Applications. It will take a while because of all the unknowns, but I think I have done most of the preparations now (gathering all the sources, updating the build scripts). It will be a matter of compiling, fixing failures and retracing issues to their resolution.

I think I will also provide scripts for an easy roll-back from the new KDE 5 packages to either the default Slackware packages or else my KDE 4.14.3 packages.

Note that this is going to be relevant and beneficial only to people who are running Slackware-current (our development version) so if you are going to want to try this later on, you need to know what you are up to. Once you will upgrade from KDE 4 to my new KDE 5 packages, it may not be trivial (i.e. without cleaning out your ~/.kde and ~/.local directories) to downgrade at a later point in time.

End transmission.


Watch Netflix video in your chromium browser – this time for real


I have made change to my Chromium package which some of you will find interesting. As you might know (I wrote about it in an earlier article here on Alien Pastures) Google and Netflix combined their efforts and that resulted in native support in Chrome for the playback of Netflix videos, using the Widevine Content Decryption Module (CDM) which is incidentally also owned by Google. This was all made possible using the Encrypted Media Extensions (EME) in a HTML5 player. Unfortunately, I was not able to find a way to add this Widevine CDM support to my Chromium package – using a similar approach to the way I add support for Flash using the binary libraries taken from the official Chrome RPM.

Then my Slackware buddy ppr:kut pointed me to a discussion in the Chromium bugtracker on Google Code where someone stated he had found the solution. The description was a bit vague, no patches were posted, but the general concept was clear.

I proceeded with updating my SlackBuild for chromium-dev (which is currently at version 41.0.2236.0) and re-writing my not-working widevine patch. That resulted in a new chromium-dev package which reported that a Widevine plugin was available. Alas… when opening a Netflix page and attempting to play a video, this only resulted in the error “M7363-1262-00000000″ which seems to have a relation to a mismatch between the Widevine CDM library and the browser. A possible explanation could be that I used the Widevine CDM library from stable Chrome 39.0.2171.95 in that build of the chromium development version 41.

So, my next attempt was to rebuild the stable chromium package (39.0.2171.95) with the Widevine patch, using the Widevine CDM library from the Chrome RPM bearing that same version. And what do you know… success!

I can now watch Netflix video’s in my Slackware chromium browser. How nice is that.

Apparently, having a functional Widevine CDM support will allow you to watch Youtube Movies as well, but since I already pay for Netflix I did not want to test these Youtube rentals. Another test which failed was my attempt to watch television on, the content streaming network of my provider (UPC/Liberty Global). Even with a UserAgent spoofer and all browser cookies removed, that site still detected that I was visiting using a Chrome/Chromium browser and kept presenting an annoying popup to force me to switch to a different browser because Chrome does not support Silverlight anymore (on Mac OSX and Windows 64-bit at least, remember their NPAPI depreciation). No way around that, even though I was fairly sure that Horizon TV also used Widevine for Digital Rights Management (DRM) in the past. Guess I still have to use Firefox with Pipelight for that, then.

What do you need in order to watch Netflix in Chromium on Slackware (14.1 and -current)?

  • Just two packages are needed: chromium and chromium-widevine-plugin. The latest chromium package was rebuilt to enbable support for Widevine. The chromium package itself does not contain any proprietary binaries. The chromium-widevine-plugin package is what contains the “” library which was extracted from the official binary Chrome RPM – this is proprietary software.
  • It is not necessary to use a UserAgent spoofer. Netflix works out of the box.
  • Make sure your mozilla-nss package has at least version 3.16.4 (Pat Volkerding upgraded all mozilla-nss packages in recent Slackware releases for this reason)
  • In Netflix Playback-settings chose HTML5

Note 1:

No more changes are needed to the file “/etc/default/chromium”. The plugin is announced to chromium by means of the “” library which is built from the Open Source code in the chromium tarball, but only in the presence of the proprietary “”. Installing or upgrading the chromium-widevine-plugin package will show a few lines of warning if it detects that you still have the old configuration block enclosed by “START chromium-widevine-plugin” and “END chromium-widevine-plugin“. You should delete that block now.

Note 2:

If you don’t care about Netflix or don’t want to install any non-free software, then the chromium package is still OK for you – just don’t install chromium-widevine-plugin and you’ll be fine. If you even want to get rid of any hint of Widevine support you can always recompile the package with the variable “USE_CDM” inside the chromium.SlackBuild set to zero (0). That will prevent the creation of the (open source) adapter library “”.

Have fun! Eric

Happy New Year of 2015

To all of you who are reading my blog posts: I wish you all the best for this new year of 2015.

May it be a year where religion is not abused as a reason for killing people indiscriminately. May it be a year where people start thinking out of the box in an attempt to solve the big issues of this era. May it be a year where fear of technology is replaced by joining forces to share new technologies and have everyone profit frm them, not just the rich upper classes. May there… well you get the idea.

Don’t forget Slackware in 2015. I won’t forget you guys. In fact, I hope to post soon with news about bringing Netflix playback support to my Chromium package (this time it looks to be for real).

Cheers, Eric


Rye Honey Sourdough Bread

Not everybody follows the Google+ community “The art of bread”, so I will duplicate my post about a great bread I baked last week.

Last year during the christmas holiday, I started my bread baking hobby – basically everything created out of yeasted dough. In the beginning I used the regular “fast-action” yeast – commercial granulated yeast available in small sachets. But then I discovered the health benefits of “wild yeasts” and created several “sourdough starters” to experiment with those. It turns out that the breads I bake from my sourdough starters have so much more depth of flavour than the breads I bake with the fast-action commercial yeast… so that’s what we’ve been eating almost exclusively since spring season.

I felt it was time to create a rye sourdough starter this year’s christmas holiday period, to see how different the breads would be using this new starter compared to the wheat based starters I have used so far.
My first attempt to bake something with that new starter (a buckwheat and dried cherry sourdough bread) failed miserably because the dough collapsed just when I wanted to bake it (was it overproofed? Too much buckwheat?). I still baked the sticky mess in a dutch oven to keep it together somewhat… and the result was a very nicely tasting clump of very dense bread.The second attempt went a lot better:
My wife gave me a book on sourdough by the Swedish baker/writer Martin Johansson. Using his recipe for Rye and Honey sourdough, I ended up with the big loaf in the picture. I never had a sourdough grow so much in volume during its bulk fermentation and proofing stages, it was amazing! This time, the dough kept its strength and structure and gave a perfect result. The added honey creates a beautiful dark and tasty crust, and the crumb is soft, with a delicious blend of the rye and acacia honey.
I never cared much for the rye bread we can buy in the shops here in the Netherlands, but I had been adding 10% rye to my whole-wheat sourdough breads lately and that really improved the flavor of my breads. I am glad I finally tried increasing the rye percentage.Here’s the recipe I followed (slightly adapted from the book).The night before you bake, create a levain – mix the following ingredients and leave them to develop overnight (covered under plastic wrap or a towel):

  • 50 gr rye sourdough (100% hydration)
  • 150 gr water
  • 65 gr rye flour (I used stone-milled whole-grain flour)
  • 35 gr whole wheat flour

The next day (in my case, appr. 10 hours later), mix the following together and leave to autolyse for 30 minutes:

  • yesterday’s levain
  • 30 gr honey
  • 165 gr water (tepid)
  • 325 gr strong white flour (I used  200 gr wholewheat and 100 gr plain flour instead)
  • 75 gr rye flour

After the 30 minutes autolyse, mix into the dough:

  • 8 gr salt

Knead the dough by hand for 10 minutes, then leave it in a covered bowl for its bulk fermentation stage. The recipe estimates this to be 3 to 5 hours, but after 3 hours my dough had expanded to more than double the original volume so at that point I decided to continue with the recipe.

Gently press the air out of the dough and fold it into a ball: stretch a bit of the dough to the side and fold it back to the center. Repeat this while rotating the mass of dough. This brings some tension into the skin of the dough ball you are forming.

Dust a round proofing basket with flour (or use any kind of bowl lined with a tea towel and sprinkle the towel generously with flour), and place the dough in the basket with the seam down (the seam-side will be facing upward in the oven, thus creating opportunity for the bread to crack open while baking). Cover the basket (or place it inside a big plastic shopping bag) to prevent draught from messing with it and leave it alone in your kitchen for a further 1.5 hours of proofing.

In the meantime, place an oven stone or pizza stone roughly in the middle of your oven (if you have one of course… the srone adds heat mass which is beneficial for common household ovens), and a metal tray on the oven floor. Pre-heat the oven to 240 C,

When the dough has proofed sufficiently (and roughly doubled in volume again), turn over the basket onto a silicone mat or a sheet of baking parchment, and shove that onto the baking stone in the oven.
Pour a cup of cold water into the metal tray on the oven floor – that will produce steam and develop a great crust.

Bake for 20 minutes on 240 C with the steam, then lower the temp to 210 C, open the oven door slightly to let the steam escape, close the door again and bake for a further 20 minutes.

The smell! The flavor! One of my best.

(Wine-) Pipelight update – careful upgrade

pipelight-logo After a long time of silence (but ongoing development as shown in their git repository) the Pipelight developers released a new stable pipelight a few weeks ago. I created Slackware packages for this (Slackware 14.0 and newer) but before you upgrade, please read the words of caution at the end of this post, they will save you some frustration.

The new pipelight is a bugfix release: after Google deprecated NPAPI plugins, the focus for Pipelight team has been better support for Firefox. As stated in the release notes, most of the remaining bugs should now be in Wine, not in pipelight. That has also lead to more focus on what used to be called “wine-compholio”. the team’s patch-set for wine that implements the Windows browser plugin support. The name “wine-compholio” has changed to “Wine Staging” which is now even used as the default wine version on Fedora. I am not willing to go that far, so there is still a separate wine-pipelight package that you have to install on Slackware in order to use my pipelight package.

Remember that you can always get the latest Windows plugin releases (an important feature in case of security fixes) without having to wait for me creating a new package. Just run the command “pipelight-plugin –update” as root. After doing that, the next time your browser loads the pipelight plugin, it will automatically download the newest version of your installed Windows plugin(s).

I know that some people are grumbling whenever someone develops a program for Linux that enables the use of Windows software (emulated or otherwise), such as wine or pipelight. The fact is, if you want to watch Netflix on your Slackware computer, and you do not want to install Google Chrome, then Mozilla Firefox combined with pipelight and MS SilverLight is still the only way to achieve this. Chromium does not support NPAPI either and the Widevine CDM can not be made to work as it does in Chrome. Also, software using Silverlight is still widespread in school systems. I will welcome the future implementation of EME in Firefox that will allow separate download and use of Content Decryption Modules (CDM) like Widevine which is used by Chrome for streaming Netflix. Then, Google Chrome nor pipelight/silverlight will be necessary any longer. Accepting that DRM is here to stay and can still be made compatible to Open Source and Free Choice is the start and I am glad that Mozilla thought hard and long about the apparent clash and came up with a sane solution.

Anyway, enough of the ranting.

In my original post about pipelight, you will find full installation and configuration instructions, as well as a troubleshooting section. That blog article is also referred to on the support page. Let me remind you that you need to go multilib if you want to use pipelight on 64-bit Slackware.

Package location (uploads expected later today, I thought it was more important to have this blog page up first):

A note of caution when upgrading to my pipelight-0.2.8 package:

This only applies to 64-bit Slackware!!!

I have made one important change to the file locations of the 64-bit pipelight package. The file “” is a 64-bit shared library, but the previous 64-bit pipelight packages would install this file into “/usr/lib/pipelight/”. That is not the correct location for 64-bit libraries, so the new package installs this file as “/usr/lib64/pipelight/”.

This has the side effect that your pipelight stops working. The error message(if you start firefox in a terminal) will be something like “pluginInitOkay(): incompatible version of pluginloader.exe“. Don’t worry, you can remedy this.

These are the steps you have to take in order to fix this (it’s a one-time action):

As root user: remove all old copies of the library created by earlier pipelight versions:

# rm -r /usr/lib/pipelight

As your own user account, list all plugins you have currently enabled (copy that command’s output because you have to re-enable them in a later step):

$ pipelight-plugin --list-enabled

That command basically checks your “~/.mozilla/plugins/” directory for symlinks named “libpipelight*.so”. If you look inside that directory, you will notice that all these symlinks are pointing to the no longer existing location “/usr/lib/pipelight”. So, you first remove those symlinks:

$ pipelight-plugin --disable-all

And re-create them properly (still as your own user account):

pipelight-plugin --enable <your previously enabled plugin(s)>

That’s all. Have fun! Eric