[00:56:16] !log tstarling synchronizing Wikimedia installation... : [00:56:18] Logged the message, Master [01:06:06] !log preilly synchronized php-1.19/extensions/MobileFrontend/MobileFrontend.body.php 'fix html formatter' [01:06:08] Logged the message, Master [01:18:46] !log preilly synchronized php-1.19/extensions/MobileFrontend/ 'zero and mobile changes' [01:18:49] Logged the message, Master [01:35:31] AaronSchulz: https://www.mediawiki.org/w/resources-1.20wmf1/maintenance/update.php etc. [01:40:43] !log preilly synchronized php-1.19/extensions/MobileFrontend/templates/ApplicationTemplate.php 'fix robots file' [01:40:45] Logged the message, Master [01:40:59] Krinkle: what about that? [01:42:05] AaronSchulz: well that looks like a misconfigured symlink, it should point to resources to not to mw [01:42:25] or is there a need to have mw-root versions public? [01:42:59] it means the regular /w protections don't apply. not that it is venerable right away, it is not supposed to be accessible [01:43:06] and never was up until recently [01:43:21] anyway filed as bug 35939 [01:47:19] Krinkle: I think there are some extensions or something [01:47:25] it's like that for some hacky reason [01:47:50] wgExtensionAssetsPath is bits.wikimedia.org/w/extensions-1.xxwmfx/* [01:47:51] I think it was assumed that a proper config var fix would come in the next version... [01:48:17] this was done in 1.19/1.18 to fix ./resources 404 errors because /w/resources can only point to one version simultaneously [01:48:53] so as a hack this was done, it works for ./w/resources which is now verison-available via ./w/resources-1.xxx/resources/ [01:49:15] but I doubt there is a reason to have that additional level there, if not, feel fee to document it on the bug [02:20:35] !log LocalisationUpdate completed (1.19) at Fri Apr 13 02:20:35 UTC 2012 [02:20:37] Logged the message, Master [02:29:12] "* Implement $wgResourcesPath and $wgResourcesDirectory" [02:29:19] Krinkle: what would each of those do? [02:29:48] Like stylesdir and stylespath [02:29:51] internal/external [02:30:13] ahh, yes [02:30:24] * AaronSchulz randomly forgets that convention sometimes [02:30:29] If one isn't needed, that's fine too [02:30:44] well, it doesn't exactly make sense that a dir is one and a path the other. [02:31:00] yeah [02:31:24] anyway, I'd lean towards the first option [02:32:01] I gotta go btw, I'll see it on the bug [02:37:32] hmm [02:37:59] how can I convert one date format to what user prefers?? [02:39:01] !log LocalisationUpdate completed (1.20wmf1) at Fri Apr 13 02:39:01 UTC 2012 [02:39:03] Logged the message, Master [02:48:56] !log tstarling synchronizing Wikimedia installation... : [02:48:59] Logged the message, Master [02:54:40] any reason Im only getting 60kb/s download speed for the enwiki dump? [02:58:29] > Betacommand: Your connection sucks? You've been rate-limited for multiple concurrent connections? There's a bad hop somewhere? [02:58:41] ToAruShiroiNeko: The {{formatdate:}} magic word. [02:58:51] cf. mediawiki.org/wiki/Help:Magic_words [02:59:00] Joan: its my only connection, I get 400+ on other project dumps [03:01:19] Betacommand: Are you downloading only one dump? [03:01:25] yes [03:01:55] Hmm, dunno. You could play around with traceroute to see if there's a bad hop somewhere. [03:03:19] Joan: Im looking but its odd, I only have the issue with the enwiki dump [03:07:29] Joan: traceroute is clear 19 74 ms 73 ms 73 ms dataset2.wikimedia.org [208.80.152.185] [03:10:44] I'm not sure if load affects the response time of the server. [03:10:58] If a lot of people are requesting the same dump, I'd guess it slows it down. [03:11:01] But I don't know for sure. [03:13:25] Joan: ping is also clean [03:19:37] Joan: I switched to http://wikipedia.c3sl.ufpr.br/enwiki/ and im at around 200Kb/s [06:24:45] can we put dependencies in parser extensions? for example my extension should take input from the output of the SyntaxHighlighter extension [07:45:35] nischayn22: check if SyntaxHighlighter does not offer hook you could use to modify the output [08:19:40] TimStarling, are you the right/only person to ask about wikidiff2 improvements? specifically https://bugzilla.wikimedia.org/show_bug.cgi?id=13462 [08:20:22] hello DarkoNeko [08:43:21] hmm Nemo_bis *waves sleepily* [09:12:12] Beau_: I don't think it offers any such hook [09:13:51] Beau_: if it doesn't offer, is there no other way? [09:14:55] nischayn22: you can always create it :-) [09:16:29] Beau_: How to do that? Any documentation for that? [09:17:10] you can try reading https://www.mediawiki.org/wiki/Manual:Hooks [09:42:16] Nemo_bis: what about it? [09:43:25] TimStarling, https://bugzilla.wikimedia.org/buglist.cgi?list_id=107147&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&component=wikidiff2&product=MediaWiki%20extensions [09:43:48] TimStarling, and in particular the hideous https://bugzilla.wikimedia.org/show_bug.cgi?id=13462 [09:44:08] afk now [10:55:03] hi [10:55:18] can you help? I have some complications with wikimedia's etherpad... [11:00:45] Aktron: what's the problem exactly? I've rarely used the etherpad so it's doubtful that I would know the answer, but more detailed info would be required for anybody to be able to assist you :) [11:01:31] Snowolf: Yesterday, there was a board meeting of WMCZ. We logged our discussion to this etherpad: http://etherpad.wikimedia.org/rada12dubna [11:01:53] however, few hours after the meeting ended the pad is impossible to open [11:02:18] yet all other pads work normally... [11:05:21] notpeter: Aktron has some etherpad issues, can't see to access http://etherpad.wikimedia.org/rada12dubna - neither can I, and doesn't give the option "yes, create this pad" that it does if the url would be incorrect, just is stuck on loading [11:05:29] *can't seem [11:07:57] Aktron: notpeter is the one who configured etherpad or at least wrote the page for it on wikitech, so likely would be the guy to harass for this, however he's unlikely to be around at this hour [11:08:06] I'd hang around and wait for a reply, eventually [11:09:08] Snowolf: Well I have the result of the discussion already copied to an txt document. However, this is quite strange. Several members of our chapter already expressed an opinion that someone did this on purpose. [11:09:18] Snowolf: I have no problem with waiting too [11:10:31] it's good you made a copy; the contents of an etherpad are not guaranteed to be available later, it is meant to be a scratch area only [11:11:13] yes, but all other pads we use work but this one [11:11:17] Oh somebody that actually knows what they're talking about is around xD [11:11:36] apergos: it's weird, it just gets stuck on loading the url [11:11:59] because it is strange that only this one etherpad file was not possible to open :) [11:12:05] I can look at the back end in a little while and see if there's anything obviously odd [11:36:49] if I wait long enough it times out with this message: [11:36:57] The proxy server received an invalid response from an upstream server. [11:36:57] The proxy server could not handle the request GET /rada12dubna. [11:37:04] and a couple other header and footer lines [11:37:17] would one of you like to check and see if the same thing happens for you please? [11:38:37] apergos: I got the same response few minutes ago [11:39:59] ok [11:44:33] I don't see anything obvious in the logs or on the host itself [11:44:44] so it's probably best to wait for not peter to poke at it a bit [11:45:11] the request gets to the local apache and then is never completed by the etherpad process [11:45:28] that's interesting... [11:46:09] it's handed off, I can tell that because entries go into the referrer log for the ones that come from the external cz redirector [11:46:25] but after that there's nothing logged anywhere [11:47:43] whether there's something about the pad contents or the process (or some cache someplace, if etherpad has one), I don't know, that would require more than a cursory look at it [12:40:30] Afternoon guys, i think we have some database problems. I have just tried 3 times to log into en.wikipedia and been quite clearly told that my account does not exist :) [12:41:28] uh oh [12:41:34] wanna repeat that in wikipedia-operations? [12:41:39] yep [12:41:45] er [12:41:47] wikimedia-operations [12:41:49] sorry [14:20:03] hi, any progress with the etherpad issue? [14:27:18] Aktron: which issue? [14:35:34] Nikerabbit: Yesterday, there was a board meeting of WM CZ. The discussion was ongoing there: http://etherpad.wikimedia.org/rada12dubna but the log is not available since cca 23:00 CEST. All other pads are working but this one. Several members of our chapter already expressed this was done on purpose, I would like to know what is exactly going on... [14:37:44] Aktron: does "not available" mean spins forever? spinning for me (but can get other pads) [14:38:10] jeremyb: scroll up [14:38:22] jeremyb: according to (13:45:11) apergos: the request gets to the local apache and then is never completed by the etherpad process [14:38:25] there was an earlier discussion with a bit more detail [14:38:29] jeremyb: I simply got 502 error [14:38:51] according to (02:36:49 μμ) apergos: if I wait long enough it times out with this message: [14:38:52] (02:36:56 μμ) apergos: The proxy server received an invalid response from an upstream server. [14:38:52] (02:36:56 μμ) apergos: The proxy server could not handle the request GET /rada12dubna. [14:39:03] no need to paste ;) [14:39:07] for what the enduser sees [14:39:28] all right, I'll leave you to read and go back to my stuff [14:42:26] apergos: well i guess the first thing I'd do is dump the data from SQL or wherever it's stored for this pad and for a brand new pad and compare [14:42:46] I didn't want to take that on [14:42:57] sure. [14:43:00] I was happy to look at it breifly and see if it was sometihing simpler [14:43:52] oh, yay! i got a 502 too! ;) [14:44:03] wheee [14:44:10] it says error. but not what error [14:45:34] Aktron: I can tell you that it wasn't done on purpose, nobody wants to touch etherpad :) [14:47:06] Nikerabbit: ok... what do you mean by "nobody wants to touch etherpad" ? [14:47:12] WMCZ uses etherpad quite often :-) [14:47:17] Nikerabbit: well they could have done it on a middleman without having to actually touch etherpad! ;) [14:47:21] obviously, we'll have to look for a bit different tool [14:47:52] Aktron: pad.riseup.net is pretty good (and i know a few of the guys that run it). but not infailable [14:48:14] Aktron: the tool itself is fine, but ops here don't want to maintain it [14:48:16] <^demon> etherpad? Totally a fad. [14:48:35] {{fact}} [14:48:47] hmm [14:49:47] it's meant for scratch work, not as a permanent record [14:50:17] no. Permanent records are usually based on a text written in an etherpad in few hours. However, it is quite suspicious that the record didn't last for this several hours [14:53:11] Aktron: frankly, there aren't that many ops. it's hard to imagine that any of them would do this or that ct/erik/sue would tell them to [14:54:18] i guess the exception would be if there were a court order or if some agency told them to and asserted there was some imminent threat that couldn't wait for a court [14:54:30] but that is quite unlikely [14:54:37] pretty hard for a court order to show up and get handled in less than 24 hours [14:55:14] ok [14:55:32] I don't suspect anyone of having done something malicious [14:55:33] I think we have some members of our community who are quite skilled when it comes to hiding some information [14:55:35] a bug is much more likely [14:55:44] but I don't think they are ''that much'' skilled :-) [14:55:50] Aktron: (note this couldn't have been done by just any shell user. would have to be someone with root. i think, someone could confirm) [14:56:20] assuming there are no fun exploits, then yes, you can't really dig around in the db otherwise [14:56:28] but we still don't know that it's gone from the db [14:56:34] it might all be there [14:56:39] this root access is granted for only those 3 people you mentioned? [14:56:52] Aktron: no, i think none of those 3 have root [14:56:59] Aktron: those are the root's bosses [14:57:05] no, it's more like about 9 or so [14:57:09] ok [14:57:10] and those three are not any of them [14:57:18] is there a list of these people somewhere? [14:57:27] yes [14:57:30] well one of my suspicions was that it was just replaced with some text that was soooooo huge that it was a problem. but idk if there's any size limits in place [14:58:03] can I see it? [14:58:07] yes [14:58:14] Aktron: the idea that somebody with root access would intentionally mess with your etherpad is beyond unlikely :P [14:58:15] Aktron: http://orgcharts.wmflabs.org:8888/#of-unit-box-for-4f5e806d0b3d0d0f2e000009 [14:58:59] http://meta.wikimedia.org/wiki/System_administrators [14:59:04] people with root are in the top box [14:59:25] oh, i guess add domas to my list [14:59:36] and not everyone on mine has root! [14:59:52] Snowolf: And the level of paranoia in WM CZ is also beyond unlikely as well [15:00:04] :-) [15:00:10] but thanks anyway [15:00:18] Aktron: have you looked at the list? Nobody in that list would mess with your etherpad xD [15:01:31] thanks for your help anyway :-) [15:01:37] see ya [15:01:48] * apergos fumes a bit [15:01:51] grrrr [15:02:56] apergos: confess, it was you that intentionally sabotaged WMCZ's etherpad, wasn't it? :P [15:03:21] no, but if they keep it up it might be :-P [15:03:25] :D [15:03:30] <^demon> Yeah, apergos must have nothing better to do with his time than sabotage everyone else's work :p [15:03:37] shhhh [15:03:54] don't let the cat out of the bag now... [15:04:27] it's in his nick! [15:05:07] heh [15:49:48] les projets rament [15:50:58] Wikipedia is quite slow atm [15:51:39] requests sometimes take a minute or longer to respond [15:53:46] bits.wikimedia.org is v slow from the UK [15:53:52] nl-wiki slow [15:56:04] seems to be fast again [15:57:45] nope, slow again [15:58:04] jorn, Tim-away, werdna, JeLuF, or anyone with server access, can you perhaps check what's going on? [15:58:28] you want to ask that sort of thing in wikimedia-operations (sorry for the multitude of channels) [15:58:54] one of the bits lvs servers in esams was unhappy for a little bit [15:58:59] not sure beyond that... [15:59:14] okay, thanks for the info [15:59:20] sure [15:59:48] nl-wikt slow [16:00:04] noticed the same, have no server access though ^^ [16:01:55] en-wikt slow [16:02:17] Church_of_emacs: jorn != jo rm [16:02:29] but jo rm also surely has little [16:03:09] oh, okay. I tried to access a list of devs on meta-wiki, but it took to long, so I just kinda guessed ;) [16:03:41] A couple of people are reporting lags on several projects? [16:04:04] yes [16:04:22] haha [16:04:23] may be specific to europe [16:04:28] status.wikimedia.org [16:04:31] is not very helpful [16:04:49] no, Church_of_emacs, Asia too. [16:09:55] I have 1200ms lag in Asia, and performance issues with static and geoip lookup. [16:10:02] ^from status.wikimedia [16:10:58] I cannot rollback oO [16:11:50] ok, so far, I've heard complaints about fiwiki, nlwiki, enwiki, commons. Seems like a server issue. [16:13:29] dewiki as well [16:16:38] plwiki works for me, however someone else reported the same issue [16:17:09] seems by the time, the ops notice, it would have fixed itself. [16:17:14] or gotten worse :P [16:17:21] I'm hoping for an outage. [16:25:17] Speed seems pretty much back to normal for me in the UK in last few mins. [20:37:23] !log awjrichards synchronized php/extensions/MobileFrontend/MobileFrontend.body.php 'r114889' [20:37:25] Logged the message, Master [22:42:28] gn8 folks [23:11:32] I don't know if this has already been fixed [23:11:34] but [00:10:30] [[Special:Log/newusers]] create2 * Thehelpfulone * created new account User:THO (TEST): testing an IRC bug, password sent by e-mail [23:12:05] actually it's probably a bug with the IRC bot that I'm using [23:30:40] bonne nuit