You are not logged in.
Last week I upgraded my system and php was upgraded to version 7.4 (from 7.3).
Not only my Nexcloud installation doesn't work now (current version of Nextcloud is incompatible with php > 7.3), also php 7.4 can't open the 'gd' dynamic library (php-gd version is 7.3.11).
I have tried installing the most recent versions of php, php-gd and php-fpm from testing, and editing Nextcloud's php version check, but it still doesn't work.
My question is: being php <= 7.3 a dependency of nextcloud, and being both packages in archlinux32's repositories, is it normal that this dependency is broken?
Related to this, is it normal that the current versions of php and of some of its libraries in the repostories are not the same?
I have tried many things and I have been unable to fix this problem, mainly because I made a mistake and cleaned pacman's cache prematurely, and now I cannot downgrade php to 7.3.
Offline
You can always get old releases from the archive.
If php can no longer use the supplied pgp-gd library then that seems like a bug to me. You should be able to raise a bug for that.
Last edited by levi (2019-12-18 23:36:22)
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
levi, I'm really, really grateful for your help. I have just downgraded the packages and this fixed my problem. I had searched the package database for old versions, but I didn't remember the archive (I feel so silly now...).
Regarding the php-gd error, I'm not sure if it's a bug or a problem related with Nextcloud.
Just out of curiosity, am I right to think that php should not be upgraded in the repositories if it breaks some other package?
Thank you again for your quick and wise reply. You're awesome!
Offline
Assuming it follows the same policy that's supposed to apply to python and perl, then yes, all dependent packages should be updated in the stable branch at the same time at the very least, although we've recently had some problems with python libraries, so I would not be surprised if php dependencies aren't well tracked yet either.
Unfortunately I don't know php well enough to help with testing libraries. Python's easy, just start the interpreter and try to import the lib, but I don't know if php even has an interactive interpreter; I've only ever come across it in the back end of certain web servers.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Yeah, sorry about the late answer, peeking at a list of php module, most of them are still 7.3.11. Most modules are
built from one PKGBUILD (php), so I assume the buildmaster moved the main package only and no subpackages. Seen
this before with systemd and others. I force move all modules from the main php package by hand.
Offline
@levi: php is also an interpreter, so testing with a script (let's say we want to test whether XSLT processing is working):
shell> cat > test.php <<EOF
<?php
$xsl = new XSLTProcessor();
?>
EOF
shell> php test.php
Without 'php-xsl' installed we get:
PHP Warning: PHP Startup: Unable to load dynamic library 'xsl' (tried: /usr/lib/php/modules/xsl (/usr/lib/php/modules/xsl: cannot open shared object file: No such file or directory), /usr/lib/php/modules/xsl.so (/usr/lib/php/modules/xsl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Fatal error: Uncaught Error: Class 'XSLTProcessor' not found in /root/test.php:4
Stack trace:
#0 {main}
thrown in /root/test.php on line 4
Installing 'php-xsl' and enabling it in '/etc/php/php.ini':
extension=xsl
now with 'php-xsl' installed we can execute 'test.php' without getting an error.
Offline