How to submit patches for Amarok

If you followed the Amarok development in the last 18 months, you have seen us move from SVN to Gitorious, and finally to KDE’s own git implementation, For patch submitters  and other external contributors there was always a bit of a confusion on what is the best way to submit code to Amarok. Unfortunately there have always been several ways, with the risk of loosing track of the patches, which is a sad side effect when there is too much choice.

Since we moved to, we now also have a reviewboard! It is available here: and this is the perfect place to submit code for our project. String or feature freeze and code “not just ready” is no excuse to not use the review board

So to all contributors: register at and show us your code 🙂

Important: Please, subscribe to and first talk about your ideas there. Good ideas are often shared by more than one person and that can avoid two people working on the same implementation without knowing about each other. It is really mandatory for all contributors to talk to the team about their ideas before even starting to code to avoid such problems. And of course, don’t forget to read our HACKING guide!

Posted in Amarok, Git, KDE | Tagged , , | Comments Off on How to submit patches for Amarok


.. is the total number of countries where the Multimedia/Edu sprint participants in Randa are from. You read that right: seventeen! We had developers from Austria, Brazil, Croatia, Denmark, France, Germany, Greece, Holland (the Netherlands), Italy, Norway, Peru, Poland, Scotland (yeah, I know…), Spain, Switzerland, Ukraine and the USA.MmEduSprint
Impressive, isn’t it? So sad I had to leave this afternoon already, but here are a few highlights of the weekend: we had a very talented chef who spent his holiday to prepare our yummy meals, very productive sessions in the various rooms of the huge building during the day, dsc_0945_smallgorgeous weather, the worlds most beautiful mountain right around the corner ( I am biased 🙂 )dsc_0823_resized and of course the mandatory Raclette evening, prepared by Mr. Fux: dsc_0820-small And here is the man who made all this possible: Mario, the most efficient Sprint organizer I know:dsc_0813_resized Kudos, Mario, well done!

I should not forget the reason why we were in Randa: Amarok and the Mulitmedia people gathered in this lovely Swiss village to concentrate on various themes, amongst them the current state of Amarok and it’s roadmap, presenting the state of Pulseaudio, sharing a vision of the Multimedia future, possible uses of Nepomuk in Amarok, and many more like Sound events in KDE, a VLC presentation by Jean-Baptiste Kempf and the future of KMix by Christian Esken. But I better leave it to the developers to blog about the details 🙂

A special Thank You! goes to the currently most famous man in Norway, Knut Yrvin. He made it possible to have an online presentation and discussion over the phone with the Qt Multimedia developers in Brisbane, who kindly stayed in their office much longer than usual to talk with us. A big hug to Knut for being such a great Community Manager, and a big sorry from me, I totally forgot to take a picture of him, so I am shamelessly using a picture made by Thorsten Rahn on the Little Matterhorn: dsc_0899_resized And no, they didn’t break it, the Matterhorn is still up in all it’s glory 😉

Posted in Amarok | Comments Off on Seventeen…

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.

UPDATES: I changed the VLC installation instructions to make sure you install the 1.1 version instead of the git master branch which is the development version.

