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

[roucaries bastien]

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 <terceiro at 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+debian at gmail.com>
Cc: Nishanth Aravamudan <nish.aravamudan at canonical.com>, 846385 at 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.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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gmagick-im-team/attachments/20161205/3a550102/attachment.sig>