Mango gone live

The new system to request accounts (Mango) has gone live. Updated instructions for people wanting an SVN account are at: The maintainers listed in the various MAINTAINERS files have received instructions on how the system works. This email also contains information regarding another (intended for foundation members) GNOME service you’ll have access to. Suggest to read the email asap.

Note: I haven’t added the translator coordinators yet.


Last 2 weeks I had loads of time to hack on Mango. I will have much less time from now on. There are still a few things I want implemented (by me, Baris, someone else):

  • Move Foundation member information into LDAP
    This is a huge amount of work. Need to rewrite the Mango parts, enhance the LDAP schema (probably new schema + conversion), port all scripts currently using the database, need somehow to setup users (e.g., might not have an LDAP account atm), etc.
  • Allow people to either change their Mango password, or request a new one
    Not hard, mostly worried about security.
  • Allow maintainers to change for their modules who the maintainers are
  • Allow people to change their LDAP details (SSH keys, email address)
    Security regarding SSH keys is ehr.. difficult.
  • Allow existing LDAP users to request additional permissions for their account (e.g., ability to upload modules, or the alias)
  • Export the maintainer data (only module name, username) as XML

For general discussion, please use the gnome-infrastructure mailing list. If you find bugs, please file them in GNOME Bugzilla, Infrastructure, sysadmin, mango.

Sneak preview of Mango

Mango will soon be the new way to request GNOME accounts (usually SVN). Mango was first written by Ross Golder, then enhanced by Baris Cicek during Summer of Code 2007 to handle requesting accounts. After that I also changed a few things. Here is a sneak preview of how it’ll handle requesting accounts. It is a sneak preview as there is some small amount of work left.

This is what the website will look like:

If a user wants a new account, the following form needs to be filled in:

After sending in the form, the email address has to be verified:

The user now has to follow the link in Evolution:

Verifying the email address results in the following page:

The maintainers will be emailed:

After logging in, the maintainers have the ability to reject/approve the account:

The requester gets an update on the status:

At the same time, the Accounts Team is requested to create the user:

The Accounts Team can see all accounts that are ready to be setup:

The new user form loads all details from the requested account:

Finally, the user gets an email regarding the new GNOME account:

Reasons not to blog

Saw a mention of a blog with the following in it:

Remember what today might be a funny and smart post, it can be tomorrow’s reason for an employer to not consider your application […]

I avoid blogging about certain things, but that is my decision. Regarding not blogging because of possibly someone at one certain point getting a wrong impression, I agree with xkcd:


Note that I’m not going into any of the rest of that blog. Just this one reason. If that reason was stated as ‘It shows that you’ (etc), I wouldn’t have a problem with it. Regarding that someone should act different because of possible future jobs: don’t pretend you are someone else.

Dropping those old crasher reports

Diego Escalante Urrelo proposed to drop <= GNOME 2.16 crash reports on desktop-devel-list. The reasoning (as discussed on bugsquad-list) is:

  1. They are really old and most of them are answered “well yes, try SVN/last-release it [might be] fixed there”, or simply ignored. They only make bugzilla noisy, hence making difficult to find useful reports.
  2. It is unlikely any new crasher will occur. As we’ve been triaging these crashers for over a year, the chance of a new 2.16-specific crasher is not worth the amount of time it takes to triage the dupes.

There hasn’t been much response on above proposal. I plan to implement above as per 30 September, this year.

Clarification: As some people are misunderstanding: This is not about closing existing bugreports with a ‘please upgrade’ (this is up to the individual developers of each product). This is about not accepting new incoming crash bugreports coming from GNOME 2.16 or earlier. This as the chance of getting an actual new crasher (instead of a dupe) is highly unlikely. This coming from the people (not me) who look at the thousands of new crash bugreports arriving each week.

Creating your own SVN repository

It is now possible to create your own GNOME SVN repository for everyone having a GNOME SVN account.

The full instructions are at:

But, they are short enough to repeat:

  1. If you need to import the history of some existing repository (SVN or something else), you still need to mail with a link to the dump and your GNOME SVN username.
  2. However:

  3. If you just want an empty SVN repos, execute the following:
      ssh $ new-svn-repos $REPOS

$REPOS should be all lowercase chars, optionally some ‘-‘ thrown in there as well.

Data parsed from MAINTAINERS files

Probably only interesting if you are (or should be) listed in a MAINTAINERS file

In a few days (perhaps more…), people in /trunk/MAINTAINERS will receive new instructions on how to approve SVN account requests (via a system called Mango). These emails will go to everyones email address listed in LDAP. Obviously, that LDAP email address needs to correct. Also, the information in /trunk/MAINTAINERS should have been parsed correctly. I’ve emailed everyone who had a mismatch between the MAINTAINERS email address and LDAP. However, I already noticed for some people their LDAP email address as well as the one in /trunk/MAINTAINERS bounce (oops).

To see the data parsed from the MAINTAINERS files, click here. This file is sorted by account name. It has two lists. One shows possible invalid data. The second list contains all maintainers found from the various MAINTAINERS files.

If you want to ensure there are no mistakes, please check the file and look for your userid. It shows your email address (spam protected) and the modules you are a maintainer of. If you are not listed at all or if some module is missing, please check the /trunk/MAINTAINERS file for typo’s. See lgo/MaintainersCorner if you are interested in the syntax.

