Bug#1074180: transition: php8.4

[Ondřej Surý]

Package: release.debian.org
Severity: normal
User: ***@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-php-***@lists.alioth.debian.org, team+debian-horde-***@tracker.debian.org

Hi,

this is the pre-announcement of the bi-annual transition from PHP 8.2 to PHP 8.4
that happens before the next stable release.

Currently, the first alpha release of PHP 8.4 is planned for July 2024:

https://wiki.php.net/todo/php84

I'll try to get this to experimental as soon as possible, but usually the
extensions start to catch up with the changes around the first Release Candidate
(end of September 2024). This is also usually the time when then PHPAPI version
settles and will not change anymore.

My guess is that it would be reasonable for packagers of downstream packages to
start more serious testing around first Beta version.

I've tried to CC the PEAR and HORDE packagers, if you know of more people who
should be involved in the transition, please let them know.

Ondrej

Ben file:

title = "php8.4";
is_affected = .depends ~ /phpapi-/;
is_good = .depends ~ /phpapi-2024/;
is_bad = .depends ~ "phpapi-20220829";

[Athos Ribeiro]

Post by Ondřej Surý
Hi,

Hi Ondřej,

Post by Ondřej Surý
this is the pre-announcement of the bi-annual transition from PHP 8.2 to PHP 8.4
that happens before the next stable release.
https://wiki.php.net/todo/php84
I'll try to get this to experimental as soon as possible, but usually the
extensions start to catch up with the changes around the first Release Candidate
(end of September 2024). This is also usually the time when then PHPAPI version
settles and will not change anymore.

Thanks!

Post by Ondřej Surý
My guess is that it would be reasonable for packagers of downstream packages to
start more serious testing around first Beta version.

When the time comes (beta), I can prepare a mass rebuild of reverse
dependencies and file bugs around so we can track the progress on this
one (as I have been doing with David for symfony, phpunit, and
pkg-php-tools). I suppose we will also need a changed php-defaults
version setting it as default or as a supported version.

Post by Ondřej Surý
I've tried to CC the PEAR and HORDE packagers, if you know of more people who
should be involved in the transition, please let them know.
Ondrej
title = "php8.4";
is_affected = .depends ~ /phpapi-/;
is_good = .depends ~ /phpapi-2024/;
is_bad = .depends ~ "phpapi-20220829";

[Athos Ribeiro]

Hi,

I performed a first mass rebuild for all php8.2 and php-defaults
reverse-dependencies. The results are available at:
http://people.ubuntu.com/~athos-ribeiro/rebuilds/php8.4-alpha/

Since there are still API changes missing in alpha, it would be nice to
do another rebuild for beta (or next month for an RC).

For now, I suppose I will not start filing bugs for the current failures
though: I believe we will get more significant results when we have the
API changes in place.

Finally, note that there are most likely some false negatives in the
list since some packages hard code the php8.2 dependency.

[Paul Gevers]

Hi Athos,

Post by Athos Ribeiro
I performed a first mass rebuild for all php8.2 and php-defaults
http://people.ubuntu.com/~athos-ribeiro/rebuilds/php8.4-alpha/

Are you aware that we at ci.d.n offer support for these kind of rebuild
archives as external sources to schedule autopkgtests against? See the
bottom of [1].

This was also recently discussed in bug 1073983 that mentioned scripts
by glondu to do the scheduling. If you're interested, that bug had more
discussion so is probably a good read.

Paul

[1]
https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/debci/templates/extra_apt_sources_list.yaml.erb?ref_type=heads

[Athos Ribeiro]

Post by Paul Gevers
Hi Athos,

Hi Paul,

Post by Paul Gevers

Post by Athos Ribeiro
I performed a first mass rebuild for all php8.2 and php-defaults
http://people.ubuntu.com/~athos-ribeiro/rebuilds/php8.4-alpha/

Are you aware that we at ci.d.n offer support for these kind of
rebuild archives as external sources to schedule autopkgtests against?
See the bottom of [1].

