Re: proposed migration duty - special php edition
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. I mostly indulged in non-PHP work today, but have some small updates: > [07:09] + php-defaults: php-recode/amd64 => unsatisfiable > Depends: php7.4-recode > Problem: php7.4-recode really doesn't exist in Ubuntu > => 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 ... I emailed the Debian php maintainer and asked their plans: > Hi Ondřej, > > We noticed that with php7.4 there seems to be a change in how php-recode > is packaged. It looks like it's no longer provided by php7.4, and we're > wondering if that is intended to be its own separate package, or if it's > intended to go away entirely? If the former, do you know there has > already been work to package it? Or, of the latter, it looks to us like > this would impact src:fusiondirectory and src:gosa, which presumably > would need dropped from the archive? I'm curious if you're aware of > this and if you have plans for dealing with it - our preference would be > to follow your plans here. Hi Bryce, recode extension has been unbundled from PHP: https://www.php.net/manual/en/intro.recode.php It should be fairly easy to package, but intl extension is so much better, so I am not sure it’s worth it. Ondrej > [07:09] + exim4 - retriggered (E: Can not write log (Is > => Your retrigger worked \o/ > [07:09] + xdebug (php-codecoverage, php-unit) > => Results good - all done \o/ > => But phpunit had further issues. > 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 > 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 I followed along the research and patch reviews, but don't have anything meaningful to add. Hope you and Robie get a chance to continue work on this; let me know if I can assist. I looked a bit at the new 9.0.1 release. It looks like it removes a fair bit of deprecated functionality. I think Robie's approach of cherrypicking the actual fix and leaving the merge until later, is the safest approach here. > [07:09] + php-memcache (php-doctrine-cache-bundle?) > => Results good - all done \o/ > - 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 It's just yet another case of php7.3 getting pulled in (first thing to look for, 99% of the time that's what it is). I've uploaded a no-change rebuild which should resolve this. I also added the package to my list for next go-around. (I don't know why ben doesn't flag packages like this one -- it should have been in its list...) > [07:09] + 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 \o/ Some other php-horde packages that might need attention: php-horde-nag php-horde-mnemo php-horde-lz4 php-horde-kronolith php-horde-imp php-horde-ansel php-horde-text-filter php-horde-mime I plan on looking at these, but if anyone wants to beat me, feel free. They may merely need no-change rebuilds. > 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 I've seen this in Debian's test logs too, e.g.: https://ci.debian.net/data/autopkgtest/unstable/amd64/p/php-imagick/4439426/log.gz Notably, we don't get that error message in our latest php-imagick build: https://launchpadlibraria
Re: proposed migration duty - special php edition
On Tue, Mar 03, 2020 at 03:07:42PM +0100, Christian Ehrhardt wrote: > On Tue, Mar 3, 2020 at 2:33 PM Robie Basak > wrote: > > > On Tue, Mar 03, 2020 at 12:38:08PM +0100, Christian Ehrhardt wrote: > > > 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 > > > > Debdiff for phpunit attached. Please review! > > > > LGTM, please add Origin to > https://salsa.debian.org/php-team/pear/phpunit/-/commit/4e3d1bb78a4da170467ebcb6a3c19e97e1d2220a > as mentioned on IRC > LGTM to me as well. Perhaps of note, this patch landed in Debian as part of the phpunit 9.0.1 packaging. https://salsa.debian.org/php-team/pear/phpunit/-/blob/31a9b77df17426f5a6f89149d32636ef8338b118/ChangeLog-9.0.md I saw in the bileto run there were a number of affected packages. When this lands in proposed would we need to retrigger all those against this? Bryce -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Proposed migration report for Tue 2020-03-03
# bind9, bind9-libs, isc-dhcp, debian-installer, bind-dyndb-ldap Stuck on debian-installer, which is stuck on linux, which has a block proposed tag: https://launchpad.net/bugs/1865025 # apache2, cacti Resolved via https://launchpad.net/ubuntu/+source/cacti/1.2.9+ds1-1ubuntu2 (bug #1865067: fix also sent upstream). Cacti mitigated, apache2 should follow (the cacti armhf test is green already, britney just didn't notice it yet). # ruby-defaults Big transition going on # munin I troubleshooted and think I found a class for one type of error. I filed https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1865938 with my findings. For now, I retried the test. There are more packages stuck, but this took quite some time already. More tomorrow. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Triage report for 2020-03-03 (bug touched on 2020-03-02)
Just this bug I wanted to highlight: LP: #1863749 - *+(Triaged) [strongswan] - NTRU Plugin Missing in Focal If someone has experience with the NTRU plugin, please chime in on the bug, as we need to gather reasons to have it enabled again and included in Focal as a Feature Freeze Exception. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed migration duty - special php edition
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] bryce: any emergency php things to look into? > [07:08] 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] + 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] + 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] + 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] + 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 >
Re: proposed migration duty - special php edition
On Tue, Mar 3, 2020 at 3:41 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Tue, Mar 3, 2020 at 3:08 PM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
>>
>>
>> On Tue, Mar 3, 2020 at 12:38 PM Christian Ehrhardt <
>> christian.ehrha...@canonical.com> wrote:
>> ...
>>
>>> 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
>>>
>>
>> Taking a first look at these now ...
>>
>
>
> Note: both packages are rather rarely updated. Both still refer to git://
> anonscm.debian.org
>
> Note: There is an old patch `phpunit6_compatibility.patch` that touches
> the offending file already.
>
> The code extends phpunit:
> abstract class HTTP_Request2_Adapter_CommonNetworkTest extends
> PHPUnit\Framework\TestCase
>
> This is defined in phpunit src/Framework/TestCase.php:
> 416 protected function setUp(): void
>
> 417 {
>
> 418 }
>
> vs
>
> 122 protected function setUp()
>
>
> Ok, it seems the :void type was added and needs to be adapted for.
>
> Trying to recreate the same in a local VM works, so we can iterate in
> there.
>
> The tests will succeed if we just append the : void as needed.
>
> But it becomes clear that they will need more work later.
> The result is RC==0 but showing a lot of:
> The @expectedException, @expectedExceptionCode, @expectedExceptionMessage,
> and @expectedExceptionMessageRegExp annotations are deprecated. They will
> be removed in PHPUnit 9. Refactor your test to use expectException(),
> expectExceptionCode(), expectExceptionMessage(), or
> expectExceptionMessageRegExp() instead.
>
> We also now hit the issue rbasak looked at and has a debdiff attached.
> => PHP Warning: file_put_contents(/usr/bin/.phpunit.result.cache): failed
> to open stream: Permission denied in
> /usr/share/php/PHPUnit/Runner/DefaultTestResultCache.php on line 108
>
> The root cause change in phpunit can be seen here
>
> https://github.com/sebastianbergmann/phpunit/commit/f5e5add13e73933c65878f53d5a94cdc0f120cc4
> and explained here
> https://github.com/sebastianbergmann/phpunit/issues/3288
> https://phpunit.de/announcements/phpunit-7.html
>
> Here are two debdiffs for bryce to consider.
> They will need the debdiff that Rbasak provided in -proposed first.
>
I've started test builds and will later trigger tests in
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3963/+packages
https://bileto.ubuntu.com/#/ticket/3963
I already found that php-net-ldap2 needed a v2 which is attached here:
P.S. The projects seem dormant, not sure if upstreaming is worth. Both
> compat v6 and v7 patches are not usptreamed either. The way it is we can
> retain them ... for now.
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
fix-phpunit8.5-php-net-ldap2-v2.debdiff
Description: Binary data
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed migration duty - special php edition
On Tue, Mar 3, 2020 at 3:08 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Tue, Mar 3, 2020 at 12:38 PM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
> ...
>
>> 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
>>
>
> Taking a first look at these now ...
>
Note: both packages are rather rarely updated. Both still refer to git://
anonscm.debian.org
Note: There is an old patch `phpunit6_compatibility.patch` that touches the
offending file already.
The code extends phpunit:
abstract class HTTP_Request2_Adapter_CommonNetworkTest extends
PHPUnit\Framework\TestCase
This is defined in phpunit src/Framework/TestCase.php:
416 protected function setUp(): void
417 {
418 }
vs
122 protected function setUp()
Ok, it seems the :void type was added and needs to be adapted for.
Trying to recreate the same in a local VM works, so we can iterate in there.
The tests will succeed if we just append the : void as needed.
But it becomes clear that they will need more work later.
The result is RC==0 but showing a lot of:
The @expectedException, @expectedExceptionCode, @expectedExceptionMessage,
and @expectedExceptionMessageRegExp annotations are deprecated. They will
be removed in PHPUnit 9. Refactor your test to use expectException(),
expectExceptionCode(), expectExceptionMessage(), or
expectExceptionMessageRegExp() instead.
We also now hit the issue rbasak looked at and has a debdiff attached.
=> PHP Warning: file_put_contents(/usr/bin/.phpunit.result.cache): failed
to open stream: Permission denied in
/usr/share/php/PHPUnit/Runner/DefaultTestResultCache.php on line 108
The root cause change in phpunit can be seen here
https://github.com/sebastianbergmann/phpunit/commit/f5e5add13e73933c65878f53d5a94cdc0f120cc4
and explained here
https://github.com/sebastianbergmann/phpunit/issues/3288
https://phpunit.de/announcements/phpunit-7.html
Here are two debdiffs for bryce to consider.
They will need the debdiff that Rbasak provided in -proposed first.
P.S. The projects seem dormant, not sure if upstreaming is worth. Both
compat v6 and v7 patches are not usptreamed either. The way it is we can
retain them ... for now.
fix-phpunit8.5-php-http-request2.debdiff
Description: Binary data
fix-phpunit8.5-php-net-ldap2.debdiff
Description: Binary data
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed migration duty - special php edition
On Tue, Mar 3, 2020 at 12:38 PM Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: ... > 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 > Taking a first look at these now ... -- 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
Re: proposed migration duty - special php edition
On Tue, Mar 3, 2020 at 2:33 PM Robie Basak wrote: > On Tue, Mar 03, 2020 at 12:38:08PM +0100, Christian Ehrhardt wrote: > > 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 > > Debdiff for phpunit attached. Please review! > LGTM, please add Origin to https://salsa.debian.org/php-team/pear/phpunit/-/commit/4e3d1bb78a4da170467ebcb6a3c19e97e1d2220a as mentioned on IRC -- 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
Re: proposed migration duty - special php edition
> ... > > => 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 > For the php-unit tests combining xdebug + php-defaults + phpunit-global-state + phpunit worked. Triggering that on all architectures now. => These tests are good now, done -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed migration duty - special php edition
On Tue, Mar 03, 2020 at 01:33:53PM +, Robie Basak wrote: > Debdiff for phpunit attached. Please review! I should add that I've tested phpunit build and autopkgtest locally on amd64 only, and php-cache-lite autopkgtest (without a build) locally against the local build of phpunit. signature.asc Description: PGP signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: proposed migration duty - special php edition
On Tue, Mar 03, 2020 at 12:38:08PM +0100, Christian Ehrhardt wrote:
> 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
Debdiff for phpunit attached. Please review!
diff -Nru phpunit-8.5.2/debian/changelog phpunit-8.5.2/debian/changelog
--- phpunit-8.5.2/debian/changelog 2020-01-09 12:09:16.0 +
+++ phpunit-8.5.2/debian/changelog 2020-03-03 12:20:47.0 +
@@ -1,3 +1,13 @@
+phpunit (8.5.2-1ubuntu1~ppa1) UNRELEASED; urgency=medium
+
+ * d/p/0003-Default-cache-location-to-current-directory.patch: cherry-pick
+from Debian VCS 4e3d1bb to change default cache location to the current
+directory. This stops phpunit failing by default when it tries to write to
+/usr/bin to fix autopkgtests of reverse dependencies. Closes: #951258.
+Thanks to Andrius Merkys.
+
+ -- Robie Basak Tue, 03 Mar 2020 12:20:47 +
+
phpunit (8.5.2-1) unstable; urgency=medium
[ Sebastian Bergmann ]
diff -Nru phpunit-8.5.2/debian/control phpunit-8.5.2/debian/control
--- phpunit-8.5.2/debian/control2020-01-09 12:07:53.0 +
+++ phpunit-8.5.2/debian/control2020-03-03 12:20:47.0 +
@@ -1,7 +1,8 @@
Source: phpunit
Section: php
Priority: optional
-Maintainer: Debian PHP PEAR Maintainers
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian PHP PEAR Maintainers
Uploaders: Prach Pongpanich ,
David Prévot
Build-Depends: debhelper-compat (= 12),
diff -Nru
phpunit-8.5.2/debian/patches/0003-Default-cache-location-to-current-directory.patch
phpunit-8.5.2/debian/patches/0003-Default-cache-location-to-current-directory.patch
---
phpunit-8.5.2/debian/patches/0003-Default-cache-location-to-current-directory.patch
1970-01-01 00:00:00.0 +
+++
phpunit-8.5.2/debian/patches/0003-Default-cache-location-to-current-directory.patch
2020-03-03 12:20:16.0 +
@@ -0,0 +1,20 @@
+From: Andrius Merkys
+Date: Sun, 16 Feb 2020 10:37:31 +0200
+Subject: Default cache location to current directory
+
+Bug-Debian: https://bugs.debian.org/951258
+---
+ src/TextUI/TestRunner.php | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/TextUI/TestRunner.php
b/src/TextUI/TestRunner.php
+@@ -157,7 +157,7 @@
+ if (isset($arguments['configuration']) &&
$arguments['configuration'] instanceof Configuration) {
+ $cacheLocation =
$arguments['configuration']->getFilename();
+ } else {
+-$cacheLocation = $_SERVER['PHP_SELF'];
++$cacheLocation = \getcwd() . \DIRECTORY_SEPARATOR .
'cache'; /* get around \dirname(...) */
+ }
+
+ $arguments['cacheResultFile'] = null;
diff -Nru phpunit-8.5.2/debian/patches/series
phpunit-8.5.2/debian/patches/series
--- phpunit-8.5.2/debian/patches/series 2020-01-09 12:07:44.0 +
+++ phpunit-8.5.2/debian/patches/series 2020-03-03 12:20:07.0 +
@@ -1,2 +1,3 @@
0001-Remove-Composer-autoload.patch
0002-phpunit.xsd-is-installed-in-usr-share-php-PHPUnit.patch
+0003-Default-cache-location-to-current-directory.patch
signature.asc
Description: PGP signature
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
proposed migration duty - special php edition
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] bryce: any emergency php things to look into? [07:08] not really, although there's a few things in migration that could be looked into [07:09] + 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] + 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] + 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] + 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] + 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-cac
