PyGTK: Performing engine maintenance while the car is running

The PyGTK hackfest is happening at the OLPC office in Cambridge, and we’ve had some productive discussions so far. There are two major orthogonal changes happening simultaneously.

Python 3

First, Python 3 support for interacting with the GTK+ stack. As far as I understand it, the Python 3 work is mostly mechanical and uninteresting, so I won’t say much more about it. There’s just a lot of code that needs to be changed.

Introspection

Second, pushing forward the new PyGI stack which among other things is significantly more memory efficient.

So there are two Python binding stacks now with different tradeoffs. In pictures, here are their respective architectures:

PyGTK


In PyGTK, a large C library is generated which bridges the two worlds, which combines hand-written “overrides” with some metadata (.defs file) about the C library.

PyGI


In PyGI, everything is done dynamically based on the information from the .typelib file. There are a very few custom overrides.

PyGTK-on-PyGI


This is our current concept; in the combined architecture, the API people are used to from PyGTK is preserved, however we begin to “hollow out” the core so that for more of the simple functions that aren’t overridden, instead of generating a static C blob for them, we look up dynamically through PyGI. This would be relatively straightforward to do on a per-function level by adding a hook in the metaclass or __getattr__. More complex would be doing this on a whole-class level, however this would also be the biggest win in terms of memory usage which is important for everyone, but particularly for Sugar.

More updates as we hack them. If you’re interested you can join us!

Advertisements

How the Fedora desktop gets made

I’d like to illuminate a bit the process by which the Fedora Desktop CD image gets made.

People

Ultimately, the content of the image is created by people. Yes, those names you see on the Internet have real people behind them. After creating content (source code, art, documentation, etc.), it’s typically added to:

Revision Control (git)

A revision control system is a shared online service where people can put changes to a particular component, from applications like Rhythmbox to operating system plumbing like the Linux kernel. From revision control, content is pulled by Fedora into:

Fedora Package CVS

Fedora uses a system of tracking the content of these repositories around the internet called Fedora CVS. This content is pulled periodically at the discretion of a package maintainer. When it’s added to Fedora CVS, it then gets submitted to:

Koji

The Koji service turns the content of the Package CVS into files called .rpm which are consumable components that can be installed individually, but for the purpose of the CD, are combined at a high level using:

Comps

The Fedora Comps is simply a list of these packages. For our purpose here, the most important part is a group called @gnome-desktop which defines the components (out of the universe of packages in the Fedora repositories) that are installed by default on the desktop. From comps, we now turn to:

spin-kickstarts

The spin-kickstarts project uses Kickstart files to combine the comps grouping of packages above with some “extra sauce” such as scripts. (For example, the Live images are specifically modified not to perform software updates while they’re in “Live” mode). The specific kickstart file of interest is fedora-livecd-desktop.ks. This kickstart file is then consumed by:

LiveCD tools

The LiveCD tools consume the kickstart file, a comps listing, and a repository of RPMS and actually creates the final CD image.

This whole process happens nightly, and the results currently appear here. I hope you learned something and/or found this interesting!