Deze LoCoHealthChecks zijn maandelijks, en zeker de moeite van het bijwonen waard, maar vanavond is het extra interessant omdat er als punt op de agenda staat ‘Introducing your LoCo to the wider Ubuntu community’, oftewel ‘Je LoCo kennis laten maken met de hele Ubuntugemeenschap’.
Als je graag meer wilt weten over de Ubuntugemeenschap, en dan dus vooral de internationale, raad ik je aan om vooral te komen vanavond.
Vergeet het niet! 3 augustus, 19.00-20.00 CEST in #ubuntu-locoteams.
Meer informatie op de Ubuntu Wiki: https://wiki.ubuntu.com/LoCoCouncil/LoCoHealthCheck.

However, I would like to take the opportunity to try to turn this into something positive. Because, 1% guys, we know we can do better! Don’t see this debate about Canonical’s contributions to GNOME as an attack on the Ubuntu project, but instead as a challenge!

Raise that number! Show your appreciation for GNOME by contributing to it. We all know the One Hundred Paper Cuts project; work on solutions for the bugs reported there and forward the the patches upstream! Go to GNOME Live! and browse the project pages for ways to contribute. For I believe that the best way to deal with criticism is not attacking the critic with starting a flame-war, but dealing with the problem pointed at.

The challenge: just 1% of the commits are from Canonical. The solution: contribute!

It seems from Dave Neary’s slides that @ubuntu.com addresses are also attributed to Canonical (correct me if I’m wrong!), so it is not limited to Canonical employees.

The day

There were some really interesting sessions today. I haven’t attended much, but I did go to the keynote about activists and journalists and the treats for them in an online world, and what the (FLOSS) desktop can do against that.
Another interesting one was the “GNOME 3 for your Application” talk. Some really interesting plans were shown. I can’t help and wonder, though, if a lot of this isn’t just duplicating stuff from Ubuntu’s Ayatana project, or at least touching it very closely. RedHat’s GNOME 3 and Ubuntu’s Ayatana seem to have a lot in common, but unfortunately there doesn’t seem to be much cooperation and so far the standards and APIs proposed upstream were declined and refused to be used. It would be really a shame if GNOME Shell — which seems to be the big chunk that is going to contain all the new neat functionality — would be using a new API, separate from existing projects. If it would be using standards, but not be using existing libraries for them, then we’d have just dumb duplication of code. I can think of a better way to spend resources.

I hope there will be more cooperation, or at least communication, between RedHat and Canonical on this matter.

T-shirts

I hope this will be the last time I mention those blasted shirts here. Finally we were able to hand out all t-shirts today after some of the organisation went to pick them up from the printer in Nijmegen yesterday night. The good news here is that the Igalia logo, which the printer somehow had made disappear from the final prints of the first batch of t-shirts, is on the newest batch. But still, with the Igalia logo missing from the first sponsors and the huge delays in the deliverances we’re of course not too happy with the service.

Social Media Livestream

The first view days there have been some issues with Identi.ca the UDStream based Social Media Livestream on the GUADEC website. At first the dents were shown with the time in GMT, whereas the tweets were correctly shown in CEST. After I had fixed this everything appeared to be right, but fortunately Stéphane Maniaci was kind enough to keep nagging me about it until I had completely fixed all problems with the microblogging system used more often than Twitter by the attendees. See, my hacky fix for the date problems (‘+ 2 * 3600′) was only working on Google Chrome/Chromium, but made all dents disappear in any other browser. After fiddling a bit with the date format I thought things were completely fixed, but they weren’t in all browsers.

Then I cleaned the code a bit up and by delaying the formatting the Date until after the Date class has been initialised the time is now correctly everywhere without hack, and Identi.ca isn’t broken anymore. This also means that the screen of the livestream in the venue is working at long last!
I’ll push my changes to the GUADEC 2010 Website’s Git repository next week(end) and will backport the changes back upstream to UDStream as well.

Collabora barebecue

Unfortunately, after two weeks of very hot weather, the summer started to fade a bit at the beginning of the conference. Now, this isn’t that bad for a conference, it makes being inside much more bearable, but it is a shame for beach parties. We were having a barbecue at “Beach Company”, but no swimming! The party was very well organised, and the vegetarians were happy with their own stuff and barbecue, and everyone had a great time. New to most of the international guests was the presence of large quantities of the Dutch version of satay sauce (or ‘peanut sauce’), which we seem to put in litres on everything, according to some of them.

Last words

Tomorrow will already be the last day of the conference! I can’t believe that after all these months of preparation GUADEC 2010 will be over! I can surely say that it has been a great fun so far and I’ve met some really nice people. Despite some problems with ordered goods (ahem, t-shirts, ahem), there weren’t any major problems and I’m glad that everyone seems to be enjoying the conference so much.

On to a great last day!

I started to wonder about the use and desirableness of non-English posts on Planet Ubuntu after a comment from LoCo Council member Laura Czajkowski on my blog post Realise native English speakers are privileged. She said: We have many ubuntu members who do not post on planet.ubuntu.com as they feel it has to be in English which is unfortunate as I’d love to read them – we all can use a web translator.

That is something I personally agree with. I see Planet Ubuntu as a window into the general Ubuntu community, not necessarily just the English speaking part of it. After all, when you want language-specific content your LoCo can always provide their own Planet.

However, before bombarding the Planet with posts in a language that not everyone understands I would like to discuss this first and at the same time point at the lack of rules and guidelines there seems to be for Planet Ubuntu. We’ve seen how this can cause confusion and irritation lately when people questioned the appearance of notably Dell, but also other entities. It was their opinion that Planet Ubuntu should be for Ubuntu Members, on a personal title, only.

I’m in favour of allowing everyone to post in their favourite language on Planet Ubuntu. It would make it more useful for more people to read the planet, which would expose them to the rest of the community as well, and it would reflect the international nature of the community better. On top of that, it would allow us all to follow parts of the community that now remain ‘hidden’, by either testing our foreign-language skills, or by testing the quality of the online translation tools.

