Re: [arch-dev-public] Upcoming PHP 8.1 update

2022-01-08 Thread Pierre Schmitz via arch-dev-public
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

2022-01-08 Thread Justin Kromlinger via arch-dev-public
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

2022-01-08 Thread Pierre Schmitz via arch-dev-public
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