proposed migration duty - special php edition

Christian Ehrhardt christian.ehrhardt at
Tue Mar 3 11:38:08 UTC 2020

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)
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 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
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
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.
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.
--- 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
  -> 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
=> 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
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*.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ubuntu-server mailing list