How to automount optical media on Debian Linux for Kodi – Reblogged from Ddumont’s blog


This problem has been bugging me for a while: how to setup my Kodi based home cinema to automatically mount an optical media ?

Turns out the solution is quite simple, now that Debian has switched for systemd. Just add the following line to /etc/fstab:

/dev/sr0 /media/bluray auto defaults,nofail,x-systemd.automount 0 2

continue reading …

Source: How to automount optical media on Debian Linux for Kodi

Debian is preparing the transition to FFmpeg!

Ending an era of shipping Libav as default the Debian Multimedia Team is working out the last details of switching to FFmpeg. If you would like to read more about the reasons please read the rationale behind the change on the dedicated wiki page. If you feel so be welcome to test the new ffmpeg packages or join the discussion starting here. (Warning, the thread is loooong!)


Hot upgrading Erlang applications using tools in Debian

Erlang lets you write applications supporting zero downtime by switching one live system to another running a different application version converting the application’s state on the fly to the new representation. Debian packages however can have only one installed version on a system which prevents using Erlang’s hot-upgrade feature easily.

Engineers at Yakaz (Jean-Sébastien Pédron) came up with a nice solution by creating separate directories for each application release and creating .deb packages for managing the transitions. I had to solve the same problem recently and found that the erlsvc Perl application they created needed a few patches to be usable with latest Erlang and other packages and with the changes it worked perfectly. Yakaz was not interested in accepting the patches and developing it further, but let me continue the maintenance. Please find the updated erlsvc application under my GitHub account and feel free to submit patches if you find something to fix in it.

I have also packaged erlsvc as an official Debian package and it is waiting in the NEW queue for being accepted. When it enters unstable you will have to make very little effort to make your applications hot-upgradeable on Debian!

update: The package has now been accepted to the archive. Thanks to the FTP Masters for their hard work!

Kodi from Debian

The well known XBMC Media Center has been renamed to Kodi with the 14.0 Helix release and following upstream’s decision the xbmc packages are renamed to kodi as well. Debian ships a slightly changed version of XBMC using the “XBMC from Debian” name and following that tradition ladies and gentlemen let me introduce you “Kodi from Debian”:

Kodi from Debian main screen

Kodi from Debian main screen

As of today Kodi from Debian uses the FFmpeg packages instead of the Libav ones which have been used by XBMC from Debian. The reason for the switch was upstream’s decision of dropping the Libav compatibility code and FFmpeg becoming available again packaged in Debian (thanks to Andreas Cadhalpun). It is worth noting that while upstream Kodi 14.0 downloads and builds FFmpeg 2.4.4 by default, Debian ships FFmpeg 2.5.1 already and FFmpeg under Kodi will be updated independently from Kodi thanks to the packaging mechanism.

The new kodi packages are uploaded to the NEW queue and are waiting for being accepted by the FTP Masters who are busy with preparing Jessie for the release (Many thanks to them for their hard work!), but in the meantime you can install kodi from

Happy recovery from the holidays! 🙂

update: I have updated the Kodi version to 14.2 in the xbmc-ffmpeg repository also updating FFmpeg to 2.6.1.
The packages can be used with Jessie, but unstable and experimental repositories also have to be enabled due to some dependencies missing from Jessie but present in unstable/experimental.

update 2: Dominique Dumont wrote a nice how-to about automounting optical media (CD/DVD) using Kodi on Debian.

update 3: Kodi is now available from jessie-backports, testing and unstable. Please use the packages from the official repositories instead of my temporary one which contains outdated packages and will be deleted.

XBMC (from Debian) running on MIPS CI20 dev board

XBMC on CI20 MIPS dev board

Imagination Tech kindly offered many developers (including me) a CI20 development board which let me play with XBMC on it a bit and patching it alive. The OpenGL GUI works smoothly, but video can’t be played due to crashes in FFmpeg/Libav/libva (See bug report here).
The patches needed  are sent to upstream and the latest Debian package already ships them.

Big part of the credits go to Cory Fields who created the first MIPS patches I found and updated for latest XBMC code. Thanks!

update:  Both Kodi 14.0 and XBMC 13.2 crash in which library is closed source thus I can’t debug it further.

update 2:  The crash is fixed in latest beta image from Imagination Tech which makes XBMC from Debian able to play videos using software rendering:

update 3: Kodi also runs with with the patches sent upstream:


update 4: Patches for Kodi have been merged!

Run Wireshark on Android using Lil’ Debi!

Running Wireshark for Android has been an dream for a long time. Now it became a reality!

Wireshark running on Android using Lil'Debi

