Update to php 7.0

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1522422/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Status changed to 'Confirmed' because the bug affects multiple users.

Nah, php7 is not a revolution. php5 over php4 broke API too much, but php7 is much more close to php5.6 than php3 to php4 or php4 to php5 ever was.

And php5.6 follow the same support pattern as all php 5.x versions before: http://php.net/supported-versions.php

Thus I don't think Debian would ever release with two versions of PHP -> stretch will have only 7.x (most probably 7.1) and I really advice Ubuntu to do the same.

If you need to run 5.6, you can do that will older Ubuntu release.

I don't agree, PHP 7 is up to twice as fast as PHP 5.6. If it is not a revolution, why a lot of big sites use HHVM and not PHP 5.6? PHP 7 and HHVM performance are similar, so please add PHP7 to repository.

Just a small clarification, the advantages that the big sites have obtained using HHVM are ONLY related to performance. Do not insert PHP7 in repository is a big mistake. Certainly you can always compile it, but why follow this road? What real benefits?

The performace improvement is nice, but "revolution" would mean a lot of broken code, and this is not what happens with PHP 7.0. The amount of breakage is not that big to justify the amount of work to also support PHP 5.6.

I think completely different from you. I think the fact that there is not 'broken code' does not justify the non-inclusion.

You are just repeating the same story that I've heard with every minor version. I still hear some broken obsolete code requires PHP 5.3. The major version bump is not as severe as with python2->python3, so there's a need to put a stake into the ground somewhere.

Also "think" is different from putting your money where you mouth is. Maintaining several versions of PHP requires a substantial amount of work. And the amount of work and support required is much higher when you release multiple versions of PHP as part of stable release than let's say supporting those versions in outside repositories (like my ppa:ondrej/php*).

Ultimately this would be a Canonical people's decision, but I strongly advice against having a multiple versions of PHPs as part of stable Ubuntu release.

I did not know that each time was released a minor version of PHP at the same time was released on the market a product as HHVM which is up to twice as fast as PHP 5.6 without changing one line of code. However do not be surprised if people will go to HHVM, if canonical decides not to support PHP 7. If this makes you happy, I hope for you that will happen.

I also wish to see PHP 7 in the next LTS. It was released somewhat too late to replace 5.6 so the next best thing is a new package. Wait. You say almost nothing has changed, so why not ditch 5.6? That sounds good too.

It's really all about the speed of migration. Switching to PHP 7 as fast as possible is important for several reasons. Going to PHP 7 on productions servers would decrease running costs substantially. Especially on big projects like the one I'm working on. I'm also a huge fan of the new syntax and generally the updates to the language.

The thing is our servers run on Ubuntu LTS without any PPAs for maximum stability. If it's confirmed Ubuntu 16.04 LTS is not having PHP 7 the migrations move from being 5 months away to 2,5 years away. It's sad to even think about.

Ondřej, thanks for your work on your repos!!
Just to clarify: As of today, we don't know whether PHP 7 will make it in 16.04, correct? What does it depend on? Are there any links to discussions about that? I did not find any ...

Phillip, that's a question for @rbasak and ultimately for Canonical whether they allocate enough time to make it happen.

Thanks for the quick answer. Let's see what we can do about that :-)

For what it's worth, I would really like to see PHP7 in Ubuntu 16.04. Is there anything I could do to help it to happen?

I wouldn't exactly call PHP7 a revolution - it's faster, and it has some nice features (particularly valuable for me are return type hinting and scalar type hinting). I've upgraded a few applications from PHP5.3 to PHP7.0 without any changes to the code. I did have to change configuration like where the PHP 7.0 FPM is located, but that was it, and the speed improvement was noticeable.

I feel like vinc-q and Ondrej actually agree with each other but don't realize it...

For what it's worth, I agree that Ubuntu should have PHP7, but we don't need two PHP packages. There aren't enough BC breaks to warrant it. Like Ondrej said, you can stick to older Ubuntu releases or build from source if you need <7.

Here's a thought: I don't know anyone running Ubuntu servers who's using the stock PHP because it's usually too old. People either use Ondrejs PPAs, compile themselves or use some other vendor (i.e. Plesk provided packages).

PHP 5.6 support ends August 2017. That's 9 months of backporting security fixes. PHP 7.0 is supported until December 2018.

If you ask me, this is a no-brainer. Ship the latest available version with every LTS. @Ondrej, thanks for your awesome work!

Still using Ubuntu 12.04 LTS with php 5.3.10 ...
at work, the policy is to change distribution each 4 years, a few months after the LTS is out, with no additional ppas.

next upgrade is for 16.04 LTS aproximatly in june 2016!
the next one will be for 20.04 LTS ... aproximatly in june 2020!

So, I would really like to have php7 which is 2 times faster than php5, otherwise I will be stick with php5 until mid 2020....

Please add a php7 branch in the core 16.04 distribution.

It has been added:

http://packages.ubuntu.com/xenial/php/php7.0

We haven't committed to anything yet. The schedule is tight. Whatever we ship we will need to support for 5 years, so it cannot be half done.

We are pretty certain that we don't want to ship both 5.6 and 7.0, so we expect to remove one or the other before release. Based on my current understanding I would like us to ship 7.0 in 16.04, but the transition needs to be completed first. For 7.0 to make 16.04 it needs to have replaced all the functions that 5.6 currently performs for us (reverse dependencies etc) and replace 5.6 in main. If this doesn't happen by feature freeze (18 Feb), we expect to remove 7.0 from universe, and 16.04 will ship with 5.6 only.

We can continue to use this bug to keep everyone updated. If there are any blocking issues then we'll mention them here. I will try to make sure that anyone interested in making this happen has the opportunity to volunteer to fix any blocking issues in time.

Thanks for the detailed response. I'm sure that you've seen that there is a wide interest to get PHP 7 in, but I can certainly understand your reasoning. Please let us know if there is anything we can do to help make it happen!

Superlative wording by original submitter, although enthusiastic, is not accurate.

Comment #6 by Ondřej is an accurate assessment of the situation.

Comment #16 Matthias Niessis accurate risk assessment for Canonical (9+ months of backporting if they go with 5.6...)

One thing is certain though, Ondřej and his PPA is a PHP hero. :)

@racb and rest:

The main blocker is all the rdeps that depend on php5-<something>. There are two approaches we could take:

1) patch all the sources to depend on php-<something>

2) prepare src:php5 that just depend 1:1 on src:php7.0

well, there's third option:

3) do as much 1) and then finish with 2)

I have prepared 2) here: http://anonscm.debian.org/cgit/pkg-php/php5.git/

Re 1) the new pkg-php-tools and naming needs decision and a quite lot of work:
http://lists.alioth.debian.org/pipermail/pkg-php-pecl/Week-of-Mon-20160104/000677.html

This has to be solved by PEAR maintainers with help from anybody who has time to help (that's not me).

Cheers,
Ondrej

Thanks Ondřej, this is helpful.

On Fri, Jan 08, 2016 at 10:45:45AM -0000, Ondřej Surý wrote:
> 1) patch all the sources to depend on php-<something>

In Ubuntu we don't have specific maintainers for packages, instead teams
that work towards goals. So unlike Debian where you'd need to mass file
a bug, give maintainers a chance to respond, then perhaps upload delayed
NMUs etc, in Ubuntu the method is for one developer to just mass upload
a change like this as necessary. So the actual doing of it doesn't
concern me, but there is a risk in having to deal with any failures that
might be the problem for our schedule.

