Dear release team, Could you get a glimpse at this bug?
I had supposed that this change was safe because these structure could be only allocated using API call (no malloc) and size of structure was expanded. Do you think we need for safety a so bump ? Sorry for this late mail Bastien ---------- Forwarded message ---------- From: Antonio Terceiro <terce...@debian.org> Date: Sun, Dec 4, 2016 at 1:08 AM Subject: Re: [Pkg-gmagick-im-team] Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change) To: roucaries bastien <roucaries.bastien+deb...@gmail.com> Cc: Nishanth Aravamudan <nish.aravamu...@canonical.com>, 846...@bugs.debian.org 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
