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: 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!

The Disgrace of the United States

Ten years ago tonight, my country, my beloved USA, became the Bad Guys. We became the attackers. Sad to say, this is not commonly admitted, any more than we admit that we admit that we invaded Canada in 1812, and were thrown out, or that we stole what is now the US Southwest from Mexico, and then called the treaty the Gadsden Purchase, or that we created, in part, the situations in Afghanistan, Iran and Iraq that are now still burdening us and the world. We like to think well of ourselves, as do all people. There is no excuse for teaching lies to kids in history books, though.

There were heroes then; many people opposed the war, voted against the war, marched against the war, and many then paid for their patriotism. The lucky ones were just booed, the more unfortunate lost their jobs. There are many now who still are out telling the truth, and bringing more facts out into the light. Along with the Bush administration, the American press let us down ten years ago with their unquestioning acceptance of the administration lies. And now that same press continues to call upon those guilty of this horrible war, the architects and shills, to give their assessment of the situation now! Unbelievable. And it isn't just Fox "News" either. These "neo-cons" should pay a price for lying to the country, leading to untold thousands upon thousands of deaths and injuries, and beggaring both the US economy and the entire nation of Iraq.

History is based upon the facts, not the white-washing that is currently being attempted. We invaded Iraq for no good reasons, our occupation wrecked the country, and we left in disgrace. Lying about the past will never change the truth. The US lost the War of 1812, and we were the aggressors in the Spanish-American War, the Mexican-American War, the Second Iraq War, and many others. I love my country, and I have to tell the truth.

And now back to free software.

Adventures in git

