Want to test the phonon-vlc backend? Here you go :)


, , , , , ,

As some of you might have read in Mark Kretschmann’s blog, we now have a fairly good phonon-vlc backend that already works better in many ways than other available backends. It is still in alpha stage, but we would love to have testers give it a try.

The instructions below are for a Kubuntu or Debian system, I did the installation on the latest Kubuntu 10.04 beta checkout as of Saturday, April 4th. I will give some additional commands for other distributions where those are needed.

DISCLAIMER: Please do not install this backend if you are not comfortable with alpha code and willing to test and report bugs. We currently do not give support for it. We also strongly suggest you test this with Amarok from git, since there were quite some changes applied to the Amarok code, too. See also the KDE git tutorial for those not familiar with it.

The requirements are the following:

I assume you have the environment variables set as suggested in part 3 of the above mentioned HowTo for Amarok from git. We still need to add some more lines to make sure we get a proper debug output for the phonon-vlc backend:

Add the following lines to your $HOME/.bashrc:


1. Install the latest VLC version

I haven’t found out how to build libvlc as a standalone library, so I did build VLC 1.1 pre. This will drag in quite some code, but you will get a brand new VLC version as a bonus 🙂 Make sure you do indeed use VLC 1.1, it doesn’t work with the current 1.0.5 on Lucid.

You can find the source code here: http://git.videolan.org/vlc.git. Since I would like to use the new VLC by default, I did a system-wide installation, but the careful amongst you can do a local installation. The steps are the following:

use a local vlc directory, I use $HOME/kde/src/
git clone git://git.videolan.org/vlc.git
cd vlc

Now I am somewhat lazy, so I used the very handy build-dep command to find all the necessary dependencies for VLC. You can do this by activating the source repositories in your /etc/apt/sources.list, then type the following command:

sudo apt-get build-dep vlc

For OpenSuSE users, this would be:

sudo zypper si -d vlc

This will bring in almost all necessary dependencies, but the following did not show up, so I had to install those afterwards:




To build VLC, you will also need the following packages:



OK, lets build it then:

./configure --prefix=/usr

don’t forget to change this prefix for a local installation, and of course do not run make install with sudo rights below.

make -j3 && sudo make install

There you are, you have a brand new VLC! For those using a local installation, don’t forget to remove the distro packages to avoid any conflicts.

2. Build the phonon-vlc backend

The current code is located on Gitorious. Keep in mind that this is still very much work in progress, so there will be changes to the code almost daily. Below is the suggestion for a local build:

Again, use a new repository for this code, I suggest $HOME/kde/src/ as usual:

git clone git://gitorious.org/phonon/phonon-vlc.git
cd phonon-vlc
mkdir build
cd build

Everything is read to build now:

cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde/ -DCMAKE_INCLUDE_PATH=$HOME/kde/include/ -DCMAKE_LIBRARY_PATH=$HOME/kde/lib/ -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon-vlc/

all in one line, of course, don’t forget to change the -DCMAKE_INSTALL_PREFIX for a non local installation.

make -j3 && make install
the same warning applies for a non local build, do use sudo make install

We are almost there, now let’s activate this backend:

kbuildsycoca4 --noincremental

And now you can change your backend in the System Settings -> Multimedia -> Backend tab. Start Amarok and enjoy 🙂

Please help us improve this backend and report any bugs you might find here: http://bugs.kde.org/enter_bug.cgi?product=phonon, component “VLC backend”. Keep in mind that this is still work in progress, so make sure your bug report is really against the latest version. For those willing to give a hand and/or submit patches, please meet us in #phonon on irc.freenode.net or make a merge request for your patch.

Powered by Blogilo


Show your Love on Valentine’s Day :)



I usually boycott this marketing day of the flower business, since it is exactly that, a very well orchestrated campaign of the flower producers to guarantee their income in the bad season between Christmas and Mother’s Day, but this year the FSFE has launched a lovely campaign which I fully subscribe to.

