Hi everyone!
I want to move my wiki from one server (A) to another (B). On server A I
have a lot of files. I don't need them on server B, but I need all my
wikipages.
What I've done is: I removed the 'images' directory and ran:
php maintainance/rebuildall.php
Unfortunately now wiki still thinks that all the files are at the places
where they need to be. This is clearly not true since the images directory
is empty.
Questions:
1) how to property delete the files permanently?
2) is there any script to make the files and their description in MediaWiki
DB consistent?
Cheers,
-----
Yury Katkov, WikiVote
Reposting from mobile-tech:
I wrote a short Ruby script to show what versions of MediaWiki different
projects are running on:
https://gist.github.com/b5a97d4dc34f5fc56304
Shows number of languages running on a given project/version.
Might make easier figuring out if a patch in core we need is already
deployed. I guess for now we're interested in wiki and wikivoyage.
Sample output:
$ ruby wikiver.rb
---
all:
php-1.21wmf7: 863
php-1.21wmf8: 4
wikibooks:
php-1.21wmf7: 121
wiki:
php-1.21wmf7: 332
php-1.21wmf8: 4
wiktionary:
php-1.21wmf7: 171
wikiquote:
php-1.21wmf7: 88
wikisource:
php-1.21wmf7: 64
wikimedia:
php-1.21wmf7: 30
wikinews:
php-1.21wmf7: 33
wikiversity:
php-1.21wmf7: 15
wikivoyage:
php-1.21wmf7: 9
Good news for the few Windows users of you.
I succeeded in accessing my labsconsole VM using
* PuTTY and
* WinSCP
with appropriate proxy (PuTTY) respectively tunnel (WinSCP) settings via
the bastion server.
_This will be documented in the next days_ (sorry, not earlier) on
https://labsconsole.wikimedia.org/wiki/Help:Access
and https://labsconsole.wikimedia.org/wiki/Help:Putty .
With the correct settings, a _single_ click connection or file transfer
is possible,.
No command line input trouble is needed.
Tom
This is great news. Congratulations to those who worked on this grant proposal. I'm always glad to hear that progress continues to be made at making Wikimedia content more accessible and/or editable on mobile.
Pine
On Fri, Jan 11, 2013 at 9:37 AM, Siebrand Mazeland (WMF) <
smazeland(a)wikimedia.org> wrote:
> Date: Thursday 2013-01-17
> Time: 10:00 UTC - 11:00 UTC
> What: Knowledge transfer Solr in Translate
> Where: Google Hangout (*send me a mail for an invitation*)
> Seats left: 5 (first come, first served, I'll overbook by 2)
>
> Over the past few months, we have started integrating MediaWiki's
> Translate extension tighter with Apache Solr for translation memory and
> translation search features. This session is primarily meant to transfer
> knowledge about the use of Solr in Translate to other members of the
> Wikimedia Language Engineering team. As we're doing it anyway, we thought
> we might as well invite more people that have and interest in the
> technology.
A recording of the session is available now:
http://www.youtube.com/watch?v=yH902KsEYag
Cheers!
Hi everyone,
We attempted to deploy 1.21wmf8 using git-deploy[1], and ran into
enough problems that we decided the best course of action is to use
scap[2] today and for the foreseeable future.
The new plan is to implement scap/sync-file/sync-dir for Eqiad as a
temporary solution for next week and possibly as much as a few weeks
beyond that, and then deploy a new-and-improved git-deploy when we
have the problems we uncovered today sorted out.
That means people deploying code *don't* have to learn a new system
right away; scap/sync-file/sync-dir will remain the standard mechanism
for the rest of this week and the rest of next at a minimum, and
probably a while longer. Yay for the devil we know! :-)
Ryan and Chris will still be doing the tutorial tomorrow (lunchtime in
SF). Ryan tells me that the changes he's planning are under-the-hood,
and that users of the system shouldn't notice anything substantially
different in the workflow.
Rob
[1] http://wikitech.wikimedia.org/view/Git-deploy
[2] http://wikitech.wikimedia.org/view/Scap
Hi everyone,
As you probably read from CT's email last week about the Eqiad
migration (you read that, right? No? Go read it. I'll wait)
Ok, done now? So, as you know (now), we plan to suspend all scheduled
deployments next week during the data center migration (January
21-25). We'd like to keep the number of moving parts to a minimum,
thus we'd like to avoid changing anything unless necessary.
That said, we are contemplating leaving the Wednesday window for
1.21wmf8 to non-Wikipedia in place as a means of testing deployments
themselves. Unlike previous core deployments (which are pretty
routine), we're reserving the right not to have that deployment, and
may delay the already-revised deployment calendar one more week if
things are still messy on Wednesday. I'm guessing that the odds of
that deployment happen are pretty low (I'll say "20%" based on aerial
extraction).
So, to reiterate the plan with respect to deployments over the next
couple of weeks:
January 14-15 (Mon-Tue): deployments from fenari to Tampa cluster
using scap/sync-file/sync-dir as normal.
January 16 (Wed): 1.21wmf8 deployed to test, test2, and mediawiki.org
January 16-18 (Wed-Fri): 1.21wmf8 deployments using git-deploy from fenari
January 17 (Thu): Brown bag with Ryan Lane and Chris Steipp to talk
about git-deploy
January 21 (Mon): Deployment freeze (and U.S. holiday)
January 22-25 (Tue-Fri): Deployment freeze
January 23 (Wed): MAYBE 1.21wmf8 deployment to some or all non-Wikipedia sites.
I hope this all makes sense. Questions/comments/concerns?
Rob
Željko Filipin, QA Engineer for WMF, will be giving a presentation at
FOSDEM in Brussels Feb 2 about our browser automation project.
Congratulations Željko, it looks like a great track to be part of.
https://fosdem.org/2013/schedule/track/testing_and_automation/