I have managed to make OpenShot more stable under Linux.

In a previous blog posting, I had reported that OpenShot was dangerously unstable, and even unstable under its native Linux. I’m basing this on OpenShot 1.4.3, installed from the package manager under Debian / Jessie, with a KDE 4.14 desktop.

This Was The Posting.

It turns out that there can be ways to overcome this instability.

Firstly, I have changed the Output Mode, with which this application renders its previews, from “sdl” to “sdl_preview“.

More importantly there seems to be a detail in its practical use, which I was unaware of before. Earlier, I had imported a captured .OGG / .OGV file into its video clip resources. In itself this presents a problem, in that certain .OGV Theora files, especially ones produced by screen capture, are known to give this program problems. This can be anticipated, by the video clips in question having blank thumbnails.

On the first try, I told OpenShot to play the video clip anyway in its preview window. The progress bar went from the beginning to the end at the correct speed, but once it reached the end, the application became unresponsive and KDE had to shut it down forcibly. This was with the Output Mode still set to “sdl“.

Apparently, once OpenShot has crashed, it has saved corrupted information into the folder ‘~/.openshot‘ . Had I known this, I could have deleted that folder completely before trying out the application again. But instead I tried to use OpenShot again right away, sometimes telling it to play the .MP4 version of the same video or other clips.

That was when my desktop froze. The X-server did not crash, but no movement or mouse input could be given anywhere on the desktop. The actual mouse pointer was still moving in response to the mouse however, and it was also changing from the usual pointer, to the special pointer when hovering over the preview panel. I needed to use <Ctrl>+<Alt>+F1 in order to open a Virtual Terminal in text mode, and then to ‘kill -9‘ the actual application pinning the other virtual terminal.

My setups typically allow for multiple sessions to be logged in at once, and Virtual Terminals 1-6 are text-based, while the graphical ones start from Virtual Terminal 7. So once the offending processes were killed, I was able to <Ctrl>+<Alt>+F7 back into the graphical session, which was not corrupted.

But the way I finally broke this spell with OpenShot, was to delete the directory ‘~/.openshot‘ and its corrupted contents. After that, the application was able to play the .MP4 video clips fine, which also had thumbnails that corresponded to their content.

Also, if I decide that a user-space configuration is needed to ensure the stability of the system, I copy the contents of the configuration folder for one application, into ‘/etc/skel‘, from where a skeleton of starting files is copied, every time the home directory of a new user is set up. That way, any newly-installed user will inherit my recommended settings.

In order to do that, after I deleted the config folder once, I only launch the application briefly, and make my configuration settings, before exiting the application again immediately. At that point I feel that the config folder is in its correct state, to be copied to ‘/etc/skel‘ .

There are certain purposes, which OpenShot may be better able to suit than alternatives, simply because OpenShot has more features.

Dirk

 

Possible Solution to ‘Dropbox Missing Systray Icon’ under KDE

Just yesterday I installed the proprietary version of “Dropbox” on my ‘Debian / Jessie’ computer named ‘Phoenix’. I had the extra HD space to spare, and also had an existing Dropbox account to link to. But what I soon noticed, was the fact that I was suffering from the same problem many other users of ‘KDE 4′ were having with the newest Dropbox for Linux.

It seems that the Linux versions of Dropbox are tuned to work best under ‘Ubuntu’, not ‘Debian’. And in General, Ubuntu uses either ‘GNOME’ or ‘Unity’ as its desktop manager, which leaves many KDE users having to use the official Command Line Interface for Dropbox.

Mind you, this CLI is not bad as those go, but missing the System Tray Icon was annoying me. I had to install ‘libappindicator…’ as well as ‘python-appindicator’ from the package manager, and even after having done that, and after having restarted Dropbox using the CLI, the systray icon did not appear for me, because in recent Dropbox versions, only the ‘Nautilus’ support is included. Nautilus is the Ubuntu / GNOME counterpart, for what ‘Dolphin’ does under KDE. Luckily, there is an open-source Dolphin plugins package named

‘kdesdk-dolphin-plugins’

But that package assumes we already have Dropbox installed, and does not affect the system tray.

