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:

Screenshot_20190615_181900

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:

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

Installing Snap under Debian

The traditional way of installing software under Linux, specifically under Debian, has been, to use a package manager which accesses global repositories of software, and sometimes, to use a graphical front-end to the same package manager.

Thus, under Debian the package-manager command-line to install <somepackage> would be:

apt-get install <somepackage>

But, if we have “Synaptic” installed, that is a graphical front-end for the same set of commands, that I’ve come to like and trust. If we do not have Synaptic installed but wish to, then the way to install it from the command-line would be:

apt-get install synaptic

But what has happened in the Linux world is that this method of installing packages has become ‘boring’. There exists software which is not listed in the package repositories, and which Synaptic will therefore also not find in response to explicit searches, but which users will want to install, simply due to the evolution of software. One reason for which this software is not listed could be, that it would be tedious for package maintainers to compile, but another could be, the fact that some software is proprietary in nature, or at least partially so, so that to include it in the open-source repositories may in some cases be illegal.

And so, even Linux users will sometimes seek other ways of installing specific software, which they already know exists. And another way to do so has traditionally been, to compile this additional software from source code. But, sometimes the out-of-tree software we wish to install needs to come in the form of binaries. A recent development in this field has been, the emergence of a software-management system called “Snapcraft“. It’s based on the ‘Snappy’ package manager, that was developed by Canonical.

I’m going to assume for the moment that the reader already understands the existence of security implications, in installing binaries from anywhere except the package manager, together with the official repositories, even when those binaries are to be sandboxed. And I’m not going to explain those in this posting.

One reason for which Snappy exists, is the fact that some of the more-traditional installation scripts, for out-of-tree binaries, needed to make arbitrary assumptions about the organization of the Linux computer, and there are many different versions of Linux, which eventually lead to incompatibilities with the binary software. Their developers have had to make assumptions about how the customer’s computer was configured, and those assumptions will eventually be wrong for some versions of Linux. Snappy can circumvent this limitation, or so its developers claim. Whether it truly can or not remains to be seen, as Snappy is still in its infancy as I’m writing this. It could be that I just jumped in with a fashion trend, which may turn out just to have been a fad, as seen several years or decades in the future.

But this posting will continue on the assumption that the reader has a Debian Linux computer, but that he wishes to install Snappy anyway. Snappy was designed more with Ubuntu in mind, but is also available for Debian Linux.

(Updated 6/15/2019, 14h20 … )

Continue reading Installing Snap under Debian

NixNote2 has been forked.

One of the apps which I like to use under Android, is the Evernote Web-clipper. But because I am not using Windows anymore, I no longer have the official Windows client application for this service. Yet, I have a paid-for Premium subscription to Evernote. Therefore, I am interested in synchronizing my clippings with my desktop computer, even though I’m using Linux.

One solution which exists for people like me, is the NixNote2 (Linux) application, which is essentially a clone of the Evernote client application. But before Linux users go ahead to install and use this program, there is a recent fact which they need to be aware of. Under Debian / Stretch, aka Debian 9, the version which we may install from the package manager, is currently only version 2.0~beta11-1. This version is badly broken, and trying to use it could lead to some confusion, about why it malfunctions.

The behaviour might already be familiar to some other, unfortunate Linux users: When we first authorize it to sync with our account, it stores its token but only syncs once. After that, attempts to sync fail, and, the (Qt5) System Tray Icon misbehaves badly.

From what I heard this version is broken because the package maintainer for it has failed to maintain the code properly. Maybe he has moved on to different projects? But if he has, the defective version should not really be in the repositories anymore. And so a different developer has come forward, who will allow people to download his up-to-date version, that seems to work fine. This up-to-date version is available as an Appimage.

Screenshot_20190611_183556

I suppose that a type of question may arise, as to why software like this needs to be maintained, or, why it stops working. And in this case, the best answer I can decipher is that Evernote allows third-party client programs to connect, but tightens the protocol with which any client – mainly their own – needs to communicate with their server, either to improve security, to add features, or both.

Situations like this can even lead to some feelings of persecution, which may be stronger in the manufacturers of third-party devices or the programmers of third-party client apps, than they need to be for users. But what might just be happening is the provider trying to improve their infrastructure, and perhaps also, being a bit sluggish in communicating changes they make to the protocol to independent developers and users.

What users need to know, is to start with a healthy client app, before searching for other answers as to why, perhaps, the sync is malfunctioning. ;-)

Screenshot_20190611_183651

 

Dirk

 

OpenCV Reinstalled on Computer Phosphene

One of the things I needed to do a few months ago, was a complete reinstall of software on a computer which was named ‘Phoenix’, but which had suffered from a hard-drive controller failure, so that it needed to be resurrected as the computer ‘Phosphene’. Both times that hardware had Debian / Stretch installed, even though the first time it was not an official Kanotix install. The second time it was.

When I need to reinstall the O/S, I also need to install much software again. And one piece of software which I’ve been focusing on somewhat in recent days, is “OpenCV“.

‘OpenCV’ is a library and a series of header files, and a set of Python modules, and a Java Interface, that specialize in Computer Vision, which could therefore be classified as a rudimentary AI, although it should be said that This form of AI is still of such a variety, that the computer is only performing remarkably complicated calculations, to be able to do things, which were not feasible only a few decades ago. It provides Image Recognition. Because of the way I am, I value having many computing resources installed, even if I rarely use them. OpenCV would be one such resource.

What tends to happen on Debian-based platforms, is that the version of OpenCV available from the package manager is a somewhat old version – in the case of Debian / Stretch, v2.4.9 – which is only important to install the library packages for, not the ‘-dev’ packages, and the former because the library packages are also dependencies of many other packages, which use OpenCV in the background, but not in any way that the user would want to write his own applications with.

What I additionally did, was to install v4.1 from the OpenCV Web-site, from source-code, and this seems like a good move because v4.1 is rumoured to be easier to write programs with, than v3.2 was, especially if the power-user does not want to end up shoulder-high in low-level code, to do many of the uninteresting parts of what his application needs to do, to be user-friendly.

But then, before writing our own applications with OpenCV, what we might also want is a demo program, that just shows users what the capabilities of this library and of this SDK are. And so the main program to do this with is called “OpenCV Demonstrator“. This could be a way to intrigue ourselves, as well to show off what our computers can do, maybe to friends?

 

Screenshot_20190610_082145

 

But here I ran into a bit of a snag. ‘OpenCV Demonstrator’ has only been compiled, by its author, as an application that uses OpenCV 3.2, and according to examination of my blog entries from before the reinstall, was compatible with v3.4. It’s not compatible with v4.1, even though v4.1 is more powerful. Whenever there is a major version update, let’s say from 3 to 4, applications built against one version will no longer run, when compiled against the next version. But I wanted that Demonstration Program. And so the following is what I did:

Continue reading OpenCV Reinstalled on Computer Phosphene