Recently, I have made fairly major changes to kernel-package, and there were some reports that I had managed to mess up cross compilation. And, not having a cross-compilation tool chain handy, I had to depend on the kindness of strangers to address that issue. And, given that I am much less personable than Ms Vivien Leigh, this is not something I particularly look forward to repeating. At the onset, building a cross compiling tool chain seems a daunting task. This is not an activity one does frequently, and so one may be pardoned for being non-plussed by this. However, I have done this before, the most recent effort being creating one to compile rockbox binaries, so I had some idea where to start. Of course, since it is usually years between attempts to create cross-compiling tool chains, I generally forget how it is all done, and have to go hunting for details. Thank god for google. Well, I am not the only one in the same pickle, apparently, for there are gobs of articles and HOWTOs out there, including some pretty comprehensive (and intimidating) general tool sets to designed to create cross compilers in the most generic fashion possible. Using them was not really an option, since I would forget how to drive them in a few months, and have a miniature version of the current problem again. Also, you know, I don t feel comfortable using scripts that are too complex for me to understand I mean, without understanding, how can there be trust? Also, this time around, I could not decide whether to cross compile for arm-elf, as I did the last time, or for the newfangled armel target. A need for quickly changing the target for the cross compiler build mechanism would be nice. Manually building the tool chain makes a wrong decision here expensive, and I hate that. I am also getting fed up with having to root around on the internet every time I wanted to build a cross compiler. I came across a script by Uwe Hermann, which started me down the path of creating a script, with a help option, to store the instructions, without trying to be too general and thus getting overly complex. However, Uwe s script hard coded too many things like version numbers and upstream source locations, and I know I would rapidly find updating the script irritating. Using Debian source packages would fix both of these issues. I also wanted to use Debian sources as far as I could, to ensure that my cross compiler was as compatible as I could make it, though I did want to use newlib (I don t know why, except that I can, and the docs sound cool). And of course the script should have a help option and do proper command line parsing, so that editing the script would be unnecessary. Anyway, all this effort culminated in the following script: build cross toolchain, surprisingly compact. So I am now all set to try and cross compile a kernel the next time a kernel-package bug comes around. I thought that I would share this with the lazy web, while I was at it. Enjoy. The next thing, of course, is to get my script to create a qemu base image every week so I can move from user mode Linux to the much more nifty kvm, which is what all the cool kids use. And then I can even create an arm virtual machine to test my kernels with, something that user mode linux can t easily do.

As some of you may know, Arthur Liu did the initial work on a GTK+ interface for aptitude last summer as part of the Google Summer of Code program. Since that program ended, I've been working to complete the GTK+ interface, along with some unrelated but similarly large changes to other parts of aptitude. It's been a while since I've written anything about aptitude-gtk, though, mostly because I set it aside for a few months to improve the dependency solver. While I'll probably be doing more work on the backend over the summer, I also hope to get the GTK+ interface to a point where I can feel comfortable including it in a stable release of aptitude. There are two things that I want to be in place for the GTK+ interface before I release it:

1. The interface should be functionally complete, meaning that you should be able to do anything you can do in the other interfaces.
2. The interface should be reasonably straightforward to use and nice to look at. This is a never-ending task, but there are some pieces of the current interface that are particularly ugly or awkward that I'd like to fix before release.

I've gone through the major areas of the current UI and marked them up with notes about things that I think need to be done. This isn't a definitive or exhaustive list, but it should give some idea of where aptitude is and where it's going.

---

Dashboard Tab The first thing you see when you start aptitude is the dashboard. This is a display that gives you immediate access to some of the most common things you'll want to do: searching for a package, viewing the available upgrades, and upgrading as many packages as aptitude can figure out how to upgrade without removing anything. This is one of the most complete parts of the interface, but there are a few minor aesthetic things that I'd like to take care of. [UPDATE] Michael Johnson writes:

I agree with most of the notes on this screen. However, I'd like to see the Selected Package changelog stay. I often look more than one upgrade back. The summary doesn't show more than what's being upgraded. However, I do like the idea of package description tab. The search box should definately always be available. I found it annoying when I had to click back to a different tab to get it. One thing I definately miss from the console version of aptitude is the list of recommended and suggested packages. I don't let aptitude auto-install recommended packages, but I like to know what they are.

---

Packages tab This is the view that's shown after you search for a package by name, keyword, or by other criteria. It's also fairly complete, but there are more things that could be added (mostly enhancements). Related to this is the dialog box for editing which columns are visible:

---

Dependency solver tab The dependency solver got a lot of love in the 0.5.2.1 release, and it's now basically functional. There are some minor layout issues to be fixed, and if I have time I'd like to add more ways of controlling the resolver's behavior.

---

