Hey! Welcome to my site. You may want to subscribe to my RSS feed. Thanks for visiting!

The sessions are quite short, most of them just under an hour which works quite well, most sessions have follow-up sessions planned. Refer to http://summit.ubuntu.com/uds-karmic/ for further details.

Improving LoCo Team Events

This was the first session I attended today. We discussed package and bug jams and how it could be improved. Also the possibility of introducing marketing jams where users would get together to produce local marketing content such as posters, CD covers, etc in local languages. A requirement was identified for a Facebook-like events engine. Currently loco-teams are finding Facebook a handy tool for this, and something similar may be included in Launchpad for all Ubuntu related events based on the current sprints scheduler. The community directory is 98% complete, Jono will provide us with more details soon when it’s just about complete.

Refocusing The Ubuntu Spirit

This was mostly a discussion that went into various different directions. The Ubuntu Code of Conduct came up and it was discussed how new users sometimes are a bit too diligent trying to enforce it on everyone else in the community. It was agreed that the CoC is a guideline on how people should conduct themselves and that it shouldn’t be used to through books at people, so to speak. Keeping users and developers motivated was also discussed, and the possibility of some kind of showcase of success stories from users around the world.

Free Culture in Ubuntu

Getting free culture on the Ubuntu discs is hard due to the lack of free space. Free culture could be provided in Ubuntu via links and default subscriptions in Firefox, Liferea, Miro etc.

Tutorial on Upstart and How to Convert to it

Scott James Remnant did an introduction on Upstart. Upstart replaces Init on Ubuntu and migration for all init scripts to Upstart is planned for Karmic. Upstart is quite nifty and replaces lots of duplicate and error-prone work that package maintainers had to implement in init before. You can specify environment variables or put entire scripts into the sections before, during and after a process is started. Upstart also keeps an eye on the list of PID’s that it spawned and won’t break when a user does something like execute “apache2ctl stop”.

Meet Your Users

This was a workshop/discussion about personas, archetypes and stereotypes and how personas are used to define the edges of our user universe. We wrote down who we think our users are and they were posted up the board and sorted in to different groups. I think this was the first BoF I’ve ever attended that was led by a women. Speaking of which, there are much more women attending this UDS than previously. One of the results seem to be that there’s some more attention given to some of the more softer issues in Ubuntu. Hopefully it also means that our community has built a good reputation of being welcomming and mature.

Edubuntu Session Tomorrow

Tomorrow at 9:00 UTC (11:00 in Barcelona) we’re having the Edubuntu session where we’ll discuss the Edubuntu stategy document, it’s been in draft for a while and we will hopefully have it finilized very soon (maube even tomorrow if we’re lucky). Some people couldn’t make it, so we’ll try to keep #edubuntu in sync with discussions if the Internet holds up.

Today I read a post from Matt Zimmerman on the ubuntu-devel list where he says that filing bugs directly to Launchpad is not recommended and not best practice. Instead, Apport should be used whenever possible. Apport assists the user in preparing bug reports that will be as useful as possible to the developers who will have to triage and attend to the bug report in various ways.

Many of us have told users to file a bug on Launchpad when they encounter bugs that should be reported. I’ve done it before as well, which is why I’m reposting the information to spread the word. Apport is good at picking up crashes in many programs and will automatically run and gather crash report data. Often though, bugs aren’t caused by crashes. Even so, you can still submit your bug reports using Apport:

Using the help menu in your program:

In most programs, you can simply click on the Help menu and click on “Report a Problem”. This will invoke Apport and prepare a bug report. If you’re a developer and would like to add Apport suport to your software, please refer to the Apport Developer Howto.

Manually invoking Apport

Perhaps the bug you have encountered prevents you from accessing the Apport menu, or perhaps it’s a program that for various reasons (such as being a command line tool) simply doesn’t have an Apport menu. In such a case, you can press alt+F2 and enter  “ubuntu-bug packagename” where packagename is the name of the package which the bug relates to.