Update: If the information between LDAP and the MAINTAINERS file differs on purpose, you can of course ignore the mail you received from Mango.

Shooting yourself in the foot

Last weekend, I replaced a few parts in my pc. This meant I needed to upgrade my distro from ‘i586’ to x86_64. However, this is unfortunately not supported by the distro (RC1 gives weird error messages, the development one tells me it is not supported). The obvious solution is to do it manually.

RPM thought otherwise. It doesn’t let you install x86_64 packages because either it looks at the kernel, or the i586 rpm didn’t allow it. So I used ‘mc’ to install a x86_64 kernel (easier than extracting with cpio). Rebooted, and with the x86_64 kernel (nothing else upgraded), rpm still wouldn’t let me install x86_64 packages. In order to get around that, I manually installed the x86_64 rpm package and all it dependencies (note, this means that if you repeat this, your rpm will NOT work for a while). RPM has too many dependencies 🙁

After installing RPM, I noticed it had a few issues. Namely, it crashed when installing packages. This was due to the /var/lib/rpm files being architecture dependent. I first made a backup of that directory, then used a i586 db_dump (db42-utils) to make a dump of every file. Installed (cpio method) x86_64 db42-utils and restored the files from the dumps. After this RPM sort of worked (sometimes screwed up the rpm database, requiring a rm -f /var/lib/rpm__*). The corruption was solved eventually, but I don’t know how/why.

I then made a script to check for every installed i586 RPM, and upgrade to the x86_64 one (rpm -Uvh). The script knows to change ‘libfoo’ to ‘lib64foo’. It also tried to remove i586 packages if the x86_64 one was already installed (-Uvh didn’t always remove the i586 package.. and of course never for libs). I used a local mirror of a large part of the x86_64 distro for this (15GB or so). Strangely, RPM didn’t really complain about dependency issues (I only ignored them max 3 times, to solve specific problems). Probably the dependencies don’t check the architecture. I had to use –replacefiles more often. The –replacefiles was always due to the i586 libs having the same files as the x86_64 ones (causing conflicts). This didn’t occur too often, I think Mandriva tries to avoid these messages somehow.

Every so often, I used ‘urpmi’ to have it install a few deps. That (perl) command strangely always worked. Even with the mix of i586 and x86_64 packages (I had some perl stuff as i586, some as x86_64.. it still worked).

To check the progress (how many packages still as i586), I used: rpm -qa –queryformat ‘%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n’. In the output, I was only interested in the i586 packages not starting with lib. The amount of those packages started dropping very fast. In the end I looked at ~60 or so packages manually. Some I just removed if I couldn’t find a x86_64 version.

Of course, some stuff broke. E.g., postfix has a deamon_directory in its config file which was correctly updated to the lib64 one. However, pcre in still pointed to the i586 lib. There was another similar problem (something in /etc/alternatives still pointed to /usr/lib). In total, I have 10 i586 packages left (some packages I made for myself that should actually be noarch, plus things like wine, java plugin, …). This not counting the libs (I did remove the i586 -devel stuff at one point). For something not supported by the distro (Frederic Crozat commented “best way to shoot yourself in the foot”), I expected much worse.

New IP addresses for GNOME Subversion and L10N machines

Just copy/pasting an announcement by Ross Golder:

Due to reasons beyond our control, we will shortly be changing the IP addresses for the GNOME subversion and L10N machines. I currently expect we will be doing this at some point on Sunday 16th September 2007. The old IP address should continue to work until 22nd September, by which time the DNS change should have fully propogated.

This change will largely be transparent except for developers using Subversion/SSH, for whom this change will likely cause your subversion client to give an warning. This warning is just to highlight the fact that the IP address has changed and can be ignored.

The new IP address for the subversion server will be, and the server’s host key fingerprint is as before:


Apologies for any inconveniences. Please post any questions, comments or follow-ups regarding the change to

Note: Initially, the IP alias for l10n wasn’t working. It is now. Further, the change in this announcement already happened.

So I like usability — it that so bad?

As zeenix wrote:

OTOH, The discussion went very well until the biggest opponent of git, Olav Vitters admitted that “It translates to: I really care about not needing to learn an SCM.”. From that point onwards, I completely lost the interest in the discussion.

Admitted? I made myself perfectly clear from the start. I like something that guides/helps me. I also really care about the advantages it brings for devs (who could use a better system)/translators/.. and I like people to investigate and list them in a wiki, exactly because I am not the right person to investigate that. This was in one of the first emails I wrote. I also posted this again in a followup email to avoid any confusion on that part. You are misstating what I said by leaving that out. Further, I do not oppose Git, I want each choice to be investigated.

I don’t appreciate that you implicitly state that the discussion was ok except for my part of it. If you have an issue with me, Planet GNOME is not the place.

How to report inappropriate content on GNOME Bugzilla

If you see inappropriate content on GNOME Bugzilla, please report this to or report in the #bugs channel on (use e.g. xchat). This for stuff like accidental information appearing in bug-buddy reports, spam, bad behavior, etc.

Note that above step does not include things like Digg, Planet GNOME, mailing lists, etc.