[13:14:31] * anomie sees Iaf5cf656 and realizes we're getting to have a lot of testing junk in the repo root [16:30:27] bd808: _joe_ just merged the extra scap proxies :) [16:30:38] sweet! [16:30:52] * bd808 hopes for a <20m full scap [16:31:09] I suspect we might need to still do some work on scap so it doesn't overload single hosts so much [16:31:14] but this should help [16:32:24] a more robust source discovery would be nice. It could ssh to the best candidate and run some command that returned true/false based on the load of the box or something [16:32:40] or we could just replace it all with bittorrent and call it a day :) [16:33:52] If we could just get rid of the cached urls that contain the wmf branch name things would be so much simpler [16:35:31] ^d: can you do https://www.mediawiki.org/wiki/Gerrit/Project_ownership#Request_for_WikidataQuality ? [16:35:36] i cant [16:36:50] <^d> {{done}} [16:47:01] thanks! [16:47:51] <^d> yw [17:12:31] 3CirrusSearch, MediaWiki-Core-Team: Support multiple datacenters in CirrusSearch - https://phabricator.wikimedia.org/T86781#976349 (10Chad) 3NEW [17:12:52] <^d> manybubbles: wheee ^ [17:39:37] 3wikidata-query-service, MediaWiki-Core-Team: Write example queries in different query languages - https://phabricator.wikimedia.org/T86786#976465 (10Manybubbles) 3NEW [18:05:33] ^d: You can keep two elasticsearch clusters in sync using some message bus and a river plugin to send new documents to both. Or like you imagined a multi-write setup that is more direct [18:06:09] maybe you could create a kafka rive plugin if there isn't one already and use that as the cross-dc message bus [18:06:13] *river [18:06:42] https://github.com/endgameinc/elasticsearch-river-kafka and https://github.com/mariamhakobyan/elasticsearch-river-kafka [18:08:06] Using a river plugin to feed Elasticsearch is kind of neat. It decouples the document producer from the cluster entirely which can enable some fun data flows [18:12:05] <^d> I had looked at rivers. [18:12:18] <^d> But I really wanted an ES-to-ES river, not something in between :p [18:15:46] hoo|away: ori: _joe_: if you want to cherry-pick it: https://github.com/facebook/hhvm/commit/fd41d2001042bf208864da0d08e3dd96a52e43f5 [18:16:05] you only really need the change to runtime/base/tv-arith.cpp [18:19:27] swtaarrs: That's a sneaky bug. Thanks for hunting it down and finding a fix [18:19:43] np [18:20:04] it was especially sneaky because the heap profiles I collected actually did blame hash_init [18:20:13] due to how we reuse slabs we get from malloc [18:23:19] 3MediaWiki-Page-editing, MediaWiki-Core-Team: ipblocks query from EditPage unconditionally goes to master - https://phabricator.wikimedia.org/T51419#976656 (10aaron) a:5tstarling>3aaron [18:26:28] 3MediaWiki-extensions-CentralAuth, SUL-Finalization, MediaWiki-Core-Team: Investigate and fix OOMs caused during account globalization - https://phabricator.wikimedia.org/T78727#976682 (10bd808) @swtaarrs has a patch upstream that may be the true fix for this ( AaronSchulz: SoS? [18:53:21] 3wikidata-query-service, MediaWiki-Core-Team: Write example queries in different query languages - https://phabricator.wikimedia.org/T86786#976725 (10Lydia_Pintscher) [19:41:47] https://wikitech.wikimedia.org/wiki/Special:SpecialPages [19:41:53] * AaronSchulz wonders what the empty bullet is for [19:42:02] qqx? [19:42:14] [19:48:01] swtaarrs: Awesome, thanks :) [19:49:51] _joe_: Can you include that in your ongoing(?) hhvm update? [20:08:44] * AaronSchulz hands ^d https://gerrit.wikimedia.org/r/#/c/177001/3 [20:13:19] swtaarrs: \o/! thanks [20:22:12] 3SUL-Finalization, MediaWiki-extensions-CentralAuth, MediaWiki-Core-Team: Cherry-pick and deploy fd41d20010 from facebook/hhvm - https://phabricator.wikimedia.org/T86813#977091 (10ori) 3NEW a:3Joe [20:53:34] ^d, legoktm: RFC meeting on https://www.mediawiki.org/wiki/Requests_for_comment/Guidelines_for_extracting,_publishing_and_managing_libraries at the top of the hour. Would be great to have you folks around to help discuss [20:55:28] csteipp: Nice to have you there too if you have anything to add re library security things we should add to the RFC [21:25:22] 3MediaWiki-Core-Team: Investigate memcached-serious error spam that mostly effects HHVM API servers - https://phabricator.wikimedia.org/T75949#977325 (10ori) >>! In T75949#974876, @tstarling wrote: > The current hypothesis is that this is due to local port exhaustion, which occurs when a server does more than ab... [21:25:32] ^ TimStarling, fyi. [21:25:37] * ori runs to a doc appt [21:29:45] 3wikidata-query-service, MediaWiki-Core-Team: Wikidata Query - make unit tests for domain specific language - https://phabricator.wikimedia.org/T86832#977332 (10Manybubbles) 3NEW [21:32:48] 3wikidata-query-service, MediaWiki-Core-Team: Wikidata Query - add license - https://phabricator.wikimedia.org/T86833#977341 (10Manybubbles) 3NEW [22:02:12] It seems something of a waste to have a content blob stored that's basically a serialized list of what's supposed to be in the database table. [22:02:16] Unless we're needing the content blob for some other purpose. [22:02:52] well, there's only one reason to do such a thing, and that is for multiuser editing, versioning, access control, etc. [22:02:56] wiki stuff [22:03:09] there wouldn't be much point for private user watchlists [22:03:32] Yeah, if we're wanting history, diffing, and everything that's "some other purpose" [22:05:02] / Done as one big message so that stewards can create a local [22:05:02] // translation to customize the output as they see fit. [22:05:05] -.- [22:15:17] hoo: Did we not ever have you look at those special pages while they were in dev? :/ [22:16:13] I thought you were on code review for most of them but maybe I didn't add you at the right times and places [22:18:09] Maybe I was to busy at that time [22:18:20] Maybe during my exams last year or so [22:19:31] Was that comment for this message? -- http://sulfinalization.wmflabs.org/wiki/MediaWiki:Globalrenamequeue-request-userinfo-local [22:20:32] My thought with that one was that there were fancy templates on meta to make data that the stewards were used to seeing and I didn't want to try and hard code that in the app [22:21:23] No, not that one [22:21:28] that one is ok-ish [22:21:34] it's big, but ok [22:21:46] http://sulfinalization.wmflabs.org/wiki/MediaWiki:Globalrenamequeue-view [22:21:49] this one is to big [22:21:58] that's not how we should use localization [22:22:03] ah. yeah that was punting [22:22:24] I added a todo now [22:22:40] next core update will break the interface :S [22:22:58] I'll try to also fix that and then I'm done for now, I guess [22:23:44] hoo: which core update? [22:24:28] TimStarling: do you know what function call is causing https://phabricator.wikimedia.org/T51419 ? I don't get that locally and xhprof is off on production so I can't see the calls [22:25:02] legoktm: Not sure... but the checkboxes overlap the text on master [22:25:25] On the request page [22:25:30] ehm [22:25:34] MatmaRex just changed how vforms work in core so there might be a regression? [22:25:37] request approval/ deny page [22:25:49] Possible [22:26:01] The new checkboxes certainly look fancy, but they overlap [22:26:22] wat [22:26:44] legoktm: hoo: what where [22:26:46] linkssss [22:27:15] MatmaRex: Do you have CentralAuth installed? [22:27:26] I can give you a screenshot, if not [22:27:28] hoo: you mean a local installation? no [22:27:31] please do [22:29:45] MatmaRex: https://people.wikimedia.org/~hoo/tmp/Form-mess.png [22:30:15] hoo: how are you making that form? is it a HTMLForm, or hardcoded HTML? [22:30:28] $form = HTMLForm::factory( 'vform', [22:31:11] hoo: is the code up somewhere? (is this master/whatever, or something you're just writing now?) [22:31:31] It's up, wait a sec [22:31:39] that definitely shouldn't be happening; it used to, but that bug was fixed a few months ago :) [22:32:02] https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/includes/specials/SpecialGlobalRenameRequest.php [22:32:30] my MediaWiki is on master [22:33:22] hoo: that… doesn't look like it generates any checkboxes? [22:33:51] MatmaRex: Sorry, wrong page :P [22:34:04] this one https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/includes/specials/SpecialGlobalRenameQueue.php [22:34:12] 'movepages' => array( [22:34:16] grep for that [22:34:49] 3wikidata-query-service, MediaWiki-Core-Team: Wikidata Query - add license - https://phabricator.wikimedia.org/T86833#977518 (10Smalyshev) Apache is good for me. [22:35:33] yeah [22:35:35] hmmmphpmhpmhmh [22:38:36] hoo: well i dunno, it does look like i broke it, but i don't understand why [22:39:10] hoo: is there anywhere i could look at this output myself? or do i have to set up centralauth locally? [22:39:30] Beta, I guess [22:39:39] hoo: or, can you just pastebin me the HTML? :D [22:41:12] <^d> bd808: PSR-7 is a clusterfuck. [22:41:38] × Your paste triggered our spam filter and has been dropped [22:41:40] meh [22:41:48] ^d: which one is that? cache or http? [22:41:51] <^d> hhtp [22:42:10] yeah I saw the "all object are immutable" thread and checked out [22:42:33] these kids don't want to write php. they should switch to haskell or something [22:42:38] MatmaRex: http://pastebin.com/j7tHgkyk [22:44:21] <^d> bd808: Also, wtf? https://github.com/php-fig/fig-standards/tree/master/proposed/psr-8-hug [22:45:12] heheheh. +2 [22:45:58] <^d> Clearly we need to let our objects hug [22:46:51] hoo: thanks, looking [22:47:21] ^d: I bet there is an epic flamewar on the mailing list that lead to that one [22:47:23] bd808: Ok, I got 4 (minor) changes up in gerrit... after that the interface should be fine [22:48:29] hoo: awesome. I'll check them out and see if I can +2 [22:54:32] :) [22:55:36] <^d> bd808: "I PREFER MY OBJECTS TO KISS!" [22:55:53] <^d> "WHAT ABOUT OBJECTS THAT DON'T LIKE OTHER OBJECTS IN THEIR SPACE?" [22:56:08] http://i2.kym-cdn.com/entries/icons/original/000/007/582/tumblr_lmputme3co1qa6q7k_large.png [22:56:51] hoo: shit's fucked up, give me a few more minutes and i'll figure out why [22:56:51] <^d> "HUGGING IS SOMETHING RESERVED FOR ONE OBJECT AND ANOTHER; IDENTICAL OBJECTS SHOULDN'T BE ALLOWED TO HUG" [22:56:59] <^d> ^ That was the guy from the deep south :p [22:57:29] heh, ok :) [23:01:07] hoo: this should fix it: https://gerrit.wikimedia.org/r/185083 please test [23:02:51] will do in a bit [23:42:04] bd808: so I noticed that when I want to use the merge-plugin, the first composer install will only get the plugin and then if I composer update it downloads stuff in the other files [23:42:18] nod [23:43:21] I'm guessing there's no way to do it in one step? [23:43:22] the plugin doesn't exist in composer for the first run so it can catch the "on install" event [23:43:22] *can't [23:43:51] since the plugin just decorates the normal install/update process it really can't do something after it is installed in the first run