However we do want to end up in sync with Debian in the end, of course,
so we don't want to do something one way if Debian will eventually do it
another.

> 2) prepare src:php5 that just depend 1:1 on src:php7.0

Or we could drop src:php5 and provide additional transitional packages
in src:php7.0 instead, which would appear to be the same thing from a
binary package perspective.

Either way we could do this, but it seems wrong and hacky to me, except
temporarily and where users might install these directly and therefore
need a transitional package.

> well, there's third option:
>
> 3) do as much 1) and then finish with 2)

If we do 2) then that's only temporary anyway, presumably, since we'll
want to drop all transitional packages in a future release both in
Debian and Ubuntu?

Given the schedule we probably want to take the path of least resistance
though. I certainly don't want to do something you don't want to support
in Debian.

> Re 1) the new pkg-php-tools and naming needs decision and a quite lot of work:
> http://lists.alioth.debian.org/pipermail/pkg-php-pecl/Week-of-Mon-20160104/000677.html
>
> This has to be solved by PEAR maintainers with help from anybody who has
> time to help (that's not me).

This worries me a bit more. Do we risk breaking PEAR/PECL users if we
commit to PHP 7.0 in 16.04 and then find we don't have this ready in
time?

> This worries me a bit more. Do we risk breaking PEAR/PECL users if we
> commit to PHP 7.0 in 16.04 and then find we don't have this ready in
> time?

PECL seems to be mostly fine although some PECL packages won't be converted at all and some need a code from some upstream git branch.

PEAR is hard to say - that's probably individual. I've seen report about broken Cacti with PHP 7 just today, so it needs some effort to test at least major packages.

The timing is very tight, but I think it's doable if you put enough effort into it and do some SRUs later to move the PECL modules from git branch to release code. This might be good to prenegotiate with release/core team.

Both choices are horrible due timing, but fixing bugs in PHP 5.6 long after it's security support has ended is a nightmare because PHP 7.0 has diverted too much from PHP 5.6 code.

Fixing bugs as they appear in PHP 7.0 and dependent packages should be much much easier because it will be up-to-date code. It might need relaxing SRU policy a bit, but it will pay of in invested time (and money) long term.

Also I would say that people expect to find PHP 7 in next LTS and the sheer effect of disappointment might lead to distro-switch (although my PPAs could come to save a day in such case, there are some people who won't use PPAs in production no matter what).

In the end, this should not be just a technical decision, because the impact of either choice are also not technical.

There's no point in shipping both PHP5.6 and 7 given they're mostly backwards compatible. PHP7 on 16.04; those who want PHP5 could either PPA or remain on earlier versions of ubuntu.

Never mind then!

https://twitter.com/zeevs/status/687241123467767808

...

After studying php-fpm architecture, I think the best handling is to support php7 as php7-fpm. Instead of using mod_php, Apache will have to connect to php7 through mod_proxy_fcgi. With proper setting, one can have both php5-fpm and php7-fpm run in parallel. The Apache server can then support both PHP version at the same time.

OK, OK. I was here because I didn't find php7-fpm in the current repository. And I really want to use it.

I've manually compiled it for my use, but I want an official package that will automatically have updates and patches.

php7.0-fpm is in Xenial/universe.

I am very interested in making this happen and in also making sure that the PHP community is able to respond quickly and to help if there's anything that can be done to make this happen. As has been discussed, most PECL packages are ready for PHP 7, PEAR is now much less widely used in PHP since most projects will bring userland dependencies in via Composer. I notice however that the php-pear package is still depending on PHP 5, so I can't say how well either PEAR or PECL will work with the PHP 7 packages that have already been worked on (and which look awesome, thanks!)

Thanks to everyone contributing to this, I am watching the issue and will be happy to help in practical terms in any way that needs helping.

Not my intention to just do a +1 here, but I'd love to have PHP 7 in Ubuntu 16.04. Sure,
Ondřejs PPA would work, but as mentioned earlier - I think it would disappoint many users if PHP 7 didn't make it into 16.04. I really hope you make it!

Thanks for an awesome OS, and thank you Ondřej for your work making the internet faster.

To stop further disinformation most of PHP 7 is already packaged for xenial:

http://packages.ubuntu.com/search?keywords=php7&searchon=names&suite=xenial&section=all

So let's concentrate on whats missing. I think we're missing some extensions so far like:

php7.0-mysqlnd (neither in Ondřej's PPA or Ubuntu!)
imagemagick (in Ondřej's PPA but Ubuntu has only php5-imagick)
graphicsmagick (neither in Ondřej's PPA or Ubuntu!)

@Ondřej can you give a little overview regarding missing extension?

BTW I am willing to help with the packaging :)

@bhat3 phpX.Y-mysql is already compiled with mysqlnd; php-imagick is the package you seek. graphicsmagick was not yet asked for by anybody, so I haven't touched it.

@Ondřej Nice to know, but for clarification:

mysqlnd: that means we're using mysqlnd now by default and there is only one package now?

imagick: php5-imagick is also the package for PHP 7?

gmagick: Here, asking for it ;) No serious i can really reduce the load on servers and with the 2.0.0 extension release it's ready for 7.0 (https://pecl.php.net/package/gmagick) How can i help here?

> mysqlnd: that means we're using mysqlnd now by default and there is only one package now?

Yes

> imagick: php5-imagick is also the package for PHP 7?

No, I said `php-imagick`, so it's php-imagick and not php5-imagick.

> gmagick: Here, asking for it ;) No serious i can really reduce the load on servers and with the 2.0.0 extension release it's ready for 7.0 (https://pecl.php.net/package/gmagick) How can i help here?

Please fill an issue here: https://github.com/oerdnj/deb.sury.org/issues I'll look into it when I have some time.

Hello everyone!

Thank you for the various comments and updates. And, of course, a special thank you to Ondřej for his work and his PPA.

Brief intro: My name is Nish and I'm looking into the PHP options for Canonical's Ubuntu Server team.

tl;dr (although, please read it!): Our most reasonable options for Xenial are either *only* PHP5.6 in main or PHP7.0 in main (with no PHP release in universe).

A couple of disclaimers up front:
  - My thoughts are not exhaustive, so I may have forgotten something. Please do not hesitate to ask as we go. And rbasak, ondrej and others, feel free to correct me as needed!
  - While these thoughts are wholly my own opinion, I have discussed them with rbasak and others, so they are considered.
  - No official decision has been reached. I would like to hear from community members on my thoughts, and have a reasonable discussion of what is best.

Our current status quo:
  - PHP5.6 is in the main component in Xenial
  - PHP7.0 is in the universe component in Xenial

To level-set, per https://help.ubuntu.com/community/Repositories/Ubuntu, that means that PHP5.6 is "Officially supported software" while PHP7.0 is "Community maintained software, i.e. not officially supported software".

Going forward, there "are" (some are far less realistic than others, but included for completeness) the following options, as I see it. Note that all options only apply to Xenial, the upcoming 16.04 LTS release.

1) Drop PHP5.6 and PHP7.0 from the Ubuntu repositories
  Pros:
    - No maintenance cost/formal support cost
  Cons:
    - No form of PHP in the official repositories
    - Potentially massive churn of repositories
    - No official upgrade path for PHP 5 users in Wily or Trusty.
    - Users who do wish to have PHP, must use a PPA (Ondřej's or otherwise).
  Conclusion: Not a viable option, end-users expect some release of PHP to be present (and "worst-case", continuity with the version present in 15.10/Wily.)

2) Promote PHP7.0 to main
  Pros:
    - Users are able to install either PHP5.6 or PHP7.0 in Xenial, as they see fit.
    - Users receive support for both PHP5.6 and PHP7.0.
    - Upgrade path is clear for the expected common cases:
      * Update to PHP5.6 during LTS upgrade (Trusty -> Xenial) [minimize likelihood of disruption on LTS]
      * Keep PHP5.6 during Wily -> Xenial [minimize likelihood of disruption on latest release]
      * Upgrade to PHP7.0 during Wily -> Xenial [provide latest version of PHP on latest release]
  Cons:
    - Cost of official support is significant, in terms of bugs and ensuring appropriate security updates occur to the "main" packages.
    - Active support for PHP5.6 upstream ends Dec. 31, 2016. Security support for PHP5.6 upstream ends Dec. 31, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP5.6 security fixes, at least, needing to be maintained. [http://php.net/supported-versions.php].
    - Active support for PHP7.0 upstream ends Dec. 3, 2017. Security support for PHP7.0 upstream ends Dec. 3, 2018. Xenial EOLs in April 2021. So that implies at least several years of PHP7.0 security fixes, at least, needing to be maintained. [http://php.net/supported-vers...

@Nish: Big thanks for sharing the thoughts of the server team and that you take this issue serious :) Running quite a lot web servers with PHP on Ubuntu LTS and RHEL in prodution, i like give you some short feedback on the mentioned options:

1 & 4: are a no go if Ubuntu Server wants to stay as relevant as it is now in the web server OS market. Although it would probably bring a big boost to Raphaël Hertzog's LTS efforts ;)

2: Is what makes users really happy. It will definitely strengthen Ubuntu's role in the PHP market with more work for Canonical.

3 & 5: While i can fully understand the reasons, both will dissatisfy a lot of people. Given the reduced load impact of PHP 7.0 in data centers and the huge install base of widely used PHP 5.* web apps.

So option 2 is the bravest option for Canonical, but will give you the most user satisfaction. Given that the packaging work by Ondřej and others made this dual stack option possible and AFAIK didn't happen with Canonical involved, you could just keep "standing on the shoulders of giants" as maintenance would be mainly communication, syncing and merging with Debian or out sourcing to Ondřej ;). And for just sticking to that, you should really take feedback from the PHP and security teams at Debian :)

BTW i would love to see option 2 happening, as i am still so happy about the other brave move Canonical made with promoting Nginx to main for trusty. I replaced Apache in so many production environments :)

> - No clear (obviously safe?) path for users upgrading from a PHP 5 base (Trusty or Wily) to PHP 7 base.

If you can pull this http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-jessie&id=23e81c46bb4978596efe58a23070eb75dd3d5380 via SRU you might be able to keep src:php5 from trusty on top of xenial (given there are no conflicts in the libraries.

> Re: 7.0 security support ends in 2018

I expect the changes between 7.0 and 7.1 (and 7.2) much less intrusive than changes between 5.6 and 7.x branch, so the security team will have easier job maintaining 7.0 past 2018. (Same with PHP 5.4 <- we pull security changes from PHP 5.5 for the moment.)

> Re: xdebug segfaults

I just updated xdebug to rc4 today - retry with that. I had some users reporting the segfaults in rc3 but fixed in git.

> > Re: xdebug segfaults
>
> I just updated xdebug to rc4 today - retry with that. I had some users reporting the segfaults in rc3 but fixed in git.

Yeah, I actually built RC4 myself last night to test and it didn't seem to make any difference. Note that I'm using the pkg-php-tools from http://anonscm.debian.org/cgit/pkg-php/pkg-php-tools.git/log/?h=master-7.0, but I don't think the issue should be there, but in xdebug itself.

Here's the debug I've gotten so far. The segfault is line 1150 in xdebug_stack.c:

                } else if (edata && edata->prev_execute_data && edata->prev_execute_data->opline && edata->prev_execute_data->opline->opcode == ZEND_INCLUDE_OR_EVAL) {

I added some manual debugging (as I learn how to build non-optimized versions of packages) and got:

edata = 0x7f5b23214030
edata = 0x7f5b23214220
edata->prev_execute_data = 0x7f5b232141b0
edata = 0x7f5b23214380
edata->prev_execute_data = 0x7f5b23214310
edata = 0x7f5b23214850
edata->prev_execute_data = 0x7f5b232147e0
edata->prev_execute_data->opline = 0x7f5b2328d500
Usage:
    pkgtools COMMAND

Options:
    --help: print help
    -h: print help
    --verbose: increase verbosity
    -v: increase verbosity
    --sourcedirectory: set source directory
    -D: set source directory

Commands:
  : Without arguments: print help
edata = 0x7f5b23215000
edata->prev_execute_data = 0x7f5b23214f90
edata->prev_execute_data->opline = 0x3
Segmentation fault (core dumped)

Seems like prev_execute_data is corrupt?

On 26 Jan 2016 5:25 p.m., "Nish Aravamudan" <email address hidden>
wrote:
> - Users who do wish to have PHP 5, must use a PPA (Ondřej's or
otherwise).

Or stick with the current LTS until they're in a position to adopt PHP 7.

At work we won't upgrade to Xenial until all our code is compatible with
PHP 7, and then if Xenial doesn't ship a supported PHP 7 I'll recommend we
switch to a distro that does, or install a supported 3rd party package like
Zend Server. I imagine there are many PHP houses that will do the same. (I
don't mean that to sound like an ultimatum, just illustrating a real world
use case.)

I appreciate all the work people are putting in to try to make this happen.

PHP Mapscript is important to me, is there anything I can do to help with
that?

Cheers,
R

--
"Racing turtles, the grapefruit is winning..."

On 26.01.2016 [19:57:31 -0000], Richard J. Turner wrote:
> On 26 Jan 2016 5:25 p.m., "Nish Aravamudan" <email address hidden>
> wrote:
> > - Users who do wish to have PHP 5, must use a PPA (Ondřej's or
> > otherwise).
>
> Or stick with the current LTS until they're in a position to adopt PHP
> 7.

Absolutely, sorry -- I should have called this out explicitly as an
option.

> At work we won't upgrade to Xenial until all our code is compatible with
> PHP 7, and then if Xenial doesn't ship a supported PHP 7 I'll recommend we
> switch to a distro that does, or install a supported 3rd party package like
> Zend Server. I imagine there are many PHP houses that will do the same. (I
> don't mean that to sound like an ultimatum, just illustrating a real world
> use case.)

This is excellent to understand, thank you for providing your input!

> PHP Mapscript is important to me, is there anything I can do to help with
> that?

I think once/if swig is updated, mapscript will too. If you can take a
look at the swig issue and help out there, that'd be great! Otherwise,
it's on my own todo list.

On 26.01.2016 [19:53:20 -0000], Nish Aravamudan wrote:
> > > Re: xdebug segfaults
> >
> > I just updated xdebug to rc4 today - retry with that. I had some users reporting the segfaults in rc3 but fixed in git.
>
> Yeah, I actually built RC4 myself last night to test and it didn't seem
> to make any difference. Note that I'm using the pkg-php-tools from
> http://anonscm.debian.org/cgit/pkg-php/pkg-php-
> tools.git/log/?h=master-7.0, but I don't think the issue should be
> there, but in xdebug itself.
>
> Here's the debug I've gotten so far. The segfault is line 1150 in
> xdebug_stack.c:
>
> } else if (edata && edata->prev_execute_data &&
> edata->prev_execute_data->opline &&
> edata->prev_execute_data->opline->opcode == ZEND_INCLUDE_OR_EVAL) {
>
> I added some manual debugging (as I learn how to build non-optimized
> versions of packages) and got:

Figured it out and got:

(gdb) print *edata->prev_execute_data
$7 = {opline = 0x3, call = 0x4, return_value = 0x0, func = 0xfbcd80, This = {
    value = {lval = 0, dval = 0, counted = 0x0, str = 0x0, arr = 0x0,
      obj = 0x0, res = 0x0, ref = 0x0, ast = 0x0, zv = 0x0, ptr = 0x0,
      ce = 0x0, func = 0x0, ww = {w1 = 0, w2 = 0}}, u1 = {v = {type = 8 '\b',
        type_flags = 12 '\f', const_flags = 0 '\000', reserved = 2 '\002'},
      type_info = 33557512}, u2 = {var_flags = 1, next = 1, cache_slot = 1,
      lineno = 1, num_args = 1, fe_pos = 1, fe_iter_idx = 1}},
  called_scope = 0x7ffff3203018, prev_execute_data = 0x7ffff3213f20,
  symbol_table = 0x7ffff327d090, run_time_cache = 0x40000c08,
  literals = 0x1069c20}

Will Redis be supported if PHP 7 becomes reality?

> Will Redis be supported if PHP 7 becomes reality?

Do you mean the PHP Redis module? If so, that is already present in Xenial/universe (php-redis).

My team has been running Ondřej's PPA for PHP 7 for the last month.
We run it on Ubuntu 14.04 with nginx 1.8 using WordPress. So far there has not been any issues with it.
My team, boss, and especially our Clients have been so happy to have things run much faster.
Thanks Ondřej

At this point we can not go back. We are fully invested with PHP7.
Even the community around us is jumping right in. We are seeing blog posts, info-graphics, benchmark stats, etc all being passed around.

We use AWS Opsworks with Chef to configure our servers.
So Option 2 is ideal for us as it would require less configuration with Chef.

Honestly, we probably will not jump on 16.04 for awhile unless it has PHP7 by default.
So having php7 on 16.04 would encourage us to adopt 16.04 a lot sooner.
Which would mean the sooner we would write blogs about it, etc to help promote the movement to PHP7 and Ubuntu 16.04

For anyone interessted in gmagick follow: https://github.com/oerdnj/deb.sury.org/issues/239

@Nish What about further communication from the server team, can you keep as informed over here? I think there's not so much need for much more discussion, as the points should be clear now. BTW RedHat even choose 5.4 for RHEL 7 which is like LTS² ;)

Just one last practical thought on dual stack in main (option 2), that would mean you can officially run i.e. Drupal 7 & Drupal 8 or Typo3 6 & Typo3 7 on one server in parallel (using those sexy FPM setups i run with up to 100 pools per server for app seperation).

So a supported and slick dual stack is a really big feature that you can't beat with RHEL+SCL (nested stuff in /opt) cause it really shows the excellence of Debian packaging :) And it is also nice pick up for any marketing actions for Ubuntu as a web server plattform.

So, nothing "official" to provide yet, but I wanted to keep everyone updated.

Based upon feedback from various teams (including security and the archive administrators), it is not tenable for two versions of PHP to live in main.

Given the positive feedback received here for PHP7.0 being available at all, I'm working hard to get a PPA going that would allow PHP7.0 to transition to main, which would also remove PHP5 from main (if/when we go down that path). Primarily, this is verifying all the various reverse-depends on php5* packages are migrated, etc. Also, many many packages in universe must be rebuilt, to pull in the new php* packages for PHP7 support.

The PPA is at https://launchpad.net/~php-ubuntu/+archive/ubuntu/php7.0, but please do not use it for any production-like systems! It is undergoing fairly heavy churn and is intended to be a holding place as I go through and rebuild/bootstrap packages.

Our current state is that phpunit is now installable, but there are several unit tests failing in two stacks, doctrine & symfony. Unfortunately, they form a build-depends cycle and I'm working to bootstrap them up to fully functional versions.

Once we have this base layer of common build-depends packages done, I'm hopeful that we can automate most of the remaining package rebuilds. Then it's just a matter of triaging the failed rebuilds, which I will hopefully get some assistance from our awesome community with!

I'll send out another update once symfony & doctrine have been bootstrapped and the automation has been kicked off.

And then finally, once we do have this "live" somewhere, we'll need to seriously test and consider all the upgrade paths to ensure the transition is as seamless as possible.

Again, no official decision has been made, but I'm working hard that whatever decision is reached, it won't be due to some technical limitations of the packaging wrt. PHP7.0.

-Nish

You can expect a donation if PHP 7 gets in.

thanks a lot for your job.

@Nish Coming just back from FOSDEM and had some more talks about PHP 7.0. As you said right when Canonical is only able to maintain one PHP in main, then it should really be 7.0 or the supported PHP will have double load and half the speed compared. In summer when xenial is heading for production most PHP Projects will have 7.0 support out and everyone will regard 5.* as outdated.

But i would still love dual stack, so i can upgrade all servers from trusty to xenial :)

Thanks a lot guys for your involvement and I cross the fingers to see PHP7 integrated in Ubuntu 16.04 !
How can I / we help to make it before mid February ?

@marmotte31: Don't get confused the community packaged 7.0 for Debian and Ubuntu and so far it's in universe. Now it's Canonical's take if they will support it in main. For helping you can test xenial and PHP7.0 on some dev machines or look for missing packages: http://packages.ubuntu.com/search?suite=xenial&section=all&arch=any&keywords=php&searchon=names

tl;dr: We are aiming to go forward with plans to push PHP 7.0 only in
main for Xenial (16.04), thus dropping PHP 5. We have until 18 February,
Xenial's Feature Freeze data, to vet this out as best we can. I would
like to ask the community to help us see what is broken, what works,
etc. Specifically, we need folks to test the actual use of PHP 7.0 :)

