Hi,

to prevent the situation from the last time, I am kind of "starting"
the transition to PHP 8.2 now with PHP 8.2.0~alpha2.  I will be uploading
packages to experimental as I will be updating them to support PHP 8.2.

Ondrej

Ben file:

title = "php8.2";
is_affected = .depends ~ "phpapi-20210902" | .depends ~ "phpapi-20210903";
is_good = .depends ~ "phpapi-20210903";
is_bad = .depends ~ "phpapi-20210902";
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmLFlsdfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcL5Bg//eTOW8HuuF15R/5SPKReyizaG9oB75HIVUBWTwnovNcJx3UNvlpoGCrdK
jWEaAD+Pv9b321gZikPuauYgwT3N0sGeA7L51aRO1m4BCEvmOTnY6VbmLvS66KM9
AWZigYK+/ZLDxju5edAdhfA25a8GLeFuXHg9YZERmpIoZH+++iVFnNZtrWbJ+NB0
cpcMapq9jIkuz3qKKEccKFTCD1Yy63rCVgqaTWg0oHydKyx1n4OQjZhmDMOgHdPg
hgN+9Kc5YLYcK3ReyKCxaernWcPtP9Zw8JJx3b62EmvKV6fglWNMzt++dQhGzM+5
iwWHeAaR/UaGf43T1DtT4j55quUXRNaJda3GQ27xoBDZRf8k7LZSp+rnhUZDlNRe
fX2LYyCe2IBkATiKIa1A3JfuPf6/6i1OEXP6keMVgf9LdLSi+yGZ//DLy+ObhCOF
+Q0yBv8eYSpOUk4EChFCKBvLLVv+PDdo896FK1E0z42XpJvWVVHGJ8ZZ9IljnLM7
l8Ccnr4Iov9aETXWBE+seEV1P6G034yj6CxmSBgTnJ2gKJLhT/mLPbLfqZsl0saF
xwCyq03p1Xz1DZtZJXCFNNe2LV56vYYmvxs/EnrSN2jgziIKvHPQffl+QRVelbza
BJ7ZIWxDLmSJfdkJbd91PPKnPePkUo5WsMyCFI+PCNQjox7xeXk=
=jKgC
-----END PGP SIGNATURE-----

Hi Ondřej,

Ack and appreciated. I assume your ambition is to ship bookworm with PHP
8.2.

Tracker file set up and will be available in a short while.

Paul

Hi Ondrej,

Are you planning on releasing this between the release in November and
the freeze or is the plan to land this is unstable after the bookworm release?

Hi Ondřej, Mike and Horde team, PHP PEAR and Composer team, and Release
team.

Le 21/07/2022 à 13:22, David Prévot a écrit :

There is a new URL/view, thanks Paul for the hint:

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

There are still over twenty packages that need fixing in the Horde camp,
probably most of them could use a “Restrictions: allow-stderr”
workaround in debian/tests/control.

I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and
cacti), am crossing fingers that the latest php-proxy-manager upload
will fix its issue, and hope that the recent issue that popped up with
phpunit, phpunit-type and php-doctrine-common (that looks similar) will
fix itself soon enough too (upstream being usually pretty reactive).
php-log is still not in testing, so not a blocker.

I believe there are no more blockers that could be spotted with debci.
Since not all packages have tests, and those tests can’t spot every
regressions, there will probably be more issues, but I believe it looks
good for now (especially compared to previous transitions). I believe
the first (non RC) PHP 8.2 release is expected upstream in a month, so,
if that’s the targeted version for Bookworm, I hope this transition
could happen as soon as possible.

Ondřej, there were some missing php8.1-* packages that needed NEW
processing last time, have all php8.2-* packages been processed this time?

Regards

David

icingaweb2 explicitly doesn't support php8.2 upstream yet, their php8.1
support took many months to land, getting php8.2 into unstable before
the bookworm freeze will most likely result in not shipping icingaweb2.

Kind Regards,

Bas

Hi all,

@horde team, do you think you can work on these deprecation warnings in
time? If not, can we have the allow-stderr restriction uploaded soon
please? Maybe somebody can help the horde team to get these uploaded if
that helps (please let us know).

Ack. "I" am affected as cacti maintainer. I'll make sure cacti isn't in
the way. Upstream already acked the bug report.

