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

My Favourites



February 2018
« Jan    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current


LibreOffice 5.4.3 packages available

libreoffce_logoThe Document Foundation released the third update for LibreOffice 5.4 last week, as you can read on their blog where they write about the new LibreOffice 5.4.3 . My manic-depressive mood-swings are on the manic side at the moment so next to baking sausage rolls (brabantse worstenbroodjes for which I will publish an updated recipe on this blog soon) and a batch of sourdough bread, I finally had the energy to fix the admin interface for the SlackDocs mailing lists, wrestled myself through 14,000+ emails in my administrative mailboxes, wrote a plan to migrate my LAN services from the ageing server to the new server I bought this summer (which involves conversion of several large databases to InnoDB and loads of custom packages), plus I binge-watched almost 2 full seasons of Stranger Things in 3 days’ time. I know I will crash hard in a couple of days but I hope to have a new Plasma ‘ktown’ update before that happens.

Back to the topic: the LibreOffice 5.4 release notes contain full detail about its features: Note that the developers state that “LibreOffice 5.4.3 continues to represent the bleeding edge in term of features, and as such is targeted at technology enthusiasts and early adopters” and I think that describes us Slackware users well enough 🙂
Their advice for more conservative users is to stick to the 5.3 releases but I am no longer compiling packages for that.


In any case, thanks to the 16 cores on my build server it did not take all that much time to generate packages for Slackware 14.2 and -current.
When I tried the new programs on my laptop (which is running Plasma5) I noticed that the default User Interface for LibreOffice causes rendering issues. Also, my Plasma5 destop is configured to move application menus out of the application window into a button in the window’s top bar. That setting is apparently not compatible with the default User Interface and it caused the loss of the LibreOffice menu.
I could fix these issues by editing the profile script “/etc/profile.d/” and un-commenting the line “export SAL_USE_VCLPLUGIN=gtk3” to force LibreOffice to use GTK+3 as the widget set.

The libreoffice packages for Slackware can be downloaded from any mirror like this one:

Have fun! Eric

OpenJDK8 security update November 2017

icedteaOn the ‘distro packagers‘ mailing list for OpenJDK there was an announcement today that IcedTea 3.6.0 is ready, and allows building of the OpenJDK 8u151_b12 (Java 8 Update 151).The official October 2017 security fixes for Java 8 are applied, and the announcement contains a long list of CVE entries that are being addressed.

You can download openjdk and openjre packages for Slackware 13.37 and newer:

If you want to compile the OpenJDK package from source yourself you will need to install apache-ant first, but this package is not needed if you just want to run Java using the JRE or compile Java code using the JDK.

Note about 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.

Have fun! Eric

Chromium is now compiled using clang

chromium_iconIn my previous blog post about Chromium 62, I described the issues I had while attempting to compile it on Slackware14.2. The gcc compiler suite on Slackware 14.2 is “too old” for Chromium because it lacks the required C++11 support. More to the point, the Google developers use clang instead of gcc for their own compilations and therefore gcc support is becoming stale. Response by Google developers when they encounter a gcc-related bug report is to ‘please switch to clang’.

Unfortunately, as previously noted, the chromium build framework will download Google’s own clang binaries in that case. I do not trust these binaries on my Slackware computer. I stated that I would not switch to clang until it became possible to either use Slackware’s own clang or else compile Google’s clang from source on my own computer.

I exchanged a couple of emails with Google developers and got enough hints to convince me that compiling Google’s clang was possible.

And indeed, after a week of trial and error (especially the 32bit build gave me headaches) I managed to add all the needed bits and pieces to my chromium.SlackBuild.

The updated packages for Chromium (version 62.0.3202.75) for which the sources were released last week, are compiled with clang instead of gcc, and that clang has been compiled from source first. Of course, this adds time to the package build… every time I compile the chromium package, the SlackBuild script has to download and compile clang as well. But, the process is fully automated and a separate “gcc5” package is not needed on Slackware 14.2. Also, we are future-proof now. And an added bonus is that the package size has decreased substantially, from 65 to 56 MB (a 14% decrement).

Note about the new Chromium release: it addresses CVE-2017-15396 (Stack overflow in V8) so it will be good to upgrade.

If you want to compile chromium using gcc nevertheless (to decrease the total build time for instance) then all you need to do is: set the variable “USE_CLANG” to “0”.
On Slackware 14.2 you still need my gcc5 package and apply the instructions from my previous post.

The packages for chromium are available for Slackware 14.2 and -current in my repository or one of its mirrors:

Have fun! Eric

Netsurf, a lightweight browser, works on the framebuffer too

Someone asked me to build a package for Netsurf. I had never heard of Netsurf before. It turns out that Netsurf is a cross-platform web browser which also runs on Linux. Its rendering engine is written from scratch, therefore the browser does not share code with any of the big browsers. Netsurf is actively developed and has a healthy community. A new version was released last week – 3.7.
Functionally speaking, this browser is not as versatile or capable as other modern browsers, but its advantage is that it is small, fast, suited for low-end hardware, and more importantly: it works on the Linux framebuffer. This means that you can have a basic graphical web browser on your server console. It looks better than “links -g”.
Note: even though Netsurf comes with both a GTK version (netsurf-gtk) and a framebuffer version (netsurf-fb), even the framebuffer binary make heavy use of X.Org and freetype libraries. So if you want to use the framebuffer browser on a server console, you need to install the X series anyway.

How to make Netsurf work on the Linux framebuffer, i.e. on the console?

  • Add your user to the “input” group so you can use the mouse (i.e. the /dev/input/mice device node) using the command (as root):
    # gpasswd -a your_username input
    If you are currently logged on, you need to logout and login again to make this change effective.
  • Determine the width and height of your framebuffer console to make maximal use of your screen dimensions (netsurf on a framebuffer defaults to a window of 800×600 pixels) by querying the /sys virtual filesystem and look for the characteristics of the fb0 framebuffer device:
    # cat /sys/class/graphics/fb0/virtual_size
    This will return width and height in pixels, comma-separated. In my case I get “1920,1080”.
  • Read the available documentation to learn about the limitations.

With the above taken care of, start the Netsurf framebuffer browser with:
$ netsurf-fb -w <width> -h <height>
… where <width> and <height> are the values obtained from the command further up.

Curious? Get the package from my regular repository ( or any of its mirrors.

If you want to compile netsurf yourself, you’ll also need two dependencies, “perl-html-tagset” and “perl-html-parser“.

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