A possible downside to officially opening Planet Ubuntu for every language could be that it would be less clear what to expect when visiting it. Now people that can speak English know they can go to the planet and read everything. However, this requires mostly a change in behaviour and if people want an English-only planet they can always set one up, no?

What do you, dear (Planet Ubuntu) readers think? Do you want multilingual blog posts, like me? Or are you opposed to it? Please leave a comment.

The days of Latin and French as the lingua francas of the world are long over and we all know that English has taken its place. Especially IT is dominated by the language. Virtually all documentation and function naming is done in English, as well as almost all the communication. There are not many languages that have their own words for ‘computer’ or ‘internet’, or ‘software’ and ‘hardware’ for that matter.

It is logically, of course, to use this language now. It makes no sense to try to get everyone to learn Swedish all out of the sudden because we like that better. If you want to successfully communicate online and participate in an open source community you’ll need English. However, this is the cause of a large inequality between native and non-native speakers.

It comes clear when you take a look at what happens when you’re not a proficient English user. When your English isn’t correct:

• people will take you less seriously and treat you more like a child or an ignorant person;
• you find it harder to express yourself and to make your intentions to someone else;
• using it takes more energy and is more frustrating, meaning you’re less likely to use it;
• you’ll be more often misunderstood and/or be considered harsh, causing negative feedback;
• you find it harder to understand documentation, HowTos, blog posts and other community-vital information.

These points all discourage less fluent persons to contribute to discussions, to speak up. This is very clearly demonstrated by the relative high amount of Americans, and other contributors of English speaking countries, in the community, especially in key roles.

The United States with 300 million inhabitants is smaller than geographical Europe with 731 million people, or the EU with 501 million. Still there are many more Americans visible in the open source projects. There are only about 70 million native English speakers in Europe, from Ireland and Great Britain.

But lets start about India, Indonesia and China. All these countries have populations of less or more than one billion people. That is huge! Ubuntu also seems to be very popular there. Still we don’t see as many contributors from those countries as we see from English speaking countries.

Of course there are many factors that have to do with the diversity and origins of the community members. However, this doesn’t explain everything. India, Indonesia, Brazil and China might still be working very hard on making broadband accessible to everyone, but (Western) Europe has mostly far better internet connections than a lot of parts of Northern America.

I think that one very important reason for this is the fact that not everyone speaks good English, and for a lot of people who do speak English using it is still not as simple as using their native language. You can never learn a second language as good as your native language and it does cost a lot of energy for many people to use it when reading, writing, speaking and listening.

That is a barrier to them to contribute to the open source communities, so they stay in their LoCos or hang around a bit in the international community, but don’t do as much as they could or would like to do, because they find it costs too much energy or it too hard to learn or do because of the language. For most voluntary contributors Ubuntu is something they do in their leisure time, as a hobby. When your hobby is mostly hard and not as fun as other things you could do in the same time, it is not hard to decide not to contribute.

This is probably costing us more contributors than gender or race inequality. It is also something that is harder to solve since you can’t take away all problems by simply educating people and raising their consciousnesses. There will always remain a language barrier.

Raising consciousness does help, though. First of all I would like to make all native English speakers realise that they are in fact — every one of them, including those with dyslexia — very privileged over non-native speakers.

Secondly I would like to ask everyone in the community — also the non-native speakers — to take into account someone’s proficiency when reading a mail written in bad English. It might be tempting, unconsciously, to dismiss the email and consider the author as someone who didn’t bother to write it in proper English. However, please consider that this might be the best English of the author. Give the author a chance regardless.

Thirdly I would like to ask everyone in the community to realise how important localisation and translations are, of the interface and the documentation. Americans are very privileged that they have their whole system, from the texts in some obscure application from universe to their default currency, localised by default. They never have to adapt when a certain application is only available in US English, or when a command line calendar is following their historic conversions. Others do.

Checking the Ubuntu community

I wanted to end this post with an overview of the different councils of the Ubuntu community and the countries of origin/native languages of their members. Just read the data and consider it.

Community Council

Forum Council

IRC Council

LoCo Council

Technical Board

We willen het makkelijker maken voor mensen om mee te helpen en om te zien wat er gebeurt. Want het is eigenlijk te gek dat een lokale gemeenschap voor een opensourceproject bestuurt wordt alsof het een fanforum is. Het zou veel makkelijker moeten zijn om mee te praten, ook al is het niet veel. Dan krijg je sneller mensen die meehelpen naar hun kunnen. Alle kleine beetjes helpen, en iederen moet mee kunnen doen. Dat is wat opensource is, en dat is waar we naartoe moeten.

Het viel me op tijdens het overleg over het voorgaande dat veel mensen het forum van Ubuntu NL gelijkstelden aan Ubuntu NL zelf. Klaarblijkelijk lijkt het forum voor veel mensen zo belangrijk dat ze het gevoel hebben dat het forum alles is. Dat is niet zo, en deze blogpost wil ik aangrijpen om dat te benadrukken.

Laten we eerst eens kijken naar wat Ubuntu NL allemaal doet:

• Vertalingen
• Documentatie
• Releaseparties
• Ondersteuning op IRC
• Ondersteuning op een maillijst
• Ondersteuning op het forum

Dat is meer dan het forum. Sommigen zullen delen hiervan zien als een voortzetting van de forumgemeenschap. Maar besef wel dat een redelijk aantal van de mensen die bijdragen aan Ubuntu NL nauwelijks op het forum komen! Niet iedereen — en daar ben ik één van — vindt een forum een prettige manier om te overleggen. Het vertaalteam gebruikt al tijden een maillijst. Dat heeft echter wel als resultaat dat voor veel mensen ze nogal onzichtbaar zijn.

