proposed migration duty - special php edition
Bryce Harrington
bryce at canonical.com
Tue Mar 3 18:30:04 UTC 2020
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
More information about the ubuntu-server
mailing list