proposed migration duty - special php edition

[Bryce Harrington]

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] <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