Als we eens kijken naar de aangeraden gebruiken voor LoCo’s van de LoCo-raad op https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamsBestPracticesandGuidelines dan zien we dat ook weer terug. Je ziet dat het forum één van de manieren is waarop ondersteuning gegeven kan worden. Misschien moeten we ook maar duidelijker het forum losweken van het team zelf. Een appart forumbestuur kan sneller beslissingen nemen en zit dichter op het forum, en het zorgt er bovendien voor dat de rest niet mee hoeft te vergaderen over forumonderwerpen.

Het is zo gegroeid dat veel communicatie over het forum gaat. Jammer genoeg lijken fora te stimuleren om nergens anders dan op het forum te kijken. Veel mensen horen enkel aankondigingen als die op het forum geplaatst worden. Het forum is dus de centrale plek geworden waar mensen van de gemeenschap elkaar ontmoeten. Het totale monopolie dat het forum echter op de communicatie lijkt te hebben schrikt wel mensen af om bij te dragen. Ook ik ben lange tijd niet actief voor Ubuntu NL geweest omdat ik gewoon geen zin had om een forum in de gaten te moeten houden.

Het forum heeft alles een beetje opgeslokt, en samen met dat monopolie is het niet onbegrijpelijk dat mensen soms denken dat het forum alles is. Maar het is wel een verkeerde aanname, en een aanname die mensen weg kan houden. Het forum is één van de manieren om te communiceren, maar er zijn meerdere. Bovendien is het slechts een middel.

The definition is this:

“A paper cut is a trivially fixable usability bug that the average user would encounter in default installation of Ubuntu or Kubuntu Desktop Edition.”

The goal is to fix at least 100 paper cuts this cycle. Last cycle we had the same goal, but actually finished 103 — thanks to great upstream participation — and I hope we can break that record for Maverick.

There are ten milestones to which accepted paper cut reports are assigned. Each milestone has a theme.

• Round 1 File Management: Nautilus;
• Round 2 Office: Evolution, OpenOffice.org, gedit, etc;
• Round 3 Social Networking: Empathy, Gwibber;
• Round 4 Miscellaneous;
• Round 5 Photo Management: Shotwell;
• Round 6 Sound and Video: Rhythmbox, Totem, PiTiVi, etc;
• Round 7 GTK+ and Notify OSD;
• Round 8 Miscellaneous;
• Round 9 Software Center: package descriptions;
• Round 10 Software Center: applications from universe that don’t work.

This set of milestones may change and the lists of bugs assigned to them aren’t final. Please also note that you can only work on paper cuts that are on this list. The milestones are a guideline, but please feel free to work on any paper cut with the status ‘Triaged’, your work will be appreciated! A list of paper cuts with the ‘Triaged’ status.

When you have chosen to fix a paper cut, please make sure you check the upstream bug report if it is there. Once you have fixed a paper cut and have got a patch ready, please attach it to the paper cut bug report and we will be very happy to accept it.

We are also looking for stories. Have you fixed a paper cut? Tell us how you did! Blog about it, or send your story to Jorge Castro or Jono Bacon.

If you want to work on Kubuntu you can find a list of paper cuts by searching for the ‘kde’ tag.

The two new tags are ‘app-menu‘ and ‘trayaway‘. The first one is for problems that show up in applications when the Application Menu is enabled. Currently there are no bugs using that tag. The second tag is for the Notification Area transition; some applications still refer to the tray in their settings and dialogues, but that should be removed once the tray is gone as well.

Indicator Application

Another tag we’ve been using last cycle was ‘indicator-application‘, for bugs related to the Application Indicators. At first the tag was mostly used for applications that needed to be ported to Application Indicators — the tag still gives you a nice list if you want to do some work — but later in the cycle bug reports about issues with the implementation of Application Indicators in the users also ended up on this list.

Usage

I would like to ask everyone at the two lists to use the tags when necessary. But only when necessary, because if we want to make sure the list of bugs under a certain tag remains usable we need to tag with care.

This means: don’t tag bugs reported against the packages of the projects themselves; i.e. don’t tag bug reports reported against the ’indicator-application’ package with ‘indicator-application’. The tags are purely for issues with those projects in other packages.

Helping out

The tags are a great opportunity for those of you that want to help out with Ubuntu’s desktop experience. Most of the issues you’ll find with these tags are not too hard to fix and would be a great way of getting to know the Ubuntu platform by contributing to the cool stuff. There are still a lot of  applications listed at the overview page of the ‘indicator-application‘ tag that need to be adapted to use an Application Indicator. But once we’re a bit further in the Maverick cycle the other tags will also give you quick access to some bite-size tasks. Fixing those will make a real difference on the desktop!

The complete list of Ayatana tags can be found at the BugSquad’s tag list on the Ubuntu wiki. Please update the wiki page if you start using a new tag.

The forest path between Hoeilaart station and UDS hotel Dolce la Hulpe

I arrived at the evening of Sunday 9 May at the hotel after having walked from the Hoeilaart train station to the Dolce la Hulpe hotel, where the conference was located. Fortunately I had missed the bus in the Netherlands that brought me to the train station where I departed, so I managed to take a quicker bus (makes sense?) and got the earlier train.; the walk from the train station to the hotel was a lot longer than I had anticipated.

Canonical chose the hotel wisely, one could say, because it was completely surrounded by forest and even the village was at least a half an hour walk away. The only escape methods where the expensive cabs or the evening coaches Canonical kindly had provided for. This meant that we had nothing to do than thinking and talking about Ubuntu. Not that this was a bad thing, I enjoyed every minute of the week.

Wireless

Like every hotel upon which a swarm of geeks descends the wireless network of the Dolce la Hulpe lobby also collapsed under the weight of the almost(?) 300 attendees trying to access it at the same time. The routers just couldn’t keep up with the endless requests for new DHCP-leases. Fortunately the network in the conference centre and the auditorium was deployed by the Canonical sysadmins. If I heard it correctly there were about twenty access points flown to the hotel and set up in the auditorium and around the brick core of the conference centre. Those networks did not fail and provided a reliable connection with the outside world. Yay for them!