I love Free Software!

Show your love of Free Software by different means:

  • donate to your favorite Free Software project
  • hug/kiss your favorite Free Software developer (don’t forget to ask permission first 🙂 )
  • buy your favorite Free Software developer a drink/food/flowers (and make the inventors of the Valentine’s Day happy)
  • express your happiness about Free Software by sending congratulations to your favorite Free Software project team

Powered by Blogilo

In an ideal world…


, , , , , ,

… every Free Software project should not only have developers, but also

  • graphical artists
  • usability experts
  • user support specialists
  • documentation writers/translators
  • software translators
  • bug triagers
  • marketing ninjas
  • community managers
  • release managers
  • website and wiki maintainers
  • unlimited funds…

Amarok is very lucky to have most of those. No, not the unlimited funds, sadly, thats one of the reasons why we ask our dear users and Amarok lovers to support us with donations, it allows us for example to maintain our server,  which in turn can host other Free Software projects of the KDE family like Konversation.

Linda and Valorie have started to write the handbook for Amarok 2.2.2, and Valorie is currently looking for skilled wiki writers and maintainers,  too.

I am more active in doing user support and act as a bug triager for Amarok, and occasionally also other KDE projects like Phonon. This all started on a rainy Sunday afternoon when I tried to get rid of some of the numerous duplicate bug reports and wishes and I got hooked on it. Some 12 months later I have closed 1885+ bugs and triaged thousands of others:  Amarok went from 2.0 to 2.2.2 and got 2864 new bug reports and wishes in this time, of which 3071 could be closed. An average 5-10% only were unique bugs, all the rest were either duplicates, invalid, already solved or reported against the now unmaintained Amarok 1.4.x. Some were also reported against Amarok by error and had to be reassigned to another project.

Bug reports and wishes are something that definitely needs triaging, since many reports have flaws. This can be

  • an incomplete or a too complicated description, sometimes not even in English
  • missing elements: version number, distribution, what were they doing when the bug occured
  • in case of crashes: incomplete backtraces
  • more than one item per report, which makes it too difficult to follow
  • duplicates
  • already implemented features or corrected code
  • Invalid reports

All of these flaws are quite common, it is rather rare to get bug reports that can be used "as is" by the developers. And that is my point: bug triaging is not a developer task. Developers develop code, they should not have to loose their time running after users for more information about a bug or a wish. Unfortunately most of the projects don’t have their own triagers and rely on the KDE bugsquad to do this task, which is not that easy and something that needs to be addressed:

While much of the triaging can be done by people not involved in a particular project, it gets difficult when the triager doesn’t know the application. IMHO s/he should at least be a regular user of the application and ideally also run the developer version from GIT or SVN. This is not as complicated as it sounds, most of the projects have step-by-step instructions on how to build from trunk. If it is one single application the triager is interested in, s/he can build it locally in the home directory, which can be easily removed if needed. But it is of course important that the triager is in direct contact with the developers, be this only to be able to get feedback from them if necessary.

I encourage all larger projects to recruit dedicated triagers. This has more than one advantage:

  • it takes away an important workload and the developers can concentrate on their primary task
  • dedicated triagers know the application and can judge much better what is needed to make a report useful than somebody who occasionally triages here and there
  • it adds strength to the team, and dont’ forget, sometimes triagers become developers 🙂 (not me, there are already too many bad coders in this world … )
  • id adds efficiency to your development cycle, and you find your way around in the bugs list since all incomplete bugs are gone

Now how do we recruit triagers? This can be done by encouraging advanced users to give a hand from time to time, I can assure you, bug triaging can get addictive 🙂
But there is a much easier way: through the BugWeeks dedicated to bug triaging in the KDE Forum. The first BugWeek has just ended, set up and lead by Darío Andrés, our "Bugs Hero" who had the initial idea and set up all the course. We plan to hold two BugWeeks per month and encourage everybody to participate and make the number of untriaged bugs much, much smaller! Also, a BugWeek on the forum has the advantage of being easier to run than a BugDay, where people need to be online at the same time and share a wiki.