Package information tab The package information page is probably the weakest part of the GTK+ aptitude interface; it wouldn't be too much of a stretch to say that this tab is holding back a stable release of aptitude-gtk. The big problem I have with it is that I feel that the information tab should open up with an overview of the status of the package. What version is installed, what's available, what archive is it in, who's the maintainer, how big is it, etc. Instead, aptitude-gtk currently shows you a big tree of all the package's dependencies. While that's useful, it should be something the user chooses from. I also find this tab to be visually unappealing, but I'm not entirely sure how to fix that. [UPDATE] Gunnar Wolf writes:

As you have mentioned in your blog post (quote this mail if you so wish) that you want to make the package information screen "sexier": I think it would be natural to integrate screenshots (from http://screenshots.debian.net/) into it. Of course, it would be worth measuring whether it imposes too high a load into that system (maybe it should only get a screenshot if the user explicitly asks for it) - but surely would be a net win.

I think this is a great idea and I'm definitely planning to incorporate this feature. [UPDATE] Michael Johnson writes:

One of the things I really like about aptitude-gtk over console-aptitude is how obvious it makes some things. The version display on this tab is one of those things. Maybe it could be more obvious, I don't know. I agree, the dependency list is not the most important thing. And it's missing the reverse dependencies. I use that more than the dependencies. As far as the actual display of the list, I can't think of anything besides a tree. Although the current implementation does feel quite clunky. What I'd more like to see first is the list of files in the package. But I can see how other people would have different priorties. So it should be really easy to change the default view.

---

Preferences tab One of the reasons that it is a stretch to say that the information tab is holding aptitude-gtk back is the preferences tab, which is a huge pile of not-yet-implemented-ness. In fact, it's not even designed, let alone implemented. Releasing a GUI program with no way to alter the settings strikes me as ... silly.

---

Preview tab The preview tab is a bit weaker than the packages tab, in my opinion, but much stronger than the information tab. Like the information tab, I find it visually unappealing, but I'm not entirely sure how to improve it. I'm currently leaning towards the paned browser idea. [UPDATE] Michael Johnson writes:

I've never been comfortable using this tab. It never made much sense to me. I think the last one or two times I used aptitude-gtk it started making sense, but that seems to be too long a time. I think it's the mass of text at each top level entry. The console version has brief descriptions with more info in the details pane when the entry is selected. Perhaps healthy use of tool tips or an info pane would help with this. The paned browser idea sounds promising. I think it will be easier for new users to follow. And it provides a natural way to provide more information on what each section is about.

---

That's all folks!

All Horde packages (horde3, imp4, kronolith2 ) were in GNU Arch repository. After Lenny release, we decided to migrate to Git. Git has a lot cool features, and I was convinced by Pierre Habouzit talk about Packaging with Git. Technically, I used git-archimport to keep all history of packaging. Each package has a Git repository with some branches: upstream, upstream+patches, upstream+repack (if needed), pristine-tar, debian-sid (imported from GNU Arch) and debian-<release>. The hardest step was to set up a common ancestor for debian-sid and upstream branches: I found git-merge-unrelated-branch script to do it automagically. I write guidelines for packaging Horde with Git on Debian Wiki with some notes about migration from GNU Arch to Git. Comments welcome!

Just got home from a wonderful concert by Brad Mehldau at the CSO. This was long overdue as I kept reading about Mehldau. And even though he performs quite regularly around here, I had never seen him. Big mistake. The first set was performed as a (strictly acoustic) trio with Larry Grenadier on bass and Jeff Ballard on drums. After several compositions by Mehldau and a brazilian samba piece, the first set closed with a rendition of 'Holland' from Sufjan Stevens' album Michigan which was truly beautiful. The second set had Mehldau performing solo, again with several compositions of his own as well as one from Neil Young's classic 'The Needle and the Damage Done' leading two two pieces from the Sound of Music including an amazing, yet really different 'My favourite things' that just hushed a piece of the central melody along with a strond rhythmic element. Lovely. And then to cap it all off, four encores. Highly recommended.

Wednesday 1st

At the G20 protests, Londoner Ian Tomlinson collapses and is attended to by the emergency services; Metropolitan Police claim "during this time a number of missiles - believed to be bottles - were being thrown at them". Tomlinson dies that evening.

Thursday 2nd

The Evening Standard reports that "police were bombarded with bricks, bottles and planks of wood" as they helped Tomlinson.

Saturday 4th

Postmortem of Tomlinson finds he died of a heart attack.

Monday 6th

The EC Data Retention Regulations 2009 comes into force requiring internet service providers to retain details of emails, internet phone calls and other web traffic.

Tuesday 7th

The Guardian publishes a video of a police officer assualting Tomlinson on 1st April.

Wednesday 8th

Twelve Pakistani students are arrested on suspicion of planning terror attacks over the Easter holiday weekend.

Thursday 9th

The Guardian publishes a second video of Tomlinson's assualt, contributing that no missiles were thrown.

Monday 13th

Police arrest 114 climate protestors on conspiracy to cause criminal damage at Nottingham power plant. [ref]

Tuesday 14th

A video of a seperate assualt at the G20 protests is published.

Thursday 16th

Police claim tourist's photography of transport-related buildings is "strictly forbidden" and demand the photos are deleted. [ref]

Friday 17th

A second postmortem of Iam Tomlinson finds the cause of death to be an abdominal haemorrhage. A policeman is interviewed under caution on suspicion of manslaughter. [ref]

Saturday 18th

The Times reveals MP Damian Green private emails were searched by the police using the keywords "Shami Chakrabarti" (director of Liberty) after his arrest last year.

Monday 20th

The Guardian reveals police intelligence was given to E.On before the Nottingham climate demonstration, including movements of protesters and their meetings.

Tuesday 21st

Another video of the Tomlinson assault is revealed showing his head hitting the pavement. The Independent Police Complaints Commission fails to obtain an injunction to prevent broadcast.

Wednesday 22nd

Nine Pakistani students arrested during anti-terror raids are released after 13 days without charge and are passed to UK Border Agency custody for deportation. [ref]

Monday 27th

Home Secretary Jacqui Smith announces that ISPs and telecoms companies will be asked to record usage "to track murderers and paedophiles" without a warrant. [ref]

Tuesday 28th

Emails are revealed of the Home Office asking Phorm, the behavioural targeted advertising service, whether they are falling outside the law. Home Office claim Phorm would be legal if consent is obtained and that "providers of goods and services need only ensure they are compliant with relevant legislation". [ref]

Wednesday 29th

The Guardian documents the friends of the 7/7 bombers were denied bail on secret evidence - "the appellant asked the judge the question: why are you sending me to prison? To which the judge replied: 'I cannot tell you that.'"

(The much-delayed part 2 in an ongoing series: shiny things in telepathy-glib) Over a year ago I explained my first major round of work on telepathy-glib, with which it could be used to implement D-Bus services. I started to write this post shortly after, but then got distracted by a bee or something; recent discussion about having a D-Bus binding in GLib has finally prompted me to finish it. The second major round of work on telepathy-glib dealt with implementing client code, and went sufficiently well that telepathy-qt4 (currently under development) uses essentially the same model. Again, while telepathy-glib is intended for Telepathy implementors, I think TpProxy's ideas are generically useful, particularly for "large" D-Bus APIs.

Some background: dbus-glib and libtelepathy

The life-cycle of a DBusGProxy (PD clipart credit: karderio and Andy)

The API provided by dbus-glib for client code is, er, rather less than ideal. The basic object is DBusGProxy, which has a few problems. There's one per interface, rather than one per object; this leads to a maze of twisty GObjects, all suspiciously similar. Our old client library, libtelepathy, got round this by subclassing DBusGProxy to make helper objects called TpChan, TpConn etc., which were simultaneously the proxy for the "main" interface (Channel, Connection etc.), and a factory for proxies for the other interfaces (like Channel.Type.Text and Channel.Interface.Password). This still wasn't ideal, but it was a start. If you use a DBusGProxy in any way after it has emitted the destroy signal, this is considered to be invalid use of the API, and dbus-glib asserts all over the place. We'd rather it didn't do that - remote objects becoming invalid is a fact of life, and if you don't immediately discard all your references to those objects, remote operations on them should just give you a runtime error. You have to be prepared to handle such runtime errors already, because any IPC call can fail at any time. The main API for calling methods uses varargs and is rather subtle. Notably, the calling convention for variant parameters (of D-Bus signature 'v') is not consistent with the calling convention for any other container. For any other container, for instance a GPtrArray *, you pass in a GPtrArray ** pointing to a GPtrArray * variable containing NULL; on success, a pointer to a new GPtrArray is written into that variable. For variant parameters, though, you must pass in a GValue * pointing to a zero-filled GValue, and the result will be written into that GValue. dbus-binding-tool generates thin wrappers around this method-calling API which provide type-safety, although they can't directly specify a non-default timeout. As for signals, before binding to a signal, you have to tell dbus-glib about its signature. This tells dbus-glib how it should push the signal arguments onto the C stack (in GObject terminology: how it should marshal them), to match the signature of the signal-handler function. The documentation claims that this isn't necessary for objects supporting the Introspect method, but that's untrue - on the other hand, if the documented behaviour actually happened, I would consider this to be a critical bug in dbus-glib, since it would enable remote objects to crash dbus-glib clients (by causing signal arguments to be pushed onto the stack in a way that does not match the signature of the signal handler). Of course, the signal-adding function takes varargs, and has to be called exactly once per signal per object. If you don't, dbus-glib asserts when you connect to the signal; if you call it twice, dbus-glib asserts anyway.

TpProxy TpProxy is a GObject subclass vaguely inspired by Python's dbus.proxy.ProxyObject. It isn't a subclass of DBusGProxy, which lets us encapsulate dbus-glib almost completely - in fact, all the references to DBusGProxy are in a separate header, proxy-subclass.h, only used by subclasses of TpProxy (as opposed to normal library API users). TpProxy instances are per-remote-object (per-object-path) like in dbus-python, rather than per-interface like in dbus-glib or QtDBus. As explained below, I believe that this is the most natural object mapping for D-Bus interfaces; in practice it tends to lead to clearer code for us, since one remote object often maps nicely to one UI element (of course, if your objects only have one interface, this approach is no better or worse than dbus-glib's). TpProxy provides support for the following common D-Bus things:

• Calling methods
• Connecting to signals
• Objects becoming invalid
• Objects with optional interfaces
• Extensibility

It doesn't currently provide any particular help with Properties - the Properties interface is just another interface as far as we're concerned. We find that, in practice, that's not a problem (even though we use D-Bus properties extensively). In telepathy-qt4 we basically reinvented TpProxy in C++, as Tp::DBusProxy. I've put in some comments below illustrating how the general ideas we used in TpProxy translate into a different object mapping.

Calling methods Method calls on TpProxy are done through auto-generated wrapper functions, much like DBusGProxy. These look something like this:

typedef void (*tp_cli_channel_callback_for_close) (TpChannel *proxy,
    /* any 'out' arguments would go here - Close() doesn't have any */
    const GError *error, gpointer user_data,
    GObject *weak_object);
TpProxyPendingCall *tp_cli_channel_call_close (TpChannel *proxy,
    gint timeout_ms,
    /* any 'in' arguments would go here - Close() doesn't have any */
    tp_cli_channel_callback_for_close callback,
    gpointer user_data,
    GDestroyNotify destroy,
    GObject *weak_object);

Methods for some interfaces, like DBus.Properties, are available on TpProxy itself; others, like Telepathy's Channel.anything, are only available on a particular subclass, like TpChannel. Things to note here:

• It's an asynchronous call with a callback. General design principle: "this is IPC, get over it". We don't try to hide the fact that IPC is taking place by doing pseudo-blocking calls.
• The timeout is explicit (although you can always pass -1 to let libdbus pick a "reasonable" default for you). This is because the remote service might not respond, and API users should be at least vaguely aware of this: "this is IPC, get over it".
• The callback isn't a GCallback; it has an explicit signature, for some semblance of type-safety (it's not much, but it's better than nothing).
• The callback takes a GError, because any IPC call can fail for any reason.
• A TpProxyPendingCall * is returned. This is a pointer to an object that only exists until just after the callback is called (so you can ignore it if you don't want it), with a method you can call to cancel the method call (with hindsight this is not ideal, and if I was writing this API now, I'd use gio's GCancellable). "Cancel" is perhaps slightly misleading: the method call still takes place (it was already in libdbus's outgoing queue) but the result gets ignored and the callback isn't called. This is mostly so you an object can forget all the calls it was busy making at the time that the results become irrelevant (e.g. the object is destroyed).
• There is an extra weak_object argument, which is weakly referenced and is passed to the callback: in practice, most users of telepathy-glib use this as well as or instead of user_data. If the weak_object runs out of references, the callback is automatically cancelled, which means that in practice, explicit cancellation is almost never needed.
• The generated code has as its first argument a suitable subclass of TpProxy, in this case TpChannel (we tell the code generator about subclasses).
• You can't see it in the API, but the TpProxy gains an extra ref while a method call is in progress, so you never have to worry about what happens if the proxy gets unreffed during a method call.
• There's an explicit destructor for the user_data, which is called even if you "cancel" the method call.

In telepathy-qt4, these methods are on small generated helper classes similar to dbus-python's dbus.Interface, one per interface (we provide accessors for them on the non-generated DBusProxy subclass). Instead of using callbacks, we return a temporary QObject per call, which emits a Qt signal on success or failure (that's how all async calls in QtDBus work).

Connecting to signals Similarly, signals have some generated functions:

typedef void (*tp_cli_channel_signal_callback_closed) (TpChannel *proxy,
    /* any arguments would go here - Closed doesn't have any */
    gpointer user_data, GObject *weak_object);
TpProxySignalConnection *tp_cli_channel_connect_to_closed (TpChannel *proxy,
    tp_cli_channel_signal_callback_closed callback,
    gpointer user_data,
    GDestroyNotify destroy,
    GObject *weak_object,
    GError **error);

API notes for these:

• The callback doesn't take a GError any more, because signals can't fail; the weak_object and the user_data are the same as for method calls
• This isn't actually a GObject signal at all: those aren't particularly typesafe, and lack namespacing. This might not be very binding-friendly, we haven't tried doing that yet... it might be worth introducing a signal with details, like in dbus-glib, for which these functions are "C bindings".
• The returned TpProxySignalConnection lets you disconnect from the signal, just like the TpProxyPendingCall above; it can safely be ignored
• Similarly, if the weak_object dies, then the signal automatically disconnects
• It is possible for connecting to a signal to fail: this happens if the proxy doesn't actually have the requested interface. If this happens, it's graceful, not a crash. In practice, the flow of code is almost always such that error can safely be NULL because the interfaces are already known.

In telepathy-qt4 the per-interface generated helper classes emit Qt signals. In many cases, we end up proxying these signals by responding to them in the hand-written Tp::DBusProxy subclass by emitting a different signal, in order to give them a nicer representation.

Becoming invalid This is IPC, and any error can happen to you at any time. We found that it was useful to have a general concept of "this object is no longer useful", so we introduced the concept of an object becoming invalidated. The invalidation reason is stored on the object as a GError. If this GError is NULL (as it is initially), then the object is still expected to be valid; if it's non-NULL, the remote object has vanished and the local proxy no longer works. There are several ways a TpProxy can become invalid:

• its bus name falls off the bus (the process exited or crashed)
• application-specific reasons (usually triggered by a D-Bus signal in a subclass, like the Telepathy Channel's Closed signal)
• the GObject gets disposed

Method calls on an invalidated object always fail, with the invalidation reason as the error. This means that calling a method on a TpProxy should never crash your process. The method's callback has to be prepared to handle an error in any case, because this is Sparta^WIPC, so there's no loss in giving it another error. Connecting to signals on an invalidated object always fails, and any existing signal connections are disconnected when it becomes invalidated. This means that if a new remote object appears, and it happens to have the same object path, bus name etc. as the old one, you won't get its signals. A TpProxy can either be bound to a unique bus name or a well-known bus name. In the equivalent code in telepathy-qt4, we call this "stateful" or "stateless" - these names don't capture the intention perfectly, but they're the best we could come up with. A proxy for a stateful API like Telepathy's Channel should always bind to a unique name - when the unique name falls off the bus, the TpProxy becomes invalidated automatically, representing the fact that the Channel you had no longer exists, and nothing can be a perfect replacement for it (the VoIP call has already been terminated, you've already left the chatroom, or whatever - if you make another Channel, that's e.g. a distinct VoIP call). A proxy for a stateless API like Telepathy's ConnectionManager, where an exiting process can disappear, be service-activated again, and still have exactly the same API, should bind to the well-known name. Proxies for well-known names aren't invalidated when the process exits. Qt doesn't have a natural equivalent for GError, so the invalidation reasons in telepathy-qt4 are just a pair of strings, the namespaced name and the message - basically a libdbus DBusError. The principle is the same, though.

Optional interfaces As mentioned above, TpProxy instances are per-remote-object (per-object-path) like in dbus-python, rather than per-interface like in dbus-glib or QtDBus. I believe that this is the most natural object mapping for the D-Bus object model, because the D-Bus interfaces on a remote object can behave like any of these:

• classes and subclasses (Telepathy.Channel.Type.Text is a Telepathy.Channel)
• shared interfaces (some Telepathy.Channel objects, of many Types, implement Telepathy.Channel.Interface.Group; any D-Bus object can implement DBus.Properties)
• optional features (some Telepathy.Channel.Type.Text objects implement Telepathy.Channel.Interface.ChatStates, some do not)
• discoverable extensions (some Telepathy.Channel.Type.Text objects implement Telepathy.Channel.Interface.Messages, which is more or less Text 2.0)

The way in which interfaces are discovered is also variable. The "classic" D-Bus way to discover interfaces would be to call Introspect. Telepathy services still support that style of introspection, but we don't use it for anything beyond d-feet:

• Introspect returns a blob of XML, which you have to parse into something useful; if it was in a D-Bus data structure, you'd already have some sensible data structure.
• Finding out more information about the supported interfaces than their names isn't very useful: in a static language like C you already need to know the methods, signals, properties and their signatures in order to write and compile your code, and in a dynamic language like Python consumers of Introspect end up being remotely crashable by services with unexpected method signatures (this is one of dbus-python's big mistakes in my opinion).
• If a method that you want to call turns out to be missing, the worst that can happen (in a competently written service) is that it fails with a D-Bus error - and you have to handle D-Bus errors anyway, because this is IPC and anything could fail.
• Static bindings like dbus-glib have poor support for removing interfaces for which C code exists at runtime, whereas Telepathy needs features like an IM connection that might or might not support avatars (we don't get to find out until we've successfully connected to the server).

Instead, our older interfaces have a method on the "base class" (Channel, Connection etc.) called GetInterfaces, which just returns an array of strings. Newer interfaces (like Account), and older interfaces that have been ported (like Channel), have a property called Interfaces which is, again, an array of strings - this lets us combine the download of the interfaces list with downloading other basic information in a GetAll call. To cater for all these ways to use interfaces, the TpProxy base class has very basic support for interface discovery - you can ask it whether it supports an interface, and you can tell it that it does, in fact, support an interface. Asking which interfaces are supported is directly useful for library users; it's also used as a check by the generated method-call and signal-connection stubs, which return a canned error (Telepathy.Error.NotImplemented in Telepathy's case) if the object isn't known to have the interface. Telling TpProxy that it does support an interface is intended for use by subclasses, and might have been protected if we were writing C++: what happens in practice is that a concrete subclass like TpChannel knows how to discover the fully supported interfaces for this particular object, does so, and calls methods on the TpProxy to tell it which interfaces can work.

