Arch Linux

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.

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.

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.

I've added php<7.2 to nextcloud 12.0.4

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/libphp7.so into server: libicui18n.so.59: 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.

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".

@Natanji You can downgrade icu and its deps.
Or check /var/log/pacman.log for last update and downgrade all mentioned packages.

@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.

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.

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?

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...

@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.

FYI, I also had to make the following downgrade for nextcloud to work again: php-apcu (5.1.8-2 => 5.1.8-1)

FYI: There's another upstream bug report I opened [1], that now got some traction, but has already been closed again.

[1] https://github.com/nextcloud/server/issues/7384

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.

Well, I get the impression from the fact that that wasn't initially done, that it would be non-trivial to do so.

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.

@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.

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?

> 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.

This is broken for more than 3 weeks now, is it time to just package the beta yet?

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 (https://github.com/nextcloud/tasks/issues/136).

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 (https://aur.archlinux.org/packages/nextcloud-git/), 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!

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.

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.

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.

This is getting ridiculous: https://github.com/nextcloud/server/issues/7384#issuecomment-356310446

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.

I've put php71*packages to community-testing, could you please check if it works?

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:

provides=("${pkgname/71/}=${pkgver}")

I updated php71, drupal, nextcloud in community-testing

php71 from community-testing works for me! (using php71 php71-apache php71-gd php71-intl php71-mcrypt php71-sqlite)

I can confirm that this works for me too, using php71-gd and php71-apache. Thank you!

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 192.168.1.1:54034] 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?

*edit:
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.