Re: [arch-dev-public] openssl 3.0
Hi all, I have prepared a openssl-3.0 and 1.1 packages with the bootstrapped dependencies. In addition to this there is a hopefully complete todo list: https://archlinux.org/todo/openssl-30/ containing about 500 packages. Next steps: 1) Let's agree on a time window where no other rebuild can take place within our staging repos. How about at least the first two weeks in February? 2) I guess we have to at least build the core and toolchain packages manually. (*) Hopefully we may automate everything else. If you like to take a look: [openssl] Server = https://repo.pierre-schmitz.com/$repo/os/$arch Important: Only use this to check building packages within a chroot. Installing this on a system will break it. *) libarchive already fails \o/; but hopefully this unit test can be ignored: https://github.com/libarchive/libarchive/issues/1596 On Sat, Jan 8, 2022 at 10:24 PM Pierre Schmitz wrote: > > a follow up: > > * Retiring OpenSSL 1.0 will take place here: > https://archlinux.org/todo/openssl-10-retirement/ This wont affect the > 1.1 -> 3.0 transition though. > * I have placed an openssl-1.1 package into [staging] that should make > it easier to migrate as it provides the 1.1 version of libcrypto.so > and libssl.so > * The idea was to have openssl-3.0 depend on that at first to make the > transition more seamless. I still need to solve the bootstrap issue > though. > > As this is going to be a massive rebuild we should plan a time frame > when to do this and avoid any other rebuilds. ATM there are more than > 700 packages in our staging repos. > > - Pierre > > On Mon, Dec 6, 2021 at 6:41 PM Pierre Schmitz wrote: > > > > just a small update: This is going to be a little more complicated and > > I suggest we tackle this at the beginning of next year. I got some > > very helpful feedback from our community (Thanks a lot loqs). > > * We might be able to drop version 1.0 (which is no longer maintained > > by upstream anyway). packages that only work with 1.0 should be > > dropped imho. > > * We are going to need to provide 1.1 for a couple of packages > > (hopefully not for long) > > * We are going to have to solve the bootstrap issue with pacman. I > > guess by either linking it statically, make it depend on the 1.1 > > package at first > > > > Greetings, > > > > Pierre > > > > On Sat, Nov 6, 2021 at 10:32 AM Pierre Schmitz wrote: > > > > > > Hi Jelle, (also forwarding to dev-public) > > > > > > definitely yes, OpenSSL 3.0 is on my wish list! :-) > > > > > > I did not want to jump on it at day one though. Even the last minor > > > updates were quite painful and we still have packages requiring > > > version 1.0 and are still not compatible with 1.1. > > > > > > While they claim that most packages should work with a recompile, it > > > would be nice to actually know which packages are not compatible. This > > > should help whether we need another compatibility package are would be > > > able to just replace openssl 1.1 with version 3. > > > > > > I know about foutrelis' awesome rebuilder script, but I wonder if we > > > have something similar that I just could run for half a day to get an > > > idea which package would break and which wont? Like a dry run that > > > wont commit anything. If no such thing exists yet, I might have a look > > > myself. > > > > > > Greetings, > > > > > > Pierre > > > > > > On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa wrote: > > > > > > > > Hi Pierre, > > > > > > > > Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens > > > > to have already started. > > > > > > > > https://fedoraproject.org/wiki/Changes/OpenSSL3.0 > > > > > > > > Greetings, > > > > > > > > Jelle > > > > > > > > > > > > -- > > > Pierre Schmitz, https://pierre-schmitz.com > > > > > > > > -- > > Pierre Schmitz, https://pierre-schmitz.com > > > > -- > Pierre Schmitz, https://pierre-schmitz.com -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
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 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
Re: [arch-dev-public] Upcoming PHP 8.1 update
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 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 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
