Advogato blog for federico

Thu 2008/Oct/02

Thu, 2 Oct 2008 19:04:45 GMT

Mortadelo 0.3 is released

I've just released Mortadelo 0.3, the graphical, systemwide version of strace. You can use Mortadelo to examine the system calls from all your processes.

Source tarball: mortadelo-0.3.tar.gz

Git repository: git clone git://gitorious.org/mortadelo/mainline.git mortadelo

openSUSE 11.0 one-click install:

Tue 2008/Sep/23

Tue, 23 Sep 2008 19:06:56 GMT

The Git user's survey 2008 is up! Be sure to participate to make Git better. I found question 27 very interesting, with a bunch of commands that I never knew about but that could be very useful to me.
Everyone who has a laptop: GNOME is now wired to support the hotkey which laptops have to toggle the internal/external display output (Fn-F7 on Thinkpads, for instance). X exposes this as the XF86Display keysym. However, not all laptops expose that key in the same fashion. For some of them to work, one needs to add entries to HAL's description files, or do some ACPI magic.

We are building a list of laptops to see how they expose the "toggle displays" and "rotate the screen" hotkeys (for tablets). If you have a laptop, please add it to the list so that we can add support for it. Thanks!

Tue 2008/Sep/16

Tue, 16 Sep 2008 21:09:53 GMT

Usability of planets

We have another flamewar about inappropriate posts on Planet GNOME.

Why does this keep happening? Let's take a user-centered view. Say you are a reader of a planet aggregator. Your question is, how do I get rid of the posts by Annoying Person?

Now, let's compare two planets: Planet GNOME and Planet SUSE.

Planet GNOME Planet SUSE

In Planet GNOME, you must scroll to the bottom of the (very long) page, click on the "Feeds" line to expand it, and then you will find checkboxes for each of the feeds. You can then find Annoying Person there and uncheck him.

Step 1: wait for PGO to load. Step 2: scroll to the bottom. Step 3: find the "Feeds" line. Step 4: click on "Feeds". Step 5: find Annoying Person. Step 6: uncheck his checkbox.

That's six steps just to get rid of stupid posts.

In Planet SUSE, each post has an "X" icon. If you click it, the icon turns into a checkmark, and all of that person's entries will be hidden the next time you load the planet.

Step 1: Find the "X" icon next to Annoying Person's post. Step 2: Click the icon.

It is clear that Planet SUSE is much more usable than Planet GNOME in terms of "how do I hide the posts by Annoying Person". You don't have to know that to hide someone, you must scroll to the bottom of the page, find a magic little expander, etc. You just click on the "go away" icon which is right there by the annoying post, and you are done.

Mon 2008/Sep/08

Mon, 8 Sep 2008 21:06:14 GMT

Today's harvest, green beans

This is about 240 grams of green beans that we grew out of eight plants, on more or less 40x40 cm of soil. The plants should yield about three times that amount, once the younger beans and flowers mature.

I don't know if that kind of yield is low or high, but it definitely feels good to get something edible out of a little patch in the sidewalk. No fertilizers or anything, just soil from our little compost heap. This is the sidewalk in question; the beans are the ones with the large leaves. There is also epazote (anti-flatulent aromatic herb for cooking beans), garlic, mint, a couple of watermelon seedlings, rosemary, petunias, roses, rue, and a couple of plants whose names we don't know.

Our gardening book is How to grow more vegetables, by John Jeavons (acutally, a slightly newer edition than the one presented there).

Tue 2008/Aug/26

Tue, 26 Aug 2008 18:08:36 GMT

Predefined desktop items for Nautilus

Back in the Summer of Code 2007, Sayamindu Dasgupta worked on adding support for predefined desktop items to Nautilus. This is so that system administrators can set up desktop links that will appear on users' desktops. A university could set up an icon to take people to the university's intranet, for example.

Basically, I'm reviving Sayamindu's patch and bringing it up to date for the current Nautilus. The idea is that you set up a GConf key, /apps/nautilus/desktop/predefined_items_dir, and point it to a directory which holds .desktop files. This kind of indirection through a GConf key is what makes the scheme work nicely for deployments with Sabayon: sysadmins can have predefined items for various groups of users, and select among those by simply changing a mandatory GConf key for each user. This wouldn't be so easy if there were a hardcoded directory like /var/nautilus/global-desktop-items.