On another hand I would like to write about a particular form of invalid bug reports: those from poisonous people. Every project has sometimes to face people submitting bug reports and wishes in non-objective ways . The bug may exist, but the way these particular reporters report it and comment on it is poisonous, subjective to the extreme and sometimes quite insulting. A non-objective report is not something one can act upon in another way but by marking it as Invalid  if the reporter doesn’t change their tone. To avoid loosing the important information, IMHO the triager should make a new report with the important information, but close the original one.

I have done this twice already and it worked out quite well, so I think this is really worth a try.

My reason for doing this is clear: useless reports by these people, insulting and personal attacks are discouraging and demotivating for the developers. It can in the worst case lead to developers leaving a project because of this. The triagers have a unique possibility to avoid these insults to reach the developers in filtering those. Of course this can be dangerous for the triagers, too, as themselves can get wary of such posts.

We here should all think and take action to not let this happen and make use of the wonderfully motivating and supportive network we have which is KDE: talk about around you and let the magic work. Don’t keep it in your mind alone or in your developer channel or mailing list or bug report, talk to your team, to your friends, to the bugsquad and of course the Community Working Group. And don’t forget the two last paragraphs of the KDE Code of Conduct: Support Others in the Community and Get Support from Others in the Community.

Powered by Blogilo

Travelling to Buğday?


, , , , ,

The KDE bugsquad will organize a bugday for Phonon on November 8th. To make sure not to forget that day, I duly entered it into my Google calendar. But I must say that the mail I got today from Dopplr was quite astonishing: it seems I will travel to Buğday, Turkey on that day!
Now, while I enjoy travelling, I think it’s a bit far away just for a bug triaging event, isn’t it?

Regardless this interesting suggestion, I will stay at home and give a hand in bug triaging, this will probably be more efficient 🙂 Don’t hesitate to join the fun in #kde-bugs on irc.freenode.net on November 8th!

PS. I seem to travel again on November 21st, this time to Giv’at’Ada, Israel. Since I planned to be in Bern for the Swiss Karmic Koala Release Party, I guess that’s what is meant 😉

Powered by Blogilo

Amarok,KDE and Kubuntu at OpenExpo in Winterthur, Switzerland


, , , , ,

Another edition of Openexpo in Winterthur is over and I owe you a (not so) short report:

Eckhart, Andi and Adriaan held a booth for KDE, Mark and Sven were manning the Amarok one and I tried to be at both the KDE and Kubuntu booth during these two days. This was made quite easy by the organizers as they arranged the three booths around the same pilar we shared with the guys from the Swiss OLPC Team.

While Andi could only attend the first day (thanks again, Andi, for helping us, it was really nice meeting you!), Adriaan was also wearing his FSFE/FTF hat and was busy with attending talks, FSFE and Swiss FOSS meeting and getting in touch with a lot of Swiss activist, especially during the second day. He sometimes found a little time to show KDE running on OpenSolaris and talk about the pilars of KDE and brought some very yummy Dutch cookies. Eckhart held the KDE flag steadily, selling swag, showing 4.3.1 and handing out CDs (we had Kubuntu 9.04 and Fedora KDE Live Media kindly provided by the Fedora guys from the booth right in front of us). He even found some time on brainstorming about how to improve the booth to make it better despite the little space and prevented the table from getting too much cluttered with empty water glasses, paper and such. Great work, Echkart, as usual! I sat somehow between the KDE and Kubuntu booth (actually the booth of the official Swiss Ubuntu LoCo Team), showing KDE 4.3.1 on my laptop to give people some taste of what they could expect for the next release. The Swiss Team was present with Manuel and Roman on Wednesday, Dirk and Dani on Thursday (since Dani helped out a the OOo booth on the first day) and Nick was the nice guy who attended all two days! He really deserves a special Thank You for his patience and expertise 🙂 It was also a nice occasion to meet Dirk, who is usually helping out the German team and took his Thursday afternoon off to give a hand.