Before, I list examples of what we've immediately thought of to cover,
if you do choose to help out, please provide:
  * Details of what versions used (before & after)
  * What your exact usage was
  * How you determined success
Note that you must be using the Ubuntu packages for PHP and any
PEAR/PECL/external modules. That is, we can only "support" a fully
Ubuntu-version based PHP installation. I must stress, that simply
providing a "Yes it works" response will be insufficient to be sure we
have done things correctly.

Here is our current shortlist of obvious & large things that need
testing:
  - Upgrade success (both of the PHP core and any packages you use).
  - Install success (fresh PHP7.0 installs)
  - Horde
  - Symfony
  - SWIG (*)
  - Wordpress
  - phpmyadmin
  - Drupal
Are there any other frameworks or large Ubuntu-packaged programs,
frameworks or PHP-things we have forgotten?

(*) SWIG: I know it's broken right now, but once it's available...

How to test:
  - Do not do this in production!
  - Spin up a test VM/deployment with Xenial.
  - Add the PPA at https://launchpad.net/~php-ubuntu/+archive/ubuntu/php7.0
  - Ideally, simply an apt-get update; apt-get upgrade will pick up the
    new versions under Xenial.
  - Packages are going to be changed and updated as we go forward.
  - Most of main/universe PHP-dependent packages have been rebuilt.

