Wednesday, March 20, 2013

Testing, another way to help your favorite FOSS project

I've done some testing before, but this time I want to document it here, so I can come back later and remind myself of some of the critical steps, and so others new to testing can get the confidence to start contributing in this way as well. I'm mainly using Kubuntu as an example here, but applications and desktops need testing as well. If you are using a non-Debian distribution, the commands I use will not work. Consult your documentation for equivalents.

I'm lucky in that I have some extra computers I can use as testing machines. But when I didn't, I used virtual machines, and those aren't too difficult to set up. However, I'll discuss that another time.

In general, please read the /topic in your development IRC channel, then ask about testing, or join the testing channel if there is one. Often you'll be given bug numbers to test for a specific package -- please be sure to comment completely in the actual bug report, not just give feedback in the channel. Be sure to ask what information is necessary. ISO testing is another place where folks are needed; again, your devel channel /topic should give you some good information. And don't forget to join and read the relevant lists as well; no one can be in IRC all the time.

Right now, some packages need testing in the next Kubuntu distribution release. I prefer using the command line for things like this, because 1. in the console, upgrades happen "under" the desktop, so config files are updated cleanly, and 2. it is much faster. So first, the upgrade. Instructions to do this in the GUI:

If your computer is already on, log out of your session. At the login screen, rather than typing in your password, hit Control + Alt + F2. Then log into first your computer with your username and password, then

sudo update-manager -d

This updates all your repositories to the development release. Next, the start the actual upgrade:

sudo do-release-upgrade -d

You'll have to OK a few things, so it's not entirely unattended. After the packages are all downloaded, the upgrade still takes quite awhile. Sometimes I start this at night, and just check on things in the morning.

Next, you'll need to install the package, or build the application from a tarball, or source. Depending on your distro tools, this might vary a bit.

Building from source

For Amarok, Myriam has a great blog post about how to build from git:, so I won't cover that. If you doing a local build of a different package, the steps will be similar. Consult the documentation for details. This blog post is kept updated, and deals with lots of different distributions.

Install from a PPA

To install a package from a PPA, in Debian-based distros, there is an easy way to add it (addrepo in Debian):

sudo add-apt-repository ppa:

This will download and register the public key, as well as adding the repository. Then you can simply install the package via the command line or using the GUI tools you prefer.

Build from a tarball

To get the tarball, cd to the directory where you want to unpack it, then wget the file. As as example, here's how I built phonon 4.4.4 from the tarball:

cd ~/kde/src/
tar xf phonon-4.4.4.tar.bz2
cd phonon-4.4.4 && mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon-4.4.4
sudo make install

I'm not sure that building phonon in my home folder was a good idea, but since I build Amarok locally, I've gotten into the habit of doing that.

So now you have your package or packages, and can do the tests, and report your results. Have fun!

1 comment:

  1. Hello Valerie,

    Thanks for animating people to test :)

    Just two small remarks: Maybe you should add the information that update-manager is quite distribution specific and might not be available in the users choice of distribution. (It is 1) only for apt 2) just one front-end). In general your Blog post mainly covers (k)ubuntu and partially debian, and even though this is in the blog tag and your title, it is not really visible on e.g. planetkde. You should maybe mention that in the blog entry.

    As for the installation prefix: If you are going to take the regular place where the rest of KDE expects packages, I recommend using `kde4-config --prefix` instead of a hard-coded /usr. If you set up a testing environment with more than one package, you could always use that. But /usr is quite probably where all the "official" packages end up as well (also note that these files might get overwritten by your package manager)

    Happy Testing :)