The design team

The design team was a great example for us all by showing how to learn quickly. During the Lucid cycle they received fierce criticism for some of the changes to the way Ubuntu looks and feels, but soon they started to improve their communication with the community. What the community members want is an explanation of why the change was made, a rationale for the decision. Announcements made for the Maverick cycle where much more elaborate, linking to design specifications on the wiki and showing examples, even before the Ubuntu Developer Summit. Creating a ‘planet’ for the design team has also helped with this by providing the design team with a channel for communicating with the rest of us. It must not have been easy to see your hard work for Ubuntu being rewarded with personal attacks on your blog post, I really hope the frequency will decrease over time as the community gets used to the concept of a design team.

Other teams can learn from this!

The sessions

Room at the UDS Maverick (Mahogany?)

There was a session about providing people wanting to write applications for Ubuntu with clear information on how to do so. At developer.ubuntu.com we’ll be creating a site that gives a comprehensive overview of the Ubuntu platform — i.e. the libraries that are used and recommended by Ubuntu — and links to more extensive documentation, like the yet-to-be-written Ubuntu Developers Manual. We want to make it very easy to Quickly write an application that scratches your itch and integrates well with the Ubuntu desktop.

During another session we’ve discussed the Bug Squad Mentorship programme, which didn’t work very well during the Lucid cycle. The people that had offered to mentor didn’t accept a lot of students, and the people that got accepted as a student didn’t always turn up. However, a mentorship programme has a lot of potential and we want to get this working. Therefore hggdh, Pedro Villavicencio, Charlie Kravetz and I volunteered to be the Bug Squad Mentorship administrators. Our task will be to couple students to mentors. At the moment we’re in the process of cleaning up, if you’re considering to request mentorship, please wait. All current students and mentors should have been mailed with a question regarding their current status and whether they are still interested. See the blueprint if you want to know more.

We’ve also discussed the status of the Adopt-an-Upstream and Adopt-a-Package projects. We’re happy to see that people are taking part in it, but we would like to see some more participation in the larger projects. Work will be done on making the documentation more clear, as well as adding more information when necessary. The blueprint contains the work-items.

In between or during the sessions I also found some time to talk with the sole Ubuntu NL and the Ubuntu BE members I’ve seen about Ubuntu NL. We had some nice discussions and I was really glad to meet them In Real Life. As a matter of fact I’ve met the same amount of people from New Zealand as from the Netherlands. To me that really is a powerful demonstration of the language barrier for participating in the international community. English is vital, but this is a disadvantage to non-native speakers. Not only will non-native speakers have more trouble eloquently selling their ideas to eloquent native speakers, but a lot of the non-native speakers actually never learn English good enough to contribute internationally.

Motivation

What can really motivate me, I’ve discovered at the UDS, are exciting new things. The prospect of Unity coming true, or even Scott James Remnant‘s awesome sounding plans for Upstart in Maverick make I cannot wait for those to become reality and I’m proud to be active in a community that produces this wonderful operating system. Maverick promises to become a great release already, imagine what 12.04 is going to look like!

Af en toe organiseren ze een wedstrijd om de aandacht de vestigen op de problemen die er zijn en om vrouwen aan te moedigen actief te worden in de gemeenschap. Nu hebben ze een nieuwe wedstrijd georganiseerd: ‘World Play Day’. Over het algemeen zijn het vooral mannen en jongens die worden afgebeeld als gebruikers van technolgie; het doel van deze wedstrijd is het verzamelen van foto’s waarop meisjes — jonger dan 12 — te zien zijn die met Ubuntu.

Er zijn twee prijzen te winnen: de winnaar wordt aangewezen met behulp van een verkiezing. Het meisje op de foto dat door de gemeenschap wordt uitgekozen als de beste wint een Dell Mini 10n. De andere prijs wordt verloot door een willekeurige deelnemer te trekken uit de inzendingen. Het meisje op deze foto krijgt een verzameling ‘Ubuntu-goodies’: een muismat, Silly putty, een Ubuntu notepad(gerecycled), een Ubuntu pen, een Ubuntu keycord en een Ubuntu t-shirt.

De volledige aankondigen — met alle regels nog even duidelijk op een rijtje — is te vinden op http://wiki.ubuntu-women.org/Events/Competitions/WorldPlayDay/Announcement.
Inzenden kan tot 1:59 op 15 mei. (23:59 UTC, 14 mei).
Dit bericht was een aangepaste versie van een onderwerp dat ik eerder op het Ubuntu NL forum opende. Zie http://forum.ubuntu-nl.org/offtopic/’ubuntu-women’-wedstrijd-world-play-day/.

Lean menu, slick icon!

It has been a while since I blogged about giving Transmission an Application Indicator. In that post I said I was also working on giving Banshee an Application Indicator, bug #518171. Since then we’ve decided to not provide the indicator in the Banshee.NotificationArea extension, the default tray icon in Lucid still. Instead I’ve moved the code I already had over to a separate extension that has become part of the Banshee Community Extensions. The Banshee Community Extensions project, or BCE, is a set of extensions that are not part of the Banshee core, but shipped separately. The entry-barrier for new extensions is lower — useful if you’re submitting yours just before the 1.6.0 release — and they are hosted at Gitorious, which makes cooperation a lot easier.

Bertrand Lorentz accepted my merge proposal at 27 March and was so kind to clean up the code a bit and since then the Banshee.AppIndicator extension has been available from the BCE code repository.

Using Banshee.AppIndicator on Ubuntu 10.04 “Lucid Lynx”