Please provide your experience in a bug update. We want to both negative
and positive reports!

my test report.

current dev version: Precise Ubuntu 12.04 LTS with php 5.3.10
xenial version: Daliy build xenial-desktop-amd64.iso 05-Feb-2016 08:06 1.4G

fresh install on VirtualBox 5.0.14 r105127
locale used: french
default parameters

hanged on automatic first reboot after system install....
restarted the Virtual Machine, then the system has boot correctly.
installed Guest Additions provided by virtualbox

# add-apt-repository ppa:php-ubuntu/php7.0
# apt-get update
# apt-get upgrade

# apt-get install mysql-server mysql-client
# apt-get install php-cli php
# apt-get install php-mysql php-mcrypt php-gd

optional:
# apt-get install php-tidy

I waste a lot of time for reasons that do not involve php.
mainly 2 points :
1) Porting mysql ini file:
 both table_cache and innodb_data_file_path parameter when defined prevent the MySQL server from starting!!!!
 - table_cache has been replaced by table_open_cache.
 - didn't found for innodb_data_file_path and commented it out!
 Half a day lost for this! I hope this post will help other people...
2) network interface names:
 eth0 is no more the name for the first interface.
 had to recode product licensing php code to deal with that.

php7 itself:

no much to say php7 is working like a charm!
- no pbs with phpMyAdmin-4.5.4.1
- my 105000+ php code lines application(*) just works fine as expected!
I cannot say anything about speed as I have no reference for a VM.