Extensibility The API stubs used by TpProxy to call methods and bind to signals are generated from XML documents containing an augmented form of D-Bus introspection data. These XML documents contain various Telepathy-specific extensions, but none of the extensions are language-specific - telepathy-glib, telepathy-python and telepathy-qt4 all operate from exactly the same XML specification. telepathy-qt4's different object-mapping did require us to tighten up some rules that were previously only conventions, but even so, the format is the same. I think this is vitally important - it just doesn't scale to have one set of language-specific annotations in a D-Bus API for each language that will have bindings. One thing that we make heavy use of is what I call "Ugly_Case", which is camel-case with underscores at word boundaries. This gives us a simple, unambiguous and foolproof rule to use in code generators whenever we generate any of the popular conventions for identifiers:

• CamelCase: delete underscores
• javaCamelCase: force everything before the first underscore to lower case, then delete underscores
• lower_case: force everything to lower case, retain underscores
• UPPER_CASE: force everything to upper case, retain underscores

dbus-glib, by contrast, applies a complex and subtly buggy algorithm to the CamelCase D-Bus names, which results in our SendDTMF method being mapped into GLib as send_dt_mf, and requires that telepathy-glib's Python reimplementation of dbus-binding-tool uses a bug-for-bug compatible implementation (we ended up reimplementing dbus-binding-tool in order to generate the TpProxy-based bindings). Our code generation tools are still rather ad-hoc, because so is our spec format, but for draft interfaces it's possible to copy them into individual projects and use them to generate additional methods for TpProxy or any subclass. This is how we implement unfinished APIs like geolocation in Empathy, for instance. The Interfaces or GetInterfaces hook described above is entirely usable for these extension interfaces, and in fact that's how they're set up. In telepathy-qt4, the generated method stubs are genuine C++ methods, so we can't just append methods to an existing class: this is why we have one helper class per interface, so individual clients can generate a helper class for their particular version of an unfinished API, and instantiate an object of this class attached to a particular Tp::DBusProxy. When an interface becomes stable, it can be added to the set of interfaces for which code is generated in telepathy-glib or telepathy-qt4, at which point any client or service that was already using the final draft of that interface can easily be ported to the library version using sed (the API remains the same).

