Alien Pastures

My thoughts on Slackware, life and everything

Month: December 2017 (Page 1 of 2)

December packages for Slackware’s Plasma 5 – focus shift

December 23, 2017 / / 87 Comments

Jingle Bells galore! I have some goodies for you, right before Christmas. If your winter holiday starts today, there’s some nice new stuff to play with – especially if you have not dared touch slackware-current until now. Perhaps it’s time to free up a partition on your hard drive now?

The KDE Applications 17.12 have been released by the KDE community. This set of KDE applications is completely free of the legacy KDE4 stuff (kdelibs4). The KDE developers have removed everything from their regular release cycles that is still based on kdelibs4 and/or unmaintained or broken anyway.

This made me consider my strategy for future upgrades in my ‘ktown’ repository. I expect that users of Slackware 14.2 are typically still using all kinds of 3rd party applications that are dependent on KDE4. If I just went ahead and removed all KDE4 support from the ‘14.2‘ section of the repository, that would likely not be received well. On the other hand, I want to go forward with Plasma 5 and make sure that the scripts and sources are in good condition to transition to Slackware-current when Pat feels the time is right. Plus, a complete removal of old KDE4 stuff needs testing too. Perhaps (small) parts of the old KDE4 should be re-added to support older applications… what do I know. For that reason I have left the ‘kdelibs‘ package in its ‘kde4’ subdirectory.

I have decided to freeze the ‘ktown’ package repository for Slackware 14.2 (for 64bit; I had already ceased 32bit updates a while ago). It will stay as-is and will not get updates anymore (unless something serious happens and a need for updates is present). From this December ’17 release onward, I will focus exclusively on Slackware-current (both 32bit and 64bit) with my Plasma 5 packages in ‘ktown‘.
The remainder of this article is perhaps only relevant if you are (or want to start) running -current.

So here we are. The December ’17 set of Plasma 5 packages for Slackware -current. My KDE-5_17.12 contains: KDE Frameworks 5.41.0, Plasma 5.11.4 and Applications 17.12.0. All based on Qt 5.9.3 and exclusive for Slackware-current.
There’s again a choice of ‘latest‘ and ‘testing‘ where the ‘testing’ repository contains 17 recompiled packages that provide a Wayland compositor stack. This means you can have a working Plasma5 Wayland session if you use ‘testing‘ as opposed to ‘latest‘.
The ‘testing‘ repository is for… testing. Do not use those packages on a production environment unless you are familiar with Slackware, debugging graphical sessions and know your way around slackpkg/slackpkg+.

What’s new in the December release

  •  Several recompiled/upgraded ‘deps’: OpenAL, PyQt5, cfitsio, ddcutil, gpgme, json-glib, libburn, libpwquality, libxkbcommon, lmdb and poppler.
  • The telepathy section of the ‘deps’ also saw several upgrades: libaccounts-glib, libaccounts-qt5, libnice, libsignon-glib, signon, signon-plugin-oauth2, signon-ui, telegram-qt, telepathy-gabble, telepathy-glib, telepathy-logger-qt5, telepathy-mission-control, telepathy-morse and telepathy-qt5.
  • The Frameworks update is a stability release, see: https://www.kde.org/announcements/kde-frameworks-5.41.0.php .
  • The Plasma updates are also a meant to be a stability update, see https://www.kde.org/announcements/plasma-5.11.4.php .
    I compiled plasma5-nm against openconnect so that it picks up support for it. However I did not add a ‘openconnect‘ package to the ‘deps’ section, you need to install it separately if you need it.
  • Applications 17.12.0 is where the hammer hits. KDE Applications 17.12 is the first release that sheds its KDE4 legacy. Any program which was not yet ported to KDE Frameworks 5 has been removed. This means that we say goodbye to the following packages:
    libkface (unmaintained), blogilo (unmaintained and broken), jovie (replaced by Qt Speech), kaccessible (superseded by Qt5 functionality), ksaneplugin (no one used it), kde-runtime (split up), kremotecontrol, kppp, kfilereplace, klinkstatus, kopete and kscd (I did not have a package for kscd anyway).
    New to the stage is ‘ksmtp’ which belongs to the KDEPIM suite (also part of Applications).
    And ‘kstars’ has moved out of Applications and into applications-extra because it no longer follows the regular release schedule. See https://www.kde.org/announcements/announce-applications-17.12.0.php .
  • In applications-extra I have added kstars (hm, I already said that). I rebuilt calligra and krita. Upgraded to a newer version are kile, kpmcore and partitionmanager. Removed is kuser because that was still KDE4 based and no longer works now.
  • I have emptied the kde/kde4 and kde/kde4-extragear subdirectories except for the ‘kdelibs’ package. The ‘oxygen-gtk2’ package has moved to ‘applications-extra’ because it may still be needed for Mozilla-based browsers (like Pale Moon).
    If you have a KDE4-based application that needs library support on this Plasma 5 desktop, let me know which of the removed packages needs to return in ‘kde/kde4’! Use the ‘ldd’ command to find what libraries you are missing.
  • The ‘kdei’ subdirectory which used to contain the localization packages, is gone. The Plasma 5 localizations are contained in the packages themselves now. This means that you can no longer selectively install just one language, or even none at all. This will increase the disk space requirements a bit.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

