[09:23:23] hello [13:18:34] what's the situation with SVN? It's not completely read-only yet, right? Are teams forced to migrate to Gerrit? [13:21:25] it's pretty much read only [14:12:40] andre__: there are still some months for that, but already done for almost all WMF teams I think [14:13:17] yeah, just found out it's July 2013 [15:17:30] Nemo_bis, is there a reason why you removed 32703 from blocking 30443? [15:17:43] just because it's WONTFIX doesn't make it less blocking. :) [15:19:09] andre__: in fact it's the opposite [15:19:35] the only valid reason to fix that was that it was needed for gender, but as the reporter said it isn't I marked it closed [15:19:43] ah! [15:19:52] (nobody had ever supported his original idea) [15:19:55] okay then. sorry :) [15:23:09] my fault: the comment by me wasn't clear enough [16:59:45] * blishchrot voiced a concern in #wikimedia when it more appropriately would have belonged here in #wikimedia-tech [16:59:49] should it be restated here or is that not necessary? [17:00:02] what was it? [17:00:15] :-D [17:00:18] it concerned the deprecation of secure.wikimedia.org [17:00:34] oh. well if you didn't get a response there, you could say it here or in [17:00:35] heh [17:00:38] wikimedia-operations :-P [17:00:45] really here is fine [17:00:52] too many fricking channels [17:01:48] there was a response, and the response was satisfactory [17:01:54] ok then [17:12:22] blishchrot, what was it about? [17:59:00] secure.wikimedia.org as it *was* had a merit in that it allowed the wikivolume and the language to be concealed within the ssl/tls [17:59:17] the wikivolume being either "wikipedia," "wiktionary," "wikiquote" or cetera [18:00:03] secure.wikimedia.org as a dns query is vague [18:00:03] whereas, for example, en.wikipedia.org or, say, ru.wiktionary.org is specific [18:00:31] the particular wikivolume and language being viewed can be known by somebody whose business it is none, even though he/she cannot see the more vital contents of the communication [18:00:47] understood? [18:02:01] unfortunately it did that by means of an awful hack and by not being at all scalable [18:02:45] it ran on one box, so you have an idea of how bad it was [18:03:07] right, that is unfortunate [18:28:41] is need-volunteer only for wikidata? https://bugzilla.wikimedia.org/describekeywords.cgi [18:38:21] Krenair: did you see the response? ^^ [18:38:37] yep, thanks jeremyb [19:37:30] ori-l: is it going to break you if I upgrade zmq libs to 2.2.0? [20:13:21] As I work on the ops blog post -- is https://wikitech.wikimedia.org/view/Incident_response still basically accurate? [20:14:20] woosters: perfect question for you I guess? [20:16:13] sumanah .. ya. Tim wrote that page [20:16:34] OK, and nothing about incident response has changed in the last year? ok [20:17:04] it is a good cheat sheet on how to approach a site incident and how to start gathering info [20:17:06] (nothing major I mean) [20:17:07] ok [20:17:32] it's a good example of the kind of capacity-building work we've done in the last 2 years [20:17:40] written in mid-2011, still helping people today [20:17:47] Reedy: fyi, i'm going to do all the change_tag / tag_summary migrations today [20:17:52] just don't want to point people to it if it's terribly inaccurate :) [20:18:01] binasher: awesome [20:21:58] woosters: so I'm looking at the Ops roadmap before I wikify it and I see that you changed it a little a few days ago, but that other than that, people had not changed it since July. So once I move it to the wiki, ok to delete it from Google Docs so people will update it onwiki instead? [20:22:23] sumanah: that page doesn't mention graphite... maybe it should [20:22:42] jeremyb: do you have the ability to edit that wiki? [20:22:46] yes [20:23:26] but maybe an actual op should be consulted? ;) [20:23:31] if you think it's a good idea to put it in the Diagnostic section, you could mention that on the talk page [20:23:51] it doesn't have a talk page at all now. not sure if that would get lost [20:24:03] sumanah .. i can lockdown google doc after that. . need not delete [20:24:25] woosters: ok, sounds good. I'm going to put it on wikitech.wikimedia.org - page title doesn't matter, we can always move it :-) [20:26:43] actually, woosters, I just had a magical idea. We can just make this particular Google Doc publicly viewable, but not publicly writeable. Is that ok? [20:27:07] woosters: I had this idea when I actually came face-to-face with the pain of importing a spreadsheet into a wikitable [20:27:14] wiki > google goc? [20:27:17] need to polish it then cos it was like a worksheet [20:27:28] oh, it's a spreadsheet... [20:27:30] eh, no need to polish, nothing secret in there [20:28:26] and it's good to let the world see our worksheets .... I can write up a summary on wikitech.wikimedia.org and point to the worksheet/spreadsheet for the minutiae and details. sound good woosters? [20:32:08] ok [20:32:22] Thanks [20:40:43] Ryan_Lane: no; would be great in fact [20:40:49] great [20:40:49] Ryan_Lane: missed your earlier message, sorry. [20:40:53] no worries [20:41:06] ori-l: salt may need fairly regular updates of zmq [20:41:13] is that going to be problematic? [20:41:38] I can make sure to warn you in advance [20:41:38] no, i'm keeping up with zmq head :) [20:41:41] ah [20:41:42] great [20:41:53] it may not be *that* up to date :) [20:42:37] salt looks pretty neat [20:42:38] * ori-l reads [20:42:44] yeah. it's pretty awesome [20:43:03] we won't be using states, but will likely use most of the rest of it [20:43:37] I'm really excited about events :) [20:43:38] ok, woosters, there is a readable version at https://docs.google.com/spreadsheet/pub?key=0AjJTXygDRPGddFlXS0hnZC04MVc4cjljT0lmZTI4TGc&output=html but not editable by the public. [20:44:12] isn't the netapp done? [22:47:01] Reedy: When I did a sync-file, I got a ton of errors: mw19: rsync: change_dir#3 "/apache/common-local" failed: No such file or directory (2) [22:47:02] mw19: rsync error: errors selecting input/output files, dirs (code 3) at main.c(643) [Receiver=3.0.9] [22:47:11] Reedy: any idea what those are about? [22:47:16] It'll be mostly the apaches notpeter is reinstalling [22:47:24] ok [22:47:37] don't worry about them :) [22:47:38] I'll just sync again later then [22:47:59] notpeter *should* run sync-common on the apaches before putting them into rotation [22:48:11] ah cool [22:49:33] I also need to sync some stuff [22:49:34] * Reedy waits [22:49:43] I totally do [22:49:47] I'm very enurotic about it [22:49:55] I do repeatedly, actually [22:49:58] just in case [22:50:13] heh [22:50:22] also, Reedy kaldari I should be done tomorrow at the latest [22:50:28] wheeee [22:50:32] really? [22:50:34] all of them? [22:50:37] yeah [22:50:41] wow [22:50:42] you rock [22:50:43] TBH, this time around, I can't say I've had to fix any afterwards ;) [22:50:44] ^^ [22:50:48] thanks :) [22:51:03] What's next? [22:51:14] it mostly just takes one week every two years. not so bad [22:53:51] well, I think it's more than week [22:53:57] a week even [22:54:25] between libsrvg, icu and whatnot [22:55:02] oh, yeah. I meant just obsessively unpooling, reinstalling, and repooling [22:55:03] eek librsvg [22:55:11] the setup is real work :) [23:21:32] * jeremyb wonders what icu is [23:22:01] Intensive Care UNIX [23:23:25] heh [23:23:37] huge Unicode library, unfortunately [23:23:43] Aw. [23:23:58] Why wouldn't they call it HUL? [23:25:12] probably this TLA was already taken at IBM when they asked [23:26:47] Hrm. [23:26:54] * marktraceur looks up HUL [23:27:44] Harvard University Library is probably the most interesting one [23:29:07] Heads-up Lounge [23:31:15] Heh, I like it [23:31:40] My perspective in all this is finding the funniest expansion for HUL in the phrase "THE HUL HAS BEEN BREACHED!" [23:31:49] I think Heads-Up Lounge is good [23:33:50] let's rename mediawiki.org villagepump to that :) [23:34:52] HUL HAS BEEN BREACHED - reminds me of WE ARE SINKING http://www.youtube.com/watch?v=yR0lWICH3rY [23:35:23] !log updated payments cluster to b5a80e04086c3a7 [23:35:29] Logged the message, Master [23:36:45] we have a mw.o village pump?