Becoming ready The concept of being "ready" does not directly exist in TpProxy, but is implemented in TpChannel, TpConnection and TpConnectionManager. The idea is that a freshly created proxy object isn't really fully usable yet - you have to connect to basic signals and recover the initial state of the remote object, as well as checking which extension interfaces are supported. In many well-designed D-Bus APIs you can do this initial setup with a few signal connections and a DBus.Properties.GetAll call. After doing that initial setup (which has to be done asynchronously, because it's IPC), the TpProxy subclass has a local cache of the remote object's state (not necessarily in the same format as the representation on the bus), which can be accessed synchronously at any time, and will be updated in response to change-notification signals. TpChannel and subclasses like it have explicit support for checking for readiness, and having a callback called when the object is ready or invalidated (whichever happens first). The "ready" property also supports the GObject notify signal. telepathy-qt4 took this concept and ran with it - there is library support for objects that can become ready, including a mixin. If I had as much time to work on telepathy-glib as I wish I had, this would be one of the first telepathy-qt4 features to be added to telepathy-glib.

Features becoming ready Going beyond that, in an extensible framework like Telepathy it's probable that not every client understands (or wants to understand) every feature of every object, so it's highly inefficient for every proxy object to subscribe to all the change notification signals and cache all the remote state on the off-chance that the library user wants them. In the API for TpContact (which is not actually a TpProxy for various reasons) we introduced the concept of optional features; telepathy-qt4 extended this idea throughout the library. The idea is that each library user knows which of the optional features are "interesting" to it, and makes a single asynchronous call (which expands into a series of D-Bus calls inside the library) to download the state for core functionality plus all of the selected features, and subscribe to change notification for all of those. This is another telepathy-qt4 thing that telepathy-glib still needs to catch up with; until someone works out how to make the clone() syscall apply to programmers, I fear all libraries are doomed to lag behind how their designers want them to look :-) (license: CC-BY-3.0 / LGPL-2.1+)

