[08:55:57] <_joe_> Krinkle: auto_prepend is only used in the fcgi SAPI by HHVM too [08:56:19] <_joe_> so I just reproduced the behaviour [08:56:47] <_joe_> TimStarling: and now the apache config is less scary, so we could surely do that [08:57:21] <_joe_> I was actually about to do that, then I realized that php7 DTRT as far as opcache is concerned - it just saves the realpath as the cache key [08:58:03] <_joe_> If we have a need to alias /w to the general dir everywhere, it's relatively easy and safe to test/implement nowadays [08:59:41] <_joe_> Krinkle: when you have time, we should really merge https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/492975 [08:59:52] <_joe_> and backport it to the current branch too [14:41:11] _joe_: yeah, it's only 1 symlink and for a trivial file. Once inside the multi version entry point, everything is absolute. Is it's not like the opcache would be fragmented much if at all (maybe 7 different docroots in total). [14:41:23] But good to know it's already using real paths [15:04:41] <_joe_> Krinkle: I merged all of your arclamp patches, and now I have a set coming your way :P [15:04:54] <_joe_> when gerrit complies, that is [15:13:05] <_joe_> Krinkle: https://gerrit.wikimedia.org/r/c/operations/puppet/+/499219 and following, but I'm more interested in you maybe merging https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/492975 when you have time [15:35:58] <_joe_> uhm https://phabricator.wikimedia.org/T219279 seems like a blocker for the migration? [15:38:34] <_joe_> I'll have to take a better look at what's going on [15:41:48] <_joe_> duesen: any idea who could look into this? [15:46:00] Oh, hey _joe_, you flagged it already. :-) [15:59:30] <_joe_> James_F: yeah but it might need reinforcement later in the US day :) [18:27:31] _joe_: ready for swat https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEvents/+/499238/ [18:28:14] <_joe_> thanks! [18:28:37] _joe_: should be part of wmf.23 naturally, so you can backport to wmf.22 later today if you want. or I can as well. let me know :) [18:29:05] <_joe_> I'll do it in tomorrow's EU SWAT window I guess [18:30:01] <_joe_> but tbh I won't move past 1/1000 sampling until it's clear to me what the implications of https://phabricator.wikimedia.org/T219279 are [18:30:26] <_joe_> I've seen you've added it as a blocker for the migration, which seems fair to me [18:48:46] <_joe_> I just verified what Ed described in the bug happens, and it's a nifty fix in php 7.2.x [19:19:53] _joe_: Probably the thing to do will be to just rename the pages, to the new title if possible or to subpages of some prefix if there's a conflict, much like we do with namespaceDupes.php. Same for any users with names starting with these letters (like User:ɱ in a previous update, see ) (see also /mediawiki/extensions/WikimediaMaintenance/+/208988>) [19:51:30] subbu: parsoid post-merge job is failing: [19:51:31] - This package requires php >=7.2.0 but your PHP version (7.0.33) does not satisfy that requirement. [19:51:37] phpunit-coverage-docker-publish [19:51:45] Might need to fix something somewhere :) [19:54:19] Krinkle, computers are frustrating man :) something needs fixing somewhere always .. ok .. will file a phab task for this and pretend it is fixed for now. we don't need to worry about published docs just yet .. and in a few months time, everything may move to 7.2 and this might magically resolve itself. [19:57:57] Krinkle: IIRC that's known already, but it's being ignored until CI is updated to use 7.2 for that job everywhere (instead of making something custom just for Parsoid) [19:58:53] anomie: is there a task for that? I don't think that's something that would happen by itself for a long time, given parsoid is the only thing requiring php 72 [19:59:18] the other way around however, seems possibly absent (supporting php70 but not 72) so that'd be fine to push proactively [20:02:38] <_joe_> given we're running 7.2 in production... [20:02:44] anomie, let me know if you find something .. otherwise, will file a task to track it and we can decide what to do couple months down the line. this is by no mean critical to fix now. [20:02:54] <_joe_> I would rather fix the inclusion of php7.2 in the job [20:03:17] <_joe_> subbu: if you file a task we can look tomorrow (we == SRE) [20:03:26] k [20:03:46] <_joe_> it seems like a matter of installing the right php version within a docker container at first sight [20:04:30] hasharDinner: ^ When you look in, you'll probably know already about any plans and Phab tasks for updating phpunit-coverage-docker-publish to use PHP 7.2 instead of 7.0. [20:06:58] _joe_, https://phabricator.wikimedia.org/T219319 [20:08:31] anomie: it might be very easy to handle, ie just switch from a php70 to a php72 container. Else we gotta build a new one which is usually not the end of the world [20:08:54] anomie: or we craft another job that has 72. I think we had to do that for parsoid since they are dropping 7.0 support [20:10:33] (oh just noticed Timo replied above. So it is probably covered, but I will be happy to assist. Though tonight I am in meetings) [20:13:29] subbu: no new container, just update 1 or 2 lines in a jjb yaml file to point to a 72 container for that job, and then generate/upload the new xml files for it. [20:14:03] could be a good small change to (re)introduce current JJB methodologies, happy to help, subbu [20:14:28] Krinkle, will accept help! Thanks. [20:14:51] subbu: wanna pair up for 30min or so some time this week? [20:16:23] Friday morning works. [22:26:24] subbu|away: cool, sent an invite. Would help if you could try to install JJB from https://www.mediawiki.org/wiki/Continuous_integration/Jenkins_job_builder#Install_JJB ahead of time. Don't worry if it fails for any reason, then we can continue during the meeting, but if it works on first try, that'd save some time :)