GNOME People

Congrats to the VirtualBox team on being the first (that I know of) to provide a working Seamless/Unity/Coherence mode for OpenSolaris 2008.05 guests on OS X.  (I don’t know how long this has actually worked, I only tried it last night, in VB 1.6…)

Obviously a bit of work to do before it rivals the sort of integration that Windows guests enjoy in Fusion and Parallels, but it’s a good step in the right direction…

Being able to put on a Live DVD of a band you like (in this case, Mew from Copenhagen) and crank up the volume. It creates an excellent head space and atmosphere to get work done.

Next up - Jeff Buckley at the Metro in Chicago.

Funny - when the font chosen for the credits is so big that assistant grip gets shortened to “ass. grip” I don’t know if it’s the Danish sense of humour or just a funny accident.

I'd like to use the same/etc/sudoers file for a lot of servers. sudo seems to support this because it has Host_Alias. What's the best way to share the same file ?

• the path to /etc/sudoers seems to be hardcoded, so i can't put it on a network fs.
• i haven't find any ldap support
• scp the file to all the hosts ?

Any experience in that ? Thanks.

And today, I finally turn 30. I've been grumpy about this day getting closer and closer for the last three or four years, which have passed in front of my eyes with me nearly not noticing.

The last year has had more downs than ups, and at times has been quite dark. I feel things are slowly getting better, and I spend more time looking forward than back, which certainly should help.

Tomorrow I'll hold a small party at home with some friends, but the big and proper event will be in September, when five or six people in our colla, born in 1978, will celebrate our 30th birthday, in a massive, weekend-long party already dubbed La festa dels excessos. You shouldn't miss this one!

Thanks to the many people who have phoned, texted or emailed me already. It reminds me that I'm surrounded by people who love me and were there when I needed them.

Converting a project from one version control system to another is always painful. Doing so is a rather momentous change to contemplate. With organizational & community inertia being what it is, not something easily rushed into. Worse is when you attempt to use a modern tool as a better front end for an old one.

One of the neat things about the 3rd generation distributed version control system projects (ie Bazaar, Git, or Mercurial) is their plugins which allow you to continue to work with a Subversion upstream project but use the modern tool as a front end locally. For those of us who have been very productively using DVCS for some time, this is a godsend.

Using one of these plugins to thence evaluate the usability or performance of one of a DVCS is not really the best approach one could take; none of them were built with using Subversion as a peer in mind, and lord knows Subversion is not built to store revisions with such complex relationships. Thus the idea has turned out to be a very challenging problem space for everyone but most have had their tools mature to the point where Subversion is the bottleneck. And despite my misgiving that starting out your experience with a 3rd generation DVCS by first using it to access some legacy project will not show your new shiny tool in its best light, the reality remains that most people need to get on with being productive, and doing a full blown conversion (or starting use with a brand new projects) are less likely to be your circumstance.

Having been using Bazaar (known best by the abbreviation bzr) for well over 18 months and overall being very happy with the experience, I would like to encourage other GNOME hackers to try it; likewise I have some patches I’d like to contribute to GTK so I thought I’d start by using bzr-svn to get a branch of GTK as a starting point (and to likewise give Bazaar’s Subversion interface a workout). So I created Bazaar branch of GTK.

The first step was to create a Bazaar branch that represents the foreign Subversion repository. This was painful.

I originally attempted to do this while I was at the GTK Hackfest we had in Berlin; that turned out to be a disaster because (as one does at a conference or meeting) we were moving around every few hours connecting and disconnecting from the ‘net, and I was busy trying to do this from my laptop rather than a server somewhere. (Unfortunately bzr-svn relies on a memory fix that is not yet in the released version of Subversion, and not every distro has their Subversion patched with it). So that fell flat on its face.

I was able to restart the process a week or two later and leave it running overnight. Along the way I’d learned a technique for doing a few hundred revisions at a time (do bzr pull -r $i in a loop and increment the variable by a hundred or whatever each cycle) and so was able to cope with the need to disconnect periodically. Which is well, because it took 2 days to do the import.

While I was at first appalled by this, I really can’t blame Bazaar. The GTK codebase is, of course, rather large. First preserved commits were in 1997; there are over 15,000 revisions; a working tree (excluding VCS metadata) is 83 MB in size. The bigger problem however, is that Subversion is not fast at accessing historical data (the time taken to process revisions started at over 32 minutes per 100 but eventually dropped to about 9 minutes per 100 as it got to the most recent history; interesting).