Despite the ongoning economic crisis, the event was nice although very noisy, with good catering and the organizers did a lot to make us comfortable (thanks again to Hannes and the two Matthias from ch/open !). The adjacent business event called Topsoft was focusing on the same themes as usual, ERP and CRM, with big booths, suits and ties everywhere, expensive flyers and buzzwords. They even had Brazilian dancers on the first evening "apéro" 🙂 But even without the big money, we had a lot of fun on our side and were greeted with a yummy supper at the social event, listening to some lightning talks (where Sven presented the Darker Radio Charts available as a script in Amarok) and making new acquaintances. Add to that the Free Beer which made us all quite happy 🙂

The evening of the second day was topped by a gathering of about 20 Free Software activists in a Spanish bodega with very good tapas and some beer and sangria in Zürich. So sad Eckhart had a train to catch and couldn’t join in, but we will repeat that on the next occasion, promised. How about Openexpo in Spring again?

Powered by Blogilo

Compiling Amarok from git locally – full summary updated


, , ,

/* */ Last update: May 23, 2012

As we have more and more questions for support on how to install Amarok 2.x from GIT, I thought I might make another synopsis on how to install a local build. Apparently linking to previous posts is not very useful because people tend not to read the links…

Warning: please do not try this if you are not comfortable with compiling from sources, and be aware that compiling from a development branch can break a few things!

Note: as I use Kubuntu, this is heavily biased, but there are a few indications for other distributions, as far as those have been provided by the previous bloggers. Thanks go to Mark Kretschmann who started that adventure and wrote the first instructions, to Stephan Jau who wrote an excellent How-to for the SVN version for Kubuntu users and to David Faure who corrected some of our settings. And, of course, all the Amarok Team who do a tremendous job every single day 🙂

This document explains how to install Amarok 2 from GIT in your home directory – in an easy way 🙂

Update 15: May 23rd 2012 Added information for Gentoo builds.

1.Install git, the compiler and KDE 4 development packages:

  • In Kubuntu, Debian, and all their derivatives:

    • sudo aptitude install git-core build-essential kde-devel

    Since Kubuntu 10.10, the kde-devel metapackage does not exist anymore. You will need to add these packages to the above installation line now:
    * kdesdk
    * kdelibs5-dev
    * libkonq5-dev
    * kdebase-workspace-dev

    As well as a basic KDE installation, formerly provided by the now defunct kde-minimal metapackage:
    * kdebase-runtime
    * kdebase-workspace
    * kdebase-apps
    * plasma-desktop

    I also highly recommend to install the oxygen-icon-theme and oxygen-icon-theme-complete, so you don’t have missing icons if you do not run KDE.

  • In Archlinux:

    • sudo pacman -Sy git base-devel kdelibs kdebase-runtime

  • In Gentoo:

    • sudo emerge -av dev-util/git kdelibs plasma-workspace
    • alternatively: layman -a kde && emerge -avt --autounmask=y --autounmask-write=y =amrok-9999

  • In OpenSuSE:

    • sudo zypper install git

  • In Fedora:

    • sudo yum install git kdelibs-devel

2. Install ccache to speed up compilation

ccache is a very nice tool that can speed up your compilation. It speeds up re-compilation of C/C++ code by caching previous compiles and detecting when the same compile is being done again. Install the package from your distribution and set the size of the cache to 2 GB with the command

ccache -M 2G

This will take 2Gb of space in your local directory, but the gain of time is really impressive. Enable the use of ccache by adding it to your local .bashrc, described in step 3 below:

3. Define the PATH and local environment

Append the following to $HOME/.bashrc (or create the file if you don’t have one)

  • export PATH=$HOME/kde/bin:$PATH
  • export PATH=/usr/lib/ccache:$PATH

