[01:25:40] Who needs diffs anyway? [12:42:37] woo, PHP 7 [12:42:37] https://phabricator.wikimedia.org/T195393#4228562 [12:44:50] Reedy: Hm.. that shows php5 as slower than hhvm. That's.. good, but also.. what? [12:45:08] It's to be expected, no? [12:45:11] hhvm is faster than php5 [12:45:18] And it's one long running script, not numerous short lived [12:46:47] there WAS a reason for us to move to HHVM you know... [12:47:15] mark: not just you guys like pain? :P [12:47:27] not just for the popcorn of watching joe and ori [12:47:33] pffft [12:52:40] Reedy: No no, the whole point of that task is: " We've always kept cli scripts on php5 instead of HHVM because HHVM is slow on CLI " [12:52:57] And with the final switch of that to HHVM, rebuildLocalisationCache got slower. [12:53:10] HHVM is slower for short lived scripts [12:53:17] It would be faster for long intensive scripts [12:53:53] Undeployed patches to enable JIT made it slightly better, but various people still confirmed on that task that it was like 5min for php5, 40min (!) for HHVM, and 16min for HHVM with JIT - ergo, stil slower than php5, ergo still a push to get them on PHP7 asap to recover the loss in speed. [12:54:06] Reedy: I know, that's what I think too, and I've been saying that, and yet.. the task. [12:54:26] task = https://phabricator.wikimedia.org/T191921 [12:54:46] Well, beta isn't comparable to some extent [12:54:49] VM [12:55:02] Shared CPU. Less Memory... Shared disks [12:55:11] "full scap sync as part of train" does not sound like beta [12:56:02] https://phabricator.wikimedia.org/T191921#4127269 [12:56:06] [thcipriani@deployment-tin ~]$ [12:56:09] sounds like beta to me [12:56:19] So does https://phabricator.wikimedia.org/T191921#4140587 [12:56:51] Several SAL entries show "Finished scap" with over 100 minutes. [12:57:09] This is confirmed in prod, and started when we switched mwscript from php5 to hhvm for the last time. [12:57:19] Where most time is spent in rebuilding l10n cache. [12:57:38] I didn't try hhvm on tin [12:58:08] * Reedy runs on hhvm on tin [13:00:37] gogo php7 [13:40:52] Krinkle: so, hhvm on tin... [13:40:52] real 40m32.809s [13:41:05] Aye, that looks familiar. [13:41:12] So this is a jessie/stretch thing? [13:41:44] Kinda looks like they cause some improvements on hhvm alone yeah [13:41:52] Unless tin has major I/O issues or something [13:42:05] That might make it worthwhile to first switch to mwdeploy with php (alternate) =hhvm [13:42:39] I mean, that in itself has nothing the lose. Afaik the only reason we didn't switch to stretch yet is because we wanted to switch to php7 at the same time, right? [13:43:16] Switching deploy and maint to stretch/hhvm would take the pressure off the php7 switch, allowing us to get things in place first [14:17:39] James_F: So, joe merged the patch... [14:18:05] I think we just need to disable php55 on master in ci... And make sure it still runs on <= REL1_30... [14:18:38] Sure. [14:18:45] I looked at that earlier. [14:20:55] Hmm [14:20:56] # Run MediaWiki PHP 5.5 tests on MW < 1.31 [14:20:56] # TODO: Drop master from this list [14:20:56] - name: ^(quibble|mediawiki|mwext|mwskin).*php55.*$ [14:20:56] branch: ^(REL1_(2[789]|30)|master|wmf/.*|fundraising/.*)$ [14:21:06] Oh [14:21:10] just need to remove master from there [14:22:08] https://gerrit.wikimedia.org/r/434922 [14:23:05] Yeah. [14:23:46] Reedy: Apparently we have tests in int-config asserting that we test php55 against master. :-) [14:23:54] pfft [14:24:05] easy to fix [14:28:08] assertProjectHasPhplint [14:28:15] looks like no one added php70 to that [14:32:34] 14:29:20 KeyError: 'mediawiki-core-php55lint' [14:32:44] Is that related to https://github.com/wikimedia/integration-config/blob/master/jjb/mediawiki.yaml#L265 ? [14:36:35] Yes. [14:41:55] https://gerrit.wikimedia.org/r/#/c/434922/ [14:41:58] V+2 from jerkins now [14:46:53] Just need someone to sanity check that, and we can merge it then merge James_F's patch to master [14:49:47] Well, sanity check and merge and deploy it. CI admins are few on the ground. [14:50:07] DEPLOY ALL THE THINGS [14:50:20] Krinkle: ^ mind giving that a second set of eyes please, and I can deploy after [14:57:26] cheers [15:06:10] oh, duh, this is a zuul deploy, not jerkins [15:13:46] Ok, so... [15:16:03] * Reedy rebases [15:16:19] https://integration.wikimedia.org/zuul/ looks good [15:16:25] no php55 jobs [16:18:03] Reedy: Gosh. It's done. [16:18:14] Reedy: Who's going to send the announcement to engineering@? [16:26:11] <_joe_> we should talk about moving scripts to php7 maybe [16:26:23] <_joe_> at least the ones that suffer more from being on hhvm [16:26:31] <_joe_> like the wikidata dispatch ones [16:27:18] Yeah. [16:29:57] When we're onto the php7 boxes... we just s/php/php7/ in foreachwikiindblist instead? [16:30:45] To stop accidental use of php8? [16:31:01] well, php is going to default to hhvm still, presumably? [16:31:08] Oh, you mean to force PHP7 on a box which defaults to HHVM, right. [16:31:19] ja [16:32:35] Rather than switching the jobrunner boxes to default to PHP7 and manually forcing jobs that don't work there yet (?) back to HHVM? [16:33:48] Well, I'm guessing hhvm on new debian is the next changes [16:33:54] Before we start migrating in earnest to php7 [16:35:25] That's T192092 right? [16:35:25] T192092: setup replacement for terbium (maintenance_server) on stretch - https://phabricator.wikimedia.org/T192092 [16:35:28] And family. [16:35:59] I guess so. Which are mostly done, bar the swapping them into being the live machines AFAIK [16:38:17] * James_F nods. [17:18:57] James_F, Reedy: someone going to announce to wikitech-l? [17:19:26] legoktm: Should it be CindyCicaleseWMF? [17:21:54] I don't know if she's around today [17:25:43] Then you? You did the most work. :-) [17:26:29] I can do that after breakfast then [17:26:46] anomie: based on https://phabricator.wikimedia.org/T173786#3651007, PHP 7's scalar type hints are different from HHVM's? [17:27:46] legoktm: When it says "Hack" I believe that means Hack rather than PHP, not HHVM versus Zend. [17:31:10] hm [17:31:18] https://3v4l.org/1S8Vo looks like it works fine? [17:31:33] <_joe_> php still defaults to hhvm [17:32:08] <_joe_> and you should always run any script with "php", and let SREs handle that [17:32:32] <_joe_> the override should just be meant to be used during transitions/testing [17:37:09] legoktm: Except 3v4l has the hhvm.php7 ini settings enabled that we're not going to enable: . On terbium it gives the "Argument 1 passed to foo() must be an instance of int, int given" error indicating that it interpreted "int" as a class name. [17:37:21] oof [17:37:26] I should've checked that [17:37:49] ok, so I'll leave the PHPCS sniff in that blocks scalar types [18:19:11] Reedy: Because I always need to have a pointless never-merge patch on the go, there's now https://gerrit.wikimedia.org/r/434973 to drop HHVM support. ;-) [18:22:18] James_F: Hmm. How does that patch compare to https://gerrit.wikimedia.org/r/c/426165/ ? [18:23:24] anomie: I documented that in https://gerrit.wikimedia.org/r/434978 [18:23:36] (scalar types) [18:23:39] anomie: Oh, I didn't know of that. Looks at first glance like mine's a super-set (not just removing HHVM-specific hacks, also dropping special code in Special:Version etc.). [19:01:28] James_F: If you're on the cleanup-after-PHP5 spree, it might not hurt to check for no-longer-needed calls to function_exists(), method_exists(), class_exists(), and is_callable(). Maybe also comments mentioning /php ?[57]/i for stuff that can be cleaned up now. [19:03:47] Yeah. [19:04:08] Maybe /php(?: | ?[><] ?| before | after | pre-)?[57]/i ... [19:11:06] heh [19:15:06] What version of PHP should we keep aiming for supporting in index.php? Right now we seem to be roughly aiming for php 5.3… [19:42:21] Meh, it seems #wikimedia-security is set up in a way that banned users in it by name when logged-out, so that even if logged in now, they remain unable to join. That's unfortunate. [19:43:31] Actually, no, it banned by hostname cloak. But it happened while NickServ was offline. That's... weird :P [19:45:57] Krinkle: /msg chanserv clear #wikimedia-security bans [19:46:02] will unban everyone [19:46:16] Right, as well as any entries that existed previously. [19:46:19] yes :( [19:46:41] alternatively you can unban yourself with /cs unban, and then manually -b everyone else [19:46:53] I suppose someone with op access to that channel can view the bans and redo the ones afterwards and/or selective unban the appropiate ones. [21:23:49] It's amazing how much old php back compat we'll be removing in the next few weeks [21:25:18] only to start more :) [21:26:03] Yeah. [21:26:13] Maybe we should drop support for PHP70 soon? ;-0 [21:26:26] Only if you want ops to murder you [21:26:36] php72 or go home. [21:27:41] php72 performance is very impresive [21:27:49] impressive [21:28:51] You can prove anything you want with a benchmark [21:29:32] well i upgraded one server which hosted phabricator (was very slow with php5.6) now loads instantly with 7.2 [21:32:09] Unfortunately it's not that easy for WMF prod [21:34:07] 7.0 is a pretty nice baseline for now [21:45:54] It goes EOL soon though, except for Debian maintainers' efforts, right? [21:46:35] security only for 6 months more [21:46:49] Aha, yes, until 6 December 2018. [21:47:04] http://php.net/supported-versions.php says 3/12/18 [23:54:21] ?? is my favorite PHP 7 operator [23:57:47] <=> tops the ranking for me