Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

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!
Tasklist

FS#73452 - [nextcloud] Nextcloud 23 is not compatible with PHP 8.1

Attached to Project: Community Packages
Opened by Markus (wolegis) - Friday, 21 January 2022, 20:52 GMT
Last edited by David Runge (dvzrv) - Friday, 09 September 2022, 09:43 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:


Nextcloud 23 is not compatible with PHP 8.1. See https://github.com/nextcloud/server/issues/29287

The dependency information in the nextcloud package should reflect this.

I know this effectively makes Nextcloud on Arch Linux non-installable and non-upgradable. But I think this would be better than the current situation breaking existing installations.
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 09 September 2022, 09:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with nextcloud >= 24.0.0
Comment by Chih-Hsuan Yen (yan12125) - Saturday, 22 January 2022, 06:33 GMT
With PHP 8.1, many operations, including nextcloud-cron.timer and requests to CalDAV resources, report the following error (warning?):

Return type of OC\Memcache\Cache::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice at /usr/share/webapps/nextcloud/lib/private/Memcache/Cache.php#93

This upstream commit seems related: https://github.com/nextcloud/server/commit/113756db30fcbffe9e90b54c29e78dee0676109f#diff-f8033a478e65baa105f6455ef20b0ef14e2bcbcc002ed5ea7602a6f3da331116
Comment by David Runge (dvzrv) - Saturday, 22 January 2022, 09:33 GMT
@wolegis: Thanks for the report.

The package with a patch for php 8.1 has been in [community-testing] for nearly a week [1] and the update to php 8.1 has been discussed on the arch-dev-public mailing list [2] for longer than that.
To mitigate problems such as this, please consider to help testing [3] in the future.

@yan12125: Thanks for the pointer. I'll try to backport this patch into the existing one!

[1] https://github.com/archlinux/svntogit-community/commit/c78893ca625b81a48d3201ac31dff70b2477133f#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a
[2] https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030570.html
[3] https://wiki.archlinux.org/title/Arch_Testing_Team
Comment by David Runge (dvzrv) - Saturday, 22 January 2022, 09:57 GMT
Please check whether nextcloud 23.0.0-3 in [community] fixes your problems.
Comment by Chih-Hsuan Yen (yan12125) - Saturday, 22 January 2022, 11:49 GMT
Thanks! Here comes the next error:

Return type of Pimple\Container::offsetUnset($id) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice at /usr/share/webapps/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php#143

Those pull requests seem related:
https://github.com/nextcloud/server/pull/29953
https://github.com/nextcloud/3rdparty/pull/905
https://github.com/silexphp/Pimple/pull/266

Also, pimple is mentioned at https://github.com/nextcloud/server/issues/29287#issuecomment-946632591. Maybe those dependencies should also be updated besides backporting patches from https://github.com/nextcloud/server/issues/29287 (Support PHP 8.1 - First batch) and https://github.com/nextcloud/server/pull/29862 (Support PHP 8.1 - Second batch).
Comment by David Runge (dvzrv) - Saturday, 22 January 2022, 12:45 GMT
The problem with upgrading a 3rdparty submodule is that that is not how we are building the package (it's built from a premade source tarball, so patches have to be backported unfortunately).

Both merge requests for php 8.1 support [1][2] are contained in the backported patch already.

However, the changes introduced by the pimple 3.5.0 upgrade [3] seem trivial enough to also backport into the existing patch.

[1] https://github.com/nextcloud/server/pull/29432
[2] https://github.com/nextcloud/server/pull/29862
[3] https://github.com/nextcloud/3rdparty/pull/905/files
Comment by David Runge (dvzrv) - Saturday, 22 January 2022, 13:05 GMT
Please check whether 23.0.0-4 in [community] fixes the problems (and/or introduces new ones).
Comment by Pierre Schmitz (Pierre) - Saturday, 22 January 2022, 13:28 GMT
Did anybody try to suppress deprecation warnings and notices? At least according to the PHP changelog those warnings are not fatal. E.g. change "error_reporting = E_ALL & ~E_DEPRECATED" in you php.ini, or simply set it to E_ERROR. (I was able to install and run nextcloud this way; so we might not need patches if warnings are ignored)
Comment by David Runge (dvzrv) - Saturday, 22 January 2022, 15:24 GMT
@Pierre: I'm not convinced suppressing the warnings is the way forward here, as they indicate other underlying issues that may lead to all sorts of problems if simply ignored. I do not think that is a fix we should endorse at all.

Additionally, if untreated, these warnings spam the application's log and make it really hard to figure out what's going on or lead to huge log files.
Comment by Pierre Schmitz (Pierre) - Saturday, 22 January 2022, 19:50 GMT
You are correct, this workaround is far from great. On the other hand I am not sure if the upstream patches are any better; adding "ReturnTypeWillChange" is more or less ignoring errors :-)

If you actually disable deprecation notices they wont be logged. It might be possible that Nextclouds re-enables those warnings and logs them anyway.
Comment by Chih-Hsuan Yen (yan12125) - Sunday, 23 January 2022, 05:42 GMT
Thanks David! 23.0.0-4 works fine and I didn't got a warning/error after hours of normal usage.

> adding "ReturnTypeWillChange" is more or less ignoring errors :-)