Sysadmins should be able to define mandatory items, which users cannot change or delete, and also "normal" items, which users can tweak or remove. Mandatory ones would be ones like "Company Intranet" or "Link to Helpdesk". Distros could use normal items for their marketing materials; the perenially hacky "Welcome to FooLinux" icons that currently are hard to do properly.

The problem I'm having is how to make non-mandatory items work. You want this behavior:
1. The sysadmin defines a non-mandatory item.
2. The user sees the item in his desktop. He doesn't want it anymore, so he deletes it. Where do we mark this deletion?
3. The user decides that he wants the item back after all. How does he restore it?
4. The sysadmin updates the non-mandatory item and he wants it to show up again in people's desktops. How can this override what the user had done?
I'm leaning toward having two extra boolean values in .desktop files: an X-GNOME-Mandatory and X-GNOME-Deleted. If the "mandatory" value is false, then the user may change or delete the item. For changes, the item is copied from the predefined_items_dir to the user's ~/Desktop and that version is modified. For deletions, the item is copied there as well, but then the "deleted" flag gets turned on.

If the user wants an item back, he turns on "show hidden files" and those files get shown again. (Or we could hack the Trash to restore the item by turning off the "deleted" flag...)

If the sysadmin updates an item in the predefined_items_dir, this item will override items of the same name in users' desktops, based on the item's timestamp.

Does this make sense? Am I overlooking something?

Thu 2008/Aug/21

Thu, 21 Aug 2008 17:04:56 GMT

People who use git-mirror.gnome.org may have noticed that SVN tags don't get fetched automatically when they get their daily fix of updates with "git fetch" or "git pull" (that is, you run "git tag" and it doesn't list new tags that appeared since you did your original clone). Within your repository, take a look at .git/config:
```
[remote "origin"]
	url = git://git-mirror.gnome.org/git/gtk+
	fetch = +refs/heads/*:refs/remotes/origin/*
	fetch = +refs/tags/*:refs/tags/*      ### <---- Add this line!
```
The first "fetch" line is already in your .git/config and it means, "every time I fetch from the origin, get all the branch heads in the origin's refs/heads and stuff them in the refs/remotes/origin namespace" (i.e. update all the branch heads).

The second "fetch" line is what you need to add. It means, "every time I fetch from the origin, also get all the tags and stuff them in my own namespace".

After that, just do "git fetch origin" and all the tags will be downloaded to your repository.
Mike Wolf has been working madly on rpm2git to make it easier to use. He has made some very cool changes:

Rpm2git no longer requires you to have an environment suitable for rpmbuild (e.g. specfiles in /usr/src/packages/SPECS, patches in /usr/src/packages/SOURCES). If you have a single directory with a specfile and patches, you can simply run rpm2git on that.

You don't need to have all the BuildRequires from the specfile, either.

Perhaps most importantly, you don't need to mess with your $PATH anymore nor install helper scripts. Rpm2git now works out of the box after "make install".

All of these changes are now merged in the rpm2git repository.

Thu 2008/Aug/14

Thu, 14 Aug 2008 20:04:44 GMT

Sometimes Oralia boils water in the kettle, and adds a stick of cinnamon to make an infusion. The other day I heard the kettle boiling and I thought, "time for some green tea!". I didn't notice that the water was actually cinnamon, and made my tea as usual.

Well, hot damn, green tea made with cinnamon water turned out to be *good stuff*. I think I could grow an addiction to this.
Labels for RANDR monitors

When you configure multiple monitors, it is useful to know which physical monitor corresponds to each element in the configuration GUI. Both KDE and MacOS display cute labels on each monitor.

I implemented pretty much the same thing for GNOME, with the addition of color-coding. Hello, sexy:

This is in the following Git repositories (look at the monitor-labeling branches in all of them, and also tray-icon-rotation for gnome-settings-daemon):
This is just awaiting approval from the the release team to be committed to SVN :)

Tue 2008/Aug/12

Tue, 12 Aug 2008 21:05:06 GMT