Last few months since I got my EeePC have been a lot of fun. Playing and tweaking the little bastard is a joy in the end of a busy day. Besides, since I loaded it with the most useful SysAdmin tools, it became a powerful device in my tool belt . Unfortunately, I ve been stupid enough to drink a glass of orange juice while messing with it. I know, I know! Silly thing to do. I should know better! But life is like that I spilled a few drops over it. Of course, the web is pouring off information on what to do in cases like this, so I ll just summarize what I did:

1. Imediatelly, without thinking or questioning, I turned it upside down and removed the battery. It was a clumsy thing to do I ended up spilling the rest of my orange juice on the floor while worrying about the EeePC. Concearns about filesystem corruption (or whatever) crossed my mind, but I can always deal with that later First things first!
2. I went online in another computer and found out how to disassemble it. For me it was easy, since I got other two computers at home but if I needed to leave it there while looking for information, I would! If it s upside down and has no power whatsoever (the battery was removed), it s safe, I think. The information was easily found. I decided I didn t need to disassemble all of it, but having those information at hand was pretty useful.
3. I began by removing the keyboard. It s tricky but not difficult. The secret relies on the spring-mounted tabs near the screen. I checked for spills under it and cleaned with a cotton swab.
4. I was not very confortable to open the case, but I decided that turning it back on without checking the electronic parts first was too risky. So I said goodbye to my warranty and unscrewed the 6 screws from the bottom and the 9 from the silver casing under the keyboard.
5. There I found some little drops! Good decision to open it up! I dried it using cotton swabs again.
6. Before putting it all together, I decided to leave it open until the next day. I was pretty sure everything was dry again, but better safe than sorry . The next day I successfully assembled it and turned it on. Great! Everything worked fine.