Reload your edited .bashrc:

  • source $HOME/.bashrc

NOTE: if you are not using the bash shell, edit your proper shell config file (~/.zshrc or ~/.tcshrc or whatever it may be).

4. Make KDE aware of Amarok’s plugin location:

  • echo 'export KDEDIR=$HOME/kde' >> $HOME/.kde/env/myenv.sh
  • echo 'export KDEDIRS=$KDEDIR' >> $HOME/.kde/env/myenv.sh

Beware, some distributions call the above folder $HOME/.kde4/… (OpenSuSE in particular).

5. Make sure you have all the necessary dependencies

The README file in the source states the required and optional dependencies, but I might as well write it down here, so there is no other document to be read for the lazy ones. Of course, before diving into compiling from source, check if those dependencies are available in the package repository of your distro 🙂
For the lazy, there is a quite easy way to get all the necessary dependencies for amarok by using the build-dep command. Activate the source repositories in your /etc/apt/sources.list, then type

  • sudo apt-get build-dep amarok

For OpenSuSE users this would be

  • sudo zypper si -d amarok

For Fedora users, it is

  • yum-builddep amarok

Note: you must of course install the devel versions of these packages!
Important:if you previously had Amarok 2.x installed from your distribution, you already have all the dependencies, you only need the corresponding devel versions. Those are all provided by your distribution as well.


  • MySQL 5.0 (or newer) Embedded: libmysqld compiled with fPIC (In-process database support)
    Note:If you have installed MySQL Embedded in non-default location (i.e. $HOME/usr), Amarok may fail to start with error regarding libmysqlclient library. In this case, add the following string to your ~/.bashrc:
    export LD_LIBRARY_PATH=$HOME/usr/lib/mysql:$LD_LIBRARY_PATH where $HOME/usr is the path you will use in the --prefix option when compiling (see step 7. below)


  • MySQL 5.0 (or newer) Server (external database support)

  • ffmpeg 0.6.0 or higher (Libraries and tools for handling multimedia data and transcoding)

    • http://www.ffmpeg.orgFor all supported encoders to be available in Amarok, FFmpeg needs to support the following codecs:

      • libfaac (NOT just “aac”)
      • alac
      • flac
      • libmp3lame (NOT just “mp3”)
      • libvorbis (NOT just “vorbis”)
      • wmav2

    Note: Since there is no ffmpeg-dev or libffmpeg-dev package in Debian/Kubuntu, you need to install libavcodec-dev and libavformat-dev, those are the ffmpeg libraries needed.

5.1.Various dependencies that might cause compile errors and have to be installed:

(these are rather specific to Kubuntu, might have other names in other distributions and/or are already installed)

  • libstrigiqtdbusclient-dev
  • libsearchclient-dev
  • libmysqlclient
  • libmysqlclient-dev
  • libmysqld-dev
  • libmysqld-pic
  • libwrap0-dev, needed as a dependency for MySQL. For OpenSuSE users, the package to install is tcpd-devel

5.2. Changes for mysqld in Kubuntu Oneiric and Debian Sid:

Mysqlclient was moved in these distros with the arrival of mysql 5.5, so mysql_config no longer reports mysql_pic. To correct this you need to patch a few files. Find below the patch by Jonathan Riddell:

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 4241e69..41b3412 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -957,7 +957,7 @@ if(KDE4_BUILD_TESTS)

– target_link_libraries(amaroklib ${MYSQL_LIBRARIES} ${ZLIB_LIBRARIES})
+ target_link_libraries(amaroklib ${MYSQL_LIBRARIES} -L/usr/lib/mysql ${ZLIB_LIBRARIES})

