[15:30:56] legoktm: Was there a particular reason to have ParserOptions options for the magic links, instead of relying on the global configuration? It seems like it's causing a lot of trouble. [16:48:21] anomie hi could you review https://gerrit.wikimedia.org/r/#/c/308753/ please? COuld you +1 or -1 please? [16:48:25] I tested it and it works [16:51:12] But it requires a +1 before it can be merged please? [16:51:24] paladox: I see stuff but I have no idea what it does or if it would work. Sorry. [16:51:59] anomie Ok, compare https://gerrit.wikimedia.org/r/#/q/bug:T67 to http://gerrit-test.wmflabs.org/gerrit/#/q/bug:T67 [16:51:59] T67: RSS/Atom feeds - https://phabricator.wikimedia.org/T67 [16:52:37] the linked patch just needs a +1 from you for mutante [16:54:04] :) [16:55:41] anomie here's a better example, compare https://gerrit.wikimedia.org/r/#/q/bug:T85002 and http://gerrit-test.wmflabs.org/gerrit/#/q/bug:T85002 [16:55:42] T85002: Gerrit bug search not (naively) working with Phabricator tasks - https://phabricator.wikimedia.org/T85002 [16:55:52] first link should link to https://gerrit.wikimedia.org/r/#/c/308753/ [16:58:59] :) [18:08:28] anomie: Because we generally keep global state out of Parser and it's all in ParserOptions::initialiseFromUser()...I could remove the setters so it could be assumed that the parser always follows the global configuration? [18:09:48] legoktm: That would mostly eliminate the issues I've seen, assuming no one uses reflection to screw around with them. [18:14:57] anomie: https://gerrit.wikimedia.org/r/310600 [18:20:52] anomie: And for Scribunto, do you think we should have EditPage wrap the error(s) somehow? [18:21:23] addshore: I see you didn't convert Special:Watchlist to use WatchedItemStore. Any suggestions on how to make it possible for Extension:ORES to add "wlshow=oresreview" and "wlprop=oresscores" into ApiWatchlist? [18:21:52] legoktm: It would be nice if EditPage would set off the errors from the status somehow, yes. [18:26:13] hmm, I'll split that into two separate patches then, so the prepareSave() part can go ahead [18:33:48] thanks [18:44:13] anomie: should Scribunto still handle the case where an invalid module was saved prior to removing support for invalid modules and no one has touched it since? (like all of the tracking category stuff) [18:44:38] legoktm: I don't see any reason not to handle that case. [18:48:50] alright, updated to not switch the hook and left a todo instead. [18:50:19] legoktm: https://gerrit.wikimedia.org/r/#/c/310463/3/Scribunto.php ? [18:50:58] missed that, sorry [18:51:07] * legoktm actually tests now [18:51:40] hello folks! Do we have any nice script to ls / cat a file in Swift ? [18:52:15] use case is to figure out the list of files under wmf mwstore://local-multiwrite/timeline-render/ [18:52:26] and eventually cat one of the files there :] [18:52:28] anomie: Tested and it works as expected [19:18:58] anomie: I've got a "dear lazyweb" question about api.php. Do we have an action that would let me find out if an ip address is on the block list? [19:20:34] bd808: https://en.wikipedia.org/w/api.php?action=query&list=blocks&bkip=192.2.0.2 ? [19:20:36] my use case is creating new LDAP accounts. We want to break the wikitech dependency on OSM, but I really don't want to recreate all the abuse defense tooling in Striker [19:21:24] Or, for an example that works, https://en.wikipedia.org/w/api.php?action=query&list=blocks&bkip=95.79.172.81 [19:22:15] nice! So many things that aciton=query exposes [19:22:33] And IPv6 works too: https://en.wikipedia.org/w/api.php?action=query&list=blocks&bkip=2602:306:36D5:8230:0:1:2:3 [19:23:29] Yeah, if you're wanting to look up any sort of information, action=query is the first place to look. [19:25:27] bd808: but there are multiple block lists, we also have a global blocklist, and tor is also kind of a block list. The former has a separate API [19:26:41] legoktm: hmmm.. ok. One thing I'm thinking or requiring is a SUL account that will auth via OAuth. That might be my cheap way of blocking jerks [19:27:39] do we automatically revoke OAuth auth-ability when a user is blocked? [19:27:52] that is a good question [19:30:58] anomie: I keep forgetting, is Scribunto aiming for 1.24 or 1.25 as minimum version? [19:32:24] bd808, legoktm: OAuth checks if the user is blocked when $wgBlockDisablesLogin is set. It also checks SUL locks even when that config isn't set. [19:33:02] legoktm: I don't know if anyone ever actually decided. [19:33:50] I'll vote for 1.25 because then we can get rid of all the UtfNormal in core fallbacks as well as legacy API docs [19:34:08] anomie: that would only fire when using the OAuth grant to do something else on the wiki right? [19:34:26] I have no objection. extension.json too, if you can figure out how to make that work for Scribunto. [19:34:29] since its in the session load callback [19:35:32] bd808: Well, in post-SessionManager MW it's done in the SessionProvider, whenever the user supplies the OAuth Authorization header. [19:37:15] https://www.mediawiki.org/w/index.php?title=Extension%3AScribunto&action=historysubmit&type=revision&diff=2238741&oldid=2234731 [19:41:25] tgr|away: global rename seems to be broken again (in wmf.19) :( https://phabricator.wikimedia.org/T145596 [19:41:38] * legoktm starts digging [19:42:54] hmm AaronSchulz https://phabricator.wikimedia.org/T145596#2638084 [19:43:31] legoktm: looking [19:44:28] legoktm: A decent reason to still handle invalid module content, even if it can't be saved anymore: http://localhost/w/api.php?action=parse&title=Module:Foo&text=this+is+broken [19:45:00] I clicked on that link expecting it to work :P [19:45:14] hmm [19:46:07] * anomie was thinking "how can I test the tracking category patch" and came up with that [19:50:45] Content validation is kind of messed up right now, there 3-4 different ways everyone does it [19:51:08] I filed https://phabricator.wikimedia.org/T143761 for that because none of them support my use case -.- [19:59:00] legoktm: I see, just LSB fun where __METHOD__ and get_class() interact [19:59:03] * AaronSchulz fixes [20:33:30] anomie: is there a ticket or something with details of what needs to happen (regarding ores watchlist things)? [20:38:21] addshore: Not really, https://phabricator.wikimedia.org/T122689#1939440 is probably the best summary that currently exists. What they want is a "wlshow" parameter that works like the "Hide: probably good edits" (ores-damaging-filter) checkbox on Special:Watchlist (and likely also its inverse), and the ability to return scores not terribly unlike the highlighting they add to Special:Watchlist rows. [20:40:49] anomie: i'll try to take a look this week (or next) [20:41:58] Or in SQL terms, adding a JOIN and a WHERE clause for the wlshow, and a JOIN with an additional selected field for the wlprop. Although in the API we'd probably want all the scores instead of just the 'damaging' score, so more complicated than just that. [20:43:20] addshore: Doing this ORES thing is a Q2 goal for Reading Infrastructure, but Q2 doesn't start until October so we're not too rushed just yet. (: [23:29:12] TimStarling: I suspect we're running parser tests twice now in Jenkins. Once via 'mediawiki-phpunit-hhvm-trusty' and via 'mediawiki-parsertests-hhvm-trusty' (both use phpunit, one excludes group 'ParserTests', the other sets --testsuite=parsertests). [23:29:26] Looking in the jUnit output, both contain ~1200 parser tests. [23:29:34] Or are there more that are not included in the xml report? [23:29:49] https://integration.wikimedia.org/ci/job/mediawiki-phpunit-hhvm-trusty/6752/console [23:29:50] https://integration.wikimedia.org/ci/job/mediawiki-phpunit-hhvm-trusty/6752/testReport/(root)/ [23:29:52] https://integration.wikimedia.org/ci/job/mediawiki-parsertests-hhvm-trusty/6646/console [23:30:19] ParserTest_Parser__parserTests and ParserTest_Parser__extraParserTests run in both. [23:30:29] so you think group exclusion is broken? [23:30:46] it doesn't matter so much anymore since (on my laptop) phpunit parser test execution time went from 2 minutes to 12 seconds [23:31:29] but yes, group exclusion should work [23:32:34] Yeah, I'd like to either restore that group, or simply remove the second jenkins job. [23:32:42] Jenkins runtime went from 8+ minutes to 3 minutes for the main phpunit job [23:32:52] which is presumably also from without parser tests to with parser tests [23:33:18] We made it separate originally to run them concurrently for faster response. [23:33:37] $this->addTest( new ParserIntegrationTest( $runner, $fileName, $test ), [23:33:37] [ 'Database', 'Parser' ] ); [23:34:01] I guess I got that group list from the wrong place [23:35:07] ParserTestTopLevelSuite still has @group ParserTests, but the group is not mentined anywhere else [23:35:18] and afaik it's now invoked directly without that class [23:35:38] Maybe from CoreParserTestSuite? [23:35:56] the individual tests are filtered, not the suites [23:36:34] Right [23:37:11] So the main job uses --exclude-group ParserTests, whereas the parsertest job uses --testsuite parsertests (not the group). [23:37:24] I think the parsertests suite invokes the parser tests directly, not via PHPUnit [23:37:29] which means the group filter does not apply [23:37:49] CoreParserTestSuite does exactly that it seems [23:38:25] I have a fix tested, just rebasing etc. [23:38:53] Okay :) [23:42:07] https://gerrit.wikimedia.org/r/#/c/310699/ [23:42:51] I confirmed the issue and tested the fix using --group not --exclude-group but it's very likely to work [23:43:57] https://gerrit.wikimedia.org/r/310700 [23:46:01] interesting experiment MaxSem [23:46:31] legoktm noticed that I had screwed up the exit status on parserTests.php and so they were unconditionally passing [23:48:22] I wonder if we can check for things like that automatically [23:59:55] TimStarling, it saved only 10s on mediawiki-phpunit-hhvm-trusty though :)