Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#56553 - [nextcloud] Not compatible with PHP 7.2"

Attached to Project: Community Packages
Opened by Natanji (Natanji) - Sunday, 03 December 2017, 18:17 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 10 January 2018, 04:28 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 16
Private No


After upgrading php today, Nextcloud printed a message: "This version of Nextcloud is not compatible with PHP 7.2". Indeed this is a known upstream issue that will seemingly not be fixed, because 7.2 support will only come with Nextcloud 13:
Since Nextcloud 13 is not yet available, the package needs to be updated with a requirement of php<7.2 such that any update of PHP on a machine is deferred until nextcloud 13 is available.

Additional info:
* package version: nextcloud 12.0.3-3

Steps to reproduce:
* update php to 7.2 while nextcloud is installed
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Wednesday, 10 January 2018, 04:28 GMT
Reason for closing:  Fixed
Additional comments about closing:  nextcloud 12.0.4-2
Comment by David Runge (dvzrv) - Monday, 04 December 2017, 10:38 GMT
Seems we have to wait until nextcloud 13.
The beta apparently works with it. 12.0.4 does not.
However, I would refrain from patching this again, unless upstream says it's good.
Comment by Natanji (Natanji) - Monday, 04 December 2017, 12:10 GMT
I'd say at least the requirement should be added ASAP before people install php-7.2 and see their setup breaking, like I did.
Comment by David Runge (dvzrv) - Monday, 04 December 2017, 12:25 GMT
I agree.
However, I wrote a mail to arch-general to give a heads up, but it's not very likely, that all affected people will read it in time.
Comment by Sergej Pupykin (sergej) - Monday, 04 December 2017, 12:42 GMT
I've added php<7.2 to nextcloud 12.0.4
Comment by Natanji (Natanji) - Monday, 04 December 2017, 13:05 GMT
Does anybody have an advice on downgrading the setup so apache works again? I downgraded the php packages to these versions here:
php 7.1.11-1
php-apache 7.1.11-1
php-gd 7.1.11-1
But when I try to start the httpd service (apache is installed), I get:
httpd[10228]: httpd: Syntax error on line 538 of /etc/httpd/conf/httpd.conf: Cannot load modules/ into server: cannot open shared object file: No such file or directory

Downgrading apache to 2.4.28-1 (like before the php update) didn't help.
Comment by Eli Schwartz (eschwartz) - Monday, 04 December 2017, 13:17 GMT
That's because you did a partial update. The correct solution is to not upgrade anything, I guess... or stop using NextCloud. It's a pity the nextcloud maintainers don't feel like fixing actual compatibility problems in a point release. Working with current versions of php is not a "feature release".
Comment by Sergej Pupykin (sergej) - Monday, 04 December 2017, 13:19 GMT
@Natanji You can downgrade icu and its deps.
Or check /var/log/pacman.log for last update and downgrade all mentioned packages.
Comment by David Runge (dvzrv) - Monday, 04 December 2017, 13:24 GMT
@Natanji: I think a look into your cache might help to find what you missed for downgrade: `ls -lah /var/cache/pacman/pkg/php*`
Note that, the latest php release makes php-mcrypt obsolete (virtual).

@eschwartz: Very unfortunate indeed. I nudged them on twitter for it, but I'll most likely write a bug report for it, if there isn't one yet.
Comment by tom (archtom) - Monday, 04 December 2017, 14:01 GMT
I did

pacman -Q | grep php

and downgraded all packages with php 7.2

DOWNGRADE_FROM_CACHE=0 downgrade php-7.1.12-2 php-apache-7.1.12-2 php-cgi-7.1.12-2 php-fpm-7.1.12-2 php-gd-7.1.12-2 php-intl-7.1.12-2 php-sqlite-7.1.12-2 php-xsl-7.1.12-2

and rebooted. Everything working again so far.
Comment by Natanji (Natanji) - Monday, 04 December 2017, 14:10 GMT
Interesting, for me downgrading the php-packages was not enough. I had to downgrade icu, but then it would still fail because one of its deps required the .60 version apparently. So I had a look at its deps. Since icu has a LOT of deps, I opted only for the libraries and downgraded lib32-icu, libcdr, libfbclient, libical, libmspub, libphonenumber, libvisio and libxml2. Now apache works again, but I really hope this now won't break my system in other ways...

What I don't understand is why I can't pacman -Syu anymore now. After the downgrade of php, I should satisfy the new dependencies I called for. But it fails with "cannot satisfy dependencies, nextcloud requires php<7.2" despite php and associated php-* modules being on version 7.1.11-1. Is pacman not able to only upgrade packages that do not in some way depend on php?
Comment by Eli Schwartz (eschwartz) - Monday, 04 December 2017, 14:36 GMT
Uh, because `pacman -Syu` says "upgrade all packages, including nextcloud and php"...

