Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

Hi Niels, Bob, others,

On Fri, Sep 25, 2015 at 8:34 AM, Niels Thykier  wrote:
> Thanks for getting it uploaded to NEW.
>
> I have prodded the FTP masters about fast tracking and will try to
> finish the resulting transition as fast as possible. :)
 Now it's accepted, built fine on almost all architectures and the
tracker seems to be correct.
It fails on mipsel[1] with:
-- cut --
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...
/«PKGBUILDDIR»/scripts/tap-functions.shi: line 58:  2290 Aborted
  ( "$@" )
EXEC: ./rwfile -stdio -filespec out_truecolor_stdio_%d
/«PKGBUILDDIR»/tests/input_truecolor.miff PCDS
not ok 244 - PCDS truecolor (stdio)
FAIL: tests/rwfile.tap 244 - PCDS truecolor (stdio)
-- cut --

It was failed previously a few times as well, but a rescheduled build
solved it. To be honest the reasons were: signal 01 (SIGBUS) "Bus
Error"
But I suspect the cause may be the same, please reschedule the build
of graphicsmagick on mipsel.

The build is strange on mips just for the record. Sometimes (just like
in the past) it builds in a hour. Nowadays it's over twelve hours
sometimes, but it seems to be at lease six hours[2].
Bob, how may I help you to find the root cause of the slow building on
mips at least?

Thanks,
Laszlo/GCS
[1] 
https://buildd.debian.org/status/fetch.php?pkg=graphicsmagick=mipsel=1.3.21-4=1443407301
[2] https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=mips

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Aurelien Jarno]

On 2015-09-28 08:46, László Böszörményi (GCS) wrote:
> Hi Niels, Bob, others,

Hi,

> On Fri, Sep 25, 2015 at 8:34 AM, Niels Thykier  wrote:
> > Thanks for getting it uploaded to NEW.
> >
> > I have prodded the FTP masters about fast tracking and will try to
> > finish the resulting transition as fast as possible. :)
>  Now it's accepted, built fine on almost all architectures and the
> tracker seems to be correct.
> It fails on mipsel[1] with:
> -- cut --
> Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...
> /«PKGBUILDDIR»/scripts/tap-functions.shi: line 58:  2290 Aborted
>   ( "$@" )
> EXEC: ./rwfile -stdio -filespec out_truecolor_stdio_%d
> /«PKGBUILDDIR»/tests/input_truecolor.miff PCDS
> not ok 244 - PCDS truecolor (stdio)
> FAIL: tests/rwfile.tap 244 - PCDS truecolor (stdio)
> -- cut --
> 
> It was failed previously a few times as well, but a rescheduled build
> solved it. To be honest the reasons were: signal 01 (SIGBUS) "Bus
> Error"
> But I suspect the cause may be the same, please reschedule the build
> of graphicsmagick on mipsel.

The failure is strange, but indeed the new build was successful. Looks
like something to be investigated.

> The build is strange on mips just for the record. Sometimes (just like
> in the past) it builds in a hour. Nowadays it's over twelve hours
> sometimes, but it seems to be at lease six hours[2].
> Bob, how may I help you to find the root cause of the slow building on
> mips at least?

graphicsmagick uses FP instructions, and it happens that the machines we
currently use for the mips port do not have an FPU. The instructions are
emulated, that's why it takes longer to build (or actually to run the
testsuite). We have recently changed the ISA to mips32r2, which improves
things a bit (up to 40% on some packages), but the gain for
graphicsmagick seems to be around 10% only. The real solution is to get
new machines with an FPU, we are currently working on that.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Emilio Pozuelo Monfort]

reassign 796310 src:graphicsmagick 1.3.20-4
fixed 796310 src:graphicsmagick 1.3.21-4
thanks

Hi,

Since libgraphicsmagick3 no longer exists, the BTS gets confused and thinks this
bug isn't fixed, and so britney won't attempt to migrate graphicsmagick:

Updating libgraphicsmagick3 introduces new bugs: #796310

Let's see if this fixes that.

Emilio

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Niels Thykier]

On Fri, 25 Sep 2015 06:56:30 +0200
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> On Fri, Sep 25, 2015 at 12:41 AM, Emilio Pozuelo Monfort
>  wrote:
> > Yeah, sorry if that came out too harsh. I just meant to say that fixing the 
> > RC
> > bug should take priority as this is blocking other transitions. It's good 
> > that
> > you're looking at it, so no worries.
>  It was a bit harsh, but no problem. I guess we all have enough things
> to do. The updated package is now in NEW, hopefully will be accepted
> to the archives soon.
> 
> Kind regards,
> Laszlo/GCS
> 
> 

