For the basic setup, see this tutorial. So, once you have contacts in the Evolution CouchDB Ubuntu One addressbook, syncing to Ubuntu One happens automatically:

The same contacts show up automatically in the Ubuntu One web UI:

Now, we just need to get mobile devices (N900, Android, etc) to sync contacts there also, and your contacts would be everywhere you need them!

Enjoy it!

Since this is also my first post about it (didn’t want to make it too public until it worked great), I wish to give special thanks to Sandy Armstrong, Tomboy’s super hacker, whose help in making this work has been very valuable. Not only he helped us in all the problems we found, but he was very receptive on our suggestions for changes in the syncing protocol. So, every time you sync your notes (to Ubuntu One or a Snowy server), please save some money to pay him (and me, if possible) some beers

• First, about RMS’s talk. I really didn’t find offensive his comments, just was a bit upset by the way he answered some of the questions asked by some people (this is a stupid question or something like that was one of his answers), but well, I can live with that and didn’t feel offended at all. But I found his talk very, very (did I say very?) boring. Talking about how cool is free software in front of an audience of free software enthusiasts, and about the history of GNOME and KDE in front of many of the core contributors to those projects was, IMHO, a total waste of time. While the talk is great for other audiences, it was totally out of place at GCDS. And that’s all I have to say about this, no meme from me.
• There was a lot of interest on CouchDB from many people:
  • Tracker guys might want to use it to store metadata and files.
  • Roberto Majadas, the newest incorporation to the GNOME Hispano board, has been working on Vala bindings for my couchdb-glib library. He should announce them soon, I think.
  • Henri, from Midgard, implemented, while in Gran Canaria, the replication protocol used by CouchDB for Midgard, which means you would be able to sync (contacts, bookmarks, notes, etc) not only to CouchDB servers, but also to any server running Midgard.
  • People liked a lot (at least they applauded a lot) the demos for the stuff we’ve doing for bookmarks (Firefox) and contacts (Evolution and Akonadi) storage in CouchDB, that Steve Alexander showed in his talk on Wednesday. Thanks BTW to Ryan Lortie, who kindly gave his slot for his gnio talk so that Steve could talk about our work.
• About GNOME 3 technologies, I have to say that the platform changes seem to be very well on track (thanks to Andre Klapper for keeping track), and GNOME Shell looks really good, even though it seems to still miss some functionality (applets? notifications?), which I’m sure the people working on it will settle down. Not so sure about Zeitgeist. It looks really great, don’t misinterpret me, but after thinking about it for a while, I couldn’t imagine how it would be useful for me, given how I access files. I’m sure it would be quite useful for lots of people, I’m just talking about me, but I think it would make a lot of sense if, instead of a separate application, it were a Nautilus view, just like you have the icon, list and compact views. But well, I’ll try testing it soon and maybe I’ll get convinced.
• I liked a lot the Telepathy tubes stuff for desktop sharing, as well as the libnice talk by Youness Alaoui. These 2 open the door for very nice things to be added to desktops in the not-so-distant future.
• I talked with several people about the contents of the conference, and most people agreed that, for someone that follows GNOME development the whole year, most talks are useless. Not that they are not interesting, because they are, but it would be much more useful if they were replaced with discussion groups that came up with plans for the next development cycles. Talks are still ok for new people getting to the conference, but having BOFs just after the core days, where a big percentage of the attendees are already gone, is, IMO, not a good idea, they should really be part of the core days. UDS (Ubuntu Developer Summit) has this right IMO, where there are only a few keynotes, and then several rooms hosting those discussions for different topics, where people come up with clear plans of what they should be working on. I hope we can do something similar for next year.
• And after complaining about too many talks, I have to say that one of the best things in the conference (along with the GNOME 1, 2, 3 talk by Fernando Herrera and Xan López), at least for me, was the Pitivi tutorial, by Edward Hervey, which showed to the profanes like me how to do nice videos. I hope I’ll be able to follow his teachings and, soon, publish some nice videos of my motorbike and skiing rides as well as my holidays, with good rock&roll as the soundtrack That, along with Mistelix (a DVD authoring tool) might change radically the way my friends and family enjoy my photos and videos.
• Federico was selected as the first GNOME Hispano honorific member in the GNOME Hispano dinner on Thursday. It’s just a honorific title (accompanied by a bottle of local rhum as the prize ), but he really deserves anything we can do to show him our admiration to the best hacker I’ve ever worked with.
• I missed the FreeFA tournament, because playing football at 3PM under the Canarian sun is something my religion forbids But yeah, even with me not playing, Bastien lost again
• Also nice was to have the personal hobbies lightning talks on Tuesday. As I discussed with some people, sexist problems, IMO, might be solved if some people, instead of being all the time in front of a computer, got out once in a while and met some non-geeky people (including women, of course) and share some hobby with them. That might make them understand better how to behave in front of women or people with different cultures. So I hope mega geeky people in the audience used those lightning talks as a starting point to find non-technology hobbies.
• I really missed more KDE<->GNOME cooperation talks. Most of the cross-desktop talks were about things specific to one or the other desktop, not about how both projects could cooperate more. At the end, except in parties, it was hard to find KDE people (at least I only saw the KDE people I know in parties) around, and I guess the KDE people had the same impression. We even had 2 separate parties one day!!! Have to say though that the GNOME one was funnier, as some KDE people that showed up at the GNOME one told me

