Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-18 Thread Paul Gevers

Hi Ondřej,

On 08-01-2023 22:41, Ondřej Surý wrote:

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.


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: transition: php8.2

2023-01-12 Thread Mike Gabriel

Hi Paul,

On  Do 12 Jan 2023 14:59:50 CET, Paul Gevers wrote:


Hi Mike and other Horde maintainers,

On 22-10-2022 17:31, Mike Gabriel wrote:
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.


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


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


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpoiggSl00vF.pgp
Description: Digitale PGP-Signatur


Bug#1014460: transition: php8.2

2023-01-12 Thread Paul Gevers

Hi Mike and other Horde maintainers,

On 22-10-2022 17:31, Mike Gabriel wrote:
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.


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-11 Thread Sebastian Ramacher
Hi Ondřej

On 2023-01-11 20:42:28 +0100, Ondřej Surý wrote:
> 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

Those will be rebuilt semi-automatically.

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

Those require a source-only upload.

Cheers

> 
> 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)
> ond...@sury.org
> 
> 
> 
> > On 8. 1. 2023, at 22:41, Ondřej Surý  wrote:
> > 
> > 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ý  (He/Him)
> > 
> >> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
> >> 
> >> Control: severity 1023370 serious
> >> Control: severity 1023381 serious
> >> 
> >> Hi Ondřej,
> >> 
> >>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
>  On 12/15/22 20:15, Ondřej Surý wrote:
>  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).
> >>> 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.
> >> 
> >> 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
> 

-- 
Sebastian Ramacher



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-11 Thread Ondřej Surý
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ý  (He/Him)

> On 11. 1. 2023, at 21:01, Paul Gevers  wrote:
> 
> Hi Ondřej,
> 
>> On 11-01-2023 20:42, Ondřej Surý wrote:
>> 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?
> 
> 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).
> 
>>> yes, I will take care of those, I’m just uploading them in batches as the 
>>> dependencies require.
> 
> 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



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-11 Thread Paul Gevers

Hi Ondřej,

On 11-01-2023 20:42, Ondřej Surý wrote:

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?


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).



yes, I will take care of those, I’m just uploading them in batches as the 
dependencies require.


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-11 Thread Ondřej Surý
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)
ond...@sury.org



> On 8. 1. 2023, at 22:41, Ondřej Surý  wrote:
> 
> 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ý  (He/Him)
> 
>> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
>> 
>> Control: severity 1023370 serious
>> Control: severity 1023381 serious
>> 
>> Hi Ondřej,
>> 
>>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
 On 12/15/22 20:15, Ondřej Surý wrote:
 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).
>>> 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.
>> 
>> 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



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-08 Thread Ondřej Surý
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ý  (He/Him)

> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
> 
> Control: severity 1023370 serious
> Control: severity 1023381 serious
> 
> Hi Ondřej,
> 
>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
>>> On 12/15/22 20:15, Ondřej Surý wrote:
>>> 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).
>> 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.
> 
> 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



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-08 Thread Paul Gevers

Control: severity 1023370 serious
Control: severity 1023381 serious

Hi Ondřej,

On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:

On 12/15/22 20:15, Ondřej Surý wrote:

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).


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.


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-07 Thread Sebastiaan Couwenberg

On 12/15/22 20:15, Ondřej Surý wrote:

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).


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

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#1014460: transition: php8.2

2023-01-06 Thread Graham Inggs
On Fri, 6 Jan 2023 at 12:00, Sebastiaan Couwenberg  wrote:
> is_good doesn't match what's currently used for builds with php8.2:
>
>   phpapi-20220829

This has just been merged, thanks Adrian!


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



Bug#1014460: transition: php8.2

2023-01-06 Thread Sebastiaan Couwenberg

On 7/14/22 15:23, Paul Gevers wrote:

https://release.debian.org/transitions/html/php8.2.html

[...]


title = "php8.2";
is_affected = .depends ~ "phpapi-20210902" | .depends ~ 
"phpapi-20210903";

is_good = .depends ~ "phpapi-20210903";
is_bad = .depends ~ "phpapi-20210902";


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


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

 phpapi-20220829

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2023-01-05 Thread Paul Gevers

Hi Ondřej,

On 21-12-2022 21:28, Paul Gevers wrote:

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


Please go ahead.


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-12-21 Thread Paul Gevers

Control: tags -1 confirmed

Dear Ondřej,

On 15-12-2022 20:15, Ondřej Surý wrote:

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).


Assuming this happened (more or less).


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


Please go ahead.

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-12-15 Thread Ondřej Surý
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)
ond...@sury.org



