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] <bryce> + 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] <bryce> + exim4 - retriggered (E: Can not write log (Is
> => Your retrigger worked
\o/
> [07:09] <bryce> + 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] <bryce> + 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] <bryce> + php-horde-lz4 (TestCase::setUp() -- looks familiar)
> And another case of "Class 'DOMDocument' not found"
> Trying the same fix with a php-defaults retrigger.
> Results look good, triggered on all architectures now.
> => Results good - all done
\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://launchpadlibrarian.net/466792067/buildlog_ubuntu-focal-amd64.php-imagick_3.4.4-3ubuntu1_BUILDING.txt.gz
I wonder if phpunit only tries to write to that cache when there are
failures. That would make the error message a bit of a red herring
(although still worth fixing).
Again though, looking at the logs for these packages, I notice a lot of
php7.3 and php7.2 and phpunit7... So easy guess is these all just need
rebuilds. I've queued rebuilds for:
- php-cache-lite
- php-db
- php-text-password
- phpmd
If you could, please check later that these all migrate ok.
I didn't look at php-imagick (I think it's migrated ok now?)
> Class II:
> - doctrine/2.6.4-1 -> need 2.7.1-1 from proposed together with new
> php-defaults (I triggered that for now)
> - php-codecoverage -> need 7.0.10+dfsg-1 from proposed together with new
> php-defaults (I triggered that for now)
> - phpunit-global-state -> need 3.0.0-2build3 from proposed together with
> new php-defaults (I triggered that for now)
It looks like the triggers weren't sufficient, they're still on the
excuses page. Looking at the logs they mention php7.3 so probably all
need no-change rebuilds.
If you agree, but don't get a chance to file the rebuilds I'll do it on
my workday tomorrow.
> 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
Nish had to patch this for PHPUnit6 compatibility.
Possibly it just needs a no-change rebuild. There's no new version in
Debian so maybe that's all it needs? I'm surprised Debian didn't pick
up Nish's patch by now.
> @bryce - please take note of a few things:
> - packages we needed to trigger with like `phpunit-global-state` eventually
> have to be in focal to have everything work together correctly.
> - In general `phpunit` and its dependent tests in update-excuses might need
> a session on its own to unblock all of php*.
Like I mentioned above, I notice ben does not make mention of a lot of
the packages in this list. Same thing happened last time too. I think
ben is insufficient. I am maintaining a separate package list but it's
just manually updated. It'd be nice to have a more reliable way to get
a more comprehensive listing of packages needing rebuilt, whether via
ben or some other way. But, if we're only doing this once a year it may
just be something we have to slog through manually each time.
Anyway, thanks again!
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
