Today I tried to fill my compile/test breaks with some help for php7.4 by asking bryce this morning.
Summary for now is the usual one - I've moved a lot of things further, but there is work left :-) [07:07] <cpaelzer> bryce: any emergency php things to look into? [07:08] <bryce> not really, although there's a few things in migration that could be looked into [07:09] <bryce> + php-defaults: php-recode/amd64 => unsatisfiable Depends: php7.4-recode Problem: php7.4-recode really doesn't exist in Ubuntu But in d/control we have: 433 Package: php-recode 435 Depends: php-common, 436 php7.4-recode, Focal and Debian only have php7.3-recode from src:php7.3 Debians src:php-defaults (73) depends on php7.4-recode as well (they are just as broken). It turns out that src:php7.4 has no -recode package anymore. In the changelog I found: * The recode extension has been moved to PECL. But OTOH (if that is the right link) https://pecl.php.net/package/recode looks dead. => php-defaults will need a fix, this way it can't work a) - drop php-recode from php-defaults - remove rev-deps src:fusiondirectory and src:gosa otherwise update_output will stop you for making them non-installable b) - package the PECL php7.4-recode and get it to focal - then php-defaults migration will be able to continue => Not sure what Debian's plan on this is/was but as I said they should be just as affected. @Bryce that is up to you to continue ... [07:09] <bryce> + exim4 - retriggered (E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)) => Your retrigger worked https://launchpad.net/ubuntu/+source/exim4/4.93-11ubuntu1 has migrated [07:09] <bryce> + xdebug (php-codecoverage, php-unit) => both stumble over "Class 'DOMDocument' not found" Common fixes around the net: -> DomDocument instead of DOMDocument -> sudo apt-get install php-dom -> sudo apt-get install php7.4-xml The latter got me to realize that the test installs `php7.3-xml` but not `php7.3-xml` release: 2:7.3+69ubuntu2 depends on php7.3-xml proposed: 2:7.4+73ubuntu1 depends on php7.4-xml Part of the overall 7.4 transition. php-xml should be from src php-defaults, need a custom trigger with that (as expected for a transition). At first I wondered why it won't take my &trigger=php-defaults%2F2%3A7.4%2B73ubuntu1 But then I realized that src:73ubuntu1 generates binaries 2:7.4+73ubuntu1 With that I restarted xdebug on x86 to sniff test. => Results showed that this was indeed enough for php-codecoverage - I triggered all architectures that way. => Results good - all done => But phpunit had further issues. The new fails now seem like legitimate test-errors vs the new version: - Exception: Serialization of 'ReflectionClass' is not allowed - Deprecated: Function ReflectionType::__toString() is deprecated ... At least all 39 errors are about the same two things above, so one fix should do it for all. => https://github.com/sebastianbergmann/global-state/issues/21 This identified it would work with "sebastian/global-state": "^2.0 || ^3.0", In packaging terms that means we might need: phpunit-global-state | 3.0.0-2build3 | focal-proposed/universe | source, all I've triggered the tests including that also. => The results with that is further but not done yet. It seems there are a bunch of php7.4 issues where signatures change. Examples: --- Expected +++ Actual -'Argument #2 (No Value) of PHPUnit\Framework\Assert::assertCount() must be a countable or iterable' +'Argument #2 of PHPUnit\Framework\Assert::assertCount() must be a countable or iterable' But as we learned from other threads in this whole topic there also is a new phpunit - lets add that as well. => These tests are still ongoing - I'll reply later [07:09] <bryce> + php-memcache (php-doctrine-cache-bundle?) This is recently failing for php-memcache/3.0.9~20170802.e702b5f-4build1 as well as php-memcached/3.1.4+2.2.0-1 The test look reminds me of xdebug as I see: => "Class 'DOMDocument' not found" -> again another case that needs a trigger with the new php-defaults to pick up php7.4-xml to work Triggered both: - php-doctrine-cache-bundle test for php-memcache is good now -> I triggered all architectures that way now => Results good - all done - php-doctrine-cache-bundle test for php-memcached still failed `so: undefined symbol: php_msgpack_serialize` - does that ring a bell for someone? -> it might need the new php-memcache as well? - Nope, it must be something else -> This issue in php-memcached is free for anyone to pick up [07:09] <bryce> + php-horde-lz4 (TestCase::setUp() -- looks familiar) And another case of "Class 'DOMDocument' not found" Trying the same fix with a php-defaults retrigger. Results look good, triggered on all architectures now. => Results good - all done I've realized looking at the above that phpunit also has a lot of things that try to move together and are influenced by the 7.4 transition. Tests that are broken seem to come in three classes: Class I: - php-cache-lite - FAIL stderr: PHP Warning: file_put_contents(/usr/bin/.phpunit.result.cache): failed to open stream (no idea yet) - php-db - same I/O error - php-imagick - same I/O error - php-text-password - same I/O error - phpmd - there are two versions, the newer 2.8.1-2 failed on the same I/O error => Rbasak offered to take a look at these, he'll reply to this mail later Class II: - doctrine/2.6.4-1 -> need 2.7.1-1 from proposed together with new php-defaults (I triggered that for now) - php-codecoverage -> need 7.0.10+dfsg-1 from proposed together with new php-defaults (I triggered that for now) - phpunit-global-state -> need 3.0.0-2build3 from proposed together with new php-defaults (I triggered that for now) Class III: - php-http-request2 - PHP Fatal error: Declaration of HTTP_Request2_Adapter_CommonNetworkTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in /tmp/autopkgtest.Ih0Z0B/build.kMc/src/HTTP_Request2-2.3.0/tests/Request2/Adapter/CommonNetworkTest.php on line 5 (no idea yet) - php-net-ldap2 - same as the error in php-http-request2 => TODO Class III issues are still open and free for grabbing by anyone @bryce - please take note of a few things: - packages we needed to trigger with like `phpunit-global-state` eventually have to be in focal to have everything work together correctly. - In general `phpunit` and its dependent tests in update-excuses might need a session on its own to unblock all of php*. P.S: Can I mention that it is confusing (for me) that php-defaults (73ubuntu1) is doing the transition to php 7.4 :-) I realized it is just a sequential number, but at an inconvenient coincidence :-) -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
-- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