I hope my full week-end day of php7 testing will help to have it by default in xenial!

(*) <offtopic>
It's a new kind of CMS I develop on my free time. http://webportal.yakpro.com
I expect to deliver test versions later this year.
</offtopic>

@Nish Can you explain the changes or diff to Ondřej's packages? I run them in production with Typo3 7 and Drupal 8 but on trusty.

@bhat3 I don't think there are any differences on src:php7.0 (as we coordinate the changes - I just merged couple of patches), so the main differences is in packages written in PHP (and perhaps some PECL modules, haven't checked what has been done in ~php-ubuntu on that front).

On Mon, Feb 8, 2016 at 3:07 AM, bhat3 <email address hidden> wrote:
> @Nish Can you explain the changes or diff to Ondřej's packages? I run
> them in production with Typo3 7 and Drupal 8 but on trusty.

There is no alteration to Ondřej's debian packages (note, that may or
may not be the same as his PPA, but I think it is the same). The core
PHP7 packages are all autosyncing from Debian currently (and will
until feature freeze, aiui).

The difference in ~php-ubuntu relative to Ondřej's PPA should be close
to 0 for packages that are in both, as I believe Ondřej and I are
building from effectively the same source. But the remaining packages
that are only in ~php-ubuntu have been rebuilt so as to only pull in
PHP7.0 dependencies. That in turn required some bootstrapping for some
circular build dependencies. But, generally speaking, source-wise, the
packages in the Xenial archive and the PPA are identical, just with
different deps.

Bug #1543324 filed - [needs-packaging] php-pear
Bug #1543334 filed - [needs-packagin] pkg-php-tools

Bug #1543349 filed - [needs-packaging] php-memcache

Bug #1543361 filed - Rebuild packages for bootstrapping PHP7.0 in archive

Bug #1543376 filed - phpab: add nocheck and stage1 build profiles

Bug #1543399 filed - php-directory-scanner: add nocheck and stage1 build profiles

Bug # 1543693 filed - sync libbson from Debian experimental
Bug # 1543696 filed - sync libmongoc from Debian experimental
Bug # 1543703 filed - [needs-packaging] php-mongodb

Bug # 1543710 filed - php-codesniffer: add nocheck and stage1 build profiles
Bug # 1543721 filed - php-email-validator: add nocheck and stage1 build profiles
Bug # 1543723 filed - libphp-swiftmailer: move to generic PHP dependencies
Bug # 1543740 filed - [needs-packaging] php-proxy-manager 2.0.0
Bug # 1543803 filed - sync aws-sdk-for-php from Debian experimental
Bug # 1543807 filed - [needs-packaging] php-opencloud 2.0.0
Bug # 1543808 filed - Please consider dropping php-guzzle from Ubuntu Xenial

Bug # 1543817 filed - php-guzzlehttp-psr7: add nocheck and stage1 build profiles
Bug # 1543820 filed - jmespath.php: add nocheck and stage1 build profiles
Bug # 1543826 filed - php-monolog: bootstrap for PHP7.0
Bug # 1543846 filed - phpunit-recursion-context: add nocheck and stage1 build profiles
Bug # 1543847 filed - phpunit-diff: add nocheck and stage1 build profiles
Bug # 1543848 filed - phpunit-environment: add nocheck and stage1 build profiles
Bug # 1543849 filed - phpunit-exporter: add nocheck and stage1 build profiles
Bug # 1543850 filed - phpunit-global-state: add nocheck and stage1 build profiles
Bug # 1543851 filed - php-token-stream: add nocheck and stage1 build profiles
Bug # 1543852 filed - php-timer: add nocheck and stage1 build profiles
Bug # 1543853 filed - php-doctrine-instantiator: add nocheck and stage1 build profiles
Bug # 1543855 filed - php-doctrine-collections: add nocheck and stage1 build profiles
Bug # 1534856 filed - php-doctrine-inflector: add nocheck and stage1 build profiles

Bug # 1543867 filed - php-xdebug: ensure segmentation fault fix is in Xenial
Bug # 1543868 filed - php-doctrine-cache: add nocheck and stage1 build profiles
Bug # 1543869 filed - php-doctrine-common: add nocheck and stage1 build profiles

Bug # 1543856 filed - php-doctrine-inflector: add nocheck and stage 1 build profiles [typo above!]

Bug # 1544276 filed - twig: update and bootstrap for PHP7.0 support
Bug # 1544279 filed - symfony: update and bootstrap for PHP7.0 support

Bug # 1544302 filed - php-codecoverage: update and add nocheck and stage1 build profiles
Bug # 1544303 filed - php-codecoverage: update and add nocheck and stage1 build profiles
Bug # 1544304 filed - php-codecoverage: update and add nocheck and stage1 build profiles

err, sorry, c&p error, the last two above are:
Bug # 1544303 filed - phpunit-comparator: update and add nocheck and stage1 build profiles
Bug # 1544304 filed - phpunit-mock-object: update and add nocheck and stage1 build profiles

Bug # 1544307 filed - phpunit: update to PHP7.0 dependencies
Bug # 1544312 filed - Sync php-zend-code 3.0.1-1 (universe) from Debian experimental (main)
Bug # 1544316 filed - doctrine: update to PHP 7.0 dependencies
Bug # 1544318 filed - php-doctrine-data-fixtures: update to PHP7.0 dependencies
Bug # 1544338 filed - php-doctrine-cache-bundle: update and add nocheck and stage1 build profiles
Bug # 1544341 filed - php-doctrine-bundle: update and add nocheck and stage1 build profiles

Bug # 1544352 filed - [PHP7] After bootstrapping, these PHP packages can automatically be rebuilt

These are the instructions for the archive admin to bootstrap symfony/phpunit/doctrine in the archive (to solve build-dependency loops with staged builds).

Updated the instructions and fixed a few typos.

Clarify the sync points in the boostrap process to maximize parallel builds in the archive.

First of all, thank you for the great work! I'm very much looking forward to PHP7 in the new Ubuntu LTS.

I installed the latest 16.04 server image (http://cdimage.ubuntu.com/ubuntu-server/daily/current/xenial-server-amd64.iso) in a VM and added the php-ubuntu/php7.0 PPA.

My goal was to get Nginx up 'n running with PHP FPM. Short story: it's working pretty well!

Some observations. Please forgive me if I'm stating some very obvious things, I'm not a Linux packaging expert at all :)

