Intentional community

This blog is generally seen in the planets for Ubuntu, KDE, and Linuxchix. These are all FOSS intentional communities, by which I mean that the founders and members form a community to in which they can create. I found Linuxchix first (thanks, Megan!), and I loved how welcomed I was, although I was still at the time using Windows. How many linux channels welcome an mIRC user? The longer I hung out there, the more I learned, and the more I was impressed by all the different work the community members were doing out in the greater FOSS world. I also loved that it was women and men working together to make FOSS a better place for women.

When I ended up using Kubuntu (after trying Mandrake and then Gentoo, and GNOME/Ubuntu), some of the Ubuntu Women members welcomed me onto Freenode. When I found that that freenode was where the Amarok team hung out as well, I added the server to my Konversation server list. Members of both of those teams made me welcome, taught me some of the Freenode quirks, and I learned a bit more about how Linux is made. Lots of teams, loads of projects, each with their own culture and ways of working. Because Ubuntu and KDE both have a Code of Conduct, I felt somewhat safe, although I had heard lots of horror stories about linux channels on freenode and elsewhere. After experiencing some quite frightening attacks in the Linuxchix channels, I learned how resilient a community can be, and how creative security can be -- even fun.

So, codes of conduct. In the wake of the recent controversy following PyCon, one of my friends said that they imply that all men are assholes. This surprised me. Linuxchix has two rules: Be polite. Be helpful. All people are expected to follow them; I see the rules as intentional community. We want polite and helpful resources, so those are the rules for everyone. The Ubuntu CoC has grown a bit through the years, but is still phrased positively: http://www.ubuntu.com/project/about-ubuntu/conduct. I prefer the old shorter one, but both are focused on creating a helpful, respectful community.

I like the KDE CoC a lot. Once I found it, I felt much better about becoming involved. It reminded me very much of the simple Linuxchix rules.

This Code of Conduct presents a summary of the shared values and “common sense” thinking in our community. The basic social ingredients that hold our project together include:

• Be considerate 

• Be respectful 

• Be collaborative 

• Be pragmatic 

• Support others in the community 

• Get support from others in the community -- quoted from http://www.kde.org/code-of-conduct/ 

In my opinion, there is nothing in any of these codes or rules that blames men, or is negative. They paint a picture of a place where we want to work, and hang out with friends afterwards. I'm an older woman as the name of this blog implies, and I don't want to pretend to be a guy to collaborate without hassle. I want to be myself, and be welcomed for the skills and passion I bring. I also want more women and other minorities to feel welcome. A boy's club is not welcoming, and linux has that reputation. Too often well deserved.

So I ask each of my readers, what do you want? Is your behavior creating what you want? This is not aimed at men, by the way. All of us create our culture together, intentionally or not. I hope we will more consciously make our community the most pleasant, welcoming and creative in all of FOSS.

[Note on PyCon: The entire controversy has left me feeling sick. Congratulations are in order to the conference staff and leadership, who conducted themselves well. Yet they now have this mess connected to their fine conference, rather than good memories. There are no winners here, from what I can see. Since I didn't attend, and am not part of that community, no comments on PyCon itself or the controversy will be published here.]

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.