For the transition, do we agree it's smart to wait until the non-RC php
8.2 arrives, or should try and transition earlier to some RC candidate
to find issues earlier? Where can I find the timeline of php 8.2?

It would indeed be good to make sure that these are in the archive
before we start. I also recall php toolchain changes in the last
transition. If there are any pending toolchain changes, please make sure
that they are deferred or migrated to testing already, before we start
the transition.

Paul

Hi Paul,

my overall intention is to get Horde ready for bookworm before X-mas.
On my todo list are more urgent packages atm, though (pam-python,
gosa). Both will require some effort.

For Horde, getting autopkgtests resolved (and packages migrate to
testing) is one thing, but getting all of Horde
deprecation-warnings-free with php8.2 at run time is a completely
different cup of team. (Horde upstream is slowly working on Horde6,
but that will not be ready for bookworm, so we have to stay with
Horde5 for Debian 12).

I am currently trying to get my UDD dashboard beautiful again, but
this will be an ongoing effort until December (and probably more
uploads after X-mas).

The allow-stderr flag in debian/tests/control is a viable solution,
but I'd love to use that as a last ressort. At the moment, it is more
helpful (to me) to see all those CI failures and not have them mask
with that flag.

Greets,
Mike

Hey David,

I'll be uploading the PECL extensions for PHP 8.2 to experimental as I will update them
for PHP 8.2 - I haven't started yet, but should be able to do before or around the PHP 8.2.0
release.

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

Hi Paul,

I don’t recall any major changes to the toolchain, but I’ll double check. I switched some of the PECL extensions to use separate sources for different PHP version, so I don’t have to bundle old versions with new in single tarball, so it might be a good time to finish this, so bookworm has a cleaner state of PECL extension packages.

Ondrej
--
Ondřej Surý <ondrej@sury.org> (He/Him)

I wanted to update PHP 8.2 in experimental today, but it seems that firebird-dev is in bad shape[1] as "All"[2] build failed

1. https://tracker.debian.org/pkg/firebird3.0 <https://tracker.debian.org/pkg/firebird3.0>
2. https://buildd.debian.org/status/fetch.php?pkg=firebird3.0&arch=all&ver=3.0.11.33637.ds4-1&stamp=1666553566&raw=0 <https://buildd.debian.org/status/fetch.php?pkg=firebird3.0&arch=all&ver=3.0.11.33637.ds4-1&stamp=1666553566&raw=0>

I am going to fill serious bug now

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

The test failures in php-faker are caused by a bug in PHP [1] that has
been fixed since 8.2.0 RC5 [2]. They can be ignored, assuming we're
not shipping RC5.

[1] https://github.com/FakerPHP/Faker/pull/528#issuecomment-1292745178
[2] https://github.com/php/php-src/commit/7f0b228f48ad29c13a84dc8c8bc050f34d3a855a

Regards,
Robin

Do you plan to include php-imagick in this?

I had to rebuild it with php8.2 from experimental for icingaweb2.

Kind regards,

Bas

Hi Bas,

yes, in fact, I've mass uploaded[1] all the extensions to the experimental today
to be rebuilt with PHP 8.2

1. It's kind of hackish, so it might take me couple of retries to figure out the
right mangling of the packages for the experimental uploads. So far, I hit
the "empty-binary-package" auto-REJECTs and missing orig source. I hope
that exp3 did hit the sweet spot, but even that there are couple NEW packages
built from the source, so it might take some time to get them processed through
NEW queue.

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

Hey all,

I think everything is mostly ready in experimental. I'll try to sort out
the rest of the missing extensions over the weekend (imagick, memcached,
redis and maybe few others).

The bump from 8.x to 8.2 is relatively painless, so can we schedule the
transition in few days/weeks?

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

Dear Ondřej,

Assuming this happened (more or less).

Please go ahead.

Paul

Hi Ondřej,

Ping. In a week from now, the Transition and Toolchain freeze starts
[1]. The upload should happen before then, otherwise I'm going to
withdraw the approval.

Paul

[1] https://release.debian.org/testing/freeze_policy.html

is_good doesn't match what's currently used for builds with php8.2:

  phpapi-20220829

Kind Regards,

Bas

This has just been merged, thanks Adrian!


