https://bugzilla.wikimedia.org/show_bug.cgi?id=63659
Bryan Davis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #8 from Bryan Davis <[email protected]> --- * mw-update-l10n gets version=wikidb data via mwversionsinuse * mwversionsinuse reads from /a/common/wikiversions.json * mwscript uses MWMultiVersion::initializeForMaintenance() to process the `--wiki=<WIKIDB>` argument and choose a php-1.XwmfY version to run scripts from. * MWMultiVersion::getVersion() reads the compiled /usr/local/apache/common-local/wikiversions.cdb to find the version for a given database * Scap does not compile /usr/local/apache/common-local/wikiversions.json into /usr/local/apache/common-local/wikiversions.cdb until the final step in the scap process. This combination means that when mw-update-l10n runs `mwscript mergeMessageFileList.php` the version seen by mergeMessageFileList will always be the version that database was at on after the *prior* scap (or sync-wikiversions) execution. This is why it looks like ExtensionMessages-1.23wmf21 was built for the prior version; it was. If you run scap twice without changing wikiversions.json, the second time mergeMessageFileList.php will see the expected version of MediaWiki. The fix for this is to add a step early in scap (just after sync-common) to compile /usr/local/apache/common-local/wikiversions.json to wikiversions.cdb. This shouldn't be done before or during sync-common because that would push the updated version out to the apaches during their runs of sync-common and thus before they have compiled the l10n cache locally. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
