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
signature.asc
Description: OpenPGP digital signature
