Re: [arch-dev-public] Upcoming PHP 8.1 update
I have finished the rebuild of modules und pushed all packages into [testing]: . https://archlinux.org/todo/draft-php-81-module-rebuild/ Unfortunately there are two packages that had build issues: * libguestfs: No idea why it has a PHP module anyway. But this package does not compile with [extra] packages as well, so it is likely unrelated to PHP and probably cuased by an ocaml update. I used the repos archive from last month to build this package for now. * php-snuffleupagus: Does not pass tests with PHP 8.1 and there seems to be no upstream patches we could apply. (pkgstats usage is only 0.03%) I have disabled the failing tests for now. Next is to check if there remain any incompatibilities aside from modules; e.g. the nextcloud version constrain we talked about. I might create a todo list as well. Removing php7 and everything that depends on it will be done in a separate step once php 8.1 has moved into [extra]. Greetings, Pierre On Sun, Jan 2, 2022 at 2:00 PM Pierre Schmitz wrote: > > So, its been some time and things seem to look a lot better now. I see > the nextcloud patch was merged some time ago as well. We might need to > aplly it manually as I don't see a patch release for some reason. Most > things work fine with PHP 8.1. So far the issues are mostly arbitrary > versions constraints or actual bugs that would be broken on 8.0 as > well. (e.g. conflicting type hints in sub classes) > > My plan is to prepare updating the php package to 8.1 and create a > rebuild list. At the same time I'll remove the php7 package. It's been > a year now and I would consider anything that only works on php7 as > unmaintained. Here is a list of php7-packages that would be affected: > * mediawiki: works fine with PHP 8 > * drupal: should work on PHP 8 according to upstream > * zabbix-frontend-php: unclear; I read that it might have been fixed > in version 5.4 > * phpvirtualbox: probably broken; latest release was in 2018. This > should be remvoed fro mthe repos imho > * web-news: brobably broken; latest release was in 2009. Also should be > removed. > * phppgadmin: probably broken; development seem slow or stalled on PHP > 8 support. We might need to drop this as well > * phpldapadmin: might work. New version was just released and claims > to support anything newer than PHP 7.2 > * dokuwiki: unclear; might need patches > > Greetings, > > Pierre > > On Mon, Dec 6, 2021 at 6:53 PM David Runge wrote: > > > > On 2021-12-06 18:32:49 (+0100), Pierre Schmitz via arch-dev-public wrote: > > > In general we could provide PHP 7 till its end of life in about eleven > > > months. But I don't think its worth providing several different minor > > > versions at the same time. > > > > I agree. > > > > > This is not how semver is supposed to work :-) (Someone should check > > > Nextcloud but looking at their PR it mostly seems about tests, > > > documentation and deprecations but no hard errors). > > > > I would definitely wait until the PR for nextcloud [1] has settled (it's > > still a draft). > > The changes apply to 23.0.0 (which has been in testing only for a few > > hours). > > Do note, that effects of php 8.1.0 on the nextcloud-apps is completely > > unaccounted for in this scenario. > > > > I would like to have nextcloud 23.0.0 in [community] before we proceed > > with any testing with php 8.1.0 if that is fine with you. > > > > Best, > > David > > > > [1] https://github.com/nextcloud/server/pull/29862/commits > > > > -- > > https://sleepmap.de > > > > -- > Pierre Schmitz, https://pierre-schmitz.com -- Pierre Schmitz, https://pierre-schmitz.com
[arch-dev-public] Elastic stack packages have been replaced by OpenSearch
Due to the licence change of Elasticsearch and Kibana from Apache 2.0 to SSPL [0] both packages have been stuck on the last Apache 2.0 version for a while. For this reason both have now been moved to the AUR and are replaced by OpenSearch and OpenSearch Dashboards in community [1]. Please refer to the official migration guide [2] and consider providing any insights on the ArchWiki page [3]. While the beats agents [4] are still on Apache 2.0 newer versions suffer compatibility issues [5] with ElasticSearch OSS and OpenSearch. Thus those have been moved to the AUR as well. Please note that the AUR packages are now orphans, feel free to adopt them. [0] https://www.elastic.co/pricing/faq/licensing [1] https://archlinux.org/packages/?sort=&q=opensearch [2] https://opensearch.org/docs/latest/upgrade-to/upgrade-to/ [3] https://wiki.archlinux.org/title/OpenSearch#Upgrading_from_Elasticsearch_OSS [4] https://github.com/elastic/beats [5] https://wiki.archlinux.org/title/OpenSearch#Compatibility_with_Beats_OSS -- hashworks Webhttps://hashworks.net Public Key 0x4FE7F4FEAC8EBE67 pgp4OztGWCNGB.pgp Description: OpenPGP digital signature
Re: [arch-dev-public] openssl 3.0
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