Hi Kristian, I would not recommend to deploy PHP 7 after its end of life in November this year. In theory someone might be able to backport security fixes though.
In this case I would urge to update Flyspray to its latest version which has support for PHP 8.0: https://github.com/Flyspray/flyspray/releases We seem to use version 0.9.9.7 which we updated 9 years ago. From there on its probably easier to make to work with recent PHP versions. Greetings, Pierre On Sun, Jan 23, 2022 at 3:15 PM Kristian Klausen <krist...@klausen.dk> wrote: > > On Sat, Jan 22, 2022 at 20:45:45 +0100, Pierre Schmitz via arch-dev-public > wrote: > > Hi David, > > > > sorry about the hassle. I did not expect much issues here. I would > > consider this one of the smoother PHP updates. Unless people ignored > > warnings by previous PHP versions. I guess that is what mostly happend > > here. PHP 8 gets more and more strict each version. > > > > After reading the issues on Nextcloud's Github repository I guess we > > can conclude that they will probably lack behind at least one PHP > > minor version. This is quite incompatible with the Arch way. > > > > Anyway, let's talk about some options to solve such issues: > > > > 1) Let's no longer package software that requires older versions of > > PHP. Personally I would run such complex software with very specific > > needs in a Docker container. E.g. Nextcloud even provides an official > > one. > > FYI: > As stated earlier by Jelle[1], our bugtracker isn't currently compatible > with PHP8. In case PHP7 is dropped from the repos and no one steps up > fixing the flyspray code[1]. The DevOps team will likely just run the > the bugtracker in a container of some sort. > > [1] > https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030571.html > [2] https://gitlab.archlinux.org/archlinux/flyspray/ > > - Kristian > > > 2) Keep trying to patch upstream packages to keep them working. > > 3) We provide two sets of PHP packages: "php" would always be the > > latest stable version and be released no matter what. In addition to > > this there would be e.g. "php-legacy" packages providing the oldest > > supported version, currently 7.4. This would be updated to 8.0 in > > November when 7 is EOL and php-8.2 get's released. The difference to > > the currently available php7 package will be the lack of a version > > number in package and binary names. So both packages will be a moving > > target, but always two versions apart. > > > > I would give option 3 a try. I'd like to get rid of versioned > > constraints then and reduce the amount of third party modules. While > > we would end up with more packages we need less testing and will be > > able to move faster. > > > > *) https://www.php.net/supported-versions.php > > > > On Sat, Jan 22, 2022 at 10:57 AM David Runge <d...@sleepmap.de> wrote: > > > > > > On 2022-01-21 17:51:17 (+0100), Pierre Schmitz via arch-dev-public wrote: > > > > I just released PHP 8.1 into [extra]. > > > > > > > > Please also check https://archlinux.org/todo/php-7-retiredment/ so PHP > > > > 7 can be dropped soon. > > > > > > > > have a nice weekend, > > > > > > Unfortunately, it likely won't be ;_; > > > > > > https://bugs.archlinux.org/task/73452 > > > > > > Another reminder for users to *please* join the Testing Team [1] and > > > help test our packages! > > > > > > Best, > > > David > > > > > > [1] https://wiki.archlinux.org/title/Arch_Testing_Team > > > > > > -- > > > https://sleepmap.de > > > > > > > > -- > > Pierre Schmitz, https://pierre-schmitz.com -- Pierre Schmitz, https://pierre-schmitz.com