Thanks to the hard work of Chow Loong Jin Banshee.AppIndicator was one of the community extensions that got packaged in Debian and later synced by Ubuntu. If you want to use the Application Indicator for Banshee you first need to install the banshee-extension-appindicator package. Install ‘banshee-extension-appindicator’. At the moment there is a small packaging bug in banshee-extension-appindicator, it should depend on the libappindicator0-cil package, but it doesn’t. You can work around this issue by manually installing libappindciator0-cil.

Once you’ve installed you first need to disable the Banshee.NotificationArea extension. Go to Edit->Preferences–>Extensions, scroll down and untick the checkbox for the “Notification Area Icon” extension. Now scroll up again and enable “Application Indicator for Banshee”. Done!

You improve your relation with a project if you invest in it, and that is good for the quality of the project and Ubuntu. I would like to make you aware of a great way of being nice to upstreams: Adopt-an-Upstream. Slick name! But what is it? It is part of something a group of people from the community team lead by Jorge Castro have been working on ince the last UDS. The goal was to make it easier for upstream developers to find out how Ubuntu works and to improve the relations and synergy between up- and downstream.

At the wiki a starting point was created for upstreams where they can find an overview of the information that matters to them. Furthermore, a guide was created for upstreams that would like to get included in Ubuntu, but would like an overview of the requirements, the dos and the don’ts.

For members of the Ubuntu community there is something else: Adopt-an-Upstream is a way of taking care of a specific project that is included in Ubuntu. It’s mainly about being the communicational glue between up- and downstream. A comprehensive list of tasks:

• watch what’s going on upstream
• make sure new releases get to Ubuntu
• forward patches from Ubuntu to upstream
• communicate release schedules and announcements from Ubuntu to upstream

Summarised: act like a bridge between Ubuntu and the upstream project. Do you have an application you really like, or you really know a lot of, please consider to adopt it. Of course you don’t have to do it all on your own. Especially for large — be it in size, functionality or the number of bug reports — applications this can be a burdensome task. Those applications can be adopted by a group of people.

Next week Thursday 11 March at 17.00 UTC and on Thursday 18 March at 23.oo UTC Jorge Castro and I will be giving a one-hour session in #ubuntu-classroom at Freenode about Adopt-an-Upstream. We will explain the project more thoroughly and show how you can help out. Also, we will mention the Adopt-a-Package programme, which could be considered a part of Adopt-an-Upstream. If you consider getting involved in either one of these projects, please join one of the two sessions!

Questions? Please leave a comment!

Are you still out there, lone Ubuntu Karmic user? You must feel quite deserted with all the awesomeness and shiny new stuff that draws everyone’s attention to Ubuntu 10.04 ‘Lucid Lynx’. I hope you can forgive us.

To make up for the lack of attention I decided to provide Indicator Application for Ubuntu Karmic. I’ve changed two dependencies in Indicator Application’s control file — back in Karmic we were still providing some pkg-config (.pc) files for Mono assemblies in their main package rather than in separate ‘-dev’ packages — and uploaded it for Karmic to a PPA: ppa:qense/appind-karmic.
If you want to add it you can add ‘ppa:qense/appind-karmic’ to your Software Sources in System->Manage->Software Properties=>Other Software=>Add and download the archive’s GPG key, or use the command sudo add-apt-repository ppa:qense/appind-karmic.

WARNING: I haven’t tested if it works, I just made sure it built correctly. Be careful and please report all problems here and not on Launchpad since Ubuntu Karmic isn’t supposed to run the Indicator Application.

Also make sure to reload your Indicator Applet after you’ve updated to make the service load.

Ubuntu Opportunistic Developer Week

OK, I admit it, I lied to you. I didn’t provide the PPA just to please those poor Karmic users. As you may already have seen in Jono’s blog post containing today’s UODW schedule — complete schedule at the wiki — I’ll be giving a session about using Indicator Application in your application at 19.00 UTC this evening. Because a lot of people are obviously still using Ubuntu 9.10 ‘Karmic Koala’ I wanted to provide a way for them to try it out without having to upgrade.

If you’re going to attend, are using Karmic and would like to see AppIndidcator in action on your computer, you can use this PPA to do that. If you’ve got any question, please don’t hesitate to ask here, on this website, or at IRC in #ayatana on Freenode; I’m ‘qense’ there.

We keep track of applications that need support for Indicator Application on Launchpad with the bug tag ‘indicator-application‘: the list of bugs against applications that need Indicator Application support. There are code snippets on the wiki page of Application Indicator but in this blog post for those who would like to use it in their application.

I recently added support for Indicator Application to Lernid, Bzr-Gtk and Transmission and am now working on getting it into Banshee. How do you help Ubuntu with adding support to existing applications? I’ll try to make that clear in this blog post.

#1. Find something to work on. That list of bugs against applications that need Indicator Application support is a great place to start looking. Don’t forget to mark a bug as ‘In Progress’ when you’re actively working on it!

#2. We’re adding support to an application that is most likely used on more places than just Ubuntu. Therefore you should keep in mind that not only enabling Indicator Application support should be easy, but also disabling it. This means you’ll have to do some Autotools magic in order to make sure libappindicator is present and it is wanted. At the AppIndicator wiki page there is an example autotools macro. This should be added to the ./configure.ac, which can mostly be found in the project’s source code root directory.You may have to adapt this in order to make it fit in the existing makefiles.
NOTICE: The previously mentioned autotools example was written with the programming language C in mind. When you’re writing in C# you can reuse the code, but please keep in mind that you should check for ‘appindicator-sharp-0.1′ rather than ‘appindicator-0.1′. The whole check isn’t necessary for Python.

#3. Now we can start writing the code. Finally! I’m afraid I have to disappoint you, because the code itself is the least work of the whole procedure. Again, there is a Porting Guide at the wiki page with examples for all supported languages. Those are pretty straightforward, so I won’t repeat them here, but if you still have questions, don’t hesitate to leave a comment. Important is that you should use the previously defined autotools variable HAVE_APPINDICATOR (when programming in C) to allow the application to be compiled with a GtkStatusIcon as well, on other systems. You can do that like this:

