[Pkg-gmagick-im-team] Bug#846385: Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan
<nish.aravamudan at canonical.com> wrote:
> Package: imagemagick
> Version: 6.9.9.6+dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> We recently merged imagemagick 6.9.9.6+dfsg-1 in Ubuntu 17.04; however
> we see autopkgtest failures in ruby-rmagick and php-imagick with this
> version (note that Debian is seeing similar failures).
>
> At least for ruby-rmagick, it seems like (possibly) upstream made an ABI
> change without bumping the SONAME for libmagickcore, and ruby-rmagick
> ends up pulling in the wrong dependency
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz).
>
> More specifically, we are building against imagemagick
> 8:6.9.6.6+dfsg-1ubuntu2:
> https://launchpadlibrarian.net/295470626/buildlog_ubuntu-zesty-arm64.ruby-rmagick_2.15.4+dfsg-2build1_BUILDING.txt.gz.
>
> During the build, the tests pass succesfully (using the above version of
> imagemagick), but you can see that the the resulting binary package has
> dependencies that are more relaxed than that specific version:
>
>  Depends: ruby (>= 1:2.3~0), libc6 (>= 2.17), libmagickcore-6.q16-2 (>= 8:6.8.8.9), libruby2.3 (>= 2.3.0~preview2)
>
> Therefore, when the autopkgtest runs:
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz,
> imagemagick 8:6.8.9.9-7ubuntu9 is used, and a segmentation fault occurs.
>
> Thanks to Marc Deslauriers' research, it seems like there might have
> been at least one ABI breakage upsream in libmagickcore:
> https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.1-10/6.9.2-10/67f2f/abi_compat_report.html,
> which might be related.
>
> What is your opinion on this as the Debian maintainer? Should the SONAME
> be bumped and symbols files be updated?

Some detail:
*  GetDefaultOpenCLEnv is not a problem because opencl is disable on debian
* struct _DrawInfo (1) is not a problem from a C point of view because
it should be set and destry by API function. It is a opaque object. So
no need to so bump for this
*  _ElementReference (1) is part of _Drawinfo so not a problem
* _GradientInfo (3) is the same
* For _image is an opaque type so it is the same

Now for interpreted language you may need the size of this kind of
structure and thus need stricter dependencies or use at
innitialisation a runtime check of imagesize returned by

AcquireImage() function.

Bastien





> Thanks for your time!
>
> -Nish
>
> --
> Nishanth Aravamudan
> Ubuntu Server
> Canonical Ltd
>
> _______________________________________________
> Pkg-gmagick-im-team mailing list
> Pkg-gmagick-im-team at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team