Hi László,

Thanks for getting it uploaded to NEW.

I have prodded the FTP masters about fast tracking and will try to
finish the resulting transition as fast as possible. :)

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Jakub Wilk]

* László Böszörményi (GCS) , 2015-09-23, 22:13:

[1] http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc


Here's my review:


-Breaks: pdf2djvu (<= 0.7.21-2)


Dropping the Breaks is correct, but I would expect such changes to be 
documented in the changelog.



-Conflicts: libgraphicsmagick
-Replaces: libgraphicsmagick
+Conflicts: libgraphicsmagick, libgraphicsmagick3
+Replaces: libgraphicsmagick, libgraphicsmagick3


Conflicts/replaces on "libgraphicsmagick" is long obsolete and should be 
removed.


Conflicts/replaces on "libgraphicsmagick3" in necessary because of 
/usr/{lib,share}/GraphicsMagick-1.3.21/ directories. :-/ Fortunately, 
can make the new package co-installable with the jessie version by 
making conflict/replaces versioned:


Conflicts: libgraphicsmagick3 (>= 1.3.21)
Replaces: libgraphicsmagick3 (>= 1.3.21)


+++ graphicsmagick-1.3.21/debian/graphicsmagick.install 2015-09-22 
21:55:12.0 +0200
@@ -1,2 +1,3 @@
usr/bin/gm
usr/share/doc/graphicsmagick/www
+usr/share/man/man1/gm.1


I don't understand what why this change is needed. It's not documented 
in the changelog.



+++ graphicsmagick-1.3.21/debian/libgraphicsmagick++1-dev.links 2015-09-23 
00:40:01.0 +0200
@@ -1 +1,2 @@
usr/share/doc/graphicsmagick/www/images 
usr/share/doc/libgraphicsmagick++1-dev/images
+usr/lib/libGraphicsMagick++-Q16.so.11.0.0 usr/lib/libGraphicsMagick++-Q16.so


I don't think these symlinks are useful.
If upstream build system doesn't create them, then we shouldn't either.


+++ graphicsmagick-1.3.21/debian/libgraphicsmagick1-dev.links   2015-09-23 
00:23:12.0 +0200
@@ -1 +1,3 @@
usr/share/doc/graphicsmagick/www/images 
usr/share/doc/libgraphicsmagick1-dev/images
+usr/lib/libGraphicsMagick-Q16.so.3.13.0 usr/lib/libGraphicsMagick-Q16.so
+usr/lib/libGraphicsMagickWand-Q16.so.2.7.1 usr/lib/libGraphicsMagickWand-Q16.so


Ditto.


-   dh_shlibdeps -a -L libgraphicsmagick3 \
-   -l debian/libgraphicsmagick3/usr/lib
+   dh_shlibdeps -a -L libgraphicsmagick-q16-3 \
+   -l debian/libgraphicsmagick-q16-3/usr/lib


These days -l and -L shouldn't be needed.

--
Jakub Wilk

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Thu, Sep 24, 2015 at 1:38 PM, Jakub Wilk  wrote:
> Conflicts/replaces on "libgraphicsmagick3" in necessary because of
> /usr/{lib,share}/GraphicsMagick-1.3.21/ directories. :-/ Fortunately, can
> make the new package co-installable with the jessie version by making
> conflict/replaces versioned:
>
> Conflicts: libgraphicsmagick3 (>= 1.3.21)
> Replaces: libgraphicsmagick3 (>= 1.3.21)
 +1

>> +++ graphicsmagick-1.3.21/debian/graphicsmagick.install 2015-09-22
>> 21:55:12.0 +0200
>> @@ -1,2 +1,3 @@
>> usr/bin/gm
>> usr/share/doc/graphicsmagick/www
>> +usr/share/man/man1/gm.1
>
> I don't understand what why this change is needed. It's not documented in
> the changelog.
 A quick check showed the manpage is not installed otherwise, need check.

>> +++ graphicsmagick-1.3.21/debian/libgraphicsmagick++1-dev.links 2015-09-23
>> 00:40:01.0 +0200
>> @@ -1 +1,2 @@
>> usr/share/doc/graphicsmagick/www/images
>> usr/share/doc/libgraphicsmagick++1-dev/images
>> +usr/lib/libGraphicsMagick++-Q16.so.11.0.0
>> usr/lib/libGraphicsMagick++-Q16.so
>
> I don't think these symlinks are useful.
> If upstream build system doesn't create them, then we shouldn't either.
 I was afraid that other packages may use it to detect the QD support