Wireshark running on Android using Lil’Debi

You only need a rooted Android device with ~2GB free space, Internet connectivity and some patience to follow the steps below.

  1. Install Lil’ Debi from Google Play or F-Droid. Lil’Debi will install a Debian root file system in a loop device separately from the Android file system allowing us running Debian side-by-side to the Android apps.
  2. Start Lil’ Debi and create the Debian system with 2000 MB image size. We will need some space for Wireshark, the graphical interface Wireshark depends on and for the capture files.
  3. Start the newly created Debian system and log in to it. You will see the error message “bash: [: : integer expression expected”, but you can continue.
  4. Now run the following commands at the command line to install all the packages Wireshark will need:
    # some important directories are missing from the PATH by default
    export PATH=/sbin:/usr/sbin/:$PATH
    # we will start an X server later
    export DISPLAY=
    # install wireshark an a few things to make it nicer
    apt-get install openbox gnome-themes-standard tshark wireshark
    # gnome-settings-daemon depends on plenty of packages we don't need now,
    # but we need gnome-settings-daemon for the GNOME theme to be applied
    apt-get install --no-install-recommends gnome-settings-daemon
  5. To run graphical applications from the Debian chroot we need to set up an X server on Android because Android uses a different method for presenting the GUI. XServer XSDL is available from Google Play and from SourceForge. Install and start it. It will show the display it is serving which will most probably end with :0, so the DISPLAY environment variable we set before is correct. (If there is an other number after the “:”, fix your DISPLAY variable.)
  6. Start the openbox window manager, gnome-settings-daemon and finally wireshark in capturing mode:
    openbox &
    # if you would like to have bigger menu fonts skip starting gnome-settings-daemon
    gnome-settings-daemon &
    wireshark -k -i wlan0
  7. Switch to the X server to see wireshark starting up, close the warning dialogs start capturing traffic!

I tested the tests above using a Nexus 7 (Asus 2013 version) running CyanogenMod M7, thus root access was granted by default, Lil’ Debi 0.4.7, and XServer XSDL 1.11.14.

update: Lil’ Debi has apparently been removed from Play Store. 🙁

Beautiful Wireshark on OS X using Homebrew and GTK+3/Quartz

According to common wisdom GTK+ applications are not nice on OS X. They use XQuartz to draw widgets on the screen which is slower than native Quartz interface and the gray theme is not very appealing either. But does it have to stay this way? Could not GTK+ applications look more “native” on OS X?

They could! In six easy steps we can transform Wireshark to look way more elegant with the help of Homebrew, a package manager for OS X, GTK+3 the latest stable version of the toolkit and GNOME’s standard themes. (The steps are collected at the end of this post. The instructions assume no prior installation of brew packages. If you would like to remove all previously installed packages run “brew list | xargs brew uninstall”.)

Homebrew is a good alternative to installing software on OS X from source and Wireshark is already packaged there. Two commands let us start using it, but first we need to install XQuartz:

# install XQuartz from, sorry, it is a manual step
# and you also have to logout, then login to start using it
# install Homebrew
ruby -e "$(curl -fsSL"
# install Wireshark (and ccache to recompile stuff faster)
brew install ccache wireshark
brew uninstall wireshark
brew install --build-from-source wireshark --with-gtk+

Well, it works, but it is not exactly nice. The default install uses GTK+2 which is an older version of the toolkit.


Let’s try using GTK+3, which step needs some changes to Homebrew’s formulas

# remove packaged Wireshark
brew uninstall wireshark
# install hub which lets you experiment with other Homebrew branches
brew install hub
# Pull my repo until every commit gets accepted to Homebrew core
cd $(brew --repository)
hub pull
# build Wireshark from source, now using GTK+3
brew install --build-from-source wireshark --with-gtk+3

The widgets became slightly nicer, but we are far from being satisfied with that, right? The fonts still look very different from the fonts of other applications and we still use XQuartz. Note the big “X” in the lower right corner.


The bigger part of the changes were needed to enable building libraries without XQuartz support, and for the sake of simplicity let’s start over with Homebrew and compile Wireshark with GTK/Quartz

# start over: clean up everything installed by Homebrew
brew list | xargs brew uninstall

#install packages we don't have to recompile to use Quartz
brew install ccache d-bus fontconfig freetype gettext glib gmp icu4c libffi libpng libtasn1 libtiff pkg-config xz hicolor-icon-theme gsettings-desktop-schemas c-ares lua portaudio geoip gnutls libgcrypt atk pixman hub
# install XQuartz from
# Well, some builds will need the header files/libs, but you don't have to re-login
# and actually use XQuartz
#compile the rest of GTK+ 3 related libraries
brew install --build-from-source at-spi2-core at-spi2-atk cairo harfbuzz pango gtk+3 gtk+ librsvg gnome-themes-standard wireshark --without-x --without-x11 --with-gtk+3

The fonts became nicer, the shortcuts are shown like “^K” and we don’t see the big “X”. Probably the rendering of the widgets became faster as well, but I can’t tell. We successfully switched to Quartz!


.. But Wireshark is still gray, like before. It is no surprise, since we installed GNOME themes, but haven’t enabled them yet. Let’s finish the polish:

mkdir -p ~/.config/gtk-3.0
echo "[Settings]" > ~/.config/gtk-3.0/settings.ini
echo "gtk-theme-name = Adwaita" >> ~/.config/gtk-3.0/settings.ini

Wireshark-gtk3-quartz-adwaitaVoilà! GTK+ applications are considered to be ugly on OS X because no one installs the standard themes! Using XQuartz as a GTK+ backend also did not help, but I think the themes brought the biggest difference.

Enjoy the new look and check other applications as well if they could be improved!

These are the minimal steps collected to get nice GTK+3 applications and Wireshark ready for being copy-pasted:

# install Homebrew, you will also need XCode with Command Line Tools installed
ruby -e "$(curl -fsSL"

# install packages we don't have to recompile to use Quartz
brew install ccache d-bus fontconfig freetype gettext glib gmp icu4c libffi libpng libtasn1 libtiff pkg-config xz hicolor-icon-theme gsettings-desktop-schemas c-ares lua portaudio geoip gnutls libgcrypt atk pixman
# install XQuartz from
# Well, some builds will need the header files/libs, but you don't have to re-login
# and actually use XQuartz

# this may be needed by gtk+3 install (at least on my system with a previous installation)
brew link --overwrite gsettings-desktop-schemas

# compile the rest of GTK+ 3 related libraries
brew install --build-from-source at-spi2-core at-spi2-atk cairo harfbuzz pango gtk+3 gtk+ librsvg gnome-icon-theme wireshark --without-x --without-x11 --with-gtk+3

Thanks to Seb Shader’s post for describing the process of installing GTK+3/Quartz on OS X from source. I used most of his steps in updating the Homebrew formulas.

Update: Wireshark, and other GTK+ based programs could be beautiful on Windows as well, but Tarnyko, who packaged the latest GTK+3 Windows bundles needs help due to lack of time he can dedicate to the project. Please help him if you would like to see nicer GTK+ on Windows!

Update 2: With the release of GTK+ 3.14 Adwaita became the default theme thus installing and setting up Adwaita from gnome-themes-standard step can be omitted. The minimal steps collected at the end of the instructions are updated to reflect that, while the rest of the post documents the original steps creating a nicer looking Wireshark using GTK+ 3.12.

Update 3: With all the related changes merged to Homebrew’s master there is no need to use my repository anymore following the minimal steps.

I Can Hear Music again (thanks to forked-daapd/Debian)

When I started looking for a lightweight solution of serving a music library over LAN I did not expect so many complications. I expected it not to be a unique need to have something running on a SheevaPlug straight from the Debian repository. Apparently it kind of was.

Debian used to have mt-daapd (popcon: 165), but now it is available from oldstable only and upstream is dead. There is tangerine (popcon: 98) with its Mono dependencies and GUI which seemed to me overkill and more like a demo of a networked application written in Mono than a music library server. The most promising candidate was forked-daapd (popcon: 220) but it was far from being a true winner.

First, it had a series of dead upstreams. At the beginning it was forked from mt-daapd (hence the name) by Julien Blache who also served as the prior Debian maintainer. Then the code base was forked and converted to use Grand Central Dispatch. Then the GCD fork died off slowly as well a few years ago. When I found the package it had been unmaintained for a few years and was based on the GCD branch which prevented building it on many architectures and the server itself was crashing or quitting occasionally.

Luckily there still existed a fork thanks to Espen Jürgensen which was well maintained and could serve as a way out but examining it closely it turned out that it had switched to libevent from GCD but to a version (1.4) which is present only in oldstable! And some say Debian’s software versions are ancient ;-). Moreover it was not simply libevent 1.4-based, but it included some heavily patched parts of it.

