Failed to fetch PPA information (PHP 5.6 / Ubuntu 12.04).

[fubarhouse]

Assuming we have no possibility of upgrading Ubuntu or PHP, what's the recommended course of action on the following error?

TASK [Add repository for PHP 5.6.] *********************************************
fatal: [20161107093340.loc.gbuild.net]: FAILED! => {"changed": false, "failed": true, "msg": "failed to fetch PPA information, error was: HTTP Error 404: Not Found"}

[fubarhouse]

So it seems that because the PPA has been consolidated into https://launchpad.net/~ondrej/+archive/ubuntu/php, package names have simply changed.

I propose that PHP 5.5 repository changes to this one, and all relevant package names listed on the documentation change to their corresponding package name. Notably php-fpm and php-memcached, but I'm yet to go through the list thoroughly.

for example, php_memcached_package should now be fixed to php-memcached instead of php5.6-memcached.

I'm yet to do more testing, but it simply updating the documentation should do the trick.

[thom8]

The repo referenced here has now been deprecated -- https://github.com/geerlingguy/drupal-vm/blob/master/provisioning/tasks/init-debian.yml#L24 / ppa:ondrej/php5

ppa:ondrej/php supports 5.5, 5.6 & 7.x

[fubarhouse]

In that case, could we perhaps update the documentation to make the package names or variable references refer to valid packages?

[fubarhouse]

Doing some testing with the packages now, and it seems like the following will ensure PHP 7 gets installed as well as 5.6, but the system defaults to 7.0.

php5.6-apcu

vagrant@20161107194036:~$ sudo apt-get install php5.6-apcu
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'php-apcu' instead of 'php5.6-apcu'
The following extra packages will be installed:
  libphp7.0-embed php-apcu-bc php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline
The following NEW packages will be installed:
  libphp7.0-embed php-apcu php-apcu-bc php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline
0 upgraded, 8 newly installed, 0 to remove and 30 not upgraded.

php-pear

vagrant@20161107194036:~$ sudo apt-get install php-pear
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libedit2 libpcre3 php-cli php-common php-xml php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline php7.0-xml
The following NEW packages will be installed:
  php-cli php-common php-pear php-xml php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-readline php7.0-xml
The following packages will be upgraded:
  libedit2 libpcre3
2 upgraded, 10 newly installed, 0 to remove and 30 not upgraded.

I vote to remove the following from the documentation on the grounds that they ensure PHP 5.6 is not being used upon completion of the playbook.

  - php5.6-apcu
  - php-pear

Taking these packages out of the build makes it all work again like a bought one!

I'd also recommend adding the following, but I'll leave that decision up to somebody else - but I'll be using it until APC can work under 5.6 with a supported repository.

php_enable_apc: false

[thom8]

To avoid this becoming an XY problem, what are you trying to do?

[fubarhouse]

What am I trying to do?

Simply build a new vagrant box using Drupal VM with certain variables, custom roles etc.
We do however use Ubuntu 12.04 and PHP 5.6, and not knowing much about the brand new problem identified this morning I couldn't resolve quickly - it would in fact prevent everybody in my team from working at some point...

Knowing the problem better now, I can easily resolve it in my team - but others using the same setup are inevitably going to face it. I would think it'd be sensible to get the information out there and those interested parties can handle it how they wish.

Removing the packages prevents PHP7 being installed - which my team has an invested interest in keeping away from. Adding the php_enable_apc: false prevents errors coming from an assumed php-apc dependency which doesn't exist - but the new PPA doesn't feature APC for PHP5 unfortunately.

Does this answer your question?

[geerlingguy]

FYI, there's a lot of totally wacky things that happen depending on the specific packages you install—Ondrej's PPA seems to cater towards an 'SSH in and do things' audience, so most of the workarounds mentioned in the PPA's docs center on 'edit your .bash_profile file and do this or that', but that really doesn't work for automation 📦

I did fix this recently for PHP 5.6 (because it hit the same issue), and @thom8 posted an update for 5.5 in #972.

But if you install any package that recommends/suggests anything having to do with PHP 7, then Ondrej's PPA will install and default the system php command to PHP 7. There's not much you can do about that. See: geerlingguy/ansible-role-php@06d8a0e

[geerlingguy]

(And yet again, and again, and again, this is why I prefer RHEL/CentOS for my own servers... configuration is almost always simpler, weird things don't happen as often, and the assumption package maintainers make is that you aren't sitting around twiddling settings on your servers by hand all the time :P)

The only reason I default Drupal VM to Ubuntu is because it seems most devs who have ever heard of Linux have only ever heard of Ubuntu.

[geerlingguy]

/rantmode off

[geerlingguy]

This should be fixed via the PR @thom8 just submitted—see: https://github.com/oerdnj/deb.sury.org/wiki/PPA-migration-to-ppa:ondrej-php#why-is-php70-cli-always-installed as well. (In addition to geerlingguy/ansible-role-php#158 for an upstream test issue with Ubuntu 12.04).

[fubarhouse]

I'll update the roles and system and try again, see what happens.

This wouldn't be the first time Ubuntu has given unexpected results - but it could very well be years before I'm able to (allowed to) move it into a different distribution or php version.

Our Acquia server is built upon Ubuntu 12.04 and PHP 5.6, and whilst our remote server is using that configuration we are also bound to it. It could very well be years, and I may not even work here anymore by the time that happens.

Continued support is a must for us, even if I need to create private roles myself to allow that to happen. With that said, I hear your complaints loud and clear.