Now that was just what worked for me. My EeePC is back, fully restored but, of course, the warranty is void :-( So I cannot recommend you to do the same. Best advice I can tell you: Keep liquids away your EeePC!

This time, I won t bother too much with release announcement. Xan has done that job for us =D. The good news that preceeded this release by about a week is that now both me and Xan are reviewers for the GTK+ port, so we are able to approve patches, too, along with the already existing reviewers. This may help our port move forward more quickly. If you think your patch is an easy review, or urgent, do catch us on IRC, and let us know, since our port has quite a backlog, and it may be sometime before our scanning of the list catches your entry =). Thanks to everyone who contributed to this release. I am sure there are many rough edges to sharpen on the new features, so come test and report bugs, (and provide patches if possible =)) please!

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

I'd forgotten how sexy, useful, and great mod_perl is. I've recently been struggling with a friend's CGI-based site, and after a minor effort we made it run with Apache::PerlRun:

Apache::PerlRun gives you the benefit of preloaded Perl and its modules. This module's handler emulates the CGI environment, allowing programmers to write scripts that run under CGI or mod_perl without any change

Because the site code wasn't very clean we had to make a lot of changes to get it working under Apache::Registry.

Apache::Registry is the Apache module allowing you to run CGI scripts very fast under mod_perl, by compiling all scripts once and then caching them in memory.

