php-imagick failing autopkgtests

There was a third commit to magick/color.c, 68c6a7d, made last Nov 8 which appears to also pertain to this issue. Please update your diff to include this commit.

@Steve, updated the diff, thanks for catching that!

Note that even so, php-imagick won't pass the tests. I've got debdiff I'm testing now that will at least get it to run the tests correctly with phpunit. I'm seeing 3-4 segmentation faults that I can't fully figure out (but seems like sort of a well known issue with imagemagick and particularly, possibly, with php-imagick, which relies on having well-defined version numbering which Debian & Ubuntu break (backports applied without changing the version #)). I'm not sure the best way forward on this, but it does appear that Debian has the same issue, at least. And I'm working on narrowing down those failing tests and should have a final debdiff by tomorrow.

This bug was fixed in the package imagemagick - 8:6.8.9.9-7ubuntu1

---------------
imagemagick (8:6.8.9.9-7ubuntu1) xenial; urgency=medium

  * Add backports of d6054824, 95c8394e and 68c6a7d to
    0070-Fix-PixelColor-off-by-one-on-i386.patch (LP: #1549942)
    which were missed in "PixelColor off by one on i386
    (closes: #811308)
    https://github.com/ImageMagick/ImageMagick/issues/54".

 -- Nishanth Aravamudan <email address hidden> Thu, 25 Feb 2016 09:11:02 -0800

imagemagick (8:6.8.9.9-7ubuntu2) xenial; urgency=medium

  * Add backport of a54fe0e8 to fix segmentation faults during
    php-imagick tests (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Wed, 02 Mar 2016 15:45:35 -0800

php-imagick (3.4.0~rc6-1ubuntu2) xenial; urgency=medium

  * Fix failures in autopkgtests (LP: #1549942)
    - d/tests/control: run phpunit from tests/ subdirectory to pick up
      the SKIP helper.
    - d/tests/control: limit imagemagick to 1 thread to avoid openmp
      related segfaults.
    - d/tests/control: add gsfonts and libmagickcore-6.q16-2-extra as
      test dependencies.

 -- Nishanth Aravamudan <email address hidden> Wed, 24 Feb 2016 19:10:58 -0800

With the above two versions of imagemagick & php-imagick, the autopkgtests now succeed.

Hi Nish,

> - d/tests/control: limit imagemagick to 1 thread to avoid openmp
> related segfaults.

This implies that php-imagick doesn't work correctly unless MAGICK_THREAD_LIMIT=1 is set; which clearly will not be the case out of the box. So I don't consider this a valid workaround for test failures, as it implies the code will still segfault in production.

On Sun, Mar 6, 2016 at 12:57 AM, Steve Langasek
<email address hidden> wrote:
> Hi Nish,
>
>> - d/tests/control: limit imagemagick to 1 thread to avoid openmp
>> related segfaults.
>
> This implies that php-imagick doesn't work correctly unless
> MAGICK_THREAD_LIMIT=1 is set; which clearly will not be the case out of
> the box. So I don't consider this a valid workaround for test failures,
> as it implies the code will still segfault in production.

I'm actually following the recommendations upstream for php-imagick
(https://github.com/mkoppanen/imagick#openmp). I believe this is
already a known issue with the imagemagick/openmp code and the
php-imagick maintainer implies this is where they spend a lot of their
time (https://github.com/mkoppanen/imagick/issues/138).

The bug is in imagemagick, though, not in php-imagick. I agree it's a
non-ideal fix, but the alternative is for (in my testing) basically
every test to fail. I will spend some time on Monday debugging
imagemagick with the fixes already mentioned in this bug applied to
see if it is another simple missing backport.

Alternatively, php-imagick *could* change the configuration of
imagemagick when installed. But I don't think that is normal or
possibly even allowed by the Debian manual.

The underlying issue here is that php-imagick and imagemagick need to
be kept in sync -- any modification of one must be tested against the
other for regressions (and that is not currently done, afaict). So
when backports to imagemagick occur, they are self-consistent (as far
as imagemagick's own tests go), but consumers of the API seem to break
(php-imagick's tests).

On Sun, Mar 06, 2016 at 07:02:56PM -0000, Nish Aravamudan wrote:
> On Sun, Mar 6, 2016 at 12:57 AM, Steve Langasek
> <email address hidden> wrote:
> >> - d/tests/control: limit imagemagick to 1 thread to avoid openmp
> >> related segfaults.

> I'm actually following the recommendations upstream for php-imagick
> (https://github.com/mkoppanen/imagick#openmp). I believe this is
> already a known issue with the imagemagick/openmp code and the
> php-imagick maintainer implies this is where they spend a lot of their
> time (https://github.com/mkoppanen/imagick/issues/138).

The imagemagick code isn't what has changed here; php-imagick has changed.
The php-imagick package in xenial has passed its test suite with all recent
versions of imagemagick in the archive, but the new php-imagick (which
includes substantial code changes) is failing.

> The bug is in imagemagick, though, not in php-imagick.

First, this is not at all clear to me. Imagemagick is a widely used utility
and library; there have been no changes to the upstream version of
imagemagick included in Ubuntu since 15.04; and there are no reports of
segfaults with imagemagick outside of php-imagick (except for input
fuzzing). This suggests to me that this is not a bug in imagemagick at all,
but a misuse of the imagemagick API by php-imagick (possibly related to
competing threading implementations in PHP vs. libmagick).

Second, even should this be a bug that needs to be fixed in imagemagick, it
is the *combination* of imagemagick and php-imagick that is buggy. The test
suite is currently giving us a strong indication that whereas the current
php-imagick package is usable, upgrading to the new php-imagick package will
make it substantially less usable.

We should not make the test suite artificially pass if it's giving us
accurate information about the (non-)usability of the package. The only
reason to make this change to the test suite would be if the crasher bugs it
exposes are *not* real bugs and do not affect production use of the package.
This seems unlikely to be the case. But if you've analyzed the failures and
found this to be true, please let me know.

The other possibilities here are:

 - The old php-imagick in xenial is already buggy and crashes in the same
   way, but the testsuite for the old version of the package is
   insufficiently rigorous to pick up on it. In this case, it's appropriate
   to override the testsuite failures *in proposed-migration* to let the new
   package in because this is a test regression but not a functional
   regression.

 - The old php-imagick in xenial is not buggy in this way and this
   represents a real regression in the runtime behavior of the package. In
   this case, either we need a real fix to the code, so that the testsuite
   passes *without* a testsuite-specific workaround; or we should to remove
   the php-imagick package from xenial as too-buggy-to-live, and let it back
   in only when it's resolved.

 - The old php-imagick in xenial is not buggy, this is a real regression in
   the runtime behavior, the package cannot be removed (because it has too
   many reverse dependencies), and we can't fix the runtime b...

> I've had a look at the ImageMagick code to see what MAGICK_THREAD_LIMIT=1
> does, and see that the same thing can be accomplished programmatically by
> calling SetMagickResourceLimit(ThreadResource, 1). I believe that invoking
> this from the php-imagick MINIT function should be sufficient to get correct
> behavior at runtime, not just in the testsuite; I will prepare a patch here
> for testing.

Confirmed that this gives a passing testsuite without having to modify the environment of the testsuite alone. Please find the final debdiff attached for your reference.

On 07.03.2016 [03:57:59 -0000], Steve Langasek wrote:
> On Sun, Mar 06, 2016 at 07:02:56PM -0000, Nish Aravamudan wrote:
> > On Sun, Mar 6, 2016 at 12:57 AM, Steve Langasek
> > <email address hidden> wrote:
> > >> - d/tests/control: limit imagemagick to 1 thread to avoid openmp
> > >> related segfaults.
>
> > I'm actually following the recommendations upstream for php-imagick
> > (https://github.com/mkoppanen/imagick#openmp). I believe this is
> > already a known issue with the imagemagick/openmp code and the
> > php-imagick maintainer implies this is where they spend a lot of their
> > time (https://github.com/mkoppanen/imagick/issues/138).
>
> The imagemagick code isn't what has changed here; php-imagick has changed.
> The php-imagick package in xenial has passed its test suite with all recent
> versions of imagemagick in the archive, but the new php-imagick (which
> includes substantial code changes) is failing.

Right, you are correct that the variable here is php-imagick. Sorry for
mis-stating that earlier.

For reference, I'm actually not sure why, but Debian's version has been
failing for much longer
(https://ci.debian.net/packages/p/php-imagick/unstable/amd64/). And that
occurred with different versions of both php-imagick and imagemagick.

What can be happening here is that php-imagick relies on some behavior
(php-imagick upstream is ony tested against official imagemagick
releases) that is supposed to be present in some version of imagemagick
(checked by version string). Debian/Ubuntu backport patches that alter
functionality but do not bump the version string and that can lead to
php-imagick not doing the right thing. I'm not sure if that is the case
currently.

> > The bug is in imagemagick, though, not in php-imagick.
>
> First, this is not at all clear to me. Imagemagick is a widely used utility
> and library; there have been no changes to the upstream version of
> imagemagick included in Ubuntu since 15.04; and there are no reports of
> segfaults with imagemagick outside of php-imagick (except for input
> fuzzing). This suggests to me that this is not a bug in imagemagick at all,
> but a misuse of the imagemagick API by php-imagick (possibly related to
> competing threading implementations in PHP vs. libmagick).

Well, I am new to this, but my understanding of php-imagick is that
there have been many bugs fixed in imagemagick's memory handling (and
threading, possibly) due to php-imagick. Not all of those fixes are in
Debian & Ubuntu's imagemagick.

As indicated by my backports already in this bug (and in my latest),
there are clearly missing upstream changes that are needed in the
Debian/Ubuntu version of imagemagick (both an incomplete backport and a
(possibly) missing one). Note that if I hold php-imagick constant and
test against the two version of imagemagick (with and without my fixes),
I get different results (while upstream php-imagick against upstream
imagemagick does not see any issues) -- that to me indicates the bug is
missed fixes in imagemagick. So I'm not entirely sure whether it's a
misuse of an API (which seems like it'd be broken in upstream
php-imagick against our base version of imagema...

On Mon, Mar 07, 2016 at 05:09:06AM -0000, Nish Aravamudan wrote:
> Note that if I hold php-imagick constant and test against the two version
> of imagemagick (with and without my fixes), I get different results (while
> upstream php-imagick against upstream imagemagick does not see any issues)
> -- that to me indicates the bug is missed fixes in imagemagick.

Not knowing the details of upstream's testing, it could also be that the
upstream imagemagick build they're testing against doesn't have openmp
enabled?

> Again, I know that seems to be the case, but Debian's results imply
> something else. Are the launchpad sbuilds multi-cpu?

Yes, they are.

> Another big difference between the version of php-imagick, ignore
> functionality, is a huge increase in coverage tests. I belive
> php-imagick 3.3.0~rc2 only runs 27 tests, while 3.4.0~rc6 runs 251. More
> on this below.

Right, fair enough!

So the new php-imagick upload now passes its testsuite on amd64 and ppc64el,
but shows failures on i386, armhf and s390x

  http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/armhf
  http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/i386
  http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/s390x

Same test failure on i386 and s390x, and only 1 test failure instead of 20+.
Different failure on armhf (a test timeout - possibly a problem of the
architecture being slow rather than a bug in the code).

Is this a new test? Do you believe this test would fail with the previous
version of php-imagick as well? Should we bypass this test failure for now
to get php7 migrated?

On 07.03.2016 [06:38:45 -0000], Steve Langasek wrote:
> On Mon, Mar 07, 2016 at 05:09:06AM -0000, Nish Aravamudan wrote:
> > Note that if I hold php-imagick constant and test against the two version
> > of imagemagick (with and without my fixes), I get different results (while
> > upstream php-imagick against upstream imagemagick does not see any issues)
> > -- that to me indicates the bug is missed fixes in imagemagick.
>
> Not knowing the details of upstream's testing, it could also be that the
> upstream imagemagick build they're testing against doesn't have openmp
> enabled?

I think the upstream maintainer implied it is on, but I'm not 100%. I'll
see if I can see that setting in their CI.

Also, I forgot to mention this earlier, but the segmentation faults I
see are somehow racy -- that is, they don't happen on every execution.
And the upstream maintainer implied to me that this is actually quite
common, it seems like, in the shutdown routines in imagemagick -- and
that a common google-able workaround for Ubuntu is to recompile
imagemagick from source w/o openmp support :( They *are* more
reproducible for me under phpunit (as opposed to `make
tests`/run-tests.php), but still not consistent.

> > Again, I know that seems to be the case, but Debian's results imply
> > something else. Are the launchpad sbuilds multi-cpu?
>
> Yes, they are.

Ok, I wonder why the results are so different in Debian (and for me on
my laptop).

> > Another big difference between the version of php-imagick, ignore
> > functionality, is a huge increase in coverage tests. I belive
> > php-imagick 3.3.0~rc2 only runs 27 tests, while 3.4.0~rc6 runs 251. More
> > on this below.
>
> Right, fair enough!

Yeah, it's a (good, but) large difference in coverage.

> So the new php-imagick upload now passes its testsuite on amd64 and ppc64el,
> but shows failures on i386, armhf and s390x
>
> http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/armhf
> http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/i386
> http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/s390x
>
> Same test failure on i386 and s390x, and only 1 test failure instead of 20+.
> Different failure on armhf (a test timeout - possibly a problem of the
> architecture being slow rather than a bug in the code).

Yeah, I'd think the armhf failure is just an issue with the running time
as opposed to a bug. That time limit is hardcoded in the test -- would
you want me to propose upstream changing that value based upon the
platform? Or just increasing it across the board?

> Is this a new test? Do you believe this test would fail with the previous
> version of php-imagick as well? Should we bypass this test failure for now
> to get php7 migrated?

It is a new test, and is one I fixed in the updated version of
imagemagick. It was an architectural bug in imagemagick, actually --
where i386 had the correct value for rounding, but all other
architectures didn't.

Ah, this actually goes to the heart of the issue I mentioned earlier.
This tests (025-get-color.phpt) tests for different behavior based upon
the imagemagick version. In our case, we are running 0x689 (base
imagemagick versio...

On Mon, Mar 07, 2016 at 07:18:25PM -0000, Nish Aravamudan wrote:
> > So the new php-imagick upload now passes its testsuite on amd64 and ppc64el,
> > but shows failures on i386, armhf and s390x

> > http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/armhf
> > http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/i386
> > http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/s390x

> > Same test failure on i386 and s390x, and only 1 test failure instead of 20+.
> > Different failure on armhf (a test timeout - possibly a problem of the
> > architecture being slow rather than a bug in the code).

> Yeah, I'd think the armhf failure is just an issue with the running time
> as opposed to a bug. That time limit is hardcoded in the test -- would
> you want me to propose upstream changing that value based upon the
> platform? Or just increasing it across the board?

I would say it should get more investigation first. For one thing, the
error message says "Maximum execution time of 3000 seconds exceeded", but
3000 seconds is 50 minutes and the entire autopkgtest run only took 5
minutes.

For now, the test is overridden for proposed-migration.

> > Is this a new test? Do you believe this test would fail with the previous
> > version of php-imagick as well? Should we bypass this test failure for now
> > to get php7 migrated?

> It is a new test, and is one I fixed in the updated version of
> imagemagick. It was an architectural bug in imagemagick, actually --
> where i386 had the correct value for rounding, but all other
> architectures didn't.

> Ah, this actually goes to the heart of the issue I mentioned earlier.
> This tests (025-get-color.phpt) tests for different behavior based upon
> the imagemagick version. In our case, we are running 0x689 (base
> imagemagick version), but actually it's not upstream 0x689, it's 0x689 +
> backports, in particular some from 6.9.2 that fix the code being tested
> here.

> So the test does this check:

> if ($v['versionNumber'] >= 0x692) {
> //this is the new correct behaviour
> return (intval(round($someValue, 0, PHP_ROUND_HALF_UP)));
> }
> else {
> //old behaviour had wrong rounding.
> return (intval(round($someValue, 0, PHP_ROUND_HALF_DOWN)));
> }

> And executes the else-case, but we have the fixes that are in the
> if-case.

> I'm not sure what to do about this. Technically, we know in this test on
> Ubuntu, we should now (on all architectures) be testing the if-case, so
> we could carry a patch for the test that removes the conditional?

I see. That doesn't look like a very sane test to me; the test ought to test
that the output is *correct*, not test that the output matches some known
bug. Yes, I think patching this test to always check for the correct value
is appropriate.

On 07.03.2016 [21:32:04 -0000], Steve Langasek wrote:
> On Mon, Mar 07, 2016 at 07:18:25PM -0000, Nish Aravamudan wrote:
> > > So the new php-imagick upload now passes its testsuite on amd64 and ppc64el,
> > > but shows failures on i386, armhf and s390x
>
> > > http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/armhf
> > > http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/i386
> > > http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/s390x
>
> > > Same test failure on i386 and s390x, and only 1 test failure instead of 20+.
> > > Different failure on armhf (a test timeout - possibly a problem of the
> > > architecture being slow rather than a bug in the code).
>
> > Yeah, I'd think the armhf failure is just an issue with the running time
> > as opposed to a bug. That time limit is hardcoded in the test -- would
> > you want me to propose upstream changing that value based upon the
> > platform? Or just increasing it across the board?
>
> I would say it should get more investigation first. For one thing, the
> error message says "Maximum execution time of 3000 seconds exceeded", but
> 3000 seconds is 50 minutes and the entire autopkgtest run only took 5
> minutes.
>
> For now, the test is overridden for proposed-migration.

Ok that is odd, good point!

> > > Is this a new test? Do you believe this test would fail with the previous
> > > version of php-imagick as well? Should we bypass this test failure for now
> > > to get php7 migrated?
>
> > It is a new test, and is one I fixed in the updated version of
> > imagemagick. It was an architectural bug in imagemagick, actually --
> > where i386 had the correct value for rounding, but all other
> > architectures didn't.
>
> > Ah, this actually goes to the heart of the issue I mentioned earlier.
> > This tests (025-get-color.phpt) tests for different behavior based upon
> > the imagemagick version. In our case, we are running 0x689 (base
> > imagemagick version), but actually it's not upstream 0x689, it's 0x689 +
> > backports, in particular some from 6.9.2 that fix the code being tested
> > here.
>
> > So the test does this check:
>
> > if ($v['versionNumber'] >= 0x692) {
> > //this is the new correct behaviour
> > return (intval(round($someValue, 0, PHP_ROUND_HALF_UP)));
> > }
> > else {
> > //old behaviour had wrong rounding.
> > return (intval(round($someValue, 0, PHP_ROUND_HALF_DOWN)));
> > }
>
> > And executes the else-case, but we have the fixes that are in the
> > if-case.
>
> > I'm not sure what to do about this. Technically, we know in this test on
> > Ubuntu, we should now (on all architectures) be testing the if-case, so
> > we could carry a patch for the test that removes the conditional?
>
> I see. That doesn't look like a very sane test to me; the test ought
> to test that the output is *correct*, not test that the output matches
> some known bug. Yes, I think patching this test to always check for
> the correct value is appropriate.

But what is "correct" to an API consumer? That imagemagick always rounds
up? Then php-imagick will always f...

For the reverse-recommends that refer to php5-imagick, we'll need to update php-pear via LP: #1553419 so that we pick up php-xml on pear builds.

On Mon, Mar 07, 2016 at 10:53:49PM -0000, Nish Aravamudan wrote:
> > I see. That doesn't look like a very sane test to me; the test ought
> > to test that the output is *correct*, not test that the output matches
> > some known bug. Yes, I think patching this test to always check for
> > the correct value is appropriate.

> But what is "correct" to an API consumer? That imagemagick always rounds
> up?

The test code asserts that this is what's correct, I assume with some cause.

Really, this is a bad test because it's testing aspects of the imagemagick
implementation, not the php-imagick code. Instead of hard-coding an
imagemagick version check, it would be better if this test allowed for both
buggy and non-buggy versions of imagemagick and accepted either value, given
the imperfection of checking version numbers.

Or, the test could use values that didn't run into this rounding problem?
Since this behavior difference doesn't seem to be relevant to testing the
behavior of php-imagick itself.

> Then php-imagick will always fail against older version of
> imagemagick.

For the package, it's acceptable for the test to fail against older versions
of imagemagick. For upstream, that's their decision.

The fusiondirectory package includes /etc/fusiondirectory/fusiondirectory-apache.conf, which it registers in the postinst by doing 'ln -s /etc/fusiondirectory/fusiondirectory-apache.conf /etc/apache2/conf.d/fusiondirectory.conf'. The config file in question includes the apache conditional,

<IfModule mod_php5.c>

Will this work with php7?

This bug was fixed in the package gosa - 2.7.4+reloaded2-9ubuntu1

---------------
gosa (2.7.4+reloaded2-9ubuntu1) xenial; urgency=medium

  * debian/control, debian/patches/006_update-to-php7.0-naming.patch:
    + Update to PHP7.0 naming (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Fri, 12 Feb 2016 12:20:13 -0800

php-horde-ansel & php-horde-image pass their tests if I manually add a build-dep on php-xml. Same is needed for phpbb3, but there are no tests. As mentioned earlier, once php-pear is updated, that will no longer be necessary.

This bug was fixed in the package fusiondirectory - 1.0.8.8-3ubuntu1

---------------
fusiondirectory (1.0.8.8-3ubuntu1) xenial; urgency=medium

  * debian/control:
    + Update to PHP7.0 dependencies (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Mon, 07 Mar 2016 14:51:20 -0800

This bug was fixed in the package php-imagick - 3.4.0~rc6-1ubuntu2

---------------
php-imagick (3.4.0~rc6-1ubuntu2) xenial; urgency=medium

  * Fix failures in autopkgtests (LP: #1549942)
    - d/tests/control: run phpunit from tests/ subdirectory to pick up
      the SKIP helper.
    - d/tests/control: add gsfonts and libmagickcore-6.q16-2-extra as
      test dependencies.

  [ Steve Langasek ]
  * Use libmagickwand-6.q16-dev | libmagickwand-dev as the test dependency
    instead of hard-coding an soname that will require us to update the tests
    file for each new ABI.
  * debian/patches/no-openmp-threads.patch: limit the number of openmp
    threads used to 1.

 -- Nishanth Aravamudan <email address hidden> Wed, 24 Feb 2016 19:10:58 -0800

This bug was fixed in the package pictor - 2.34-0ubuntu2

---------------
pictor (2.34-0ubuntu2) xenial; urgency=medium

  * Update to PHP7.0 dependencies (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Fri, 12 Feb 2016 22:27:31 -0800

This bug was fixed in the package ldap-account-manager - 5.2-1ubuntu1

---------------
ldap-account-manager (5.2-1ubuntu1) xenial; urgency=medium

  * Update to PHP7.0 dependencies (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Fri, 12 Feb 2016 12:59:32 -0800

This bug was fixed in the package phpbb3 - 3.0.14-1ubuntu1

---------------
phpbb3 (3.0.14-1ubuntu1) xenial; urgency=medium

  * Update to PHP7.0 dependencies (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Fri, 12 Feb 2016 15:53:26 -0800

This bug was fixed in the package php-horde-ansel - 3.0.3+debian0-2ubuntu1

---------------
php-horde-ansel (3.0.3+debian0-2ubuntu1) xenial; urgency=medium

  * d/tests/control: Update to PHP7.0 dependencies (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Fri, 12 Feb 2016 16:49:43 -0800

This bug was fixed in the package imagemagick - 8:6.8.9.9-7ubuntu3

---------------
imagemagick (8:6.8.9.9-7ubuntu3) xenial; urgency=medium

  * Add backport of 54b752c3 to fix color behavior (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Tue, 08 Mar 2016 09:22:10 -0800

This bug was fixed in the package php-horde-image - 2.3.4-1ubuntu1

---------------
php-horde-image (2.3.4-1ubuntu1) xenial; urgency=medium

  * d/tests/control: Update to PHP7.0 dependencies (LP: #1549942).

 -- Nishanth Aravamudan <email address hidden> Fri, 12 Feb 2016 17:34:55 -0800

imagemagick 6.8.9.9-7ubuntu4 uploaded.

This bug was fixed in the package php-imagick - 3.4.0~rc6-1ubuntu3

---------------
php-imagick (3.4.0~rc6-1ubuntu3) xenial; urgency=medium

  * Fix failures in autopkgtests (LP: #1549942)
    - imagick-3.4.0RC6/tests/025-get-color.phpt: Do not do version
      check, as Ubuntu has backported the referenced fixes.

 -- Nishanth Aravamudan <email address hidden> Mon, 07 Mar 2016 17:55:24 -0800