1) I was surprised that the PHP package seems to have a dependency on Apache. I understood later that php can depend on a number of packages, including php-fpm, and that Apache is simply the first it finds. No biggie, something for the tutorials :)

2) The php-fpm package currently refers to php5.6:

Package php-fpm is a virtual package provided by:
  php7.0-fpm 7.0.3-3
  php5.6-fpm 5.6.18+dfsg-3
You should explicitly select one to install.

3) The default nginx config file has a php 5.6 reference for php-fpm:

/etc/nginx/sites-available/default:57
- # fastcgi_pass unix:/var/run/php5-fpm.sock;
+ # fastcgi_pass unix:/run/php/php7.0-fpm.sock;

4) I was a bit confused that the php-fpm service is called php7.0-fpm.service, whilst the binary is called php-fpm7.0. Although I guess that will be automatically cleared up once the 7.0 is dropped?

5) The phpmyadmin package has php 5.6 dependencies:

sudo apt-get install phpmyadmin
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dbconfig-common dbconfig-mysql javascript-common libjs-jquery
  libjs-sphinxdoc libjs-underscore libmcrypt4 php-gd php-gettext php-mcrypt
  php-pear php-phpseclib php-readline php-tcpdf php5-common php5-gd php5-mysql
  php5.6-common php5.6-phpdbg php7.0-gd php7.0-mcrypt

That's it for now! :)

> 2) The php-fpm package currently refers to php5.6:

Strange, it looks like php-fpm is missing from src:php-defaults, I'll look into that.

> 4) I was a bit confused that the php-fpm service is called php7.0-fpm.service, whilst the binary is called php-fpm7.0.

The service file is called after the package.

> Although I guess that will be automatically cleared up once the 7.0 is dropped?

Nah, it will stay (as there will be 7.1, 7.2, 8.0, ...)

> 5) The phpmyadmin package has php 5.6 dependencies:

There's a PPA from phpmyadmin author somewhere...

> The php-fpm package currently refers to php5.6:

Fixed in src:php-defaults_27

JFTR php7.0-dev_7.0.3-4 also fixes building with new libtool (>= 2.4.6-0.1~) and as Xenial already have this libtool you need to merge the update.

> > The php-fpm package currently refers to php5.6:

> Fixed in src:php-defaults_27

Just checked, can confirm its fixed using the latest server build and the php-ubuntu/php7.0 PPA.

> 1) I was surprised that the PHP package seems to have a dependency on Apache. I understood later that php can depend on a number of packages, including php-fpm, and that Apache is simply the first it finds. No biggie, something for the tutorials :)

@Nish Since Nginx it also in main it would be nice to do an "Depends: apache2 | nginx". But i don't know how much work is that in coop with Debian and how many packages are affected. What do you think?

@bhat3 there's no direct dependency on apache2. php7.0 package just pulls first SAPI and coincidentally it's libapache2-mod-php7. 0

Bug # 1546823 filed - swig: disable PHP bindings until PHP7 support exists

This list of packages all successfully built and passed testing with a relatively automatic `find debian -type f -print0 | xargs -0 sed -i 's/php5/php/g'`.

So, if today is feature freeze for Ubuntu 16.04 LTS, is there any word yet if PHP7 is in or out?

I tested PHP7 and only had problems getting phpMyAdmin, but haven't tried for a few days.

Really, it would be a shame if PHP7 were not in 16.04. I don't see much else to desire for upgrade.

> @bhat3 there's no direct dependency on apache2. php7.0 package just pulls first SAPI and coincidentally it's libapache2-mod-php7. 0

Thanks for clarification :) Just followed Joost claim, altough i never ran into that with PHP itself, but experienced that with PHP related packages like "owncloud" and that was always nasty when you're married to Nginx+FPM in the first place ;)

@Ondrej
> There's a PPA from phpmyadmin author somewhere...

Tried to find it, but without success. Would be nice if someone could link it here.

@rbasak @nacc zmq and imagick PECL extensions modified for PHP 7.0 have been ACCEPTED into unstable today, if you still can import them...

It would be nice to know definitively if PHP7 will be in Ubuntu 16.04 or not. Because I (and I think people other than me) don't know if I can write PHP7 or PHP5 code.

