On Tue, Mar 03, 2020 at 12:38:08PM +0100, Christian Ehrhardt wrote: > 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
Great analysis work, thanks Christian and Robie. phpunit was a familiar face in the 7.3 transition, so no surprise that there's some hiccups with it. The signature changes and handling of 'void' types affected several packages last go-around, and guess a few remain to be shaked out. The patches from last transition may be of some help. > [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. How weird... > => 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 ... That's probably a good suggestion to check with Debian first on this, I'll do that. > [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 Excellent. > [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 Yeah that's an unfortunate version number. :-D > => 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 Thanks again for all that. Sounds like this will bring us much closer to 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 Permissions error maybe? > 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) These weren't included in the ben report. (I wonder if we need a similar tool to identify packages like these that maybe don't need a no-change rebuild but do need a retrigger.) If the triggers don't clear these, then I bet a no-change rebuild would do the trick. > 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 Yep, this is caused by a change in 'void' semantics. Andreas and I dealt with a some of these last transition. > @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*. By session do you mean retriggering all of the packages with a newer phpunit? > 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 :-) Hah, I hadn't even noticed that but you're right. :-) Bryce > -- > 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