[00:39:05] tgr: I'm trying to unbreak some things in mw-vagrant caused by https://gerrit.wikimedia.org/r/#/c/264717/ [00:39:24] Do you remember what the `basename( $_SERVER['argv'][0] ) === 'MWScript.php'` bit was about? [00:40:12] that detects mwscript [00:40:14] that whole patch is mostly garbage [00:41:29] if you run 'php someScript.php ...' then $multiVersion will be null but throwing an error is probably not an expected result [00:41:50] well the whole multiversion code is mostly garbage if you ask me :) [00:52:48] huh, that part really is garbage [00:53:09] the require should be after the if [00:53:43] it was added in PS12 apparently [01:03:35] tgr: yeah. I'm fixing since I bumped into the var export problem [01:05:13] If you look at the prior patch this was improving, you can see that I only added the require to support the raw php usecase -- https://gerrit.wikimedia.org/r/#/c/154472/2/puppet/modules/mediawiki/templates/multiwiki/CommonSettings.php.erb,unified [01:05:53] so basically, LoadWgConf needs $wgDBname, $wgDBname needs the multiversion object, getting the multiversion object needs to be preceded by throwing errors, you need to know $wgLocalDatabases to know if you have to throw errors, and LoadWgConf is needed for wgLocalDatabases [01:05:59] sounds fun [01:06:40] It's fixable [01:06:54] this wasn't a GCI sized task though ;) [01:07:17] the class_exists could be simply replaced by another basename check [01:08:51] agreed, although, unicornisaurus wasn't a GCI sized student [01:08:54] I think it just needs to be rearranged to be nested ifs [01:10:46] replace class_exists with basename, move LoadWgConf to its original location, move the count($wgDatabases) block below it [01:10:51] I think [01:12:00] so the basename check is meant to see if mwscript was run but the db name given was junk right? [01:12:21] yes [01:12:53] * bd808 curses how slow vagrant provision has become [01:13:21] probably putting $wasCalledViaMwscript = basename( $_SERVER['argv'][0] ) === 'MWScript.php to the top of the file would make the whole thing more readable [01:14:21] Notice: Compiled catalog for mediawiki-vagrant.dev in environment production in 160.91 seconds [01:14:24] ffs puppet [01:20:46] $ mwscript eval.php --wiki=foo --- PHP Notice: Undefined index: foo in /var/www/w/MWMultiVersion.php on line 146 [01:21:03] I don't think things even allow the check that is there to be reached [01:41:59] bd808: I haven't tested properly the last few PSs of that patch because it required provisioning in and out wikis, and I was fed up with that by the eleventh time [01:42:12] :) [01:42:48] but I did test the earlier versions and silently ignoring a non-existent wiki was definitely happening at the time [01:42:58] yeah [01:43:07] well.. maybe [01:43:30] it should die, but it might die with a really strange error [01:44:54] I think it will end up telling you that the maintenance script doesn't exist [18:59:20] csteipp: composer 1.0.0-beta1 includes "Fixed SSL support to fully verify peers in all PHP versions, unsecure HTTP is also disabled by default" [18:59:42] wuhoo! [19:00:06] it's breaking stuff for windows users too :) [19:00:40] they have been working pretty hard on the tls stuff in the push to 1.0 [19:01:33] probably time to actually look at their implementation again [19:12:26] Sharpen your stabby stick first? [19:16:00] Is there a way to tell phpunit.php on multiwiki setup with which wiki to work? I tried but it seems to ignore --wiki completely... [19:17:33] Are you using mwscript too? [19:20:35] Reedy: nope, phpunit doesn't seem to work with mwscript [19:20:54] produces Class 'tests/phpunit/phpunit' could not be found in '/vagrant/mediawiki/tests/phpunit/phpunit.php'. [19:21:20] yeah I don't think there is any handling for that [19:21:38] I found this piece of advice: https://www.mediawiki.org/wiki/Fundraising_tech#Running_PHPUnit_tests_under_vagrant [19:21:44] tests shouldn't "work with" a wiki [19:21:57] bd808: what do you mean? [19:22:25] the difference between wikis is configuration. tests should manage that themselves [19:22:35] except maybe browser tests [19:22:43] bd808: I'm not sure test can "manage" difference between enwiki and wikidatawiki [19:22:55] wikidata tests can't run on enwiki [19:23:05] it does have 'wiki' => false, [19:23:38] but (except for browser tests) tests shouldn't run against a real wiki either. The db setup and config should be separate [19:23:57] jenkins doens't have a farm of wikis to choose from [19:24:06] (except for browser tests) [19:25:04] bd808: not sure what you mean by "real wiki" but wikidata test needs tons of configs, which are not present in default wiki [19:25:18] so it can not run on default wiki [19:25:56] as soon as I manage to get it into right wgDBname, it works just fine. But how I make that happen (except for hardcoding stuff into local settings which I don't like)? [19:26:38] how does wikidata/wikibase manage that for CI tests under Jenkins? [19:26:55] bd808: yes. I imagine wikibase tests just use one wiki [19:27:02] configured for wikibase [19:28:12] if default wiki is wikibase-enabled, everything is fine. If it's not, the tests can not run [19:28:27] hmmm [19:29:15] looking at https://integration.wikimedia.org/ci/job/mwext-testextension-php55-composer/981/consoleFull there's also a bunch of scripts running [19:29:29] so maybe some of that scripts add some settings that are not there by default [19:30:10] yeah. the test setup for Jenkins builds a LocalSettings.php [19:30:15] yuck [19:31:41] I guess I shouldn't be surprised that they are really integration tests rather than unit tests [19:32:00] mocking out things in core is not fun [19:32:05] bd808: ok. So should I just suck it up and add the magic MWMultiVersion::initializeForMaintenance(); into my LocalSettings? Or maybe vagrant could do it for me? [19:33:30] I've been mucking around with mw-vagrant's multiversion code yesterday and today. I have a use case that it doesn't support right now [19:33:53] I want to disable an extension that is installed globally on a particular wiki [19:34:04] the rabbit hole here is deep [19:35:23] If you can figure out how to get things to run via mwscript that would probably be nicest I guess [19:37:53] bd808: mwscript does not like phpunit too much... I guess it assumes there should be a class named phpunit there. But I could see if I can hack around it if that's the preferred solution [19:38:28] after all, phpunit does say it which classname to use.... so mwscript trying to use different one looks like a bug [19:38:37] well I don't know if there is any other generic solution for reusing the config of the wiki farm wikis [19:38:56] ok I'll try to make mwscript behave then [19:39:15] mwscript is probably tightly coupled to maintenance scripts right now [19:39:24] bd808: there's also this: https://www.mediawiki.org/wiki/Fundraising_tech#Running_PHPUnit_tests_under_vagrant which seems to work but I'm not sure it is good [19:39:53] oh [19:39:56] hmm... [19:40:21] that doesn't look too horrible. we could probably add that as default config [19:43:18] it works for me... I'm just not sure if it's good magic or bad magic :) [19:44:35] If it doesn't break anything when no --wiki param is passed it's probably not evil magic [19:46:32] i have a hack locally for phpunit [19:47:23] https://gist.github.com/filbertkm/501a6f9d7380f3159603 toward the beginning in my localsettings [19:47:34] which works for any cli script, including phpunit [19:54:56] aude: that's basically what initializeForMaintenance does... [19:55:09] as far as I can see [19:55:16] yeah [22:33:40] tgr: Is there an AuthManager patch for CentralAuth yet? I thought I'd seen it, but maybe I'm thinking of the sessionmanager one.. [22:34:07] csteipp: no [22:35:31] csteipp: beat the christmas rush and write it yourself ;) [23:26:26] bd808: this might be an adam question but he's out...and i'm so stuck but feel like i'm missing something basic. the vagrant fundraising role has a wiki at /srv/mediawiki-fr that is served at payments.wiki.local.wmftest.net, which is working, but i don't see where it's configured. no mention of that dir anywhere in /etc/apache2 [23:27:45] anything *.local.wmftest.net resolves to 127.0.0.1 [23:28:30] and the default apache vhost handles all the routing [23:28:56] cwd: what config are you looking for? [23:29:39] my problem is that static assets are still getting served out of /vagrant/mediawiki [23:29:55] i guess because the symlink at /var/www/w/extensions [23:30:00] yeah [23:30:08] but i don't understand how anything is getting served from mediawiki-fr [23:30:17] we haven't adopted the new router that prod uses for static assets [23:30:27] "dark magic" [23:31:10] look at settings.d/wikis/payments/wgConf.php [23:31:17] which is generated by puppet [23:33:15] haha, well this is not what i was expecting [23:33:26] cwd: reading puppet/modules/mediawiki/manifests/wiki.pp may give you some other clues [23:33:51] mediawiki-vagrant uses a cut down version of the multiwiki config management system from WMF prod [23:35:09] cwd: oh I pointed you at the wrong file to $IP. that's set in settings.d/wikis/dbConf/*.php [23:37:52] cwd: but for the static asset stuff I guess we should add something like https://github.com/wikimedia/operations-mediawiki-config/blob/master/w/static.php [23:38:26] paymentswiki is the only thing using the alternate MW clone right now [23:38:36] so you'd be the only person to notice :) [23:40:03] bd808: far out [23:40:18] so if i actually wanted to understand what is going on here...multiversion is the word to search for? [23:41:15] i can fix this for my purposes just relinking the extensions dir [23:41:33] the easiest way to follow the bouncing ball would be to start reading at /var/www/w/index.php I suppose [23:41:54] This is yet another thing that I should write some docs on for mw-vagrant [23:42:22] I don't know if the prod stuff it rips off is really documented anywhere other than the code either [23:42:34] if i manage to grok it i'll write a wiki page or something [23:44:11] most of the smart bits are generated from templates in puppet/modules/mediawiki/templates/docroot/w/ [23:44:44] and the system roughly corresponds to https://github.com/wikimedia/operations-mediawiki-config/tree/master/multiversion [23:45:27] described a bit here -- https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment#mediawiki-staging.2Fmultiversion [23:46:36] bd808: thank you for the info! [23:46:40] * cwd puts on goggles [23:46:48] yw and good luck [23:47:08] It all starts to make sense about the 10th time you have to read through it [23:48:19] :) [23:49:01] i'm actually glad it's something i don't know about and not a dawning complete misunderstanding of web servers