@MoritzMuehlenhoff We won't be able to apply backwards compatible fix for phabricator. Since the daemons uses a php 7.1 feature and a 5.* feature. It won't be able to support php 7.0. Upstream have already decided that too. Stuff like importing git repo to uploading patches through differential will not work as the daemons won't be able to run under php 7.0 due to the missing feature. There is no alternative feature in php 7.0 we can use.

This issue is coming back on T182832

@MoritzMuehlenhoff: There is at least one 3rd party PHP 7.1 package available [ 1 ]. Could we not use their source packages to build our own binaries? I realize it is indeed a large amount of maintenance, however, it seems preferable to being stuck on a buggy and obsolete version of PHP for the next couple of years.

Don't mind me, but it seems like Debian does have packages for php7.1 and php7.2, albeit in newer release channels, but perhaps we prefer backporting those over using a different third party? https://packages.debian.org/buster/php, https://packages.debian.org/buster/php7.1. (Buster is currently in testing still, though.)

I think those packages are the same - sury.org is owned by the debian maintainer for php - so those are semi-official backports, as far as I can tell.

Confirmed: all of the news entries on https://tracker.debian.org/pkg/php7.1 are by Ondřej Surý.

I've tested buster php 7.1 packages on stretch and they work see https://phab-stretch.wmflabs.org

Maybe we can either pin php* and the apache2 php package to buster or backport buster packages into stretch-wikimedia?