UPDATE: There is a mailing list dedicated to kamion development at https://lists.sourceforge.net/lists/listinfo/kamion2-devel if you want to join the discussions…

Unfortunately, it is not joyful to work on the Kamion anymore. Mainly because of the lack of feedback from the developers community… read on:

For those who [still] do not know what Kamion is, here’s a definition from the webpage:

Simple description: Kamion is a user-friendly user state migration and backup tool created for KDE 4. Meaning - it allows even the most inexperienced user to transfer program related data such as e-mail messages, IM program history as well as the configuration of those programs from one computer to another. It can be used for backup purposes too.

The name Kamion means “The Truck” (see the logo) in my mother tongue (Serbian language).

Longer description: Kamion is a project consisted of the library named libKamion, graphical user interface for QT4/KDE4, and a few console tools. This organization is similar to the one of the Debian’s APT (Advanced Packaging Tool).

The library manages the database about the location of the application data (such as e-mail messages from KMail of Thunderbird…) for each supported application; and creates/restores the Kamion archives.

The GUI represents that database (list of applications and their resources) in a user-friendly manner allowing easy creation and restoration of the data. For those that do not have the ability to run the GUI, there are console based tools that offer the same functions as the GUI but without the user-friendliness.

Things that are finished:

  • libKamion - in working state
  • KDE4 GUI - in working state
  • console tools - broken
  • Gnome GUI - not started

Things that need to be worked on

  • Program support - I have almost no marketing abilities and no will to do the marketing. Kamion itself can not know what files to archive for a specific application. The application developers need to provide Kamion XML data files. I tried to push this format to the FreeDesktop but received no feedback whatsoever (although information needed by Kamion could be used for automatic creating of AppArmor/SELinux policies as well, and possibly for more things that I can not foresee at the moment). This is the main thing that needs to be done.
  • I18n support in the library - the application’s resources are not supported to have internationalized names. It could be done as a part of the GUI, or as a part of the library
  • mature and move from playground

I will gladly help anyone willing to take this task - explain the program and library architecture, explain the kamion archive format, application data XML file format…

If you’re willing to take on the job, put your e-mail address in the comment (in bla AT bla DOT bla format, or similar)


You can support my work on , or you can get my book Functional Programming in C++ at if you're into that sort of thing.