[00:02:03] <jcrowgey>	 Hi there, we recently upgraded from wikimedia 1.12.0 to 1.15.5-8 and i'm having some trouble getting the right output for <style> elements, can anyone advise?
[00:06:57] <jcrowgey>	 in the old version, pages get output with a <style> element that's being generated by index.php, but in the new version no such style element is output.  can anyone point me to documentation index.php?action=raw&gen=css
[00:13:20] <jcrowgey>	 i wonder if this room is all robots, it looks like there are many people here.  can anyone advise if this is there is a better room for my question?
[00:14:51] <RoanKattouw>	 jcrowgey: For MediaWiki support you should be in #mediawiki
[00:15:34] <LeslieCarr>	 jcrowgey: sorry, i am here but have no idea myself :(
[00:37:06] <wilfredor>	 Hi
[00:37:44] <wilfredor>	 I need a article list from a Category list, how make that?
[00:38:16] <wilfredor>	 Mi category list is in es:wp
[00:38:23] <wilfredor>	 http://pastebin.com/me6baH87
[00:38:55] <RoanKattouw>	 So you have a list of categories, and you want a list of pages in those categories?
[00:39:06] <wilfredor>	 RoanKattouw: right
[00:39:18] <RoanKattouw>	 I am not aware of any existing tool that will do that for you, you may have to write code to do this
[00:39:22] <wilfredor>	 That is for make a ZIM file for SOS Childrens
[00:39:33] <RoanKattouw>	 If anyone knows of a tool, they're probably in #mediawiki , which is the proper channel for this question
[00:39:51] <wilfredor>	 I need help, I havent time
[00:40:01] <wilfredor>	 It;s for the FLISOL
[00:46:24] <jcrowgey>	 lesliecarr, thanks for the reply.  i'll keep googling and experimenting
[01:47:21] <logmsgbot_>	 !log awjrichards synchronizing Wikimedia installation... : r114983 on wikis still running 1.19
[01:47:25] <morebots>	 Logged the message, Master
[02:23:57] <logmsgbot_>	 !log LocalisationUpdate completed (1.19) at Fri Apr 20 02:23:57 UTC 2012
[02:24:00] <morebots>	 Logged the message, Master
[02:33:02] <logmsgbot_>	 !log LocalisationUpdate completed (1.20wmf1) at Fri Apr 20 02:33:02 UTC 2012
[02:33:04] <morebots>	 Logged the message, Master
[03:52:15] <__URANUS__QD>	 !ops !admin
[04:56:00] <pgehres>	 !log disabled paypal on donatewiki and disabled queue consumer for duration of PayPal outage
[04:56:04] <morebots>	 Logged the message, Master
[04:56:54] <Bsadowski1>	 http://www.internetretailer.com/2012/04/19/paypal-plans-outage-tonight-move-data-center
[04:56:54] <Bsadowski1>	 ah
[06:07:58] <AFBorchert>	 again timeouts with deletions at Commons: Request: POST http://commons.wikimedia.org/w/index.php?title=File:Ramapir22.jpg&action=delete, from 78.43.93.68 via amssq43.esams.wikimedia.org (squid/2.7.STABLE9) to 91.198.174.56 (91.198.174.56)
[06:08:02] <AFBorchert>	 Error: ERR_READ_TIMEOUT, errno [No Error] at Fri, 20 Apr 2012 06:07:06 GMT
[06:27:36] <pgehres>	 !log re-eanabled PayPal on donatewiki and wmfwiki and resumed queue consumer on Aluminium
[06:27:39] <morebots>	 Logged the message, Master
[08:27:36] <logmsgbot_>	 !log LocalisationUpdate completed (1.19) at Fri Apr 20 08:27:36 UTC 2012
[08:27:38] <morebots>	 Logged the message, Master
[08:36:53] <logmsgbot_>	 !log LocalisationUpdate completed (1.20wmf1) at Fri Apr 20 08:36:53 UTC 2012
[08:36:55] <morebots>	 Logged the message, Master
[13:14:56] <logmsgbot_>	 !log demon synchronized php-1.20wmf1/maintenance/backupTextPass.inc  'Pushing out Idb58ce27 for Ariel/Chris for dumps'
[13:14:58] <morebots>	 Logged the message, Master
[13:34:14] <apergos>	 ok this sucks. 
[13:34:27] <apergos>	 getRawText is used to populate the length
[13:34:39] <apergos>	 of course we don't use it in the xml output (rightly so I suppose)
[13:36:57] <apergos>	 bah
[13:57:56] <apergos>	 ^demon: holler when you have a few minutes, I need someone to run this issue by
[13:58:05] <^demon>	 What's up?
[13:58:32] <apergos>	 so trying to sort out the rev_len (and soon to be sha1) issue
[13:59:02] <apergos>	 here's the sound byte version:  the text in the xml dumps is munged to drop \r.  expected by evryone, that's not changing.
[13:59:23] <apergos>	 we record rev_len in there with each text.  rev_len is the length of the raw thing in the db (or should be anyways). 
[13:59:32] <apergos>	 rev_len !+ length(xml text)
[13:59:35] <apergos>	 != 
[13:59:52] <apergos>	 this is bad.  it's bad for prefetch (read old text. length = rev-Len? no? try the db)
[14:00:07] <apergos>	 it's bad for users (I'm checking this text and using the length.. and wtf?)
[14:00:09] <apergos>	 etc.
[14:00:30] <^demon>	 rev_len is being calculated before \r is stripped?
[14:00:32] <apergos>	 options are; don't munge (fail.  breaks backwards compat and we've been doing it forever)
[14:00:53] <apergos>	 rev_len is cauclatd from getRawText() (see the populate rev_len script)
[14:01:24] <apergos>	 we use getRevisionText() to get our copy
[14:01:34] <apergos>	 and then do 
[14:01:36] <apergos>	 		$stripped = str_replace( "\r", "", $text );
[14:01:37] <apergos>	 to it
[14:01:53] <apergos>	 just in case. (I think the parser does that anyways but for old revisions that are already in there...)
[14:02:36] <apergos>	 so
[14:02:48] <apergos>	 what to do. :-D
[14:03:12] <apergos>	 for prefetch we will only have the text as it appears in the xml file. plus the rev_len we wrote with it. 
[14:03:36] <apergos>	 so that is the number that has to be in the db
[14:03:58] <apergos>	 if it's going to do us any good. but then that changes the defn of rev_len somewhat.
[14:04:05] <^demon>	 The *best* solution is to to strip \r *everywhere* IMHO.
[14:04:06] <apergos>	 the same will be true for sha1 when that foes
[14:04:19] <^demon>	 I don't see the point in storing the \r when we strip it in so many places.
[14:04:19] <apergos>	 well sure but then those old revs in the db....
[14:04:33] <apergos>	 need to all get rewritten and boy that's dicey
[14:04:48] <^demon>	 Yeah, it's certainly not trivial.
[14:04:55] <apergos>	 maybe it's oce burned twice shy but there have been so many issues when we try to "fix" old revisions...
[14:05:12] <apergos>	 though I agree in the longer term we want to do it.  in the short term though
[14:05:16] <^demon>	 We could pretend the old revisions don't exist ;-)
[14:05:20] <apergos>	 hahaha
[14:05:23] <apergos>	 no not so much
[14:05:27] <apergos>	 they are in a billion dumps
[14:05:29] <apergos>	 :-P
[14:05:31] <apergos>	 well
[14:05:37] <apergos>	 a few hundred anyways
[14:05:58] <apergos>	 so I would be pitching for the sha1 and the rev-_len to be "text without \r" 
[14:06:10] <^demon>	 I agree there.
[14:06:12] <apergos>	 I hope we don't do any other transormations on the text before we write it
[14:06:18] <^demon>	 Every other solution sounds hacky.
[14:06:25] <apergos>	 yeah they do don't they?
[14:06:47] <^demon>	 The only other text transformation I can think of PST, but that's done well before it gets to you.
[14:06:53] <^demon>	 *of is
[14:06:55] <apergos>	 pst?
[14:07:00] <^demon>	 pre-save transform.
[14:07:18] <apergos>	 well that *should* affect the text before it goes in too
[14:07:35] <apergos>	 (I was looking at that, which is what makes me think anything not ancient already has the \r's gone)
[14:08:12] <apergos>	 ok, we also have 
[14:08:14] <apergos>	 $normalized = $wgContLang->normalize( $stripped );
[14:08:21] <apergos>	 I know we do some normalization before save
[14:08:37] <apergos>	 but that above line gets done for the xml text we write out
[14:08:49] <apergos>	 (and hence for rev len)
[14:08:49] <^demon>	 Yeah, that does unicode and other various normalization that I know zilch about.
[14:08:52] <apergos>	 uh huh
[14:09:13] <apergos>	 old revisoins aren't normalizaed, I have a pointer to a few somewhere
[14:09:18] <apergos>	 (they should be someday)
[14:09:25] <^demon>	 Old revisions suck :)
[14:09:30] <apergos>	 yes they sure do
[14:09:35] <apergos>	 welcome to my hell :-D
[14:09:57] <apergos>	 I should say "they aren't well normalized", there was probably some cleanup done on them
[14:10:15] <^demon>	 I'm fine with changing what _len and _sha1 mean, it should only *practically* affect the old revisions.
[14:10:22] <^demon>	 (back to the original problem)
[14:10:58] <apergos>	 I think that's right
[14:11:22] <apergos>	 this will mean a rerun of the population script with a patch (since it currently uses the "wrong" text)
[14:11:47] <apergos>	 ok, thanks for your ears, wanted to make sure I wasn't overlooking some brilliant better solution
[14:11:51] <^demon>	 If we have a list of affected revisions, we could make the script only run on those revs.
[14:11:55] <^demon>	 Would save tons of time.
[14:12:00] <apergos>	 we don't
[14:12:05] <^demon>	 Well damn :(
[14:12:19] <apergos>	 how would we get it? check the length against the text length :-P
[14:12:25] <apergos>	 but if we're already in there, 
[14:12:41] <apergos>	 might as well just do that check at the time the script runs, if it fails, update the value
[14:13:31] <^demon>	 Good point, no point in iterating twice.
[14:13:36] <apergos>	 not so much
[14:14:11] <apergos>	 ok thanks again
[14:14:31] <^demon>	 You're welcome.
[15:42:00] <slakr>	 hmm... has anyone investigated changing ConfirmEdit to use reCAPTCHA instead of FancyCaptcha?
[15:42:22] <slakr>	 it looks like FancyCaptcha's getting increasingly cracked: http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=271
[15:42:24] <Reedy>	 isn't recaptcha broken?
[15:42:31] <slakr>	 no idea
[15:42:39] <slakr>	 I mean, I assumed it was still working, but I dunno
[15:42:41] <Reedy>	 lol
[15:42:58] <Reedy>	 http://www.allspammedup.com/2011/01/google-recaptcha-cracked/
[15:43:04] <Reedy>	 RIP.
[15:43:12] <slakr>	 well I mean
[15:43:29] <slakr>	 put another way, even if recaptcha is cracked, it's not *as* cracked as FancyCaptcha :P
[15:43:36] <slakr>	 or at least, is a little more difficult to crack than Fancy
[15:43:57] * slakr  shrugs

[15:44:29] <slakr>	 the 59.57.14.123 contrib list and EF hit list are particularly ominous
[15:45:39] <sDrewth>	 can anyone tell me what a global IP block actually prevents on WMF wikis
[15:45:49] <sDrewth>	 obviously it stops edits
[15:46:00] <sDrewth>	 but does it stop creation of accounts
[15:46:11] <sDrewth>	 and/or does it stop the autocreation of accounts?
[15:46:22] <sDrewth>	 where an existing account is in play
[15:49:40] <slakr>	 afaik, auto-creation of accounts happens before blocks are handled. (i.e., it happens as part of the auth hooks, which come before the block matches), but I could be totally wrong
[15:54:46] <sDrewth>	 thanks slakr that would align with what I saw with creations and a blocked IP
[17:00:33] <logmsgbot_>	 !log reedy synchronized wmf-config/InitialiseSettings.php  'Giving test2wiki moar namespaces'
[17:00:35] <morebots>	 Logged the message, Master
[17:01:58] <logmsgbot_>	 !log reedy synchronized wmf-config/InitialiseSettings.php  'Bug 36124 - Deploy ProofreadPage extension on test2'
[17:02:01] <morebots>	 Logged the message, Master
[17:11:14] <RoanKattouw>	 !log Fixed ownership of /h/w/common/php-1.20wmf1/cache/l10n , should be owned by l10nupdate but was owned by reedy
[17:11:16] <morebots>	 Logged the message, Mr. Obvious
[17:31:05] <logmsgbot_>	 !log catrope synchronized wmf-config/CommonSettings.php  'Remoev wgArticleFeedbackv5OversightEmails override that was messing things up'
[17:31:08] <morebots>	 Logged the message, Master
[17:38:11] <robla>	 AaronSchulz: * Tuesday, April 17, 22:00-23:00 UTC (3pm-4pm PDT): Configuration change for Swift on commons [Aaron, Ben]  <--- this didn't happen yet did it?
[17:43:51] <AaronSchulz>	 no
[17:45:22] <robla>	 AaronSchulz: when should we schedule that?
[17:46:47] <AaronSchulz>	 next tue? not sure
[17:46:59] <robla>	 Reedy: there's an item on the deploy calendar: * Enable EnotifWatchlist on all wikis, 1 h window with ops to check load ([[bugzilla:28026]], [[RT:1784]]) [Scheduling: Reedy] 
[17:50:21] <guillom>	 errr
[17:50:29] <guillom>	 I can't reach any Wikimedia site
[17:50:30] <StevenW>	 what he said ^
[17:50:32] <Thehelpfulone>	 secure just broke?
[17:50:38] <Thehelpfulone>	 it's only on https://
[17:50:43] <guillom>	 ok
[17:53:25] <MaxSem>	 am I the only one for whom site is ureachable via HTTPS?
[17:53:28] <Amgine>	 https://en.wiktionary.org/wiki/ <- blank for me
[17:53:37] <RoanKattouw>	 HTTPS is broken, known issue
[17:53:39] * RoanKattouw  updates topic

[17:53:44] <Wiki13>	 ah?
[17:53:53] <Wiki13>	 https is failing?
[17:55:39] <Nemo_bis>	 HTTPS everywhere kills me
[17:56:13] <Wiki13>	 me also
[17:56:24] <RoanKattouw>	 Yes, HTTPS is broken
[17:56:27] <RoanKattouw>	 We figured out why
[17:56:29] <Wiki13>	 you need to disable it to 
[17:56:33] <closedmouth>	 read the topic
[17:56:41] <Nemo_bis>	 Wiki13, yeah, too lazy even for thet :p
[17:56:49] <RoanKattouw>	 Someone deployed a new nginx configuration, and that caused all nginx servers (including the ones that serve as HTTPS proxies) so restart at the same time
[17:57:03] <Nemo_bis>	 oh
[17:57:28] <helderwiki>	 Is https://en.wikipedia.org down?
[17:57:33] <RoanKattouw>	 helderwiki: See topic
[17:57:46] <helderwiki>	 I'm getting Erro 15 (net::ERR_SOCKET_NOT_CONNECTED): Erro desconhecido. (only on httpS)
[17:57:56] <closedmouth>	 takes two seconds
[17:58:03] <helderwiki>	 thanks
[17:58:23] <malafaya>	 actually I had to read it twice to understand it was onnly an HTTPS issue :)
[18:00:43] <Danny_B|backup>	 any eta for https up?
[18:00:50] <Reedy>	 few minutes
[18:01:36] <logmsgbot_>	 !log awjrichards synchronizing Wikimedia installation... : 
[18:01:38] <morebots>	 Logged the message, Master
[18:02:38] <RoanKattouw>	 OK, things should be coming back up now
[18:02:46] <RoanKattouw>	 According to nagios, the following are back up
[18:03:23] <RoanKattouw>	 For Europe: bits, upload, wikipedia, wikibooks, wikimediafoundation
[18:03:38] <RoanKattouw>	 For the US: bits only
[18:03:47] <RoanKattouw>	 Ahm
[18:03:58] <RoanKattouw>	 When I say "the US" I really mean "the entire world except Europe"
[18:04:21] <MaxSem>	 WP is still down for me in Europe
[18:04:27] <emijrp>	 wikipedia down for me, Spain
[18:04:31] <closedmouth>	 there are places other than the US and europe?
[18:04:42] <PiRSquared>	 closedmouth: maybe Asia?
[18:04:55] <closedmouth>	 never heard of it
[18:05:25] <PiRSquared>	 it's that thing over there
[18:05:29] <Amgine>	 Oceania.
[18:08:32] <RoanKattouw>	 Ah yes Nagios is reporting Europe as having gone back down now
[18:08:42] <omtsh>	 I'm in the UK, down here.
[18:08:53] <RoanKattouw>	 Looks like we're having some additional problems, it's being looked at
[18:10:39] <Jan_eissfeldt>	 a german admin just notified me, he is down. looks like https only
[18:11:04] <RoanKattouw>	 Yes
[18:11:09] <RoanKattouw>	 HTTPS is down across the entire Wikimedia cluster
[18:11:27] <RoanKattouw>	 It briefly looked like things were coming back up, but it looks like that was a fluke, it's all gone back down now
[18:35:46] <RoanKattouw>	 OK HTTPS should be coming back up now
[18:36:15] <emijrp>	 ok in SPain
[18:36:30] <Superjuju10>	 Hi. Explanation of the failure of HTTPS .
[18:36:33] <Superjuju10>	 ?
[18:36:39] <Wiki13>	 ehm
[18:36:42] <Jan_eissfeldt>	 no trouble in the german projects
[18:37:01] <Superjuju10>	 Down in #wikipedia-fr
[18:37:07] <RoanKattouw>	 According to Nagios, HTTPS should be back up wordwide for all projects
[18:37:14] <RoanKattouw>	 *worldwide
[18:37:21] <Wiki13>	 Superjuju10: <RoanKattouw> Someone deployed a new nginx configuration, and that caused all nginx servers (including the ones that serve as HTTPS proxies) so restart at the same time
[18:37:24] <MatmaRex_>	 pl.wiki works for me
[18:37:33] <RoanKattouw>	 It was a little bit more complicated than that
[18:37:42] <Wiki13>	 oh?
[18:37:43] <RoanKattouw>	 The nginx configuration change itself was at fault
[18:37:55] <Wiki13>	 -.-
[18:37:59] <RoanKattouw>	 It looked innocent enough, but apparently it caused issues somehow
[18:38:01] <Snowolf>	 HTTPS working for me and Savh
[18:38:18] <RoanKattouw>	 Or at least that's what people think, because undoing the config change made everything come right back up
[18:38:22] <Superjuju10>	 Wiki13: A report with a future update Mediawiki?
[18:38:35] <Wiki13>	 idk
[18:38:38] <Wiki13>	 working on NL now btw
[18:38:38] <RoanKattouw>	 This was not related to the MediaWiki 1.20 upgrade in any way
[18:48:02] <logmsgbot_>	 !log catrope synchronized php-1.19/extensions/ArticleFeedbackv5  'Apply https://gerrit.wikimedia.org/r/5449'
[18:48:04] <morebots>	 Logged the message, Master
[18:48:28] <logmsgbot_>	 !log catrope synchronized php-1.20wmf1/extensions/ArticleFeedbackv5  'Apply https://gerrit.wikimedia.org/r/5449'
[18:48:30] <morebots>	 Logged the message, Master
[18:48:49] <Snowolf>	 Could anybody take a look at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Issues_with_the_security_certificate.3F ?
[18:48:58] <Snowolf>	 I got all those kinds of things ignored so I cannot test it
[18:49:34] <RoanKattouw>	 Eww
[18:50:44] <Jarry1250>	 Is (will) anyone from ops (be) looking at the session expiry/can't log in problem, btw?
[18:50:57] <RoanKattouw>	 Is it still occurring?
[18:58:25] <Jarry1250>	 Roan: Yup, says en:WP:VPT
[19:10:19] <malafaya>	 does anyone know if localizations from TW are being synched with live wikis?
[19:15:30] <saper>	 malafaya: yes, there is a thing called "l10n update"
[19:16:05] <malafaya>	 i meant if it is already running after the move to git
[19:16:18] <malafaya>	 apparently it is (i was told in #mediawiki-i18n
[19:23:11] <Superjuju10>	 HTTPS back in french Wikipedia 
[20:02:06] <logmsgbot_>	 !log aaron synchronized php-1.20wmf1/includes/filerepo/file/LocalFile.php  'deployed c77fbd394cda701758ad4523113f567bff7ede66'
[20:02:08] <morebots>	 Logged the message, Master
[20:13:38] <Superjuju10>	 Good night :)
[21:52:23] <logmsgbot_>	 !log aaron synchronized wmf-config/CommonSettings.php  'Added NFS backends for local/shared repos; they are not used yet.'
[21:52:25] <morebots>	 Logged the message, Master
[22:01:01] <logmsgbot_>	 !log aaron synchronized wmf-config/CommonSettings.php  'Switched testwiki to use the new LocalRepo config style.'
[22:01:03] <morebots>	 Logged the message, Master
[22:03:37] <logmsgbot_>	 !log aaron synchronized wmf-config/CommonSettings.php  'Switched test2wiki to use the new LocalRepo config style.'
[22:03:39] <morebots>	 Logged the message, Master