Archive for July, 2008

Fedora/RPM packaging

Tuesday, July 22nd, 2008

Since starting at One Laptop per Child I have been doing some distro work on the OS platform for the XO laptop. The platform is based on Fedora 7 and I have been working on rebasing us onto Fedora 9 for the next release.

Having very little distribution experience outside of developing Gentoo for the last few years, I’ve found some aspects of Fedora’s binary package (RPM) workflow particularly interesting:

  1. Automatically detected dependencies: In Gentoo ebuilds, we have to state that package A depends on library B. In Fedora, when building the binary package, the build tools determine many runtime dependencies automatically so there is no need for developers to manually list all dependencies in spec files.
  2. Chroot build environments: All packages are built in an otherwise-empty chroot. The build system creates a chroot, quickly installs all of the base binary packages and the build dependencies, then builds/installs a package, produces a package, and throws the chroot away. This allows for predictable build environments and is good for QA.
  3. Community access to the build box: All packages are built by Koji. Koji has a nice “scratch-build” system where you can throw a source RPM at it, and it will build it and serve it back to you on a webpage a few minutes later. Great for build testing and handy if you don’t have a complete build environment locally. The scratch-build service is open to non-developers assuming they have been through the click-through contributor agreement.
  4. Subpackages: It’s pretty neat how one spec file (equivalent to an ebuild in some ways – textual build scripts) can actually produce several packages. Your spec file takes one upstream tarball, unpacks/compiles/installs it, and then specifies which of the installed files belong to which subpackage.

Naturally, there are some drawbacks too:

  1. Build dependencies: Even though many runtime dependencies are automatically detected, you still need to specify the components required for compilation. Remember, each package is built in a clean chroot. You end up having to specify most of the dependencies anyway (although it is still convenient in that you do not have to specify which subpackage has which dependencies – that is determined automatically).
  2. No build customisation: OLPC have to fork a few packages which have wacky dependency chains, just to disable support for a certain feature or whatever. Forking away from upstream is undesirable but sometimes necessary. For example, we had to disable libgnome support in GNOME’s Python bindings to avoid libgnome being pulled into the build. libgnome was pulling in the following packages: audiofile bluecurve-icon-theme control-center-filesystem esound-libs fedora-gnome-theme fedora-icon-theme fedora-logos gail gnome-icon-theme gnome-keyring gnome-themes gtk-nodoka-engine libart_lgpl libbonoboui libgnomecanvas libgnomeui libutempter metacity nodoka-metacity-theme pyorbit. Ouch.
  3. Convolution/confusion of build tools: To build a package, you can use rpmbuild to do it on your live system, or you can use mock to do the clean chroot thing I described above. Or you can use koji’s command-line client to upload it to koji. Not everything can be done through koji/mock, e.g. you still need to use rpmbuild to build OLPC’s kernel. Also, rpmbuild is the only tool that can build a source RPM, I think.

I’ve also been impressed by the Fedora development community. The community recently made the realisation that OLPC is Fedora’s biggest deployment (over 400,000 XO laptops worldwide, 55,000 more built and distributed each month, 100% of them running Fedora). Greg Dekoenigsberg recently announced the Fedora OLPC special interest group which sounds promising.

OLPC’s Learning Lab

Thursday, July 17th, 2008

The learning lab is one of the aspects of One Laptop per Child which you don’t hear much about. It took me a couple of weeks at the office before I stumbled across their lab space in the corner of our office.

The learning lab is staffed by some key people, including David Cavallo from the MIT Media Lab and Cynthia Solomon, one of the original founders of Logo. These people have years of experience working alongside top scientists such as Marvin Minsky and Seymour Papert.

Last week, David Cavallo gave an enjoyable presentation about the education model behind the efforts of learning group. He shared some experiences from around the world and started a discussion on how to better integrate such ideals into the XO laptop and its software. The session has been published on dailymotion – if you’ve got an hour to kill, I’d definitely recommend watching it.

UPEK TouchStrip Sensor-only (147e:2016) on Linux

Wednesday, July 9th, 2008


As part of my fprint fingerprint scanning on Linux efforts, I have completed a new driver for a popular bit of hardware that has been unsupported on Linux until now: the UPEK TouchStrip sensor-only variant with USB ID 147e:2016.

We have already supported another variant including a biometric co-processor for some time now, but in the absence of the co-processor, the sensor-only variant required a completely different driver. Support for the sensor-only devices is a significant step forward as this hardware can be found in a lot of laptops. I’ve already received some success reports – thanks!

The driver is only available in libfprint development repositories (not any released versions). System76 have created an installation guide which may be useful for keen users.