Tag Archives: Ubuntu


On holiday, laptop down

I’m currently on holiday in North Berwick. It’s been fun but not quite as relaxing as hoped. Liam has started waking at night again after two months of sleeping through the night.

I’ve been getting up early to do a couple of hours work each morning, but this laptop’s hard drive has started hard crashing after a few minutes. Hard drives fail too often. Hopefully it will give me time to finish this blog entry and hit Publish. I guess I’ll be offline until I get back on Monday.

Brussels and Prague

I’ve been travelling more than usual in May and I’m not finished.

I spent a couple of days in Brussels at Thomas Vander Stichele‘s place, getting a crash course in the Flumotion streaming media server because I’ll be writing Flumotion‘s user documentation.

I’m writing quite a lot of documentation these days, and enjoying it as a holiday from writing code. It’s stress free in comparison. I’d like to make Openismus known for creating documentation along with our development and QA work. There’s always a need for it.

After Brussels I spent a few days with Liam’s grandparents in Karlsruhe before heading to Prague for FOSSCamp. Being away from him for so long was not easy.

Things I read on the train to Prague:

  • The GStreamer Application Development Manual: This is a truly useful document. I now feel like I understand how to use gstreamer. That has allowed me to make sense of the surprisingly mature gstreamer C++ bindings and should help my understanding of Flumotion. I now want to read the GStreamer Plugin Writer’s Guide too.
  • The GNOME Documentation Style Guide: This was better than expected, written by true strunkandwhiteistas who show real experience of writing technical documentation. I didn’t learn much new but was glad to see the advice presented for others. Many points are repeated, but that’s maybe to allow each audience to get the whole message without reading the other sections. Still, the text is sometimes long winded, suggesting a rogue extra author.

FOSSCamp was not quite the dull unstructured talk-fest that I feared, just because of the quality of the attendees, each of whom had something fascinating to explain. It was indeed mostly just talk, with little chance of any resulting action, but it was at least interesting talk.

I quickly introduced Glom to a small group of people who seemed positive and led a larger discussion about updates of stable upstream releases in stable versions of distros, mostly focusing on Ubuntu because only the Ubuntu people seemed to have opinions. Maybe the other distros’ processes are not so easily influenced. I think we already have a result, which I can hopefully mention soon.

I stayed an extra day to meet André Klapper, who is attending the Ubuntu Developer Summit, so we could talk about his bugmaster work for Openismus. We fight entropy. I attended the Ubuntu Mobile sessions in the morning before taking the train home to Munich, but it was impenetrable to anyone not already involved. But that’s UDS – it’s for people already working on stuff.

Both FOSSCamp and the overlap with UDS allowed me to meet many of my favourite people and I am guilty of enjoying their company when I should have been meeting more new people instead.

On Saturday we fly to Scotland (North Berwick) for two weeks so Liam can meet his other grandfather and aunt. I’ve tried to plan the pain out of flying with a five-month old baby for the first time, but it’s sure to be a challenge.

Glom 1.6 bug fixes

We didn’t do a new major version of Glom recently, though we usually follow the GNOME schedule, because some of the new features are not quite ready, such as the drag-and-drop layout, and the new printout designer.

But this does mean that we have a chance to get a bug-fixed version of Glom’s stable version into Ubuntu’s stable version, for the first time. I’ve had some success with that, thanks to Chris Brotherton. It can still take a long time (10 days last time, though it felt like longer), and the longer it takes the more chance there is that a change in some other package can be a reason to wait. But I have a feeling that things are getting easier.

Of course, the more usable Glom is in Ubuntu, the more bug reports we can get. Many thanks to Jani Monoses and Pavel Mlčoch for keeping me busy, particularly for discovering the problems with changed behaviour in PostgreSQL 8.3, which we discovered late because PostgreSQL 8.3 only just started working for some people recently. These bugfixes mean yet more tarball releases for Ubuntu to package, and there’s always the risk that they will stop taking new versions as they really hit their freeze. Hopefully, they’ll manage to do just one more update because Jani found some more critical bugs.