diff –git a/src/core-impl/collections/db/sql/mysqlecollection/CMakeLists.txt b/src/core-impl/collections/db/sql/mysqlecollection/CMakeLists.txt
index 7218d54..07c5b6e 100644
— a/src/core-impl/collections/db/sql/mysqlecollection/CMakeLists.txt
+++ b/src/core-impl/collections/db/sql/mysqlecollection/CMakeLists.txt
@@ -36,6 +36,7 @@ target_link_libraries(amarok_collection-mysqlecollection
+ -L/usr/lib/mysql
diff –git a/src/core-impl/collections/db/sql/mysqlservercollection/CMakeLists.txt b/src/core-impl/collections/db/sql/mysqlservercollection/CMakeLists.txt
index 3312e14..72196ae 100644
— a/src/core-impl/collections/db/sql/mysqlservercollection/CMakeLists.txt
+++ b/src/core-impl/collections/db/sql/mysqlservercollection/CMakeLists.txt
@@ -36,6 +36,7 @@ target_link_libraries(amarok_collection-mysqlservercollection
+ -L/usr/lib/mysql

To apply the patch, save it as a kubuntu_mysqld_pic.diff, go tho the amarok/ directory in your git checkout (see section 7 below) and type the following:

patch -p1 < kubuntu_mysqld_pic.diff

6. Create folders:

  • mkdir $HOME/kde
  • mkdir $HOME/kde/src
  • mkdir $HOME/kde/build
  • mkdir $HOME/kde/build/amarok

7. Checking out and Building:

Now you need a source checkout from git.kde.org. In the folder ~/kde/src/, type the following command:

git clone git://anongit.kde.org/amarok.git

this will drag approx. 55-60Mb of data, depending on the moment you actually make this checkout. Everything is now ready to build:

  • cd $HOME/kde/build/amarok
  • cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/amarok
  • make install

8. Updating KDE Config:

  • kbuildsycoca4 --noincremental

Note: this might not be necessary for most of the cases Now you are ready to run Amarok 2.x by typing “amarok” in the shell. We strongly recommend you run amarok with the -d and –nofork option, so you will have debugging enabled and can get a valid backtrace if Amarok crashes.

9. Updating your Amarok build:

Since the development is quite fast with git, you should update your Amarok build regularly, and a daily checkout is not too much. This is made easy with the following command:

  • cd $HOME/kde/src/amarok
  • git pull

This will update your local git branch. If you have done modifications to your local branch you would like to keep, make sure you update with the --rebase option. See also the git tutorial for KDE in section 10. You can now simply build again with

  • cd $HOME/kde/build/amarok
  • make install

Since you have installed ccache, a full build will speed up over time. To have an idea about the build time, just type time make install when building. If you have several CPU cores, you can speed up even more with the -j[n] option, where [n] is the number of CPU cores +1. Of course, the more CPU you use for building, the less you will have available for other tasks 🙂

10. More information and useful links

Don’t forget: running a development version also means that it is eventually not stable and can break anytime ! This is especially true after a feature freeze, when the developers merge their personal git branches to the master branch.
Note: To be notified about major changes you definitely should subscribe to our mailing list amarok@kde.org at https://mail.kde.org/mailman/listinfo/amarok. Of course you will also find help in our #amarok channel on irc.freenode.net, but reading the mailing list is mandatory and spares us a lot of time. Since you don’t want to repeat all this completely when you upgrade to a newer version of your preferred distribution, you should consider installing your /home directory on a separate partition from the start, it will spare you quite some time and hassle in the future.

Edit: Casper van Donderen just pointed me to the possibility to have the latest Amarok from git on Windows, too: if you build KDE using the emerge system, just type emerge amarok at the kdeenv command prompt. Thanks for the hint, Casper!

11. Important information for code contributors

Amarok uses a unit test infrastructure that allows us to test the builds. If you consider contributing code to Amarok, you need to install Google Mock and you should build Amarok with the following cmake flag: KDE4_BUILD_TESTS=ON
For more information about the test infrastructure, read the Qtestlib Manual
Please also see the instructions for the git configuration if you have push rights in this link

Powered by Blogilo