Category Archives: Uncategorized

Patreon account for Patrick Volkerding’s Slackware

Hi Slackware supporters, fans and users.

Patrick Volkerding has confirmed on that the Patreon account “slackwarelinux” is actually his.

Everybody who wanted to support Slackware after it became clear that the Slackware Store had not been paying Patrick and family for a long time, but was not prepared to create a PayPal account in order to donate money: there is now an alternative.
Patreon is a community site where “Patrons support the creators they love in exchange for exclusive membership benefits“.
I don’t know whether Pat will do stuff like “exclusive benefits” considering the fact that he already gives away Slackware Linux for free since 26 years… anyway, he created a page there where you can setup a monthly recurring payment of one dollar or more – whatever you can spare. Payment methods are either PayPal or credit cards.

if you do not have a credit card and do not want to use PayPal either, you can still send money through regular postal mail. Pat’s address can be found in the initial post here:

So, check out and consider helping Patrick and family to keep Slackware alive.

Pale Moon browser removed from my repository

I have removed my contributed build of the Pale Moon browser from my package repository.

The reason? Primarily the attitude of its developers. The main developer is ridiculing Slackware. When working on my initial SlackBuild script and trying to obtain approval to use their ‘official branding’ I had a seriously grim argument with the lead minion of the developer group and the lead maintainer had to step in to appease. That set me off on the wrong foot from the beginning, but I thought an alternative to Firefox would be beneficial to Slackware users, so I added the package and build script despite my misgivings.
However, the above is not how a respectful relationship between developer and distributor works. Also, Moonchild refuses to mention me as a “contributed build” on the “contributed builds” page.

And frankly, I have enough of the arrogant attitude that all issues with their browser (which is a derivative of Mozilla Firefox code, forked before the moment certain big changes were being made to Firefox) are caused by packagers who compile and distribute their own binaries and never caused by the developers. That just falls short of confessing that their code is not mature yet.

If you want to keep running Pale Moon, you can use the SlackBuild script maintained by Khronosschoty and one of the binary packages he provides here:


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.


Using your Slackware to control your Android

Linux and Android

No worries, even though this article is a side-step into the Android ecosystem, it is still on-topic for Slackware users.
I recently bought a Huawei Watch 2, when it was in a sale on Amazon. It’s the 4G version and long ago I had made a deal with myself that if a smartwatch with GPS and room for a SIM card would go below 300 euros, I was going to buy it. And so it happened, and the watch is a lot of fun. It’s incredibly light-weight and fits comfortably. Despite grumpy reviews it is a solid design and does not feel like cheap junk at all. I still need to find a provider who will allow me to use a second SIM card for my mobile subscription, so for the moment this watch is SIM-less. It talks to my phone over Wi-Fi and Bluetooth so nothing’s lost and I have full connectivity on the watch. The idea is to have a SIM in the watch so I can go outdoors for a long run without having to take my phone with me.

An Android Wear watch will pair with only one single phone. It’s quite picky about its friends. Therefore, if you switch phones and want to pair the watch to your new phone, it will wipe and reset itself to factory defaults. That was not what I wanted when I traded my four years old HTC One M8 for a HTC 10 phone. Yes, that too was a bargain sale – I got it for 272 euros which is roughly 65% of the regular price around here.

So I went searching for ways around my dilemma, and as it turns out: it is quite easy to de-couple an Android watch from its pal the phone, and let it pair with a new phone, while keeping its current settings and content. I am going to document that process here, because much of it is generic enough that you can use it to manage the internals of any Android device, like your phone.

The singularly important tool for interacting with Android devices is the Android Debug Bridge, or “adb” for short. It’s a program or rather a suite of tools that run on Linux, Windows and OS/X and allow you to execute commands remotely on the Android device. Commonly the bridge is used over a USB connection between Computer and Android device, but in this article I will show you that you can just as easily use a Wireless connection.

Installing Android Debug Bridge

First, let’s setup the Linux computer. In our case, that will of course be a Slackware computer, right? 🙂

ADB is a small part of the “Android SDK Platform-Tools” and in the past, this meant you had to install the complete SDK in order to gain access to adb and fastboot. Recently, Google has started making adb and friends available as a separate, much smaller (around 5 MB) ZIP download. The URL is static but the content will be refreshed from time to time.

  • Download the ZIP containing the platform-tools for Linux:
  • Extract the ZIP file to /usr/local (you need to be root):
    unzip -d /usr/local
    That leads to a directory /usr/local/platform-tools/ with a lot of stuff in it.
  • Create two wrapper scripts for the ‘adb’ and ‘fastboot’ binaries inside the extracted directory. This way, typing “adb” or “fastboot” will work in any directory:
    cat << EOT > /usr/local/bin/adb
    /usr/local/platform-tools/adb “$@”
    chmod 755 /usr/local/bin/adbcat << EOT > /usr/local/bin/fastboot
    /usr/local/platform-tools/fastboot “$@”
    chmod 755 /usr/local/bin/fastboot
  • Download and install a UDEV rules file which identifies most if not all known Android devices and makes udev create device-files for them when the Android connects (strictly speaking, his is only relevant for remote debugging over USB… if you connect over wireless then device-files are not used). The file is community-maintained and part of a git repository for Ubuntu. After installing the UDEV rules, you need to reload udevd’s cached rules:
    wget -O /etc/udev/rules.d/51-android.rules
    chmod 644 /etc/udev/rules.d/51-android.rules
    /etc/rc.d/rc.udev reload

