On Thu, Dec 01, 2016 at 03:55:02PM +0100, roucaries bastien wrote: > On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan > <nish.aravamu...@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
I don't think that is the case. After initializing a _Drawinfo struct, ruby-rmagick needs to operate on it, by assigning values to its fields. So unless I am missing some API in imagemagick to set fields of _Drawinfo, it is *not* opaque for API users. If the structure size changes without a proper SONAME bump, this *will* cause segfaults. Please reconsider this, and do SONAME bumps when there are ABI changes. > * _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. See above.
signature.asc
Description: PGP signature
