[02:21:02] <Krinkle>	 Hm.. job insertion errors should be rare but this suggests it might not be https://phabricator.wikimedia.org/T204183
[02:21:28] <Krinkle>	 But it's hard to compare, we have much  better logging now, but I don't recall seeing redis insertion errors in the past.
[08:39:57] <addshore>	 Is there a list of repos somewhere that mediawiki-vendor is meant to serve / contain the libs for?
[08:40:21] * addshore goes to find a way to get all wmf deployed extensions with a composer.json that actually requires some package
[08:50:04] <addshore>	 This will do :D ... find . -name 'composer.json' -exec grep -H "require\"" {} \;
[08:52:49] * addshore leaves his finished version in the irc logs for searchability...
[08:52:50] <addshore>	 find . -name 'composer.json' -exec grep -H "require\"" {} \; | sed 's/:.*//' | sed 's/\/composer.*//' | sed 's/\.\///'
[08:55:33] <hashar>	 addshore: mediawiki/vendor would hold dependencies for the extensions deployed on wmf.  The reference of extensins would be in mediawiki/tools/release in make-wmf-branch
[08:55:44] <hashar>	 addshore: surely CI should be switched to default to composer
[09:00:17] <addshore>	 hashar: well, I just finished writing some crappy script to compare what is in mediawiki-vendor vs what will actually be installed if you install all of our extensions
[09:01:24] <hashar>	 oh
[09:01:37] <hashar>	 addshore: oh also there is a bit more madness going on
[09:01:57] <addshore>	 hehe, of course :P
[09:02:09] <hashar>	 mediawiki/vendor would hold all dependencies for deployed extensions
[09:02:14] <hashar>	 that is for the master and wmf/ branches
[09:02:18] <addshore>	 yuppp
[09:02:31] <hashar>	 but mediawiki/vendor RELXXX branches only hold dependencies for the extension in the mediawiki tarball
[09:02:47] <hashar>	 so if you have an extension that is not in the tarball and the extension has dependencies via composer
[09:02:52] * addshore cares about https://phabricator.wikimedia.org/T179663
[09:02:56] <hashar>	 the job will fail on the REL branch because vendor lacks the depedencies
[09:03:06] <hashar>	 there is a task about it somewhere. And probably we should just use composer instead
[09:03:30] <hashar>	 and iirc
[09:03:30] <addshore>	 heh
[09:03:31] <addshore>	 The requested package monolog/monolog ~1.18.2 exists as monolog/monolog[1.22.1] but these are rejected by your constraint.
[09:03:38] <hashar>	 doh
[09:04:01] <addshore>	 DonationInterface has "monolog/monolog": "~1.18.2", but apparently that is not installable
[09:04:03] <hashar>	 the quibble jobs using vendor do not run composer install,  though they do install the require-dev dependencies
[09:04:32] <hashar>	 DonationInterface is a special case.  Its master branch is tested  with  vendor and core branch fundraising/REL1_27
[09:04:43] <hashar>	 because the fundraising cluster runs on a fork of REL1_27
[09:04:52] <addshore>	 okay, I'll just take DonationInterface out of my list for now :)
[09:04:55] * addshore re runs
[09:04:57] <hashar>	 yeah ;]
[09:05:30] <hashar>	 https://phabricator.wikimedia.org/T203084  has the quibble / zuul-cloner command being used
[09:06:05] <hashar>	 (note: quibble is passed parameters that are then passed to zuul-cloner:  --branch REL1_27 --project-branch mediawiki/extensions/DonationInterface=master --project-branch mediawiki/vendor=fundraising/REL1_27
[09:06:16] <addshore>	 evil DOnationInterface
[09:06:36] <hashar>	 yeah it is a special case really
[09:13:26] <addshore>	 I could pretty easily write a jenkins job for the hackey thing I have just written, and then have it running daily
[09:13:40] <hashar>	 ah
[09:14:00] <hashar>	 addshore: so for that in integration/config there are some python tests that are run on a daily basis
[09:14:20] <addshore>	 really? comparing mediawiki-vendor and what should be there? or?
[09:14:25] <hashar>	 which generates some dashboard https://integration.wikimedia.org/ci/job/integration-config-qa/lastCompletedBuild/testReport/
[09:14:44] <addshore>	 aah, okay
[09:14:48] <hashar>	 but that does not clone mediawiki-vendor :]
[09:15:01] <addshore>	 I mean, this script is shitty, but it works :P
[09:15:05] <hashar>	 good!
[09:15:17] <hashar>	 I guess you can just create yet another jenkins job so
[09:15:23] <addshore>	 yup
[09:18:18] <test_>	 im dumb
[09:21:19] <addshore>	 https://www.irccloud.com/pastebin/iV25Ch7D/
[09:21:20] <addshore>	 hashar: ^^
[09:21:27] <addshore>	 those are the current differences then :)
[09:21:44] <hashar>	 diff between ?
[09:21:54] <addshore>	 master (being core and extensions master) and vendor
[09:22:07] <hashar>	 I guess because some are not pinned
[09:22:21] <addshore>	 so if you take all extensions that are deployed and have a composer.json and install them using the composer merge plugin, VS what is pinned in mediawiki-vendor
[09:22:30] <hashar>	 probably we could make that a job for mediawiki/core and mediawiki/vendor to ensure master/wmf branches are in sync
[09:22:34] <addshore>	 or updated and mediawiki-vendor was not updated
[09:22:45] <hashar>	 hmm
[09:22:52] <hashar>	 I would guess some of those deps are not explicitly pinned
[09:23:02] <hashar>	 maybe james-heinrich/getid3     has "1.9.*"
[09:23:42] <addshore>	 well, james-heinrich/getid3 isn;t in mediawiki/composer.json it is required only by extensions it would seem
[09:23:59] <hashar>	 TimedMediaHandler/composer.json:		"james-heinrich/getid3": "^v1.9"
[09:24:01] <addshore>	 "james-heinrich/getid3": "^v1.9" in TimedMediaHandler
[09:24:17] <hashar>	 JADE/composer.json:		"justinrainbow/json-schema": "~5.2"
[09:24:17] <hashar>	 Kartographer/composer.json:		"justinrainbow/json-schema": "~5.2"
[09:24:19] <addshore>	 but that's fine, versions don't have to be pinned there
[09:24:26] <addshore>	 only in mediawiki-vendor
[09:24:43] <addshore>	 my main point is though, someone really has to keep an eye on mediawiki-vendor
[09:26:42] <addshore>	 I guess I should make the patches to update those libs in mediawiki-vendor now
[09:27:27] <addshore>	 the status of that job should basically be checked before each branch cut, and mediawiki-vendor fixed if needed
[09:32:14] * addshore made 3 patches for those libs
[10:41:31] <hashar>	 addshore: going to have a nap and I will look at adding WikibaseLexeme & all to the extensions gate
[11:56:38] <Reedy>	 addshore: The last release of getid3 was broken
[11:56:51] <Reedy>	 https://github.com/JamesHeinrich/getID3/releases
[11:57:16] <Reedy>	 Only in demos, but still
[11:57:17] <Reedy>	 https://github.com/JamesHeinrich/getID3/commit/adb28c2e69ec0c6ca722e8363016d8a042069b37
[11:57:29] <Reedy>	 So I added PHP linting
[11:57:29] <Reedy>	 https://github.com/JamesHeinrich/getID3/commit/1f9135a8a59184402c7e47f3c95b9e70d5369d28
[11:57:36] <addshore>	 haha
[11:57:40] <Reedy>	 And made travis do shit
[11:57:41] <Reedy>	 https://github.com/JamesHeinrich/getID3/commit/f178850e6ccbee87e47c10361585d5cc99f679db
[11:58:12] <Reedy>	 Really, what we need is to get something like https://phabricator.wikimedia.org/T180278 actually done
[11:58:21] <Reedy>	 So we know if we have actual issues, or just version number creep :P
[12:00:22] <Reedy>	 addshore: Of course...
[12:00:30] <Reedy>	 WMDE/Wikidata is the worst offender in vendor
[12:01:01] <Reedy>	 6/28 are yours
[12:01:56] <Reedy>	 Oh, probably more
[12:02:03] <Reedy>	 Because some of the symfony stuff are WMDE stuff :P
[12:02:23] <Reedy>	 I'm happy to do a bump on the pear stuff at least
[12:07:12] <Reedy>	 https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460336/
[12:07:19] <Reedy>	 Core doesn't pin them, so nothing to update there
[12:08:53] <Reedy>	 addshore: https://github.com/justinrainbow/json-schema/pull/495 looks fine to bring in
[12:09:51] <addshore>	 Reedy: really the extension that requires getid3 should state it doesn;t want this broken version
[12:09:58] <addshore>	 then in the script I just wrote, it won't get pulled in
[12:10:10] <Reedy>	 lol
[12:10:13] <Reedy>	 It's not a big deal
[12:10:19] <addshore>	 no, but then the script works :P
[12:10:19] <Reedy>	 We could bring it in, and just delete the demo
[12:10:28] <Reedy>	 But the script has only just been created, sooo
[12:10:38] <addshore>	 I actually already added the demo dir to the gitignore of mediawiki-vendor
[12:10:48] <Reedy>	 That works too
[12:10:52] <addshore>	 because, it thought, why on earth are we pulling demo stuff in :P
[12:11:05] <addshore>	 thats already in the PS for mediawiki-vendor
[12:11:17] <Reedy>	 Why on earth are they including them in their exports? :P
[12:11:37] <addshore>	 because people know nothing
[12:11:56] <Reedy>	 Are they all Jon Snow?
[12:12:01] <addshore>	 indeed
[12:12:07] <addshore>	 oooh, when does got start again..
[12:12:13] <Reedy>	 Fucking ages, I think
[12:12:17] <Reedy>	 upstream patches a go go
[12:18:45] <Reedy>	 addshore: https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460339/
[12:19:31] <Reedy>	 that was confusing me for a minute
[12:19:48] <addshore>	 heh
[12:19:56] <Reedy>	 like, why is that committed...
[12:21:26] <Reedy>	 damn i
[12:21:26] <Reedy>	 t
[12:21:28] <Reedy>	 trailing commas
[12:25:20] <Reedy>	 12:21:52 The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update`.
[12:25:26] <Reedy>	 composer update is a noop
[12:27:12] <Reedy>	 typical, validate gives different errors locally
[12:32:42] <addshore>	 :D
[12:33:18] <Reedy>	 wait and see what fails in the end
[12:43:26] <Reedy>	 srsly, what is this shit
[12:44:40] <Reedy>	 hashar: Anything special about mwgate-composer-hhvm-docker ?
[12:45:50] <hashar>	 Reedy: it runs composer in docker ? :]
[12:45:52] <hashar>	 what is happening?
[12:46:02] <Reedy>	 It's failing with 12:21:52 The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update`.
[12:46:06] <Reedy>	 on https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460339/
[12:46:13] <Reedy>	 But if I run composer validate locally, no error
[12:46:23] <Reedy>	 and composer update is a noop
[12:46:55] <hashar>	 try locally ?
[12:47:11] <Reedy>	 I did, no error :P
[12:56:55] <hashar>	 Reedy: maybe it is a stale cache :/
[12:57:11] <Reedy>	 silly thing
[13:08:59] <hashar>	 well
[13:09:01] <hashar>	 cache pruned
[13:09:04] <hashar>	 but https://integration.wikimedia.org/ci/job/mwgate-composer-hhvm-docker/1318/console failed nonetheless
[13:10:15] <Reedy>	 Could obviously be a composer bug
[13:12:40] * Reedy downgrades composer to check
[13:14:56] <Reedy>	 Nope, 1.6.5 locally doesn't give that error
[13:15:46] <Reedy>	 Annoying
[13:16:08] <hashar>	 Reedy: seems to be an issue with that patch
[13:16:18] <hashar>	 I debugged on the slave directly
[13:16:32] <hashar>	 ssh integration-slave-docker-1010.integration.eqiad.wmflabs
[13:16:38] <hashar>	 cd /srv/jenkins-workspace/workspace/mwgate-composer-hhvm-docker
[13:16:42] <hashar>	 sudo docker run --rm -it --workdir=/src --entrypoint=composer --volume /srv/jenkins-workspace/workspace/mwgate-composer-hhvm-docker/src:/src docker-registry.wikimedia.org/releng/composer-test-hhvm:0.2.5 --ansi validate --no-check-publish -vvvv
[13:16:50] <hashar>	 that fails with the patch you send
[13:17:20] <hashar>	 trying again with: git fetch https://gerrit.wikimedia.org/r/mediawiki/vendor refs/changes/39/460339/2 && git checkout FETCH_HEAD
[13:17:25] <hashar>	 yeah that patch fails composer validate
[13:17:33] <Reedy>	 it doesn't locally though
[13:17:44] <hashar>	 but master works fine
[13:17:48] <Reedy>	 there's the usual...
[13:17:48] <Reedy>	 Remove jakub-onderka/php-console-highlighter from require-dev
[13:17:48] <Reedy>	 It's already in require, so having both is confusing and redundant
[13:17:50] <Reedy>	 ffs
[13:17:53] <Reedy>	 name : The property name is required
[13:17:53] <Reedy>	 description : The property description is required
[13:18:43] <Reedy>	 hashar: What does `composer update --no-dev` change?
[13:19:51] <Reedy>	 With or without --no-dev locally there's no lock file changes
[13:21:19] <hashar>	 trying
[13:24:40] <hashar>	 Reedy: https://phabricator.wikimedia.org/P7542
[13:25:06] <Reedy>	 That just looks like php version differences
[13:25:13] <Reedy>	 uh, composer version differences
[13:25:18] <hashar>	 the container uses Composer version 1.6.5 2018-05-04 11:44:59
[13:25:23] <hashar>	 which is the one from integration/composer
[13:26:10] <hashar>	 so yeah composer.lock is changed 
[13:26:15] <hashar>	 and would need to be commited in
[13:26:25] <Reedy>	 Hmm
[13:26:36] <Reedy>	 bloody compoters
[13:26:38] <Reedy>	 *computers
[13:27:07] <Reedy>	 https://github.com/wikimedia/mediawiki-vendor/commit/8c405f8f2ff3facd980563fd20f8f7878d27ec3e
[13:27:21] <Reedy>	 I think we need to ask volker what version of composer he's running...
[13:27:25] <hashar>	 see also https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460336/2/composer.lock :]
[13:29:44] <Reedy>	 bleugh :)
[13:29:45] <Reedy>	 Cheers
[13:29:59] <Reedy>	 https://gerrit.wikimedia.org/r/460357 to update the readme to tell people to use at least 1.6.5 too
[13:41:42] <Reedy>	 hashar: heh, new error
[13:41:43] <Reedy>	 13:27:22 Warning: fork failed - Cannot allocate memory in /src/jakub-onderka/php-parallel-lint/src/Process/Process.php on line 47
[13:41:43] <Reedy>	 13:27:22 Cannot create new process php -d asp_tags=Off -d short_open_tag=Off -d error_reporting=E_ALL -n -l './elasticsearch/elasticsearch/src/Elasticsearch/Endpoints/Tasks/Get.php'
[13:41:43] <Reedy>	 13:27:22 Script parallel-lint --exclude composer/autoload_static.php --exclude jakub-onderka/php-parallel-lint/tests --exclude symfony/var-dumper/Tests/Fixtures --exclude psy/psysh/test . handling the test event returned with error code 255
[14:24:07] <Reedy>	 addshore: Want to re CR+2 https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/460339/ please?
[14:24:13] <Reedy>	 Looks like tests are passing finally :P
[14:27:26] <addshore>	 i guess
[14:28:44] <Reedy>	 Then need to rebase shit
[16:22:12] <Reedy>	 addshore: https://gerrit.wikimedia.org/r/460336
[16:26:39] <anomie>	 DanielK_WMDE: When you have a chance, I'd appreciate feedback on T204158.
[16:26:40] <stashbot>	 T204158: Review namespacing of MCR classes - https://phabricator.wikimedia.org/T204158
[19:48:12] <legoktm>	 and this is why we pin dependencies >.<
[19:49:01] <James_F>	 legoktm: Eesh, yes.
[19:57:10] <legoktm>	 gahh, pear's bug tracker just threw away my report because I was supposed to log in first, even though the instructions said you didn't need to login if you provided an email address >.<
[20:05:05] <legoktm>	 https://pear.php.net/bugs/bug.php?id=23768
[20:06:01] <legoktm>	 (yes, pear doesn't let you pick a PHP version higher than 5.6)
[22:44:24] <Reedy>	 legoktm: https://github.com/pear/Net_Socket/tags
[22:44:28] <Reedy>	 Looks like someone has deleted it
[22:45:13] <Reedy>	 Or.. not
[22:45:50] <Reedy>	 ah, it's just github display
[23:05:19] <Krinkle>	 TimStarling: Hm.. from your comment https://phabricator.wikimedia.org/T204010, suggests that the Lucene query bar is equivalent to "query" in DSL, is that right?
[23:06:13] <Krinkle>	 Which means it would be possible to do a complex filter like (foo:x OR bar:y) in a filter (and thus be label-able and disable-able), by using DSL, despite it normally requiring to occupy the Lucene bar on the dashboard.
[23:18:32] <TimStarling>	 yes, true, it is possible to run that query using the query bar