[00:06:14] <Reedy>	 Should be good to go now
[00:07:51] <bd808>	 +2
[00:08:06] * bd808 has not gotten to do a +2 for a while
[00:08:30] <bd808>	 it seems like I've mostly been reviewing python code hidden in our puppet repo
[00:09:11] <Reedy>	 Does anything actually use that code? :P
[00:09:34] <bd808>	 toolforge :)
[00:09:44] <bd808>	 its a cute little project you may have heard of
[00:09:50] <Reedy>	 I was meaning ObjectFactory in mw et al :P
[00:10:19] <bd808>	 ah! Yeah its used in the logger and also in ... some stuff that AaronSchulz built
[00:10:43] <bd808>	 I basically extracted it from Aaron's code and added a couple of features when I was building the logger
[00:10:49] <Reedy>	 silly ide search bugs :)
[00:11:22] <bd808>	 I think maybe bag o stuff and the db layer?
[00:11:32] <Reedy>	 yeah
[00:11:33] <AaronSchulz>	 multiwrite bagostuff
[00:11:59] <bd808>	 oh hi AaronSchulz 
[00:12:05] <bd808>	 long time no see
[00:12:34] <AaronSchulz>	 hey
[00:12:57] <bd808>	 apparently BlueSpiceExtendedSearch uses it too
[00:13:08] <bd808>	 according to github search
[00:13:28] <Reedy>	 Yeah, I just made a patch to make it stop using the global namespace one
[00:13:53] <Reedy>	 Technically, we could kill the compat layer from core then
[00:14:08] <bd808>	 AaronSchulz: how is life in the big city?
[00:15:22] * bd808 had forgotten how fun hadoop can be. 52 minutes of CPU time in 90 seconds of wall clock time
[00:25:24] <Reedy>	 00:08:00 License "GPL-2.0-or-later" is not a valid SPDX license identifier, see https://spdx.org/licenses/ if you use an open license.
[00:25:29] <Reedy>	 What is this about? When it is...
[00:26:17] <bd808>	 Reedy: packagist whining at you?
[00:26:31] <Reedy>	 jerkins https://integration.wikimedia.org/ci/job/composer-package-hhvm-docker/1772/console
[00:26:39] <Reedy>	 so composer
[00:27:11] * bd808 bets on an old as hell composer version
[00:27:45] <Reedy>	 Have we still not fixed that?
[00:30:16] <Reedy>	 https://github.com/wikimedia/integration-composer
[00:43:48] <bd808>	 the reduction in api calls mystery is not answered by traffic source. The 60/30/10 split of internet/internal/cloud calls is pretty consistent from the start of 2017 to now.
[00:44:09] <bd808>	 which I guess means interestingly that the decrease is global and relatively uniform
[00:45:22] * bd808 is not a data analyst and is hungery so will stop looking for now
[00:45:41] <bd808>	 too hungry to spell apparently
[00:45:50] <greg-g>	 bd808: did you just find a new "the decline of editing" graph? :)
[00:46:48] <bd808>	 greg-g: sort of, but this one is a cliff that happens between 2018-03-04 and 2018-03-05. Half of the action api traffic just disappears
[00:47:40] <bd808>	 hmmmm... I wonder actually if there is something that moved mobile apps traffic from the api to restbase service...
[00:48:29] <bd808>	 but... that would not be uniform. it would all be external
[00:48:37] * bd808 shrugs
[00:51:53] <Krinkle>	 Reedy: btw, could you do another rebuildLocalisationCache comparision, this time HHVM on deploy1001 *with* the JIT flag as well?
[00:52:17] <Krinkle>	 We have 40min for Jessie with HHVM, 15min for Jessie with HHVM+JIT, and 15min for Stretch with HHVM (no JIT).
[00:52:24] <Krinkle>	 I'm curious if it's even better with JIT 
[00:52:30] <Reedy>	 What's the flag?
[00:53:02] <Krinkle>	 Reedy: PHP='hhvm -v Eval.Jit=false'
[00:53:03] <Krinkle>	 I think
[00:53:30] <Krinkle>	 Or PHP=' hhvm -vEval.Jit=1
[00:53:36] <Krinkle>	 I forgot which is the default
[00:53:38] <Reedy>	 mwmaint1001 I used last time
[00:54:28] <Krinkle>	 See https://phabricator.wikimedia.org/T191921#4150546
[00:55:09] <Krinkle>	 So yeah PHP='hhvm -vEval.Jit=1' should speed it up in theory
[00:55:43] <Reedy>	 running
[00:55:57] <bd808>	 adding SSDs would speed it up more :)
[00:56:27] <Reedy>	 to beta? :P
[00:56:48] <Krinkle>	 Hehe
[00:56:59] <bd808>	 ah. beta already has SSD I think...
[00:57:14] <Krinkle>	 Also, I see Tyler usually runs it with --threads=6 although I guess as long as we have something to compare with that'd be fine 
[00:57:23] <Krinkle>	 I think threads=6 is what scap uses on beta
[00:57:27] <Reedy>	 Well, if it's quicker with 1 thread... :P
[00:57:36] <Reedy>	 it's already done with c*
[00:57:38] <Krinkle>	 evaluating >>> import multiprocessing >>> max(multiprocessing.cpu_count() - 2, 1); on deploy1001 returns 30
[00:57:46] <Krinkle>	 which is what scap uses
[00:57:58] <Krinkle>	 https://github.com/wikimedia/scap/blob/5c3646ad20df9c872ba6c62cc9ceae3f1e7ee219/scap/tasks.py#L535
[00:58:18] <bd808>	 the VM sees 32 cores?
[00:58:21] <Krinkle>	 Yeah, I don't know if the threads hurt or not.
[00:58:32] <Krinkle>	 bd808: 8 presumbaly
[00:58:51] <Krinkle>	 ..=6 in beta and ..=30 in prod
[00:59:09] <bd808>	 ah, that makes more sense
[01:00:08] <bd808>	 a huge amount of the time in rebuildLocalisationCache is stat calls on all the json source files
[01:00:34] <bd808>	 Unless I'm confused about which script that is
[01:01:52] * bd808 disappears to find food
[01:02:35] <Reedy>	 nds
[01:04:06] <Reedy>	 sa
[01:07:15] <Reedy>	 Krinkle: real    11m45.815s
[01:11:22] <Krinkle>	 Reedy: nice
[01:11:54] <Krinkle>	 Reedy: Could you add that in a brief comment on T191921 so I can cite it elsewhere?
[01:11:54] <stashbot>	 T191921: mwscript rebuildLocalisationCache.php takes 40 minutes on HHVM (rather than ~5 on PHP 5) - https://phabricator.wikimedia.org/T191921
[01:12:03] <Reedy>	 I did :P
[01:12:10] <Reedy>	 https://phabricator.wikimedia.org/T191921#4247675
[01:15:09] <Reedy>	 Krinkle: Hey... Do you reckon those Memcached issues Aaron found might explain some of the weirdness of my devwiki using memcached on PHP7 for a few years?
[01:15:27] <Krinkle>	 Reedy: Maybe :P
[01:15:52] <Krinkle>	 Reedy: Got a link to one of these bug reports or error messags?
[01:16:05] <Reedy>	 https://phabricator.wikimedia.org/T152345
[01:16:27] <Reedy>	 I had some others...
[01:24:17] <Reedy>	 Will test after patch is merged :P
[01:32:16] <Krinkle>	 Reedy: Yeah, it's possible
[01:32:28] <Krinkle>	 I would expect that case to fail quickly with some kind of type error 
[01:32:39] <Reedy>	 silly edge cases :)
[01:33:05] <Krinkle>	 but it's possible the cas() case would time out if it can't detet the issue and just waits for the unlock that failed
[01:33:15] <Reedy>	 Interesting no one else has seemingly had a problem with it
[01:33:23] <Reedy>	 Wonder if Wikia patched it differently/seperately
[01:34:46] <Reedy>	 definitely worth backporting too :)
[01:48:07] <Reedy>	 legoktm: Guess we can bump MW core to codesniffer 20 :P
[01:50:32] <legoktm>	 Reedy: yes :D will need some exclusions in .phpcs.xml for the new sniffs...
[01:50:40] <Reedy>	 stop adding new stuff then!!!
[01:54:38] <Reedy>	 Should do a release of objectfactory and bring that in too
[01:54:41] <Reedy>	 *I should
[01:55:16] <Reedy>	 Is that v2 worthy bumping PHP version? Or just 1.1?
[01:56:52] <legoktm>	 it's a breaking change
[01:57:02] <legoktm>	 so it needs a new major version
[01:57:22] <Reedy>	 So it is a v2 thing?
[01:57:46] <legoktm>	 yeah, 2.0.0
[01:58:22] <Reedy>	 Is it worth letting you do a tour-de-codesniffer first? I'm imaginging 18->20 for that isn't gonna make much difference on that library
[01:59:31] <Reedy>	 Meh, either way, it's not urgent
[02:03:42] <legoktm>	 I don't think it's worth breaking compat unless there's something we gain
[02:04:16] <Reedy>	 less copypasta
[02:12:51] <Reedy>	 https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-mysql-php70-docker/74/console
[02:12:54] <Reedy>	 https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-mysql-hhvm-docker/74/console
[02:12:58] <Reedy>	 Why is quibble a lot faster on hhvm?
[02:15:24] <Reedy>	 legoktm: Any reason we can't use class_alias?
[02:15:50] <legoktm>	 class alias has to be in the file with the class itself
[02:16:09] <Reedy>	 Ah, duh. Makes sense
[02:16:39] <legoktm>	 https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-mysql-php70-docker/buildTimeTrend https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-mysql-hhvm-docker/buildTimeTrend it looks like php70 is generally faster, but the times are all over the place
[02:24:42] <legoktm>	 oops
[02:25:54] <Reedy>	 heh :)
[02:27:40] <legoktm>	 Reedy: how's https://gerrit.wikimedia.org/r/436715 ? was there anything else you needed to change?
[02:28:17] <Reedy>	 LGTM
[02:28:22] <Reedy>	 I think that's all I changed yeah
[02:30:04] <legoktm>	 yeah, I think I changed mind on mass moving libraries to >=7.0
[02:30:58] <Reedy>	 I mean, we don't need to necessarily make releases for them all
[02:31:50] <legoktm>	 right, that can be done whenever it needs to be
[02:32:18] <Reedy>	 Maybe that question of whether we want to do a release before bumping to 7, but that can always be done in retrospect too if necessary
[02:34:21] <legoktm>	 https://gerrit.wikimedia.org/r/436716
[02:37:37] <Reedy>	 02:27:08     - Installation request for mediawiki/phpunit-patch-coverage 0.0.8 -> satisfiable by mediawiki/phpunit-patch-coverage[0.0.8].
[02:37:37] <Reedy>	 02:27:08     - mediawiki/phpunit-patch-coverage 0.0.8 requires wikimedia/scoped-callback ^1.0.0 -> satisfiable by wikimedia/scoped-callback[v1.0.0] but these conflict with your requirements or minimum-stability.
[02:37:55] <Reedy>	 does that library need a patch too?
[02:37:57] * Reedy looks
[02:38:27] <legoktm>	 ugh, I need to fix that job
[02:38:34] <legoktm>	 in the mean time, yes
[02:39:29] <Reedy>	 https://gerrit.wikimedia.org/r/#/c/436718/
[02:40:56] <legoktm>	 ty, I'll tag and update jenkins
[02:41:09] <legoktm>	 filed https://phabricator.wikimedia.org/T196128 for the long term fix
[02:48:52] <TimStarling>	 legoktm: any comment on https://phabricator.wikimedia.org/T196043 before I go ahead and email 9 contributors?
[02:52:54] <legoktm>	 TimStarling: I feel pretty stupid for not noticing the incompatibility earlier, after the issues with faststringsearch binaries not being redistributable. For relicensing, we've typically just assumed consent for WMF employees (especially former ones that might be hard to contact)
[02:53:28] <legoktm>	 And I checked that the FSF also agrees that licenses are incompatible: https://www.gnu.org/licenses/license-list.html#PHP-3.01
[02:54:04] <TimStarling>	 I could just notify the non-staff contributors
[02:56:00] <legoktm>	 I think that should be fine
[03:05:41] <TimStarling>	 btw I'm waiting with baited breath for your interview scorecard
[03:06:38] <legoktm>	 oops, I usually wait a few hours before filling those out, I'll do that now
[03:08:19] <legoktm>	 My favorite part was how 20 minutes before we were supposed to start, Comcast decided to cut our home internet. Yay for mobile hotspots ^.^
[03:44:57] <legoktm>	 TimStarling: submitted it
[03:54:36] <TimStarling>	 thanks
[04:34:09] <legoktm>	 I do wonder where https://salsa.debian.org/mediawiki-team/wikidiff2/blob/7eaf1f37e9f5fa1818fd7e424a8bb13bc17c6619/debian/copyright came from
[04:35:21] <legoktm>	 https://www.mediawiki.org/w/index.php?diff=205080&oldid=183604&title=Extension:Wikidiff2
[04:37:48] <legoktm>	 TimStarling: hmm, I think wikidiff2 has been labeled as GPL since the beginning. See https://www.mediawiki.org/wiki/Special:Code/MediaWiki/12986 
[04:38:02] <legoktm>	 > GPL blah blah, see below for history
[04:38:44] <TimStarling>	 uh huh
[04:40:44] <legoktm>	 + * Some ideas are (and a bit of code) are from from analyze.c, from GNU
[04:40:44] <legoktm>	 + * diffutils-2.7, which can be found at:
[04:43:47] <TimStarling>	 well, if we are saying Dairiki still owns the copyright then it would be GPL 2: https://sourceforge.net/p/phpwiki/code/HEAD/tree/trunk/lib/diff.php
[04:44:41] <legoktm>	 How much of that code still exists today? 
[04:46:16] <TimStarling>	 https://sourceforge.net/p/phpwiki/code/HEAD/tree/trunk/lib/difflib.php is more relevant
[04:47:31] <TimStarling>	 there are hundreds of lines here that are very similar
[04:48:40] <legoktm>	 :/
[04:50:03] <TimStarling>	 I guess it has to be GPL then
[04:56:34] <legoktm>	 ugh
[05:06:09] <legoktm>	 This means we have to remove it from Debian/Ubuntu :(
[05:15:20] <TimStarling>	 yes
[05:15:55] <TimStarling>	 theoretically we could replace the GPL bits with another diff engine implementing the same interface
[05:16:20] <TimStarling>	 ultimately it all comes from published computer science literature
[05:20:13] <legoktm>	 I assume other people have already tried to convince PHP to make their license GPL compatible...
[05:28:07] <legoktm>	 TimStarling: https://gerrit.wikimedia.org/r/436723
[06:10:51] <legoktm>	 I'll file a follow-up task about the licensing problem
[06:20:11] <legoktm>	 https://phabricator.wikimedia.org/T196132
[07:25:42] <legoktm>	 Krinkle: https://phabricator.wikimedia.org/R2355:829c9ef924d552503a2e6c70e108a5317dc7b9c3 and you have commit/shell access to the tool now
[19:00:18] <legoktm>	 anomie: Krinkle: since I've spent a bit more time looking at the installer, is there any good reason to let people pick MyISAM if they have InnoDB available? When you pick MyISAM, it puts up a giant warning telling you not to pick it >.<
[19:05:03] <anomie>	 legoktm: I don't know of any reason for people to use MyISAM anymore.
[19:08:25] <Reedy>	 Double check with the DBAs and remove it?
[19:10:20] <paladox>	 some hosts providers says innodb is easily data can be lost.
[19:10:25] <paladox>	 when mysql crashes
[19:10:53] <Reedy>	 Eh?
[19:11:00] <Reedy>	 InnoDB has better crash recovery...
[19:11:23] <paladox>	 well that is strange but a host provider i knew said that
[19:11:24] <paladox>	 not me
[19:11:24] <Reedy>	 I thought the only benefit MyISAM has is full text search?
[19:11:25] <paladox>	 :)
[19:11:30] <paladox>	 welll
[19:11:37] <paladox>	 innodb supports full text search now
[19:11:42] <paladox>	 since mysql 5.6?
[19:12:41] <anomie>	 MyISAM might still be faster, since it doesn't bother with slow things like transactional integrity. ;)
[19:15:00] <legoktm>	 hahaha
[19:15:59] <anomie>	 OTOH, a quick search indicates that MyISAM might only have table-level locks so that could make it slower when there are many concurrent writers.
[19:26:40] <legoktm>	 Krinkle: in https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Change_coming_to_MonoBook_skin_for_mobile_users there's a note by Graham87 about the jump to links that I think might be related to your change
[19:48:31] <James_F>	 legoktm: Not that I want to nerd-snipe you or anything, but https://gerrit.wikimedia.org/r/#/c/66054/ might be your kind of thing… Will need discussion etc.
[19:49:05] <legoktm>	 ooooh
[19:49:29] <James_F>	 Found whilst going through https://gerrit.wikimedia.org/r/#/q/status:open+age:3years which is a bit sad.
[20:46:40] <Krinkle>	 legoktm: replied