Further, I was disappointed by the fact that most of the other complaints I could Google involved KDE 5, while I needed to solve this problem with KDE 4.

And so after doing some more reading, I wrote the following script:

(Edit 03/31/2016 : ) I would like to thank Darwin Silva, who suggested a solution below, which works better for me, than the solution which I had first posted. Specifically, the solution by Mr. Silva allows Dropbox to animate the icon correctly, to show its status. I apologize for taking so long to test Mr. Silva’s solution, but often have limited time to go after all the things I should be doing on my own computers:

 


#!/bin/bash
# "Restart Dropbox.sh"

# Allow Dropbox 3.14.7 to show a system-tray icon.
# Works under KDE 4.14...
# Only drawback: Icon has generic page as image.
# Systray Icon Context Menu fully functional.

#DROPBOX_USE_LIBAPPINDICATOR=1
#XDG_CURRENT_DESKTOP=Unity

dropbox stop

sleep 30

dbus-launch dropbox start

This seems to have done the trick for me. But be warned: This will serve us at best, Until the Next Reboot. Possibly, this script may need to be run more often. There is a workaround which fully automates that problem, but that workaround was not worth my while.

It may be possible to edit

~/.config/autostart/dropbox.desktop

But doing so is pointless, because Dropbox will overwrite that file, every time it updates itself…

Dirk

 

How I typically Solve my Kleopatra Start-Up Delay Problem

Both under Linux and under Windows, I use “Kleopatra”, which is a GUI for the ‘GnuPG’ system – the “GNU Privacy Guard”. In case the reader does not know, GnuPG or ‘GPG’ is one software alternative for providing ‘Public Key Cryptography’, which can be used in practice to sign and/or encrypt emails, as well as to validate digital signatures made by other people’s computers.

Using GPG does not strictly require that we use Kleopatra, because there exists the capability which some power-users have, to use GPG from the command-line, and Kleopatra is a distinctly KDE-based front-end, even though there exist Windows ports of it.

One problem which I eventually run in to, and which has been reported elsewhere on the Internet, is that at first after installation, Kleopatra seems to run fine, but that after some point in time we encounter a strange delay, when we start up this program, which can last for several minutes or even longer, during which the program does not respond properly to user commands. Our GPG installation does not seem to be compromised.

In my case, this seems to take place entirely, because Kleopatra has been instructed to check the revocation status of some certificates, but no ‘OCSP Server’ has been specified in its settings. According to some other reports on the Web, this is a problem specific to “CACert” certificates, and in my case also, the problem seems to set in, after I’ve added a CACert certificate to my key-ring. Yet, AFAIK, this problem could just as easily occur after we’ve added other certificates.

The way I eventually solve this problem – on every computer I own – is to open Kleopatra somehow, and then to go into Settings -> Configure Kleopatra -> S/MIME Validation , and then to look at the field which says “OCSP responder URL”. By default, this field will be blank.

Since in my case the problem starts after I’ve added my CACert certificate, I actually add the OCSP Server which is provided by CACert there, which is currently “http://ocsp.cacert.org/”. After that, I find that when I open Kleopatra, a narrow and subtle progress-bar in the lower right of the application window, sweeps to completion within one second, and the program opens fine.

I need to explain why this solution works for me, so that anybody who may be having the same problem, but not with a CACert certificate, can also solve this problem.

Certificates which are not self-signed, are signed by a ‘Certificate Authority’, such as CACert. When Kleopatra starts, one of the functions which it automatically performs is to check its certificates against a ‘Revocation List’, in case the Certificate Authority has decided to revoke it.

The actual certificate which I received from CACert, has the detail encoded into its plain-text data, that its revocation status must always be checked. But what I’ve found happens with Kleopatra specifically, is that if no OCSP Server has been specified, instead of somehow recognizing the fact that it cannot check the revocation status, this program goes into some type of infinite loop, never actually connecting to any server, but also never seeming to exit this state.

