Recently one of the Gnome Foundation directors quit, and there has been a proposal to expand the board by 2 members. In both cases, the proposed new members have been taken from the list of candidates who did not get seats in the last election from highest vote getter down.

While at first this sounds sensible, the voting system we use doesn't provide a way of finding out who would have been selected for the board if a particular candidate was removed from the ballot.

The progress on JHBuild has continued (although I haven't done much in the last week or so). Frederic Peters of JhAutobuild fame now has a CVS account to maintain the client portion of that project in tree.

Perl Modules (#342638)

One of the other things that Frederic has been working on is support for building Perl modules (which use a Makefile.PL instead of a configure script). His initial patchworked fine for tarballs, but by switching over to the new generic version control code in jhbuild it was possible to support Perl modules maintained in any of the supported version control systems without extra effort.

Yesterday there were some news reports about the opposition party in Victoria issuing a FOI request and finding that the breath testers used to test blood alcohol content routinely under report the readings by up to 20%. They used this fact to show that it was giving negative readings for some people who are a little over the limit. On the face of it this sounds like a problem, but when you look at the statistics the automatic reduction makes sense.

I've been doing most JHBuild development in my bzr branch recently. If you have bzr 0.8rc1 installed, you can grab it here:

bzr branch http://www.gnome.org/~jamesh/bzr/jhbuild/jhbuild.dev

I've been keeping a regular CVS import going at http://www.gnome.org/~jamesh/bzr/jhbuild/jhbuild.cvs using Tailor, so changes people make to module sets in CVS make there way into the bzr branch. I've used a small hack so that merges back into CVS get recorded correctly in the jhbuild.cvs branch:

One of the new features in the soon to be released bzr 0.8 is the new "knit" storage format.

When comparing the size of the repository data for jhbuild with "knit" and "metadir" formats (metadir is just the old storage format with repository, branch and checkout bookkeeping separated), I see the following:

                metadir   knit

Size 9.9MB 5.5MB Number of files 1267 307

The reason for the smaller number of files is that information about all revisions in the repository is now stored together rather than in separate files. So the file count comes out at a constant plus 2 times the number of tracked files (a knit index file plus the knit data file). For comparison, the CVS repository I imported this from was 4.4MB, and comprised 143 files.

One of the new features comming up in the next release of bzr is support for shared repositories. This provides a way to reduce disk space needed to store multiple related branches. To understand how repositories work, it helps to know a bit about how branches are stored by bzr.

There are three concepts that make up a bzr branch:

1. A checkout or working tree. This is the source files you are working with. It represents the state of the source code at some recorded revision plus any local changes you've made. In the diagram on the right, it is represented as the red node.
2. The branch, consisting of a linear sequence of revisions. This is represented by the blue nodes in the diagram. Note that there may be multiple paths from the first revision to the current revision due to branching and merging. The branch revision history indicates the path that was taken by this particular branch.
3. The repository, being a store of the text of all the revisions in the ancestry of the branch, plus metadata about those revisions. This essentially stores information about every node and edge in the diagram.

In previous versions of bzr, this information was not clearly separated. However with the new default branch format in bzr 0.8 they are separated, and a particular directory need not contain all three parts, which is what makes the space savings and performance improvements possible.

Rodney: my suggestions for intltool were not intended as an attack. I just don't really see much benefit in intltool providing its own po/Makefile.in.in file.

The primary difference between the intltool po/Makefile.in.in and the version provided by gettext or glib is that it calls intltool-update rather than xgettext to update the PO template, so that strings get correctly extracted from files types like desktop entries, Bonobo component registration files, or various other XML files.

One issue that was meantioned as a Gnome Goal was to switch packages to use a po/LINGUAS file.

The idea makes sense — translators only need to edit a simple text file to add a new translation to an application, rather than having to modify the configure.in/configure.ac file without breaking things. Unfortunately, the suggested way of supporting this is a pretty big hack. A better long term solution would be to use the upstream gettext macros and po/Makefile.in.in infrastructure.

I've been testing out Ekiga recently, and so far the experience has been a bit hit and miss.

• Firewall traversal has been unreliable. Some numbers (like the SIPPhone echo test) work great. In some cases, no traffic has gotten through (where both parties were behind Linux firewalls). In other cases, voice gets through in one direction but not the other. Robert Collins has some instructions on setting up siproxd which might solve all this though, so I'll have to try that.
• The default display for the main window is a URI entry box and a dial pad. It would make much more sense to display the user's list of contacts here instead (which are currently in a separate window). I rarely enter phone numbers on my mobile phone, instead using the address book. I expect that most VoIP users would be the same, provided that using the address book is convenient.
• Related to the previous point: the Ekiga.net registration service seems to know who is online and who is not. It would be nice if this information could be displayed next to the contacts.
• Ekiga supports multiple sound cards. It was a simple matter of selecting "Logitech USB Headset" as the input and output device on the audio devices page of the preferences to get it to use my headset. Now I hear the ring on my desktop's speakers, but can use the headset for calls.
• It is cool that Ekiga supports video calls, but I have no video camera on my computer. Even though I disabled video support in the preferences, there is still a lot of knobs and whistles in the UI related to video.

Even though there are still a few warts, Ekiga shows a lot of promise. As more organisations provide SIP gateways become available (such as the UWA gateway), this software will become more important as a way of avoiding expensive phone charges as well as a way of talking to friends/colleagues.

Thought I'd post a followup on my previous post since it generated a bit of interest. First a quick summary:

• It is not an Ubuntu Dapper specific bug. With the appropriate combination of fonts and pango versions, it will exhibit itself on other Pango-enabled Firefox builds (it was verified on the Fedora build too).
• It is not a DejaVu bug, although it is one of the few fonts to exhibit the problem. The simple fact is that not many fonts provide ligature glyphs and include the required OpenType tables for them to be used.
• It isn't a Pango bug. The ligatures are handled correctly in normal GTK applications on Dapper. The bug only occurs with Pango >= 1.12, but that is because older versions did not make use of the OpenType tables in the "basic" shaper (used for latin scripts like english).
• The bug only occurs in the Pango backend, but then the non-Pango renderer doesn't even support ligatures. Furthermore, there are a number of languages that can't be displayed correctly with the non-Pango renderer so it is not very appealing.

The firefox bug is only triggered in the slow, manual glyph positioning code path of the text renderer. This only gets invoked if you have non-default letter or word spacing (such as justified text). In this mode, the width of the normal glyph of the first character in the ligature seems to be used for positioning which results in the overlapping text.

Ran into an annoying Firefox bug after upgrading to Ubuntu Dapper. It seems to affect rendering of ligatures.

At this point, I am not sure if it is an Ubuntu specific bug. The current conditions I know of to trigger the bug are:

• Firefox 1.5 (I am using the 1.5.dfsg+1.5.0.1-1ubuntu10 package).
• Pango rendering enabled (the default for Ubuntu).
• The web page must use a font that contains ligatures and use those ligatures. Since the "DejaVu Sans" includes ligatures and is the default "sans serif" font in Dapper, this is true for a lot of websites.
• The text must be justified (e.g. use the "text-align: justify" CSS rule).

If you view a site where these conditions are met with an affected Firefox build, you will see the bug: ligature glyphs will be used to render character sequences like "ffi", but only the advance of the first character's normal glyph is used before drawing the next glyph. This results in overlapping glyphs:

Emmanuel: if you are using a language like Python, you can let the language keep track of your state machine for something like that:

def load_items(treeview, liststore, items):
    for obj in items:
        liststore.append((obj.get_foo(),
                          obj.get_bar(),
                          obj.get_baz()))
        yield True
    treeview.set_model(liststore)
    yield False

def lazy_load_items(treeview, liststore, items):
    gobject.idle_add(load_items(treeview, liststore, item).next)

Here, load_items() is a generator that will iterate over a sequence like [True, True, ..., True, False]. The next() method is used to get the next value from the iterator. When used as an idle function with this particular generator, it results in one item being added to the list store per idle call til we get to the end of the generator body where the "yield False" statement results in the idle function being removed.

Back in January I started working on a new Python wrapper for the GPGME library. I recently put out the first release:

http://cheeseshop.python.org/pypi/pygpgme/0.1

This library allows you to encrypt, decrypt, sign and verify messages in the OpenPGP format, using gpg as the backend. In general, it stays fairly close to the C API with the following changes:

• Represent C structures as Python classes where appropriate (e.g. contexts, keys, etc). Operations on those data types are converted to methods.
• The gpgme_data_t type is not exposed directly. Instead, any Python object that looks like a file object can be passed (including StringIO objects).
• In cases where there are gpgme_op_XXXX() and gpgme_op_XXXX_result() function pairs, these have been replaced by a single gpgme.Context.XXXX() method. Errors are returned in the exception where appropriate.
• No explicit memory management. As expected for a Python module, memory management is automatic.

The module also releases the global interpreter lock over calls that fork gpg subprocesses. This should make the module multithread friendly.

I've been in London for a bit over a week now at the Launchpad sprint. We've been staying in a hotel near the Excel exhibition centre in Docklands, which has a nice view of the docs and you can see the planes landing at the airport out the windows of the conference rooms.

I met up with James Bromberger (one of the two main organisers of linux.conf.au 2003) on Thursday, which is the first time I've seen him since he left for the UK after the conference.

Recently, Jeff brought up the issue of the use of the old Gnome logo on Slashdot. The reasoning being that since we decided to switch to the new logo as our mark back in 2002, it would be nice if they used that mark to represent stories about us.

Unfortunately this request was shot down by Rob Malda, because the logo is "either ugly or B&W (read:Dull)".

Not to be discouraged, I had a go at revamping the logo to meet Slashdot's high standards. After all, if they were going to switch to the new logo, they would have done so when we first asked. The result is below:

I put out a new release of gnome-gpg containing the fixes I mentioned previously.

The internal changes are fairly extensive, but the user interface remains pretty much the same. The main differences are:

• If you enter an incorrect passphrase, the password prompt will be displayed again, the same as when gpg is invoked normally.
• If an incorrect passphrase is stored in the keyring (e.g. if you changed your key's passphrase), the passphrase prompt will be displayed. Previously you would need to use the --forget-passphrase option to tell gnome-gpg to ignore the passphrase in the keyring.
• The passphrase dialog is now set as a transient for the terminal that spawned it, using the same algorithm as zenity. This means that the passphrase dialog pops up on the same workspace as the terminal, and can't be obscured by the terminal.

Comments:

Marius Gedminas - 2 Mar, 2006

Any ideas how to use it with Mutt?

Launchpad got a mention in the latest Everybody Loves Eric Raymond comic. It is full of inaccuracies though — we use XML-RPC rather than SOAP.

Comments:

opi - 24 Feb, 2006

Oh, c'mon. It was quite fun. :-)

In my previous post, I mentioned using Tailor to import jhbuild into a Bazaar-NG branch. In case anyone else is interested in doing the same, here are the steps I used:

1. Install the tools

First create a working directory to perform the import, and set up tailor. I currently use the nightly snapshots of bzr, which did not work with Tailor, so I also grabbed bzr-0.7:

$ wget http://darcs.arstecnica.it/tailor-0.9.20.tar.gz
$ wget http://www.bazaar-ng.org/pkg/bzr-0.7.tar.gz
$ tar xzf tailor-0.9.20.tar.gz
$ tar xzf bzr-0.7.tar.gz
$ ln -s ../bzr-0.7/bzrlib tailor-0.9.20/bzrlib

2. Prepare a local CVS Repository to import from

As most people probably know, the Gnome project is planning a migration to Subversion. In contrast, I've decided to move development of jhbuild over to bzr. This decision is a bit easier for me than for other Gnome modules because:

• No need to coordinate with GDP or GTP, since I maintain the docs and there is no translations.
• Outside of the moduleset definitions, the large majority of development and commits are done by me.
• There aren't really any interesting branches other than the mainline.

I plan to leave the Gnome module set definitions in CVS/Subversion though, since many people help in keeping them up to date, so leaving them there has some value.

There is a new "We Love Our Lamb on Australia Day" commercial by Sam Kekovich. It is definitely worth watching. It probably won't piss off as many people as last year's did though :)

Last year's ad seems to still be available here.

Comments:

Martin Sevior - 17 Jan, 2006

Excellent James! Very funny :-)

Cheers

Martin

Richard Kleeman - 19 Jan, 2006

Bloody ripper Jim!

The Bugzilla migration on Friday went quite well, so we've now got all the old Ubuntu bug reports in Launchpad. Before the migration, we were up to bug #6760. Now that the migration is complete, there are more than 28000 bugs in the system. Here are some quick points to help with the transition:

• All bugzilla.ubuntu.com accounts were migrated to Launchpad accounts with a few caveats:

  1. If you already had a Launchpad account with your bugzilla email address associated with it, then the existing Launchpad account was used.
  2. No passwords were migrated from Bugzilla, due to differences in the method of storing them. You can set the password on the account at https://launchpad.net/+forgottenpassword.
  3. If you had a Launchpad account but used a different email to the one on your Bugzilla account, then you now have two Launchpad accounts. You can merge the two accounts at https://launchpad.net/people/+requestmerge.

• If you have a bugzilla.ubuntu.com bug number, you can find the corresponding Launchpad bug number with the following URL:

The gnome-gpg utility makes PGP a bit nicer to use on Gnome with the following features:

• Present a Gnome password entry dialog for passphrase entry.
• Allow the user to store the passphrase in the session or permanent keyring, so it can be provided automatically next time.

Unfortunately there are a few usability issues:

• The anonymous/authenticated user radio buttons are displayed in the password entry dialog, while they aren't needed.
• The passphrase is prompted for even if gpg does not require it to complete the operation.
• If the passphrase is entered incorrectly, the user is not prompted for it again like they would be with plain gpg.
• If an incorrect passphrase is provided by gnome-keyring-daemon, you need to remove the item using gnome-keyring-manager or use the --force-passphrase command line argument.

I put together a patch to fix these issues by using gpg's --status-fd/--command-fd interface. Since this provides status information to gnome-gpg, it means it knows when to prompt for and send the passphrase, and when it gave the wrong passphrase.

The migration is finally going to happen, after much testing of migration code and improvements to Malone.

If all goes well, Ubuntu will be using a single bug tracker again on Friday (as opposed to the current system where bugs in main go in Bugzilla and bugs in universe go in Malone).

Comments:

Keshav - 17 Jan, 2006

Hiiii,

I am Keshav and i am 22. I am working as software dev.engineer in Software Company . I am currently working on Bugzilla. I think i can get some help in understanding how i can migrate bugzilla . Can you provide me the tips and list the actions so that i can come close in making a effective migration functionality

Thomas: that behaviour looks like a bug. Are all of those volumes mountable by the user? The drive mount applet is only meant to show icons for the mount points the user can mount.

Note also that the applet is using the exact same information for the list of drives as Nautilus is. If the applet is confusing, then wouldn't Nautilus's "Computer" window also be confusing?

To help debug things, I wrote a little program to dump all the data provided by GnomeVFSVolumeMonitor:

In my previous article, I outlined the thought process behind the redesign of the drive mount applet. Although it ended up without any preferences, I don't necessarily think that it doesn't need any preferences.

A number of people commented on the last entry requesting a particular preference: the ability to hide certain drives in the drive list. Some of the options include:

1. Let the user select which individual drives to display
2. Let the user select which classes of drive to display (floppy, cdrom, camera, music player, etc).
3. Select whether to display drives only when they are mounted, or only when they are mountable (this applies to drives which contain removable media).

Of these choices, the first is probably the simplest to understand, so might be the best choice. It could be represented in the UI as a list of the available drives with a checkbox next to each. In order to not hide new drives by default, it would probably be best to maintain a list of drives to hide rather than drives to show.