As always, the accompanying README file contains full installation & upgrade instructions. I have some further reading material in case you are interested in the Wayland functionality of the ‘testing’ repository: README.testing.

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas. If you want to read them, here they are: http://alien.slackbook.org/blog/tag/kde5/

Where to get the new packages for Plasma 5

Package download locations are listed below (you will find the sources in ./source/latest/ and packages in /current/latest/ and /current/testing/ subdirectories). 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.

Live ISO of PLASMA5

A new Plasma5 Live ISO image (based on liveslak-1.1.9.4) has been uploaded to http://slackware.nl/slackware-live/latest/ , in case you want to try the new Plasma5 desktop out first in a non-destructive way. Note that this ISO (contrary to last month’s ISO) does not contain Wayland support.

Have fun! Eric

Attn: bear’s Slackware 14.2 mirror (32bit) will be removed due to space constraints

December 22, 2017 / / 14 Comments

I have been maintaining a mirror for the Slackware 14.2 (32bit) distribution on my ‘bear‘ server. Its URL is http://bear.alienbase.nl/mirrors/slackware/slackware-14.2/ .

Unfortunately this server runs off a SSD disk which is just 120 GB in size. It has its limits with regard to what I can store there. Lack of disk space is forcing me to remove this mirror copy of the 32bit Slackware 14.2 today. My own repositories are growing and are hungrily looking at that occupied space.
If you were mirroring from my server, you can switch to one of the other highly esteemed mirrors:

The 64bit mirror is not going to go away, I like to have a mirror of the latest stable release on ‘bear‘ (ok… only 64bit from now on). When a future Slackware 15.0 gets released, its mirror will then take the place of the 14.2 mirror on ‘bear‘.

Eric

Updates for LibreOffice and multilib, more to come

December 22, 2017 / / 26 Comments

libreoffce_logoBecause of recent updates in slackware-current (in this case, the boost package) the LibreOffice in my own repository stopped working. Library conflict. Don’t you love the life on the bleeding edge 😉

By coïncidence, the Document Foundation had just released a new version of their LibreOffice sources, so instead of recompiling the old 5.4.3 packages I could grab the new 5.4.4 release and turn those sources into Slackware packages (Slackware 14.2 and -current). The next major release 6.0 is just around the corner but I am not going to wait for that.
You can get the new packages from my repository – like https://slackware.nl/people/alien/slackbuilds/libreoffice/ .

Also, I updated the multilib repository with the latest updates in slackware-current (the new l/Mako, a/lzlib and a/plzip are now also available in a “compat32” version).
Remember to also install the new packages, not just upgrade the existing ones! If you have a local mirror, that means using “upgradepkg –install-new” and if you use slackpkg with slackpkg+, you need to do “slackpkg update; slackpkg install multilib ; slackpkg upgrade-all”. That “slackpkg install multilib” takes care of installing any package you are still missing.