This is quite interesting. No, I was not aware!
I suppose I would need to also push php8.4 and php-defaults to that
repository so autopkgtest would pick those up, right? Or is it possible
to pick those from experimental?

Post by Paul Gevers
This was also recently discussed in bug 1073983 that mentioned scripts
by glondu to do the scheduling. If you're interested, that bug had
more discussion so is probably a good read.

I will go through that and will request those autopkgtests for the new
rebuild I performed for PHP 8.4 beta available in experimental.

The new rebuild for the PHP beta version is available at
http://people.ubuntu.com/~athos-ribeiro/rebuilds/php8.4-beta/

This time we had 64 build failures. Note that there may be some false
positives and false negatives among them since some would need changing
due to hard coded php8.x dependencies.

I will follow through soon by filing bugs for those packages and
then I will proceed to request those autopkgtests based on these
rebuilds.

Hopefully, we will be ready for 8.4 GA which should be out by the end of
November.

[Paul Gevers]

Hi Athos,

Post by Athos Ribeiro
I suppose I would need to also push php8.4 and php-defaults to that
repository so autopkgtest would pick those up, right? Or is it possible
to pick those from experimental?

You can request from multiple additional archives, so yes, it's possible
to pick those from experimental.

Post by Athos Ribeiro

Post by Paul Gevers
This was also recently discussed in bug 1073983 that mentioned scripts
by glondu to do the scheduling. If you're interested, that bug had
more discussion so is probably a good read.

I will go through that and will request those autopkgtests for the new
rebuild I performed for PHP 8.4 beta available in experimental.

Well, we'd first need to add your repo to the ci.d.n infrastructure.
I'll do that tomorrow.

Paul

[Paul Gevers]

Hi Athos,

Post by Paul Gevers
Well, we'd first need to add your repo to the ci.d.n infrastructure.
I'll do that tomorrow.

I notice that you have a new archive for (probably) each rebuild. It
might be less hassle in the use of ci.d.n if you can maintain a
canonical URL for your latest rebuild, e.g. a softlink from
~athos-ribeiro/rebuilds/latest to ~athos-ribeiro/rebuilds/php8.4-beta now.

I've added php8.4-beta to the list of supported external repos.

Paul

[Athos Ribeiro]

Thanks Paul, I will prepare the link.

I also filed FTBFS bugs for the packages which are failing to build with
php 8.4. I skipped the ones which were clearly failing for unrelated
issues, but I still filed bugs for the ones which have dependency issues
(either because have hard coded deps with php 8.2 or because they depend
on other packages which are FTBFS with php 8.4). This way, we can track
those and re-build them once we get those dependencies sorted out.

I added php8.4 user tags on them for the
pkg-php-***@lists.alioth.debian.org user.

https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-php-pear%40lists.alioth.debian.org&tag=php8.4&state=open

[David Prévot]

Hi Ondřej,

Le Sun, Sep 22, 2024 at 09:30:24AM +0200, Ondřej SurÃœ a écrit :
[
]

The next release will be RC 1, planned for 26 September 2024.

I would like to start the transition to PHP 8.4 as soon as possible after that,
so we have plenty of time to solve all the problems that comes with upgrading.

That’s great news, thanks! I forgot to subscribe to this bug report
initially, so thanks also for the explicit CC ;).

Cheers,

taffit

[Debian Bug Tracking System]

tags -1 confirmed

Bug #1074180 [release.debian.org] transition: php8.4
Added tag(s) confirmed.

[Mike Gabriel]

Hi David,

Hi,

[
] It seems that most regressions are related to Horde (hence
CCing the team and Mike)

Half (14) of the 28 remaining issues spotted by debci are about
Horde packages. A quick look at a few random ones makes me hope that
most of them could be fixed by adding “Restrictions: allow-stderr”
to debian/tests/control.

https://qa.debian.org/excuses.php?package=php-defaults