How do you know which package your program belongs to? You can do a search in Synaptic (available from System -> Administration -> Synaptic) or you could check via the command line:

1. Which package does this file belong to?

jonathan@disclaimer:~$ dpkg -S /usr/bin/gnome-terminal
gnome-terminal: /usr/bin/gnome-terminal

2. Search through the APT cache:

jonathan@disclaimer:~$ apt-cache search gnome-terminal
gnome-terminal - The GNOME 2 terminal emulator application
gnome-terminal-data - Data files for the GNOME terminal emulator

The Ubuntu developers expect a big surge in bug reports following up to the release of Ubuntu 9.04 (Jaunty Jackalope), which is due on 23 April. When everyone does their part to make bug reports as good as possible, then there’s less work for the developers and bugs get sorted out quicker!

AJ Venter writes that we need more, not less Linux distributions. We’ve discussed it to a degree on the #clug IRC channel, where AJ Venter also sometimes hangs out as silentcoder. I wanted to discuss it with him, but he said that he doesn’t want to discuss it over IRC and also blogged that he doesn’t want to. He says that he really wants to discuss it over comments on the post instead.  Since he has disabled comments on the blog post in question, I decided to write this blog-reply.

I’m not convinced that we need more distributions. More distributions would result in huge duplication of work:

• Additional bug trackers
• More packaging work
• Relationships between maintainers and upstream projects
• Documentation
• Additional installer work
• … and there’s probably a lot more

There’s also very little benefit from doing a whole new distribution from scratch. Doing a custom installation from an existing distribution has plenty of benefits:

• Existing installers
• Lots of existing packages
• Most common issues are known and can be tracked in the distribution’s bug tracker

Distributions such as Debian and Ubuntu are super-easy to adapt, and there are very few use-cases that could warrant doing a distribution from scratch as apposed to doing a custom install disc of those two systems. Ubuntu’s parent company, Canonical, even goes a step further by offering free hosting for free software packages via the Launchpad PPA service.

I don’t think AJ’s “diversity” “arguement” is solid or even makes a proper case for the need for more distributions. You can have diversity and satisfy a wide array of unique use cases by leveraging the work of  the existing distributions, without being wasteful and duplicating effort unnecesarily.

Possible Hardware Damaging Bug

Linux 2.6.27 has a serious bug where it can permanently disable your e1000 ethernet device by damaging the firmware stored on the device. Linux 2.6.27 has recently been included in the Ubuntu 8.10 (Intrepid Ibex) alphas. Testing the Ubuntu 8.10 alphas on your e1000 hardware is potentially very dangerous.

If you’re unsure whether you have an e1000 card, and if you’re running a previous Intrepid alpha, or if you’d like to try it out, it might be best to check first. You can check whether you have an e1000 network card with the “lspci” command in a terminal, which will show you a list of PCI connected hardware. You can also check whether you have the e1000 module currently loaded by typing “lspci  | grep e1000″. If your’e still unsure, please ask a friend to help you check.

Bug report in Launchpad

The Ubuntu bug report on this matter states:

In some circumstances it appears possible for the 2.6.27-rc kernels to corrupt the NVRAM used by some Intel network parts to store data such as MAC addresses. This is limited to the new e1000e driver, and reports have only appeared from users of “82566 and 82567 based LAN parts (ich8 and ich9)” (to quote Intel). The reports seem to be isolated to laptops, but it is not clear if this is because desktop/server parts are not vulnerable, or if use cases simply increase the chances of laptop users being hit.

It’s not clear whether users of older e1000 cards are affected, but on-board ethernet devices typically aren’t easy to replace, so I suggest you play it safe until there is more clarity on the issue.

Developer announcement

An announcement has been made on the ubuntu-devel-announce list, which states that users who do testing should be informed of this problem:

While we expect alphas to include a fair number of bugs, and rely on your continued support and testing to help resolve these bugs for Ubuntu releases, bugs that damage hardware are quite another matter.  As a result of this bug we must recommend that users do *not* use Intrepid alphas, including the LiveCDs, on machines with Intel GigE ethernet.

Please tell your friends who use Intel Gigabit network cards to be careful, and not use Intrepid Alphas or Betas until this issue has been known to be resolved.

In The Meantime

Testing of the Ubuntu 8.10 pre-release versions is still strongly necessery and encouraged. If you are affected by this bug, you can test Ubuntu in a virtualised environment in the meantime using either of the following (linking to instructions):

• VirtualBox
• KVM
• VMWare
• Xen

If you’re looking for the quickest and easiest option, I recommend VirtualBox.

Update:

The e1000e module will be removed from the module-init-tools package, preventing it from being loaded. This is hopefully a temporary solution, according to Tim Gardner:

Pursuant to discussions on this list, ongoing discussions in the bug
report (Bug #263555), and IRC chats with our release manager Steve
Langasek I've uploaded module-init-tools_3.3-pre11-4ubuntu10 to Intrepid
with a blacklist file for e1000e. Hopefully this is a temporary measure.

When the updated module-init-tools makes it into the archive, the daily builds should be completely safe to use on your computer with an e1000 card. The downside is that your ethernet card won’t work. On desktop machines, it’s usual to have a spare PCI slot and quite easy to add another cheap ethernet card. On servers it’s not always the case, and on laptops it’s certainly not, so don’t take any big chances. I’m hoping badly that this is just a temporary solution. The release date is already starting to loom, and the beta is imminent. Shipping an Ubuntu version where ethernet adaptors don’t work will not be cool.

A bit more than a week ago I learned how to generate debdiffs. I wish I knew how to do it earlier, since it’s incredibly easy, and very empowering.

Previously, when working on bugs on Launchpad, all I could really do is make comments on what causes the bug, and make suggestions on how to fix it. Now, I can actually fix it myself, and attach the debdiff that can be applied to the current package that will fix it. It’s awesome, all you really need to do is download a source package, make the required changes, bump up the version number, create a new source package and then create the debdiff between the original and modified source packages. And all it takes to create the debdiff is just one simple command.

I’ve learned parts of the above previously from the Ubuntu-MOTU classes, but what made it much easier for me is the MOTU Videos, which you can get on YouTube, or if you want to view it off-line (like I did), you can download it via http.

I won’t achieve my goal of becoming a MOTU by the end of this month, as I said I wanted to nearly three months ago, but I’ve learned a lot the last month or so, and I’m glad that I’ve actually made some progress. I’ll just have to work a bit harder and maintain/gain momentum. The MOTU’s have been great with helping out and giving advice. A big thank you to all of you, especially the friendly people of #ubuntu-motu.

Storm, the Python-based ORM used by Launchpad, has been released under a free license. In a bug report comment, our benevolent dictator stated that “We are all actively working on making Launchpad open source.”. I hope that this is just the first step, and that we’ll see more components being re-licensed soon. I don’t understand how keeping Launchpad proprietary will make Canonical more money, but I’ve decided to trust their judgment and their business plan.

I’m not sure if I should trust Apple that much though. They have purchased CUPS, the printing system used in Ubuntu and many other unix-like systems. Apple has licensed CUPS for MacOS X for several years now, and many people have questions on the reasons for the buy-out. I’ve been wondering whether Apple has some fears around the freshly released GPLv3. Apple has manufactured printers in the past (I’m not sure if they still do), and they probably own a significant amount of patents regarding to printing.

I don’t have anything to base it on, but perhaps they anticipated CUPS being released under the GPLv3, which might have an affect on the value of their patents if they ship CUPS in MacOS. Buying out CUPS means that they can keep the software under the older license, which does not cover patents. Maybe, it’s nothing like that at all. Perhaps we’ll see CUPS getting even better, and be able to get great commercial support for CUPS directly from Apple. I guess we’ll just have to wait and see.