After Ubuntu Hardy is released then our upstream bug fixes will probably never get into Ubuntu Hardy unless we can claim that they are security problems, as is still the problem with Glom in Ubuntu Gutsy. At FOSSCamp in Prague in May I’m apparently meant to be leading some discussion about how to get stable updates into stable distros. I have some ideas about who a distro (and its users) should trust, and about what is currently just providing a false sense of security at the cost of user experience. I don’t know what to expect from FOSSCamp so it might not have any effect. I didn’t see the point in flying to the last FOSSCamp in Boston for one day just for some seemingly aimless meeting and talking, but Prague is not far away by train, so it’s worth a look.

Just-Works IR Remote Controls on Ubuntu

gnome-lirc-properties GUI is now in Ubuntu Hardy, after much effort.

We had a variety of remote controls for testing, so we could at least guarantee that it worked for a certain list. Here are our results. The ones that worked perfectly were recognized by gnome-lirc-properties’ auto-detection button and their keys were immediately recognized in the preview area.

  • Streamzap PC Remote Control (IR receiver and remote control): Worked perfectly.
  • SnapStream Firefly PC Remote (IR receiver and remote control): Worked perfectly.
  • Sound Blaster Remote Control Upgrade – White Box (Has its own IR receiver): Worked perfectly.
  • Pinnacle Remote Kit (IR receiver and control): lirc has no driver for this, and no patch has been submitted to lirc by anyone that can confirm that it works.
  • Xbox 360 Universal Media Remote. (Just a remote, though the XBox has a built-in IR receiver): This didn’t work with any of the other IR receivers, but it presumably works with an actual XBox running Ubuntu. We’d love to hear from people running Ubuntu Hardy on an XBox. Does the auto-detection in our GUI work?

We also tried two other replacement remote controls that have no IR receiver of their own. They work with the other IR receivers – you can use the key learning feature in our GUI to configure them.:

  • Sony RM-V202 4-Device Universal Remote Commander.
  • One For All “Universal Replacement Remote” URC4110.


So I’m adding one of these to my Ubuntu Hardware page, because it just works.

Webcams that just work with Ubuntu Linux

The GNOME Foundation Board asked me to buy a webcam for the GNOME Events Box, so we could show Cheese on our stands. This could be cool together with the box’s new projector. I also wanted a webcam for my own use so Liam’s grandparents can see him in motion more often. So this was an opportunity to discover if any two available webcams really “just work” with Ubuntu, after doing some research and guessing. The results were great.

I bought a Logitech QuickCam Pro 9000 and a Creative Live! Cam Optia AF, both 2 Megapixel webcams. The video for both “just work”ed perfectly in Ekiga, Cheese, and Skype, on Ubuntu Linux Gutsy (7.10) and Hardy (8.04, currently in beta), though all these programs require you to choose the video input from a list, regardless of how well the webcam works. The Logitech one has a built-in microphone without an extra cable. The Creative one has a separate cheapish in-ear headphone+microphone headset for the regular 3.5mm “minijack” socket.


I recommend the Logitech because it has a convenient built-in USB microphone that avoids non-USB microphone hell, though you’ll obviously then need speakers for the output. I added it to my Ubuntu Hardware. That page has almost paid for the costs of the USB Wi-Fi sticks that I bought to discover one that worked. Maybe it will pay for my webcam too. What other hardware should I use that page for, to discover just one model that really “just works”? As I’ve said before, I think the hardware lists on the Ubuntu wiki are mostly useless for real users because nobody is insisting that “just works” really means “just works”, and nobody is flagging the ones that really do just work.

It was nice to see that these products have dire warnings about not attaching them to your Windows PC before installing the special software, and to see that Amazon has lots of comments about how people couldn’t get them working with Windows.

Getting my microphone to work

