Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1121878 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 David Prévot <david@tilapin.org> - 2022-10-22 16:30 +0200
    Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Sebastiaan Couwenberg <sebastic@xs4all.nl> - 2022-10-22 17:00 +0200
    Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2022-10-22 17:10 +0200
      Bug#1014460: transition: php8.2 Mike Gabriel <mike.gabriel@das-netzwerkteam.de> - 2022-10-22 17:40 +0200
        Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2023-01-12 15:10 +0100
          Bug#1014460: transition: php8.2 Mike Gabriel <mike.gabriel@das-netzwerkteam.de> - 2023-01-12 20:50 +0100
    Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Sebastiaan Couwenberg <sebastic@xs4all.nl> - 2022-12-05 16:50 +0100
      Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2022-12-21 21:40 +0100
        Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2023-01-05 12:20 +0100
      Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Sebastiaan Couwenberg <sebastic@xs4all.nl> - 2023-01-08 07:50 +0100
        Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2023-01-08 22:30 +0100
          Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2023-01-11 21:10 +0100
          Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Sebastian Ramacher <sramacher@debian.org> - 2023-01-11 21:40 +0100
          Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2 Paul Gevers <elbrus@debian.org> - 2023-01-18 22:30 +0100

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

[Multipart message — attachments visible in raw view] — view raw

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

> 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

[toc] | [next] | [standalone]

#1121885

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

[toc] | [prev] | [next] | [standalone]

#1121886 — Bug#1014460: transition: php8.2

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1121889 — Bug#1014460: transition: php8.2

[Multipart message — attachments visible in raw view] — view raw

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.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

[toc] | [prev] | [next] | [standalone]

#1132916 — Bug#1014460: transition: php8.2

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1132967 — Bug#1014460: transition: php8.2

[Multipart message — attachments visible in raw view] — view raw

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.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

[toc] | [prev] | [next] | [standalone]

#1127554

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

[toc] | [prev] | [next] | [standalone]

#1129819

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1131776

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1132230

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

[toc] | [prev] | [next] | [standalone]

#1132341

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1132818

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1132823

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)
> ondrej@sury.org
> 
> 
> 
> > On 8. 1. 2023, at 22:41, Ondřej Surý <ondrej@sury.org> 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ý <ondrej@sury.org> (He/Him)
> > 
> >> On 8. 1. 2023, at 22:24, Paul Gevers <elbrus@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#1133812

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web