I’ll look at the 14 other (not Horde related) remaining issues. The
symfony one should be fixed tomorrow once (php-guzzlehttp-promise
and) the latest guzzle enter testing (could have been two days ago
if the packaging kept running the tests when it was reintroduced to
Debian).
Regards,
taffit

The Horde situation in Debian is quite sad. Upstream is working on
some modernization aka Horde 6, but nothing in sight so far.

I'll ping Horde upstream on the current status the coming days, can
you - for now - ignore the php-horde-* package in the onoing transition?

Mike

[William Desportes]

Hi all,

Sorry to be the one to have two php*admin blocking packages.
phpMyAdmin nearly passed salsa CI, just one more test to fix.
phpldapadmin I might need some help or this will be delayed one more week. I did not investigate for now.

Happy end of year 🎉
--
William Desportes

Hi,

[…] It seems that most regressions are related to Horde (hence CCing the team and Mike)

Half (14) of the 28 remaining issues spotted by debci are about Horde packages.

[…]

The Horde situation in Debian is quite sad. Upstream is working on some modernization aka Horde 6, but nothing in sight so far.
I'll ping Horde upstream on the current status the coming days, can you - for now - ignore the php-horde-* package in the onoing transition?

If by ignoring, you mean “get it removed from testing”, I assume it’s possible.
Looking at what’s left on the [excuse] page, there are three end-user packages (mediawiki, phpldapadmin and phpmyadmin), all other look like libraries that are not used by any package currently in testing (well, except symfony, but the last upload is targeted to fix the remaining test issue on i386).
excuse: https://qa.debian.org/excuses.php?package=php-defaults
Regards,
taffit

[William Desportes]

Note that the only php-zumba-json-serializer only build-depends on
php-opis-closure. Not sure if that build-dep is still needed, if not
then we can drop php-opis-closure after php-opis-closure gets updated.

php-opis-closure is not maintained, see https://bugs.debian.org/1086186
to drop the package.

There was a PR on phpmyadmin-sql-parser to drop
php-zumba-json-serializer but it was rejected.
Ref: https://github.com/phpmyadmin/sql-parser/pull/598

I did file an issue upstream about changing de dependency:
https://github.com/zumba/json-serializer/issues/63

So those need to be looked at, alongside the applications (mediawiki,
phpmyadmin, etc).

phpmyadmin -> Upload done.
phpldapadmin -> One patch pushed to salsa, selenium DEP-8 are still
failing. Investigation in process..

--
William

[William Desportes]

Post by William Desportes
php-opis-closure is not maintained, see https://bugs.debian.org/1086186
to drop the package.

Well, they just did release v4. no time for that now.

Post by William Desportes
So those need to be looked at, alongside the applications (mediawiki,
phpmyadmin, etc).

phpldapadmin -> Upload done, DEP-8 OK

Can someone make php-defaults test against php-opis-closure 3.6.3-3 and
not 3.6.3-2 ?

Also, I do not know why php8.2 is listed on the php-defaults migration
page.

Apart from php8.2 and the testing of the right version of
php-opis-closure: php8.4 should migrate soon ?!

Happy new year to you all !

--
William

[David Prévot]

Hi,

Can someone make php-defaults test against php-opis-closure 3.6.3-3 and not
3.6.3-2 ?

Well, 3.6.3-2 is the version currently in testing, and 3.6.3-3 can’t
migrate currently because it fails its debci against php8.2. On the
other hand, php-opis-closure 3.6.3-3 testsuite is OK with php8.4, and
since it seems to be the last blocker for this transition, can the
release team allow to let php-opis-closure migrate in sync with
php-default?

Regards,

taffit

[Debian Bug Tracking System]

Your message dated Fri, 10 Jan 2025 10:42:08 +0100
with message-id <4139b33f-87d5-429e-9e54-***@debian.org>
and subject line Re: [pkg-php-pear] Horde issues [Was: Bug#1074180: transition: php8.4]
has caused the Debian Bug report #1074180,
regarding transition: php8.4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)