## I now have Linux installed on my Samsung Galaxy Tab S.

A fact which I had lamented about, was that my Samsung Galaxy Tab S, First Generation – Android tablet – had essentially crashed. Its behavior had gotten so unstable as to make it unusable.

What this also did – given that I have a working Pixel C – was make the software / firmware -installation on the Tab S expendable, which meant that as soon as I was over the loss, I found myself willing to experiment with it.

So I did a factory reset, which made it stable again, at the expense of deleting all my user-data and separately-installed apps from Google Play. Essentially, the tablet had crashed while I was doing a routine update of apps, for which reason the FS corruption was limited to the ‘/sdcard’ partition, where user-installed apps are stored, as well as perhaps, to the ‘/data’ partition, where application data is stored. The factory reset empties those, and, because no system software update was taking place at the time of the crash, the ‘/system’ and ‘/boot’ partitions probably did not suffer from any corruption.

Then, I installed Linux on that tablet, using the Google Play store app named “GNURoot“, as well as using the Google Play store app named “XSDL“. When we install Linux on Android-capable hardware, we need to have a working Android system on that as well, because only the Android software can really provide the display drivers, and the I/O.

XSDL is an Android app which emulates a Linux X-server, which Linux sessions could connect to, as long as the Linux sessions can be persuaded not to try launching their own X-server instance, which their packages tend to depend on.

GNURoot is an app for Android 6+ that allows Debian / Jessie packages to be installed directly to the Android File System, and which runs those packages as though it was Linux. Remarkably, it does not require the device be rooted. It also uses the Android kernel. With the correct packages installed, it’s possible to get a proper desktop-session going between ‘GNURoot’ and ‘XSDL’. But the process is not user-friendly.

At first I had tried to install a system of ~400 packages, that provide ‘XFCE’, only to find that this desktop-manager could not connect to the ‘XSDL’, X-server, at least in any way I could get working. But then I tried uninstalling ‘GNURoot’, reinstalling ‘GNURoot’, and then installing the packages for ‘LXDE’, which is a lightweight, yet better desktop manager than the older XFCE would have been. This time, doing so required I patiently install ~600 packages.

Apparently, LXDE could be told to connect to an ‘XSDL’ instance quite well, and I obtained a working desktop-session. I also installed “GIMP” and “Blender”, which both ran fine – even on my Android tablet !

There was one caveat to using this configuration however, which is that I absolutely needed to connect an external, Bluetooth mouse, as well as an external Keyboard. Apparently, the ability of ‘XSDL’ to provide virtual replacements for those, just wasn’t up to snuff.

(Updated 8/31/2019, 12h10 … )

## How To Burn Blu-ray Movies using Linux – via the GUI

One project which I had half-installed on my laptop named ‘Klystron’ some time ago, but which was not working, was software that would make the task straightforward to carry out, to burn Blu-ray movies from a Linux computer. Because I finally wanted to get that working, I spent time on this in-depth today.

One fact which many people understand, but few people know how to manage, is that Blu-ray movies are not supposed to be burned using the ISO9660 File-System, nor, with the .ISO-Files typically associated with that FS, that store its images. Technically, Blu-ray movies are supposed to be burned using a File-System called ‘UDF’, and version 2.50 of that preferably. Under certain circumstances, v2.01 of UDF may have to suffice, since Linux support for v2.50 is still lagging.

(Edit 10/19/2017 :

I suppose that one detail which I should have included all along, is that I was doing this on a Debian / Jessie system, which is also known as Debian 8. This is also known as the ‘oldstable’ version of Debian now, just because of technological progress. Therefore, Debian 8 was unable to do certain things, which Debian 9 can do out-of-the-box.

I will explain below, why The patch which I described in this posting, should not be undertaken on a Debian / Stretch system, which is also known as Debian 9, and which would be the up-to-date version of Debian as I’m writing this. )

I will spare the reader a lengthy account of what did not work. In order for this to work, I needed to have the Debian Multimedia Repository installed in my /etc/apt/sources.list , which should be straightforward for other people to duplicate. And my main purpose in having this repository, was to get the package ‘tsmuxergui’, version 2.6.11 . In addition, I was working with ‘K3b’ , v2.0.2 .

‘tsmuxergui’ is a GUI-front-end for ‘tsMuxer’, which is a program that can be used to set up Chapters and other playback details, as well as the 1920×1080, H.264-compressed video files of course, that are supposed to make up the program on the final Blu-ray.