Espen also liked the idea of packaging his version in Debian and we extracted the patches to libevent and slowly got them accepted to libevent’s master.

Forked-daapd’s master works best with libevent 2.1.4-alpha, but thanks to Espen the development branch now also works with libevent 2.0.x giving up some performance and a little feature.

This was a long journey, but finally Espen’s forked-daapd became ready for being used as a new upstream of the Debian package thus please welcome 20.0+git20140530+gc740e6e-1, the first version of forked-daapd building on all architectures for a very long time and a prime candidate for being the music library server in Jessie (and wheezy-backports, soon)!

Testing, bug reports are always welcome!

From the package description:

 forked-daapd is an iTunes-compatible media server, originally intended
 as a rewrite of Firefly Media Server (also known as mt-daapd).

 It supports a wide range of audio formats, can stream video to iTunes,
 FrontRow and other compatible clients, has support for Apple's Remote
 iPhone/iPod application and can stream music to AirTunes devices like
 the AirPort Express.
 It also features RSP support for Roku's SoundBridge devices.

 Built-in, on-the-fly decoding support enables serving popular free music
 formats like FLAC, Ogg Vorbis or Musepack to those clients that do not
 otherwise support them.

update: Forked-daapd package has been migrated to testing and is also available from wheezy-backports.

XBMC 13.0 Gotham entered Debian

