[00:00:39] Echo looks broken on wikitech for OSM: http://cl.ly/image/1V1V2O2o3D47 [00:01:08] -_- [00:01:11] * Ryan_Lane sighs [00:01:26] Ryan_Lane: Any docs on rackspacecloud? [00:01:35] I find Kennisnet_racespace, but I doubt that it is [00:01:39] nope [00:01:44] what docs would we need on it? [00:01:55] there's a console and the password is in the normal spot [00:02:13] List of instances, url to console, some generic stuff. Like https://wikitech.wikimedia.org/wiki/Linode basically [00:02:27] ah. ok [00:02:42] I'll do it [00:03:17] I have it [00:05:39] Ryan_Lane: OK. I categorised wikitech-static and created [[Rackspace]] with 1 line. Take it from here. [00:12:20] (PS1) AzaToth: handle redis errors so bot doesn't die [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 [00:12:32] YuviPanda: ↑ [00:13:50] Hm, I noticed that the databases on Labs don't include the user_properties_anonym tables [00:14:21] The Toolserver ones seem to have that? [00:14:43] Krinkle: weird. look at echo now [00:15:05] Krinkle: it looks like old messages have [[[No page]]], but new messages have a proper link [00:16:12] I created a new public/private RSA key pair. [00:16:21] And I uploaded my public key to wikitech.wikimedia.org. [00:16:29] Now I'm trying to SSH in to bastion.wmflabs.org and it's failing. [00:16:29] you also need to upload it to gerrit [00:16:31] ah [00:16:34] Both? [00:16:35] Elsie: how long ago did you do it [00:16:39] for bastion access, no [00:16:39] A few minutes. [00:16:49] let me check something [00:17:11] what's your username/shell account name? [00:17:17] mzmcbride [00:17:32] (CR) Ori.livneh: "(1 comment)" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 (owner: AzaToth) [00:17:35] seems your key is ok [00:18:00] Oh, now it's working. [00:18:12] You blessed it. [00:18:12] twkozlowski: Hi [00:18:15] it can take up to 5 minutes [00:18:17] Hi Krinkle [00:18:25] That was probably it. [00:18:26] twkozlowski: Those tables are a toolserver invention, they do not exist in mediawiki proper [00:18:33] Once I'm in bastion, how do I access the SQL servers? [00:18:41] andrewbogott: ^^ [00:18:43] I'm on bastion1 currently. [00:18:54] Krinkle: I see... [00:18:55] Krinkle: user_properties does. [00:18:57] ori-l: hell knows, I just know it failed to parse the JSON, and that redis had thrown a error, and redis examples explicitly looks at the "err" thingi [00:19:01] Krinkle: wikitech-static runs a static offsite version of wikitech [00:19:06] twkozlowski: They are on the list for tool labs to create at some point. Though I haven't had a confirmation from Coren. Last I checked I understand there were some doubts about whether they should be public. [00:19:06] I'll update the page :) [00:19:12] user_properties_anonym is a view. [00:19:19] A specialized view, rather. [00:19:21] on toolserver, yes. [00:19:22] They're all views... [00:19:35] throw callback_err; [00:19:35] ^ [00:19:35] TypeError: Cannot read property '1' of undefined [00:19:35] at Command.callback (/data/project/lolrrit-wm/lolrrit-wm/src/relay.js:80:43) [00:19:42] ori-l: ↑ [00:19:53] twkozlowski: How do you access the SQL servers from bastion? [00:19:54] bahahaha. there's a wikitech page and a wikitech.wikimedia.org pahe [00:19:55] Krinkle: Well, they can be accessed on Toolserver, so they're already kind of public. [00:19:57] *page [00:20:02] * Ryan_Lane deletes [00:20:13] Elsie: You have to be added to the Tools group, I've been told. [00:20:27] ori-l: anyway, it shouldn't theiretically be possible to interfer [00:20:28] andrewbogott kindly added me there a couple of minutes ago. [00:20:46] if we can read the "err" variable, shouldn't affect if error callback is called [00:20:48] Oh. [00:20:51] twkozlowski: I know, but a past violation is no excuse for a future one. Everyting is being re-evaluated. [00:21:05] twkozlowski: Anyway, I'm just a messenger in this. [00:21:09] Krinkle: Yes, I understand. [00:21:18] twkozlowski: I'll get your stats in a second. [00:21:37] AzaToth: that's pretty clear, tho [00:21:40] How do I list the various groups? [00:21:41] var message = JSON.parse(reply[1]); [00:21:44] that's the cause of the error [00:21:46] Elsie: would you like to be added to tools? [00:21:48] I'll likely need access to a few. [00:21:52] Ryan_Lane: If you could, that'd be great. :-) [00:21:55] twkozlowski: I don't think this will be a problem, it just might take a while for them to get a similar kind of view running. Especially given that this one also contained some extra features (not just partial table but also modified values and even an extra column from another table) [00:22:01] I may need access to some others as well, I'm not sure. [00:22:04] ori-l: yes, but I assume the real error is in err [00:22:16] your wikitech username is: Mzmcbride? [00:22:30] twkozlowski: I'm personally also blocked on user_properties_anon, that and the toolserver.* tables such as namespaces and wikis. [00:22:41] Ryan_Lane: MZMcBride or mzmcbride [00:22:43] ori-l: /data/project/lolrrit-wm/lolrrit-wm/node_modules/redis/index.js:139 [00:22:43] throw callback_err; [00:22:48] MediaWiki name v. shell name [00:23:05] Krinkle: thank you kind sir [00:23:05] Elsie: ah. someone had already added you [00:23:16] Heh. [00:23:19] how quick is that? :D [00:23:25] ori-l: I first thought only to handle the JSON parse error, but of felt like trying to only patch something up, instead of taking care of the _real_ error [00:23:26] How do I go from bastion1 to an SQL server, then? :-) [00:23:36] Elsie: don't login to bastion, to begin with [00:23:40] Oh, shit. [00:23:46] login to tools-login.wmflabs.org [00:23:47] I just set up an alias for that. [00:23:58] I should SSH in to tools-login.wmflabs.org always? [00:24:02] you can also login to tools-login from bastion [00:24:03] if you want [00:24:08] but it's not necessary [00:24:14] Elsie: for tools, yes [00:24:19] for other labs projects, use bastion [00:24:21] Okay, got it. [00:24:25] How do I see which groups I'm in? [00:24:29] id [00:24:29] Or that someone else is in? [00:24:37] Awesome. [00:24:54] do: id laner [00:24:55] for instance [00:25:00] and prepare to cry [00:25:05] You're in a lot of groups! [00:25:25] Okay, cool. [00:25:28] I need to purge myself from most [00:25:38] So from bastion1, I can just SSH into tools-login. [00:25:45] Assuming that's the hostname. [00:25:55] Not so much. [00:27:17] you need to forward an ssh agent if you want to [00:27:20] or use proxy command [00:27:30] it's easier to use tools-login.wmflabs.org directly [00:27:51] Okay, I'm in to tools-login. [00:27:52] I use bastion, but I forward an agent [00:27:56] That's quite the ASCII art... [00:27:59] heh [00:28:06] thank Coren for that one ;) [00:28:08] * Elsie .hushlogins some more. ;-) [00:28:50] > The last Puppet run was at Fri Jul 26 00:20:23 UTC 2013 (7 minutes ago). [00:29:03] Well, that's a real lost opportunity to make a puppet freshness joke, isn't it. [00:29:21] nah, it's not critical. [00:29:42] So I can get into tools-login directly from the outside, because it's been special-cased. [00:29:53] For the other hosts, I'll have to set up a proxy or an SSH-agent forward. [00:30:23] Oh, gotta touch .hushlogin and .suppresstips. [00:30:40] Nope, still getting noise when logging in... [00:31:37] MariaDB [enwiki_p]> select count(*) from revision; [00:31:39] * Elsie grins. [00:32:27] ori-l: it's possibly redis is generating a error, and it seems it's not pushed into the global error callback [00:32:39] Elsie: proxy-command [00:32:44] Coren: When you have a minute, is there a way to disable the login message for tools-login? I tried touching .hushlogin and .suppresstips, but I'm still getting something about I'm not sure. [00:32:49] not a proxy ;) [00:32:53] AzaToth: yeah, I think the patch is worthwhile. I've just been experimenting with BLPOP locally to verify the semantics [00:33:09] Ryan_Lane: Heh, I skimmed that doc page, but it made my head hurt and my eyes glazed over a bit. [00:33:16] Elsie: Not completely. Ryan insists on the presence of the /etc/issue and that can't be suppressed. :-) [00:33:24] Elsie: sounds like a seizure [00:33:38] ori-l: I tried restarting. [00:34:11] mzmcbride@tools-login:~$ cat /etc/issue [00:34:11] Ubuntu 12.04.2 LTS \n \l [00:34:12] That's not quite what I'm getting. [00:34:24] mzmcbride@gonzo:~$ tools [00:34:24] If you are having access problems, please see: https://wikitech.wikimedia.org/wiki/Access#Accessing_public_and_private_instances [00:34:38] Surely there's a way for me to disable that... [00:34:40] Elsie: the logo thingi is in /etc/motd [00:34:49] AzaToth: Right, I killed that with .hushlogin. [00:34:52] (CR) Ori.livneh: [C: 1] handle redis errors so bot doesn't die [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 (owner: AzaToth) [00:34:56] And I killed the tips with .suppresstips. [00:35:08] I've just got to kill this "If you are having access problems..." bit. [00:35:12] And then it'll be quiet. [00:35:48] ori-l: I assume it's fine for grrrit-wm to die a couple more times so YuviPanda might +2 it himself [00:36:22] AzaToth: I'd +2 it if it didn't depend on the package.json patch for no discernable reason [00:36:34] Coren: Looks like ssh -q will do it. :D [00:36:38] ori-l: didn't feel to rebase ツ [00:36:49] Elsie: that's /etc/ssh/sshd_banner [00:37:14] Indeed. [00:37:19] a.k.a. your fubar [00:37:27] AzaToth: ssh -q killed it. :-) [00:37:46] (CR) Krinkle: "(1 comment)" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76017 (owner: AzaToth) [00:37:52] The "Q" stands for "leave me the hell alone." ;-) [00:37:57] Elsie: Strictly speaking, you didn't suppress you being /sent/ the message, you just told your client to not show it. :-) [00:38:08] (PS2) AzaToth: handle redis errors so bot doesn't die [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 [00:38:15] ori-l: better? [00:38:24] Coren: True enough. But at least it's gone. [00:38:36] I cherrypicked on master [00:38:39] I like to be able to SSH in without noise. [00:39:11] twkozlowski: Okay, so the number you're looking for... [00:39:45] Krinkle: someone said "ONLY TABS!!!!!1111elevencos(0)" before I can remember [00:39:45] is 73. [00:39:45] Really? [00:39:50] That seems low. [00:39:53] Nah, I didn't want to say '42'. [00:40:11] Krinkle: :-P [00:40:12] That'd be too obvious. [00:40:17] (CR) Krinkle: "(1 comment)" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 (owner: AzaToth) [00:40:33] AzaToth: yes, so use tabs. But not for 1 line in a file of spaces. [00:40:54] it's fine to convert the file [00:40:55] Krinkle: I forgot to check that file [00:41:14] * Krinkle mumbles that an editor should detect this on open. Sublime Text does this. [00:41:41] (PS3) AzaToth: handle redis errors so bot doesn't die [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 [00:42:43] (CR) Ori.livneh: [C: 2] "I'd ordinarily wait for Yuvi to review, but we might as well use the time to collect log data." [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 (owner: AzaToth) [00:42:47] Krinkle: well, it would be possible [00:44:53] git@github.com:aclindsa/detectindent.git [00:45:20] twkozlowski: I'm not sure the Toolserver has the data you want either. [00:47:05] Elsie: this makes me sad. Is it too early or is there a different reason? [00:47:26] twkozlowski: You understand how MySQL views work? [00:47:35] I'm not sure the view has been configured to expose this data. [00:47:39] ori-l: you restart it? [00:47:43] I'm still looking. [00:47:58] Table scans are slow, though. [00:48:01] Esp. on the Toolserver.. [00:48:17] nope [00:48:19] My revision count(*) on enwiki_p on Labs is still running. [00:48:26] So much for putting things in memory! [00:51:06] This shit is sloooooooow. [00:51:35] count(*) is pain on mysql. [00:51:44] Elsie: login is slow [00:51:55] Elsie: I hope you are NOT using login to query db [00:52:12] AzaToth: What am I supposed to be using? [00:52:17] tools-dev [00:52:22] Really? [00:52:32] What's the difference? [00:52:38] I can't login [00:52:39] That doesn't really matter for an interactive SQL query. [00:52:52] I'm stuck at If you are having access problems, please see: https://wikitech.wikimedia.org/wiki/Access#Accessing_public_and_private_instances [00:52:54] I assume the SQL server is independent of the login host(s). [00:53:07] k [00:53:10] AzaToth: *sigh* NFS stalled. It'll come back in a little bit (usually less than a minute) [00:53:28] k [00:53:29] > select distinct up_property from user_properties_anonym; [00:53:35] I'm running that on Toolserver. [00:53:42] And it's taking one (1) forever. [00:53:46] I still have issues with the controller; it'll take an outage to switch hardware to isolate the issue. [00:53:56] I see [00:54:09] In the meantime, the stalls are relatively infrequent and last less than 2 minutes as a rule. [00:54:31] I just logged in to tools-login again. [00:54:33] It seems fine. [00:54:34] http://ganglia.wikimedia.org/latest/graph.php?r=hour&z=xlarge&h=labstore3.pmtpa.wmnet&m=cpu_report&s=descending&mc=2&g=cpu_report&c=Labs+NFS+cluster+pmtpa [00:54:46] The big orange blob is the stall. [00:55:22] Interesting... MariaDB treats views differently. [00:55:28] It shows the fields, but just blanks them. [00:55:32] Rather than hiding them completely. [00:55:36] user_password, etc. [00:56:25] That's not MariaDB but my decision when creating the view to keep the schema identical to production's. [00:56:42] ori-l: I restarted it now [00:56:49] There's no performance impact? [00:56:58] I thought views were sensitive to that kind of thing. [00:57:12] Elsie none that are measurable. [00:57:49] I don't have much faith that either of my queries will ever finish. [00:57:52] :-( [00:57:52] There's a performance impact for /conditionally/ redacted views (i.e.: revision suppresion) but alternative views are provided to keep indexes and remove the entire rows instead. [00:58:06] suppression [00:58:12] * Elsie nods. [00:58:50] For instance, if you have a where clause on rev_user or rev_user_text you should use the revision_userindex table which is nominally the same but has those indices usable (at the cost of not having the offending rows at all which isn't an issue if you where against them anyways) [00:59:30] But mysql is known to be idiotic when doing a count(*) as it almost always will do a full table scane. [00:59:32] scan* [00:59:35] Right, right. [00:59:45] The Toolserver had that issue with the logging table. [00:59:54] There was logging and logging_ts_alternate or something. [01:00:00] Same deal; also there is logging_userindex for the same reason. [01:01:02] I'm glad all 12 AFT tables are exposed, but not user_properties. ;-) [01:01:19] And 10 EducationProgram tables. [01:01:22] Lord... [01:01:46] What's user_old? [01:02:15] A very old version of the user table. [01:02:15] povwatch_log... [01:02:26] Some of these tables shouldn't exist... [01:02:45] page_broken, heh. [01:03:17] Yeah, I erred on the side of inclusion for things that did not contain private information. :-) [01:03:33] These are all in master, though? [01:03:36] * Coren nods. [01:03:50] Yeah... PovWatch hasn't been installed anywhere in like half a decade, I don't think. [01:04:12] AFAICT, enwiki is the only db with it too. [01:04:24] I don't think it was ever even installed there. [01:04:29] It was on testwiki. [01:04:43] Possibly valuable, possibly amusing, definitely historical. :-) [01:05:11] It's on testwiki_p as well. [01:06:09] geo_killlist... [01:44:33] twkozlowski: http://p.defau.lt/?GicnWilTVq0Lzof2YF4jvA [01:46:12] Unrelated: http://p.defau.lt/?zLkJsvIBHpOwuZjmcIpc_w [01:46:19] MariaDB [enwiki_p]> select count(*) from revision; [01:46:19] +-----------+ [01:46:19] | count(*) | [01:46:19] +-----------+ [01:46:19] | 522545105 | [01:46:21] +-----------+ [01:46:24] 1 row in set (46 min 19.92 sec) [04:08:12] Elsie: That's actually not so bad for a full table scan of revision. [06:47:59] (CR) Yuvipanda: [C: 2 V: 2] "TY!" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/75908 (owner: AzaToth) [06:49:01] (CR) Yuvipanda: "Hmm, I'm already bundling the node_modules with this. I suppose I don't need to if we have this?" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76017 (owner: AzaToth) [07:17:50] (CR) Yuvipanda: [C: -1] "(2 comments)" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76016 (owner: AzaToth) [07:20:25] (CR) Legoktm: "#wikimedia-dev and other channels have +c set, so an op will need to disable those before we can see the colors." [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76016 (owner: AzaToth) [08:23:59] !ping [08:23:59] pong [09:16:55] [bz] (8PATCH_TO_REVIEW - created by: 2Antoine "hashar" Musso, priority: 4Low - 6enhancement) [Bug 41285] [OPS] foreachwiki on beta use all.dblist instead of all-wmflabs.dblist - https://bugzilla.wikimedia.org/show_bug.cgi?id=41285 [09:21:14] (PS2) AzaToth: adding package.json for easier npm install [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76017 [09:22:18] petan, ? [09:22:23] hm [09:22:26] [09:22:33] SELECT COUNT(*) AS count FROM logging_userindex WHERE `log_timestamp` > 20130126000000 [09:22:34] -> ; [09:22:34] +---------+ [09:22:34] | count | [09:22:34] +---------+ [09:22:34] | 3046171 | [09:22:36] +---------+ [09:22:38] 1 row in set (50.28 sec) [09:22:42] ? [09:22:59] you know I have no access to production db's [09:23:01] neither replicas [09:23:06] Oh right. [09:23:06] so I can't fix whatever is wrong there [09:23:28] (PS2) AzaToth: adding color filter for the IRC output [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76016 [09:23:31] petan, can you blow an airhorn at Coren to wake him up then? [09:23:46] no, is that actually so urgent? [09:24:05] No. I just like to ping him. :D [09:24:41] YuviPanda: done [09:24:57] AzaToth: shouldn't node_modules be rm -d if we start using this? [09:25:37] yes [09:25:56] didn't want to remove it before you said it was ok [09:25:56] AzaToth: can you do that in the same patch? [09:25:56] yea [09:26:20] AzaToth: also where does the git head sha comes from? [09:28:53] which? [09:29:04] AzaToth: the one in package.json [09:29:07] ah, it was npm init who added it [09:29:50] should probably get rid of that too :) [09:33:43] (PS3) AzaToth: adding package.json and remove convenience node_modules [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76017 [09:34:08] (PS4) AzaToth: adding package.json and remove convenience node_modules [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76017 [09:34:16] YuviPanda: done [09:34:33] AzaToth: I'm happy to merge. Only thing confusing me is the gitHead param in package.json [09:35:41] removed it [09:35:51] forgot to add -p it in PS3 [09:35:57] thus PS4 [09:36:02] :) [09:36:03] merging [09:36:33] (CR) Yuvipanda: [C: 2 V: 2] adding package.json and remove convenience node_modules [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76017 (owner: AzaToth) [09:36:54] (PS3) AzaToth: adding color filter for the IRC output [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76016 [09:37:02] (PS4) AzaToth: handle redis errors so bot doesn't die [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 [09:37:11] rebased them [09:37:23] YuviPanda: https://gerrit.wikimedia.org/r/#/c/76049/ [09:37:40] YuviPanda: Ori forgot to V:2 it so it never got merged [09:37:54] YuviPanda: but it should fix the grrrit crash [09:37:58] (CR) Yuvipanda: [C: 2 V: 2] "Thanks :)" [labs/tools/grrrit] - https://gerrit.wikimedia.org/r/76049 (owner: AzaToth) [09:37:58] done [09:38:07] AzaToth: want to pull and restart? :) [09:38:16] not merge the colors first? ツ [09:38:35] I'm still a little ambivalent about the colors :P [09:38:40] heh [09:38:41] AzaToth: what happens to colors in channels that have them off? [09:38:51] they will be uncolored [09:39:05] no junk? [09:39:08] no junk [09:39:19] the server removes the colors [09:39:42] but true, I've not tested that code at all ヾ [09:40:41] AzaToth: let's merge this for now, and then run live patch on toollabs for colors/ [09:40:43] and see how it goes? [09:41:43] ok, I'm updating it now [09:42:56] AzaToth: is this with or without the color patch? [09:43:06] without [09:43:08] ok [09:43:12] it's gerrit master [09:43:15] alright [09:43:18] origin master* [09:43:21] or whatever [09:43:25] it's the merged shit [09:43:42] with new clean node_modules [09:43:48] :) [09:43:49] nice [09:44:21] YuviPanda: http://paste.debian.net/18715/ [09:44:45] hmm [09:44:57] AzaToth: hmm, i think node-irc by itself supports colors [09:44:59] the irc-colors I forgot to remove from package.json [09:45:11] that's okay, I guess [09:45:17] irc-colors are a helper [09:45:26] yeah, easier to integrate into swig [09:45:35] i.e. "c.blold.red.underline("hello")" [09:45:45] wasn't that easy [09:45:51] easier, yeah :) [09:46:10] I think my code should work [09:46:11] AzaToth: want to apply the colors patch on tools and run it? [09:46:29] dunno how that works [09:46:32] git fetch https://yuvipanda@gerrit.wikimedia.org/r/labs/tools/grrrit refs/changes/16/76016/3 && git checkout FETCH_HEAD [09:46:34] err [09:46:37] AzaToth: let me do that [09:46:46] you mean the "live" bot right? [09:47:00] or is "tools" somewhere else? [09:47:06] done [09:47:08] ok [09:47:51] now to test it [09:47:51] on it [09:47:52] ok, it failed [09:48:05] AzaToth: let me get it back to master [09:48:21] done [09:48:28] ツ [09:49:11] AzaToth: you can test it by commenting out the irc.say line, and replacing it wtih console.log :) [09:49:27] Probably should have a duplicate bot for testing. :-) [09:49:37] grrrrit-wm [09:49:40] heh [09:49:54] Elsie: I do for local testing, but it needs the stream events rights on gerrit to be able to setup locally [09:50:19] config_test.yaml or something? [09:50:27] And pass that as a command-line parameter. [09:50:34] Or something. [09:50:46] you still can't test without stream events rights [09:51:04] Are those bound somehow? [09:51:29] Elsie: gerrit stream events gives you a realtime stream of changes on gerrit as they happen [09:51:44] so there's gerrit-to-redis (my script), that takes that, puts that in redis for multiple other scripts to use [09:51:51] grrrit-wm is one such script. [09:52:08] Right. I'm suggesting a second such script. [09:52:40] right. it should be easier to test. [09:52:45] :-) [09:53:26] It's just that it's in quite a few channels now, so the noise of join/quit gets amplified. [09:53:33] right. [10:09:35] Change on 12mediawiki a page Wikimedia Labs/Tool Labs/Migration of Toolserver tools was modified, changed by Silke WMDE link https://www.mediawiki.org/w/index.php?diff=747681 edit summary: /* Where's the bug tracker? */ updated description of bugzilla components [10:14:02] [bz] (8NEW - created by: 2silke.meyer, priority: 4Unprioritized - 6major) [Bug 51890] Bots compenent in bugzilla is obsolete - https://bugzilla.wikimedia.org/show_bug.cgi?id=51890 [10:18:37] [bz] (8NEW - created by: 2spage, priority: 4Unprioritized - 6normal) [Bug 51580] configure beta labs for SUL2 - https://bugzilla.wikimedia.org/show_bug.cgi?id=51580 [10:21:07] Change on 12mediawiki a page Wikimedia Labs/Tool Labs/Roadmap en was modified, changed by Silke WMDE link https://www.mediawiki.org/w/index.php?diff=747683 edit summary: /* Status of Tool Labs (as of May 22nd, 2013) */ updated "bots" to "tools-beta" [10:22:10] Change on 12mediawiki a page Wikimedia Labs/Tool Labs/Roadmap en was modified, changed by Silke WMDE link https://www.mediawiki.org/w/index.php?diff=747685 edit summary: /* Overview of available features in Tool Labs */ updated "bots" to "tools-beta" [10:23:13] [bz] (8RESOLVED - created by: 2Antoine "hashar" Musso, priority: 4Normal - 6enhancement) [Bug 45786] search: craft a fake InitialiseSettings.php for lucene-search-2 - https://bugzilla.wikimedia.org/show_bug.cgi?id=45786 [10:24:55] Change on 12mediawiki a page Wikimedia Labs/Tool Labs/Roadmap de was modified, changed by Silke WMDE link https://www.mediawiki.org/w/index.php?diff=747687 edit summary: /* Status von Tool Labs (Stand: 22.05.2013) */ updated "bots" to "tools-beta" [10:44:08]