#ifdef HAVE_APPINDICATOR
 #include <libappindicator/app-indicator.h>
#endif

(other code)

#ifdef HAVE_APPINDICATOR
(Indicator Application code here)
#else
(leave the old GtkStatusIcon code here)
#endif

#4. Now that the code and build macros have been written — and the configure script and the makefiles regenerated — and you’ve tested it (naturally), it’s time to submit your wonderful patch. Of course you do this on the bug report we’ve got in Launchpad, but we also would like you to forward the patch upstream. If there was not yet a bug report in the bug tracker of the application you ported, report one and link it to the Launchpad bug report. In the upstream bug report, leave a comment with your patch.

After that you’re done. Congratulations, you’ve helped with making the systray cleaner and prettier and more consistent. This makes us happy!

Every day a lot of new bugs are reported on Launchpad, adding to the number of open bugs reported against Ubuntu. Currently there are 81259 open bugs in Ubuntu, of which 43775 are in the ‘New’ state. This means that roughly 54% of all open bugs in Ubuntu are not or were barely touched and when this post will have been published the number is already larger. When handling such large numbers of bug even the omnipotent BugSquad can’t keep up. How can we make sure the important bugs don’t get lost in this superabundance of support requests for writing good defect reports?

If you’re working with something — in the case of Adopt-a-Package an application — you like, you’re more productive. If you work on something you can keep an overview of, work is easier. This is what Adopt-a-Package purports. You choose an application you’re familiar with, or particularly fond of, and focus on getting it into shape on Launchpad. What does this mean? A small list:

• Triaging previously untriaged — ‘New’ — bugs
• Making sure no bugs are forgotten
• Moving Confirmed bugs to Triaged
• Forwarding bugs upstream

There are several ways to tackle the adoption. If you would like to adopt something as big as GDM[1] you’ll have a hard time if you’d try to do it all on your own, unless you have a lot of spare time. In such cases it’s better to form an AdoptionTeam and attack the bugs together with some other people. Smaller applications like ‘gedit‘ can be handled by one person, although it largely depends on your personal preferences and the amount of time you’re able or willing to spend on triaging. Of course you could always look for an existing group to join. As a matter of fact, I’m still looking for some more people to help out with Nautilus.

Adopt-a-Package is thoroughly explained on its wiki page, and it is that page you should use as your primary source of information. On this page you find a list of currently adopted applications and applications that we’d really like to see adopted. When you decide to adopt an application, whether you do it with a group or on your own, please check this page first to make sure you’re not duplicating efforts. After you’ve made up your mind about what you’re going to adopt, please add your name and the application to the list and notify the BugSquad maillist.

Are you interested but still have got some questions now you’ve read this? Don’t hesitate to leave a comment or drop by in the #ubuntu-bugs IRC channel. Also, in March there will be two sessions about Adopt-an-Upstream in #ubuntu-classroom, one by me at 4 March on 17.00 UTC and one by Jorge Castro at 18 March on 23.oo UTC. You can find them listed in the Ubuntu Classroom schedule.

Activities

Most people know me as a member of the Ubuntu Bug Control team, which I fist applied to in 2006, first joined in 2007 and then rejoined in 2008. That last year was the year I started to really contribute significantly to Ubuntu and slowly started to show my face at more and more different places. I’m a bug triager, foster-parent of Nautilus, and a Brainstorm Idea Reviewer.

Ubuntu Wanted is also a project I’ve started, but it’s really behind schedule for something that was discussed during UDS-J in Barcelona. I apologise for that; the Drupal module just grew too big and Launchpad integration was too hard for it to become something satisfying. However, I’ve restarted the project and am currently working on writing an implementation with Django when I’ve got some time on my hands. The code can be found in lp:ubuntu-wanted, but please bear in mind that I’ve already got something completely different on my own work-station. However, I wait with committing it until it works and doesn’t throw errors with everything you do. At the moment most work is going into writing Django Middleware that injects a connected and authenticated Launchpad object in the request object.

As you can see on the Classroom wiki-page there are two sessions planned about Adopt-an-Upstream; I will do the first at 4 March and Jorge Castro will do the second at 18 March. If you’re interested in working on a specific area or with a certain upstream, but would like to know more about it: come to the session!

Names
In spite of what (too) many people seem to think, is my first name not English nor a nickname. My full name is Sense Egbert Hofstede, but I usually just use Sense Hofstede, which should be pronounced like this: [ˈsɛn.sə ˈɦɔf.steːdə]. The first name derived from the Germanic derivation Sint and changed via Sent and Sens to Sense. It means ‘sent’. My last name is the Dutch word for ‘homestead’. I’m the sixth Sense of the family, ‘Sense’ is common in my progeny.

My first name is often already taken whenever I need to pick a nickname, so in the end of 2005 I came up with ‘qense’. It’s close to my real name, but since the first letter is replaced with a not-so-common letter  usually available. At least it’s not used as the name for graphical interfaces, sexual education campaigns, margarine, companies, charities or bands.

AdoptionStats generates a data list and constantly returns it in the same format and therefore the results can easily be manipulated by other scripts, e.g. for generating graphs.

Use

I’ve pushed to script to a Bazaar branch on Launchpad: lp:~qense/+junk/adoptionstats. If you haven’t done it yet, install Bazaar and download the code with the command “bzr branch lp:~qense/+junk/adoptionstats” .

The script depends on the package ‘python-launchpad-bugs’, execute the command “sudo apt-get install python-launchpadlib” python-launchpad-bugs or click here click here to install it if you haven’t installed it yet.
(now using python-launchpadlib, thanks to thekorn)

The usage is very simple, but make sure you’ve made the script executable — right-click->Properties->Permissions->check ‘Allow execution of this file’, or just “chmod +x ./adoptionstats” . For getting a report on the current status of the ‘nautilus’ source package you enter the command “./adoptionstats -p nautilus” in the directory you save the file. The result is like this:

