Category: General

Hours after upgrading moinmoin, they released 1.6.1. This is a very minor upgrade. Took about 5 minutes in total to upgrade the site, including writing instructions for the next sysadmin.

I’ve noticed a few more issues:

• There are a around 170 very outdated translated pages. So if you use live.gnome.org in some language other than English the instructions might not work on 1.6.x. The cause seems to be that the upgrade instructions weren’t followed in the past.
• Linking to a bug using [[gnomebug:163163]] doesn’t work. Not sure why and #moin is silent.

I’ve upgraded MoinMoin to 1.6.0 today. MoinMoin is the software behind live.gnome.org, www.gnome-db.org and www.pango.org. The upgrade took a bit longer than expected due to:

• A bug in 1.5.8 to 1.6.0 migration script. It tried to read the whole event-log file into memory. As that file was 2.2GB for live.gnome.org the server ran out of memory, causing the script to fail. Fortunately #moin was quick to provide assistance.. I assumed some memory leak.
• Another bug which is triggered if language_ignore_browser is enabled. It prevents any page from loading. I fixed this myself. Later on I learned that this was already fixed upstream. I initially suspected our custom themes to be the cause, so didn’t ask right away on IRC.

New stuff:

• Suggest to take a look at http://moinmo.in/MoinMoinRelease1.6. I was interested in the sysadmin related changes.
• There are a few changes when making links. Basically: use <<BR>> for macro’s such as BR and [[URL]] for links. Images should use: {{attachment:filename.png}}. The upgrade script converted all existing pages to the new format.
• Hierarchical ACLs. This should ensure pages will not unintentially do not have an acl. Note: This currently is NOT enabled!
• Inline comments. Don’t really see the point, but perhaps someone likes it
• Discussion pages. I think this requires some configuration first.
• A trick to prevent spiders from causing too much server load. Plus ability to generate a sitemap.
• Something to easier allow static files to have a long Expires header. I still have to do configure the server for this.
• Xapian for search. Not enabled.

Fixed issue:

• GNOME theme uses the moinmoin icons instead of the GNOME ones. Not exactly sure why they aren’t used. Update: Fixed!

Oh, and it has been ~2 months since I prevented some annoying spammer from attacking our wiki sites. I only saw one spam attack since then, this was done manually by the spammer.

Want to help GNOME? Please port a module to GIO! See http://live.gnome.org/GioPort for instructions. I’d really appreciate a patch for librsvg (or any other not-yet ported module). Nautilus uses GIO. However, it still links against gnome-vfs and (one of?) the reason(s) is librsvg. Perhaps that is caused by other things as well. If so, please provide patches for those modules as well.
Note: Please keep the wiki page up to date. Just create an account and you will be able to edit it. Some modules might have been ported by the maintainer already (without the page being updated). If so, please update the wiki page as well.

The conversion of the CVS archive is complete. All the archives CVS modules are now available at http://svn-archive.gnome.org/viewvc/. I’ve killed anoncvs.

The cvs.gnome.org site was still running. It is has been a year since the migration to SVN and the site is not maintained anymore. However, it still contained the CVS archive. Before killing the site I wanted to move the CVS archive into SVN. That is happening at the moment. You can follow the progress at http://svn.gnome.org/migration/status-recent.xml. I’ve already made the CVS website redirect to svn.gnome.org.

Another thing I want to kill anoncvs. It has been a year and I don’t like to run services that aren’t looked at. Unfortunately I cannot kill CVS completely as there are still some external users (cvs.rpm.org.. although it seems they switched to hg).

I’ve looked at other infrastructure tasks I still want to complete, but there isn’t anything I want to do atm. After 2.22 I plan to upgrade the svn.gnome.org machine to the latest Ubuntu LTS (has a newer SVN). The LTS will only be out after 2.22, and doing such a change just before a stable release wouldn’t be good for development.

I wrote a long email to desktop-devel-list and gnome-infrastructure about doap files. I’d like to require these files and drop the /trunk/MAINTAINERS file requirement.

Excerpt from the mail:

Currently project information is spread thoughout various systems. The maintainers are available in MAINTAINERS files, developers in AUTHORS, the description is possibly in either Bugzilla or some README file, etc. I’d like to make use of DOAP files for this.

See for example the usage of DOAP on projects.apache.org:

• http://svn.apache.org/repos/asf/ant/core/trunk/doap_Ant.rdf
• http://projects.apache.org/projects/ant.html

Examples of what is in a DOAP file:

• maintainers
• long description
• releases
• homepage / download link
• bugtracker link ()
• repository info (SVN + viewvc)

And others:

• short description
• mailing lists
• various kinds of contributors
• programming language
• category
• etc

Please read the email as I don’t want to repeat the whole thing. Comments welcome (preferrably on d-d-l).

Noticed a few interesting things today:

1. GNOME hackers ask things that are answered by the (very short) IRC topic
2. Someone asked if the GTK 1.2 (1.2.0 was released on 27-Feb-1999) documentation could be put on a site somewhere again, as it is ‘extremely handy’
3. Some spammer asked if his post could be removed from the archives at mail.gnome.org

Oh, and my addition of sftp to the releng convert-to-tarballs script wasn’t useless. It finally noticed a tarball before it was on the main mirror, ftp.gnome.org. This to ensure any release team member (with a properly configured setup) won’t be affected by any mirror lag. The script will try to d/l any tarball for up to 2 minutes with an appropriate waiting time in between (might need to increase the total number of tries though). It’ll also use resume (so in case of a partial d/l, it doesn’t d/l the whole file again, except if it is corrupt)

I’ve switched from the custom commit-email.pl script to the mailer.py from Subversion 1.4.6. Apart from one issue (svn.core.svn_path_canonicalize), it seems to work fine with Subversion 1.3.1. This time when I submitted the patches they actually appeared on upstream dev mailing list as well.

Anyway, as of now you’ll see the diffs of a commit right in the email as suggested by Gabriel Burt. It doesn’t diff .po files, nor deletions or binary files. A custom reply-to header can be set. Just email me if you want one (or svnmaster@gnome.org). The reply-to can be set per repository and it needs to be the development mailing list of the repository. By default the reply-to is empty (so you’ll mail the committer). Perhaps it should default to desktop-devel-list instead.

The LDAP replication was broken between the master LDAP server and svn.gnome.org. This meant that new accounts didn’t work, nor any SSH key changes. This has been fixed by Ross Golder. So if you had any problems, please try again. If you still have problems, email accounts@gnome.org.

Patrick Fey
We have a new hacker working on Mango, he now has an SVN account.

Non-working email addresses
Note that people with non-working email addresses will have their SVN permissions disabled if the new email address cannot be found / verified. Of course, as soon as the new email address is known, SVN will be reinstated. Mail accounts@gnome.org if that happens to you. We don’t check email addresses actively btw, so this will generally only occur for people who can approve accounts in Mango (because of a bounce of the Mango explanation email).

Translator accounts
Mango now has a drop down list with translation teams. This wasn’t added before as adding this involved more than just showing a list of languages.

The Bugzilla version on GNOME Bugzilla does table locking, which makes Bugzilla appear to hang for long periods. There are a few solutions to that:

1. Port GNOME Bugzilla to latest CVS version (mostly uses InnoDB and transactions)
2. Setup a ‘shadow’ database (master/slave replication)
3. Optimizing the queries
4. Killing the long running queries

The fastest way was option #4. See viewvc for the patch. It needs Sys::SigAction and works basically like the example code in that module. This means that queries running longer than 60 seconds will be killed (the buglist.cgi ones).