As my burner, I used the external ‘Pioneer BDR-XD05′, that connects via USB 3.

There is one additional component which I needed, before K3b was willing and able to burn the UDF File System required, which it is not able to do out-of-the-box:

An out-of-tree version of ‘cdrecord’ , v3.02a7

According to its authors, the versions of cdrecord that have been placed in the standard repositories belongs to ‘cdrkit’, not ‘cdrtools’, and cdrkit fails to provide the back-end, which K3b would need to burn UDF. Yet, to try to perform a binary install of the out-of-tree version, would have been very dangerous to my system. So what I did, and what I would urge other people to do, is to use one of the source-code (tarballs) from above.

First, if the reader has ‘wodim’ installed from the package-manager, I would recommend uninstalling that, just to make sure that package-version-binaries are not overwritten by the out-of-tree versions. Then, I used the above source-code, to custom-compile ‘cdrtools’.

(Edit 10/19/2017 :

If the reader is using Debian / Stretch. aka Debian 9, then the above precaution should fail. The reason for this is the fact, that under Debian / Stretch, K3b depends on ‘wodim’. Therefore, telling the package-manager to uninstall ‘wodim’, will most probably also cause the uninstallation of ‘K3b’.

Now, I can think of several reasons for which Debian Maintainers might have made K3b to depend on ‘wodim’ in Debian Stretch. One possibility, is that they might just not like this patch being applied.

But it seems to be confirmed to me – according to this test – that under Debian / Stretch, K3b is able to burn UDF / Blu-ray File-Systems out-of-the-box. And what that would mean is that to apply this patch is neither required nor desired. )

The nice feature about this version, is that it does not even install itself to ‘/usr/local/bin’. Instead, it installs its binaries to ‘/opt/schily/bin’ , when we finally give the command ‘make install’ with root privileges, so that the ultimate risk of messing up the system is small.

(Updated 10/23/2017 : )

## Misidentified Problem, Was: Latest ‘libgcrypt’ Update breaks ‘Enigmail’.

This morning, an update installed itself on my Linux computer ‘Phoenix’, that brought the version of my ‘libgcrypt‘ libraries to ‘1.6.3-2+deb8u3‘. This is under Debian / Jessie, a version of Linux. These libraries are supposed to give access to GnuPG encryption capabilities, to certain applications.

Within my ‘Thunderbird’ email client, I have an add-on installed from the package manager, called ‘Enigmail’ (version ‘2:1.8.2-4~deb8u1‘), which gives a full suite of encryption capabilities to my email.

The latest ‘libgcrypt‘ update has broken Enigmail, which was working fine before today.

More specifically, it is no longer possible to encrypt an email to oneself. Being able to do so, is essential for two purposes:

1. When we send an encrypted email to the public key of a contact, we are also asking the software to encrypt the same email to ourselves,
2. The way we may sometimes configure our Drafts folder, is to encrypt any Draft emails saved there, so that we need to enter the passphrase to unlock our Private Key, before we can reopen our Saved, Draft emails. This is a nifty capability, to secure the emails on our hard-drive, before we’ve made the decision to Send them.

(Edit : )

I have identified the true cause of my problem. In order to make this explanation more clear, I should also add that I’ve recently revoked some keys, and created a new, main email-key.

There exists a configuration file for GnuPG, which under Linux systems is stored at:

~/.gnupg/gpg.conf

What can happen is that settings in this file, override whatever settings we choose in our GUI-application, such as with Enigmail, in Thunderbird. More specifically, I had entries which went something like this:


default-key  586A6C0052A087C0
###+++--- GPGConf ---+++###
utf8-strings
encrypt-to 586A6C0052A087C0
keyserver hkp://pool.sks-keyservers.net
###+++--- GPGConf ---+++### Tue 16 Aug 2016 01:42:05 PM EDT
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.



The problem was, that the encrypt-to entry did not at first match my default-key entry, and referred to an old, revoked key. The encrypt-to entry has as effect, that GnuPG will always try to encrypt any messages that are meant for use with hybrid encryption, also to the specified key.

I edited this file manually, to make the two entries equal. I suppose that another way to solve this problem could have been, just to remove the encrypt-to entry…

The reader might wonder, by what sort of black magic that setting got into the configuration file, and, It’s usually not advised for users to edit this file directly, with a text-editor