A couple of years ago the microphone on my headset (regular, not USB) stopped working. I had used it with Skype briefly. I guessed it was a problem with the headset. A while ago I bought a new headset, and that microphone didn’t work either. Then I knew that it was a software problem with Ubuntu/Linux. I have two new headsets now so I am really really sure.

Today, I was trying to get either Skype or Ekiga working between two computers on my local network, and I still can’t fix it. The laptop is using a USB microphone built in to a webcam, and that works fine. But I can’t get the headset to work with my desktop PC. Here are some screenshot to express my frustration.

System-wide Sound Preferences

The Sound Preferences control panel forces me to choose from a huge list of meaningless device names, none of which work. Here are the basic settings (in Ubuntu Hardy, but this hasn’t worked in Gutsy or Feisty, at least). The test button doesn’t echo any sound to me with any of the choices. Some of the choices show a dialog with a gstreamer pipeline error, which then hangs the control panel.

Sound Preferences

And here are the volume preferences (strangely only available from the panel applet), to show that the microphone is not muted:

Volume Preferences

Also, the Sound Recorder application refuses to start, saying “Your audio capture settings are invalid. Please correct them in the Multimedia settings.”, whatever device I choose in the Sound Preferences. Strangely, Jokosher’s wave graph shows that some input is being received when I speak, but I don’t hear anything when I play it back. It’s nice that Jokosher has no microphone preferences of its own, by the way.

Update: Juerg Billeter pointed out that there’s also a preferences window in the Volume Control, via the Edit menu. It has some obscure check boxes that I can select. None of them seem to help. So now there are yet more things that I can break while looking for the one thing that I need to change to fix the problem, so that one thing probably won’t fix the problem anymore when I find it.

Volume Control Preferences

Application-Specific Sound Preferences

Ekiga asks me to choose one of these devices:

Ekiga Sound Preferences

Skype asks me to choose from this huge list:

Skype Sound Preferences

And what’s with those “default” device choices in both the sound input and output? Neither actually work, though both are offered (and sometimes, but not always, chosen by default) by applications such as Ekiga.

gnome-lirc-properties: Using PolicyKit to get sudo access

Can’t get PolicyKit’s ObtainAuthorization() to work.

gnome-lirc-properties, which I just mentioned needs to edit /etc/lirc/lircd.conf, which requires sudo/root access. Various APIs exist to get temporary sudo/root access but everyone now seems to agree that the new PolicyKit system is the way to go. I’d like to link to a website for it. All the system administration control panels in Ubuntu Hardy Heron seem to use PolicyKit already.

But I can’t get the thing to work, maybe because I’m using Python, and I haven’t found any help so far. I have defined the PolicyKit mechanism, but I can’t get even a simple test of the ObtainAuthorization() method to do anything interesting. This python code does not return anything other than None from ObtainAuthorization() and none of the callbacks are called:


import pygtk
import gtk

import dbus
import os

class TestWindow:
    def on_button_clicked(self, widget, data=None):

	#Call the D-Bus method to request PolicyKit authorization:

        session_bus = dbus.SessionBus()
        policykit = session_bus.get_object('org.freedesktop.PolicyKit.AuthenticationAgent', '/', "org.gnome.PolicyKit.AuthorizationManager.SingleInstance")
        if(policykit == None):
           print("Error: Could not get PolicyKit D-Bus Interface\n")

        gdkwindow = self.window.window
        xid = gdkwindow.xid

        print "Calling ObtainAuthorization..."

        #This complains that no ObtainAuthorization(ssi) exists:
        #granted = policykit.ObtainAuthorization("test_action_id", xid, os.getpid())

        #TODO: Neither of the async callbacks are called, and how could the return value be useful if it is async?
        # Note: Other code (such as gnome-panel) seems to use ShowDialog instead of ObtainAuthorization, though
        # ShowDialog is apparently deprecated (I don't know when), but that also has no effect.
        granted = policykit.ObtainAuthorization("test_action_id", xid, os.getpid(), reply_handler=self.__handleAuthReply, error_handler=self.__handleAuthError)

        print "...Finished."

        print "granted=", granted

    def __handleAuthReply(self, granted):
        print "handleAuthReply: granted\n"

    def __handleAuthError(self, exception):
        print "handleAuthError: not granted: %s\n" % exception

    def on_delete_event(self, widget, event, data=None):
        # Close the window:
        return False

    def on_destroy(self, widget, data=None):

    def show(self):

    def __init__(self):

        self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
        self.window.connect("delete_event", self.on_delete_event)
        self.window.connect("destroy", self.on_destroy)

        self.button = gtk.Button("Obtain Authorization")
        self.button.connect("clicked", self.on_button_clicked, None)

