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: https://help.ubuntu.com/community/RaringUpgrades/Kubuntu
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: http://blogs.fsfe.org/myriam/2009/09/26/compiling-amarok-from-git-locally-full-summary/, 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/
wget http://download.kde.org/download.php?url=stable/phonon/4.4.4/src/phonon-4.4.4.tar.bz2
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!
Hello Valerie,
ReplyDeleteThanks 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 :)