Really, you should probably consider either running nextcloud-git or one of the billion old php packages in the AUR (you can make a php71 package, even). That way you will have both an upgraded system and a working nextcloud...

Comment by tom (archtom) - Monday, 04 December 2017, 14:52 GMT
@Natanji: There is also a package called nextcloud-testing in the AUR which is on the latest beta version if you don`t want to go with daily git changes.
Comment by Martin Saraceno (tinux) - Tuesday, 05 December 2017, 08:57 GMT
FYI, I also had to make the following downgrade for nextcloud to work again: php-apcu (5.1.8-2 => 5.1.8-1)
Comment by David Runge (dvzrv) - Tuesday, 05 December 2017, 10:47 GMT
FYI: There's another upstream bug report I opened [1], that now got some traction, but has already been closed again.

Comment by Tiago Peixoto (count0) - Tuesday, 05 December 2017, 14:37 GMT
It seems to me that patching it up to the beta version will be to everyone's interest. There is little point of having a package in the repository that cannot be installed.

Right now I have to choose between removing nextcloud, which I use regularly, or updating my system.
Comment by Eli Schwartz (eschwartz) - Tuesday, 05 December 2017, 15:50 GMT
Well, I get the impression from the fact that that wasn't initially done, that it would be non-trivial to do so.
Comment by Natanji (Natanji) - Tuesday, 05 December 2017, 17:10 GMT
As far as I know "beta" means Nextcloud 13 is feature complete but still has some bugs that need to be ironed out. In my opinion, a stable piece of software must not be replaced with a beta version that could, among other things, lead to data loss. One problem I see is that while there is probably a migration procedure from Nextcloud 12 to 13, the other direction might not work. Thus upgrading this package to the 13 beta might make it impossible for users to go back to a previous version of the package in case it indeed turns out to be unstable. This could effectively lead to users not being able to access their data anymore.

If we had known of this problem in advance, Arch would have only had to simply delay the php update until all software in the repositories is compatible with it. But since apparently nobody was informed of this in advance, this is no longer possible. Upstream not communicating their software's limits and requirements with downstream is always a problem and in this case, it led to this broken situation - which I'm not sure what to do about...

The best solution at this point would indeed be to add a php71 package, but not to the AUR: a [community] package such as this one must not depend on AUR packages. It would have to be added **to the official Arch repositories**, which is linked against the updated library binaries, and provides php. I'm not sure if that is against the philosophy of Arch though, but then again, there's both "python" and "python2" so why the hell not.
Comment by Natanji (Natanji) - Tuesday, 05 December 2017, 18:18 GMT
@sergej: Can you get the PKGBUILD of the previous version of the php package, make a new php71 package (well... package*s*, there are a bunch of php-* modules too after all that would now need to get php71-* packages, at least where it's a dependency or optdep) that provides php so other software can use it, and then make the nextcloud package depend on it? As a requirement of nextcloud, these php71 packages would automatically be included in [community] as well, from what I gather.

I know this additional work sucks, but I believe this is, at this point, the only way to fix this problem. To me it seems clear by now that upstream is not gonna lift a finger to fix this.
Comment by David Runge (dvzrv) - Thursday, 07 December 2017, 13:57 GMT
Hmm, I guess, one of the things to take away from this is the following:

We have to make sure, that "infrastructure applications" (or however you might want to call them), such as nextcloud, are cross-checked _before_ php is updated in [extra].
Guess the only way to make sure, that this happens, is a) to add proper versioned depends for php to these applications (if you're actually able to find out what they are) and b) for Pierre Schmitz to check these depends and hold off on the upgrade.
@eschwartz: Could you add him to this bug?
Comment by Simon Thiel (thielsn) - Wednesday, 27 December 2017, 15:13 GMT
> There is little point of having a package in the repository that cannot be installed.

This is a very valid point.

Since there is no clean solution, I'm forced to wait with any updated until we have a php71 package and dependency or the released nextcloud 13, whichever might come first.

Since the latter might take months, I would prefer to have the php71 package solution; or at least some clear instructions, how this could be done with the AUR packages without breaking the existing installation and keep it upgradable to future releases/allow to switch back to non-AUR package after nextcloud 13 has been released.

Comment by Doug Newgard (Scimmia) - Wednesday, 27 December 2017, 22:14 GMT
This is broken for more than 3 weeks now, is it time to just package the beta yet?
Comment by Chih-Hsuan Yen (yan12125) - Thursday, 28 December 2017, 02:22 GMT
There's an issue with nextcloud 13 beta: not all apps are ready for nextcloud 13 yet. For example, I need to use git-master for nextcloud-app-tasks (
Comment by Musikolo (Musikolo) - Thursday, 28 December 2017, 02:24 GMT
For those that cannot rollback to version 12 or want to use nextcloud 13, I think they could consider using nextcloud-git package from AUR (, at least until nextcloud 13 gets released.

I think this package (nextcloud) should remain with stable versions only. In my case, I could upgrade my system by ignoring all php packages, i.e., by adding the following line to my /etc/pacman.conf file:

IgnorePkg = php php-apcu php-apcu-bc php-embed php-fpm php-gd php-intl

Once nextcloud 13 is released and it's safe to upgrade to php-7.2, the above line can be removed.

I hope it helps!
Comment by Chih-Hsuan Yen (yan12125) - Thursday, 28 December 2017, 02:35 GMT
Hi Eli Schwartz and Doug Newgard,

Could you also add Pierre Schmitz (the maintainer of php* packages) to assignees of this ticket? I think in the future, php should not be updated (or should be kept in [testing]) until a stable release of nextcloud is compatible.
Comment by Doug Newgard (Scimmia) - Thursday, 28 December 2017, 02:38 GMT
Packaging the beta is a much better option than leaving it broken. Musikolo's option is a partial update, which is not supported and could break any number of things.
Comment by Marvin (mwwn) - Monday, 08 January 2018, 01:05 GMT
Pacman still doesn't fully protect you from breaking your installation, because not all php packages are required to be <7.2. At least php-fpm should get that requirement, too.
Comment by Eli Schwartz (eschwartz) - Tuesday, 09 January 2018, 15:25 GMT
This is getting ridiculous:

It doesn't appear that there is any attempt to fix this in a point release, and the package has been broken (== cannot be newly installed and prevents system updates if already installed) for over a month.

Are nextcloud planning to release nextcloud 13 *very* soon? Because if not, we very much need to delete this from the repos until it is no longer utterly broken.
Comment by Sergej Pupykin (sergej) - Tuesday, 09 January 2018, 17:24 GMT
I've put php71*packages to community-testing, could you please check if it works?
Comment by Eli Schwartz (eschwartz) - Tuesday, 09 January 2018, 17:54 GMT
sergej, thanks for adding this.

I think they should probably also provide php-whatever=7.1.13 as well, that way packages which already have a versioned dependency on php can seamlessly use this. It is easy to do with by adding the following to each split package function:

Comment by Sergej Pupykin (sergej) - Tuesday, 09 January 2018, 18:14 GMT
I updated php71, drupal, nextcloud in community-testing
Comment by Luca Weiss (z3ntu) - Tuesday, 09 January 2018, 21:33 GMT
php71 from community-testing works for me! (using php71 php71-apache php71-gd php71-intl php71-mcrypt php71-sqlite)
Comment by Natanji (Natanji) - Wednesday, 10 January 2018, 00:03 GMT
I can confirm that this works for me too, using php71-gd and php71-apache. Thank you!
Comment by Michael Gulick (mgulick) - Wednesday, 10 January 2018, 02:58 GMT
This did not work for me. Nextcloud will no longer start after installing php71 packages.

From /var/log/httpd/error_log:
[Tue Jan 09 21:55:53.268360 2018] [php7:error] [pid 1068] [client] PHP Fatal error: Uncaught Doctrine\\DBAL\\DBALException: Failed to connect to the database: An exception occured in driver: could not find driver in /usr/share/webapps/nextcloud/lib/private/DB/Connection.php:61\nStack trace:\n#0 /usr/share/webapps/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\\DB\\Connection->connect()\n#1 /usr/share/webapps/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\\DBAL\\Connection->getDatabasePlatformVersion()\n#2 /usr/share/webapps/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\\DBAL\\Connection->detectDatabasePlatform()\n#3 /usr/share/webapps/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\\DBAL\\Connection->getDatabasePlatform()\n#4 /usr/share/webapps/nextcloud/lib/private/DB/Connection.php(148): Doctrine\\DBAL\\Connection->setTransactionIsolation(2)\n#5 /usr/share/webapps/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\\DB\\Connection->__construct(Array, Object in /usr/share/webapps/nextcloud/lib/private/DB/Connection.php on line 61

I'm using mysql (mariadb) as the nextcloud database. php71 or nextcloud issue?

My bad, I missed this line in the pacman output:
warning: /etc/php/php.ini saved as /etc/php/php.ini.pacsave
moving php.ini.pacsave back to php.ini fixed the problem.