A folder named ~/.cache/kioexec/krun/13821_0/ already exists

2017-12-09 jj5 – TODO: document this on my blog…

On Debian GNU/Linux 9.1 (stretch) when I try to open an *.desktop (application/x-desktop) link in a browser I get:

A folder named ~/.cache/kioexec/krun/13821_0/ already exists.

Searching for:

A folder named kioexec krun already exists

turned up diddly squat.

I solved the issue (for me) by changing:

System Settings -> Personalization -> Applications -> Default Application s-> Web Browser


Open http and https URLs in an application based on the contents of the URL


Open http and https URLs in the following browser: firefox

Installing Subversion on Mac OS X with WebDAV support (serf library)

cd ~/Development/svn-install
wget http://prdownloads.sourceforge.net/scons/scons-2.3.4.tar.gz
wget http://mirror.ventraip.net.au/apache/apr/apr-1.5.1.tar.gz
wget http://mirror.ventraip.net.au/apache/apr/apr-util-1.5.4.tar.gz
wget http://mirror.ventraip.net.au/apache/subversion/subversion-1.8.10.tar.gz
tar xzf scons-2.3.4.tar.gz
tar xzf apr-1.5.1.tar.gz 
tar xzf apr-util-1.5.4.tar.gz
tar xzf subversion-1.8.10.tar.gz
cd scons-2.3.4
sudo python setup.py install
cd ../apr-1.5.1
./configure --prefix=/usr/local
sudo make install
cd ../apr-util-1.5.4
./configure --with-apr=/usr/local --prefix=/usr/local
sudo make install
cd ../subversion-1.8.10
sh get-deps.sh serf
cd serf
scons APR=/usr/local APU=/usr/local OPENSSL=/usr/local PREFIX=/usr/local
sudo scons PREFIX=/usr/local install
cd ..
./configure --with-openssl --with-serf=/usr/local --prefix=/usr/local
sudo make install

Nuff said!

Oh, wait… there’s a problem with misconfigured CA certificates…

cd ~/Development/svn-install
wget https://distfiles.macports.org/MacPorts/MacPorts-2.3.3-10.10-Yosemite.pkg

Run the MackPorts*.pkg…

xcode-select --install


sudo /opt/local/bin/port install curl-ca-bundle


sudo -s
cd /System/Library/OpenSSL/certs/
ln -s /opt/local/etc/openssl/cert.pem cert.pem
cd /usr/local/etc/openssl/certs
ln -s /opt/local/etc/openssl/cert.pem cert.pem


openssl s_client -connect www.progclub.org:443 -CApath /opt/local/etc/openssl/

Using MacPorts OpenSSL:

sudo port install openssl
cd ~/Development/svn-install/subversion-1.8.10/serf/
scons APR=/usr/local APU=/usr/local OPENSSL=/opt/local PREFIX=/usr/local
sudo scons PREFIX=/usr/local install


gnutls_handshake failed using git

Today I ran into this error:

jj5@mercy:~/public-git$ git push origin master
error: gnutls_handshake() failed: A TLS warning alert has been received. while accessing https://demo@demo.personalserver.com/public/git/info/refs 

The solution, of all things, was to add a ServerName spec into my Apache configuration file /etc/apache2/sites-enabled/default-ssl.conf, e.g.:

ServerName demo.personalserver.com

Bug fixed!!

HTTPS+SSLVerifyClient require in <Directory>+big POST = Apache error

I was configuring MediaWiki to allow uploads and was getting an error in the browser about the POST data being too large (“does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.”). I had a look in the Apache error log and found:

[Thu Feb 23 16:12:45 2012] [error] [client] request body exceeds m
aximum size (131072) for SSL buffer, referer: https://www.jj5.net/morpheus/Speci
[Thu Feb 23 16:12:45 2012] [error] [client] could not buffer messa
ge body to allow SSL renegotiation to proceed, referer: https://www.jj5.net/morp

So I did some research. I found this document, File upload size which suggested editing /etc/php5/apache2/php.ini which I did:

upload_max_filesize = 20M
post_max_size = 80M

That didn’t fix the problem though. I found Request entity too large which suggested checking my setting for LimitRequestBody, but that wasn’t the problem either.

Eventually I found Bug 491763 – HTTPS+SSLVerifyClient require in <Directory>+big POST = Apache error which suggested I needed to apply the SSLRenegBufferSize directive which I did like this:

  <Location /morpheus>
    SSLVerifyClient require
    SSLVerifyDepth 1
    SSLRenegBufferSize 20971520

And then after restarting Apache the problem was solved.