[00:07:34] TimStarling: There's a fair bit of code deleted in my patch which maintains PHP5.x compatibility. If we're just dropping it at the installer phase should I keep that stuff in a different patch? [00:08:25] I'm wavering between recommending that and just merging it as is and letting ops deal with it [00:10:53] TimStarling: Well, we can't merge it until hashar fixes CI to let us do so. [00:11:19] Personally I'd rather avoid hacks like PHPVersionCheck running in the installer but not on normal requests. [00:11:26] Even if temporary. [00:11:55] If we get it merged this week no_justification then can cut RC0 a few days late? [00:15:33] * no_justification doesn't care really [01:47:00] I'll do the CI thing tonight [02:23:48] James_F: Reedy: Curious if https://phabricator.wikimedia.org/T173850 should be closed? [02:42:24] Umm. Reedy has the fancy IDE to find those all, I don’t, so can’t judge how much it might be an issue? [07:54:57] James_F: All the jobs should be PHP 7 compatible now, we just need to drop the php55 ones from master/REL1_31 whenever that's ready [11:16:41] James_F: Krinkle: It was a github tool [11:16:41] https://github.com/sstalle/php7cc/commit/d20fa7d7d381fed050b5d18a094103fc41fa2911 [11:16:50] But they say to use phan/phpstan now :P [14:07:11] anomie: heh, cheers [14:07:17] Was just doing it to prevent any little conflicts [14:19:02] https://gerrit.wikimedia.org/r/427369 https://gerrit.wikimedia.org/r/427370 should be simple merges if people want to help with some cleanup [14:24:58] Do we have a generic tag for good practices cleanup etc? [14:25:06] I came across https://phabricator.wikimedia.org/tag/code-health/ but I don't think it's what I actually want [14:38:36] Reedy: tech-debt? [14:38:43] Probably :P [16:05:56] legoktm: Nice! Go go go? [16:06:18] are we dropping PHP 5.5 tests for master or just REL1_31 right now? [16:06:33] https://phabricator.wikimedia.org/T190547#4138497 [16:08:17] We don't need master/php 5.5 in prod now wikitech is moved? [16:08:18] Oh, dumps? [16:08:42] [02:14:06] Once dumps are ready, forward-port from REL1_31 to master [16:08:47] ok, just REL1_31 for now [16:08:51] If dumps is still 5.5, we should keep master [16:08:52] Yeah [16:09:31] That's the plan! [16:09:43] I should send an email or something [16:10:47] "PHP 5.5 is dead. lol" [16:11:47] I'm gonna steal the tail end of Dereckons wiki creation window as he's not used it [16:20:18] https://gerrit.wikimedia.org/r/#/c/427423/1/zuul/layout.yaml review my regex? [16:20:57] nope, won't work [16:25:33] legoktm: Luckily, that was before a step I don't care about for private wikis :P [16:29:03] phew [16:29:39] ok, sanity check on https://gerrit.wikimedia.org/r/#/c/427423/3/zuul/layout.yaml please [16:32:05] legoktm: +1, although I think the wmf/ portion may need to be specific to 1.31 or 1.32 only [16:32:06] not sure.. [16:32:26] I guess it'll solve itself given we'd just remove it entirely and only support two branches anyway [16:33:10] wmf/ has to stay as long as master is there [16:34:48] basically it should be all current branches minus REL1_31 [16:35:45] Right [16:37:25] legoktm: so RE: https://phabricator.wikimedia.org/T191931, seems like quoting is harmless and simplifies the code, and avoids problems with broken mail implementations, such as Amazons' apparently. [16:37:34] Or do we want to push this upstream instead and keep ours as-is? [16:37:52] I assume quoting would not change behaviour in cases where it works currently. [16:38:16] yeah, quoting seems to be harmless [16:38:23] seems reasonable to merge [16:40:47] legoktm: k, I'll add a few stricter test cases [16:40:54] although that'd be a preexisting bug I think [16:40:58] Not sure why the str_replace was added [16:52:41] legoktm: Hm.. REL1_31 jobs test with vendor:master [16:52:43] Is that intentional? [16:52:51] Whoops! [16:52:56] I forgot to branch vendor & add submodle [16:53:01] k :) [16:53:10] I'd like to backport https://gerrit.wikimedia.org/r/#/c/427370/ to REL1_31 [16:53:22] given the mediawiki/at-ease package is deprecated [16:53:49] Actually, given it landed in master, looks like REL1_31 jobs are already failing [16:55:27] heh [16:55:44] Would be nice rather than people seeing abandoned warnings about mediawiki/at-ease running composer update et al [17:09:54] DanielK_WMDE_: One last thing regarding MCR slots - what about outside link update context, eg. WikiPage, OutputPage, Skin; Those get the combined one, or the main one? I'd hope the combined one. [17:10:13] Given skins and extensions can use it to display additional information on the page even if the default handler might not display it. [17:10:22] Eg. hidden categories as (bad) example. [17:15:23] Krinkle: view-level code get the combined PO per default. The original MCR proposal calls for a single-slot view/edit mode, as a fallback when no integrated view or edit capability is available for a certain slot. [17:17:47] Krinkle: whether there will be a default handler, or what functionality it should have, is still undecided. In my mind, the page type handler decides what goes into the combined PO. And the default handler would add everything, blindly (except for HTML - that should at least not be doen blindly). [17:26:09] Krinkle: i'm about to head out for dinner, I'll be back online at least half an hour before the TechCOm meeting [17:26:27] Krinkle: please have a look at https://docs.google.com/document/d/1JRiCzbkrWDaBQL15L4U4GDnFrZrX6RFCJRAx-l7iT6w/edit?ts=5ad5404a# beforehand [17:36:21] James_F, Reedy, etc. ok, there shouldn't be any php55 jobs running against REL1_31 anymore [17:37:42] * legoktm -> afk [17:37:56] :) [17:43:43] Is the plan to merge https://gerrit.wikimedia.org/r/#/c/405216/ onto REL1_31 then? [17:45:06] cherry pick and merge [18:00:09] Reedy: Yes. Want to merge it? https://gerrit.wikimedia.org/r/#/c/427458/ [18:00:25] Moment, MaxSem INSTALL fixing patch being merged [18:00:29] Will hit rebase and merge after :) [18:01:39] LET'S JUST DO IT IN MASTER AND SEE THE WORLD BURNING [18:01:53] apergos will hunt you down [18:01:53] [18:02:36] Yeah, let's not make problems for SRE if we can avoid it. [18:09:56] anomie: I believe https://phabricator.wikimedia.org/T167942 might be fixed now, but not sure. [18:15:51] Krinkle: For PG 9.5+ yes. For 9.2–9.4, no. [18:19:21] In 9.2–9.4 it's actually a bit worse now, because those errors aren't flagged as "ignored" anymore. [18:21:00] 18:12:02 [142.8MB/9.10s] [18:21:00] 18:12:02 Problem 1 [18:21:00] 18:12:02 - This package requires php >=7.0.0 but your HHVM version does not satisfy that requirement. [18:21:01] hahaha [18:21:10] * James_F sighs. [18:21:24] Yeah, HHVM version matching is confusing? [18:21:29] Yeah [18:21:30] well [18:21:35] We haven't got PHP7 mode or whatever enabled [18:21:57] Intentionally. [18:22:05] which changes from 5.6.99 or whatever to some 7 [18:22:17] Does composer not have an "hhvm" require that we can set instead? [18:22:18] Can we specify a hhvm version in composer? [18:22:21] :) [18:22:22] :) [18:22:48] no_justification: btw, how do I set up the github mirror for a new gerrit repo. We created two repos under performance/ last week, but not being mirrored it seems. [18:22:50] seems to do, yeah [18:23:03] but... [18:23:12] how do we do package A XOR package B? [18:23:24] With difficulty. [18:23:36] delegate function? [18:24:46] https://github.com/composer/composer/blob/dae3c5bc2dbb666ad2248a9049b51bba6374b918/src/Composer/DependencyResolver/Problem.php#L101 [18:24:48] There seems to be support ofr it [18:24:52] But not sure how to trigger it [18:25:17] https://getcomposer.org/doc/06-config.md#platform [18:26:57] https://matthiasnoback.nl/2014/10/composer-provide-and-dependency-inversion/ [18:27:21] https://getcomposer.org/doc/04-schema.md#provide [18:27:34] list hhvm in provide? [18:29:22] Did you try plain php and hhvm in require? Maybe it'll automatically prefer one over the other. [18:29:26] E.g. in hhvm only validate that one [18:29:41] Nope... That was one option [18:29:43] We might aswell try [18:29:53] Also, why did this not fail on master? [18:30:43] in the hhvm job [18:30:49] mediawiki-phpunit-hhvm-composer-jessie FAILURE in 43s [18:30:59] Is that only run on merge? [18:31:20] mediawiki-extensions-hhvm-jessie passes on the master commit [18:31:49] No idea what mediawiki-phpunit-hhvm-composer-jessie is for [18:31:53] Oh, I guess that's for testing without vendor [18:31:56] Yeah. [18:31:59] Maybe just switch that to php7 [18:32:02] doesn't need to be on hhvm [18:32:10] Or that. [18:32:25] But isn't it going to bork for other people running hhvm, but no php 7 mode? [18:32:31] It's good that we have that job, I didn't realise we ended up adding that. [18:32:32] when running composer foobar [18:32:48] --ignore-platfom-reqs [18:33:13] Go on, add that to the docs and see how many people pay attention? ;) [18:33:45] Let's see what happens this time [18:33:46] It's a very narrow usecase here: non-tarball installs for 1.31+, using hhvm, and without vendor. [18:34:05] They can add a flag to ditch the warning, I suppose [18:34:16] Yeah. [18:35:00] lets see what adding hhvm to the requires does (if anything) [18:35:16] Yeah, maybe composer will just do the right thing and not try to enforce both [18:35:30] Krinkle: Gotta create the repo on github manually [18:35:37] I've got some WIP to auto-create [18:35:42] The code you pointed to does seem to do some magic [18:36:52] no_justification: OK. And then to trigger gerrit? [18:37:15] Just do some stuff [18:37:22] Merge a commit [18:37:48] Reedy: Meh, now it's failing php jobs for not using hhvm. [18:37:55] rofl [18:37:55] So I guess require.hhvm is only for hhvm-only projects. [18:38:21] But it's interesting that "php" can also be set from composer.platform [18:38:26] Not sure how that's different from composer.require [18:38:31] but worth a short I guess. [18:39:55] I guess it'd work if hhvm was on packagist... [18:39:59] And had a "provides" [18:41:21] Right [18:42:59] "Good to know just about every big dotcom out there is living in la-la land. Except that, if you have 100+ servers, those companies do all this in 5 minutes through Chef, Salt or Puppet. [18:42:59] Patching 500 webservers at once can be as simple as salt -G role:webserver cmd.run composer install -o here in la-la land." [18:43:00] :D [18:43:04] https://github.com/composer/composer/issues/5163 [18:43:29] I guess we fix the job as you say... [18:43:36] An see if we come up with a better fix [18:43:50] Like I say, there is a way to delegate to a php function to do checks and stuff [18:44:02] But is that overkill, if we're eventually getting rid of hhvm too? [18:46:26] 18:33:06 - This package requires hhvm >=3.18.5 but you are running this with PHP and not HHVM. [18:46:38] That definitely looks like composer is hhvm vs php aware [18:46:50] Yeah, it is. But if you require hhvm, it will.. reject php. [18:47:01] There is such a thing as hhvm-only. [18:47:24] pfft [18:49:33] Krinkle: what Reedy said. Next git action triggers it. Can also force via ssh [18:49:35] I like Krinkle's idea of just running this test on PHP7 and not HHVM for REL1_31, but we'll need a fix when we apply it to master. [18:49:55] * Reedy files a task [18:50:00] the composer-test job can imho just always be on php7 [18:50:03] Should be fine. [18:50:08] Even for prod code? [18:50:16] James_F: It doesn't relate to prod. [18:50:17] Can we please have an rfc on our dang version number? [18:50:30] This job exists to verify MW works and test pass when fetching deps from pakagist instea of mw-vendor [18:50:36] 2.0 will never happen. Let's just drop the 1 already [18:50:39] Krinkle: Oh, OK, yeah, fair. [18:51:16] +1 for MW 32.0-alpha [18:51:25] no_justification: is 1.30 newer than 31? [18:51:42] Depends on the sort algo [18:51:44] No [18:52:01] Because it's 1.30.0 and 31.0 [18:52:12] So any half ass version sort should be fine [18:52:19] True [18:52:26] If it's not, can hardly claim to version sort [18:52:28] Until we reach 100 [18:52:36] Although even then it should be fine [18:52:45] Well I don't plan on it being my problem in 35 years [18:52:54] :) [18:53:39] We should probably leave a gap for clarity. Like Opera, Edge and Node did. [18:53:47] Like.. we'll go from 1.31 to 42.0 [18:53:49] 60 is the go to number? [18:54:05] Lets do 59 just to be awkward [18:54:20] no_justification: The RfC won't be in effect for REL1_31, it'll take months of arguing. [18:54:48] And this is why we've never done it [18:54:50] * no_justification sighs [18:55:22] We'll get caught up bikeshedding [18:55:51] I doubt we'd have months of "new significant concerns" being raised though [18:55:55] Over 32 vs 42 vs 60 vs 2018 vs 8675309 [18:56:03] insignificant concerns are fine to keep raising until Infinity, but can happen after approval. [18:56:35] :P [18:56:47] * no_justification files RfC under the jfdi track [18:57:57] https://github.com/wikimedia/integration-config/blob/master/zuul/layout.yaml#L1568 [18:58:01] What do we replace it with? [18:59:30] s/hhvm/php70/ [18:59:36] And update the jjb config as well [18:59:47] not sure where its defined exactly [18:59:52] I was trying to find it in jjb :P [19:00:25] no_justification: Hm.. how do I trigger it over ssh? (Gerrit replicate) [19:00:35] oh, -jerkins [19:00:39] nope.. [19:01:04] `ssh -p 29418 gerrit.wikimedia.org replication start foo/bar` [19:02:46] And once there's an available thread for it, it'll replicate [19:02:52] (usually pretty quick, within a minute at most) [19:03:20] paladox: Hmm, something triggered a full reindex of mw/core again :\ [19:03:29] oh [19:03:32] full reindex? [19:03:42] eg: reindex-if-stale-change-358164 [19:03:45] aha [19:03:47] Like 4000+ of them [19:03:49] you can disable that [19:03:51] if you want? [19:03:51] Er, 2400 [19:03:57] it's disabled by default @ master [19:04:09] and i think 2.15 too [19:04:36] index.autoReindexIfStale [19:05:10] Hmmm [19:05:21] no_justification https://gerrit-review.googlesource.com/c/gerrit/+/166930 [19:06:19] Yeah, we should disable that [19:06:40] yep, would at least reduce the load [19:06:42] i think [19:06:45] and free up threads [19:07:28] Oh yeah, plus since batchThreads are set to a lower number (so upgrades don't hammer things), it means we do these super slow [19:07:39] yeh [19:07:59] Ok yeah, let's get a patch up to disable this [19:09:29] ok [19:09:34] * paladox will let you do that :) [19:09:56] Yeah should only take a sec [19:13:49] https://gerrit.wikimedia.org/r/#/c/427471/ [19:28:41] no_justification gerrit is gaining support for reloading gerrit.config with out restarting! [19:28:54] though some changes will need to still restart gerrit [19:28:59] but most should not require that [19:29:02] Does that fix memory leaks? [19:29:17] which memory leaks? [19:29:22] I saw that [19:29:29] Reedy: {{cn}} [19:29:50] Java is one big memory leak [19:30:58] no_justification: Thx, replication start worked perfect. [19:31:02] ly [19:31:55] Reedy: We haven't had runaway memory problems in Gerrit really. We had some GC issues, but that was mostly fixed via perf tuning the jvm. [19:36:02] Ok, I'm off to RSA (friend snagged me an expo hall badge) [20:42:29] https://www.mediawiki.org/wiki/Template:Sp-contributions-footer is broken on mw.org [20:42:33] It's showing a red $1 for username [20:48:16] [[User:{{{1|$1}}}|{{{1|$1}}}]]: [20:49:25] Reedy: Seems to work on actual Special:Contributions pages. [20:49:44] Doesn't on my own [20:49:52] Or any I view [20:50:27] works on my side too [20:50:42] and not skin dependant (tested with timeless/vector/monobook) [20:51:13] logged out, works too @ https://www.mediawiki.org/wiki/Special:Contributions/reedy [20:51:37] Works logged out.. Not logged in [20:51:38] lol [20:57:22] 1.31 now needs PHP 7.0+ [21:01:41] \o/ [21:05:48] DanielK_WMDE: https://doc.wikimedia.org/mediawiki-core/master/php/classObjectCache.html#details and https://doc.wikimedia.org/mediawiki-core/master/php/classWANObjectCache.html#details [21:05:56] but we currently lack a good discovery mechanism [21:06:06] Knowing which class houses the big mid-level intro is a problem. [21:06:11] I'm working on moving this to a separate md file [21:06:16] linked from doxy nav [21:06:30] But let me know if this is what you were looking for [21:46:17] Amusingly, I'm more proud that T186337 got fixed today than PHP 7.0. :-) [21:46:17] T186337: Fix MediaWiki deprecated calls in Wikimedia production, 2018-02-02 - https://phabricator.wikimedia.org/T186337 [21:47:48] What else is broken now? ;) [21:48:00] Reedy: Inorite? [21:48:15] TBF the deprecation log in prod is meant to be never written to. [21:48:26] Don't deprecate anything then [21:48:50] You're meant to soft-deprecate, fix everything WMF uses, then hard-deprecate because we don't care about others'. [21:49:00] I tend to [21:49:07] Or spend time cleaning up the messes others leave from not doing that ;) [21:49:19] That too. [21:49:50] There's also the opposite issue, finally hard-deprecating things that were soft-deprecated years ago. [21:50:13] May be we should write a PHP extension that traces each call and parses its doc block (ReflectionClass::getDocComment) and emits a warning for soft deprecations, too. [21:50:23] For beta? [21:50:40] Or we just hard-deprecate and revert if stuff shows up. [21:50:42] But might be harder [21:50:43] Would we ever read that log? [21:50:46] :P [21:50:48] Probably not [21:50:56] Or we'd disable it because it shouldn't be more spammy than prod [21:51:03] which is probably fair [21:51:34] The first version of the clean-up-the-deprecation-log task, T162885, was filed by SRE when it reached 10k a minute. [21:51:34] T162885: Fix MediaWiki deprecated calls in Wikimedia production, 2017-04-13 - https://phabricator.wikimedia.org/T162885 [21:52:21] My (forlorn) hope is that we never get entries again. [21:55:43] James_F: We can enforce that with scap's canary error monitor [21:56:11] We could. But we mightnot. [22:17:22] RoanKattouw: anomie: I've incorporated last weeks' RFC meeting notes into https://phabricator.wikimedia.org/T40417. Would appreciate a look-over to confirm it's a sound proposal. [22:17:29] Specifically the API parts I'm not 100% sure about. [23:30:34] anybody knows if there's a way to override messages (aka wmMessage) for testing? It's hard to test things that depend on messages if the test can be broken next time somebody edits the message... [23:35:52] SMalyshev: Set the language to qqx [23:36:09] then the message keys can be used for asserting :) [23:36:59] hoo: ahh interesting, will try that. How it handles parameters though? [23:39:40] > echo wfMessage( 'wikibase-sitelinks-counter' )->params( 'blah' )->inLanguage( 'qqx' )->text(); [23:39:40] (wikibase-sitelinks-counter: blah) [23:39:48] hoo: ah, that works, thanks! [23:39:58] You can also see this by appending uselang=qqx to any MW request :) [23:40:02] Cool