Re: [arch-dev-public] State of PHP 8 update
Just another headshup: I'll push php7 and php-8 package to staging today. I'll create a rebuild list for all modules. Once this is done I would move them to [testing] and we can check the scripts we provide for PHP 8 compatibility and update their dependency for PHP 7 if needed. Greetings, Pierre On Mon, Dec 14, 2020 at 5:31 PM Pierre Schmitz wrote: > > Hi all, > > as people start asking me when to expect PHP 8 packages in our repos, > here is a quick update: > * For those who seek adventure, I'll already have version 8 in my > unofficial repo > * A lot of the libraries I tested do not work with PHP 8 yet. E.g. > Doctrine, Elastic-Search, ... > * Software that was written for PHP 5 and was never properly ported to > 7 will not work; e.g. FluxBB we use for our Forums > * Updating software to work with PHP 8 is quite easy though and I > expect way less issues than the back in the days when we transitioned > from 5 to 7 > * A lot of developers use Arch, therefor I would like to provide PHP 8 > as soon as possible which in turn should speed up the migration or > everybody > * I will check if we could provide php7 packages alongside version 8 > so people can start developing for 9 but still are able to run some > apps with 7. PHP 7 will be supported by upstream for almost 2 years: > https://www.php.net/supported-versions.php > > I'll keep you updated. > > Greetings, > > Pierre > > -- > Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] State of PHP 8 update
The module rebuild todo list is now available at https://archlinux.org/todo/php-8-and-php7-module-rebuild/ On Fri, Jan 8, 2021 at 5:11 PM Pierre Schmitz wrote: > > Just another headshup: > > I'll push php7 and php-8 package to staging today. I'll create a > rebuild list for all modules. Once this is done I would move them to > [testing] and we can check the scripts we provide for PHP 8 > compatibility and update their dependency for PHP 7 if needed. > > Greetings, > > Pierre > > On Mon, Dec 14, 2020 at 5:31 PM Pierre Schmitz wrote: > > > > Hi all, > > > > as people start asking me when to expect PHP 8 packages in our repos, > > here is a quick update: > > * For those who seek adventure, I'll already have version 8 in my > > unofficial repo > > * A lot of the libraries I tested do not work with PHP 8 yet. E.g. > > Doctrine, Elastic-Search, ... > > * Software that was written for PHP 5 and was never properly ported to > > 7 will not work; e.g. FluxBB we use for our Forums > > * Updating software to work with PHP 8 is quite easy though and I > > expect way less issues than the back in the days when we transitioned > > from 5 to 7 > > * A lot of developers use Arch, therefor I would like to provide PHP 8 > > as soon as possible which in turn should speed up the migration or > > everybody > > * I will check if we could provide php7 packages alongside version 8 > > so people can start developing for 9 but still are able to run some > > apps with 7. PHP 7 will be supported by upstream for almost 2 years: > > https://www.php.net/supported-versions.php > > > > I'll keep you updated. > > > > Greetings, > > > > Pierre > > > > -- > > Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] State of PHP 8 update
I will soon move the packages to [testing]. Thanks for everybody helping out. I'll then set up a todo list to check for compatibility with packages depending on PHP. Some notes: * I have built xdebug for PHP8; I'll let the maintainer decide if a php7 version might be of use * I will simply drop php-apcu-bc. It is a dead project (does no longer work with PHP 8) and was only of use for old PHP 5 projects * Does anybody know if php-mongodb is still intentionally in our repos since mongodb had been removed? * libguestfs does not build with PHP 8; but it does not build with PHP 7 neither. I assume this package has other problems. I'll just ignore this for now unless someone objects. PHP is only a makedepends here. If everything works out we might be able to move PHP 8 to [extra] by next weekend. Greetings, Pierre On Fri, Jan 8, 2021 at 5:48 PM Pierre Schmitz wrote: > > The module rebuild todo list is now available at > https://archlinux.org/todo/php-8-and-php7-module-rebuild/ > > On Fri, Jan 8, 2021 at 5:11 PM Pierre Schmitz wrote: > > > > Just another headshup: > > > > I'll push php7 and php-8 package to staging today. I'll create a > > rebuild list for all modules. Once this is done I would move them to > > [testing] and we can check the scripts we provide for PHP 8 > > compatibility and update their dependency for PHP 7 if needed. > > > > Greetings, > > > > Pierre > > > > On Mon, Dec 14, 2020 at 5:31 PM Pierre Schmitz wrote: > > > > > > Hi all, > > > > > > as people start asking me when to expect PHP 8 packages in our repos, > > > here is a quick update: > > > * For those who seek adventure, I'll already have version 8 in my > > > unofficial repo > > > * A lot of the libraries I tested do not work with PHP 8 yet. E.g. > > > Doctrine, Elastic-Search, ... > > > * Software that was written for PHP 5 and was never properly ported to > > > 7 will not work; e.g. FluxBB we use for our Forums > > > * Updating software to work with PHP 8 is quite easy though and I > > > expect way less issues than the back in the days when we transitioned > > > from 5 to 7 > > > * A lot of developers use Arch, therefor I would like to provide PHP 8 > > > as soon as possible which in turn should speed up the migration or > > > everybody > > > * I will check if we could provide php7 packages alongside version 8 > > > so people can start developing for 9 but still are able to run some > > > apps with 7. PHP 7 will be supported by upstream for almost 2 years: > > > https://www.php.net/supported-versions.php > > > > > > I'll keep you updated. > > > > > > Greetings, > > > > > > Pierre > > > > > > -- > > > Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] State of PHP 8 update
php7 is now in [extra] an php 8 and the rebuilt modules are available in [testing]. I have created a new todo list to check compatibility of packages that depend on PHP: https://archlinux.org/todo/php-8-compatibility/ Greetings, Pierre On Sat, Jan 16, 2021 at 3:05 PM Pierre Schmitz wrote: > > I will soon move the packages to [testing]. Thanks for everybody > helping out. I'll then set up a todo list to check for compatibility > with packages depending on PHP. > > Some notes: > * I have built xdebug for PHP8; I'll let the maintainer decide if a > php7 version might be of use > * I will simply drop php-apcu-bc. It is a dead project (does no longer > work with PHP 8) and was only of use for old PHP 5 projects > * Does anybody know if php-mongodb is still intentionally in our repos > since mongodb had been removed? > * libguestfs does not build with PHP 8; but it does not build with PHP > 7 neither. I assume this package has other problems. I'll just ignore > this for now unless someone objects. PHP is only a makedepends here. > > If everything works out we might be able to move PHP 8 to [extra] by > next weekend. > > Greetings, > > Pierre > > On Fri, Jan 8, 2021 at 5:48 PM Pierre Schmitz wrote: > > > > The module rebuild todo list is now available at > > https://archlinux.org/todo/php-8-and-php7-module-rebuild/ > > > > On Fri, Jan 8, 2021 at 5:11 PM Pierre Schmitz wrote: > > > > > > Just another headshup: > > > > > > I'll push php7 and php-8 package to staging today. I'll create a > > > rebuild list for all modules. Once this is done I would move them to > > > [testing] and we can check the scripts we provide for PHP 8 > > > compatibility and update their dependency for PHP 7 if needed. > > > > > > Greetings, > > > > > > Pierre > > > > > > On Mon, Dec 14, 2020 at 5:31 PM Pierre Schmitz > > > wrote: > > > > > > > > Hi all, > > > > > > > > as people start asking me when to expect PHP 8 packages in our repos, > > > > here is a quick update: > > > > * For those who seek adventure, I'll already have version 8 in my > > > > unofficial repo > > > > * A lot of the libraries I tested do not work with PHP 8 yet. E.g. > > > > Doctrine, Elastic-Search, ... > > > > * Software that was written for PHP 5 and was never properly ported to > > > > 7 will not work; e.g. FluxBB we use for our Forums > > > > * Updating software to work with PHP 8 is quite easy though and I > > > > expect way less issues than the back in the days when we transitioned > > > > from 5 to 7 > > > > * A lot of developers use Arch, therefor I would like to provide PHP 8 > > > > as soon as possible which in turn should speed up the migration or > > > > everybody > > > > * I will check if we could provide php7 packages alongside version 8 > > > > so people can start developing for 9 but still are able to run some > > > > apps with 7. PHP 7 will be supported by upstream for almost 2 years: > > > > https://www.php.net/supported-versions.php > > > > > > > > I'll keep you updated. > > > > > > > > Greetings, > > > > > > > > Pierre > > > > > > > > -- > > > > Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] State of PHP 8 update
To speed things up I'll go ahead and update the remaining packages to my best knowledge. I'll also send a news draft later. Greetings, Pierre On Mon, Jan 18, 2021 at 6:51 PM Pierre Schmitz wrote: > > php7 is now in [extra] an php 8 and the rebuilt modules are available > in [testing]. > > I have created a new todo list to check compatibility of packages that > depend on PHP: https://archlinux.org/todo/php-8-compatibility/ > > Greetings, > > Pierre > > On Sat, Jan 16, 2021 at 3:05 PM Pierre Schmitz wrote: > > > > I will soon move the packages to [testing]. Thanks for everybody > > helping out. I'll then set up a todo list to check for compatibility > > with packages depending on PHP. > > > > Some notes: > > * I have built xdebug for PHP8; I'll let the maintainer decide if a > > php7 version might be of use > > * I will simply drop php-apcu-bc. It is a dead project (does no longer > > work with PHP 8) and was only of use for old PHP 5 projects > > * Does anybody know if php-mongodb is still intentionally in our repos > > since mongodb had been removed? > > * libguestfs does not build with PHP 8; but it does not build with PHP > > 7 neither. I assume this package has other problems. I'll just ignore > > this for now unless someone objects. PHP is only a makedepends here. > > > > If everything works out we might be able to move PHP 8 to [extra] by > > next weekend. > > > > Greetings, > > > > Pierre > > > > On Fri, Jan 8, 2021 at 5:48 PM Pierre Schmitz wrote: > > > > > > The module rebuild todo list is now available at > > > https://archlinux.org/todo/php-8-and-php7-module-rebuild/ > > > > > > On Fri, Jan 8, 2021 at 5:11 PM Pierre Schmitz wrote: > > > > > > > > Just another headshup: > > > > > > > > I'll push php7 and php-8 package to staging today. I'll create a > > > > rebuild list for all modules. Once this is done I would move them to > > > > [testing] and we can check the scripts we provide for PHP 8 > > > > compatibility and update their dependency for PHP 7 if needed. > > > > > > > > Greetings, > > > > > > > > Pierre > > > > > > > > On Mon, Dec 14, 2020 at 5:31 PM Pierre Schmitz > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > as people start asking me when to expect PHP 8 packages in our repos, > > > > > here is a quick update: > > > > > * For those who seek adventure, I'll already have version 8 in my > > > > > unofficial repo > > > > > * A lot of the libraries I tested do not work with PHP 8 yet. E.g. > > > > > Doctrine, Elastic-Search, ... > > > > > * Software that was written for PHP 5 and was never properly ported to > > > > > 7 will not work; e.g. FluxBB we use for our Forums > > > > > * Updating software to work with PHP 8 is quite easy though and I > > > > > expect way less issues than the back in the days when we transitioned > > > > > from 5 to 7 > > > > > * A lot of developers use Arch, therefor I would like to provide PHP 8 > > > > > as soon as possible which in turn should speed up the migration or > > > > > everybody > > > > > * I will check if we could provide php7 packages alongside version 8 > > > > > so people can start developing for 9 but still are able to run some > > > > > apps with 7. PHP 7 will be supported by upstream for almost 2 years: > > > > > https://www.php.net/supported-versions.php > > > > > > > > > > I'll keep you updated. > > > > > > > > > > Greetings, > > > > > > > > > > Pierre > > > > > > > > > > -- > > > > > Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Goodbye
Thank you for you working on Arch for such a long time. Take care, Pierre On Thu, Jan 21, 2021 at 2:08 PM Bartłomiej Piotrowski via arch-dev-public wrote: > > Hi everyone, > > I'm stepping down as a developer. It's been mostly fantastic ride for > the last 10 years but it's clear to me now that for better or worse it's > far from the project I initially joined. > > Thank you and good luck with everything, > Bart
[arch-dev-public] News draft: PHP 8.0 is available
Hi all, I'd like to move the PHP 8 rebuild to [extra] soon. Here is a little news draft to mainly inform users about the new php7 package for legacy software: --- The php package has been updated to version 8.0(1). Please refer to the upstream migration guide(2). As some applications are not compatible with PHP 8 yet we provide a php7 package which can be installed alongside version 8. Packages that depend on PHP reflect this update and will require php7 if needed. You might need to update your configuration accordingly. PHP 7 binaries and configuration have the "7" postfix: * /usr/bin/php -> /usr/bin/php7 * /etc/php -> /etc/php7 * /usr/bin/php-fpm -> /usr/bin/php-fpm7 * /usr/lib/systemd/system/php-fpm.service -> /usr/lib/systemd/system/php-fpm7.service * /run/php-fpm -> /run/php-fpm7 Note that support for php7 will be limited and likely be dropped in about a year(3) depending on how soon the majority of applications will be compatible with version 8. --- 1) https://www.php.net/releases/8.0/en.php 2) https://www.php.net/manual/en/migration80.php 3) https://www.php.net/supported-versions.php Let me know if I should add or change anything. Greetings, Pierre
Re: [arch-dev-public] News draft: PHP 8.0 is available
Thanks for the ihint. I'll use "suffix" instead. (I did a brief research about the difference between postfix and suffix; I can't say I fully understand it :-)) 'll also add a note about the modules that are available for php7 as well as users might need to manually install them. I'll probably post this tomorrow or the day after. Greetings, Pierre On Mon, Jan 25, 2021 at 8:19 PM Chester Wisniewski wrote: > > I would recommend changing "postfix" to suffix. Postfix is a package, suffix > works better in English. > > Chester > > -----Original Message- > From: Pierre Schmitz via arch-dev-public > Reply-To: Public mailing list for Arch Linux development > > To: Public mailing list for Arch Linux development > > Cc: Pierre Schmitz > Subject: [arch-dev-public] News draft: PHP 8.0 is available > Date: Mon, 25 Jan 2021 19:04:51 +0100 > > Hi all, > > I'd like to move the PHP 8 rebuild to [extra] soon. Here is a little > news draft to mainly inform users about the new php7 package for > legacy software: > > --- > The php package has been updated to version 8.0(1). Please refer to > the upstream migration guide(2). As some applications are not > compatible with PHP 8 yet we provide a php7 package which can be > installed alongside version 8. Packages that depend on PHP reflect > this update and will require php7 if needed. You might need to update > your configuration accordingly. PHP 7 binaries and configuration have > the "7" postfix: > * /usr/bin/php -> /usr/bin/php7 > * /etc/php -> /etc/php7 > * /usr/bin/php-fpm -> /usr/bin/php-fpm7 > * /usr/lib/systemd/system/php-fpm.service -> > /usr/lib/systemd/system/php-fpm7.service > * /run/php-fpm -> /run/php-fpm7 > Note that support for php7 will be limited and likely be dropped in > about a year(3) depending on how soon the majority of applications > will be compatible with version 8. > --- > 1) https://www.php.net/releases/8.0/en.php > 2) https://www.php.net/manual/en/migration80.php > 3) https://www.php.net/supported-versions.php > > Let me know if I should add or change anything. > > Greetings, > > Pierre >
[arch-dev-public] Tracking different CPU architectures with pkgstats
Hi all, while reading Allan's RFC about increasing Arch's CPU requirements(*) I had the idea to start tracking the different x86_64 architecture level using pkgstats. I am sure whether to drop support for old CPUs is not a matter of "if" but "when"; similar as it was with i686. Therefore it should help to have a rough estimate about which CPUs our users have and how the numbers develop over time. While I am at it, I'd like to also support different ARM architectures provided by archlinuxarm.org (or maybe even i486/i686 by archlinux32.org). There is a small catch though and the reason I am asking for your opinion: While we will know how many users use which architecture, all package usage data will be aggregated regardless of architecture. This means for a given package we cannot tell how often it is used on a specific architecture compared to others. I do not think that this would matter for most packages though. Greetings, Pierre *) https://gitlab.archlinux.org/archlinux/rfcs/-/blob/c5ee0eb715a01c6cd10aa5a9d3460ea46149f9ee/rfcs/0002-march.rst
Re: [arch-dev-public] Tracking different CPU architectures with pkgstats
I just updated the server to also accept x86_64 feature levels, ARM and even i686. There is a new version of pkgstats (>= 3.1.0; currently in [testing]) which is able to detect feature levels. ARM support is pretty early, but x86_64 should be fine (using Intel's cpuid library). If you like to check what gets detected on your system run: $ pkgstats submit --dump-json | head system.architecture is your CPU and os.architecture should be the same as "uname -m" Let me know if this does work for you and especially if it does not. Using Qemu for testing is quite limited and I lack old, new and AMD CPUs. An API and UI to analyze these data will follow in the future. (I guess we need to wait a few weeks to see some valid results) Greetings, Pierre On Sun, Mar 7, 2021 at 2:40 PM Pierre Schmitz wrote: > > Hi all, > > while reading Allan's RFC about increasing Arch's CPU requirements(*) > I had the idea to start tracking the different x86_64 architecture > level using pkgstats. I am sure whether to drop support for old CPUs > is not a matter of "if" but "when"; similar as it was with i686. > Therefore it should help to have a rough estimate about which CPUs our > users have and how the numbers develop over time. > > While I am at it, I'd like to also support different ARM architectures > provided by archlinuxarm.org (or maybe even i486/i686 by > archlinux32.org). There is a small catch though and the reason I am > asking for your opinion: While we will know how many users use which > architecture, all package usage data will be aggregated regardless of > architecture. This means for a given package we cannot tell how often > it is used on a specific architecture compared to others. I do not > think that this would matter for most packages though. > > Greetings, > > Pierre > > *) > https://gitlab.archlinux.org/archlinux/rfcs/-/blob/c5ee0eb715a01c6cd10aa5a9d3460ea46149f9ee/rfcs/0002-march.rst
Re: [arch-dev-public] Tracking different CPU architectures with pkgstats
Hi, I saw your post; I just did not want to go off-topic right away. :-) At least as long as I am the only contributor I hesitate to give up on how the infrastructure is set up. It seems to be much more complex to do this on "official" servers. I like being able to switch things around outside of just deploying some scripts. E.g. I do automatic deployments, updates, change Web server or database configurations etc.. Greetings, Pierre On Mon, Mar 15, 2021 at 10:42 PM Sven-Hendrik Haase via arch-dev-public wrote: > > On Sun, 14 Mar 2021 at 15:17, Levente Polyak via arch-dev-public > wrote: > > > > On 3/14/21 3:07 PM, Pierre Schmitz via arch-dev-public wrote: > > > I just updated the server to also accept x86_64 feature levels, ARM > > > and even i686. There is a new version of pkgstats (>= 3.1.0; currently > > > in [testing]) which is able to detect feature levels. ARM support is > > > pretty early, but x86_64 should be fine (using Intel's cpuid library). > > > > > > If you like to check what gets detected on your system run: > > > $ pkgstats submit --dump-json | head > > > system.architecture is your CPU and os.architecture should be the same > > > as "uname -m" > > > > > > Let me know if this does work for you and especially if it does not. > > > Using Qemu for testing is quite limited and I lack old, new and AMD > > > CPUs. > > > > > > An API and UI to analyze these data will follow in the future. (I > > > guess we need to wait a few weeks to see some valid results) > > > > Hi Pierre, > > > > that sounds wonderful, thanks for the work, this will be nice data points :) > > > > Did you see my previous mail? It would be amazing if you can consider > > growing this side-project into something official in terms of being > > available on http://pkgstats.archlinux.org/ > > > > I think this is really a great idea and project that we should advocate > > in the official hosting namespace :) > > > > cheers and thanks, > > Levente > > > > I second this and we've tried to touch on this in the past. I think > "officializing" pkgstats would be neat. > > Cheers, > Sven
[arch-dev-public] community.files pacman database corrupt
Hi all, Since Aug 30 07:17:11 CEST the "community.files" database (repos.archlinux.org/community/os/x86_64/community.files) seems to be corrupted. The package "ipguard-1.04-6" has an empty "desc" file. The "files" file has content though. Also the regular "community.db" file does seem fine. I also do not see that package being updated or moved. I did not try to regenerate the file yet to not make it harder to find the issue. Greetings, Pierre
Re: [arch-dev-public] community.files pacman database corrupt
Thanks for looking into this. It's still weird but let's see if it will happen again. I hope it wasn't a memory issue and we can just blame Allan. ;-) Greetings, Pierre On Mon, Aug 30, 2021 at 3:05 PM Evangelos Foutras wrote: > > "Fixed" by repo-adding ipguard to community. I have kept a copy of the > broken files db if anyone wants it, but it seems that > "ipguard-1.04-6/desc" had 1230 NUL bytes instead of 1230 bytes of > package details. > > On Mon, 30 Aug 2021 at 13:58, Pierre Schmitz via arch-dev-public > wrote: > > > > Hi all, > > > > Since Aug 30 07:17:11 CEST the "community.files" database > > (repos.archlinux.org/community/os/x86_64/community.files) seems to be > > corrupted. The package "ipguard-1.04-6" has an empty "desc" file. The > > "files" file has content though. Also the regular "community.db" file > > does seem fine. I also do not see that package being updated or moved. > > > > I did not try to regenerate the file yet to not make it harder to find > > the issue. > > > > Greetings, > > > > Pierre -- Pierre Schmitz, https://pierre-schmitz.com
[arch-dev-public] Netboot of 2021.11.01 ISO image is broken
Hi all, I did have some trouble build the current ISO image. As archiso requires to be run as root I had to work around some issues with GPG. As those did no longer work I thought I manually sign the artifacts. This did work fine, but later on I noticed that when using Netboot (PXE), mkinicpio-archiso is no longer able to verify the FS due to lack of any public key for GPG to use. In the meantime I moved the arch folder from the release directory. Note: just using Netboot is broken; the regular ISO image is fine. The whole PXE boot setup is weird though. It starts with a openssl signature for which I am the only one to sign it. We then verify the airootfs using gpg for which we provide the public key (the part which is currently broken). Wouldn't it be enough to instead verify the integrity using the sha checksums we already have, if it was already contain in the ssl signed image? Before diving deeper into the issue in oder to solve it, I was wondering if it wouldn't be better to ditch the whole netboot setup. It is quite complex and hard to test. What do you think? I have to admit that I do not know of any use case where you could not use a regular ISO image and had to use PXE boot. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Netboot of 2021.11.01 ISO image is broken
On Mon, Nov 1, 2021 at 5:10 PM David Runge wrote: > ... use an ephemeral PGP key (which is fine, as > it is not relevant whether it is a specific PGP key, only that the > *correct* PGP key is used to validate the root image). Thanks for your insights. I think I now found the missing peaces. Using an ephemeral key made it much more easy. I created it as it is done in https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/.gitlab/ci/build_archiso.sh#L162 (not part of archiso itself, so I got confused) I re-uploaded the arch folder. Let's hope that should fix the issue. Still, doesn't this show we do not really need GPG to achieve verification? We currently use _verify_signature() in mkinicpio-archiso, but shouldn't _verify_checksum() be as secure without the hassle to involve GPG? Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] openssl 3.0
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
[arch-dev-public] Upcoming PHP 8.1 update
Hi all, a little heads up as it takes longer than expected. I'll start the PHP 8.1 update and the required rebuilds soon. I noticed some unexpected incompatibilities and I'd like to look into these first. I'll also evaluate if we could drop the php7 packages at the same time. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
Thanks for the feedback. I'll do some more research (and also check some of my own apps). So far it does not seem that bad and most things work when disabling deprecation warnings and ignore dependency on the exact minor version of PHP. MediaWiki works fine with PHP 8.0 (I haven't check 8.1 yet). I am also preparing an update to 1.37. I don't think the remaining issues regarding Elasticsearch affect us. Flyspray (our Bug-Tracker) seems to be compatible with PHP 8.0 (according to its composer.json). So there is a chance it will work with 8.1 as well. 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. 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). Greetings, Pierre On Mon, Dec 6, 2021 at 6:13 PM David Runge via arch-dev-public wrote: > > On 2021-12-06 17:58:57 (+0100), Levente Polyak via arch-dev-public wrote: > > On 12/6/21 17:48, David Runge via arch-dev-public wrote: > > > On 2021-12-06 16:11:45 (+0100), Pierre Schmitz via arch-dev-public wrote: > > > > Hi all, > > > > > > > > a little heads up as it takes longer than expected. I'll start the PHP > > > > 8.1 update and the required rebuilds soon. I noticed some unexpected > > > > incompatibilities and I'd like to look into these first. I'll also > > > > evaluate if we could drop the php7 packages at the same time. > > > > > > Hi Pierre, > > > > > > nextcloud does not yet support php > 8.0. > > > The upcoming version 23.0.0 (currently in [community-testing]) neither > > > unfortunately [1]. > > > > > > However, the package itself guards against upgrading to php 8.1, so it > > > should be fine for current installations, but it will make installing > > > nextcloud not possible for new systems. > > > > > > That guard is just a stop gap from breaking the application after an > > upgrade. That does not really help current installations either as it cuts > > off the system from potentially important security updates. > > I agree. I was referring to right out breaking functionality on a > running system due to the php upgrade. > > > We really need to keep the dependency resolution intact which means if we > > are stuck for nextcloud the only viable options were either postpone php or > > provide a maintained set of php 8.0 that nextcloud can depend on. > > We indeed need to make an effort in regards to these situations. > It has happened before that nextcloud was not yet ready for a minor > version upgrade of php and the upgrade broke functionality for users. > That's why we have made the effort to signal the upper boundaries for > the applications as clearly as possible (to not be in this situation > anymore). > > My suggestion would be to wait for a little bit more to figure out > whether there will be patch level releases for php 8.0.x or whether we > should introduce another intermediary package (I'm not a fan of the > latter). > > Best, > David > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] openssl 3.0
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
Re: [arch-dev-public] community.files pacman database corrupt
Hi all,
seems to have happened again: the desc file of lxqt-runner had 0
bytes. I re-added the package. I got the following output. I did not
get the "...was not locked" message when trying again. Maybe our
locking does not work as expected:
==> ERROR: Repo [community] (x86_64) is already locked by
repo-{add,remove} process 2150481
==> WARNING: Repo [community-debug] (x86_64) is already locked by svenstaro.
-> Retrying in 10 seconds...
==> Adding lxqt-runner-1.0.0-1-x86_64.pkg.tar.zst to [community]...
==> WARNING: An entry for 'lxqt-runner-1.0.0-1' already existed
==> WARNING: Repo lock [community] (x86_64) was not locked!
Greetings,
Pierre
On Mon, Aug 30, 2021 at 11:56 PM David Runge wrote:
>
> On 2021-08-30 22:35:39 (+0200), Pierre Schmitz via arch-dev-public wrote:
> > Thanks for looking into this. It's still weird but let's see if it
> > will happen again. I hope it wasn't a memory issue and we can just
> > blame Allan. ;-)
>
> Unfortunately this has happened before.
>
> On 2021-04-06 I noticed the same with python-pytesseract's files db entry
> - a package which had not been touched since February - due to work on
> arch-repo-management (a pipeline started failing on validating the
> package database [1]).
>
> The package was bumped [2] and the corrupted files db entry was
> replaced.
>
> I have uploaded the community.files database with the corrupted entry
> [3] if anyone is interested.
>
>
> [1]
> https://gitlab.archlinux.org/archlinux/arch-repo-management/-/pipelines/6208
> [2]
> https://github.com/archlinux/svntogit-community/commit/0a9473072bc114cfbefe43c92acbf245dccdc980#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a
> [3] https://pkgbuild.com/~dvzrv/bugs/2021/04/community.files
>
> --
> https://sleepmap.de
--
Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] OpenSearch released to Community
Thanks a lot for your work! I already managed to migrate to OpenSearch without major issues. I am a little confused about the java dependency. It requires java-runtime instead of java-runtime-headless as Elasticsearch did. However on launch I get the following warning: "no-jdk distributions that do not bundle a JDK are deprecated and will be removed in a future release". About Elasticsearch packages: As I understand it, we are not allowed to distribute anything newer than version 7.10. This version is no longer supported by upstream, right? So we wont get any (security) updates. In that case we should rather remvoe these packages and ask people to migrate to OpenSearch. Greetings, Pierre On Fri, Dec 31, 2021 at 5:39 PM Justin Kromlinger via arch-dev-public wrote: > > Hello everyone, > > As mentioned in a previous mail [0] I've taken some time to bring the > ElasticSearch fork OpenSearch > to Community [1]. > > I've also added twelve plugin packages, a package for the Kibana fork > OpenSearch Dashboards and > eight plugin packages for that. Additionally I packaged the opensearch-cli Go > binary which > currently conflicts with the opensearch package. More plugins will follow, > but most of them can be > installed manually as well (f.e. ingest-attachment). > > I've tested both opensearch and opensearch-dashboards with my old node data, > but some plugins are > untested because I have no experience with them (primarily the security > plugin), so I would be > happy if someone could test them out. > > Please note that opensearch doesn't use the upstream-included JRE and > opensearch-dashboards doesn't > use the upstream-included NodeJS but the ones provided by our repositories. > Please keep that in > mind for any bug reports towards upstream. > > This brings up the elastic-question: What should we do with the elasticsearch > and kibana packages? > If we keep them, someone would need to adopt them - I will orphan them since > I won't be using > them anymore. Do we want to update them to their newest version with the new > Elastic license? Or > drop them to the AUR? > > If we update them to a newer version the beats packages versions are > complicated as well. The 7.X > versions already need additional configuration in opensearch and versions > >=7.13 won't work at all > [2]. I would recommend new packages for the beats-oss version 7.12.1 or even > 7.10.2 as recommended > by opensearch. > > Euch einen guten Rutsch ins neue Jahr or a Happy New Year, > hashworks > > [0] > https://lists.archlinux.org/pipermail/arch-dev-public/2021-August/030496.html > [1] https://archlinux.org/packages/?sort=&q=opensearch > [2] > https://opensearch.org/docs/latest/clients/agents-and-ingestion-tools/index/ > > -- > hashworks > > Webhttps://hashworks.net > Public Key 0x4FE7F4FEAC8EBE67 -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
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
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
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
Re: [arch-dev-public] Updates to archlinux-keyring and signatures for packager keys
Hi David, I am very sorry. I misjudged the urgency of this topic. I assumed signing the additional uid is more a "ncie to have", since pacman and wkd already works fine. I opened the ticket at https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/143 so we can create the merge requests once the new uid is fully trusted as well. I'll create new (more secure) key pairs once I have a more capable hardware key. I'll also phase out my master key once a robust web of trust has been established. Greetings, Pierre On Sat, Jan 15, 2022 at 1:37 AM David Runge via arch-dev-public wrote: > > Hi all, > > in the past days there have been a few releases of our archlinux-keyring > package, which contains the root trust of our distribution. > > We have successfully switched to using keyringctl [1] to manage the > keyring. From now on all changes to the keyring are done via merge > requests towards the archlinux-keyring repository, as it now serves as > the source of truth, whereas in the past we have been relying on the > dying SKS infrastructure or the Ubuntu keyserver (which may or may not > support all key types in use). > > I have contacted all of you over the past months and either requested > the addition of an @archlinux.org UID, the creation of a new PGP keypair > or the verification of your PGP key by means of a clearsigned token. > > To all that have added a new @archlinux.org UID or have created a new > key, please make sure that all signatures you have received from main > signing keys are also present in the current keyring (`pacman-key > --list-sigs @archlinux.org`) or in the current HEAD of > archlinux-keyring (`./keyringctl inspect ` in a clone of the > archlinux-keyring repository). If you have signatures that are not yet > in the keyring, you can add them yourself [2] and do not have to wait on > a main signing key holder to do it. > > To all that have created a new key, please make sure to setup the > correct PGP key ID in your archweb profile so that the website displays > the signatures correctly [3]. > If you have gained more than or equal to three main key signatures for > your new PGP key and the key as well as those signatures are already > available in the keyring in [core] please rebuild all of your packages > using your new key and start the process of having your old key removed > [4]. > For the purpose of mass package rebuilding you may create a TODO [5] and > use `rebuild-todo` (in the archlinux-contrib package) which makes use of > our build server infrastructure. > > > I have not yet gotten a response from or have not yet been able to > resolve my request with the following packagers (nickname in the > archlinux-keyring repository): > - bgyorgy > - archange > - arodseth > - kylekeen > - daurnimator > - pierre > - farseerfc > > Please make some time to create a new key/ UID/ or get signed, as Allan > would like to revoke his signing key in the near future (which may mean > the inability to sign packages and mass rebuild of packages in > question) as soon as the above packager signature situation has > stabilized. > > In case you have questions, feel free to reach out in #archlinux-staff > on libera.chat or via mail. > If you are interested in helping further develop keyringctl, have a look > at the relevant open tickets [6]. > > Best, > David > > [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/#usage > [2] > https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/Add-a-new-Signature > [3] https://archlinux.org/master-keys/#master-sigs > [4] > https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/Remove-a-packager-key > [5] https://archlinux.org/todo/add/ > [6] > https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues?scope=all&state=opened¬[label_name][]=new%20packager%20key¬[label_name][]=remove%20packager%20key¬[label_name][]=new%20main%20key¬[label_name][]=remove%20main%20key > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
So far everything looks fine. I am even using PHP 8.1 in production for a week now, without any issues. So I'd like to move the packages to [extra]. The remaining blocker is nextcloud though. What is the best option to resolve this? 1) Remove the version constraint 2) same as above + try to apply the upstream patch: https://github.com/nextcloud/server/pull/29862 3) temporary depend on php7; I'd like to remove that package soon though 4) anything else? Greetings, Pierre On Sat, Jan 8, 2022 at 11:09 AM Pierre Schmitz wrote: > > 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 -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
Thanks! Let me know if I may support you. Wrangling with PHP scripts is at least more fun than using gpg... On Sun, Jan 16, 2022 at 5:03 PM David Runge wrote: > > On 2022-01-16 16:40:00 (+0100), Pierre Schmitz via arch-dev-public wrote: > > So far everything looks fine. I am even using PHP 8.1 in production > > for a week now, without any issues. So I'd like to move the packages > > to [extra]. > > > > The remaining blocker is nextcloud though. What is the best option to > > resolve this? > > 1) Remove the version constraint > > 2) same as above + try to apply the upstream patch: > > https://github.com/nextcloud/server/pull/29862 > > I'll look into 1 or 2 asap. > Sorry, I have been pre-occupied with other packages/work. > > Best, > David > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
Thank you. I would not expect a lot of updates specific to PHP 8.1. Most apps should work fine. I also do not expect a lot of feedback from testing users. There should be a 8.1.2 release this week and I plan to move that one to extra. Greetings, Pierre On Sun, Jan 16, 2022 at 6:02 PM David Runge wrote: > > On 2022-01-16 17:11:44 (+0100), Pierre Schmitz via arch-dev-public wrote: > > Thanks! Let me know if I may support you. > > It went quite okay (but I had to remove parts of the patch series as > they apply to files that we do have in our tarball). > > nextcloud 23.0.0-2 is now in [community-testing]. > > As upstream hasn't released a new version yet and all apps that I > maintain have not yet had a release either, I guess it would be good to > wait at least a few more days :S > > > Wrangling with PHP scripts is at least more fun than using gpg... > > That might be true :D > I can fully recommend using sq though! :) > > Best, > David > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
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, Pierre On Mon, Jan 17, 2022 at 3:38 PM Pierre Schmitz wrote: > > Thank you. > > I would not expect a lot of updates specific to PHP 8.1. Most apps > should work fine. I also do not expect a lot of feedback from testing > users. > > There should be a 8.1.2 release this week and I plan to move that one to > extra. > > Greetings, > > Pierre > > On Sun, Jan 16, 2022 at 6:02 PM David Runge wrote: > > > > On 2022-01-16 17:11:44 (+0100), Pierre Schmitz via arch-dev-public wrote: > > > Thanks! Let me know if I may support you. > > > > It went quite okay (but I had to remove parts of the patch series as > > they apply to files that we do have in our tarball). > > > > nextcloud 23.0.0-2 is now in [community-testing]. > > > > As upstream hasn't released a new version yet and all apps that I > > maintain have not yet had a release either, I guess it would be good to > > wait at least a few more days :S > > > > > Wrangling with PHP scripts is at least more fun than using gpg... > > > > That might be true :D > > I can fully recommend using sq though! :) > > > > Best, > > David > > > > -- > > https://sleepmap.de > > > > -- > Pierre Schmitz, https://pierre-schmitz.com -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
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. 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
On Sat, Jan 22, 2022 at 9:45 PM David Runge wrote: > On 2022-01-22 20:45:45 (+0100), Pierre Schmitz via arch-dev-public wrote: > ... > > 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. > > This means giving up on system packaging and I do not agree with the > mentality of hiding away all legacy in a container. > That's neither beneficial for us nor for the upstream projects or for > the diversity (in regards to how to use and run a piece of software) of > the ecosystem in general. > > This also means that running and installing this software in an Arch > Linux based container would be not supported and/or flaky as well, which > I consider a detriment to the distribution :-/ > To spin this wheel a bit further: What is the point of having a php > package, if it could also be provided by an upstream container? I saw this more as an option for rare exceptions and not the default. This is great if you cannot run your software at all otherwise. This is also not a real option as users can do this today already. :-) > > 2) Keep trying to patch upstream packages to keep them working. > > That's what we usually do and that is also what keeps momentum in > certain upstream projects. > > FWIW, that's what we do for the entire python ecosystem for better or > worse and more specifically for e.g. python-django, which has a few > dependents that can not easily be upgraded from one minor version to the > next. > > This sometimes means getting involved with upstreams, providing patches, > using patches, etc. which is part of the packager role that we are in. > > However, the problem we are currently facing is that of upstream > frameworks and languages being unable to provide sufficient > compatibility guarantees. > > For this we need to make a greater effort to have testers and more > clearly defined (automated) test scenarios. If we can not make this > effort to some (even small) extent, I'm wondering why we are packaging > languages at all anymore. I agree this should be the way to go. Not sure if I get your right here, but (extensive) testing is best done by upstream projects though. And a lot of them even test with release candidates so their releases even work on day one. I usually provide release candidates for Arch's PHP packages as well. I could make that more public for maintainers that want to test as early as possible. We might also ask packagers to run basic unit tests during packaging. > > 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. > > Wouldn't this mean that those php versions are mutually exclusive? > I would be more in favor of moving towards a unified php version again, > else we might end up with a lua or java situation eventually. They would be installable and usable at the same time. In the same we as you may currently use PHP 7 and 8, which was originally meant to be a temporary solution. There is a catch though: The user has to alter the configuration when he wants to switch versions. > > 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. > > I don't think the option to "move faster" is a good one if there is > nothing that is outright compatible anymore ;-) > What would be the target of an up-to-date php, that has no packages > using it? This is likely exaggerated. Adaption of new versions is quite fast these days, especially minor ones. Most of the frameworks, packages and libraries had compatible release before the first patch release. But of course this heavily depends on what you work with. And here is the whole point of the issue: On one hand people want or need the latest packages and on the other hand some projects might need more time. > With a two version system (that is mutually exclusive?) we would have > the same issues with incompatible projects as soon as we move from one > version to the other, just at a different point
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
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
Re: [arch-dev-public] Starting x86_64_v3 port
On Sat, Jan 29, 2022 at 2:49 PM Allan McRae via arch-dev-public wrote: > Assuming we need people to help the x86_64_v3 port, I would post a news > item and have people apply. We have advertised developer positions in > the past and received dozens of applications, and readily filled the > available positions with quality applicants. They would be brought on > as Package Maintainers (once approved on the staff list) with access to > [extra] and [community], and have packaging privileges including being > added to the keyring. > > While advertising for x86_64_v3 specific packagers, we should make a > list of other packaging areas needing help and recruit for those too. While I would have preferred to gradually have raised the CPU requirements of our main repo (e.g. v2 right now and v3 in a few years), maintaining two x86_64 variants for a transition period might work. Nonetheless we should in work on how to get Arch back to be bleeding edge regardless of this. One aspect might be to reduce the overall amount of packages and get rid of unmaintained software (either by us or upstream). As the vast majority of hardware is v3 already we should consider x86_64 (https://pierre-schmitz.com
Re: [arch-dev-public] openssl 3.0
So I just build the 437 packages (pkgbase) and let my computer compile for just 25 hours. The initial results can be seen here https://md.archlinux.org/s/t8HOyhNOi Currently there are 27 packages in [core]/[extra] and 92 in [community] that do not build. I did not check the logs for every package yet, but I guess there are these categories: * package does not build regardless of OpenSSL (e.g. unavailable sources, checksum mismatch, issues due to LTO, ...) * packages also links to a not yet update package that still uses openssl-1.1 * packages are actually incompatible with OpenSSL 3.0 I'll need some help with: * Document why a package fails (complete build logs are attached to the document linked above) * Create a todo list for packages that are broken for other reasons and fix them * Review the legacy openssl-1.1 package and check if this approach is valid. (last time we patched versiond symbols in 1.0 which I did not apply here) See https://github.com/archlinux/svntogit-packages/tree/packages/openssl-1.1/trunk and https://github.com/archlinux/svntogit-packages/tree/packages/openssl-1.0/trunk * Fix the incompatible packages and as a last resort link to 1.1 PS: if there is a tool that is able to rebuild and install packages in the correct order (not by explicit dependency but by so lib links), let me know. Greetings, Pierre On Fri, Jan 28, 2022 at 9:41 AM Maxime Gauduin via arch-dev-public wrote: > > On Thu, 2022-01-27 at 16:47 +0100, Christian Hesse via arch-dev-public > wrote: > > Pierre Schmitz via arch-dev-public > > on > > Sun, 2022/01/23 12:50: > > > 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? > > > > I guess the ffmpeg 5.0 will be blocking for some time... > > Not necessarily. There are too many packages that don't build, I will > maintain a temporary ffmpeg4.4 package to get this todo out quickly. > Should have time for this over the weekend. > > Cheers, > -- > Maxime -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] openssl 3.0
Hi Christian,
there were some delays due to other rebuilds and lack of time/other issues.
So far I did not get any feedback, so I'd like to repeat my request for help.
* If someone with more C knowledge could review the openssl-1.1
package that would be great
* To all maintainers: Please have a look at
https://md.archlinux.org/s/t8HOyhNOi and check if your package is
listed as "failed to build". It would be great to add a note about the
Openssl 3.0 support status (see notes I added for some core packages
for example)
Greetings,
Pierre
On Tue, Mar 15, 2022 at 11:21 AM Christian Hesse wrote:
>
> Pierre Schmitz via arch-dev-public on
> Sun, 2022/01/23 12:50:
> > 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?
>
> The todo list has been around for too long already. Any news on this?
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
> putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
--
Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Upcoming PHP 8.1 update
I'd still suggest to provide two different php versions as mentioned some time ago: the current "php" and "php-legacy" which will always be the oldest supported version. These may provide the versions as you suggested: php-legacy provides php=7.4 (and will be updated to 8.0 soon) The benefit of not encoding the versions within the package name is easier maintenance and user wont have to manually update their config and systemd files. The "-interpreter" suffix is required to make it work with pacman or could php-legacy-apcu provide php-apcu=7.4? On a side node: PHP 7 is on its way out of support and wont work with e.g. OpenSSL 3 :-) So we have to update to 8.0 in a few month at latest. Greetings, Pierre On Sun, Apr 24, 2022 at 6:57 PM David Runge wrote: > > On 2022-03-08 13:56:04 (+0100), David Runge via arch-dev-public wrote: > > after waiting another couple of weeks, the situation with nextcloud > > unfortunately has still not improved. > > We see issues with utf-8 compatibility [1] and meanwhile the version > > 24.0.0 which is supposed to provide native support for php 8.1 is being > > delayed until end of April [2]. > > > > This all being what it is, I believe the sanest (but also a bit > > complicated to maneuvre) way forward is to downgrade its dependencies to > > php7, as otherwise we will be stuck even longer with > > broken/disfunctional setups. > > Meanwhile more time has passed and there has not been any progress on > this. For nextcloud 23.0.4 the compatibility patches do not apply > cleanly anymore. > > Therefore I will implement a specific version check for it to check its > own php compatibility and fail otherwise, while removing the patches. > > > The version constraints are implemented directly towards the language > > version the application is run with and would mean a good safe-guard > > against breakage in packaging and expectation. > > As it stands we would need to add a provides php=$version to the "older" > > php package (this also needs to be done for the current php7), which > > would allow more or less seamless upgrades/downgrades based upon the > > requirements of a given project. By default projects would always use > > the latest php, if not declaring version requirements. > > An upgrade to a given project, introducing an updated php version > > requirement, would automatically pull in the required php* package. > > > > I'm still a bit unsure about how to deal with this in the context of php > > modules though. For those we would still need to specifically touch a > > given PKGBUILD to change a dependency (e.g. php-gd vs. php7-gd) unless > > we come up with a way to abstract this with a common virtual provides. > > I will introduce this for php7 in [testing] now and build nextcloud > 23.0.4 against it. > > This works for the interpreter, but it's more involved when looking at > the remaining interpreter-specific modules. > > It would make sense to implement an abstraction for each that pulls in > the correct package. > E.g. for php7-apcu add a `provides=(php-apcu-interpreter=7)` and for > php-apcu add a `provides=(php-apcu-interpreter=8)`. > That way consumers can decide which interpreter they require by > depending on e.g. `php-apcu-interpreter=8`. This works similar to how we > do things for java. > > Do you have any thoughts on this? > > Best, > David > > -- > https://sleepmap.de -- Pierre Schmitz, https://pierre-schmitz.com