Yeah that seems so. At least that keyword only ignores warnings/errors from specific functions instead of globally.
Comment by slip (slip) - Monday, 24 January 2022, 05:49 GMT
using uwsgi, I'm getting fatal errors -

`Jan 23 21:24:53 server uwsgi[81310]: [pid: 81310|app: -1|req: -1/1] 10.0.0.10 () {56 vars in 1015 bytes} [Sun Jan 23 21:24:53 2022] GET / => generated 0 bytes in 1 msecs (HTTP/2.0 500) 2 headers in 103 bytes (0 switches on core 0)
Jan 23 21:24:53 server uwsgi[81310]: PHP Fatal error: Failed opening required 'loud/index.php' (include_path='.:') in Unknown on line 0
Jan 23 21:24:53 server uwsgi[81310]: PHP Warning: Unknown: Failed to open stream: No such file or directory in Unknown on line 0`

I don't know if `PHP Fatal error: Failed opening required 'loud/index.php'` is just being truncated or if it's actually attempting open only `loud/index.html` instead of `nextcloud/index.php`.

I do see a bug report issued for uwsgi having issues with php8.1 as well. Could just ask likely be related to that more than this, but historically, I've really had to babysit nextcloud so I'm starting here.
Comment by David Runge (dvzrv) - Monday, 24 January 2022, 10:14 GMT
@slip I believe this to be  FS#73470  (which is due to an incompatibility of uwsgi-plugin-php with php 8.1).
Comment by slip (slip) - Monday, 24 January 2022, 16:54 GMT
You're right. For what it's worth, Nextcloud is working. I received an email from it today about it not being reachable. So it's working, I just can't access it. Thanks.
Comment by David Runge (dvzrv) - Tuesday, 01 February 2022, 09:15 GMT
I think I have just fixed uwsgi-plugin-php with 2.0.20-5. Please test and verify, then I may also close this ticket :)
Comment by Markus (wolegis) - Wednesday, 02 February 2022, 08:52 GMT
Just updated my system and can confirm Nextcloud (in conjunction withg PHP 8.1) is now working again with uWSGI and uWSGI's PHP plugin. Kudos to David.

Nevertheless with respect to https://github.com/unbit/uwsgi/issues/2287 I'm concidering to switch to php-fpm.
Comment by Branimir Amidzic (ambra) - Friday, 04 February 2022, 07:49 GMT
Please check whether these patches broke UTF-8 compatibility.
It definitely broke my installation.

I use TbSync and DAV-4-TbSync to sync calendar, tasks and contacts between Thunderbird and my Nextcloud installation (Nextcloud 23.0.0-4, MariaDB 10.6.5-2, PHP 8.1.2-1). If I create a contact with name "šđčćž" (quite common letters in Slavic languages), it gets saved as "šđčćž". As this happens, the same contact in Thunderbird changes to "šđčćž".

This happens not only with contacts, but with files which I sync from my Android phone.

I also noticed that if I create a file named "šđčćž" in Nextcloud folder on my desktop which syncs with the server, I can not delete this file from the Web interface. When I choose "delete file" it appears to be deleted, but as soon as I refresh the page it there again. Even if I manually delete the file on my server (at /var/nextcloud/<username>/files/ directory) it's still visible in Web interface. Only after I remove it from "oc_filecache" table, it's no more visible in Web interface.

I have tested the same Nextcloud version as Docker image and it works fine. No such issue (although I tested it with default SQLite database).

Regards!

System data:
https://nextcloud.ambraspace.com/index.php/s/TeS7sZiNK6w2MTE
Password: FwNYoX5HPH
Comment by David Runge (dvzrv) - Friday, 04 February 2022, 10:23 GMT
@ambra This might be related to your database setup though. Please make sure that your database uses the correct character set and collation (see https://wiki.archlinux.org/title/Nextcloud#MariaDB ).
Comment by Branimir Amidzic (ambra) - Friday, 04 February 2022, 18:20 GMT
Hi, David!
I'm using the same database since Nextcloud version 19 or even earlier, and I've never had such issue.

All tables use CHARSET=utf8mb4 COLLATE=utf8mb4_bin.
You can check that at the link I provided in my previous comment.
Comment by Branimir Amidzic (ambra) - Friday, 04 February 2022, 18:53 GMT
After going through the patches I didn't see anything that might cause the problem.
Might be upstream problem.
I saw this in the PHP changelog (8.0 -> 8.1)

htmlspecialchars(), htmlentities(), htmlspecialchars_decode(), html_entity_decode(), and get_html_translation_table() now use ENT_QUOTES | ENT_SUBSTITUTE rather than ENT_COMPAT by default. This means that ' is escaped to &#039; while previously nothing was done. Additionally, malformed UTF-8 will be replaced by a Unicode substitution character, instead of resulting in an empty string.

I will check this.
Comment by Branimir Amidzic (ambra) - Friday, 04 February 2022, 19:12 GMT
Yes, I reverted to PHP 8, and the problem is gone...
Comment by David Runge (dvzrv) - Friday, 04 February 2022, 21:24 GMT
@ambra: Thanks for verifying it! Just wanted to make sure.

Thanks for mentioning that upstream as well. Let's hope they are able to find a fix for that soon.
Comment by Chih-Hsuan Yen (yan12125) - Thursday, 03 March 2022, 11:44 GMT
A somehow bad news - Nextcloud 24, the upcoming version expected to officially support PHP 8.1, is delayed

https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule

Loading...