Yes, you were right. It didn't help, so I've requested binNMUs for all the extensions to remove dependency on PHP 7.3, so it will sort out when the binNMU is finished.
Ondrej On Tue, 24 Mar 2020 at 04:18, David Prévot <da...@tilapin.org> wrote: > Control: reopen -1 > Control: reassign -1 php-apcu > Control: found -1 5.1.18+4.0.11-1 > > Le 23/03/2020 à 09:13, Ondřej Surý a écrit : > > > I disagree that all of the added dependencies are wrong. > […] > The autopkgtest needs to at least depend on php-cli. > > Yet, the autopkgtest does not call php-cli. Instead, it calls phpunit > (that, again, already depends on php-cli, php-xml, and php-mbstring). So > no, please revert that change at least in the VCS(s). > > php-doctrine-cache works both with php7.3 (x)or php7.4, nothing to fix > there a priori. > > > Also the dependencies are already tight > > No, the problem you’re currently facing is that php-apcu can be > installed on testing, pulls some php7.4-* related packages, but does not > enforce running php7.4 (nor installing the other php7.4 extensions). You > should be able to fix it by adding a Break : php7.3-common to php-apcu > (so that php7.3 related packages can’t be installed, and the php7.4 gets > pulled instead). > > Feel free to double check the failing autopkgtest logs linked from the > PTS <https://tracker.debian.org/pkg/php-apcu>. > > > I already filled RoM bug against php7.3, that’s the ultimate fix for > > all failing autopkgtests > > No it’s not, and can’t work anyway (removing php7.3 from unstable won’t > make it disappear from testing until a suitable replacement is ready, > but the autopkgtest regressions currently prevents php7.4 to migrate). > You may want to get in touch with the release team and ask them for an > exception to let all the php7.4 packages pass in one shot, but they may > ask you to add the Break previously suggested anyway first. > > Regards > > David > >