UPDATE 2: July 4th 2010: The VLC information is updated to reflect that all distros now ship VLC 1.1 (if they don’t, talk to them, they really should, it is much better and fixes a lot of bugs.

UPDATE 3: September 20th 2010: Development is quite fast paced for both VLC and the VLC backend, so there have been some updates: VLC 1.1.4 is now a requirement and there is an addition to the Cmake command for the VLC backend, to make sure it uses a stable phonon version: erase CMakeCache.txt in the build folder and run Cmake again, with the modifications below.

UPDATE 4: November 30th 2010: Updated the git checkout for VLC.

UPDATE 5: December 21st 2010: Phonon has moved the source repository to git now. Updated the git checkout for phonon-vlc.

UPDATE 6: January 7th 2010: You now need a newer Phonon build, updated the blog accordingly.

UPDATE 7: February 5th 2011: Please only use anongit to pull, see sections 2 and 3.

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 VLC 1.1 stable branch

Most distributions currently ship VLC 1.1.4, but for those who happen to run an earlier one it is still necessary to compile yourself, see the instructions below:

You can find the source code here: I use 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://
cd vlc

This will get you the latest stable branch, including all the latest fixes.

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:

  • libxcb-shm0-dev
  • libxcb-xv0-dev
  • libx11-xcb-dev
  • To build VLC, you will also need the following packages:

  • autoconf
  • lua5.1
  • liblua5.1-0-dev
  • 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 a newer Phonon

    Some dependencies changed in the new backend version and we want to have a newer Phonon build than 4.4.3 which is currently shipped by most distributions in KDE 4.6, Let’s start with that before we can build the backend.

    Phonon is now located on

    git clone git://
    cd phonon
    mkdir build
    cd build

    I did a system-wide installation to override the default Phonon delivered with KDE. Here comes the cmake command:

    cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon

    All in one line, of course. The command

    sudo make install

    will build it and you have a new Phonon on your system 🙂

    3. Build the phonon-vlc backend

    The current code is located on Keep in mind that this is still very much work in progress, so there will be changes to the code almost daily.

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

    git clone git://
    cd phonon-vlc
    mkdir build
    cd build

    Everything is read to build now:

    -DCMAKE_INCLUDE_PATH=$HOME/kde/include/ \
    -DCMAKE_BUILD_TYPE=debugfull \
    -DPHONON_VLC_NO_EXPERIMENTAL=true $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:, 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 or make a merge request for your patch.

    Posted in Amarok, Free Software, FSFE, Git, KDE, Kubuntu, Ubuntu | Tagged , , , , , , | Comments Off on Want to test the phonon-vlc backend? Here you go :)

    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
    Posted in Free Software, FSFE | Comments Off on Show your Love on Valentine’s Day :)

    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.

    Posted in Amarok, Free Software, KDE | Tagged , , , , , , | Comments Off on In an ideal world…

    Kubuntu 9.10 is out!

    Long awaited, finally here: the brand new Kubuntu 9.10 aka Karmic Koala is out and ready for download. It comes with KDE 4.3.2 and, of course, a brand new Amarok 2.2 🙂 Check out the release notes and download the ISO here: logo-kubuntu
    Congratulations and well done, Kubuntu community!

    Posted in Amarok, Free Software, KDE, Kubuntu | Tagged , , | Comments Off on Kubuntu 9.10 is out!

    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 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 😉

    Posted in Fun, KDE | Tagged , , , , , | Comments Off on Travelling to Buğday?

    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.


    Don't try this!

    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?

    Posted in Amarok, booth, Free Software, KDE, Kubuntu | Tagged , , , , , | Comments Off on Amarok,KDE and Kubuntu at OpenExpo in Winterthur, Switzerland

    Compiling Amarok from git locally – full summary updated

    /* */ Last update: November 13, 2013 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 🙂

    Note to Gentoo users: You can easily disregard steps 1 to 9 of this blog entry by using the following command: layman -a kde && emerge -avt --autounmask=y --autounmask-write=y =amarok-9999 In order to help the Amarok team, you should enable tests (by having ‘test’ in FEATURES), install debugging symbols (by having ‘splitdebug’ in FEATURES and ‘-ggdb’ in CXXFLAGS) and enable debugging assertions (by having ‘debug’ in USE) for Amarok as well.

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

    Update 20: April 2nd 2013 use correct DebugFull statement in cmake command

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

    • In Kubuntu, Debian, and all their derivatives:
      • sudo aptitude install git-core build-essential kdesdk kdelibs5-dev libkonq5-dev kdebase-workspace-dev

      If you want to run Amarok under KDE you also need a basic KDE installation, formerly provided by the now defunct kde-minimal metapackage: * kdebase-runtime * kdebase-workspace * kdebase-apps * plasma-desktop This is of course not necessary if you use another desktop environment. In any case it is 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 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/
    • echo 'export KDEDIRS=$KDEDIR' >> $HOME/.kde/env/
    • echo 'export XDG_DATA_DIRS=$HOME/kde/share:$XDG_DATA_DIRS' >> $HOME/.kde/env/

    Of course, you might have to create the ../env/.. folder first, but that should be obvious from the message you get on the command line 🙂 Beware, some distributions call the above folder $HOME/.kde4/… (OpenSuSE in particular). Restart KDE after this step so the environment variables are loaded.

    5. Make sure you have all the necessary dependencies

    The README file in the source states the required and optional dependencies, please refer to that document as it is the most up-to-date. 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.

    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

    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 In the folder ~/kde/src/, type the following command:

    git clone 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=Debug $HOME/kde/src/amarok
    • make install

    Update November 2012:We use KDE’s cmake that enables build tests by default. If you do not have gmock installed and don’t need build tests, please add this flag to your cmake line: -DKDE4_BUILD_TESTS=OFF See also step 11 below.

    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 --rebaseoption. 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 at Of course you will also find help in our #amarok channel on, 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 compile it against Amarok, then add cmake flag when building Amarok: -DKDE4_BUILD_TESTS=ON If you are using KDE anyway, then no need to set the CMake option, as kdelibs is set to build everything with tests enabled by default. 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

    12. Important information for git testers

    Sometimes we make changes to the database. This can be seen in the commit messages and can lead to some data loss. Please make sure to always backup your database to avoid losing data. Bart Cerneels provided a script that allows you to easily backup your database: “”

    (application/x-sh) #!/bin/bash cp -R $KDEHOME/share/apps/amarok $KDEHOME/share/apps/amarok.`date +%F` cp $KDEHOME/share/config/amarokrc KDEHOME/share/config/amarokrc.`date +%F` cp -R $KDEHOME/share/config/amarok_homerc $KDEHOME/share/config/amarok_homerc.`date +%F` cp -R $KDEHOME/share/config/amarok-appletsrc $KDEHOME/share/config/amarok-appletsrc.`date +%F`

    Posted in Amarok, Free Software, Freedom, FSFE, Git, KDE, Kubuntu | Tagged , , , | Comments Off on Compiling Amarok from git locally – full summary updated

    Preparing for another conference: OpenExpo in Winterthur next week!

    It’s this time of the year again where I prepare for attending OpenExpo in Winterthur. This important Free Software even is held on September 23 & 24 in Winterthur, Switzerland.
    This year I helped organizing more than one booth: Amarok, KDE and the Ubuntu/Kubuntu booth of the Swiss Team. While Mark and Sven will handle the Amarok booth, showing the upcoming version 2.2 of your preferred music player, I will share my time at both the KDE and the Ubuntu/Kubuntu one, presenting the latest KDE 4.3.1, using Kubuntu 9.04 (unless I find some time to install a preview of the upcoming Karmic Koala before). Not alone, of course, as I will have a lot of helping hands from Andi, Adriaan, Eckhart and Pascal for KDE, and Daniel, Dirk, Erwin and Roman at the Swiss Team booth 🙂

    Posted in Amarok, booth, FSFE, KDE, Kubuntu, Switzerland, Ubuntu | Tagged , , , , , | Comments Off on Preparing for another conference: OpenExpo in Winterthur next week!