> On 10. 12. 2022, at 17:23, Ondřej Surý  wrote:
> 
> 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)
> ond...@sury.org
> 
> 
> 
>> On 5. 12. 2022, at 16:33, Sebastiaan Couwenberg  wrote:
>> 
>> On 10/22/22 21:46, Ondřej Surý wrote:
>>> 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.
>> 
>> Do you plan to include php-imagick in this?
>> 
>> I had to rebuild it with php8.2 from experimental for icingaweb2.
>> 
>> Kind regards,
>> 
>> Bas
>> 
>> -- 
>> GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>> 
> 



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-12-10 Thread Ondřej Surý
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)
ond...@sury.org



> On 5. 12. 2022, at 16:33, Sebastiaan Couwenberg  wrote:
> 
> On 10/22/22 21:46, Ondřej Surý wrote:
>> 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.
> 
> Do you plan to include php-imagick in this?
> 
> I had to rebuild it with php8.2 from experimental for icingaweb2.
> 
> Kind regards,
> 
> Bas
> 
> -- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-12-05 Thread Sebastiaan Couwenberg

On 10/22/22 21:46, Ondřej Surý wrote:

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.


Do you plan to include php-imagick in this?

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

Kind regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#1014460: transition: php8.2

2022-11-06 Thread Robin Gustafsson
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



Bug#1014460: transition: php8.2

2022-10-24 Thread Ondřej Surý
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 

2. 
https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=all=3.0.11.33637.ds4-1=1666553566=0
 


I am going to fill serious bug now

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

> On 22. 10. 2022, at 22:23, Ondřej Surý  wrote:
> 
> 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ý  (He/Him)
> 
>> On 22. 10. 2022, at 16:56, Paul Gevers  wrote:
>> 
>> 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.



Bug#1014460: transition: php8.2

2022-10-22 Thread Ondřej Surý
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ý  (He/Him)

> On 22. 10. 2022, at 16:56, Paul Gevers  wrote:
> 
> 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.



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-10-22 Thread Ondřej Surý
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)
ond...@sury.org

> On 22. 10. 2022, at 16:25, David Prévot  wrote:
> 
> 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 :
>> Le 14/07/2022 à 15:23, Paul Gevers a écrit :
>>> Control: forwarded -1 
>>> https://release.debian.org/transitions/html/php8.2.html
>> […]
>> php-defaults was updated in experimental, allowing us to spot some 
>> regressions thanks to autopkgtests.
> 
> There is a new URL/view, thanks Paul for the hint:
> 
> https://qa.debian.org/excuses.php?experimental=1=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.
> 
>> Thanks in advance if you can try and help fixing those issues. You’re more 
>> than welcome to report bugs against packages in order to document the 
>> problem, and eventual hints to get them fixed.
>> Severity: important
>> Control: block 1014460 by -1
> 
> 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



signature.asc
Description: Message signed with OpenPGP


Bug#1014460: transition: php8.2

2022-10-22 Thread Mike Gabriel

Hi Paul,

On  Sa 22 Okt 2022 16:56:36 CEST, Paul Gevers wrote:


Hi all,

On 22-10-2022 16:25, David Prévot wrote:
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.


@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).


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
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpcF9WPAdVkI.pgp
Description: Digitale PGP-Signatur


Bug#1014460: transition: php8.2

2022-10-22 Thread Paul Gevers

Hi all,

On 22-10-2022 16:25, David Prévot wrote:
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.


@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).


I’ve filed three bugs like that (for php-nesbot-carbon, shaarli and 
cacti),


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


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.


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?


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


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-10-22 Thread Sebastiaan Couwenberg

On 10/22/22 16:25, David Prévot wrote:
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.


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

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

2022-10-22 Thread David Prévot
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 :

Le 14/07/2022 à 15:23, Paul Gevers a écrit :
Control: forwarded -1 
https://release.debian.org/transitions/html/php8.2.html

[…]
php-defaults was updated in experimental, allowing us to spot some 
regressions thanks to autopkgtests.


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

https://qa.debian.org/excuses.php?experimental=1=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.


Thanks in advance if you can try and help fixing those issues. You’re 
more than welcome to report bugs against packages in order to document 
the problem, and eventual hints to get them fixed.


Severity: important
Control: block 1014460 by -1


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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: transition: php8.2

2022-09-26 Thread Athos Ribeiro

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?

--
Athos Ribeiro



Bug#1014460: transition: php8.2

2022-07-14 Thread Paul Gevers
Control: forwarded -1 
https://release.debian.org/transitions/html/php8.2.html


Hi Ondřej,

On 06-07-2022 16:05, Ondřej Surý wrote:

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.


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



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


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

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014460: transition: php8.2

2022-07-06 Thread Ondřej Surý
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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++uWcIFAmLFlsdfFIAALgAo
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-