All my desktop and laptop computers are Linux-based, more specifically, being Debian-based, but I enjoy having some of the simplifications which Windows offers, including either to notify me of pending updates, so that I can use point-and-click methods to install those, or even, in some cases, to install updates automatically. The package which I use, to install updates automatically, as I sleep, is called ‘unattended-upgrades’, which is a package which cannot simply be installed and forgotten. If the user has installed this package, he or she must also configure it. And the following Web-article explains, how to do so under Debian:

A situation I was having for some time was, that ‘unattended-upgrades’ was installed and working fine, on my Debian / Jessie – aka Debian 8 computer named ‘Phoenix’, but that even though I had followed all the instructions for how to install and configure it on my Debian / Stretch – aka Debian 9 computer named ‘Phosphene’, the same package did not seem to work on that one. I had often found that if there did exist updates which the automated process was supposed to install, then the log file on ‘Phosphene’ would break off, just before indicating which packages were going to be installed, and no updates would take place. This would happen every time that some updates were to be installed, and required each time, that I install the updates in question manually. Also, the ‘normal’ logging output did not include any error messages; it would simply stop in mid-process.

What I finally needed to do in order to troubleshoot this process, was to wait until there were going to be pending updates, and then, instead of installing those manually, to run the following command from the command-line, as root, and to observe the output:





Running this command when there were no updates pending was rather useless, because the malfunction would not take place, unless there were updates pending. Also, this process should not be interrupted if it’s in the middle of installing updates, because doing so can and will cause package-corruption and / or software corruption. If the process is going to install multiple packages, the user needs to wait until that process has finished, before doing anything else from the same command-line. What I finally found was, that the article linked to above omits a very important piece of information.

## How to patch ‘kdeconnect’ to work under Debian / Stretch.

There exists an Android app named ‘kdeconnect’, which, when paired with the Debian / Stretch / Plasma 5.8 desktop widget by the same name, allows users to sync various features between their Linux desktop, and their Android device. The versions I’m presently using are:

• Android app: 1.12.9
• Linux package: 1.0.3~bpo9+0

Besides syncing certain basic messages, such as phone Notifications to the widget, this app allows for the desktop computer to browse directories on the Android device, which the user has authorized from his Android device – as long as the Linux desktop widget software has been patched! Below is another shot, of what this looks like when it’s working:

The main observation about this is the fact, that it does not work out of the box. The reason for this is the fact that the Linux widget is out-of-date, as a backport. The Linux-based software tries to use an SSH-FS Mount, that specifies ‘DSA’ as its crypto-algorithm. DSA is an outdated, insecure protocol, for which reason the application framework of Android no longer supports it! Android will demand that RSA be used as a minimum.

And so, due to this initial incompatibility, the SSH-FS Mount, which creates a virtual file system in the user’s home directory, in a hidden sub-directory, fails, with an error message to the user that doesn’t seem helpful. This error message simply complains that certain files and folders could not be found, that are supposed to exist remotely, from the Android device.

And so at first glance it might seem like an unsolvable problem. But as it happens, with this exact version of the Linux package, there is a fix, which I’ve been using for months. In the past I wanted to keep this patch to myself, out of fear that my readers might botch this delicate surgery. But I’ve had a change of heart, in that I want everybody to benefit from this app, even if they are using an outdated version of the Linux software. If the reader has the courage to perform this surgery, then the following is for you:

## Latest Android Update Breaks ‘kdeconnect’ on Debian Stretch (Already Resolved).

One of the apps which I have installed on my Android phone, is called ‘kdeconnect’, and I’ve blogged about it before. This is an app that allows a compatible Linux widget to sync certain data with the smart-phone.

(Screen-Shot from some earlier version of this app, which did not constrain the available directories.)

The version which I have installed on the Debian / Stretch computer I name ‘Phosphene’, is 1.0.3~bpo9+0 . I actually needed to patch this package, so that for the following few months, it was able to browse the file-system of my phone, specifically, directories which I authorized on the phone app, from my Linux computer.

Well the Android companion to this app has just received an update through Google Play. This update broke the ability of my Linux computer to mount the remote file system – i.e., to browse any directories on the phone.

(Update at 18h25 : )

But what seems to have happened is that two updates were pushed to my phone in rapid succession, the second of which put the Android app version to 1.12.9 . The reason for which I’m inferring this, is the fact that this remote mounting of the phone’s chosen directories works now, with no actual intervention from me:

The detail of this experience which puzzles me, is the thought that I had in fact been testing v1.12.9, when I first reported the app as broken…

However, this ‘broken’ result can also occur, just because of faulty communication between the two devices.

(Update 7/6/2019, 21h25 : )

## My system for switching between compilers needed an overhaul.

According to what I had written in earlier postings, I had co-installed a Debian Jessie / Security version of the GCC / CPP / C++ compiler system, which had version 4.9.2, alongside the official versions, which were 6.3, on the Debian / Stretch computer I name ‘Phosphene’. There was a problem in how I had done that. If next, the Package Maintainers had pushed through an update to their official compiler, the update would have broken my link groups – in a devastating way. And so what I needed to do was to rearrange those link-groups, to make them compatible with this scenario. The result is as follows:


dirk@Phosphene:~$su Password: root@Phosphene:/home/dirk# update-alternatives --config cc There are 2 choices for the alternative cc (providing /usr/bin/cc). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/gcc 20 auto mode 1 /usr/bin/gcc 20 manual mode 2 /usr/bin/gcc-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config cpp There are 2 choices for the alternative cpp (providing /lib/cpp). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/cpp 20 auto mode 1 /usr/bin/cpp 20 manual mode 2 /usr/bin/cpp-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config c++ There are 2 choices for the alternative c++ (providing /usr/bin/c++). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/g++ 20 auto mode 1 /usr/bin/g++ 20 manual mode 2 /usr/bin/g++-4.9 10 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# ls -l /usr/bin/gcc lrwxrwxrwx 1 root root 5 May 3 10:58 /usr/bin/gcc -> gcc-6 root@Phosphene:/home/dirk# ls -l /usr/bin/cpp lrwxrwxrwx 1 root root 5 May 3 11:01 /usr/bin/cpp -> cpp-6 root@Phosphene:/home/dirk# ls -l /usr/bin/g++ lrwxrwxrwx 1 root root 5 May 3 11:24 /usr/bin/g++ -> g++-6 root@Phosphene:/home/dirk# exit exit dirk@Phosphene:~$



Dirk Mittler