[1] https://salsa.debian.org/release-team/transition-data/-/merge_requests/36

php-igbinary needs to be moved to unstable, php-apcu is built &
installed on all release architectures.

php-raphf is also built & installed on all release architectures, but
php-pecl-http was not staged in experimental and will need to pass NEW.

php-memcached and php-redis were not uploaded to experimental either.

Kind Regards,

Bas

Hi Ondřej,

I have a couple of questions:

I'm seeing that php-common has a Breaks on php8.1-common. Why is that?
Is that really needed? It makes the migration a bit more complicated as
it means that php8.1 has to be removed at the same time that php-common
migrates.

Will you also take care of src:xdebug, next to php-pecl-http,
php-memcached and php-redis as Bas suggested?

Paul

Hi,

yes, I will take care of those, I’m just uploading them in batches as the dependencies require. I’ll check all the errors tomorrow. It was just Sunday, so I was not sitting by the computer. I expect to have everything solved next week.

The Breaks have been added there since the last transition - there was a tendency for the apt dependency solver to pick one package (say php-imagick) from old PHP version and other one from new PHP version (say php-mysql). The Breaks was the only solution we came with that worked. I can dig up some old issues from the last transition.

Ondrej
--
Ondřej Surý <ondrej@sury.org> (He/Him)

Hi,

and with that I've uploaded the php-memcached and php-redis to NEW.

I've also throw in couple more extensions:

- php-xmlrpc (unbundled from PHP 8.x)
- php-mcrypt (unbundled from PHP 8.x)
- php-maxminddb (replacement for php-geoip)

Are there any extra extensions that the people actually using PHP would like to have in Debian?

Now, what should I do about:

    • Not built on buildd: arch amd64 binaries uploaded by ondrej
    • Not built on buildd: arch all binaries uploaded by ondrej, a new source-only upload is needed to allow migration

Do I really have to reupload everything that had to pass NEW with no-change source-only upload?

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

Hi Ondřej,

I have already NMU'd one of them (no change source only), because yes,
our infrastructure currently doesn't enable us to do binNMU that
survives for arch:all (we can do arch:any).

Just in case you aren't aware, if the problem is that Build-Dependencies
aren't available yet (because of your previous batch), you don't need to
wait with uploading. The buildd's will know what to do and the package
will stay in "Builds Dependencies unavailable" until their B-D's are
built and available on the buildd.

Paul

Sorry for top posting…

It’s easier for me to wait as I don’t want use custom repository for my sbuild chroots. Hence the wait…

Ondrej
--
Ondřej Surý <ondrej@sury.org> (He/Him)

Hi Ondřej

Those will be rebuilt semi-automatically.

Those require a source-only upload.

Cheers

Hi Mike and other Horde maintainers,

We're now nearing the end of the php8.2 transition (hopefully), but
there's still a large set of horde packages affected. In the view of the
release team these autopkgtest failures will very soon be RC bugs. Will
you fix these autopkgtest real soon now (the underlying issue or
allow-stderr)? Do I need to file RC bugs for all of them? Should I
remove horde from bookworm and let you fix the packages one by one? We
can live with any reasonable option, but accepting these autopkgtest
regressions in bookworm is only acceptable by us with RC bugs filed
(causing the autoremoval timer to start counting).

Paul

Hi Paul,

as you can see in previous uploads Anton Gladky has worked on fixing
most of the Horde issues for php8.1 with recent upload. That was done
as paid work.

The goal of the funded uploads is to keep Horde in bookworm.

So ideally, and if possible, you file RC bug reports for the new
autopkgtest failures/regressions introduced by the php8.2 transition /
upload.

Thanks for your work!
Mike

Hi Ondřej,

I think we saw this pattern quite a bit in the autopkgtest failures too.
It looks like the dependencies of the individual packages aren't perfect
yet. I decided to ignore the autopkgest failures as the tests passed in
a pure unstable environment (or otherwise got an RC bug about it), but
it does hint that something is too lax on the dependency side; at least
for tests.

I have rescheduled binNMU's of the last blockers in tpu and added a
removal hint for uwsgi-plugin-php. If everything fares well,
php-defaults could migrate tomorrow morning in the 7:52 dinstall run
(maybe).

Paul

Thanks everyone. php-defaults migrated and php8.1 got removed from
testing.

Cheers