Snapifying Normal Ubuntu Packages

I’ve been playing with Ubuntu Snappy and wanted a way to bundle up traditional Ubuntu programs into a snap package.

So I wrote a script to do so! Introducing deb2snap. It isn’t perfect, but it can do some neat stuff already.

Full instructions and examples can be found on the homepage, but to whet your appetite:

./deb2snap fortune
./deb2snap --mir mir_demo_client_fingerpaint
./deb2snap --xmir xfreerdp

Now On the Desktop Team

I know I just recently posted about how awesome working in the OEM Services department was, but in the eternal quest for new challenges, I’ve moved over to the Desktop team at Canonical.

But before I get to that, one quick bonus story about a patch that I wrote in OEM Services that I really like. You know how when you plug in headphones with a standard audio jack that the audio immediately switches to headphones only? Nice feature right? Now plug in your USB headset. You’ll notice that it didn’t play through the headset: you have to go to the sound preferences tab and choose it as your output device, which is not intuitive. Same deal with bluetooth headsets.

From the user’s perspective, they should all work the same. They’re all just headsets. So for an OEM project, I wrote a pulseaudio module that tried to do just that: whenever a new pulseaudio sink or source became connected, it would switch to using it. It may need some polish (I’m no pulseaudio maintainer), but it works fine. I’d love to see it applied upstream.

Anyway, so I’m switching to the Desktop team to help work on Quickly and other application developer goodness. Speaking of which if you’re a developer, I have a session tomorrow all about release management as part of the App Developer Week: What’s the deal with time based vs feature based releases? How do I best use these Series and Milestone things in Launchpad? Find out tomorrow in #ubuntu-classroom at 14:00 UTC!

What I Do in OEM Services

I realize that I’ve never really blogged about my work at Canonical. Largely because I work in the OEM Services department, and we tend to be hush-hush. OEM means Original Equipment Manufacturer and just means a company that makes and sells computers with their own brand (like HP, Dell, Lenovo). OEM Services is the group that works with OEMs that are interested in preloading Ubuntu. Anyway, with everyone else on the planet talking about their work, it is a good time to share what I actually do and why.

I feel that making it easy to buy a machine with Linux preloaded is the most important task facing the wider FOSS community. This is how we grow the community, how we break into the mainstream.

But working with OEMs also brings more immediate benefits. When working on a specific project, both the OEM and Canonical will have QA resources dedicated to finding bad bugs or usability issues.

OEMs tend to approach QA with a subtly different eye than I do as an independent developer. They tend to try to avoid any situation where a customer will request support, as that costs money. Which means trying to avoid loss of functionality or letting the user shoot themselves in the foot.

But another thing that comes out of such attention is a focus on usability bugs. It feels really good to be able to spend time making a patch for such nits and send it upstream.

For example, here is a random sampling of stuff that I remember working on:

  • Back during the beginnings of a netbook version of Ubuntu, I helped write lots of little patches for applications to make them fit on smaller screens. OEMs would understandably hate it when a program wouldn’t fit on the screen because users wouldn’t be able to click on the dialog buttons and it just looked awful.
  • The dialog prompt for PolicyKit used to always display names like “Michael Terry,,,” which always struck me as an eyesore. It showed that way because it didn’t strip the commas from the information that getpwnam() returned.
  • When the user sets an unusual “how long to idle before blanking the screen” value, that value just didn’t show up at all in the GNOME Power Preferences dialog. This usually doesn’t come up in practice, but arose because an OEM wanted a 15 min delay, which is not a value already in the list.
  • The first time you opened rhythmbox and tried to import a folder, you got a scary “operation not supported” error message. Trying again worked fine. It was a simple fix, but one of those things that you rarely run into and if you do, just kind of shrug off and try again. But it’s nice to be able to fix such first-impressions papercuts.
  • A crash in pidgin if you used a zephyr account, enabled tzc, and didn’t have tzc installed. Not only did it crash pidgin, but X itself! This is one of my favorites because it shows just how useful an OEM’s QA approach to testing is. They really “test to break,” and exercise parts of the systems that don’t get much use. This crash was not triggered by a common use case, but had a really bad effect.

So none of these are earth-shattering fixes or cool new features. Mostly because by the time the software gets to me, it’s already as part of an Ubuntu release and thus mostly functional. I just tend to nibble around the edges. There’s a large untapped market of FOSS users that will never install an OS, and I get warm fuzzies by helping to reach them.

UDS Barcelona Review

