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

BoFs at Akademy

So excited to see all the BoF meetings shaping up for Akademy. Perhaps most exciting is the KDE Authors meetup. For background, see Supreet's great post at http://supreetpal.blogspot.com/2012/06/kde-authors-promoting-book-writing-in.html. For the BoF info, see http://community.kde.org/Akademy/2012/Wednesday. As plans now stand, we'll be in room 226 on Wednesday, July 4th at 14:00 UT. I assume we'll be in IRC (freenode) #kde-docs, or announce there a special channel.

If you want to write for or about KDE, be there!

Other exciting BoFs (These are exciting to me. There are lots of others.):

Monday: http://community.kde.org/Akademy/2012/Monday

Quality Team, 15:00 in room 226.

OwnCloud/KDE, 10:30 in room 419. ( http://dragotin.wordpress.com/2012/06/17/owncloud-bof-at-akademy-2012/ )

Tuesday: no sessions formally scheduled during the KDE e.V. Annual General Meeting. This will be my first e.V. AGM, so this is very exciting.

Wednesday: http://community.kde.org/Akademy/2012/Wednesday

Besides our Authors BoF, it will be great to attend  the Women's Outreach, at 9:30. The women's session at the Desktop Summit was outstanding, and I'm expecting great things from this session as well!

Thursday, I hope to attend Liquid democracy. Pirate politics – Free Software relationship in room 419 at 10:30. Others may find the more technical BoFs to their taste on Thursday: http://community.kde.org/Akademy/2012/Thursday

The final day of Akademy is Friday. So far the day's schedule is blank! I hope it fills as people talk about projects with others.

Going to Akademy!

Yes, I'm going to Tallinn, Estonia in a few days, courtesy of the generosity of the KDE e.V., who has sponsored my travel costs. I'm so excited! Flying in a few days early, so that jet-lag won't hinder my time at Akademy, and perhaps I can do some setup help as well. And of course I hope to wander around the medieval city until my feet fall off -- when will another chance come to see Tallinn, after all?

The talks and meetings sound exciting, but what I most look forward to is meeting my KDE family, most of whom I know only from IRC and email. I hope to see you there! Please tell me you read my blog sometimes, and I'll buy you a coffee or a beer. :-)