Yet another fixed VM uploaded

Though the last version of the 2012-10-15 VM fixed the .ovf to remove an accidentally-included extra disk, this time an incorrect version of a different disk was added. This has been corrected and the finished product tested a bit, so hopefully this time we won’t need another followup blog post!

This time it’s MusicBrainz 2012-10-15.ova, in the usual places.

Update on postgresql 8.4 issues and missing functions in upgrade

We’ve been seeing a number of issues with the upgrade scripts for this release reported here on the blog, in IRC, as well as the ticket tracker. We’ve got a couple bits of news for those upgrading from codebases older than mid-August and those using versions of PostgreSQL older than 9.0:

  1. MBS-5473: This is the ERROR: function controlled_for_whitespace(character varying) does not exist migration problem. Slaves with imports done before mid-August are missing a few stored procedures that are necessary for the upgrade. This has been fixed in the master branch as of commit 082e608c074641e2e8df2c0809d35421b02c7899 — to run the upgrade, run git fetch origin, then git checkout 082e608c074641e2e8df2c0809d35421b02c7899, then continue with step #6 of the original instructions. If you already started the upgrade but failed on the ‘merge-duplicate-credits’ script (as is likely, with this bug), don’t worry: at that point in the upgrade, restarting is not an issue.
  2. MBS-5475: This is the ERROR: syntax error at or near “ORDER” migration problem. Unfortunately, this one’s more serious: on PostgreSQL 8.4, our upgrade scripts don’t work, as one uses a feature introduced in 9.0 (as previously mentioned) After some hours of investigation, it appears that this issue can’t be resolved reasonably; therefore, for 8.4 users the upgrade path is a data re-import using a recent (post-schema-change) codebase and a data dump from October 17th or later. We’d also recommend updating to PostgreSQL 9.x at the same time if that is possible.

Sorry again for the inconvenience.

Wiki updated!

As we mentioned yesterday, the wiki was read-only for a period today as we performed some much-needed upgrades. The new wiki is now live on and testing is encouraged to make sure we didn’t miss anything! It isn’t available as of this writing because a DNS change is required, but the old wiki will remain available at for some period of time, in a read-only state.

The new wiki has a few changes:

  1. You’ll see that the style has changed; instead of maintaining our own complete MediaWiki skin, we’re now just doing some modifications on top of the provided monobook skin.
  2. Login is now required to edit pages, partly as a spam-mitigation measure and partly because people were often editing without logging in, which made it hard to track down who exactly changed a page.
  3. The MediaWiki API should now be accessible, from
  4. Finally, A few extensions have shuffled around and been updated as well; the full details are available on

If you find mistakes in our setup, please contact me: ‘ianmcorvidae’ on the MusicBrainz site and on IRC, and via email; or, file a ticket on (under MusicBrainz Hosting, assign to “Ian McEwen”).

Wiki read-only period tomorrow, September 7

Our wiki’s been needing an upgrade for some time, and we’re ready to make the switchover. However, as you may imagine, upgrading from MediaWiki 1.11.2 to 1.19.2 isn’t a trifling matter (though kudos to the MediaWiki team for it even being possible in one step!), so we’ll need a few hours to run upgrade scripts and migrate servers (though we’ve worked to make it as quick as possible). The wiki will be available during this time, but will be read-only until the switchover is complete.

The read-only window for the upgrade will start at 15:30 PDT/MST, or 22:30 UTC. The wiki will be back, shiny and new, sometime 1.5-3 hours later, presuming everything goes according to plan.

Thanks for your understanding, and hopefully you’ll agree the new wiki is much improved!

Looking for Language Liaisons

As some of you may know, this summer through Google Summer of Code I’m working on internationalization of musicbrainz-server. As outlined in my proposal, I’m currently looking to find what I call “language liaisons”: folks willing to be the go-to person about a given language for me and other developers.

Auf deutsch!
Auf Deutsch!

What’s expected of liaisons:

  1. Willing to be pestered occasionally, by me or other developers, about language-specific concerns: when adding new features, and thus adding new strings, we’d like to be able to ensure nothing’s added that will need to be changed before it can be translated into a given language.
  2. Willing to file bugs for strings already in the database that are untranslatable, should you find them.
  3. Be on the musicbrainz-i18n mailing list; this will be the main venue for organization and communication about i18n issues.
  4. Ideally, to be an active translator for your language – but this isn’t a requirement, because I’d like to get the widest global coverage I can; even if a language doesn’t currently have a translation, we don’t want to unintentionally sabotage future translators with untranslatable strings!

I’ll also be determining a (related) list of “target languages” for the summer, with the intention of releasing translation on with these languages at the end of the summer. I’ll consider for inclusion on this list languages that are both in active translation on Transifex and have language liaisons.

If you’re interested in being a language liaison, please contact me: ianmcorvidae (at) musicbrainz (dot) org, editor ianmcorvidae, or ianmcorvidae on IRC, and join the mailing list.

If you’re interested in i18n generally,  please join the musicbrainz-i18n list. For more information on my project and musicbrainz-server i18n, see the server internationalization wiki pagemy post on my personal blog, and my official proposal, or come ask about it on IRC or the mailing list!

(less useful languages)
(less useful languages)