My thoughts on Slackware, life and everything

Category: Uncategorized (Page 3 of 5)

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
n.so” for platform “xcb”
org.kde.plasmaquick: Applet preload policy set to 1
plasmashell: relocation error: /usr/lib64/libKF5Declarative.so.5: symbol _ZN15QQmlPropertyMap15allocatePrivateEv version
Qt_5 not defined in file libQt5Qml.so.5 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 https://www.kde.org/announcements/plasma-5.13.0.php 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.

Enjoy!

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:
    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

Encrypted Media Extensions on the World Wide Web

Today, a post about Digital Rights Management. I am not going to bore you with the pros and cons of restricting your freedom, but I do want to point to a meaningful event which happened this week.

Before I continue, I want you to fully realize that with Slackware Linux, your rights are not taken away. You are free to use – or not use – technologies that allow you to watch “protected” content like Netflix videos. Our browsers will work just as well if you choose not to use DRM technologies. The libraries which implement the DRM layer are separate from the Slackware packages containing the browsers (Firefox, Chromium) and are not distributed with the OS. It is up to you to add DRM extensions if you need them. You are and remain in control of your OS.

With that out of the way, what happened?
This week, the World Wide Web Consortium (W3C) has finally approved the Encrypted Media Extensions (EME) as part of the HTML5 standard. Objections from the Electronic Frontier Foundation, Free Software Foundation and other digital freedom advocates have not been honored. But that does not necessarily mean it’s a bad thing. EME is a standard to implement DRM, but it is not a DRM solution itself. EME allows companies that built their business model around the commercial distribution of protected media content to create rich applications that run in your browser, based on international standards.
Digital Rights Management is not new and it is not going away either. However: it is in need of standardizing to improve the current status-quo. Because there are already several de-facto standards to stream protected content to your browser: Flash, Silverlight, to name the two that have been most widely used in the past years. Both these technologies are dying or dead already. New technologies that build on HTML5 are already becoming unofficial standards; think of Widevine, which is a DRM solution from Google. Not just browser plugins like the ones I mentioned, but also applications can implement DRM when they allow you to watch or listen to multimedia without the option to make unrestricted local copies. Locally stored content will be encrypted and can only be played back using the original app. Lots of those on Android for instance.

DRM solutions are proprietary. Their code is not free and the libraries are distributed as binary-only. There’s a logic to that of course. Think what you will, but there are both providers and consumers that embrace them. What is more important, is that there is wisdom in embedding these technologies in Web standards. We should not encourage companies to pollute our computers with incompatible and non-interoperable solutions. So yes, I am glad that EME is a W3C standard finally. Let the Web remain viable, allowing maximum flexibility and compatibility.

I mentioned Widevine in the text, and I have something new to tell about that too.
My package repository contains the chromium-widevine-plugin. It is a add-on package to my chromium browser package that allows you (among others) to watch Netflix video content in your Chromium browser. In the past I have always used the Google Chrome RPM’s to extract the ‘libwidevinecdm.so‘ library and make a Slackware package out of it. Google stopped distributing 32bit versions of the Chrome browser after version 48 so those of you on 32bit Slackware and using my Chromium package, were stuck with an old version of the Widevine CDM library and no way of knowing how long this library would remain compatible with newer Chromium sources.
But Mozilla have since then extended Firefox’ capabilities, so that it too is now able to use Widevine’s Content Decryption Module. In Firefox, this DRM capability was implemented in such a way that by default, the browser is completely DRM-free. You (the enduser) first have to explicitly enable DRM in the browser’s settings after which Firefox will download the Widevine CDM from an Internet URL. And since Firefox comes in 32bit as well as 64bit variants, I was thinking “where do they download these Widevine libraries and are they useable in Chromium as well?”

So I set out to find the Firefox download location for Widevine CDM libraries, found them, retrieved them and tested the libraries in 32bit and 64bit Chromium. Lo and behold…. this worked!

I have now rewritten my SlackBuild script for the chromium-widevine-plugin package to use this alternate download location. And since I no longer have to extract the library from a Chrome RPM, I have also changed the package version numbering. The package version no longer reflects the Chrome release, but now it is actually reflecting the internal version of the Widevine CDM library.

Have fun watching Netflix! While I am at it, I recommend The Expanse, or perhaps Helix. If you’re not so much into Sci-Fi (or have already seen those series) and want to know more about our basic foods, check out Cooked.

Last week’s package harvest and more

Last week I made my build server at home churn through a lot of packages, let me summarize what became available recently in my slackbuilds repository:

  • I added ‘NetworkManager-openvpn‘ which is a plugin for NM adding support for OpenVPN connections. I needed this for myself since I recently started using the services of Private Internet Access (PIA). All I needed in addition was the ZIP file with OpenVPN configurations. If you need more instructions about how to setup the PIA VPN let me know and I will wrote some more about that. I also added this plugin to my PLASMA5 Live Edition.
  • I upgraded ‘Handbrake‘ to 1.0.3 which also fixed the libvpx library error on -current.
  • I updated the Flash Player plugins for Mozilla and Chromium browsers to 25.0.0.127 (this is a security update).
  • I updated Chromium and its Widevine plugin to 57.0.2987.98. There is a slightly newer release out already but that will have to wait a bit.
  • I updated LibreOffice to 5.3.1 (packages for -current only but I will build them for 14.2 too).

I did more than that; I also updated the front page of my ‘bear’ server with the information that you can access it over secure HTTP (https), and added a link to my post about the CACert issue with Mozilla and Google browsers. Furthermore I added more detail about the dynamically generated ISOs for Slackware-current (the installation DVD and the Live Edition).

I will spend my next post writing about the new KDE 5_17.03 edition which I uploaded to my ‘ktown’ repository, but let me mention here that I already uploaded a new PLASMA5 variant of the Slackware Live Edition which contains a “work in progress” version of this new Plasma 5 release (work in progress because I decided to add more packages later). I did not mention that in any previous post.
Along with that Plasma 5 Live ISO I also uploaded a variant containing the very fresh MATE 1.18 (thanks to Willy for providing me with the tried & tested packages). So there is enough to play with 🙂
I am actually considering a new spin of the PLASMA5 Live ISO because it allows me to offer the complete KDE-5_17.03 including the Kdenlive non-linear video editor in the Live OS, along with the latest LibreOffice.

Enough for now, check out my follow-up post for the news about my new Plasma 5 ‘ktown’ release.

Have fun! Eric

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders NorenUp ↑