[00:03:45] bd808: https://logstash.wikimedia.org/#/dashboard/elasticsearch/session-ip is extremely neat kudos ! [00:55:45] * bd808 decides to call it a day and find a beer [01:29:26] bd808: is there an easy way to log the context in vagrant? [01:43:55] tgr: enable the psr3 role and change the log format. [01:43:57] The logstash encoder is probably the most complete [01:43:58] S/encoder/formatter/ [01:48:44] tgr: also, step away from the keyboard, eat something, and then play with huwiki or something fun for you [02:00:01] anybody wants to review two patches from https://phabricator.wikimedia.org/T126830 ? [20:20:08] bd808: Hm.. trying out your xargs composer require trick for require-dev on-top-of- mw/vendor [20:20:17] seems to work but getting a weird error at run time [20:20:22] https://integration.wikimedia.org/ci/job/krinkle-mediawiki-phpunit-hhvm-composer-dev/4/console [20:20:25] Psr/Interface missing [20:20:28] not sure I understand why [20:21:10] On a Jenkins slave, after closing mw core and vendor, stuff works (e.g. eval.php prompt) [20:21:23] then, after $ cd vendor; composer require jakub-onderka/php-parallel-lint=0.9.2; the next process fails [20:21:32] PHP Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found in /mnt/jenkins-workspace/workspace/krinkle-mediawiki-phpunit-hhvm-composer-dev/src/includes/profiler/TransactionProfiler.php on line 36 [20:23:14] Looks like it's deleting a ton of stuff from the autoloader map internally [20:30:20] * bd808 looks [20:31:27] Krinkle: remind me where I wrote that stuff down? [20:31:52] -+ vendor/composer/ClassLoader.ph [20:31:54] - * ClassLoader implements a PSR-0, PSR-4 and classmap class loader. [20:31:54] + * ClassLoader implements a PSR-0 class loader [20:32:05] bd808: https://phabricator.wikimedia.org/T112895 [20:32:29] It strips out CSSJanus, Monolog, Psr and various others as soon as I run that composer require command [20:32:43] Also tried with --dev but no difference (other than it addng it to that part of the file) [20:34:23] [20:31 UTC] jenkins-deploy at integration-slave-trusty-1016.integration.eqiad.wmflabs in /mnt/jenkins-workspace/workspace/krinkle-mediawiki-phpunit-hhvm-composer-dev/src/vendor ((no branch)*%) [20:34:27] Try there if you like [20:35:07] git checkout . && git clean -df && php ../maintenance/eval.php; works; then $ composer require --dev composer require jakub-onderka/php-parallel-lint=0.9.2; and observe git diff [20:36:28] hmmm. slave-trusty-1016 won't let me ssh in. Maybe I got removed from the porject? [20:36:30] * bd808 looks [20:37:22] logging in to the new version of wikitech is soooo sloooow for me [20:37:34] apparently I'm in too many projects :/ [20:37:36] you're ij the admins and member list of integration [20:37:42] Should be fine [20:38:16] "channel 0: open failed: administratively prohibited: open failed" [20:38:34] Maybe wrong bastion or ssh forwarding? [20:38:53] I can log into other labs instances [20:39:30] oh, missing the integration- at the start [20:39:36] :) [20:39:45] then sudo -su jenkins-deploy and cd there [20:40:26] some paste here https://gist.github.com/Krinkle/5952c16f08ed292896f2 [20:42:17] composer show --installed output looks ok [20:42:32] so something is making it build a bad classmap I guess [20:42:43] maybe not using --optimize [20:44:46] running `composer dump-autoload -o` changes the diff a bit [20:45:34] Hm.. it ignores the config in composer.json? [20:45:45] I thought that was fixed like 1-2 years ago upstream [20:46:12] https://github.com/composer/composer/issues/3505 [20:47:32] composer's commands area bit of a mess :/ [20:48:10] heh. our `composer --version` is pretty useless [20:48:40] Indeed [20:48:53] bd808: https://github.com/wikimedia/integration-composer [20:48:58] alpha10 [20:49:02] so that fix should be in [20:49:10] alpha10 is oooold [20:49:17] alpah11 is latest? [20:49:42] alpha11 is ooold too [20:49:49] 449 commits to master since then [20:49:49] :) [20:49:57] Any breaking changes? [20:50:07] Looks like we reverted alpah11 back to 10 [20:50:09] alpha10 - 1143 commits to master since this release [20:50:17] Yeah [20:50:19] Well [20:50:35] They have stability issues. It's a moving target that's in need of a stable 1.0 release [20:50:53] Kind of like MediaWiki ;) [20:51:42] bd808: So.. I guess mw/vendor is built with a newer composer? [20:51:54] yes. generally with HEAD [20:51:59] from people's local machines [20:52:02] Rrrright [20:52:06] How about we update the ci instal then [20:52:11] could be fun [20:52:16] Was the revert reason resolved/ [20:52:38] PHP Strict Standards: [20:52:39] Declaration of Composer\Console\Application::renderException() should be [20:52:39] compatible with that of Symfony\Component\Console\Application::renderException() [20:52:39] in [20:52:39] integration/composer/vendor/composer/composer/src/Composer/Console/Application.php [20:52:39] good question [20:52:39] on line 38 [20:53:46] I'm not sure where hashar was running the command to get the error [20:54:02] Yeah, this showed up at run time [20:54:04] I think [20:54:15] Which is breaking in our case as we dont allow that during phpunit runs [20:54:33] It's a side-ways strict violation between two upstreams [20:54:39] composer and symfony [20:54:42] cluster fuck [20:54:57] mismatched versions certainly [20:55:51] `composer status` works for me locally with the latest Composer from master installed [20:56:04] https://github.com/composer/composer/commit/2491679ba3584886c191f5869303b9c431af3b91 [20:56:06] fixed [20:56:09] but unreleased [20:56:19] ok. let's try it ? [20:56:57] typical travisci tests do `composer self-update` before anything else :) [20:57:34] Composer has https strict downloads now too in master [20:57:38] which is nice [20:57:51] they are pushing towards a stable 1.0 [20:58:45] Krinkle: short of the big upgrade, just adding a classmap rebuild after the requires might work [20:58:56] and it wouldn't ever hurt anything [20:59:14] bd808: so 'composer dump-autoload -o' ? [20:59:20] yes [20:59:31] or --optimize to be more explicit in the script [20:59:56] * bd808 hates shell scripts with short args [21:17:44] Getting a little bit closer this time [21:17:44] https://integration.wikimedia.org/ci/job/krinkle-mediawiki-phpunit-hhvm-composer-dev/5/console [21:17:51] Now it's a runtime failure in phpunit [21:17:56] there's a bogus --conf parameter [21:19:20] bd808: is there some special config needed to send log events to elk on vagrant? [21:20:03] tgr: that role may be broken. I don't think I've used it since the psr3 role was added [21:20:19] it *used* to set everything up [21:20:32] it may conflict with the psr3 role as well [21:23:20] OK. it's running now! [21:23:21] https://integration.wikimedia.org/ci/job/krinkle-mediawiki-phpunit-hhvm-composer-dev/6/console [21:23:36] holy crap! good job Krinkle [21:25:06] and it passed! [21:30:36] Yay [21:30:45] same number of skipped tests (18) [21:31:07] a new group of 'risky tests' (due to @todo tag, this is a new type of strict, and which is why --strict is deprecated) [21:31:16] total test number is.. higher? [21:31:33] new: Tests: 11003, Assertions: 71200, Skipped: 18, Risky: 36. [21:31:42] old: Tests: 9403, Assertions: 68509, Skipped: 18. [21:32:23] Ah, probably because it merges lcoally with latest master. Let's see if they get closer if I run the old one again [22:06:55] bd808: OK. So i've got three patches ready that will switch from hardcoded phpunit to vendor-dev phpunit (without upgrading yet), and then when we upgrade in core it would "just work" [22:07:29] switch to local: 1) https://gerrit.wikimedia.org/r/#/c/270489/ 2) https://gerrit.wikimedia.org/r/#/c/270515/ 3) https://gerrit.wikimedia.org/r/#/c/270545/ [22:07:40] actual upgrade: https://gerrit.wikimedia.org/r/#/c/270485/ [22:08:13] Got bored of Paladox "helping"? :P [22:08:40] -_- [22:12:58] Krinkle: awesome. Want to do https://phabricator.wikimedia.org/T92605 next? :) [22:15:02] "Update composer to dev-master" [22:15:05] Oh ok [22:16:12] https://phabricator.wikimedia.org/T112895#2025963 [22:16:28] Please sanity check / review / +1 the patches linked there [22:16:40] bd808: I was doing a simialr patch locally while waiting for our hack to work [22:16:47] But deleted it [22:17:31] bd808: no thanks :) Not today [22:17:45] fine be that way ;) [22:20:20] Krinkle: Enjoying talking to a brick wall? [22:20:47] Reedy: Well, he's gotten better. I used to be more ignoring.