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

[Antonio Terceiro]

On Thu, Dec 01, 2016 at 03:55:02PM +0100, roucaries bastien wrote:
> On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan
>  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

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

[roucaries bastien]

On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan
 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-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team