XBMC v13.0 Gotham

XBMC v13.0 Gotham

Thanks to the great work of the XBMC Team XBMC 13.0 Gotham has been released last Sunday and now “XBMC from Debian” can be downloaded from experimental to Jessie and Sid systems.

It will take some time to enter unstable since it is blocked by the Libav 10 transition, but that will happen, too, eventually.

I have also set up a separate repository at based on the Debian packages in main but using XBMC’s internal copy of FFmpeg because I received several request asking for this variant. The packages there can be used on Wheezy (stable), Jessie (testing) and Sid (unstable) but are not part of Debian.

Update 1: For the interested parties the XBMC 13 Libav compatibility patches are available from a git branch in the packaging repository.

Update 2: Gotham and compatible PVR addons have migrated to Jessie (testing) and have also been uploaded to wheezy-backports. This makes Frodo and compatible PVR addons not installable from the usual official Debian repositories but if you would like to still use Frodo you can install it from Just add the following lines to your sources.list:

deb wheezy-backports main
deb-src wheezy-backports main

It may be necessary to ignore the Valid-Until header within Release files, in order to prevent apt from disregarding snapshot entries (“Release file expired”). Use aptitude -o Acquire::Check-Valid-Until=false update or apt-get -o Acquire::Check-Valid-Until=false update for this purpose. (from

Update 3: became available through HTTPS only thus sources.list have to be updated as well. You may need to install apt-transport-https package to access the repositories there.

Proposing amd64-hardened architecture for Debian

Facing last week’s Heartbleed bug the need for improving the security of our systems became more apparent than usually. In Debian there are widely used methods for Hardening packages at build time and guidelines for improving the default installations’ security.

Employing such methods usually come at an expense, for example slower code execution of binaries due to additional checks or additional configuration steps when setting up a system. Balancing between usability and security Debian chose an approach which would satisfy the most users by using C/C++ features which only slightly decrease execution speed of built binaries and by using reasonable defaults in package installations.

All the architectures supported by  Debian aims using the same methods for enhancing security but it does not have to stay the same way. Amd64 is the most widely used architecture of Debian according to popcon and amd64 hardware comes with powerful CPU-s. I think there would be a significant amount of people (being one of them :-)) who would happily use a version of Debian with more security features enabled by default sacrificing some CPU power and installing and setting up additional packages.

My proposal for serving those security-focused users is introducing a new architecture targeting amd64 hardware, but with more security related C/C++ features turned on for every package (currently hardening has to be enabled by the maintainers in some way) through compiler flags as a start.

Introducing the new architecture would also let package maintainers enabling additional dependencies and build rules selectively for the new architecture improving the security further. On the users’ side the advantage of having a separate security enhanced architecture instead of a Debian derivative is the potential of installing a set of security enhanced packages using multiarch. You could have a fast amd64 installation as a base and run Apache or any other sensitive server from the amd64-hardened packages!

I have sent the proposal for discussion to debian-dev, too. Please join the discussion there or leave a comment here.

Update: Many of you wondered if amd64-hardened could have prevented the exploitation of the Heartbleed vulnerability. I have posted a proof of concept to show that using -fsanitize=address and disabling custom freelist would have protected systems against stealing data using the exploits.

Disabling the custom freelist-like solutions and enabling-fsanitize=address would be part of amd64-hardened to make memory protection techniques work effectively thus I think if we had this architecture ready at the beginning of April, it would have been immune to Heartbleed.