Last but not least, as always, meeting again all the people I already know and making new friends is the best part of this kind of events. It makes you feel again part of a great community.

And to finish, a big thanks to the people that helped in the organization. They already had a big round of applause at the GNOME Foundation Annual Meeting, but I’ll say it again here: thanks a lot!

How? Very easy, just make sure you set up your gadget to save tracks and have it recording your itineraries whenever you move around the city/island (no need to record your walks around the conference center ). With so many people with gadgets around the city for the week, I think we can improve the current situation (not bad, but lots of room for improvement if you compare it with the Google Maps version).

To save the tracks correctly, make sure to search for your device at http://wiki.openstreetmap.org/, and follow the instructions on how to set it up for good recording of tracks. The most important thing is to setup a good interval (I use every 10 meters or every second, whatever comes first). If you use a very long interval of saving track points, the tracklog would be mostly useless. Also, if you want to do more than just saving tracks, have a look at the map making techniques page. But please, just saving the tracks is enough for helping, so there’s no excuse if you have a gadget with GPS.

And then, when you have the tracks, just send them to me, if you don’t want to bother anymore, or, if you want to bother more, join the project and help editing the map.

This initial version only allows reading and does all operations synchronously (not a problem in most cases, since the communication is done to the local CouchDB instance, which is quite quick, at least from what my tests show so far). Next releases will have all the missing functionality.

And, well, no screenshots to show, so here’s some example code for you to enjoy.

Source code is in GNOME GIT, under couchdb-glib module.

Most of the time hacking on this has been dedicated to the PolicyKit stuff, but now everything should be in place, and, apart from the 2 methods I added (RunAsRoot to replace gnomesu/gksu/kdesu, and AddUser as an example of how to use YaST’s command line interface for the operations), more methods (users management, firewall, samba shares, etc) can be easily added. With this and the GUI from gnome-system-tools, I think we can start providing a distro-independent (and acceptable to all of them) set of administration tools for GNOME (and KDE, if they adopt AdminKit), or just add the needed admin functionality to already existing applications. From now on, here are my ideas:

• Move PolicyKit mechanisms already existing in some GNOME modules (gnome-panel’s SetTime and SetTimezone, for instance) to AdminKit, provided people agree on adopting it
• See system-tools-backends and reuse as much knowledge/code as possible
• See at changing gnome-system-tools’ GUI to use AdminKit (once the functionality needed is moved to AdminKit)
• Add more admin operations, as needed. For openSUSE, we have quite a lot of functionality via yast’s command line interface, and other distros have similar stuff, so anything we need can be added AFAIK.

Get the code with:

git clone http://www.gnome.org/~rodrigo/git/osc-plugins.git

(cd AdminKit, the other top-level dirs contain unrelated projects)

And, soon, packages at my home build service repository.

First, you need to create a branch from the package you want to change:

osc branch GNOME:Factory gnome-utils

This creates a branch in your home project (home:$user:branches:GNOME:Factory), so just check it out:

osc co home:$user:branches:GNOME:Factory gnome-utils

Then, just work on changes, and when everything is ok and the package builds, just commit and submit a request

osc commit -m “Changed foo and bar”

osc submitreq create -m “Changed foo and bar”

Before submitting though, it might be wise to re-check your changes:

osc rdiff home:$user:branches:GNOME:Factory gnome-utils

which shows a diff of the changes in your branch.

osc commit/submitreq create will submit the changes to your branch and to the project you branched from (GNOME:Factory in this example), so that maintainers can review and accept (or reject) the submission. Maintainers just need to:

$ osc submitreq list GNOME:Factory

359 new home:rodrigomoya:branches:GNOME:Factory/gtk2-engines -> GNOME:Factory/gtk2-engines ‘——————————————————————-\nFri Jul 18 17:16:38 CEST 2008 – rodrigo@suse.de\n\n- Tag and upstream patches’

360 new home:vuntz:branches:GNOME:Factory/pango -> GNOME:Factory/pango ‘Tag pango64.patch’

363 new home:jproseve:branches:GNOME:Factory/glib2-branding-openSUSE -> GNOME:Factory/glib2-branding-openSUSE ‘Fix bnc#406741′

364 new home:rodrigomoya:branches:GNOME:Factory/fast-user-switch-applet -> GNOME:Factory/fast-user-switch-applet ‘Tag patch correctly’

365 new home:rodrigomoya:branches:GNOME:Factory/gnome-utils -> GNOME:Factory/gnome-utils ‘Tag some patches’

366 new home:jproseve:branches:GNOME:Factory/scrollkeeper -> GNOME:Factory/scrollkeeper ‘Tag patches’

367 new home:jproseve:branches:GNOME:Factory/icu -> GNOME:Factory/icu ‘Tag patches’

368 new home:jproseve:branches:GNOME:Factory/scrollkeeper -> GNOME:Factory/scrollkeeper ‘Tag patches’

which lists all the submissions waiting in the queue, and then just needs to review it:

$ osc submitreq show -d $id

which shows the patch for the submission identified by $id. And then, just accept or reject:

osc submitreq accept $id

osc submitreq decline -m “Your patch is wrong, don’t send me more” $id

Neat, isn’t it? This should help us a lot in getting users’ contributions quicker into the distro, as well as in a better patch reviewing system.

Summary is: don’t help Google making their maps, help OpenSteetMap instead!