But the payoff is very noticeable - the site is now blazingly fast! At some point I should write a guide to doing basic things with mod_perl. Mostly I guess the challenge is that you can write toy applications in moments, but to demonstrate how useful it is you need to apply it to something the reader is familiar with. Or demonstrate why the effort is worthwhile, given that it ties you to the Apache + mod_perl platform. Any links to existing guides, or suggestions on how to approach the guide-writing in a beginner-friendly but still useful fashion are welcome. (For what its worth I mostly write web applications using CGI::Application & jQuery these days.) ObFilm: Pretty In Pink

I was doing some routing sysadmin work for a client when I had to read mail in the system administration mailbox. This mailbox is used for cron job email, communication with ISPs that run servers for the company, and other important things. I noticed that the account was subscribed to some mailing lists related to system administration, the following is from one of the monthly messages from a list server: Passwords for sysadmin@example.com: List Password // URL
-
whatever-users@example.org victoria3 That doesn t seem terribly exciting, unless you know that the password used for the list server happens to be the same as the one used for POP and IMAP access to the account in question, and that it is available as webmail Of course I didn t put the real password in my blog post, I replaced it with something conceptually similar and equally difficult to guess (naturally I ve changed the password). The fact that the password wasn t a string of 8 semi-random letters and digits is not a good thing, but not really bad on it s own. It s only when the password gets used for 3rd party servers that you have a real problem. I wonder how many list servers are run by unethical people who use the passwords to gain access to email accounts, and how many hostile parties use such lists of email addresses and passwords when they compromise servers that run mailing lists. Now there would be an obvious security benefit to not having the list server store the password in clear-text or at least not send it out every month. Of course the down-side to doing that is that it doesn t give someone like me the opportunity to discover the problem and change the password.