2010-01-21 16:15 {'need_forwarding': 5, 'per_status': {'In Progress': 3, 'Confirmed': 0, 'Invalid': 2279, 'New': 34, 'Fix Committed': 1, 'Triaged': 583, 'Fix Released': 754, 'Incomplete': 158, "Won't Fix": 16}}

Since the application uses optparse you can get the help text with “./adoptionstats -h”, but the only other option next to ‘-p’ and ‘-h’ is ‘-v’, which enables the printing of debug-level messages to your commandline.

So far everything’s going quite fine actually, booting has become a lot less scary now the “Segmentation error” message that was the first thing you saw on boot is gone now and I found a way to solve the issues with the NVidia drivers.
Currently the package ‘nvidia-glx-185′ in Lucid is incompatible with the Xserver — ‘nvidia-glx-185′ provides the virtual package ‘xserver-xorg-video-5′, and that conflicts with ‘xorg’, which wants ‘xserver-xorg-video-6′.  Fortunately Collin Pruitt came to rescue with his blog post “Problems With Xorg and the nVidia Drivers“, which explains that you need to use the PPA ppa:nvidia-vdpau/ppa to get newer versions of the NVidia driver, nvidia-glx-195 is the latest release available from this repository, but legacy drivers are also available and should work on Lucid.

If you still get error messages from the Xserver and you can only run it in the safe-graphics mode you should make sure that the NVidia driver is enabled in System->Manage->Hardware Drivers and try again.

New stuff
Understandingly there isn’t much new in Lucid currently, the most striking difference I found was the new lay-out for the Users and Groups (‘users-admin’) configuration utility. The interface is cleaner and simpler and shows details that previously were limited to the About Me-dialogue. I reckon this is part of Canonical’ effort to make account managing easier and more consistent across the desktop, as outlined in the User Account Management-blueprint.

The Ubuntu Software Center is also being worked on, the most distinguished visual addition so far are the nice breadcrumbs that already received a lot of attention on other blogs.

Usplash is now definitely gone from the default installation and ‘libplymouth2′ is already a dependency of ‘mountall’, we’ll see probably more of that in the future. Currently there is no splash whatsoever before GDM is launched, but this is probably going to change. Keep an eye on the Boot experience work-blueprint for updates on the work being done.

I end this blog post with a Warning: the system might seem stable now, but this is because a lot of the changes still need to be made. Do not use a development release in a production environment unless you’re prepared to face the risks.

In order to allow testing of this new version I’ve uploaded both versions to a PPA. Devhelp 2.28.1 is in ppa:qense/devhelp and 2.29.2 — 2.29.3 was a mere version bump –in ppa:qense/devhelp-testing. If you find a bug in the first one, it should be reported against Debian since the only change I made there was adding an entry to the changelog.
For 2.29.2 I copied the ‘debian’-directory from 2.28.1 and removed all patches. Apart from that the only change I made was running ./autogen.sh before uploading to make sure the necessary files were there.

If you’ve got a question, please leave a comment.

If you want some help with getting started, Ubuntu Bug Control has got a mentoring program designed for getting people acquainted with triaging. At BugSquad/GettingInvolved is explained how to request a mentor:

• sign the Code of Conduct
• Although not really required, read the How to Triage guide. It does help to read it 
• request a mentor, via an email to ubuntu-bugcontrol@lists.launchpad.net. In this email, please provide an area of specialisation, if you have any.

I would like to add that including the username of your Launchpad account is most helpful as well, since that makes it easier for us to scan what you’ve done so far.

As always, questions can be asked at our IRC channel, #ubuntu-bugs at FreeNode.

If you’re already quite familiar with triaging and want to help new people, you’re most welcome! Please sign up as a mentor by leaving a little note at the ubuntu-bugcontrol mailist and add yourself to the list at BugSquad/Mentors. This page contains also more information about what is expected of you.

A good way of finding tasks to work on is the list of packages without direct subscribers — people that watch a package for new bug reports and keep it in shape — composed by Brain Murray. The packages on this list don’t have someone to look after them, so they often have a lot of ‘dead wood’, bugs that are old and haven’t been commented on for a long time. You could ask if the problem is still there, and close the bug otherwise.

There are probably also a lot of old bugs that are fixed in the Ubuntu release on which development is focussing right now. These bugs, like all bugs that are fixed in the development version of Ubuntu, should be set to Fix Released, unless they are specifically about a bug in a specific package version in a stable release. Look at Bugs/Status for more information about the meanings of the different bug statuses.

Next to the dead wood there are the normal bugs, you can handle these like you would handle any other new bug. Because these bugs are often not frequently being looked after you’ll won’t have much trouble to find one that’s easy to start your triaging career with.

Some people would like to triage all bugs for a whole package. In that case you adopt a package, which means you first triage all bugs reported against your chosen package and then subscribe to the bugmail for that package to keep an eye on it. More information about that is at BugSquad/AdoptPackage.

Triaging bugs is a very good way to help Ubuntu, get involved!

The PPA is located at https://launchpad.net/~qense/+archive/quickly

Unfortunately I made a mistake with the version, I’ve just added ~ppa1 at the end, but I want to add the Bazaar revision as well in newer versions, something I forgot here. Any thoughts on the possibilites of adding ~bzr{rev-nr.} somewhere?

I’ll manually try to update the package and the end of every day(CEST), provided there’s a new revision.

What is Quickly? According to the ‘Quickly Help Index’ it’s ‘a set of choices about writing apps for Ubuntu.’ Basically, it’s an application that creates a stub of a program for you based on a template. At the moment there’s only one template, which creates an Ubuntu project in Python.

If you’ve created a nice template that isn’t included in the branches yet you can always mail me with a request to add it to the PPA. But I’d recommend you to first try to submit it to Quickly.

