Re: proposed migration duty - special php edition
Hi, On Tue, Mar 10, 2020 at 2:42 PM Andreas Hasenack wrote: > > Hello, > > On Tue, Mar 10, 2020 at 3:32 AM Bryce Harrington > wrote: > > > * uwsgi-plugin-php: I *think* this merely needs a no-change rebuild, > > > but it's a really oddball package that is somehow generated as a > > > subpackage from uwsgi-src. I asked for advice on #ubuntu-devel. > > > How the heck do we build this??? > > > > Andreas squared this away. I approved his MP but wasn't sure if there > > was another tweak he wanted to do, so held off uploading it. But maybe > > it can go in now. > > I uploaded it, and it's already built and in the excuses page. libsoup2.4 failed, but the right combination of triggers made it pass (I tested with s390x). I now repeated that for the other architectures. -- 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
Hello, On Tue, Mar 10, 2020 at 3:32 AM Bryce Harrington wrote: > > * uwsgi-plugin-php: I *think* this merely needs a no-change rebuild, > > but it's a really oddball package that is somehow generated as a > > subpackage from uwsgi-src. I asked for advice on #ubuntu-devel. > > How the heck do we build this??? > > Andreas squared this away. I approved his MP but wasn't sure if there > was another tweak he wanted to do, so held off uploading it. But maybe > it can go in now. I uploaded it, and it's already built and in the excuses page. -- 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
> > * uwsgi-plugin-php: I *think* this merely needs a no-change rebuild, > > * php-mailparse: Cjwatson helped me diagnose this. It seems to be just Both of these have migrated, and with that the (ben) transition board is now all-green: https://people.canonical.com/~ubuntu-archive/transitions/html/html/html/php7.4.html While there's still details left to take care of, I'm going to call this completion of the "formal" milestone, and start closing bugs and cards and such. > > * php-defaults: php-recode/amd64 => unsatisfiable > > > > 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 > > > > - Based on the discussion with Debian quoted previously in this thread, > > php-recode need to be removed from these two packages. > > I've done this change for fusiondirectory. If that MP looks good, then > tomorrow I can do gosa the same way (unless someone beats me to it...) It did work, and I've uploaded both fusiondirectory and gosa. With those two changes, I *think* php-defaults should be clear to migrate. With that migrated, we're "technically" done with the transition. The rest of the list below is a different priority level. In at least some cases, I think they are wrapped up in the icu transition. > > * phpunit > > > > => 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 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. > > > > - I did a retrigger against the 12 failed packages, with > > all-proposed=1, but no dice, still same packages fail. > > - The excuses page mentions php-codecoverage and phpunit-globalstate > > - This needs more investigation > > Still TODO > > > * php-horde-* > > > 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 > > > > - Some progress has been made getting these rebuilt for 7.4, but looks > > like additional work is needed. They might need retriggered against > > phpunit and other things, or may need no-change rebuilds > > Excuses lists "Test in progress". > > > * php-text-password migration - still building against php7.3 > > - Looks like it passed run with all-proposed=1 for phpunit but is > > still blocked in migration. > > - I've retriggered this, hoping our recent progress has cleared its > > dependencies. I ran it without all-proposed, but with triggers > > against the proposed phpunit and php7.4. > > Doesn't look like the above did it. > Still TODO > > > * php-redis / php-mockery > > - Doesn't block the php migration, but may be affected by it > > - php-mockery probably needs a no-change rebuild. > > Still TODO > > > * php-text-captcha > > - Doesn't block the php migration, but may be affected by it > > - php-text-captcha has no binaries on any arch > > - Maybe this one just needs dropped? > > Still TODO > > > * doctrine / php-doctrine-cache > > - Doesn't block the php migration, but may be affected by it > > - says "Invalidated by dependency" > > - There's a number of *doctrine* packages that may be caught up in > > this. > > Still TODO > > > * symfony / php-symfony* > > - Doesn't block the php migration, but may be affected by it > > - Bunch of missing builds; not sure what this needs, but guessing it's > > another "one kick in the right spot" type of thing > > Still TODO > > > * php-lorenzo-pinky > > - Doesn't block the php migration, but may be affected by it > > Still TODO > > Bryce 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
Re: proposed migration duty - special php edition
On Sat, Mar 07, 2020 at 08:34:12AM -0800, Bryce Harrington wrote: > On Tue, Mar 03, 2020 at 11:01:54PM -0800, Bryce Harrington wrote: > > 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: > > I'm going to try to summarize as many of the outstanding issues as I > know about currently. This is in rough order of priority as I view it. > > > * uwsgi-plugin-php: I *think* this merely needs a no-change rebuild, > but it's a really oddball package that is somehow generated as a > subpackage from uwsgi-src. I asked for advice on #ubuntu-devel. > How the heck do we build this??? Andreas squared this away. I approved his MP but wasn't sure if there was another tweak he wanted to do, so held off uploading it. But maybe it can go in now. > * php-mailparse: Cjwatson helped me diagnose this. It seems to be just > a rotten tarball, that needs to be re-packed with '.orig' removed from > its name, and re-uploaded. I repacked this with a differently named tarball and uploaded. > * php-defaults: php-recode/amd64 => unsatisfiable > > > 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 > > - Based on the discussion with Debian quoted previously in this thread, > php-recode need to be removed from these two packages. I've done this change for fusiondirectory. If that MP looks good, then tomorrow I can do gosa the same way (unless someone beats me to it...) > * phpunit > > > => 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 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. > > - I did a retrigger against the 12 failed packages, with > all-proposed=1, but no dice, still same packages fail. > - The excuses page mentions php-codecoverage and phpunit-globalstate > - This needs more investigation Still TODO > * php-text-password migration - still building against php7.3 > - Looks like it passed run with all-proposed=1 for phpunit but is > still blocked in migration. > - I've retriggered this, hoping our recent progress has cleared its > dependencies. I ran it without all-proposed, but with triggers > against the proposed phpunit and php7.4. Doesn't look like the above did it. Still TODO > * php-horde-* > > 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 > > - Some progress has been made getting these rebuilt for 7.4, but looks > like additional work is needed. They might need retriggered against > phpunit and other things, or may need no-change rebuilds Excuses lists "Test in progress". > * php-redis / php-mockery > - Doesn't block the php migration, but may be affected by it > - php-mockery probably needs a no-change rebuild. Still TODO > * php-text-captcha > - Doesn't block the php migration, but may be affected by it > - php-text-captcha has no binaries on any arch > - Maybe this one just needs dropped? Still TODO > * doctrine / php-doctrine-cache > - Doesn't block the php migration, but may be affected by it > - says "Invalidated by dependency" > - There's a number of *doctrine* packages that may be caught up in > this. Still TODO > * symfony / php-symfony* > - Doesn't block the php migration, but may be affected by it > - Bunch of missing builds; not sure what this needs, but guessing it's > another "one kick in the right spot" type of thing Still TODO > * php-lorenzo-pinky > - Doesn't block the php migration, but may be affected by it Still TODO 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
Re: proposed migration duty - special php edition
On Mon, Mar 09, 2020 at 02:24:27PM -0300, Andreas Hasenack wrote: > On Sat, Mar 7, 2020 at 1:37 PM Bryce Harrington > wrote: > > * symphony / php-symphony* > > - Doesn't block the php migration, but may be affected by it > > - Bunch of missing builds; not sure what this needs, but guessing it's > > another "one kick in the right spot" type of thing > I don't see symphony or php-symphony in ubuntu since karmic > (https://launchpad.net/ubuntu/+source/symphony/+publishinghistory), > where are you seeing these problems? symfony :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Hi, On Sat, Mar 7, 2020 at 1:37 PM Bryce Harrington wrote: > * symphony / php-symphony* > - Doesn't block the php migration, but may be affected by it > - Bunch of missing builds; not sure what this needs, but guessing it's > another "one kick in the right spot" type of thing I don't see symphony or php-symphony in ubuntu since karmic (https://launchpad.net/ubuntu/+source/symphony/+publishinghistory), where are you seeing these problems? -- 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 11:01:54PM -0800, Bryce Harrington wrote: > 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: I'm going to try to summarize as many of the outstanding issues as I know about currently. This is in rough order of priority as I view it. * uwsgi-plugin-php: I *think* this merely needs a no-change rebuild, but it's a really oddball package that is somehow generated as a subpackage from uwsgi-src. I asked for advice on #ubuntu-devel. How the heck do we build this??? * php-mailparse: Cjwatson helped me diagnose this. It seems to be just a rotten tarball, that needs to be re-packed with '.orig' removed from its name, and re-uploaded. * php-defaults: php-recode/amd64 => unsatisfiable > > 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 - Based on the discussion with Debian quoted previously in this thread, php-recode need to be removed from these two packages. * phpunit > > => 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 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. - I did a retrigger against the 12 failed packages, with all-proposed=1, but no dice, still same packages fail. - The excuses page mentions php-codecoverage and phpunit-globalstate - This needs more investigation * php-text-password migration - still building against php7.3 - Looks like it passed run with all-proposed=1 for phpunit but is still blocked in migration. - I've retriggered this, hoping our recent progress has cleared its dependencies. I ran it without all-proposed, but with triggers against the proposed phpunit and php7.4. * php-horde-* > 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 - Some progress has been made getting these rebuilt for 7.4, but looks like additional work is needed. They might need retriggered against phpunit and other things, or may need no-change rebuilds * php-redis / php-mockery - Doesn't block the php migration, but may be affected by it - php-mockery probably needs a no-change rebuild. * php-text-captcha - Doesn't block the php migration, but may be affected by it - php-text-captcha has no binaries on any arch - Maybe this one just needs dropped? * doctrine / php-doctrine-cache - Doesn't block the php migration, but may be affected by it - says "Invalidated by dependency" - There's a number of *doctrine* packages that may be caught up in this. * symphony / php-symphony* - Doesn't block the php migration, but may be affected by it - Bunch of missing builds; not sure what this needs, but guessing it's another "one kick in the right spot" type of thing * php-lorenzo-pinky - Doesn't block the php migration, but may be affected by it -- 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 - v2
On Thu, Mar 5, 2020 at 6:01 AM Bryce Harrington < bryce.harring...@canonical.com> wrote: > On Wed, Mar 04, 2020 at 04:45:12PM +0100, Christian Ehrhardt wrote: > > Synced again with Bryce and Rbasak on the php-trasks-of-the-day to help. > > The following summarizes the work one and the state we left it so Bryce > can > > continue on it. > > Today I did zeroc-ice and uwsgi-plugin-php, which should hopefully get > the transition tracker down to one package: > > > https://people.canonical.com/~ubuntu-archive/transitions/html/html/html/php7.4.html > > The last package, php-mailparse, is the one with the weird .orig.orig > situation. Guessing there's a way to workaround that, just have to > figure out what that might be. > > > I've got quite some stuff done, but the very busy autopkgtest queue > stalls > > further progress right now > > > > --- > > > > #1 PHPUnit test issues in proposed migration > > - Upload phpunit and dependent fixes as identified by rbasak and me > > - Rbasak uploaded > > https://launchpad.net/ubuntu/+source/phpunit/8.5.2-1ubuntu1 > > - Then later (Depending on the former) I uploaded > > https://launchpad.net/ubuntu/+source/php-net-ldap2/2.2.0-3ubuntu3 > > > https://launchpad.net/ubuntu/+source/php-http-request2/2.3.0-1ubuntu2 > > - Depends on php-codecoverage and phpunit-global-state which after the > > efforts yesterday are both good to go (test-wise). > > - The next step would be triggering test cases with the right > components > > together. > > Actually for a first shot let's use all-proposed=1 on those. > > But for now the tests are still running, need to wait for the results > > first and then trigger those failing. > > > > TODO wait for tests to complete the first time, then trigger the failing > > ones wirth all-proposed (or global-state + php7.4 + phpunit + ..?) > > The failing ones are: > > Recheck - Still failing: composer doctrine pdepend php-codecoverage Tests didn't run yet: php-masterminds-html5 php-mikey179-vfsstream php-sabredav php-tijsverkoyen-css-to-inline-styles phpunit-comparator phpunit-global-state => Those need to be looked after, if there is a break in Fra I'll do so and let you know what I find. Failing in old, but working in the new version that I uploaded yesterday: php-httprequest2 php-net-ldap2 I've done these triggers, will recheck those later as well. > I've just now retriggered these with: > > dependencies=( > ["phpunit"]="8.5.2-1ubuntu1", > ["php7.4"]="7.4.3-4build2" > ) > > > > --- > > > > #Info > > - For bonus confusion there also is a rebuild of php7.3 ongoing at the > > moment. Also php7.4 was rebuilt (due to the ICU transition) > > => https://launchpad.net/ubuntu/+source/php7.3/7.3.15-3build1 > > => https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4build2 > > So test lists will be testing 7.4/7.3 stay sharp which one you actually > > look at. > > @Bryce the intention is to remove 7.4 before Focal releases right? > > If by 7.4 you mean 7.3, then yes that's the plan. :-) > > It looks like php7.4 is in main now, so I think once php-mailparse is > squared away I could file for the php7.2 removal. If by 7.2 you mean 7.3 then that sounds good :-) Sorry couldn't resist :-P > Tomorrow maybe. > > > --- > > > > #2 php-horde ?? > > - Look at php-horde-* if they need something > > Bryce asked for the following: > > - 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 > > => All of them passed migration, and the tests on php7.[34] are reset > we > > have to wait until those complete > > > > Looking at these I found in update excuses that the following two are > > hanging since 130 days. Mostly php and phpunit version issues - time to > > re-test them with the new versions we have in proposed. > > - php-horde-icalendar > > - php-horde-image > > > > TODO check new results once the new tests ran > > Thanks for tending these. > > > --- > > > > #4 Check FTBFS of php-msgpack > > Upload was from: > > > > > https://code.launchpad.net/~bryce/ubuntu/+source/php-msgpack/+git/php-msgpack/+merge/379773 > > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu1 > > Breaks on arm64 armhf > > Failed: Profiling perf test. [tests/035.phpt] > > Didn't I fix or at least write about that test recently? > > Yeah I had done so in: > > > https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html > > I already had an analysis and a fix there. > > After asking for review I got by Rafael and then uploaded the fix. > > It built fine at > > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu2 > > > > @Bryce - that should properly build now and resolve whatever you wanted > > to sove > > with the initial merge of that new version > > Great, thanks! > > > --- > > > > #5 rebuilds for
Re: proposed migration duty - special php edition - v2
On Wed, Mar 04, 2020 at 04:45:12PM +0100, Christian Ehrhardt wrote: > Synced again with Bryce and Rbasak on the php-trasks-of-the-day to help. > The following summarizes the work one and the state we left it so Bryce can > continue on it. Today I did zeroc-ice and uwsgi-plugin-php, which should hopefully get the transition tracker down to one package: https://people.canonical.com/~ubuntu-archive/transitions/html/html/html/php7.4.html The last package, php-mailparse, is the one with the weird .orig.orig situation. Guessing there's a way to workaround that, just have to figure out what that might be. > I've got quite some stuff done, but the very busy autopkgtest queue stalls > further progress right now > > --- > > #1 PHPUnit test issues in proposed migration > - Upload phpunit and dependent fixes as identified by rbasak and me > - Rbasak uploaded > https://launchpad.net/ubuntu/+source/phpunit/8.5.2-1ubuntu1 > - Then later (Depending on the former) I uploaded > https://launchpad.net/ubuntu/+source/php-net-ldap2/2.2.0-3ubuntu3 > https://launchpad.net/ubuntu/+source/php-http-request2/2.3.0-1ubuntu2 > - Depends on php-codecoverage and phpunit-global-state which after the > efforts yesterday are both good to go (test-wise). > - The next step would be triggering test cases with the right components > together. > Actually for a first shot let's use all-proposed=1 on those. > But for now the tests are still running, need to wait for the results > first and then trigger those failing. > > TODO wait for tests to complete the first time, then trigger the failing > ones wirth all-proposed (or global-state + php7.4 + phpunit + ..?) The failing ones are: composer doctrine pdepend php-codecoverage php-httprequest2 php-masterminds-html5 php-mikey179-vfsstream php-net-ldap2 php-sabredav php-tijsverkoyen-css-to-inline-styles phpunit-comparator phpunit-global-state I've just now retriggered these with: dependencies=( ["phpunit"]="8.5.2-1ubuntu1", ["php7.4"]="7.4.3-4build2" ) > --- > > #Info > - For bonus confusion there also is a rebuild of php7.3 ongoing at the > moment. Also php7.4 was rebuilt (due to the ICU transition) > => https://launchpad.net/ubuntu/+source/php7.3/7.3.15-3build1 > => https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4build2 > So test lists will be testing 7.4/7.3 stay sharp which one you actually > look at. > @Bryce the intention is to remove 7.4 before Focal releases right? If by 7.4 you mean 7.3, then yes that's the plan. :-) It looks like php7.4 is in main now, so I think once php-mailparse is squared away I could file for the php7.2 removal. Tomorrow maybe. > --- > > #2 php-horde ?? > - Look at php-horde-* if they need something > Bryce asked for the following: > - 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 > => All of them passed migration, and the tests on php7.[34] are reset we > have to wait until those complete > > Looking at these I found in update excuses that the following two are > hanging since 130 days. Mostly php and phpunit version issues - time to > re-test them with the new versions we have in proposed. > - php-horde-icalendar > - php-horde-image > > TODO check new results once the new tests ran Thanks for tending these. > --- > > #4 Check FTBFS of php-msgpack > Upload was from: > > https://code.launchpad.net/~bryce/ubuntu/+source/php-msgpack/+git/php-msgpack/+merge/379773 > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu1 > Breaks on arm64 armhf > Failed: Profiling perf test. [tests/035.phpt] > Didn't I fix or at least write about that test recently? > Yeah I had done so in: > https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html > I already had an analysis and a fix there. > After asking for review I got by Rafael and then uploaded the fix. > It built fine at > https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu2 > > @Bryce - that should properly build now and resolve whatever you wanted > to sove > with the initial merge of that new version Great, thanks! > --- > > #5 rebuilds for migration of php7.4 > - Those are no-change rebuilds by Byce, check build results and migration: > - php-cache-lite => build ok => still waiting in queue migrated! > - php-db => build ok => still waiting in queue migrated! > - php-text-password => build ok => fails with old phpunit, triggered with > new one 1.2.1-4ubuntu1 still in proposed. Still pulling 7.3 stuff. Maybe worth trying again after some of the other things finish migrating, otherwise just need to see which of its dependencies is still in proposed... php7.3-mbstring php-mbstring php-doctrine-instantiator php-deepcopy php-phar-io-version php-phar-io-manifest php-
proposed migration duty - special php edition - v2
Synced again with Bryce and Rbasak on the php-trasks-of-the-day to help. The following summarizes the work one and the state we left it so Bryce can continue on it. I've got quite some stuff done, but the very busy autopkgtest queue stalls further progress right now --- #1 PHPUnit test issues in proposed migration - Upload phpunit and dependent fixes as identified by rbasak and me - Rbasak uploaded https://launchpad.net/ubuntu/+source/phpunit/8.5.2-1ubuntu1 - Then later (Depending on the former) I uploaded https://launchpad.net/ubuntu/+source/php-net-ldap2/2.2.0-3ubuntu3 https://launchpad.net/ubuntu/+source/php-http-request2/2.3.0-1ubuntu2 - Depends on php-codecoverage and phpunit-global-state which after the efforts yesterday are both good to go (test-wise). - The next step would be triggering test cases with the right components together. Actually for a first shot let's use all-proposed=1 on those. But for now the tests are still running, need to wait for the results first and then trigger those failing. TODO wait for tests to complete the first time, then trigger the failing ones wirth all-proposed (or global-state + php7.4 + phpunit + ..?) --- #Info - For bonus confusion there also is a rebuild of php7.3 ongoing at the moment. Also php7.4 was rebuilt (due to the ICU transition) => https://launchpad.net/ubuntu/+source/php7.3/7.3.15-3build1 => https://launchpad.net/ubuntu/+source/php7.4/7.4.3-4build2 So test lists will be testing 7.4/7.3 stay sharp which one you actually look at. @Bryce the intention is to remove 7.4 before Focal releases right? --- #2 php-horde ?? - Look at php-horde-* if they need something Bryce asked for the following: - 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 => All of them passed migration, and the tests on php7.[34] are reset we have to wait until those complete Looking at these I found in update excuses that the following two are hanging since 130 days. Mostly php and phpunit version issues - time to re-test them with the new versions we have in proposed. - php-horde-icalendar - php-horde-image TODO check new results once the new tests ran --- #4 Check FTBFS of php-msgpack Upload was from: https://code.launchpad.net/~bryce/ubuntu/+source/php-msgpack/+git/php-msgpack/+merge/379773 https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu1 Breaks on arm64 armhf Failed: Profiling perf test. [tests/035.phpt] Didn't I fix or at least write about that test recently? Yeah I had done so in: https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html I already had an analysis and a fix there. After asking for review I got by Rafael and then uploaded the fix. It built fine at https://launchpad.net/ubuntu/+source/php-msgpack/2.1.0beta1-0ubuntu2 @Bryce - that should properly build now and resolve whatever you wanted to sove with the initial merge of that new version --- #5 rebuilds for migration of php7.4 - Those are no-change rebuilds by Byce, check build results and migration: - php-cache-lite => build ok => still waiting in queue - php-db => build ok => still waiting in queue - php-text-password => build ok => fails with old phpunit, triggered with new one - phpmd => wasn't uploaded! => last build on 7.3 at 2020-02-24 => uploaded it now - php-imagick => already built against 7.4 on 2020-02-28 TODO check results again later once the queue was drained -- 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 03, 2020 at 11:01:54PM -0800, Bryce Harrington wrote:
> On Tue, Mar 03, 2020 at 12:38:08PM +0100, Christian Ehrhardt wrote:
>
> 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
And the recode package in PECL is not really maintained at the moment, so I
would recommend
just dropping it.
The src gosa has:
samba/personal/samba/class_sambaMungedDial.inc: if
(function_exists("recode")){
samba/personal/samba/class_sambaMungedDial.inc: $utfName=
recode("ISO8859-15..UTF-16",
$paramName);
so it’s safe to drop the dependency
and the same class_sambaMungedDial.inc is in fusiondirectory.
I would not shed a single tear about this :-)
Ondrej
--
So looks like we can safely drop.
Bryce
> > [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
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
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