Woo! I’ve been back from Barcelona for a little while now. I think it was the best UDS so far (that I’ve been too, it’s only been my third).

Beforehand, Canonical held an all-employees event called AllHands. There was lots of information sharing about what different parts of the company were doing. It was very informative, and nice to get a chance to meet some of my new teammates in person.

Then UDS itself. Now that I’m on the Foundations team for the next six months, I’ll be working at a slightly lower level than I’m used to. So I attended a lot of sessions that I wouldn’t normally have and just soaked up the cleverness of those around me. I gotta say, most sessions were between two or three very smart people, with lots of others just watching, trying to keep up. At least, for the Foundations sessions which tended to be very technical.

The work that Scott James Remnant is doing to lower boot time is impressive. His goal is 10 seconds to a full desktop. There was a session about ‘what are we going to do about usplash, the boot progress bar program?’ Basically, it’s not very maintainable and has lots of bugs. Scott’s answer was basically ‘Eh, throw it out, we’re going to start X at the same time we would have started usplash; it will just slow us down.’ Love it!

There was also a nice commitment to more heavily move to pulseaudio. Historically, it’s been installed, but not all programs use it, which makes for a frustrating audio experience. So the plan is to convert lots of audio libraries to use a pulseaudio backend by default. Try to convert as many apps we can that way.

I also like the ‘100 papercuts’ initiative, which aims to catalog and fix 100 small, aggravating bugs for Karmic. It’s often the little things that annoy you and add up to a bad experience.

The Foundations team signed up for a lot of work, but I still don’t quite know which parts of that I’ll be working on. Should be an interesting cycle!

Turkish Is Crazy

So I was working on a very odd bug at work. For some reason, printing didn’t work when you chose Turkish as your language.

After some digging, I discovered that Turkish is very odd in one particular aspect. The wikipedia entry about it can explain better than me, but suffice to say:

$ LANG=en_US.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, ''); print 'TURKISH'.lower()"
$ LANG=tr_TR.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, ''); print 'TURKISH'.lower()"

This has implications for all sorts of sloppily written code. Normally it works alright, if all you care about is if two strings are the same thing when lower‘ed, but if you are using lower as part of a hash function and then talking over a network, everything will screw up. I’m surprised anything works in Turkish.

UDS Debriefing

Phew, I meant to write this a million years ago.

I went to UDS Jaunty, got the shirt, came back. It was at the Googleplex, but seemingly the backwater part of it. The food wasn’t amazing, and we weren’t allowed to really wander around. So it was just a bunch of conference rooms. With weird cameras that would move by themselves and that you couldn’t turn off.

And Mountain View, California is no Prague. There wasn’t much nightlife, and you needed a car to get anywhere. So the locale as a whole was disappointing. Next time, let’s do New Orleans!

It was neat to see how forward-thinking most of the sessions were. I felt like it was more about planning for Jaunty+1 than Jaunty. Really long-term views, with an eye towards what first steps can be done by Jaunty.

I attended the Jaunty Backup session. You can even see the videos from the session, although no one was moving the camera around as people spoke, so I’m perpetually off stage right.

The session was inconclusive, and I fear I spent too much of its time talking about Déjà Dup, but I was there to evangalize I guess. I haven’t heard back, and the spec writeup seems like it’s willing to wait until Jaunty+1, as none of the current solutions are ideal.

Which is good. Throwing Déjà Dup together in time to meet Jaunty deadlines would have been tight. But honestly, I think it’s coming along fantastically. The recently released 5.0 is really hot, and could have served as a decent first draft for Jaunty.

Besides the backup session, I did a lot of work in our secret OEM Services room, and attended the odd session. It was fun.

Dell Mini

W00t! One of my projects at work is finally public! I’m actually a little late to the party, as Dell announced it last week, but better late than never.

The Dell Mini is a neat little netbook that my team has been working on. It has a custom UI and a lot of system integration work to make it a more consumer-friendly device. The wikipedia page has links to reviews, which seem to be positive.

I’m pretty proud of it, and it’s been really great to have been able to work on it.

Canonical, Prague

So I’ve been working at Canonical for a few days now, and it’s been pretty great. It’s really nice to be able to work with the tools and processes that God intended for software development.

One excellent perk of the job is getting shipped out to the biannual Ubuntu Developer Summits (UDS). There’s one in Prague next week that I get to attend. So, that’s where I’ll be for the next week. I leave Saturday, come back on Saturday.

Hopefully I’ll be useful, but at least I’ll be able to place some names to faces right out of the gate.