Re: [Wikitech-l] Dump processes seem to be dead

Let me ask a separate question (Ariel may be interested in this): What if we took the regular permanent media backups, and WMF filtered them in house just to remove the classified stuff (;-), and then put them somewhere where others could convert them to the desired format(s)? (Build all-history f

Re: [Wikitech-l] Dump processes seem to be dead

On Tue, Feb 24, 2009 at 6:49 AM, Andrew Garrett wrote: > On Tue, Feb 24, 2009 at 1:07 PM, Robert Ullmann wrote: >> Really? I mean is this for real? >> >> The sequence ought to be something like: breaker trips, monitor shows >> within a minute or two that 4 servers are offline, and not scheduled >

[Wikitech-l] gmane.science.linguistics.wikipedia.technical missing messages

> "ND" == Nicolas Dumazet writes: ND> 2009/2/24 Platonides : Platonides? I didn't see that message from Platonides here on http://news.gmane.org/gmane.science.linguistics.wikipedia.technical . But there it is in http://lists.wikimedia.org/pipermail/wikitech-l/2009-February/041667.html So Gman

Re: [Wikitech-l] Extension:SpamBlacklist download painful

> "KP" == K Peachey writes: KP> http://www.mediawiki.org/wiki/Special:ExtensionDistributor/SpamBlacklist OK, I tried it, but Download MediaWiki extension >From MediaWiki.org Invalid response from remote subversion client. ___ Wikitech-l mailing l

Re: [Wikitech-l] Extension:SpamBlacklist download painful

The infobox seems to missing the Extension Distributor link for downloading in which case would be http://www.mediawiki.org/wiki/Special:ExtensionDistributor/SpamBlacklist ___ Wikitech-l mailin

Re: [Wikitech-l] http://en.wikipedia.org/ --> 301 Moved Permanently

All I know is I get burnt every time e.g., the translation of a built in page name changes, so linking to Rtd> http://en.wikipedia.org/wiki/ --> 200 OK gives little more confidence than linking to Rtd> http://en.wikipedia.org/wiki/Main_Page --> 200 OK Let's see how the real professionals do it $ H

Re: [Wikitech-l] $wgSpamRegex now matches the edit summary TOO

I hacked in r47737 a "ignoreEditSummary" configuration parameter. Update your copy, and put $wgSpamBlacklistSettings['ignoreEditSummary'] = true; in your LocalSettings.php :) 2009/2/24 Platonides : > jidanni wrote: >> Can somebody please tell me how to regain the previous functionality? >> >> I a

Re: [Wikitech-l] Extension:SpamBlacklist download painful

Since you appear to use Linux, svn co http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SpamBlacklist targetDirectory/ (Later on, if you do "svn update" from the targetDirectory, your local copy will be updated to include the last changes.) Use "svn help" to get more help on what's avail

[Wikitech-l] Extension:SpamBlacklist download painful

Am I doing something wrong? On http://www.mediawiki.org/wiki/Extension:SpamBlacklist we see to download, we are to go to http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SpamBlacklist/ wherein apparently it takes a lot of clicking, http://svn.wikimedia.org/viewvc/mediawiki/trunk/extension

Re: [Wikitech-l] http://en.wikipedia.org/ --> 301 Moved Permanently

Maybe we could make /wiki/ show the front page and not just redirect? Then we would have: http://en.wikipedia.org/wiki/ --> 200 OK http://en.wikipedia.org/wiki/Main_Page --> 200 OK http://radioscanningtw.jidanni.org/ --> 200 OK http://radioscanningtw.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81

Re: [Wikitech-l] Dump processes seem to be dead

On Tue, Feb 24, 2009 at 1:07 PM, Robert Ullmann wrote: > Really? I mean is this for real? > > The sequence ought to be something like: breaker trips, monitor shows > within a minute or two that 4 servers are offline, and not scheduled > to be. In the next 5 minutes someone looks at the server(s),

[Wikitech-l] http://en.wikipedia.org/ --> 301 Moved Permanently

