Hi,
can anyone help Roland with that? (If we can get ff-p-mw working
and mediawiki-math back, I’d fully support getting a current MW,
1.19 probably, into wheezy before the freeze.)
Thanks,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
---------- Forwarded message ----------
From: Roland Mas <lolando(a)debian.org>
Message-ID: <871umdcsh5.fsf(a)polymir.internal.placard.fr.eu.org>
To: Thorsten Glaser <tg(a)mirbsd.de>
Cc: 673125(a)bugs.debian.org
Date: Mon, 21 May 2012 20:13:42 +0200
Subject: Re: Bug#673125: ff-p-mw: handle mediawiki upgrades
Thorsten Glaser, 2012-05-16 13:00:21 +0200 :
> Package: fusionforge-plugin-mediawiki
>
> As discussed already (this bug is mostly for tracking things in
> Debbugs), fusionforge must handle upgrades in mediawiki as pak-
> kaged in Debian by listening to it via a trigger and running all
> upgrade scripts on all database schemas. This should be made for
> ff before wheezy.
I have a prototype here for doing that. There are unrelated problems as
well, but it's not committed yet because it doesn't work: the MW
upgrading code seems to have a bug, where it issues SQL statements such
as "SET search_path = plugin_mediawiki_siteadmin," (note ending comma).
I fixed that by locally adding…
$search_path = preg_replace( '/, *$/', '', $search_path);
…after line 1415 of /usr/share/mediawiki/maintenance/updaters.inc. I'm
not sure if this fix should be applied to MW or if the bug is actually
in the FF glue.
Roland.
--
Roland Mas
How does an octopus go into battle?
Fully-armed.