So a few points, feature freeze is today, but we have an exception (effectively) for PHP7, while we wait on resources being available to help me out (as I don't have appropriate rights yet -- and even if I did the bootstrap of phpunit/symphony/doctrine would need an admin to assist).

I have provided those bootstrap instructions in this bug, as well, as listed out packages that can be automatically rebuilt, as well as those that need a simple sed to rebuild. That covers *most* of the packages that rely on php in the archive. My goal by the end of today is to have this bug updated with the remaining ~150 packages that either failed to build or failed to test, so every PHP package is mentioned somewhere in relation to this bug.

So, the short answer is PHP 7.0 is still planned on transitioning to main and PHP 5 will be out of the archive, but it will happen after the feature freeze most likely.

Hi Nish, that is amazing news. Thanks a lot!

Bug # 1547183 filed - Remove php5 specific packages from the archive

Bug # 1547245 filed - php7.0: remove dependencies that come from universe

Maybe it's too late to throw my hat (and opinion) in, but from a hosting/hoster perspective, that's really a double-edged sword. Of course it would be splendid, if we could migrate all customers and applications to PHP7 as soon as possible. But with PHP itself increasing the support level of PHP5.6 to almost the same EOL date that PHP7 has, wouldn't it be possible to let BOTH stay in the repositories? As both now have a distinctive namespace (php5/php7) it would be incredibly helpful for us server or hosting providers, to get our customers to migrate to the new base OS (xenial) while having the possibility to select PHP5.6 or PHP7 as their web stack. With xenial only having PHP7 packages, most of our clientel will supposedly need to stay on trusty or - even worse - has to upgrade to trusty from precise, because (as sad as that is) there are a great many procucts out there, that don't have PHP7 compatibility right now (and don't plan to in the near future). Even worse when throwing in products like ZendGuard (*shiver*) into the mix, that don't support PHP7 yet (ergo all encrypted stuff from them won't work on PHP7/xenial for some time to come).

So having both php version lines would actually be a huge blessing for hosting/server customers and easier upgrade paths.

Jens G. said:
"there are a great many procucts out there, that don't have PHP7 compatibility right now (and don't plan to in the near future). Even worse when throwing in products like ZendGuard (*shiver*) into the mix, that don't support PHP7 yet (ergo all encrypted stuff from them won't work on PHP7/xenial for some time to come)."

You say many products..... and do not mention anything else than ZendGuard...

I always had problems with ZendGuard not supporting php releases, (or supporting them 2 years after the release is integrated in a ubuntu LTS release cf trusty...).
I also had problems with their "perpetual licence" that is not so perpetual...

So I wrote a php obfuscator for myself, that I made freely available under MIT license at https://github.com/pk-fr/yakpro-po
Perhaps you could consider using it....

php7 is a must!

@jegr Just run Ubuntu Trusty for PHP 5.x, virtualization is nowadays cheaper then dual PHP version maintenance. Or just have two sets of machines on on Trusty and second on Xenial and migrate the customers between those platforms.

The story with "foo doesn't support bar" is getting too old as I've heard it too many times. And it usually means "somebody else should carry the costs for supporting this really old unmaintained piece of software for us".

> So I wrote a php obfuscator for myself, that I made freely available under MIT license at https://github.com/pk-fr/yakpro-po
> Perhaps you could consider using it....

We are a hosting and service company and only administer, consult and service our customers. Their web agencies or programmers bring the requirements and we have to deal with it.

> php7 is a must!

That is your stand and I personally find it very valid. But we are not talking any OSS projects, but (sometimes) closed source software like various shops or modules etc. And those companies won't simply change just because we want them too. And our customers (as hosting company) have invested quite a hefty sum into their shops, so they, too, won't just switch to another software including external connections, payment etc. etc. just because PHP made a new release.

It's extremely frustrating on our side as I see the same thing as the trusty release will be hitting us again. A great new OS that we simply can't use for many customers, as they rely on older versions, that won't switch for months (or years). And PHP plays a great deal in that stack that is used.

I'm not sure if this bug is the appropriate place to discuss this, but can't your customers who require an older version of PHP simply stay on 14.04LTS? It is supported until 2019. Isn't that the whole point of LTS releases?

@ondrej I agree to some degree, as it would be reasonable to run xenial under the hood, not only because of the base OS but the rest of the web stack, too.

And as already stated, as PHP5.6/7 are supported from PHP to almost the same EOL time now, so it's not about "please support old unmaintained software for us" ;) As Trusty includes PHP 5.5, that would be more of a problem as to have 5.6 & 7 as options on a new platform with support until 2021. Installing trusty mid- to end-2016 feels the same as the precise/trusty thingy we had to endure the last 4 years.

That's why I'm just throwing that idea into the room. I know what we have to do otherwise, but just wanted to have a shot at perhaps brighten up the situation :)

@jstsch I'm not trying to start a specific discussion about customers or software but merely was pointing out that service providers or hosters would actually profit from both package branches staying available instead dropping one of them after freeze. And as both EOL dates are nearly the same it isn't like one of them is a support nightmare and unsupported upstream in near future.

Of course customers on trusty can stay on that. But we'll alert precise customers shortly about options for upgrades. And if xenial stays on php7 those are most likely to become trusty boxes as well, what I personally find a rather unsatisfactory solution but perhaps is inevitable.

Jens G. is right. In fact, the PHP community has extended the 5.6 support: https://wiki.php.net/rfc/php56timeline

@jegr The folks who already have PHP code compatible with PHP 5.6 shouldn't have any problems updating to PHP 7.0. I would worry more about the upgrade from PHP 5.3 in precise to PHP 5.5 in trusty.

If the customers could upgrade their code to PHP 5.6, they might as well jump directly to PHP 7.0. The most intrusive changes that broke software has happened between PHP 5.3 and PHP 5.4.

@jstsch you need OpenSSL 1.0.2 for ALPN support (needed for proper HTTP/2 negotiation), not included in Ubuntu 14.04. Why not give the possibility to use http/2 with php5.6, since it is still supported and active?

@vinc-q @jegr An upstream unmaintained code would be total no-go, but still having two versions of PHP in the main is a quite big burden for Ubuntu folks.

I could afford to run PPAs with multiple PHP versions, because I have the liberty of saying: "upstream bug, bummer" and do nothing about it if I don't have time or motivation to fix it. That's the freedom Ubuntu folks don't have, so I am at their side. Just look at the PHP bug lists (both in Debian and Ubuntu).

Guys, please can you keep the noise down in here? I really appreciate the community discussion, but doing it in this bug just creates noise for the developers working on this. If you want to continue this discussion, you're welcome to do it on the ubuntu-server mailing list (https://lists.ubuntu.com/mailman/listinfo/ubuntu-server) but please try to stick to a single thread. You're not reaching the right people in this bug anyway.

@ondrej there are many features to be removed in PHP7. Of course, already deprecated , but who manages hosting has no control over the code that cannot work on PHP7.

@racb why isn't this the appropriate place to talk about the manner of this update?

This bug is whatever we (collectively, including you) want it to be. But if you want it to be a subjective discussion about the pros and cons of what Canonical should commit to supporting in main, then that's fine but the developers actually doing the work will just start to ignore bug comments (since they are not productive), start tracking their actual work in a different bug, and we'll mark this bug "Opinion" and let you carry on.

I welcome your opinion, but let's not impede development work by mixing technical progress with subjective opinionated conversation in the same bug.

> since they are not productive

By this I mean that they are not productive to landing PHP 7 in main in Ubuntu, which is the developers' direct goal for Xenial at the moment and is what the bug title currently says this bug is for. I didn't mean to imply that your comments are not productive; sorry if this came across wrong.

@racb you're right, sorry.

In response to #53, speaking for the Drupal community, I'd like to report that we have Drupal 8 passing on PHP 7. See https://www.drupal.org/node/3060/qa for details.

FYI, PHP 7.0 is in main now (7.0.4-5), and several extensions with build-dependencies from universe are in universe. We are still working on the removal of PHP5, but I think this bug can be marked fix release as we are using other bugs to track specific actions.

@colan, to clarify, I believe drupal7 does *not* support PHP7.0, is that accurate? Currently niether debian nor ubuntu have a packaged version of drupal8.

@Nish Yes Drupal 7 doesn't yet support 7.0 and as much as i like Debian packages it makes more sense to deploy Drupal with Git.

There are plans to get Drupal 7 working with PHP 7, but there are still some issues remaining. With everything that's going on with Drupal 8, I don't think folks have had a chance to jump into this too deeply just yet. For more information, see https://www.drupal.org/node/2454439.

I wouldn't focus too much on the Debian packages. In my experience, they're not used very widely (as stated above) as there are usually custom changes. So getting Drupal 7 running on PHP 7 (without the Debian packages) would be the goal here. The packages aren't even mentioned in the official installation guide, https://www.drupal.org/documentation/install/download, or on the OS-specific page: https://www.drupal.org/node/557908.

Having said that, though, I'd be curious to know if the package maintainers had any insight they could share.

@bhat3, @colan,

Thank you very much for the feedback. I just submitted a debdiff in Bug # 1544352 for drupal7 as it is in 16.04 to change the deps to PHP7. It does work, in that I can setup a very basic instance and it ... runs :) But I don't really have the bandwidth to test it further. While I understand that upstream (drupal.org) may not mention these packages, the goal is obviously for a distribution to provide a self-sufficient instance. Would either of you be able to help test that version once it lands and indicate which if any of the upstream patches are relevant? Feel free to contact me offlist if need be. Thanks!

I'm not able to help with this at the moment, but I sent an e-mail to the package maintainers letting them know. Hopefully they'll get in touch.

@nacc,

I'm really sorry to pester as you must be v. busy at this point but is there a definitive word on what's going to happen with 16.04 GA? It's only 3 weeks away and people are having to plan out what release they'll be deploying in the near future.

FWIW as a service provider, I'm squarely with @jegr : choice (as in two supported versions as is the case in beta 2) would be much preferable!

On 01.04.2016 [06:05:01 -0000], Christian Sarrasin wrote:
> @nacc,
>
> I'm really sorry to pester as you must be v. busy at this point but is
> there a definitive word on what's going to happen with 16.04 GA? It's
> only 3 weeks away and people are having to plan out what release they'll
> be deploying in the near future.

Yep, we're going to be php7.0 only, as stated prior. Sorry for the
silence, I've been heads-down updating packages and dropping ones that
are not supported -- we are down to about 95 reverse-dependencies
holding php5 in the archive; I'm hopeful to get through that list today.

> FWIW as a service provider, I'm squarely with @jegr : choice (as in two
> supported versions as is the case in beta 2) would be much preferable!

That is more the case by happenstance; php5 is in universe because to
remove it directly would have broken much of the php part of the archive
:)