(By the way, I’m not involved in the Quickly project, I just sent the source files to my PPA.)

It’s a shame that they didn’t decide to package it themselves. Eclipse is a good and often-used IDE and I think it should be included in the repositories. We don’t have to use Debian for all packages, do we?

Fortunately there is a PPA that offers 3.4, maintained by the Eclipse Team. The PPA can be found at https://launchpad.net/~eclipse-team/+archive/ppa. Unfortunately — there we go again — the amd64 build for jaunty failed. It’s still possible to get it working. Here’s how:

Using the PPA, no ‘Software Updates’ can be installed

People using 32bit can just use the provided PPA without any problems. If you are a 64bit user you’ll have to an earlier, successful build: in this case intrepid. Everything will work just fine.

So, for 32bit use this:

deb http://ppa.launchpad.net/eclipse-team/ppa/ubuntu jaunty main

and for 64bit use this:

deb http://ppa.launchpad.net/eclipse-team/ppa/ubuntu intrepid main

Add this line to source.list with an text-editor or use System->Administration->Software Sources.

Now add the PPA’s key to your keyring using:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5126890CDCC7AFE0

Run the usual command: sudo apt-get update and you can install Eclipse like you usually install programs. However, the Software Updates functionality won’t work.

Using the eclipse.org download, with plugins

You thought this would be the easy way? I’ll have to disappoint you. When I tried to use the official download I ran into some problems that could only be solved by installing the latest — 3.4 — version of Eclipse. So, yes, you’ll have to go to the previous part and follow those instructions too. Install Eclipse and go to Eclipse.org and download the latest version of Eclipse, pick your flavour.

In the archive you’ll find a compiled Eclipse, which can be executed right away. The plugin/Software Updates functionality works.

However, you will have to use Sun’s distribution of Java. Install sun-java6-bin and make it default by executing the command sudo update-java-alternatives -s java-6-sun.

UPDATE: Good news! Ubuntu 10.04 ‘Lucid Lynx’ has got Eclipse 3.5 in the repositories, you can now just install it from the package manager.

Looking good is important for an OS — Mac OS would be a lot less cool if it wouldn’t be considered so well designed — and I think that this is where Linux stays behind. There are a lot of terribly awesome pieces of art out there on the Internet, but they aren’t always that easy to find. For example: the place to be for a good wallpaper is of course deviantART, but you have to know about it’s existence. If you want a good looking theme, go to GNOME-Look.org. There are loads and loads of elements, window borders and, the hardest part to make, icons.

I hope the promised focus on design for the next two Ubuntu releases is going to pay off. Because in my eyes Ubuntu cannot succeed on the desktop without looking good.

Enough chatter, bring on my desktop!

A quick overview of the used components:

• Wallpaper: :UntitledDocument: by ~THFM
• Iconset: GNOME-Colors, Brave
• Window borders: Si(I’m not entirely happy with this one. Any suggestions?)
• Elements: MurrinaGraphiteGentle
  (requires the Murrine engine, install it from the repository)

Conky

As you can see on the screenshot I’m using the wonderful program Conky. This program writes text on your desktop/wallpaper and can be used for all sorts of interesting things. With scripts you could even let it display the status of your coffee maker!

The configuration syntax is rich and although not that complex, takes time to learn. I wanted quick and beautiful results, so I used the CONKY-colors script — unexpectedly written in C — to generate my .conkyrc file. Have a look at it’s description for the installation instructions and make sure you read them carefully.

I used this command to generate my configuration file:

./conky-colors -c brave –cpu 1 –hd –network –weather –weathercode NLXX0012

Please keep in mind that both the resulting file and the required .scripts folder are all hidden by default. Press Ctrl+H in Nautilus to see them or copy the folder and file with terminal commands.

The translation to Dutch are done by myself, although the script does support localisation to some extend, the number of languages supported is limited. (Don’t mind the large amount of English left, that’s normal nowadays in Dutch, unfortunately.)

A lot of people add the command conky -c ‘path/to/conkyrc’ directly to GNOME’s Start-up Applications. although letting Conky start right away might work flawlessly on XFCE, it does give troubles in GNOME and KDE. Therefore you should use a script like the following one to start Conky:

#!/bin/bash
sleep 20 &&
conky -c ~/.conky/conkymain &

Dock

The dock at the bottom of my screen is Avant Window Navigator, right from the repositories. I chose this dock because its appearance is easier to configure and it’s lighter than equivalents like GNOME Do.
Install AWN

The background colours are completely transparant, the only colour is the grey in the border. Doesn’t it look great?

We got a reasonable large group, about 10+ people and a conference pack from Canonical gave us some material. A pitty the leaflets were in English, so not all people were confortable reading them, but thanks to Maarten of OS4Free we didn’t only have Dutch leaflets, but also two demo computers — on a nice demo table! — and a barebone which was used to display a loop of FOSS-related movies on a beamer, in fact the largest beamer of the whole room!

Unfortunately the CD’s that were sent to us were still in Lelystad, so the only CD’s we had were self-made and the four official I took with me — apparantly I was the only one that already had the CD’s, not anymore though.

We had a lot of room, in fact we had one of the largest stands: a rectangular table for showing some stuff and helping with problems and installation and two round tables for showing stuff — one was largely focussed on technologies for disabled, Linux seems to lead here. In the morning we had to share one round table with a person showing Windows 7.

The CD’s were popular and I think we gave about 30+ away, even one to the tech support table. Unfortunately the lecture about installing Ubuntu next to Windows wasn’t very popular, but that was compensated by the many people turning off the offer of a free CD because they already had installed Ubuntu.

At our stand we installed Ubuntu about three times. This went without problems although the Dutch translation doesn’t seem to get fully installed at all occasions. This isn’t new though.

Some pictures, thanks to ‘mr Gee’ and ‘Reekje’ for making and uploading them.

More pictures can be found here and here.