[04:55:14] 3MediaWiki-Core-Team: Isolate throughput issue on HHVM API action=parse - https://phabricator.wikimedia.org/T758#795816 (10tstarling) [06:19:49] I hate minification so much [06:20:33] can someone explain to me how I am meant to set a breakpoint in a minified file in firebug? [06:23:39] "debug mode" is not an answer since the bug is in resourceloader and pretty much the whole of resourceloader is disabled in debug mode [06:33:49] source maps [06:33:56] except RL doesn't support them yet [06:34:13] https://phabricator.wikimedia.org/T55510 [06:34:26] er, https://phabricator.wikimedia.org/T47514 probably [06:35:36] TimStarling: ^ [06:35:55] but that's probably not much help :P [06:41:51] not much [06:43:19] but there is a "prettify" button in FF now which seems to help [06:43:47] I can set a breakpoint on a prettified source line, and it stops when it gets there [06:44:26] it then puts the cursor on the wrong line, it uses the minified line number as an index into the prettified source [06:44:42] but if programming was easy, everyone would do it, right [06:44:43] ? [07:54:16] <_joe_> good morning :) [12:01:22] 3Services, MediaWiki-Core-Team: Set warning thresholds for average cluster utilization - https://phabricator.wikimedia.org/T76306#796191 (10faidon) Where is that figure coming from? Do you expect traffic to be tripled as part of a spike or natural growth? I don't think this is a reasonable number to plan for — a... [12:12:09] 3MediaWiki-Core-Team: [Bug 67774] UserMerge support for OAuth - https://phabricator.wikimedia.org/T721#796194 (10Aklapper) [14:51:14] 3MediaWiki-API, MediaWiki-Core-Team: API CORS preflight response should allow Api-User-Agent header - https://phabricator.wikimedia.org/T76340#797818 (10Anomie) p:3Triage a:3Anomie [14:52:26] 3MediaWiki-API, MediaWiki-Core-Team: API: list=tags should indicate whether a tag is defined - https://phabricator.wikimedia.org/T76052#797830 (10Anomie) 5Open>3Resolved [14:52:43] 3MediaWiki-API, MediaWiki-Core-Team: API list=tags continuation breaks with defined tags - https://phabricator.wikimedia.org/T76051#797831 (10Anomie) 5Open>3Resolved [15:27:40] 3MediaWiki-Core-Team, CirrusSearch: Prefix search containing only a namespace finds weird results - https://phabricator.wikimedia.org/T76350#798425 (10Manybubbles) [15:29:09] 3MediaWiki-Core-Team, CirrusSearch: Prefix search containing only a namespace finds weird results - https://phabricator.wikimedia.org/T76350#798425 (10Manybubbles) Useful info from village pump reporting the issue: ::::I have tested all namespaces and the only other cases were [[User talk:⁬⁬⁬⁬⁬]] (a user with on... [16:13:04] <^d> manybubbles: In re: your e-mail. Yeah I'm poking phab too. [16:13:12] <^d> I'm hoping it won't take us long to knock out quickly. [16:14:01] ^d: k. I'm going to finish up a few things on cirrus and then crack it open in earnest. unless you'd like to claim it. [16:16:54] 3MediaWiki-extensions-SyntaxHighlight-(GeSHi), MediaWiki-Core-Team: Lua syntax highlighting broken, missing text - https://phabricator.wikimedia.org/T76352#798512 (10Anomie) [16:21:24] 3MediaWiki-extensions-SyntaxHighlight-(GeSHi), MediaWiki-Core-Team: Lua syntax highlighting broken, missing text - https://phabricator.wikimedia.org/T76352#798521 (10Anomie) [16:25:19] beta hhvm logs -- Dec 1 16:15:12 deployment-mediawiki01: message repeated 10290 times: [ #012Warning: Extension:OpenSearchXml is no longer needed with this version of MediaWiki.#012 [Called from {closure} in /srv/mediawiki/php-master/extensions/OpenSearchXml/OpenSearchXml.php at line 27] in /srv/mediawiki/php-master/includes/debug/MWDebug.php on line 300] [16:25:58] anomie, legoktm: ^ Is that something your guys were working on? [16:26:17] s/your/you/ [16:26:30] <^d> We moved OpenSearchXml to core. [16:27:39] bd808: OpenSearchXml extension needs to be undeployed for wikis on wmf10 [16:27:49] I thought I remembered seeing something about that. I guess we need to get the extension off of beta [16:28:17] (or is it wmf11? I forget) [16:28:22] Well not "off of" but "stop loading" [16:29:39] <^d> Probably best to gate it, patch incoming. [16:33:03] <^d> https://gerrit.wikimedia.org/r/176679 [16:33:47] <^d> logic helps. [16:34:07] I was going to say... :) [16:37:58] 3MediaWiki-extensions-SyntaxHighlight-(GeSHi), MediaWiki-Core-Team: Lua syntax highlighting broken, missing text - https://phabricator.wikimedia.org/T76352#798536 (10Anomie) [16:42:36] <^d> The puppet code in phab-vagrant is fugly. [16:43:45] so it's puppet ... [16:56:45] <^d> https://github.com/valhallasw/phabricator-tools/blob/master/vagrant/puppet/phabricator/manifests/default.pp [16:57:42] heh. That is some crusty old puppet code. [16:58:18] <^d> I was wondering if we should ship arcanist in mw-v. [16:58:27] ewww https://github.com/valhallasw/phabricator-tools/blob/master/vagrant/puppet-apply.sh [16:59:26] ^d: I think adding that tool chain to mw-v would be a great idea. Ideally we'd figure out how to make it work from the host and the guest too. [17:00:05] <^d> If it's available in the mounted directories it should Just Work in the host as long as the bin file is in the $PATH or cwd. [17:00:09] Maybe with a bin dir or something that you could add to your path on the host if you wanted [17:00:14] <^d> Yeah [17:00:35] <^d> You can just give it a fully qualified path too if you don't want to mess with your host's path. [17:16:24] 3Services, MediaWiki-Core-Team: Set warning thresholds for average cluster utilization - https://phabricator.wikimedia.org/T76306#798607 (10GWicke) @faidon: Setting some average resource usage threshold is certainly a relatively crude way of ensuring that latency during request spikes is not driven up by resourc... [17:38:09] ^d: env::profile_script is the magic you'll want to add to the path inside the vm. [17:38:19] <^d> Yeah [17:38:49] There is an example at the end of the ::mediawiki class [17:44:49] <^d> yay works [17:45:10] <^d> enable-role arcanist, provision, ssh, `arc` works [17:45:46] <^d> (can also invoke from ./phab/arcanist/bin/arc relative to your host's files. [17:49:06] sweet. Should we just add that role all the time? [17:49:20] Assuming that arc is going to be used "soon" [17:49:32] I think we automatically install git-review today [17:50:55] <^d> I could go either way. [17:51:09] <^d> I figured some people might be using mw-v for non-dev tasks sometimes. [17:51:28] <^d> Plus, less we keep out of the default provision the better? [17:52:52] To some extent, but then again the more instructions we need to give for setting up to contribute the worse things are. A role is a great start for sure though. [17:53:32] I sometimes wish for mw-v without a wiki installed at all. Then I slap myself and deal with it. :) [17:53:47] <^d> hehe, ok. [17:53:58] <^d> how do you enable a role by default? [17:54:19] The easies way is to add it to hieradata/common.yaml [17:54:25] *easiest [17:54:46] Or make role::mediawiki include it [17:55:12] role::mediawki is loaded via hiera all the time [17:55:28] <^d> Yeah in that case I guess just remove the role and just include the module from mediawiki yeah [17:55:42] *nod* [18:14:04] <^d> I think I'm also going to abuse mw-v into a phab role like you did with ieg :p [18:18:55] 3Scrum-of-Scrums, Core-Features, MediaWiki-Core-Team: Enable $wgContentHandlerUseDB everywhere (bug 49193) - https://phabricator.wikimedia.org/T1217#798714 (10EBernhardson) [18:34:48] ori: I renamed the api module [18:41:27] bd808: https://gerrit.wikimedia.org/r/#/c/176700/ [18:43:37] AaronSchulz: {{done}} [18:44:25] AaronSchulz: You might like this -- https://github.com/phacility/xhprof/pull/52 and https://github.com/facebook/hhvm/issues/4354 [18:45:24] I think that HHVM framing issue may hit our usage of xhprof_frame_begin as well [18:47:35] well, I'm not really a fan of sub-function profiling [18:47:46] it's kind of a code smell [18:48:22] I guess it is convenient in a few bits [18:48:45] e.g., FileBackend has an entry for the method and a sub entry for the cache miss case (-miss) [18:49:57] <^d> manybubbles: Do you think you could have a look at https://gerrit.wikimedia.org/r/#/c/176016/? It's one of the things mobile wanted from us. [18:49:58] it could use another method, though the code is already small in those spots [18:50:03] <^d> (offsets in prefix searches) [18:50:25] poking around in the pecl extension was kind of fun. I had to remember how to play nice with malloc/free. [18:50:56] interesting what phpng is doing [18:51:13] zval PP_ methods will go away since they nuke a layer of pointers [18:51:27] various bits will s&r and some manual updates in pecl extensions [18:52:23] I guess if we don't care about third party users nothing has to be ported over (e.g. fss,luasandbox) [18:52:40] <_joe_> AaronSchulz: sorry I didn't manage to research the redis failover stuff at all today [18:52:46] <_joe_> but it's on my radar [18:52:46] looks like ng was merged in master, and will be in php7 [18:52:59] that reminds me, I should add some comments [18:56:08] Getting rid of a layer of pointers sounds like a good thing. I haven't looked at the phpng guts. I'm still trying to understand hhvm's internals. [18:57:06] ^d: I thought I'd reviewed this! looking again [18:57:14] <^d> okie dokie :) [19:08:09] ^d: I unstuck updates in beta and now the l10n build there is dying because OpenSearchXml is still in wmf-config/extension-list. It's a weird error though [19:08:32] It says it can't read the file and it is clearly there [19:08:38] on disk [20:37:04] bd808: Can you confirm extensions should use $GLOBALS['wgFoo'] in their main php file when adapting for Composer? [20:37:33] It seems an odd pattern. I noticed it in a few pending patches. None of them cross-reviewed yet though, so this is the time to establish a convention before its too late. [20:37:41] <^demon|lunch> bd808: We could remove from the extension-list in beta. [20:38:06] ^demon|lunch: I hacked it out by hand and proposed a config patch to remove it all together. [20:38:34] Krinkle: or global $wgFoo; as you would usually [20:39:03] Krinkle: I have seen that $GLOBALS hack too but not investigated. I think it had something to do with accessing the global scope from outside a function. [20:39:42] <^demon|lunch> Won't that be problematic as OpenSearchXml entries won't remain in i18n cache? [20:40:09] Krinkle: Jeroen may know more details. [20:40:29] bd808: I'm suspicious as it suggests the way the main php file is loaded would be different somehow. Whereas I've not seen that anywhere yet. Things are included in localsettings, which has global scope. [20:40:30] Krinkle: the problem is that compsoer includes entry points in a function scope, not file scope, so the globals need to be made explicit [20:40:38] <^demon|lunch> global $foo vs $GLOBALS['foo'] shouldn't make a difference. [20:40:44] ^demon|lunch: I think it would just stop updating them when l10nupdate runs, but Reedy would maybe know better than I. [20:40:56] Yeah, I get that. It's about being inside a funciton where it does the require statemenet for the php file [20:41:04] but that's not inside a function, that's in localsettings. [20:41:09] What is loading it differently? [20:41:12] <^demon|lunch> Sometimes, not always. [20:41:14] composer is [20:41:20] for what purpose? [20:41:21] <^demon|lunch> installer does. [20:41:37] what does composer/installer do for extensions without mediawiki? [20:41:57] that it needs the main php file for [20:42:01] <^demon|lunch> Well in the installer's case, MW doesn't exist yet. [20:42:08] Exactly [20:42:14] <^demon|lunch> It doesn't have a LocalSettings for you to include the extensions in. [20:42:28] and yet it does something? [20:42:41] <^demon|lunch> But you have to include them for something important. [20:42:56] <^demon|lunch> Oh yeah, for updates to register. [20:43:01] <^demon|lunch> So your database gets setup right. [20:43:13] Isn't that done by mediawiki/update.php/ [20:43:16] so if you install a composer package with a type of "mediawiki-extension", composer puts it in extensions/$name, and loads the entry point in vendor/autoload.php [20:43:17] which requires core [20:43:35] <^demon|lunch> Yes, but the installer gives you the option of enabling extensions. It wouldn't make sense for it not to install them properly. [20:43:40] 3MediaWiki-Core-Team: SecurePoll poll editing should take place on the central wiki - https://phabricator.wikimedia.org/T1271#799101 (10Anomie) 5Open>3Resolved [20:44:11] http://www.bn2vs.com/blog/2013/11/24/introduction-to-composer-for-mediawiki-developers/ [20:44:25] ^demon|lunch: ah, so when installing extensions via composer (documented?) it will require the main php file without needing an entry in local settings. [20:44:37] <^demon|lunch> I know nothing about composer. [20:44:49] <^demon|lunch> I'm talking about the MW installer. [20:45:05] The installer just includes them, no? [20:45:10] Krinkle: simple: https://gerrit.wikimedia.org/r/176738 [20:45:33] <^demon|lunch> Krinkle: Yes, but it's not in the global scope. [20:46:29] ori: Have you confirmed that to be an issue? I'm pretty sure it retains its scope already. All those methods, including the ones from jQuery plain, are scoped, bound and detachable. [20:46:42] ori: It has to return 'this' to enforce proper detachability and chainability. [20:46:49] It only uses the this to return itself. [20:46:59] no, it uses it in fire() [20:47:01] I remember the installer doing some weird stuff with globals. [20:47:13] ori: I know it does, that's by design. Have you confirmed it to be an isuse? [20:47:30] ori: It returns 'this' so that you can attach it to another object. [20:47:41] ori: similar to how calling $.ajax().done().abort() works [20:48:02] .done() doesn't return the mixin promise object, it returns 'this', so that it includes whatever was attached to it [20:48:15] mixins should not make assumptions about the host object. [20:49:30] ori: the code example you give should work fine already, there's even a unit test for it. I love that pattern. [20:50:29] legoktm: ^demon|lunch: None of our extensions use GLOBALS, the Installer works fine without that. Has for years. [20:50:55] well, [20:50:57] * legoktm finds commit [20:51:03] <^demon|lunch> Because I hack around it in the installer for a couple of weird things and we don't use the installer at WMF ;-) [20:51:43] <^demon|lunch> Anyway, I'm not saying that declaring things as globals is the right thing to do. [20:51:44] https://github.com/wikimedia/mediawiki/commit/248ac9e9b1af986ac3238b3b5291c6d046889347 [20:51:44] So this'll allow the installer to be cleaned up [20:51:57] <^demon|lunch> Just that extension entry point files shouldn't always rely on the fact that they're in the global scope. [20:52:01] <^demon|lunch> Because it's *not true* [20:52:15] <^demon|lunch> (and shouldn't be true. global scope needs to go away here) [20:52:16] Krinkle: yep. you're right. [20:52:19] Krinkle: thanks! [20:53:04] ori: No worries. I do see it as a confusing thing. Let me know if you have an idea to improve it. [20:53:32] since we're talking about this, I just updated https://gerrit.wikimedia.org/r/166705 (extension registration) :) [20:54:43] <^demon|lunch> I remember that from the hackathon :) [20:55:29] cool [21:04:19] [21:04:01] (CR) Paladox: "I am not sure." [extensions/LocalisationUpdate] - https://gerrit.wikimedia.org/r/168274 (owner: Reedy) [21:04:20] Amazing. [21:10:31] Krinkle: https://gerrit.wikimedia.org/r/176746 then ;) [21:11:12] Reedy: the log line from grrrit-wm is misleading; he removed himself from the list of reviewers in the same review [21:11:31] Reedy: so he's saying "i'm not sure, so go ahead and disregard", which is not unreasonable [21:11:44] He +1'd [21:11:49] Changed the commit summary [21:11:54] Niklas reapplied -1 [21:11:59] Paladox -1'd [21:12:36] oh, heh [21:17:36] Opinion leadership! [21:19:08] SMalyshev, https://gerrit.wikimedia.org/r/#/c/49159/2/modules/solr/files/jetty [21:25:06] <^demon|lunch> solr wut? [21:45:10] bd808: when you imported https://phabricator.wikimedia.org/T1223, was there a mingle SoS card for that in addition to the mobile one? [21:47:48] csteipp: yup -- https://wikimedia.mingle.thoughtworks.com/projects/scrum_of_scrums/cards/56 [21:50:57] <^demon|lunch> ori: The idea with putting it in /vagrant was so you could use arcanist from your host OS as well. [21:57:20] <^demon|lunch> ori: also: I plan to (ab)use mw-v into having a phabricator role, à la iegreview. [21:57:36] <^demon|lunch> (since the phab-vagrant code is awful awful and lacks elasticsearch) [21:57:42] <^demon|lunch> And is lucid, yuck. [21:57:51] heh, yay for abusing mwv [22:11:30] bd808: I'm trying to keep beta cluster things away from you as much as possible! [22:12:09] greg-g: heh. I self select for those problems. It's hard to focus on "boring" things when stuff is broken. [22:12:10] 3Wikimedia-Logstash, MediaWiki-Core-Team: doc_values setting in mapping causes fields >32K to reject indexing document - https://phabricator.wikimedia.org/T1269#799420 (10Aklapper) [22:13:41] 3MediaWiki-extensions-SyntaxHighlight-(GeSHi), MediaWiki-Core-Team: Lua syntax highlighting broken, missing text - https://phabricator.wikimedia.org/T76352#799430 (10bd808) [22:13:52] 3MediaWiki-Core-Team, MediaWiki-extensions-WikidataClient, Wikidata, Scrum-of-Scrums: Set languageLinkSiteGroup in $wgWBClientSettings to avoid fetching SiteList object from memcached - https://phabricator.wikimedia.org/T58602#799436 (10bd808) [22:13:54] bd808: yeah, maybe I should start negatively influencing your choices away from it :) [22:13:57] 3MediaWiki-Core-Team: Convert old 1.23wmf* and 1.24wmf* deployment branches to tags - https://phabricator.wikimedia.org/T1288#799445 (10bd808) [22:14:05] that's a bad sentence, but you know what I mean [22:14:19] greg-g: Easy! just have all the problems fixed before I notice them. :) [22:14:26] bd808: EASY! [22:15:07] 3MediaWiki-Core-Team: Improve TransactionProfiler - https://phabricator.wikimedia.org/T1341#799446 (10bd808) [22:15:39] 3MediaWiki-Core-Team: Remove ProfilerStandard dependency from SectionProfiler - https://phabricator.wikimedia.org/T1326#799448 (10bd808) 5Open>3Resolved [22:15:55] 3MediaWiki-Core-Team: Move profiler sample to config and restore --profiler maint script option - https://phabricator.wikimedia.org/T1353#799450 (10bd808) 5Open>3Resolved [22:19:03] 3MediaWiki-Core-Team: Remove ProfilerStandard dependency from SectionProfiler - https://phabricator.wikimedia.org/T1326#799463 (10bd808) [22:21:20] Keegan: could you +1 https://gerrit.wikimedia.org/r/#/c/176801/ when you have some time? [22:25:55] <^demon|pumpkinpi> manybubbles: random tidbit: https://gerrit.wikimedia.org/r/#/c/174853/ [22:27:02] Krinkle: where should the mw.hook be documented? RELEASE-NOTES? [22:27:21] ori: No, in the code with jsduck so it shows up on doc.wikimedia.org when looking for mw.hook 's [22:27:31] Krinkle: ah! makes sense. [22:27:52] ori: Though a release note saying a hook was added wouldn't hurt, too :) [22:28:31] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook [22:28:31] https://doc.wikimedia.org/mediawiki-core/master/js/source/mediawiki.page.startup.html#mw-hook-event-wikipage_content [22:33:50] Krinkle: {{done}} [22:36:22] legoktm: yup yup did did [22:36:54] thanks [22:44:13] 3MediaWiki-Core-Team, MediaWiki-General-or-Unknown: $wgProfileToDatabase still used - https://phabricator.wikimedia.org/T75917#799531 (10Chad) p:5Triage>3Normal a:3Chad [22:52:28] TimStarling: https://gerrit.wikimedia.org/r/#/c/166705/ is the extension registration patch [23:11:46] 3Wikimedia-Logstash, MediaWiki-Core-Team: Get HHVM logs into logstash - https://phabricator.wikimedia.org/T76119#799627 (10hashar) [23:16:47] 3MediaWiki-Core-Team: Experiment with Wikidata Query Engine - https://phabricator.wikimedia.org/T1028#799672 (10Smalyshev) [23:27:09] <^demon|punkinpie> manybubbles: We already support a max offset in Searcher of 100k [23:27:21] ah cool [23:27:22] <^demon|punkinpie> $this->offset = min( $offset, self::MAX_OFFSET ); [23:27:27] <^demon|punkinpie> MAX_OFFSET = 100000; [23:27:39] ok, withdrawn. I knew we did that for regular search but not for prefix search [23:27:57] <^demon|punkinpie> We "did", but since we always passed 0 it didn't matter. [23:28:02] <^demon|punkinpie> :) [23:29:00] cool [23:30:44] <^demon|punkinpie> I wrote the Cirrus patch in a way that doesn't require the core change. [23:30:54] <^demon|punkinpie> So can be merged in either order and preserves some level of back-compat. [23:32:25] <^demon|punkinpie> Hmm, something's wrong. [23:33:43] <^demon|punkinpie> http://localhost:8080/w/api.php?action=query&list=prefixsearch&pssearch=ex gives me [23:33:50] <^demon|punkinpie> 1: ex [23:33:56] <^demon|punkinpie> 2: exist [23:33:59] <^demon|punkinpie> 3: experiment [23:34:08] <^demon|punkinpie> http://localhost:8080/w/api.php?action=query&list=prefixsearch&pssearch=ex&psoffset=2 gives me [23:34:09] <^demon|punkinpie> 1: ex [23:34:14] <^demon|punkinpie> 2: experiment [23:34:16] <^demon|punkinpie> 3: exam [23:34:25] <^demon|punkinpie> I had this working :\ [23:37:34] <^demon|punkinpie> Hmm, result 1 always seems to be appended. [23:37:40] <^demon|punkinpie> same thing with psoffset=10 [23:46:33] 3Deployment-Systems, Release-Engineering, MediaWiki-Core-Team: Update servers in scap rsync proxy pool - https://phabricator.wikimedia.org/T1342#799820 (10greg)