Why I want to have the children of git rebase --interactive

Sometimes you are hacking madly and committing often. Your commit log looks like this:

* Add some fields for a popup menu * Create the popup menu * Refactor the base object to accomodate the menu's commands * Implement the signal handlers for the menu's commands

Then you type make and of course your code doesn't compile. So you do one-liner commits, one for each build error:

* Add missing include gtkmenu.h * Fix typo in popup_menu variable name * Forgot to declare a menu_item variable * Add missing argument for gtk_menu_popup function

But you don't want you submit all of those patches upstream! You only want to send perfect patches which are either additions or refactorings to the upstream code. You don't want the maintainer to know that you are a fallible human being who forgets include files and variable declarations; instead, you want him to believe that you are a coding god who sends a perfect series of patches every time.

git rebase --interactive allows you to pretend you are better than you really are. This is a good thing.

We have 8 commits in total (4 "good" ones that don't compile, and 4 "embarrassing" ones that are little fixes). So, run git rebase --interactive HEAD~8. This means, "let me fix any fuckups since 8 commits ago".

Git will drop you in an editor where you edit this:
```
pick ab365cf Add some fields for a popup menu
pick 2478bac Create the popup menu
pick 9180ffe Refactor the base object to accomodate the menu's commands
pick a6c2467 Implement the signal handlers for the menu's commands
pick 289cf1a Add missing include gtkmenu.h
pick 378ac2b Fix typo in popup_menu variable name
pick 821ac6f Forgot to declare a menu_item variable
pick 24acf67 Add missing argument for gtk_menu_popup function

# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
```
Now let's reorder the lines there, and replace some pick commands by squash. I've put in some comments about what each moved line does.
```
pick ab365cf Add some fields for a popup menu
squash 289cf1a Add missing include gtkmenu.h
# Oops, forgot to "#include <gtk/gtkmenu.h>" to have a field declared "GtkMenu *popup_menu"
	      
pick 2478bac Create the popup menu
squash 821ac6f Forgot to declare a menu_item variable
# Oops, while creating the menu items I forgot to declare my menu_item variable

squash 24acf67 Add missing argument for gtk_menu_popup function
# Oops, while creating the menu I also missed an argument to this function (how couldn't anyone?)

pick 9180ffe Refactor the base object to accomodate the menu's commands

pick a6c2467 Implement the signal handlers for the menu's commands
squash 378ac2b Fix typo in popup_menu variable name
# ... and I also mistyped popup_menu in a signal handler
```
When you are done, save that temporary file and exit your editor. Git will rewrite your commit history so that you have a clean log, with no commits like "fix this little thing". When you send that patch series to the maintainer, he'll have an easier time reading your code, and he'll be amazed at your meticulousness.

The important thing here is to do one commit per compilation error. Then it's very easy to reorder your commits, where you squash each fix with the corresponding "real" commit.

Fri 2008/Aug/08

Fri, 8 Aug 2008 16:08:37 GMT

Two-stone handicap for me on a 9x9 go board, and the birthdayful HPJ still manages to kick my ass by twenty-something points.

They must have put something in the cake, as I had two big slices while HPJ had a single tiny one.

Thu 2008/Aug/07

Thu, 7 Aug 2008 15:07:08 GMT

How to use rpm2git

Here is a second screencast on rpm2git (Ogg Theora, 69 MB). This one tells you how to use rpm2git to take the patches from a SRPM and put them in a Git branch.
During GUADEC in Stuttgart and in Dublin, Evangelia Berdou was interviewing people about how they contribute in GNOME. She used this information for her dissertation, Managing the Bazaar: Commercialization and peripheral participation in mature, community-led Free/Open source software projects. Over 100 people from the GNOME Foundation contributed to her study!

There is very valuable information in this work: how many core-platform hackers, core-desktop hackers, secondary-desktop hackers, translators, and peripheral contributors do we have? Which of them are employed to work only on GNOME, on GNOME and other free software, or are not paid for their contributions? How do people move from being peripheral contributors to core ones?

For people thinking about which sub-group of GNOME needs better tools (translators!) and support from GNOME at large, this is exactly what they need to read.