It has been a bit painful to learn to build from source, but I can do it both from git and from tarballs now. (Painful for me, and I'm sure even more painful for the patient devels who have helped me through my beginner mistakes. Thank you Amarok and KDE Multimedia devs, especially Harald and Myriam.)

Tonight, I was working with the developer of the wonderful little CLI application Rippit trying to get it to work on my system again. He gave me a patch to the tarball which cleared up one error, but then there was another, and GAH. Then I noticed that he used git, DUH, which I know how to clone from and then build. For instance, in this case, it was

mkdir rippit && cd rippit
git clone git://git.fedorahosted.org/rippit.git
cd rippit && mkdir build && cd build && cmake cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/rippit/rippit

sudo make install

From the error message, Trever could tell that I wasn't using the proper branch. So:

cd src

then, rather than ls to list all the branches, 

git branch -a 

git checkout remotes/origin/0.1 (I found this method on Stackoverflow. Thanks superlogical for your answer.)

From there, delete the build folder, and do the rest of the process as before. I love stringing together the commands with && which make it so much easier for me to copy/paste or use the up-arrow in Yakuake. I want to make it easy to rebuild so that testing can be quick.

Finally, a working Rippit again! Thanks again, Trever. You rock! KDE devels are the best.

Thoughts and worries about the proposed new Ubuntu processes

Today began in a virtual UDS session (Google Hangout) with the Xubuntu team. The video can be seen here: http://summit.ubuntu.com/uds-1303/meeting/21666/community-xubuntu-contingencies/ . Xubuntu devels stopped by #kubuntu-devel and asked us to bring our list of concerns to share. The list we developed:

• The new system will do away with releases for each upstream KDE release, which is a prominent feature of Kubuntu. One idea is to do releases of LTS+PPA with latest KDE but that's against policy and needs technical changes to make happen. Or will there be a way to create ISOs from PPAs?

• Mir is a worry since KWin will clash with it (a compositing manager inside a compositing manager). How good will continued Wayland and X support be?

• Where to put Beta releases of software? Testing is a huge part of quality. So while a PPA seems the obvious suggestion, but they'll get less testing there. Now we use a beta ppa only for backports. Consistent quality would require staging major changes somewhere else.

• How will library transitions be handled outside of cadence?

• Launchpad breakdowns. We are trying to automate more of our building tasks, but often the scripts must be run repeatedly because of Launchpad timeouts.

• Weakness of unit & hardware testing. This is crucial for a successful rolling release.   

• Security updates - who gets them? When, and how often? (LTS will get them as usual, but for rolling it seems the monthly snapshots don’t get any? you need to use rolling)

• We will be more dependent than ever on syncing with Debian for rolling. We already import, and release, Debian packages with RC bugs. Colin Watson suggested checking Ubuntu-Critical bugs anyway. Scott Kitterman replied that this would recreate painful Debian transition. Beta/buggy software is often uploaded into Debian Unstable, and proposed changes mean even less prevents bad software  from getting into Ubuntu -release.

• We need a policy for when to move packages from PPA to rolling.

• PPAs for non-Canonical contributors have low armhf/powerpc ability.           

          * KDE doesn't compile in qemu (bug 1077116) [Philip Muskovac]
          * Fixing these might be an acceptable cost of rolling release according to Steve Langasek.

I wish I could say we got answers to all of our questions. On the other hand, it was good to have those advocating for a rolling release listen to our concerns. The discussion continues on the Ubuntu-devel list and in the IRC channels. Of course the Kubuntu developers will continue to voice our concerns, and listen as the proposals change over time. As Rick Spencer said, he made a proposal to Ubuntu developers, not a announcement from Canonical. As we heard in the session today, no proposal has been formally submitted to the Technical Board. It seems possible that 13.04 will be released as planned, with the beginning of new processes put off until more of the necessary supports are put in place.

I want to thank everyone involved who continue to work so hard to provide an excellent user experience, even when we disagree about how best to do that. And especially the Kubuntu and KDE communities. You rock!

PS: This mini-UDS was a good place to share our concerns, and perhaps do some planning. But it in no way compares to a real UDS, with actual face-time, and the essential "hallway track."

Adventures in the CLI: fixing sound using apt logs

Plunging back into community involvement this week meant installing mumble, a free messaging system. The virtual UDS (Ubuntu Developer Summit) Canonical is hosting at short notice this week (today and tomorrow, actually) is being conducted on Google Hangouts. While these can be cool, they limit participation to ten, and to those who have GooglePlus logins. So the Kubuntu devels wanted to try mumble instead for our meeting(s).

I usually use apt-get to upgrade and install packages, just because it is faster and easier. Alt-F12 to get nifty drop-down bash session, up-arrow to get to commonly used commands, and viola, done! However, this time apt-get installed most of GNOME along with mumble, such as evolution, plus gnucash and other stuff! Once all this was installed, I had no sound of any sort; from speakers, in flash, through earphones. Sadness.

I began working through the sound troubleshooting guide, but none of it worked, and didn't seem to apply anyway. When I asked in #kubuntu-devel about the mumble install, Scott Kitterman asked the right questions, and told me that his list of dependencies was small, as was the list of recommended packages, and how to find the complete list:

$ cd /var/log/apt/
$ ls 
$ cat history.log

This gets you a wonderfully detailed list of all packages dealt with by apt. I started by removing the obviously un-needed packages, including mumble itself. The list was so huge that I didn't get far, however, ScottK had suggested removing slpd and roaraudio. After reading the man page for apt, I got a bit more clever about getting more stuff in one fell swoop:

sudo apt-get purge gnome-mahjong*

for instance, gets the libs and -dbg packages too. Once I went back and purged roar* -- I got the offending libs, and had sound again!

By coincidence (I think) I had a problem in flash in Firefox at the same time. So Youtube videos were silent and about 100 times too fast. Once sound came back, I noticed that I had sound in Youtube in Chromium, and everything was the correct speed as well. Flash still seems broken in FF, but that now seems unrelated.

By the way, when I re-installed mumble using Muon, everything worked well. Although I haven't tested it yet, I expect it to work as advertised. 

Planning for Google Summer of Code

Now that Google has announced GSoC 2013, we will soon hear the rules and schedule. It's never too early to plan for your participation, whether as a student, a mentor, or KDE administration team member.

I recently read an interesting book about time and how we perceive it, based on recent neuroscience: Time Warped: Unlocking the Mysteries of Time Perception, by Claudia Hammond. The section on planning projects seemed applicable for both mentors and students. Of course, for students, this is the time to get involved with the KDE community, figure out what projects look interesting, and start the learning the development process.

The crucial resource is the Handbook, written by participants. There is a Mentor's Guide and Student's Guide, also available in ebook format.

In addition to the Handbook, Time Warped offers some valuable insight into the Planning Fallacy which is the tendency to believe that the job will take less time than eventually does. The admins and mentors work with students to create a realistic and detailed timeline, which is one of the important ways to outwit this human tendency. Hammond suggests that you consider your plan and then compare the parts to projects you have done in the past, to fine-tune your time frame to completion. Hammond warns against the common belief that we will have more time in the future than we have now. This caution is very important for mentors too. And it is one reason KDE always tries to have at least one back-up mentor for each accepted project, as well as the teams for general help.

Finally, Hammond suggests that since other people make more accurate judgements about our time, describe the task to a friend and ask them to guess how long it will take you. Those who have mentored before can help new mentors with this, and students can ask those who have seen their previous programming work to help judge the prospective plan.

I look forward to seeing KDE folks, experienced and brand-new, getting to know one another, and digging into the code.

Help us out!

KDE is sponsoring a communal sprint in Randa, Switzerland again this year, but funds are a bit lacking. So we are doing a fund-raiser to help out the e.V. (foundation supporting KDE development).

I'm lucky enough to be sponsored, so of course I need to help out as well!



Please click and toss a bit of money in the hat.

Thanks!

More information at http://dot.kde.org/2012/08/13/support-2012-kde-randa-meetings-inspired-and-intense