Clearly, I could have picked an easier example for my experiments with bzr-svn, but it’s done now.

I wasn’t entirely sure whether the DVCS property that branches are all peers would apply to one that had started life backed by a Subversion repository would hold, but things work just as they are supposed to. Creating a new branch to work on a feature with bzr branch, or use the technique of using a bzr checkout along with bzr switch to do change-in-place, both worked fine. So I’m all set.

The real point, though, was to encourage more GNOME hackers to give Bazaar a try. If everyone had to put up with a endless import process like mentioned above then no one would touch it. But now that the branch is created (and up to date as of yesterday or so), anyone can use it.

With Olav’s concurrence, I put my branch on in my GNOME directory, so you can branch from it as follows:

You do the first step so that you can create a “shared repository” (in Bazaar parlance) which will allow that various branches under that directory will share all the revision data for the project. I need to warn you, though. Modern DVCS tools give you the full history of the project, but for a large project that can be pretty big. If you grab the above branch you’ll be downloading about 180 MB and it takes about 5 minutes. Yes 5 minutes is a long time, but no there’s no way around it* and in any case 180 MB is not unreasonable for such a mature project. Don’t be too worried if it seems like it is taking a bit to do the transfer. You only need to do it once, and look on the bright side. It took me 2 days. Just let it run.

Personally, I always do my work in a working branch separate from my mirror of upstream, allowing me to easily compare against the last update of upstream that I have done. So:

and away we go. Branching takes like 3 seconds. Nice and fast, no problem.

I haven’t got a script running religiously updating my GTK branch; I do a bzr pull locally once every few days in my copy of 'trunk' and have been pushing that up to http://www.gnome.org/~afcowie/gtk+/trunk/. But now that you’ve got the branch, you don’t have to rely on me anymore; this whole distributed thing kicks in and you can do it yourself. Assuming you have a svn.gnome.org account, then you can update with:

(use the --remember argument the first time to change where it updates from by default so you’re not relying on my branch anymore) and push with:

The very first time you update from Subversion bzr-svn will have to build some caches and whatnot locally, but it’ll be pretty fast from there on.

I’m ignoring the pushing and pulling of revisions between your mirror of ‘trunk’ and your local 'working' (or whatever) branch; I’m sure you can figure that part out yourself: but here’s a hint: do your work, test it, and commit it, all in 'working'; repeat; then use, say:

to consider what your current patch looks like, then shuttle it to 'trunk' with bzr pull or bzr merge (assuming you run it from 'trunk’ and whether you need to merge or not) and then bzr push to svn.gnome.org. Hope it works for you.

If you need help, poke your head into #bzr on FreeNode or write to their mailing list, or ping me and I’ll try and lend a hand. Make sure you’re using the latest releases; I doubt it will work otherwise and so recommend that you use bzr >= 1.4.0 and bzr-svn >= 0.4.10. Older versions do not contain critical bug fixes. I also encourage you to grab bzr-gtk >= 0.93.0 as the visualize command it adds:

is really amazing.

Good luck!

AfC

Update:
You need to have PycURL installed (it’s an optional dependency; used at runtime if detected). There is a bug that will prevent you doing the branch from me if you don’t. Debian and Ubuntu package python-pycurl; Gentoo USE=curl pulls in package dev-python/pycurl; Fedora package is also python-pycurl.

This very moment as the GNOME systems administration team is presently working through the consequences of the Debian SSH key vulnerability; they have for the moment very properly locked down all access to the services provided to GNOME hackers, and that knocks out access to the Subversion server meaning people can’t work with their source code properly. If there was ever a clearer demonstration on the inadequacy of old 1st generation centralized version control systems, I cannot think of it.

Vagalume 0.6 is here!

Among the new features introduced in Vagalume 0.6, the coolest one is probably the brand new tray icon for desktop users written by Mario, similar to the one already available for Maemo:

Other highlights from this version include:

• Update the status message of your IM client. Tell everyone what you’re listening to. Currently supported: Pidgin, Gajim, Gossip and Telepathy
• Gettext support: Vagalume has been translated into Portuguese, German, Finnish, Spanish, Galician and Italian
• New setting to disable the love/ban confirmation dialogs
• New D-BUS methods and a script to control Vagalume from the command line (currently only for Maemo, more news soon)
• Osso-backup support

I would like to thank all the contributors, in particular Tim Wegener for his work in the IM status support. And of course all the translators too!

Last but not least, I’d like to remind you again that, as I said in my previous post, I’ll be at LinuxTag 2008 in Berlin with other Maemo hackers. Hope to see you there!

And now, enjoy!

P.S.: I’m moving Vagalume to Maemo extras, so one of these days it should be available there. Stay tuned!

Update: Vagalume 0.6 is now available in Maemo Extras

• Shirky: A Group Is Its Own Worst Enemy (tags: social software article)
• How to run an effective meeting on IRC « Striving for greatness Advice for running meetings on IRC - sensible stuff (tags: irc meeting notes)

Let me just point out, that the consequences affect all users of SSH. Therefore IMHO all other Linux and BSD distributions need to release a security update to OpenSSH as well, to prevent the use of insecure (too common) keys, because it threatens the security of their systems as well!

Apparently, there are only about 2^15 different keys generated by the SSH versions shipped with Debian for 2 years. It's really surprising that noone noticed this earler. This is just about 32767 different keys. (For each type, size and endianess, but that still makes this number much much much too low) The weakness is caused by a bad random number generator in the Debian package.

Hackers have already generated all these 32767 different keys, for two key lengths and types. In a few hours, they'll also have generated all the 4096 bit keys that could have been generated. Other key lengths are uncommon and sometimes might even be unsupported. Most people use keys with length 1024 or 2048.

So we now have about 32767 keys which are used by lots of Debian and Ubuntu users. That's not very much. Now you have to realize how the keys are used:

The key is used to log into a system without a password. Sometimes a key is protected with a passphrase (you really should do that), but this doesn't help here, because an unencrypted clone of the key was already generated.

Sometimes (or let me even claim 'often') one such key is also used to login as root into a server. This is equivalent to just 32767 different passwords being used as root passwords. So with about this number of tries, an attacker might be able to log into your server as 'root'!

Now the weakness is 'distributed' by the users, it's not just a server-side vulnerability. If your server is running e.g. RedHat, it doesn't mean it is secure!.

In fact, if your server is running Debian and you installed the Debian security update for openssh, it will be much more secure than the RedHat server. Because the Debian server has a blacklist of keys that are too common. The other-Linux server who doesn't have this blacklist doesn't know that a certain 'weak' key is not trustworthy.

Fixing the bad key-generation is just half of the deal. "Recalling" all the keys in use out there is the big challenge, that affects all systems using SSH (and to a different extend, SSL). The most reliable way is if all other distributions would release a security update as well, which refuses to accept the keys that were generated by vulnerable Debian systems.

Let me just repeat it in other words: Any Linux/Unix/*BSD system is vulnerable that grants access to a key that was generated on an affected Debian or Ubuntu system. (Until the system has a reliable detection method of such weak keys.) Keys are usually generated on the users workstation, so if any of your users is or was potentially running Debian or Ubuntu ... you get the idea.

Note that if you are not careful, you might lock yourself out from your server. If you don't have or remember the password, installing the security update might disable your login key. So if your key is bad, make sure to generate a new, secure key and distribute it ASAP. Also remove any vulnerable key ASAP; remember that hackers now have a list of all possible keys and could use that to brute-force login.

(This is mostly based on from what I heard from others. Still you should take the warnings seriously, I guess ...)

I decided to buy an ebook reader recently as there's a lot of manga I want to catch up on and after borrowing mallum's Sony Librie for a while, I've found that it's a great format for reading comics. Brilliant to de-stress while things are compiling. Anyway, Linux tools for such devices seem to be woefully lacking, so I figured it couldn't be that hard to write my own (for my own particular needs) - and thanks to FOSS, it really wasn't :)

Thanks to The GIMP's scripting engine, I have a script that can transform images into the required format; thanks to bash, I have a shell script that can get all the images to the script; and thanks to cairo, it was incredibly easy to write an app that turns a load of PNGs into a PDF. Source for all can be found here - handy if you have a Sony Reader/Librie or an Irex Iliad or something along those lines. Probably less useful for Kindle users..?

GNOME HIG v2

Whose bright idea was it to have Ctrl-A close the current note in the version of Tomboy shipping with Ubuntu 8.04? This was a really bad idea.

Update: Owen Taylor on #gnome-hackers, and 5 minutes later Vincent Untz in a comment, hit on the answer: http://bugzilla.gnome.org/show_bug.cgi?id=162726

The upgrade to Ubuntu 8.04 had installed the US layout on me, even though I have an AZERTY keyboard (which was the layout selected). So when I hit Ctrl-A, GNOME was helpfully saying that I must have really meant Ctrl-Q. This is really useful if you’re using a non-latin layout, since you can still use Latin shortcuts by installing a US keyboard layout, but if you have another Latin keyboard layout, this sucks big-time.

So, in fact, Tomboy wasn’t closing the current note, it was closing all notes (it just happens that I only ever had one note open at the time).

Hi !

Here is my new blog that I’ve created to post my news about my GSoc. I’m a belgian student at ULB (Free University of Brussels) in computer sciences. I’m glad to be accepted with my friend Gabriel Corvalan Cornejo who will work on the VoIP features of Telepathy/Empathy with a focus on video conference.

Indeed I will work on Empathy.

Empathy is a GNOME client using reusable widgets created for it. It uses Telepathy and MC for account manager. Empathy is built on libempathy and libempathy-gtk librairies. The widgets can be used in any GNOME program with libempathy-gtk.

For more informations about empathy you can check the website.

My work consists to create a new theme API. Empathy uses his own themes and it is really difficult to add new one. So I will create an API using GtkWebkit to use HTML/CSS themes on Empathy. After, it will possible to intergrate Adium’s themes !

I’m not going to get into details because I have no interest in a pissing match but I am sure anyone who has been in any large Open Source project has had to deal with poisonous people. It sucks even more when that poisonous person trumpets themselves and actually has an audience of easily gullible listeners who’s eyes have wool pulled over and ears, cotton shoved into. It sucks yet even more when that person leaves the project, and then becomes self proclaimed pundit of the project, proclaiming to have the cure to all ills, as the person proclaimed when part of the project as well. And the total suck comes from the fact that that person, who was at first a trusted member of the project and given much responsibility, who failed on almost every single one of their given tasks, is one of the main reasons for any issues which said person now sells the cure for. We call people like this snake oil salesmen, charismatic people with no morals other than their own desire to get ahead at any cost, and it suck to see people like this still exist and still can pull one over on the masses. This day is the suxor.

Last week I was blitzed by being cc’d on a lot of email signature related bugs. :-)  To remain calm and keep delusions of control active I started on a wiki page for Message Signatures in Thunderbird.  Right now the page contains lots of links to relevant areas and ascii art mockups for choosing a default signature for accounts; it’s meant to collect thoughts, research, and define direction.

Managing Signatures

I think a general improvement plan will involve simplifying the signature selection and creation process.  Here are a number of points that I think can improve the current aspects of signature management.

• Each account is created a default signature (from the person’s name and organization)
• Every signature can be edited with a built-in signature editor (created from the compose window)
• Signatures can be imported from files, but are saved in the Thunderbird profile or preferences (see bug 324495)
• A separate dialog is used for managing all signatures, with import, add, edit, remove actions as well as a link to see the signature extensions available from AMO.

Concept Mockup of Signature Chooser in Account Settings

Using Signatures

In the relevant extensions section of the wiki page I tried to list most of the extensions that are dealing with how to use signatures in the compose window.  There are a number of ways of solving this problem and lots of issues surrounding posting style that I am hesitant to battle with.

Several bugs (see bug 219197, bug 73567, and bug 37644) have suggestions that attack the problem from different angles.  New comments and suggestions are welcome!

ASCII Art Side Note

I think I’ve started to use Johan’s ASCII Art Mockup post as a reference for my own ascii art; it’s good to see some style written down somewhere.

Since we're not supposed to start coding for GSoC until May 26th, I'm spending this time reading up on GNOME and Rhythmbox programming, as well as music information retrieval algorithms. Most of the time when I'm writing papers I just create a bibtex file of my references, but a program that I've used on occasion is Referencer. It's nice to be able to organize my articles with tags and have links to the papers themselves, but one thing that I've always found lacking in Referencer is the ability to add my own notes about the papers. So, I took it upon myself to add note functionality, and submitted a bit of a messy patch, as I've never worked with gtkmm before and I didn't really know what I was doing. It was cleaned up and fixed quite a bit by Referencer's developer John Spray, and the end result looks something like this:

I'm sure there's plenty of bugs to be ironed out (for example, ctrl+v tries to add a new document instead of pasting text in the notes pane, although right click -> paste works fine), and for now the notes field only supports plain text, but it's a start. There's also the ability to export notes as html to create a document summing up the articles (similar to Zotero's export function).

While it might not be the best idea to use the development version of Referencer, I definitely recommend checking out this program if you're looking for a neat way of organizing articles and creating bibtex files.