Just an FYI to all, php5 has been removed from Xenial and php7.0 is the only available PHP in 16.04!

@Nish Thank you so much! Where can I donate?

@Nish You mean the only available PHP in main or did i miss something about php5.6 in universe?

On 11.04.2016 [08:53:49 -0000], bhat3 wrote:
> @Nish You mean the only available PHP in main or did i miss something
> about php5.6 in universe?

There are no PHP5 options officially provided in the repositories in
16.04, in main or universe. The issue becomes, if we have PHP5
officially in universe, whether end-users read the policies or not, it
will appear to be supported (particularly for security fixes), except it
won't be. We are slightly ahead of Debian in this migration, but they
are going down the same path in parallel.

For PHP5, end-users should stay on Trusty (or run it in a
container/VM/etc).

@Nish thanks for clarification :) I can fully understand the decision, but it's still a burden for any PHP5 project there having only a three year LTS from Ubuntu left. Just been to a Drupal Conference this weekend and for example we will probably never see Drupal 7 in production "on anything" other than trusty or in the long run CentOS/RHEL (they will support PHP5 the ultralong enterprise way).

Anyway great to have PHP 7.0 in and big thanks for all you effort. Now the whole PHP community needs to migrate to PHP7 and all data centers will be happy then running xenial :)

BTW: My personal burden is that i can't update all our trusty servers to xenial now and can't finally consolidate to systemd (having also RHEL servers). In general that means a big maintenance burden to Ubuntu admins, as you will not only start to have two production systems but also two staging and two development systems with xenial and trusty. So while PHP7 has 2x times less resource usage i will have 2x times resources spend on not being able to consolidating and combining all servers to Ubuntu 16.04 ;) ;) ;)

On 12.04.2016 [09:28:47 -0000], bhat3 wrote:
> @Nish thanks for clarification :) I can fully understand the decision,
> but it's still a burden for any PHP5 project there having only a three
> year LTS from Ubuntu left. Just been to a Drupal Conference this weekend
> and for example we will probably never see Drupal 7 in production "on
> anything" other than trusty or in the long run CentOS/RHEL (they will
> support PHP5 the ultralong enterprise way).

3 years *should* be sufficient time to move to PHP7.0 -- but that's just
my opinion (and wouldn't PHP5 be out of support by then anyways?)

Ack on Drupal 7 -- I have a test build of Drupal 8 (which does support
PHP7 at https://launchpad.net/~nacc/+archive/ubuntu/php7 if people want
to test/verify). Upstream Drupal 7 is still not passing all tests with
PHP7 last I checked, so we've left it broken for now in the archive.

> Anyway great to have PHP 7.0 in and big thanks for all you effort. Now
> the whole PHP community needs to migrate to PHP7 and all data centers
> will be happy then running xenial :)

That would be easiest :)

> BTW: My personal burden is that i can't update all our trusty servers to
> xenial now and can't finally consolidate to systemd (having also RHEL
> servers). In general that means a big maintenance burden to Ubuntu
> admins, as you will not only start to have two production systems but
> also two staging and two development systems with xenial and trusty. So
> while PHP7 has 2x times less resource usage i will have 2x times
> resources spend on not being able to consolidating and combining all
> servers to Ubuntu 16.04 ;) ;) ;)

Might I suggest (I don't know any or all of the details of your customer
requirements) investigating using lxd or adapt to provide Trusty in a
container (or if you need more specific requirements a VM?) and use port
manipulation to redirect to the host webserver? Then you should be able
to server PHP5 and PHP7 websites from the same installation, with both
being fully supported.

If I find some time this week or next, maybe I'll work on a blog post or
something that will help document such a configuration, at least as an
example. I will also see if I can find some way to document the
performance impact.

@Nish Sorry for the late reply:

> 3 years *should* be sufficient time to move to PHP7.0 -- but that's just my opinion (and wouldn't PHP5 be out of support by then anyways?)

In theory yes, but in practice not. I.e. my company just launched a Drupal 7 project last week and won't except a relaunch in the next three years. We already did Drupal 8 but it's not yet stable when you also look at all the modules.

> Upstream Drupal 7 is still not passing all tests with PHP7 last I checked, so we've left it broken for now in the archive.

You don't support PHP5 anymore so you should have deleted it from the archive. All the man power goes to the Drupal 8 ecosystem right now, so it will most probably stay a PHP5 app all along.

> If I find some time this week or next, maybe I'll work on a blog post or something that will help document such a configuration, at least as an example. I will also see if I can find some way to document the performance impact.

That sounds great and could indeed be a solution using Nginx as Reverse Proxy and the stuff in LXD as an upstream for it. But it's still a complex setup and LXD/LXC got some security problems as Matthew Garrett pointed out. Anyway i am willing to help you out on that if i can and we could do an example with Drupal 7 as best practice for upgrading to xenial. Just write me a mail and i share you my contact details.

> LXD/LXC got some security problems as Matthew Garrett pointed out.

This is irrelevant to this use case. If you're prepared to run PHP5 on your host, then running it inside a container on that host instead can leave you no worse in security terms even if you assume that containers provide no security at all.

@Robie: Fully agree on that. It was just for the record so nobody thinks this is a security enhancement like isolating PHP5 with LX* but rather a way for still migrating a server to xenial. Beside the container hype it's by nature more complex and tricky to do isolation with containers than virtualization, that's why i like that Canonical pushes LXC development as some gurus claimed since years that they can escape a LXC container and interfere with the host.

PHP7 is incompatible with many PECL extensions which are used by a LOT of websites, and are therefore VERY popular.

Any release of Ubuntu which doesn't include PHP5.6 out of the box, is going to be a non-starter in the server world. PHP7 is just too new. No one has had time to adapt all of the incredibly important and vast collection of PECL extensions to PHP7 yet. PHP7 will take years to adopt. Pushing out an Ubuntu release which is PHP7-centric is most defintely a non-starter.

@r5n Name those PECL extensions. General statements are not useful to anybody.

As a counter "general statement" - no, adopting PHP 7 will not take years, it's already happening and it's not such huge deal as PHP 4 to PHP 5 transition. Most if not all of the PHP 5.6 compatible code run just fine with PHP 7.

And as is was already stated here. If you require PHP 5.x, you can just stay with Ubuntu 14.04 LTS Trusty.

I'm co-ordinating the gophp7-ext initiative, if there are still some extensions missing, can you let me know which ones? I'm not aware of very many major extensions in pecl that don't have an update available at this point. Modern PHP 5 code will run on PHP 7 with few or no amendments - adoption for most companies will be well within the timescale of this ubuntu LTS release and the next one so the PHP 7 version is the right choice IMO.

Can I just say a big THANKS to everyone that made this happen, especially @ondrej? You and Ubuntu all rock :)

I am going to skip over the already addressed php 7 dooms 16.04LTS from "servers" outside of saying it's the only thing our managed VPS clients have been talking about for months, some even postponing projects launched on our systems until 16.04LTS was available, all because of it shipping with php 7.

"Can I just say a big THANKS to everyone that made this happen, especially @ondrej? You and Ubuntu all rock :)" - I have to second this! Amazing work, and SO very very happy it made it in 16.04LTS. Thank you from all of my staff and clients alike.

While I appreciate everyone's input, at this point, this bug is done/closed :) If you have a problem with a particular package provided by Ubuntu, please file a new bug.

Thanks!
Nish