You’re all set now to connect to your Android device and interact with it. Thanks to the UDEV rules you’ve installed, you won’t have to be root to use ‘adb‘ and ‘fastboot‘ as long as your user account is a member of the “plugdev” group.

Tip: if you have a USB stick with the Slackware Live Edition, you can repeat the above with one change: instead of installing the debugger tools to /usr/local , the wrapper scripts to /usr/local/bin and the UDEV rules to /etc/udev/rules.d/ you (i.e. with “/” as the root) you install the lot to the /rootcopy/ directory of the USB stick, keeping the same directory structure and thus ending with /rootcopy/usr/local/bin/ and /rootcopy/etc/udev/rules.d/ . That will make your Slackware Live a powerful tool to manage Android devices.

Enable remote adb debugging

Android devices do not allow remote debugging by default and it is not immediately visible how to enable this capability. You will have to enable developer options on your Android. This takes the form of a secret ritual… and enables several new menus and options in your Settings.
First, generic Android instructions:

  • Open the “Settings” on your Android.
  • Scroll down to “About phone” (or “About Tablet”)
  • Find the entry which shows the “Build number”.
  • Repeatedly, tap the “Build number” line. After a couple of taps, a popup message tells you that you are an “X amount” of clicks away from becoming a Developer. As you keep tapping the number “X” will decrease to zero which completes the process.

Android Wear instructions:

  • Swipe down from the top of the screen.
  • Tap the “Settings” icon (gear icon).
  • Scroll down and tap “System”.
  • Scroll down and tap “About”.
  • Then scroll down and tap “Build Number” repeatedly.
  • Keep tapping until you get the message “You’re now a developer”.
  • Swipe to the right twice.
  • Scroll down and you’ll see new “Developer Options”.

In the new Developer Options menu you will find “ADB debugging” which you have to enable. For the Android Wear device, it makes sense to also enable “Debug over Wi-Fi” since at least my watch does not have a micro-USB connector.

If you look at the screenshot you’ll notice that the watch’s IP address is shown in the “Debug over Wi-Fi” section. We will need that IP address soon.

Connect to Android using adb

Connecting to a device which is connected through USB is simple. You request an overview of detected devices and if your device (phone or tablet) is detected, it will be listed and you can control it remotely:

adb devices

With a smartwatch, you first need to connect to its IP addres over the port number shown in the screenshot above:

adb connect

You do not need to be root to do this.
Any of the above two commands will start the adb daemon if it is not yet running. In case of connecting to a smartwatch, you will have to accept the incoming connection on the watch-side.

You can now start sending commands to be executed on the Android device. For phones, this is usually part of the rooting process followed by installing a custom ROM. That is beyond the scope of this article.

Pair your watch with a new phone

Now that the pre-requisites have been taken care of, let’s go through the steps to pair the Android Wear watch with a new phone. You do not need to be root to do this.

  • Disable Bluetooth on your old (if you have it still) and new phone.
  • Open an adb shell – basically a remote shell on the watch. You’ll notice the prompt (sawshark:/ $), sawshark is the Android codename for my Huawei Watch 2 Sport:
    adb shell
    sawshark:/ $
  • Execute the command that instructs Package Manager to clear stored data & cache (“pm clear”) of the Google Play Services (“”) and reboot the watch:
    pm clear && reboot

    This clears the pairing information including the keys to communicate securely with the paired phone, but does not trigger a factory reset which happens if you un-pair the phone via the watch settings menu.

  • Make sure you have installed the Android Wear app on your new phone but do not enable Bluetooth on the phone yet.
  • From the computer, connect to your watch again over Wi-Fi (accept the incoming connection request on your watch) using the “adb connect” command shown earlier. Start a new “adb shell”.
  • At the remote prompt enter the command to make the watch visible for Bluetooth discovery by telling Activity Manager to start an Activity specified by the intent “android.bluetooth.adapter.action.REQUEST_DISCOVERABLE” (and make sure you accept the ‘OK’ prompt on your watch):
    am start -a android.bluetooth.adapter.action.REQUEST_DISCOVERABLE
  • Now is the time to start Android Wear on your new phone, allow the app to turn on Bluetooth and start scanning for a Android Wear watch to pair with. When the phone finds your watch, an accept request will show on both. Once you have accepted both prompts, new pairing keys will be generated and stored in the watch’s Google Play Services app. You can synchronize the watch data to your phone and manage it from there.

Good luck! Eric