Work on a new Plasma5 package set is also well underway. The 64bit -current bit is done so I know I have my sources and scripts in order, and I am generating a new PLASMA5 Live ISO for testing. Stay tuned.

Hello Chromium 63 – goodbye NaCl

December 18, 2017 / / 15 Comments

December usually is a busy month, with the focus at work to wrap up as much of the ongoing projects as possible and prepare for the christmas holidays. And when there’s a lot of (paid) work to do, the voluntary work gets second place. That’s why there was not really a lot of time to churn out a Chromium 63 SlackBuild script. Two weeks ago the first sources for release 63 appeared online and fixed a lot of (security) bugs. Last week saw an update and this is what I grabbed and packaged, because you can’t wait too long with addressing security issues.

Those of you who had examined my chromium-dev.SlackBuild a while ago will already know that the SlackBuild for versions beyond 63 needed a bit of re-work to cope with changes at the source level. I am glad I did that in November, as it made the transition for the stable browser much easier.

Starting with this package, I am no longer compiling (P)NaCL by default. NaCL, or the Native Client, is a way to run applications in a sandboxed browser process at near-native speed. The PNaCL binaries are platform-independent which means one executable (.pexe) can run in Chrome/Chromium browsers on all supported platforms/architectures. Google announced in May 2017 that it would stop supporting NaCL in the first quarter of 2018 in favor of WebAssembly which is a new cross-platform cross-browser solution to run high-performance applications. Both Mozilla’s and Google’s browsers already support WebAssembly, Microsoft and Apple are getting there too. You can experience an impressive WebAssembly demo here: The Zen Garden based on Epic’s Unreal Engine.

You can of course recompile the chromium package if you need NaCL. The chromium.SlackBuild script defines a variable “USE_NACL” which used to be set to “1” and now defaults to “0”. If you set it back to “1” and run the SlackBuild script, you will get your NaCL support back.

The reason that I stopped compiling NaCL support is pretty basic.
Last month it became clear to me that many Google developers are not caring about anything else than their own ecosystem. Call me naïve. The compilation issues I was experiencing with the GCC compiler were dissed with a remark that internally, Google uses a patched version of Clang which does what they need and standards-based code is not really at the top of their list. Any issues I had with gcc (along with packagers of other distros), they were not going to fix. The anticipated but unhelpful answer was to just download and use Google’s Clang binaries. But that goes completely against the idea behind my own chromium package… do not rely on the Google binaries (aka Chrome) and instead build natively on Slackware.
It forced me to find a way to compile the Chromium sources using their ‘Google hack’ of the Clang compiler.
So when helpful people at Google (they too exist of course… not all of them are so single-minded) showed me how to download the Google Clang sources, compile that first and then use those binaries to compile Chromium in turn, it dawned on me.
All this time I had been downloading and using Google binaries anyway: the (P)NaCl code is compiled using a pnacl binary toolchain which gets downloaded from Google during the compilation of the Chromium sources. That was the moment where I took the decision to stop with providing NaCL support in my package, and make sure that all the binaries I need for the chromium package are compiled natively on Slackware.

Get chromium 63 packages for Slackware 14.2 and -current:

Using your Slackware to control your Android

December 16, 2017 / / 9 Comments

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:
    wget https://dl.google.com/android/repository/platform-tools-latest-linux.zip
  • Extract the ZIP file to /usr/local (you need to be root):
    unzip -d /usr/local platform-tools-latest-linux.zip
    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
    #!/bin/bash
    /usr/local/platform-tools/adb “$@”
    EOT
    chmod 755 /usr/local/bin/adbcat << EOT > /usr/local/bin/fastboot
    #!/bin/bash
    /usr/local/platform-tools/fastboot “$@”
    EOT
    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 https://raw.githubusercontent.com/NicolasBernaerts/ubuntu-scripts/master/android/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 192.168.1.100:5555

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 (“com.google.android.gms”) and reboot the watch: 
    pm clear com.google.android.gms && 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

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