of the library if not now, but in the close future. But sure, if
upstream doesn't create this then why should I be such pedantic.

>> -   dh_shlibdeps -a -L libgraphicsmagick3 \
>> -   -l debian/libgraphicsmagick3/usr/lib
>> +   dh_shlibdeps -a -L libgraphicsmagick-q16-3 \
>> +   -l debian/libgraphicsmagick-q16-3/usr/lib
>
> These days -l and -L shouldn't be needed.
 OK.

Thanks! Will act when I get back home.
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Emilio Pozuelo Monfort]

On 25/09/15 00:10, László Böszörményi (GCS) wrote:
> On Wed, Sep 23, 2015 at 8:30 PM, Emilio Pozuelo Monfort
>  wrote:
>> On Tue, 22 Sep 2015 21:58:46 +0200  wrote:
>>>  You make me wonder. Would it worth to have packages with different
>>> quantum depth support in parallel? I mean I would compile / install
>>> the package twice; first for QD=16 and then QD=32 to different paths
>>> so I can ship the libraries parallel for any given release.
>>
>> Please fix the aforementioned bug as it's blocking the GCC5 transition, and
>> worry about compiling things twice and providing multiple libraries later.
>  It was just a question for future upstream releases. Life is easier -
> my slowness is due to IRL things, just got back home recently and need
> to get up early in the morning. But working on the fix / update and
> going to upload it soon.

Yeah, sorry if that came out too harsh. I just meant to say that fixing the RC
bug should take priority as this is blocking other transitions. It's good that
you're looking at it, so no worries.

Thanks,
Emilio

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Wed, Sep 23, 2015 at 8:30 PM, Emilio Pozuelo Monfort
 wrote:
> On Tue, 22 Sep 2015 21:58:46 +0200  wrote:
>>  You make me wonder. Would it worth to have packages with different
>> quantum depth support in parallel? I mean I would compile / install
>> the package twice; first for QD=16 and then QD=32 to different paths
>> so I can ship the libraries parallel for any given release.
>
> Please fix the aforementioned bug as it's blocking the GCC5 transition, and
> worry about compiling things twice and providing multiple libraries later.
 It was just a question for future upstream releases. Life is easier -
my slowness is due to IRL things, just got back home recently and need
to get up early in the morning. But working on the fix / update and
going to upload it soon.

Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Fri, Sep 25, 2015 at 12:41 AM, Emilio Pozuelo Monfort
 wrote:
> Yeah, sorry if that came out too harsh. I just meant to say that fixing the RC
> bug should take priority as this is blocking other transitions. It's good that
> you're looking at it, so no worries.
 It was a bit harsh, but no problem. I guess we all have enough things
to do. The updated package is now in NEW, hopefully will be accepted
to the archives soon.

Kind regards,
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Jakub Wilk]

* László Böszörményi (GCS) , 2015-09-22, 19:40:
Also, now might be a good moment to move libGraphicsMagickWand to a 
seperate binary package.
Do you know any package which needs only that library (ie does it worth 
to be a separate one)?


I don't know. I mentioned because the current arrangement is not 
policy-compliant. Policy §8.1 allows lumping together multiple shared 
libraries in a single package only if all the SONAMEs always change 
together. But libGraphicsMagick and libGraphicsMagickWand are versioned 
independently, and in fact their soversions are already different.


--
Jakub Wilk

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Emilio Pozuelo Monfort]

On Tue, 22 Sep 2015 21:58:46 +0200  wrote:
> On Tue, Sep 22, 2015 at 8:27 PM, Bob Friesenhahn
>  wrote:
> > If there are two packages with different quantum depth, then they should be
> > able to co-exist without conflict.  Likewise, the existing package should be
> > able to co-exist with new packages which are distinguished via quantum depth
> > so that existing software continues to work.
>  You make me wonder. Would it worth to have packages with different
> quantum depth support in parallel? I mean I would compile / install
> the package twice; first for QD=16 and then QD=32 to different paths
> so I can ship the libraries parallel for any given release.

Please fix the aforementioned bug as it's blocking the GCC5 transition, and
worry about compiling things twice and providing multiple libraries later.