There s little that scares Kansans more than a good tornado. And, truth be told, there s little that excites us more than a good tornado, either. After all, we know it s going to be good for a story. Here on the plains, it is easy to remember how powerful nature really is. Weather sweeps in from all directions with little to hinder it, and tonight was a night few will forget. The 300-member Kansas Mennonite Men s Chorus, of which I m a member, had a concert tonight at 7, and we had a practice starting at 3. We sang in the beautiful old Memorial Hall on the campus of Bethel College. I need to describe the building a bit for you. It was built in 1938, in the day before auditorium designers decided you need to remove the outdoors. Three sides are full of windows, and it s just a few feet from the front doors into the auditorium itself. There is no air conditioning, so in a very humid day like today, every possible door and window is open. To stand on the stage and look out over the audience, you see light coming in from every direction, extremely bright light when there s lightning. It s been storming all afternoon. Our rehearsal featured thunderclaps, driving rain that was very audible inside, flickering lights. It was, in all honesty, a bit exciting. At about 6:35, word came that a tornado warning had been issued for the county. A few minutes later, about 20 minutes before start time, sirens were activated and the decision was made to evacuate to safety in the building s basement and an adjoining building. I, and a number of college students singing with the choir, wound up as a sort of impromptu ushers, directing people to the best place for safety and helping to get people into space efficiently. It was rather stuffy in those basement hallways, but it was also quite loud due to all the excited visiting going on. The KMMC concerts aren t usually like this. A few minutes later, word came that the tornado warning was canceled. I went down the steps, yelled out the news, and got a big cheer. People poured back upstairs. We got started a few minutes late, but nobody quite cared. A group of brass players was going to provide the prelude, but their first trumpet player had to leave at the last minute because his tool shed had blown over. They covered for him well in the concert though. When I got home later, Terah saw me and said, I thought they d cancel the concert because of the tornado. I just had to laugh, and pointed out, This is Kansas. After a tornado evacuation, it just got everybody more excited for the program! (Of course, had there been a strike, it would have been a different story.) And it was a great program. There was excitement in the air. And it was incredibly hot and stuffy on the stage with 300 men. I had sweat running down my face. The rain and the thunder continued, sometimes improving the program. About halfway through, we sang Prayer of the Children, written by Kurt Bestor, someone that was terribly saddened by the destruction during the civil war in the Balkans. The lyrics go, in part:

Can you hear the prayer of the children
on bended knee, in the shadow of an unknown room? Empty eyes with no more tears to cry,
turning heavenward to the light. Cryin Jesus, help me
to see the morning light of one more day. . . Can you hear the voice of the children
softly pleading for silence in their shattered world?. . . Angry guns preach a gospel full of hate
blood of the innocent on their hands. For when darkness clears, I know you re near,
brining peace again. Can you hear
the prayer of the children?

And when we get to the last phrase, there s a long rest after Can you hear . We sang it the phrase, and with perfect timing as we paused for the rest, was a loud clap of thunder. And after the last word of the song, total silence. Nobody moved for a few seconds, and then applause rang out. A couple of years ago, I was in the audience at a concert in the same building. Ominous weather lurked that day too. Before the concert started, the director said something like this, before giving information about evacuation procedures, should they be needed: We are plains people. We are privileged to see the awesome power and beauty of the weather and nature up close every day. If we should be a little too privileged today, here s what we ll do

So for years and years and years I assumed this photo was taken by a good friend of mine (and we sill think it may be) but we can t totally verify if it is his as he lost all his old photos after a server hack-in. Do you recognize this photo? Do you have photos from this Free Dmitry protest (August 2008, in front of the San Francisco Prosecutors office) that would share for an academic publication on this topic??? Help!

So for years and years and years I assumed this photo was taken by a good friend of mine (and we sill think it may be) but we can t totally verify if it is his as he lost all his old photos after a server hack-in. Do you recognize this photo? Do you have photos from this Free Dmitry protest (August 2008, in front of the San Francisco Prosecutors office) that would share for an academic publication on this topic??? Help!

I've released version 0.5.2 of the aptitude package manager (release notes). You can download it from Debian's experimental archive, or from the aptitude package page. WARNING: This is an unfinished piece of software. Do not install it if you want a package manager that does everything you need perfectly all the time. It is buggy and incomplete. This update includes major changes to the resolver backend and a new and improved GUI frontend for the resolver: It also includes an assortment of other fixes and improvements. Click through to the release notes to see a list of what changed in this release, with screen-shots.

The people who made the above magazine advert gave it two top-halves to the burger bun. But I think that there is actually a demand for such buns, and that it is possible to make them! Traditional buns have a flat bottom where they rest on a baking tray. One solution to this problem would be to bake in outer space, another possible solution would be to develop a rapid baking process that allows baking in a free-fall aeroplane, but both of these would be unreasonably expensive. It seems that it would be viable to bake double-ended buns by having a rapidly rising column of hot air to suspend the bun. The terminal velocity of a bun would probably not be that high (maybe 60Km/h) and it should be quite easy to have a pipe full of hot air that bakes the buns. As slight variations in the density and shape of the bun would affect the air-flow it would be necessary to closely monitor the process and adjust the air speed to keep the bun afloat. Manufacturing cheap ovens that use LASERs to monitor the position of the bun should not be difficult. This might blow the sesame seeds off the bun, but this problem may also be solvable through careful design of the bun shape to make it less aerodynamic and by strongly attaching the seeds. I m not sure how you would do this.