proposed migration duty - special php edition

[Bryce Harrington]

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