[02:13:21] Tim-away: heh: http://blog.nodejs.org/2015/02/06/node-v0-12-0-stable/ "spawnSync/execSync have been added to facilitate synchronous child processes, warning your node process won't make forward progress while waiting for the child to exit, caveat emptor!" [02:13:58] mmm [02:14:35] there goes my rant [02:46:55] sucks to be you [03:31:40] 3MediaWiki-Core-Team: Missing log library when trying to install MediaWiki - https://phabricator.wikimedia.org/T88951#1024021 (10ori) 3NEW a:3bd808 [03:35:31] 3MediaWiki-Core-Team: Missing log library when trying to install MediaWiki - https://phabricator.wikimedia.org/T88951#1024033 (10ori) Specifically, the web installer should be able to at least get to the "Environmental checks" stage. An error about composer and/or composer-installed dependencies should be emitte... [03:38:48] 3MediaWiki-Core-Team: Missing log library when trying to install MediaWiki - https://phabricator.wikimedia.org/T88951#1024035 (10bd808) This is basically an exact dup of {T74777}. I'm not sure what else can be done beyond the multiple fixes including the quoted error message that have been made as a result of th... [03:43:27] 3MediaWiki-Core-Team: Missing log library when trying to install MediaWiki - https://phabricator.wikimedia.org/T88951#1024041 (10ori) >>! In T88951#1024035, @bd808 wrote: > This is basically an exact dup of {T74777}. I'm not sure what else can be done beyond the multiple fixes including the quoted error message... [03:45:45] bd808: it's gross. there has to be a better solution. i don't believe the benefit of composer-managed external dependencies justifies breaking the install experience so thoroughly. the environment checks page is the second screen, where the first one is just a mediawiki logo with an "install" button. i'm sure we can do that much without depending on external components. [03:47:30] The message is triggered when MWLoggerFactory::getInstance() is called and !interface_exists( '\Psr\Log\LoggerInterface' ) [03:47:43] all logging now requires that class [03:48:08] which will be provided via composer either manually or via a bundle such as mediawiki/vendor [03:49:00] there are a growing number of other required libraries (cdb, cssjanus, oojsui) that are required in the same way [03:49:16] just don't log for that screen [03:49:24] i'm not saying all of mediawiki should work [03:49:49] i'm saying you should be able to render an html page with a "continue" button and get to the page that does some basic environment checks [03:50:28] is this mw-config/index.php specifically? [03:50:51] yeah [03:51:27] if ( !function_exists( 'version_compare' ) || version_compare( PHP_VERSION, '5.3.3' ) < 0 ) { [03:51:27] // We need to use dirname( __FILE__ ) here cause __DIR__ is PHP5.3+ [03:51:27] require dirname( dirname( __FILE__ ) ) . '/includes/PHPVersionError.php'; [03:51:28] wfPHPVersionError( 'mw-config/index.php' ); [03:51:31] } [03:51:54] we manage to give a friendly error for not meeting the minimum PHP version requirements [03:51:59] The wfDebug() call in includes/Setup.php looks to be the place the error comes from there [03:52:40] modify it to exempt the installer? [03:52:44] you can have the installer set a const [03:56:07] We may be able to figure out how to do something there. I still think that once we have official 1.25 tarballs this will not be a problem [03:56:43] 3MediaWiki-Core-Team: Missing log library when trying to install MediaWiki via WebInstaller (mw-config/index.php) - https://phabricator.wikimedia.org/T88951#1024042 (10bd808) [03:58:13] Maybe I can hack it so that when MEDIAWIKI_INSTALL is defined the error prints another way [03:58:57] or just have a custom error page, a la includes/PHPVersionError.php, and check for composer deps before Setup.php [03:59:34] what is the ultimate benefit of all the logging work? [04:00:51] nevermind, i re-read http://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging to remind myself [04:11:46] 3MediaWiki-Core-Team: Missing log library when trying to install MediaWiki via WebInstaller (mw-config/index.php) - https://phabricator.wikimedia.org/T88951#1024053 (10bd808) `mw-config/index.php` requires `includes/WebStart.php` which in turn requires `includes/Setup.php`. Setup.php makes several `wfDebug()` ca... [04:12:30] 3MediaWiki-Core-Team, Librarization: Missing log library when trying to install MediaWiki via WebInstaller (mw-config/index.php) - https://phabricator.wikimedia.org/T88951#1024054 (10bd808) [04:20:04] 3MediaWiki-Installer, MediaWiki-Core-Team, Librarization: Missing log library when trying to install MediaWiki via WebInstaller (mw-config/index.php) - https://phabricator.wikimedia.org/T88951#1024082 (10bd808) [04:20:17] 3MediaWiki-Installer, MediaWiki-Core-Team, Librarization: Missing log library when trying to install MediaWiki via WebInstaller (mw-config/index.php) - https://phabricator.wikimedia.org/T88951#1024083 (10bd808) p:5Triage>3Normal [04:20:37] 3MediaWiki-Installer, MediaWiki-Core-Team, Librarization: Missing log library when trying to install MediaWiki via WebInstaller (mw-config/index.php) - https://phabricator.wikimedia.org/T88951#1024084 (10bd808) a:5bd808>3None [05:07:45] Tim-away: are you planning on doing any more performance work on VisualEditor? The tooling is a bit better now, so it's a bit less like pulling teeth. [05:08:39] I could have a look, if you think there's any point [05:11:08] yeah. do you have kcachegrind / qcachegrind installed? I have a v8 trace of VE initialization in a compatible format [10:59:18] 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Deploy a Wikidata complex query service into production - https://phabricator.wikimedia.org/T85159#1024547 (10faidon) [11:02:57] 3Phabricator, MediaWiki-Core-Team, Security-Reviews: Install PHPExcel so I can export reports - https://phabricator.wikimedia.org/T152#1024566 (10Aklapper) [11:21:29] 3Echo, MediaWiki-extensions-CentralAuth, SUL-Finalization, MediaWiki-Core-Team: "User must be logged in to view notification!" exception during global merge - https://phabricator.wikimedia.org/T78423#1024630 (10Aklapper) >>! In T78423#849298, @Legoktm wrote: > I think https://gerrit.wikimedia.org/r/#/c/179969/ m... [12:47:49] 3MediaWiki-extensions-SecurePoll, MediaWiki-Core-Team: Set up mini wikifarm in Labs which has SecurePoll on it - https://phabricator.wikimedia.org/T88725#1024715 (10Anomie) >>! In T88725#1022247, @bd808 wrote: > @anomie Does your existing securepoll testing setup in labs cover this need? I started to setup a new... [16:01:20] anomie|sick: :( feel better [16:05:18] 3Datasets-General-or-Unknown, MediaWiki-Core-Team: Improve Wikimedia dumping infrustructure - https://phabricator.wikimedia.org/T88728#1025007 (10Lydia_Pintscher) I started adding Wikidata's open dump issues in a subtask. [16:06:58] bd808: I'm probably going to go have a nap once my SWAT patch is SWATted. [16:48:37] greg-g: Who'll do the MediaWiki trains this week? [16:52:39] hoo: mukunda, aka twentyafterfour [16:52:58] (see also: the calendar, I just updated) [16:53:19] Ah ok, good to know. [17:04:34] 3operations, Incident-20150205-SiteOutage, MediaWiki-Core-Team, Wikimedia-Logstash: Prototype Monolog and rsyslog configuration to ship log events from MediaWiki to Logstash - https://phabricator.wikimedia.org/T88870#1025205 (10bd808) I spent some time yesterday looking into what this will take. It turns out to... [17:33:20] <^d> Gah, why do we have 2 commonswiki_file_* indexes? [17:34:14] <^d> One from november, one from october. [17:34:25] <^d> (so it's not a currently-running rebuild...) [17:35:32] * ^d needs a manybubbles [17:36:54] <^d> I think one can be dropped. Either way, we're wasting ~200GB of disk. [17:43:20] <^d> manybubblesssssssss [17:44:00] <^d> <^d> Gah, why do we have 2 commonswiki_file_* indexes? [17:44:01] <^d> <^d> One from november, one from october. [17:44:01] <^d> <^d> (so it's not a currently-running rebuild...) [17:44:02] <^d> <^d> I think one can be dropped. Either way, we're wasting ~200GB of disk. [18:03:19] bd808: coming? [18:03:27] doh. yes [18:03:34] ^d: whining doesn't ping [18:03:38] ^d: yeah - nuke one [18:06:24] <^d> manybubbles: Seems like the newer one from Nov. is the unaliased one [18:06:26] <^d> commonswiki_file_1415166263 [18:06:41] ^d: if unaliased can delete [18:07:42] <^d> {"acknowledged":false} [18:07:43] <^d> Wot? [18:08:22] <^d> Hmm, must've gone anyway. Not seeing it in the index list [18:28:30] csteipp: hi... can we finally close the Capiunto security review bug? That extension is laughable, as an attack vector [18:29:15] hoo: I really am meaning to take a look at it. It's deployed, right? [18:30:02] No, it's not... partly because of that [18:30:38] And... please have a look... I promise that it wont take you long :) [18:37:45] hoo: Cool, I will. Sorry, I thought it was deployed, so it was in my "someday" queue [18:50:07] 3MediaWiki-extensions-CentralAuth, MediaWiki-Core-Team: Global Rename Queue to default sort in descending order, or be placed at the end of the list - https://phabricator.wikimedia.org/T88886#1022438 (10Legoktm) [19:40:13] * ^d mutes gpl thread [19:41:45] ^d: welcome to the club :) [19:45:27] Licensing discussions are a tarpit [19:47:02] bd808: I'm not sure what to do about https://gerrit.wikimedia.org/r/#/c/189148/, we have composer install --no-dev checked in to the repo, except it needs --dev to run the tests... [19:47:20] * bd808 looks [19:48:22] Hashar's test code should run "composer update" rather than "composer install" [19:48:59] install is really only for replaying the compsoer.lock file [19:49:39] Add this to the never ending list of non-intuitive Composer issues [19:52:07] legoktm: why do we have a composer.lock versioned there? [19:52:16] just because? [19:52:20] bd808: because the whole vendor directory is checked in? [19:52:33] ah ok [19:54:30] legoktm: replied on the patch [19:55:35] thanks [19:59:49] bd808: can you run "composer update" without ever having run composer install? [20:00:07] hmmm... I think so but lets find out [20:00:24] * legoktm tests [20:00:54] yes [20:05:36] * legoktm 's composer is still running >.> [20:05:39] hi hashar o/ [20:05:39] bd808: submitted https://gerrit.wikimedia.org/r/#/c/189543/ [20:05:51] legoktm: hey :-] [20:06:16] legoktm: I have no idea what is different between install and update :-/ [20:06:57] install respects the composer.lock file and will not make changes to the local vendor that are nto specified there [20:07:21] update instead respects the composer.json and will update composer.lock as needed [20:07:50] legoktm: if you get some composer gurus to endorse this patch. I will be happy to +2 it [20:08:00] the badly explained idea from upstream is that you can distribute a fixed set of dependencies via a versioned composer.lock file [20:09:33] hashar: I think bd808 counts as a composer guru :) [20:09:46] I play one in this channel anyway ;) [20:10:42] jeoren and tyler probably know way more about it all than I do [20:10:56] I was playing with composer internals over the weekend and discovered that it forces all package names to lowercase :( [20:11:07] normalize all the things [20:12:27] legoktm: In what crazy world did you want case to matter in package naming? This is php after all [20:12:49] legoktm: I have commented on the change. Feel free to deploy using JJB (I gave instructions) and +2 if all jobs are happy :] [20:13:39] hashar: thanks, I'll try that after lunch [20:14:38] bd808: well, I was trying to install a "package" named "Extension:MassMessage" and had a custom Repository class thing providing it, and it told me that the package "extension:massmessage" could not be resolved because of course, the packages in the repository weren't normalized [20:15:08] doh. That sounds like a bug actually [20:18:11] yeah, I think the ArrayLoader needs to normalize. Once I figured out how the code worked, it was pretty simple to create a custom repository thing: http://fpaste.org/183466/13035142/raw/ [20:20:14] 3MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025793 (10Lahwaacz) 3NEW [20:22:06] Is that really an mwcore problem? ^ [20:23:09] 3MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025820 (10bd808) 5Open>3stalled Hi @Lahwaacz, unfortunately this report is not very useful because it does not describe the problem well. If you have time and can still reproduce the pro... [20:23:29] * bd808 uses macros for great profit [20:23:42] does phab have them built in? [20:23:52] * hashar tries to understand bd808 newly created programming language based on obscure macros [20:24:21] greg-g: no, but you can get them from https://github.com/wikimedia/wikimedia-bugzilla-triagescripts [20:24:42] https://github.com/wikimedia/wikimedia-bugzilla-triagescripts/blob/master/wikimedia-maniphest-task.user.js [20:25:07] Because Andre is awesome like that [20:25:56] 3MediaWiki-Special-pages, MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025837 (10matmarex) [20:26:43] bd808: somewhat? aaron rewrote that a few months ago, causing this. was discussed on wikitech-l or mediawiki-l recently [20:27:13] (activeusers is heavily cached and slowly updated, which means it works at all on wikipedias, but doesn't work very well on small wikis) [20:27:51] *nod* [20:28:11] (the report was obviously filed in your component accidentally, though) [20:28:29] so basically on a wiki where it could change rapidly they would like less aggressive caching? [20:28:44] (why do we not have a #MediaWiki umbrella, anyway?) [20:28:53] There's a bug for that ;) [20:29:31] I don't remember where is is though and search is still teh suck [20:29:33] bd808: yes. right now, every time you refresh the page, it calculates data for the next 20 minutes (or something like that) [20:29:58] not the last 20 minutes, even; the *next* 20 minutes, since the timestamp on the existing cached data [20:30:49] which is obviously suboptimal when your entire wiki has a hundred or so of users, and a few dozen edits daily at most [20:31:00] Sounds like low priority fix to me but I could see why some folks would think otherwise [20:31:19] https://phabricator.wikimedia.org/T76942 [20:32:32] Oh yeah. I remember that last comment now [20:35:06] 3MediaWiki-General-or-Unknown, Project-Creators, Phabricator, MediaWiki-Core-Team: Allow to search tasks about MediaWiki core and core only (create MediaWiki umbrella project?) - https://phabricator.wikimedia.org/T76942#1025866 (10matmarex) >>! In T76942#946690, @Nemo_bis wrote: >> rename MediaWiki-General-or-Un... [20:49:05] 3MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025920 (10Lahwaacz) 5stalled>3Open [20:49:48] http://taylorswift.tumblr.com/post/110565280685/so-um :((( [20:50:41] 3MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025793 (10Lahwaacz) [20:51:37] bd808: """I hate Makefiles but I'm all for continuing to standardize""" . Yeah makefile is a drawback, this way I am not taking a side between npm/composer/tox whatever :] [20:52:14] By making everyone add another build management tool :/ [20:52:34] bah [20:52:43] phabricator's lack of edit conflict detection strikes again [20:52:45] can't we just standardize on a directory that will be mirrored if it exists after the jenkins run? [20:52:46] 3MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025950 (10Lahwaacz) @bd808 Unfortunately I have accidentally hit Enter while submitting the report, which has saved it prematurely... [20:53:36] bd808: a standard output did would be ideal indeed something like /build/docs/ [20:53:53] yes. let's do that instead of picking a tool [20:54:03] 3MediaWiki-Core-Team: Caching of Special:ActiveUsers is broken on small wikis - https://phabricator.wikimedia.org/T89027#1025960 (10matmarex) (Phabricator's lack of edit conflict detection, which you just ran into, is tracked as T78236 :/ ) [20:54:49] that is the idea. Jenkins invokes 'make docs' and grab from '/build/docs/' . Up to developers to run whatever they need to get doc (some repos might need doxygen + jsduck + kss for example ) [20:57:19] but make is picking a tool. I thought you were heading towards per-language entry points like `composer test` and `npm test` [20:58:04] https://wiki.jenkins-ci.org/display/JENKINS/Travis+YML+Plugin [20:59:38] What's this craziness? You can write Jenkins plugins as ruby gems? -- https://github.com/jenkinsci/travis-yml-plugin [21:04:15] jRuby ? :D [21:07:06] hashar: looks like it (https://github.com/jenkinsci/jenkins-plugin-runtime.rb) [21:19:16] marxarelli: yeah that is crazy [21:19:41] in our setup we can just reuse Travis Worker which reads the .travis.yaml [21:19:49] have it connect to Zuul has a worker [21:19:55] and get rid of Jenkins! [21:20:24] legoktm, csteipp: gentle reminder that we have a meeting tomorrow to talk about use-cases/user stories for AuthStack in case you haven't thought about that since last week [21:33:47] bd808: I've put the boilerplate in place for our meeting in 30 min [21:34:48] I didn't get any feedback on my email. Maybe we should discuss the proposed change today? [21:35:14] eg email Bryan your "we did this" stuff on Fridays [21:35:40] and then focus the meeting on problems and planning rather than book reports [21:36:21] I can even spam people to remind them to write the short email if needed [21:36:40] yeah, let's make that an item [21:37:28] * robla goes back to read the Friday email [21:41:10] 3MediaWiki-Core-Team, Librarization: Blog post about work on librarization project and future hopes - https://phabricator.wikimedia.org/T85482#1026099 (10bd808) 5Open>3Resolved [21:49:51] bd808: you list WDQL, AuthStack, Multi-DC, and Security as the 4 areas to cover in your mail, but the template is different [21:50:02] I think your list is probably correct [21:51:42] Those are the "big ticket" projects this quarter I think. I was trying to focus towards SoS which won't care about misc stuff unless it is a back-compat breaking change or a pre-release announcement [21:52:39] making sure everybody can do show and tell is important too but maybe we can get better at that by making room to talk about things people are excited/anxious about [22:09:57] 3operations, MediaWiki-Core-Team: Store unsampled API and XFF logs - https://phabricator.wikimedia.org/T88393#1026201 (10ori) >>! In T88393#1016697, @ori wrote: > if we have a cron job pick up any files in archive/ that logrotate failed to compress for whatever reason, we could close this task and feel good abou... [22:12:47] ^d, greg-g: the ticket for that error page stuff is https://phabricator.wikimedia.org/T76560 [22:15:46] bd808: added to our SoS section of our team meeting tomorrow [22:15:54] greg-g: thanks! [22:16:30] I don't think Nirzar is on irc :( He pings me on google chat [22:31:01] legoktm: with brad out today, can you fill on the AuthStack section? [22:31:12] *fill in [22:32:03] sure [22:32:15] if I can get the google doc to reload... [22:32:55] * bd808 curses office wifi [23:01:35] <^d> bd808: Google Chat? I've had that disabled for > 2 years now. [23:01:40] * ^d can't get pings that way [23:01:55] ^d: I know right? Designers ;) [23:02:18] I have it on to talk to folks outside the WMF like my brothers [23:06:57] bitlbee! [23:09:47] My adium is connected to 2 google talk accounts, aim, icq, and a private jabber server at the moment [23:19:46] 3MediaWiki-Configuration, MediaWiki-Core-Team: Support something similar to a resource template for localBasePath and remoteExtPath duplication in extension.json - https://phabricator.wikimedia.org/T88786#1026539 (10Jdforrester-WMF) 5Open>3Resolved [23:52:25] legoktm: mh... when adding the extension.jsons, wouldn't it be good to at least add a not to the .php version to keep them in sync?