Comment 14 for bug 1549942

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?