window = TestWindow()

gnome-lirc-properties has a real mechanism and tries to use ObtainAuthorization() for real, if someone wants to look at it properly. Here is the gnome-lirc-properties svn, and a tarball (it doesn’t do much yet).

How to use PolicyKit from an application

In return for asking the lazy web, I’ll try to describe how I think it should work, based mostly on David Zeuthen’s description. There are many opportunities to get something wrong:

  • You install a D-Bus service (a PolicyKit “mechanism”) that does the thing that needs sudo access. PolicyKit will control access to this mechanism. For instance, the Clock applet’s mechanism has a SetTimeZone method. gnome-lirc-properties uses the Python D-Bus bindings to implement its mechanism. I know that our WriteConfigFile() method is far too generic, but we will improve it when we get this working.
  • Update:: And this mechanism’s implementation should ask PolicyKit if it has authorization, and return an error if it doesn’t. Thanks mclasen. I’ll try to find out how to do this. Update: You can do this via the PolicyKit (on the session bus) object’s IsProcessAuthorized() method, now used in the gnome-lirc-properties PolicyKit mechanism.
  • As with other D-Bus services, you install a .service file, so that D-Bus activation can start it on demand. PolicyKit mechanisms use the System bus rather than the Session bus, so you install it in $(datadir)/dbus-1/system-services (/usr/share/dbus-1/system-services on Ubuntu). Here is the .service file for gnome-lirc-properties.
  • As with other D-Bus services, you install a .conf file, saying who can use the service. This is installed in $(sysconfdir)/dbus-1/system.d (/etc/dbus-1/system.d/ on Ubuntu). This is the .conf file for gnome-lirc-properties
  • A .policy file tells PolicyKit who should be allowed to use the mechanism. You install this in $(datadir)/PolicyKit/policy (/usr/share/PolicyKit on Ubuntu). Here is the .policy file for gnome-lirc-properties. I believe this allows system administrators to configure access to these features via these .policy files, and I believe that is the whole point of this D-Bus “mechanism” abstraction.
  • Applications that want to use this mechanism call the ObtainAuthorization() method on the “org.freedesktop.PolicyKit.AuthenticationAgent” D-Bus service, passing the action ID that is mentioned in the .policy file. If necessary, PolicyKit asks for a password (or whatever) for authentication, and presumably then gives the application the appropriate rights. The dialog uses (translatable) text from the .policy file, so it’s very specific to your application. Many applications still seem to be using the ShowDialog() method instead, but that has been deprecated.

gnome-lirc-properties: A GUI to configure Infra-Red Remote Controls

We at Openismus will be working on a little GUI control panel to configure remote controls, so you can more easily, for instance, control a media-center application such as Elisa. We are doing this for Fluendo.

It should end up looking something like this and it will basically just give you a working /etc/lirc/lircd.conf file for your remote control:

gnome-lirc-properties Screenshot

I’ll make a few posts about this, but first here’s some (opinionated) notes about how I think it works now on Ubuntu without this GUI:

Installing lirc