I choose to put this OCSP, because in my case, I know that it is the CACert certificate which has this need set with a high priority. It should be possible to put some other OCSP Server into the same field, because ultimately they should all be synchronized. But finally, the OCSP Server provided by the same Certificate Authority, also provides the fastest response time, for validating its own certificates.

As I see it, there was a problem in priorities somewhere, in programming this application. There was the bureaucratic priority, which states that the status of this certificate must always be checked. but then there was also the programming priority, which states that an attempt to connect to a server, without any specification of which server, will lead to some sort of malfunction eventually. And between these two, the bureaucratic priority won out.

There are some people on the Web who choose to solve this problem, by simply deactivating the feature, of online revocation checking. This can be done within the same settings tab, by unchecking the first check-box in that tab. This check-box is located directly before the setting, to “Check certificate validity every Hour” (on my setup, with a drop-down window set to “hour”). I prefer to let my software do everything it’s supposed to do, including to check the revocation status of my certificates. And the way to do the latter is to specify an OCSP Server. The fact that this problem can apparently be solved both ways, affirms the quality of the programming.

Dirk

 

How to Set Up Unattended Upgrades under Linux

I have a Debian / Jessie Linux system, with KDE 4 as my desktop manager. I have set up unattended upgrades on this machine, and would like to share with my community, the best way to do so.

Even though KDE possesses a feature called “Apper”, I do not recommend that we use this in order to perform unattended upgrades. The reason has to do with how Apper fails to deal with authentication properly.

In preparation, I would recommend that people install the package

apt-get install apt-listbugs

What this package will do is to query the Debian bug lists for any package, prior to upgrading or installing it. If the known bug-level exceeds a certain threshold, ‘apt-listbugs’ will ask the user for confirmation interactively, before installing the package. This inserts a hook into the package installation routine, which will also be invoked by unattended upgrades.

apt-listbugs is to be configured in the file

/etc/apt/apt.conf.d/10apt-listbugs

The critical line here is the one that reads

AptListbugs::Severities “critical,grave,serious”;

As the severity level which should be stopped. For a list of available severity levels, read ‘man apt-listbugs’. I found that the default was adequate. If the severity level is set too low, this mechanism will be triggered too often, but if it allows bugs to be installed which are too severe, the automated upgrades will do so.

I have not spent time pondering on how to straighten out an apt-get cache, if the apt-listbugs mechanism was triggered by a batch operation, but suspect that doing so would be easier, than to deal with installed, severe bugs. I.e., this mechanism has been triggered on my machine, only by manual installation of packages. I keep it as a precaution, that will also work with ‘unattended-upgrades’.

Finally, we can install

apt-get install unattended-upgrades

This package is first to be enabled in this file

/usr/share/unattended-upgrades/20auto-upgrades

And then configured in this file

/etc/apt/apt.conf.d/50unattended-upgrades

It is important that this package not be left at its default configuration! Please read each entry in this file, and consider what settings are appropriate. Mainly, the bundled blacklist is not adequate. Further, while to have upgrades installed may be fine, to allow your system to reboot afterward might not be fine.

And one reason for this could be, that we have a desktop manager running, which will not end the session cleanly, if the system command ‘/sbin/reboot’ is simply given. And ‘unattended-upgrades’ will use this command, in complete disregard for what desktop manager is being used.

Therefore, all packages should be identified, which when upgraded will also require a reboot, such as

Kernel Images

Kernel Header Files

Graphics Drivers

etc., etc., etc.. And then having forbidden those, the automatic reboot feature should, in my opinion, be disabled as well.

Under KDE 4, Apper will next show me which packages have not been upgraded yet, so that I may do so through Apper if I like, at which point I can manage the procedure as well. And I expect that Apper will also show me any dialogs which ‘apt-listbugs’ might display.

This system has been working splendidly for me, since June 2, 2015. I have no complaints.

Dirk

(Edit 03/14/2016 : ) Apparently, there was a crucial configuration step, which I forgot to mention, because I had forgotten setting it up. It is necessary to create a configuration file within ‘/etc/apt/apt.conf.d‘ . This config file may be named like so: ‘02periodic‘ . In my case, this file actually enables the service with the following content:


// Enable automatic upgrades of security packages

APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";