Thanks,
Emilio

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Tue, Sep 22, 2015 at 8:10 PM, Julien Cristau  wrote:
> On Tue, Sep 22, 2015 at 19:40:42 +0200, László Böszörményi (GCS) wrote:
>>  Yes, I know that. Still the packages can be tracked during a
>> transition via the package name if those were compiled against the
>> quantum-depth change or not. I have to change the package name anyway,
>> I can't just change the SONAME. Then I don't see the mandatory to
>> change the SONAME, the package name change will make it distinct of
>> the quantum-depth difference.
> Please do change the SONAMEs when you change the package names for this,
> especially if upstream provide an option to do so.
 OK, updated the package[1] if any of you would like to review it - no
other change for now. It's getting late, will upload the package
tomorrow.

Cheers,
Laszlo/GCS
[1] http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Tue, Sep 22, 2015 at 7:17 PM, Jakub Wilk  wrote:
> * László Böszörményi (GCS) , 2015-09-22, 08:25:
>>
>> [2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc
>
> You changed the package name, but not the SONAME. That doesn't sound right.
 Yes, I know that. Still the packages can be tracked during a
transition via the package name if those were compiled against the
quantum-depth change or not. I have to change the package name anyway,
I can't just change the SONAME. Then I don't see the mandatory to
change the SONAME, the package name change will make it distinct of
the quantum-depth difference.

> Changing the SONAME should be a matter of passing
> --enable-quantum-library-names to configure, as suggested by Bob Friesenhahn
> in #795102.
 Will re-read that mail from Bob.

> Also, now might be a good moment to move libGraphicsMagickWand to a seperate
> binary package.
 Do you know any package which needs only that library (ie does it
worth to be a separate one)?

Regards,
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Bob Friesenhahn]

On Tue, 22 Sep 2015, László Böszörményi wrote:


On Tue, Sep 22, 2015 at 7:17 PM, Jakub Wilk  wrote:

* László Böszörményi (GCS) , 2015-09-22, 08:25:


[2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc


You changed the package name, but not the SONAME. That doesn't sound right.

Yes, I know that. Still the packages can be tracked during a
transition via the package name if those were compiled against the
quantum-depth change or not. I have to change the package name anyway,
I can't just change the SONAME. Then I don't see the mandatory to
change the SONAME, the package name change will make it distinct of
the quantum-depth difference.


If there are two packages with different quantum depth, then they 
should be able to co-exist without conflict.  Likewise, the existing 
package should be able to co-exist with new packages which are 
distinguished via quantum depth so that existing software continues to 
work.


Dependent applications should be re-compiled and re-linked against the 
new packages so they stop using the old library.


A factor to consider is that GraphicsMagick packages of the same 
GraphicsMagick release version and quantum depth will share coder and 
filter modules which are under a path like 
/usr/lib/GraphicsMagick-1.3.21/modules-Q16.  Changing to the new 
scheme without also transitioning to a new version will result in 
over-writing existing coder/filter modules and these will now 
reference the new GraphicsMagick library rather than the old one.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Tue, Sep 22, 2015 at 8:27 PM, Bob Friesenhahn
 wrote:
> If there are two packages with different quantum depth, then they should be
> able to co-exist without conflict.  Likewise, the existing package should be
> able to co-exist with new packages which are distinguished via quantum depth
> so that existing software continues to work.
 You make me wonder. Would it worth to have packages with different
quantum depth support in parallel? I mean I would compile / install
the package twice; first for QD=16 and then QD=32 to different paths
so I can ship the libraries parallel for any given release.

> Dependent applications should be re-compiled and re-linked against the new
> packages so they stop using the old library.
 Does it mean that run-time loading is not possible? A dependent
package would ask which one (16/32) you would like and then load the
library that provides the specified QD to process the images.

Regards,
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Jakub Wilk]

* László Böszörményi (GCS) , 2015-09-22, 08:25:

[2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc


You changed the package name, but not the SONAME. That doesn't sound 
right.


Changing the SONAME should be a matter of passing 
--enable-quantum-library-names to configure, as suggested by Bob 
Friesenhahn in #795102.


Also, now might be a good moment to move libGraphicsMagickWand to a 
seperate binary package.


--
Jakub Wilk

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Julien Cristau]

On Tue, Sep 22, 2015 at 19:40:42 +0200, László Böszörményi (GCS) wrote:

> On Tue, Sep 22, 2015 at 7:17 PM, Jakub Wilk  wrote:
> > * László Böszörményi (GCS) , 2015-09-22, 08:25:
> >>
> >> [2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc
> >
> > You changed the package name, but not the SONAME. That doesn't sound right.
>  Yes, I know that. Still the packages can be tracked during a
> transition via the package name if those were compiled against the
> quantum-depth change or not. I have to change the package name anyway,
> I can't just change the SONAME. Then I don't see the mandatory to
> change the SONAME, the package name change will make it distinct of
> the quantum-depth difference.
> 
Please do change the SONAMEs when you change the package names for this,
especially if upstream provide an option to do so.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Bob Friesenhahn]

On Tue, 22 Sep 2015, László Böszörményi wrote:


On Tue, Sep 22, 2015 at 8:27 PM, Bob Friesenhahn
 wrote:

If there are two packages with different quantum depth, then they should be
able to co-exist without conflict.  Likewise, the existing package should be
able to co-exist with new packages which are distinguished via quantum depth
so that existing software continues to work.

You make me wonder. Would it worth to have packages with different
quantum depth support in parallel? I mean I would compile / install
the package twice; first for QD=16 and then QD=32 to different paths
so I can ship the libraries parallel for any given release.


This would be useful since some applications need absolute minimum use 
of resources (e.g. web applications or processing typical JPEG files) 
while others care more about the degree of color precision.



Dependent applications should be re-compiled and re-linked against the new
packages so they stop using the old library.

Does it mean that run-time loading is not possible? A dependent
package would ask which one (16/32) you would like and then load the
library that provides the specified QD to process the images.


That would require explicit code in the application and creating a 
loadable module compiled against each one.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Mon, Sep 21, 2015 at 9:22 AM, László Böszörményi (GCS)
 wrote:
>  Correct. It seems all dependencies could be built with the
> QuantumDepth change[1], but the C library package name change is
> strongly advised. Will do it today with appending q16 to the library
> name (as seen with imagemagick which also done the QuantumDepth=16
> change) if there's no objections.
[...]
> [1] https://release.debian.org/transitions/html/auto-graphicsmagick.html
 I've updated it and it's ready to be uploaded[2]. But finished late
in the evening, would like to get a round of local testing today.

Sorry for the delay,
Laszlo/GCS
[2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Julien Cristau]

On Sat, Aug 22, 2015 at 00:03:22 +0200, László Böszörményi wrote:

> On Fri, Aug 21, 2015 at 11:28 AM, Jakub Wilk  wrote:
> > Package: libgraphicsmagick3
> > Version: 1.3.20-4
> > Severity: serious
> >
> > Please either revert the QuantumDepth change, or change the SONAME.
>  Of course, I'm going to fix it. Will change the SONAME as the
> QuantumDepth change is inevitable.
> 
Ping.  It's been a month, and this bug is blocking graphicsmagick's
gcc-5 transition.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Mon, Sep 21, 2015 at 8:12 AM, Julien Cristau  wrote:
> On Sat, Aug 22, 2015 at 00:03:22 +0200, László Böszörményi wrote:
>> On Fri, Aug 21, 2015 at 11:28 AM, Jakub Wilk  wrote:
>> > Please either revert the QuantumDepth change, or change the SONAME.
>>  Of course, I'm going to fix it. Will change the SONAME as the
>> QuantumDepth change is inevitable.
>>
> Ping.  It's been a month, and this bug is blocking graphicsmagick's
> gcc-5 transition.
 Correct. It seems all dependencies could be built with the
QuantumDepth change[1], but the C library package name change is
strongly advised. Will do it today with appending q16 to the library
name (as seen with imagemagick which also done the QuantumDepth=16
change) if there's no objections.

Cheers,
Laszlo/GCS
[1] https://release.debian.org/transitions/html/auto-graphicsmagick.html

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Fri, Aug 21, 2015 at 11:28 AM, Jakub Wilk jw...@debian.org wrote:
 Package: libgraphicsmagick3
 Version: 1.3.20-4
 Severity: serious

 Please either revert the QuantumDepth change, or change the SONAME.
 Of course, I'm going to fix it. Will change the SONAME as the
QuantumDepth change is inevitable.

Regards,
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[Jakub Wilk]

Package: libgraphicsmagick3
Version: 1.3.20-4
Severity: serious

As I said in #795102, building with QuantumDepth=16 breaks the ABI.

Please either revert the QuantumDepth change, or change the SONAME.

--
Jakub Wilk