Hello, say, when we are running our link checker programs and see HEAD http://en.wikipedia.org/ --> 301 Moved Permanently HEAD http://en.wikipedia.org/wiki/Main_Page --> 200 OK HEAD http://wikimania2007.wikimedia.org/ --> 301 Moved Permanently HEAD http://wikimania2007.wikimedia.org/wiki/Main_Page

Re: [Wikitech-l] Dump processes seem to be dead

Hmm: On Mon, Feb 23, 2009 at 9:04 PM, Russell Blau wrote: > 2) Within the last hour, the server log at > http://wikitech.wikimedia.org/wiki/Server_admin_log indicates that Rob found > and fixed the cause of srv31 (and srv32-34) being down -- a circuit breaker > was tripped in the data center.

Re: [Wikitech-l] Javascript localization, minify, gzip & cache forever

On Mon, Feb 23, 2009 at 2:35 PM, Michael Dale wrote: > ... I was looking at commons upload form JavaScript load profile is like > a long waterfall or rather a steep river :( > http://metavid.org/promo/round_trips.png Note that this should be dramatically improved in next-gen browsers like Firefox

Re: [Wikitech-l] $wgSpamRegex now matches the edit summary TOO

jidanni wrote: > Can somebody please tell me how to regain the previous functionality? > > I assume I should remove my $wgSpamRegex, and instead > use $wgFilterCallback with an array of my patterns, testing only on > wpTextbox1. > Is there any simple example other than > http://svn.wikimedia.org/v

Re: [Wikitech-l] action=view links for [[:Category:With members, but no text]]

> "BTM" == Bryan Tong Minh writes: BTM> On Fri, Feb 13, 2009 at 9:16 PM, wrote: >> How can one link to a >> [[:Category:With members, but no text]] >> but with no action=edit produced? BTM> You could create a hook to LinkBegin that sets $options[] = 'known' if BTM> it is a category page:...

[Wikitech-l] $wgSpamRegex now matches the edit summary TOO

* $wgSpamRegex now matches the edit summary and page move descriptions in addition to body text. Oh no! I must not apply my rules also to the edit summary! How can I separate back out the functionality, without hacking more than just my LocalSettings.php? /** Similarly you can get a function

Re: [Wikitech-l] Dump processes seem to be dead

Robert Rohde wrote: > The largest gains are almost certainly going to be in parallelization > though. A single monolithic dumper is impractical for enwiki. > > -Robert Rohde Using dumps compressed per blocks, as the ones I used for http://lists.wikimedia.org/pipermail/wikitech-l/2009-January/040

Re: [Wikitech-l] MediaWiki 1.14.0 and 1.13.5 released

On 2/22/09 3:31 AM, Tim Starling wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > We are proud to announce the first stable release of the 2009 Q1 > branch of MediaWiki, version 1.14.0. Yay! Thanks Tim for all the work you've put into fixing up the branch for release and cleaning up

Re: [Wikitech-l] Dump processes seem to be dead

On 2/23/09 12:13 PM, Ariel T. Glenn wrote: > I asked for it, and that's why it was assigned to me. I should have > recognized much sooner that I could not actually get it done and should > have brought this to Brion's attention instead of continuing to hang on > to it after he brought it to my att

Re: [Wikitech-l] Dump processes seem to be dead

On 2/23/09 3:08 AM, Marco Schuster wrote: > Even if you had the dumps, you have another problem: They're > incredibly big and so a bit difficult to parse. So, a small suggestion > if the dumps will ever be workin' again: Split the history and current > db stuff by alphabet, please. Define alphabet

Re: [Wikitech-l] Dump processes seem to be dead

Στις 23-02-2009, ημέρα Δευ, και ώρα 19:02 +, ο/η Thomas Dalton έγραψε: > 2009/2/23 Ariel T. Glenn : > > The reason these dumps are not rewritten more efficiently is that this > > job was handed to me (at my request) and I have not been able to get to > > it, even though it is the first thing on

Re: [Wikitech-l] Javascript localization, minify, gzip & cache forever

On 2/23/09 11:35 AM, Michael Dale wrote: *snip* > Like the localization msg system this logic is hampered by the fact the > script loader is /optional/. If we required the script loader it could > be simpler: *nod* I don't think it's really feasible to make use of the loader optional and still ke

Re: [Wikitech-l] Mobile gateway testing

The page history is completely missing, as well as a link to the GFDL-copy, the mobile mirror is therefore not GFDL-conform. On Fri, Feb 20, 2009 at 12:07 AM, Chad wrote: > I think for anything other than casual browsing, using > native clients would be better. Perfect use of the API. > I've been

Re: [Wikitech-l] Javascript localization, minify, gzip & cache forever

... I was looking at commons upload form JavaScript load profile is like a long waterfall or rather a steep river :( http://metavid.org/promo/round_trips.png Would be much nicer do 1 or 2 request instead of 27 ... true... a lot are gadgets and what not.. but even on a not logged in Main page vi

Re: [Wikitech-l] Dump processes seem to be dead

On Mon, Feb 23, 2009 at 11:08 AM, Alex wrote: > Most of that hasn't been touched in years, and it seems to be mainly a > Python wrapper around the dump scripts in /phase3/maintenance/ which > also don't seem to have had significant changes recently. Has anything > been done recently (in a very bro

Re: [Wikitech-l] Dump processes seem to be dead

Most of that hasn't been touched in years, and it seems to be mainly a Python wrapper around the dump scripts in /phase3/maintenance/ which also don't seem to have had significant changes recently. Has anything been done recently (in a very broad sense of the word)? Or at least, has anything been w

Re: [Wikitech-l] Dump processes seem to be dead

2009/2/23 Ariel T. Glenn : > The reason these dumps are not rewritten more efficiently is that this > job was handed to me (at my request) and I have not been able to get to > it, even though it is the first thing on my list for development work. > So, if there are going to be rants, they can be di

Re: [Wikitech-l] Dump processes seem to be dead

Ariel, Thank you for giving some insight into what has been going on behind the scenes. I have a few questions that will hopefully get some answers to those of us eager to help out in any way we can. What are the planned code changes to speed the process up? Can we help this volunteer with

Re: [Wikitech-l] Dump processes seem to be dead

Thanks for the update Russell! On Feb 23, 2009, at 10:04 AM, Russell Blau wrote: > "Russell Blau" wrote in message > news:gnuacf$hf...@ger.gmane.org... >> >> I have to second this. I tried to report this outage several times >> last >> week - on IRC, on this mailing list, and on Bugzilla. Al

Re: [Wikitech-l] Dump processes seem to be dead

"Russell Blau" wrote in message news:gnuacf$hf...@ger.gmane.org... > > I have to second this. I tried to report this outage several times last > week - on IRC, on this mailing list, and on Bugzilla. All reports -- NOT > COMPLAINTS, JUST REPORTS -- were met with absolute silence. Two updates

[Wikitech-l] devious looking $bookstoreList

You must excuse me but if you take a look in mediawiki-1.14.0rc1/languages/messages/MessagesRu.php there's this hundreds of bytes long string of z's etc. at $bookstoreList. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedi

Re: [Wikitech-l] Dump processes seem to be dead

"Lars Aronsson" wrote in message news:pine.lnx.4.64.0902231202140.1...@localhost.localdomain... > > However, quite independent of your development work, the current > system for dumps seems to have stopped on February 12. That's the > impression I get from looking at > http://download.wikimedia.o

Re: [Wikitech-l] Dump processes seem to be dead

Ariel T. Glenn wrote: >> The reason these dumps are not rewritten more efficiently is >> that this job was handed to me (at my request) and I have not >> been able to get to it, even though it is the first thing on my >> list for development work. >> [...] >> The in-office needs that I am also

Re: [Wikitech-l] Dump processes seem to be dead

2009/2/22 Robert Ullmann : > Want everyone to just dynamically crawl the live DB, with whatever > screwy lousy inefficiency? FIne, just continue as you are, where that > is all that can be relied upon! Even if you had the dumps, you have another problem: They're incredibly big and so a bit difficu

Re: [Wikitech-l] Dump processes seem to be dead

yep, http://svn.wikimedia.org/viewvc/mediawiki/trunk/backup/ +) 2009/2/23 Alex : > Ariel T. Glenn wrote: >> The reason these dumps are not rewritten more efficiently is that this >> job was handed to me (at my request) and I have not been able to get to >> it, even though it is the first thing on