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.
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 6, 2016 at 12:57 AM, Steve Langasek THREAD_ LIMIT=1 is set; which clearly will not be the case out of
<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_
> 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 /github. com/mkoppanen/ imagick# openmp). I believe this is /github. com/mkoppanen/ imagick/ issues/ 138).
(https:/
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:/
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).