[00:00:05] <bd808>	 acutually a 4th option would be to force an l10nupdate and then do the sync-dir and manual cdb rebuild manually
[00:00:30] <bd808>	 but just doing a full scap would be about as fast I think
[00:01:17] <bd808>	 It would be really swell if the releng guys could figure out why the sync-dir is failing so we could fix it
[00:01:40] <bd808>	 all my attempts have been shots in the dark and so far unsuccesful
[00:02:32] <bd808>	 the output from the last time Mukunda did a manual run still looked like ssh-key problems but I'm really not sure why
[00:57:18] <Deskana>	 bd808: OAuth backlog grooming party tomorrow afternoon? I've not got any meetings.
[00:57:31] <bd808>	 sure!
[00:58:02] <bd808>	 I was just starting to move all the closed tasks into a hidden column
[00:58:29] <Deskana>	 bd808: Yeah, that "feature" is pretty annoying.
[00:59:01] <bd808>	 bulk column move would be nice
[01:00:06] <robla>	 bd808: I have a hack for that
[01:00:27] * robla looks up his docs
[01:00:35] <bd808>	 oh? I just drug 74 issues from one column to another
[01:00:43] <bd808>	 fun RSI work
[01:01:06] <robla>	 https://www.mediawiki.org/wiki/User:RobLa-WMF/PhabWorkboardCompare
[01:01:19] <robla>	 so....wait, nevermind
[01:01:36] <robla>	 that doesn't buy you actually changing the state
[01:01:59] <bd808>	 yeah. closed ones are at least easy as you can search for that
[01:02:03] <robla>	 ugh, yeah, RSI is the only solution for now until they at least add an API for workboard manipulation
[01:02:14] * bd808 will not hold his breath
[01:02:34] <bd808>	 probably some js ninja could figure it out
[01:03:09] <bd808>	 make an epic greasmonkey script to add all the crap they left out of the UX
[01:03:26] <bd808>	 But hey, it's not bugzilla!!!
[01:03:40] <robla>	 bugzilla workboards were great!
[01:05:58] <ori>	 hey Krinkle, got a second?
[01:06:40] <Deskana>	 bd808: Invite sent!
[01:40:41] <wikibugs>	 6MediaWiki-Core-Team, 10MediaWiki-extensions-OAuth, 7Epic: Support a nice sso experience with MediaWiki's OAuth - https://phabricator.wikimedia.org/T86869#1094612 (10bd808)
[01:54:13] <Krinkle>	 ori: Yo
[01:55:34] <ori>	 Krinkle: the insertion of dynamic style tags by resourceloader is suboptimal, somehow. On both enwiki and my dev wiki, mediawiki.searchSuggest gets its own <style> tag, but I don't see why it can't go with the previous modules' CSS buffer
[01:55:51] <ori>	 it's not loaded asyncronously via mw.loader.using() afaict
[01:55:52] <Krinkle>	 ori: There's a very good reason for that
[01:56:16] * ori waits for it
[01:56:21] <Krinkle>	 ori: Appending text nodes to a stylesheets requires the stylesheets to be re-parsed
[01:56:42] <Krinkle>	 layout, redraw, all that shit. Cascading and interacting with previous and next stylesheets in the document.
[01:57:02] <Krinkle>	 We've been there, unfortunately even done it for a few months before we realised how bad it was
[01:57:09] <ori>	 no, no
[01:57:13] <ori>	 that I understand
[01:57:20] <Krinkle>	 However for synchronously loaded stylesheets in the same batch, we can concat them
[01:57:22] <Krinkle>	 And afaik we do do that
[01:57:30] <Krinkle>	 There's a cssBuffer debounce I wrote for that
[01:57:54] <ori>	 right, so that's what is puzzling me: mediawiki.searchSuggest is in the same batch
[01:58:03] <ori>	 and there is no @import preventing it from being eligible for concatenation
[01:58:13] <ori>	 but somehow the setTimeout() / cssBuffer debounce isn't working for it
[01:59:25] <Krinkle>	 Hm.. yeah.
[01:59:38] <Krinkle>	 the mmv and echo-overlay are concatenated to the mwsuggest one afterwards
[02:00:30] <Krinkle>	 ori: Actually, they are in a separate request
[02:01:03] <Krinkle>	 enwiki main page
[02:01:43] <Krinkle>	 https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules= ext.centralNotice .. ext.eventLogging .. ext.visualEditor.viewPageTarget.init .. mediawiki.page.startup%7Cmmv.base%2Chead%7Cskins.vector.compactPersonalBar.defaultTracking%2Cschema%2CtrackClick%7Cskins.vector.js%7Cuser.defaults
[02:02:18] <Krinkle>	 and later
[02:02:18] <Krinkle>	 https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.echo.base%2Coverlay .. mediawiki.cookie%2CsearchSuggest .. mmv.bootstrap
[02:02:50] <Krinkle>	 top queue / bottom queue
[02:03:00] <Krinkle>	 I imagine there's more than 40ms between that
[02:13:05] <Krinkle>	 ori: Thx, you helped me find this bug https://gerrit.wikimedia.org/r/#/c/194787/
[02:29:46] <ori>	 Krinkle: interestingggg
[02:30:45] <ori>	 I don't think it's top queue / bottom queue, because there is a separate tag for ext.visualEditor.viewPageTarget.init on my dev instance, plus another one for ext.cite and a few other things, and a third one for mediawiki.Search
[02:30:51] <ori>	 searchSuggest
[02:30:58] <ori>	 gotta head home but will look at your patch later
[03:18:36] <wikibugs>	 6MediaWiki-Core-Team, 10MediaWiki-Configuration, 5Patch-For-Review: doMaintenance.php creates ConfigFactory::getDefaultInstance() before Setup.php is run - https://phabricator.wikimedia.org/T90680#1094750 (10Legoktm) 5Open>3Resolved
[05:27:31] <wikibugs>	 6MediaWiki-Core-Team, 7HHVM: HHVM with FastCGI does not support streaming output - https://phabricator.wikimedia.org/T91468#1094831 (10tstarling)
[05:30:34] <wikibugs>	 6MediaWiki-Core-Team, 7HHVM: HHVM with FastCGI does not support streaming output - https://phabricator.wikimedia.org/T91468#1094837 (10tstarling) This goes into the too-hard basket for now. Maybe after the HHVM devs are back online after their "infra summit", we can talk about strategies.
[05:32:16] <wikibugs>	 6MediaWiki-Core-Team, 10OCG-General-or-Unknown, 7HHVM, 7Wikimedia-log-errors: OOM reported at SpecialPage.php:534 due to large output from Special:Book - https://phabricator.wikimedia.org/T89918#1094840 (10tstarling) We could increase the memory limit, as a workaround.
[05:37:40] <wikibugs>	 6MediaWiki-Core-Team, 10OCG-General-or-Unknown, 7HHVM, 7Wikimedia-log-errors: OOM reported at SpecialPage.php:534 due to large output from Special:Book - https://phabricator.wikimedia.org/T89918#1094848 (10jeremyb) Could we predict ahead of time if a PDF will be too big and give a relevant error message in...
[09:39:37] <wikibugs>	 6MediaWiki-Core-Team, 10SUL-Finalization, 5Patch-For-Review: Update CentralAuthUser::chooseHomeWiki() - https://phabricator.wikimedia.org/T91703#1095178 (10Aklapper) p:5Triage>3High
[16:10:37] <wikibugs>	 6MediaWiki-Core-Team, 10Vector: Restore a <span> inside <h1> - https://phabricator.wikimedia.org/T91758#1095652 (10Amire80)
[16:15:58] <wikibugs>	 6MediaWiki-Core-Team, 7HHVM, 7Upstream: HHVM with FastCGI does not support streaming output - https://phabricator.wikimedia.org/T91468#1095659 (10bd808)
[16:35:50] <wikibugs>	 6MediaWiki-Core-Team: Ran out of captcha images - https://phabricator.wikimedia.org/T91760#1095696 (10matthiasmullie) 3NEW
[16:36:08] <wikibugs>	 6MediaWiki-Core-Team, 10Vector: Restore a <span> inside <h1> - https://phabricator.wikimedia.org/T91758#1095704 (10Jdforrester-WMF) 5Open>3declined a:3Jdforrester-WMF I don't think going through the churn is a worthwhile expenditure of peoples' time. `wikitech-ambassadors` notices won't get fixes faster...
[16:40:21] <wikibugs>	 6MediaWiki-Core-Team: Ran out of captcha images - https://phabricator.wikimedia.org/T91760#1095713 (10matthiasmullie) Instructions seem to be here: https://wikitech.wikimedia.org/wiki/Generating_CAPTCHAs
[16:42:42] <wikibugs>	 6MediaWiki-Core-Team, 10Analytics, 10Wikimedia-Site-requests: Ran out of captcha images - https://phabricator.wikimedia.org/T91760#1095716 (10Nemo_bis) Note, captchas were made a lot harder by df4806c64c48c2cd2cee063611b3193a47c069c8; side effects of new generation FancyCaptcha images have yet to be assessed.
[16:49:21] <greg-g>	 manybubbles: you'll be happy to know I finally hung up that powers of 2 printout from the computer history museum
[16:49:30] <manybubbles>	 good man
[16:49:32] <greg-g>	 it's in between robla and dan duvall's desk
[19:00:50] <AaronSchulz>	 ^d: https://gerrit.wikimedia.org/r/#/c/194582/
[19:09:19] <AaronSchulz>	 legoktm: https://gerrit.wikimedia.org/r/#/c/194394/
[19:09:53] * legoktm looks
[19:14:23] <legoktm>	 AaronSchulz: how is the enqueue job going to be used? will things submitting into the job queue be aware of it? or is it a configuration detail?
[19:20:59] <wikibugs>	 6MediaWiki-Core-Team, 10MediaWiki-extensions-OAuth, 7Epic: Support a nice sso experience with MediaWiki's OAuth - https://phabricator.wikimedia.org/T86869#1096539 (10bd808)
[19:34:37] <wikibugs>	 6MediaWiki-Core-Team, 6Engineering-Community, 6Multimedia, 6Parsoid-Team, and 3 others: Prepare Platform April 2015 quarterly review presentation - https://phabricator.wikimedia.org/T91803#1096558 (10bd808) 3NEW a:3bd808
[19:35:43] <legoktm>	 csteipp: could I get a +2 on https://gerrit.wikimedia.org/r/#/c/194709/ ?
[19:51:16] <AaronSchulz>	 legoktm: it will be for jobs enqueued on page views (like the cascade protection one). The calling code to enqueue it will change a little.
[19:52:03] <AaronSchulz>	 the rest is just config details (e.g. the queue always being dc-local with dc-local runners)
[19:52:36] * AaronSchulz will make the next patches today hopefully
[20:12:26] <wikibugs>	 6MediaWiki-Core-Team, 6Engineering-Community, 6Multimedia, 6Parsoid-Team, and 3 others: Prepare Platform April 2015 quarterly review presentation - https://phabricator.wikimedia.org/T91803#1096676 (10bd808)
[21:02:32] <wikibugs>	 6MediaWiki-Core-Team: Wikidata Query: Secure BlazeGraph's SPARQL - https://phabricator.wikimedia.org/T91812#1096772 (10Manybubbles) 3NEW
[21:02:38] <wikibugs>	 6MediaWiki-Core-Team: Wikidata Query: Secure BlazeGraph's SPARQL - https://phabricator.wikimedia.org/T91812#1096782 (10Manybubbles) p:5Triage>3Normal
[21:04:23] <wikibugs>	 6MediaWiki-Core-Team: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096785 (10Manybubbles) 3NEW
[21:04:31] <wikibugs>	 6MediaWiki-Core-Team: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096785 (10Manybubbles) a:3Manybubbles
[21:04:57] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Wikidata Query: Secure BlazeGraph's SPARQL - https://phabricator.wikimedia.org/T91812#1096793 (10Manybubbles)
[21:05:10] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096785 (10Manybubbles)
[21:07:46] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: Audit cache usage to see what can be DC-local and what needs cross-DC purges - https://phabricator.wikimedia.org/T91815#1096804 (10aaron) 3NEW a:3aaron
[21:09:23] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: Add code to enable setting sticky DC cookies for POST requests - https://phabricator.wikimedia.org/T91816#1096811 (10aaron) 3NEW a:3aaron
[21:10:35] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Wikidata Query: Create readonly SPARQL  - https://phabricator.wikimedia.org/T91817#1096823 (10Manybubbles) 3NEW
[21:15:33] <AaronSchulz>	 ^d: https://gerrit.wikimedia.org/r/#/c/194589/3
[21:30:44] <wikibugs>	 6MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown: Augment user_touched with an in-memory field - https://phabricator.wikimedia.org/T91279#1096848 (10aaron) CentralAuth and friends hit this path a fair amount but not all the time, this is a nice-to-have.
[21:31:11] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: MediaWiki multi-datacenter investigation and work - https://phabricator.wikimedia.org/T88445#1096850 (10aaron)
[21:31:11] <wikibugs>	 6MediaWiki-Core-Team, 5Patch-For-Review: Remove cache anti-dependencies - https://phabricator.wikimedia.org/T89184#1096849 (10aaron) 5Open>3Resolved
[21:31:29] <wikibugs>	 6MediaWiki-Core-Team, 5Patch-For-Review: Make FileRepo file cache misses use slaves instead of the master - https://phabricator.wikimedia.org/T88506#1096851 (10aaron) 5Open>3Resolved a:3aaron
[21:31:30] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: MediaWiki multi-datacenter investigation and work - https://phabricator.wikimedia.org/T88445#1011867 (10aaron)
[21:38:50] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096870 (10Manybubbles) This SPARQL syntax is just used for naming graphs already in the system: SELECT ?foo FROM <some://iri> <------ This WHERE {}  And can't be...
[21:40:46] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096874 (10Manybubbles) The same is true for  SELECT ?foo   FROM NAMED <some://iri> <---- this  WHERE {}...
[21:43:30] <anomie>	 MatmaRex: I was going to use TextInputWidget's 'indicator' event as a "click this to auto-fill the token" in ApiSandbox :(
[21:44:13] <MatmaRex>	 anomie: well, good thing you didn't do that then, because it wouldn't have worked for keyboard users! :)
[21:44:21] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: Use local jobqueue class for jobs enqueued on pages views - https://phabricator.wikimedia.org/T91819#1096876 (10aaron) 3NEW a:3aaron
[21:44:25] <MatmaRex>	 anomie: this.$indicator still exists and you can hook all kinds of things to it.
[21:45:03] <anomie>	 MatmaRex: It wasn't in the tab order, if it fired events?
[21:45:04] <wikibugs>	 6MediaWiki-Core-Team, 5Patch-For-Review: Create a local job class that enqueues jobs to final location - https://phabricator.wikimedia.org/T89308#1096883 (10aaron) 5Open>3Resolved
[21:45:04] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: MediaWiki multi-datacenter investigation and work - https://phabricator.wikimedia.org/T88445#1096884 (10aaron)
[21:45:05] <MatmaRex>	 anomie: hmm?
[21:45:16] <anomie>	 <MatmaRex> anomie: well, good thing you didn't do that then, because it wouldn't have worked for keyboard users! :)
[21:45:40] <wikibugs>	 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: Create HTTP verb and sticky cookie DC routing in VCL  - https://phabricator.wikimedia.org/T91820#1096885 (10aaron) 3NEW a:3aaron
[21:46:10] * anomie will just have to make a widget with two sub-widgets, which was what he had started before finding the 'indicator' event
[21:46:25] <MatmaRex>	 anomie: it wasn't in tab order, and it didn't respond to 'keypress' events. only 'click'
[21:46:30] <MatmaRex>	 !gerrit fe8e2f5a485727e2c8c24008ca096c39a6f47abd | anomie
[21:46:38] <MatmaRex>	 bah, the bot is not here either?
[21:46:42] <MatmaRex>	 it's never there when i need it
[21:46:47] <anomie>	 Probably good to kill it then, if it wasn't accessible.
[21:46:53] <MatmaRex>	 but that commit is how i migrated away from the 'indicator' event for ComboBoxWidget
[21:54:12] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096920 (10Manybubbles) This syntax is designed to reach into other SPARQL endpoints using some standard protocol.    SELECT ?name   WHERE {     <http://example.o...
[22:00:30] <Deskana>	 bd808: I'll be in the hangout in a sec
[22:00:51] <bd808>	 Deskana: no worries. Just got there muyself
[22:04:56] <wikibugs>	 6MediaWiki-Core-Team, 10MediaWiki-RfCs, 7Epic, 5Patch-For-Review: MediaWiki multi-datacenter investigation and work - https://phabricator.wikimedia.org/T88445#1096933 (10RobLa-WMF)
[22:13:44] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Wikidata Query: Secure BlazeGraph's SPARQL: Investigate HistoryServiceFactory - https://phabricator.wikimedia.org/T91824#1096963 (10Manybubbles) 3NEW
[22:17:06] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1096985 (10Manybubbles) Notes before I leave for the weekend: SERVICEs are looked up ultimately in ServiceRegistry.  It looks them up by URIs and some are fine be...
[22:22:05] <hoo>	 Is greg-g in the office?
[22:22:26] <greg-g>	 hoo: yessssssss
[22:22:46] <hoo>	 greg-g: I would need to push https://gerrit.wikimedia.org/r/194949
[22:23:09] <hoo>	 We have to many edits... dispatching can't follow up since we added Wikibooks to it
[22:23:19] <greg-g>	 ahhh
[22:23:20] <greg-g>	 kk
[22:23:23] <hoo>	 as a workaround we would stop dispatching to closed wikis
[22:23:28] * greg-g nods
[22:23:28] <greg-g>	 doit
[22:23:47] <hoo>	 Thanks :)
[22:39:53] <wikibugs>	 6MediaWiki-Core-Team, 10SUL-Finalization, 5Patch-For-Review: Update CentralAuthUser::chooseHomeWiki() - https://phabricator.wikimedia.org/T91703#1097085 (10Legoktm) 5Open>3Resolved
[22:49:31] <legoktm>	 greg-g: can I backport+deploy https://gerrit.wikimedia.org/r/194709 ? That way I can start a slow-ish maintenance script to run over the weekend
[22:50:00] <Keegan>	 *'''Support''' ~~~~
[22:50:15] <greg-g>	 everybody wants special deploys today..
[22:50:22] <^d>	 I have one too :p
[22:50:49] <greg-g>	 legoktm: fiiinne
[22:51:01] <Keegan>	 :)
[22:55:50] <autismcat>	 ^d: https://gerrit.wikimedia.org/r/#/c/194969/ hehe, good move ;)
[22:59:37] <^d>	 autismcat: I was going to sync that out now.
[22:59:46] <^d>	 dbperformance.log is wayyyyy too loud right now
[23:00:58] <^d>	 greg-g: yay/nay on 194969 for wmf19? It's already in master and wmf20
[23:01:09] <Nemo_bis>	 expection?
[23:01:23] <Deskana>	 bd808: I'll do a write-up of exactly what it is that we just did and send to Erik/Rob.
[23:01:28] <Deskana>	 bd808: One less email for you to write. ;-)
[23:01:42] <bd808>	 thanks!
[23:02:08] <^d>	 Nemo_bis: expection isn't a word for me?
[23:02:32] <Nemo_bis>	 ^d: you used it! https://gerrit.wikimedia.org/r/#/c/194969/
[23:02:59] <Nemo_bis>	 well, co-used
[23:03:03] <^d>	 Oh, heh.
[23:03:12] <^d>	 Typo in original commit!
[23:03:28] * greg-g looks
[23:04:26] <greg-g>	 ^d: safe?
[23:04:59] <^d>	 Safe enough. It's running on wmf20 so I'm not too worried
[23:11:33] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add whitelist of RDF datasets that queries can operate on - https://phabricator.wikimedia.org/T91813#1097184 (10Smalyshev) What can we do with named graphs? Can we do materialized queries and such?  Also, for SERVICE - does it work only for pre-defined services (...
[23:12:17] <wikibugs>	 6MediaWiki-Core-Team: Fix job runner service availability during redis outages - https://phabricator.wikimedia.org/T91835#1097185 (10aaron) 3NEW a:3aaron
[23:14:06] <greg-g>	 ^d: kk
[23:14:37] <^d>	 autismcat: merging
[23:15:21] <wikibugs>	 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Wikidata Query: Secure BlazeGraph's SPARQL: Investigate HistoryServiceFactory - https://phabricator.wikimedia.org/T91824#1097206 (10Smalyshev) Not sure for public endpoint - some people would love the chance to look at the queries, but some people may be concerne...
[23:15:25] <autismcat>	 where you waiting on me?
[23:15:28] <autismcat>	 ok by me
[23:16:03] <^d>	 I wasn't, I was just letting you know :p
[23:16:50] <autismcat>	 well, I'm not always great at reading people :)
[23:22:58] <^d>	 Less noisy? Still noisy.
[23:25:01] <^d>	 2015-03-06 23:24:00 mw1110 enwiki: Expectation (writes <= 0) by MediaWiki::main not met:
[23:25:02] <^d>	 query-m: UPDATE `user` SET user_touched = 'X')
[23:29:47] <^d>	 bd808: Looking at the conference schedule, I think about 1/3 of the sessions I'll go to are logstash/kibana related :)
[23:30:00] <bd808>	 sweet
[23:30:11] * bd808 will had you the keys to the servers
[23:30:15] <bd808>	 *hand
[23:30:20] <autismcat>	 ^d: most of them are legit now :(
[23:30:28] <^d>	 autismcat: So better then
[23:30:39] <^d>	 bd808: I know better than to take free keys around here!
[23:30:43] <^d>	 They always come with strings!
[23:30:45] <autismcat>	 see https://phabricator.wikimedia.org/T91279
[23:30:55] <bd808>	 ^d: chains more like
[23:30:57] <autismcat>	 I remember Tim complaining about that field years ago
[23:31:09] <autismcat>	 I think CA is doing most of the writes
[23:31:41] <^d>	 iirc yeah
[23:32:00] <autismcat>	 some sampling could be done as a work around
[23:32:05] <autismcat>	 but much of that is MW sucking
[23:32:29] <autismcat>	 like the watchlist "last visited" stuff
[23:32:35] * autismcat already has a bug for that
[23:37:34] <wikibugs>	 6MediaWiki-Core-Team, 10MediaWiki-RfCs, 7Epic, 5Patch-For-Review: Consider moving various DB writes on page views to using local jobs - https://phabricator.wikimedia.org/T91837#1097241 (10aaron) 3NEW a:3aaron
[23:48:47] <legoktm>	 Keegan: https://en.wikipedia.org/wiki/Special:UsersWhoWillBeRenamed is being populated...
[23:51:08] <legoktm>	 Nemo_bis: ^
[23:51:55] <Nemo_bis>	 :)
[23:52:23] <Nemo_bis>	 LOL I want to meet the global owner of "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
[23:56:05] <Deskana>	 Judging by his username I'm sure he'd be excited to meet you.