You select the remote control via a curses UI when you install lirc (or when you run sudo dpkg-reconfigure lirc). We would prefer it to install silently and let the user configure it when he wants to. I think the script for this is debian/lirc.config.in in the lirc debian package, though this doesn’t seem to be the whole story. It seems to use the prewritten configuration files in /usr/share/lirc/, listed in the /usr/share/lirc/lirc.hwdb file, which seem to be supplied only with Debian/Ubuntu.
This creates

  • /etc/lirc/lircd.conf, which maps the key names to the key codes supplied by your IR remote (usually assuming that you are using the IR receiver (if any) supplied with the IR remote control. It’s these key names that an application will receive via the liblirc_client library.
  • /etc/udev/rules.d/85-lirc.rules, which uses /etc/init.d/lirc, which starts “/usr/sbin/lircd –device=/dev/lirc0”.

Custom Configuration

When the lirc package does not know about your hardware, or if it has a bad configuration file, you can use the irrecord utility (installed with lirc) to generate a custom lircd.conf file, which you can move to /etc/lirc/lircd.conf. It checks for key codes and some other aspects of the remote control. Here is an example of an irrecord run. irrecord is a command-line utility which takes input on stdin. Doing this programatically is going to be difficult, probably requiring the creation of a libirrecord in the lirc sources.

Note that the default device for lirc is /dev/lirc, and it doesn’t check for other devices automatically, but applications don’t need to specify the device because they just communicate with lird via liblirc_client. However, the irrecord utility doesn’t use lircd so you’ll need to use the –device option with it too.

The application

The application then creates a .lircrc file (Elisa creates one in /tmp when it starts, and this seems the only sensible thing to do) which maps these key names to “command” names. This seems like a useless extra step because most applications will just invent “command” names which are identical (or near identical) to the “key” names. The entries in this .lircrc must use the same “prog” identifier string as the application has passed to the lirc_init() function – another annoying invitation to failure. This is presumably useful when using one .lircrc file to control multiple applications somehow, but I can’t see how that could ever be useful – a global .lircrc file could at the most be used to _start_ applications, not control them.

Update:: Of course, I do have the strong feeling that remote controls should be just another input device, like mice and keyboards, so the whole lirc daemon thing seems odd. But I’m not a kernel or X programmer. This might even be planned for the future, but I don’t know. We do need something to make lirc work easily now.

Bug-fixed Glom 1.6 in Ubuntu 7.10 “Gutsy”

I’m regularly annoyed that no stable version of Ubuntu has a bug-fixed version of Glom. For instance, Ubuntu Gutsy has Glom 1.6.0 and the ubuntu-updates policy does not allow it to have Glom 1.6.6. Unfortunately Glom 1.6.0 and some dependencies have bugs making it mostly unusable, such as a failure when changing field types, and not shutting PostgreSQL down properly.

The irony is that Glom is totally open source / free software and is using the recommended deployment method (shipping with the distro itself), but this doesn’t allow us to get bug fixes to users. I understand that non security bug-fixes for non-essential software is not a priority for Ubuntu but it’s frustrating for users. I suspect that they bend the rules for essential stuff like OpenOffice. I find myself wishing for a security problem to fix in Glom just so I can get the non-security bug fixes released along with the security fix.

However, Ubuntu recently created the PPA (Personal Package Archive) system, so Daniel has made some updated packages available in the Openismus PPA. Forcing people to add a repository will lose us many non-technical users but it’s the best we can do right now. I’ve updated the Glom download page.

GNOME versus projectors

My post about my new not-working-automatically Monitor reminded me of something that I forgot to follow up, though it’s probably unrelated.

At FOSDEM in February 2007, I muttered to X man Keith Packard that my laptop (with Intel graphics) didn’t work with the projector. I complain to everyone about this at all conferences, because it never works for me, regardless of laptop or projector model. Either the size is wrong or the sync rate is wrong or there’s nothing to give me any clue. It often works up to the login and then stops working after I’ve logged in. So I always borrow someone else’s laptop at the last moment. This is just one reason why my presentations are always shit.

But Keith dropped a clue. He said that immediately after login GNOME reset something that breaks things. I chased him about it in email afterwards and he said
“Oh, I found it — if your configuration settings include a monitor size, gnome would randr you to that size. I can’t remember where that was as I deleted it from my config though.”

Can anyone do something with this nugget of information?