Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Dan
On Mon, Nov 11, 2024, 11:03 Dan Horák dan@danny.cz wrote:
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Indeed it does. I've also gotten at least one FTI issue filed due to this change already.
I've -1 karma'd the corresponding f41 update, but it's a Packit managed package so I'm quite sure bodhi comments just go into the big /dev/null.
Fabio
On Mon, 11 Nov 2024 11:19:38 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Nov 11, 2024, 11:03 Dan Horák dan@danny.cz wrote:
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Indeed it does. I've also gotten at least one FTI issue filed due to this change already.
I've -1 karma'd the corresponding f41 update, but it's a Packit managed package so I'm quite sure bodhi comments just go into the big /dev/null.
isn't there a policy that requires packages built by bots to pass all the CI in bodhi? It would not caught this particular issue, but still ... Although there could be an ABI check in the CI too.
Dan
On Mon, Nov 11, 2024 at 05:38:06PM +0100, Dan Horák wrote:
On Mon, 11 Nov 2024 11:19:38 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Nov 11, 2024, 11:03 Dan Horák dan@danny.cz wrote:
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Indeed it does. I've also gotten at least one FTI issue filed due to this change already.
I've -1 karma'd the corresponding f41 update, but it's a Packit managed package so I'm quite sure bodhi comments just go into the big /dev/null.
isn't there a policy that requires packages built by bots to pass all the CI in bodhi? It would not caught this particular issue, but still ... Although there could be an ABI check in the CI too.
Also... using Packit to automate updates for stable releases seems... problematic. It used to be that it caused divergent branches; while fast-forward is now supported[1], unless this is one of those packages with a permanent update exception from FESCo it sounds like just rebuilding whatever is pushed to Rawhide might be incompatible with the stable update policy[2]
[1] https://packit.dev/docs/fedora-releases-guide/non-divergent-dist-git-branche... [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
Best regards,
On Thu, 2024-11-14 at 16:40 -0600, Michel Lind wrote:
On Mon, Nov 11, 2024 at 05:38:06PM +0100, Dan Horák wrote:
On Mon, 11 Nov 2024 11:19:38 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Nov 11, 2024, 11:03 Dan Horák dan@danny.cz wrote:
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Indeed it does. I've also gotten at least one FTI issue filed due to this change already.
I've -1 karma'd the corresponding f41 update, but it's a Packit managed package so I'm quite sure bodhi comments just go into the big /dev/null.
isn't there a policy that requires packages built by bots to pass all the CI in bodhi? It would not caught this particular issue, but still ... Although there could be an ABI check in the CI too.
Also... using Packit to automate updates for stable releases seems... problematic. It used to be that it caused divergent branches; while fast-forward is now supported[1], unless this is one of those packages with a permanent update exception from FESCo it sounds like just rebuilding whatever is pushed to Rawhide might be incompatible with the stable update policy[2]
[1] https://packit.dev/docs/fedora-releases-guide/non-divergent-dist-git-branche... [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
Sorry, I wasn't expect that change from 7.1.1-39 to 7.1.1-40 , have an soname change.
Imagemagick have a soname change detector [1] but haven't worked here because libMagickCore-7.Q16HDRI.so.10()(64bit) libMagickWand-7.Q16HDRI.so.10()(64bit) libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit)
changed to
libMagickCore-7.Q16HDRI.so.10()(64bit) libMagickWand-7.Q16HDRI.so.10()(64bit) libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit)
[1] https://src.fedoraproject.org/rpms/ImageMagick/blob/rawhide/f/ImageMagick.sp...
Best regards,
On Mon, 2024-11-11 at 17:38 +0100, Dan Horák wrote:
On Mon, 11 Nov 2024 11:19:38 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Nov 11, 2024, 11:03 Dan Horák dan@danny.cz wrote:
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Indeed it does. I've also gotten at least one FTI issue filed due to this change already.
I've -1 karma'd the corresponding f41 update, but it's a Packit managed package so I'm quite sure bodhi comments just go into the big /dev/null.
isn't there a policy that requires packages built by bots to pass all the CI in bodhi?
No. There is no such policy. No package is required to pass Fedora CI checks by policy at present. Critical path packages are required to pass openQA tests, but this policy is indifferent regarding who built the package, and ImageMagick is not critpath.
It would not caught this particular issue, but still ... Although there could be an ABI check in the CI too.
There is, to some extent (though it's checking the actual ABI, not the sonames, by the looks of it).
https://bodhi.fedoraproject.org/updates/FEDORA-2024-fff3964033 -> click on Automated Tests -> click on fedora-ci.koji-build.rpminspect.static- analysis -> takes you to https://artifacts.dev.testing-farm.io/672d5798-03e5-4b53-80ba-79846ad65d71/ , click on 'abidiff', and you'll see e.g.:
INFO Comparing from /usr/lib/libMagickCore-7.Q16HDRI.so.10.0.1 to /usr/lib/libMagickCore-7.Q16HDRI.so.10.0.2 in package ImageMagick-libs on i686 revealed ABI differences. Not Waivable Command: abidiff --d1 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/before/i686/usr/lib/debug/ --hd1 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/before/i686/usr/include --d2 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/after/i686/usr/lib/debug/ --hd2 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/after/i686/usr/include /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/before/i686/usr/lib/libMagickCore-7.Q16HDRI.so.10.0.1 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/after/i686/usr/lib/libMagickCore-7.Q16HDRI.so.10.0.2
Functions changes summary: 0 Removed, 1 Changed (575 filtered out), 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'function CacheView* AcquireAuthenticCacheView(const Image*, ExceptionInfo*)' at cache-view.c:112:1 has some indirect sub-type changes: parameter 1 of type 'const Image*' has sub-type changes: in pointed to type 'const Image': in unqualified underlying type 'typedef Image' at magick-type.h:194:1: underlying type 'struct _Image' at image.h:131:1 changed: type size hasn't changed 1 data member changes (5 filtered): type of 'FilterType filter' changed: underlying type 'enum FilterType' at resample.h:33:1 changed: type size hasn't changed 2 enumerator insertions: 'FilterType::MagicKernelSharp2013Filter' value '32' 'FilterType::MagicKernelSharp2021Filter' value '33' 1 enumerator change: 'FilterType::SentinelFilter' from value '32' to '34' at resample.h:33:1
but this is entirely informative, at two levels. It's not a failure at rpminspect level, only an 'info'. And failures at rpminspect level do not gate updates unless the package opts into this in its package-level gating.yaml config.
It would be awkward to make ABI changes in Rawhide into failures for obvious reasons (Rawhide is *where we change ABIs*). It might be more interesting to do so for stable releases, where this isn't supposed to happen without an exception, but we'd need to do some assessment of the reliability of the test first, I guess.
On Thu, Nov 14, 2024 at 04:45:16PM -0800, Adam Williamson wrote:
On Mon, 2024-11-11 at 17:38 +0100, Dan Horák wrote:
On Mon, 11 Nov 2024 11:19:38 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Nov 11, 2024, 11:03 Dan Horák dan@danny.cz wrote:
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
Indeed it does. I've also gotten at least one FTI issue filed due to this change already.
I've -1 karma'd the corresponding f41 update, but it's a Packit managed package so I'm quite sure bodhi comments just go into the big /dev/null.
[snip]
It would not caught this particular issue, but still ... Although there could be an ABI check in the CI too.
There is, to some extent (though it's checking the actual ABI, not the sonames, by the looks of it).
https://bodhi.fedoraproject.org/updates/FEDORA-2024-fff3964033 -> click on Automated Tests -> click on fedora-ci.koji-build.rpminspect.static- analysis -> takes you to https://artifacts.dev.testing-farm.io/672d5798-03e5-4b53-80ba-79846ad65d71/ , click on 'abidiff', and you'll see e.g.:
INFO Comparing from /usr/lib/libMagickCore-7.Q16HDRI.so.10.0.1 to /usr/lib/libMagickCore-7.Q16HDRI.so.10.0.2 in package ImageMagick-libs on i686 revealed ABI differences. Not Waivable Command: abidiff --d1 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/before/i686/usr/lib/debug/ --hd1 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/before/i686/usr/include --d2 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/after/i686/usr/lib/debug/ --hd2 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/after/i686/usr/include /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/before/i686/usr/lib/libMagickCore-7.Q16HDRI.so.10.0.1 /var/ARTIFACTS/work-rpminspectokf2u_1i/rpminspect/tree/workdir/ImageMagick-7.1.1.40.CPBbej/root/after/i686/usr/lib/libMagickCore-7.Q16HDRI.so.10.0.2
Functions changes summary: 0 Removed, 1 Changed (575 filtered out), 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'function CacheView* AcquireAuthenticCacheView(const Image*, ExceptionInfo*)' at cache-view.c:112:1 has some indirect sub-type changes: parameter 1 of type 'const Image*' has sub-type changes: in pointed to type 'const Image': in unqualified underlying type 'typedef Image' at magick-type.h:194:1: underlying type 'struct _Image' at image.h:131:1 changed: type size hasn't changed 1 data member changes (5 filtered): type of 'FilterType filter' changed: underlying type 'enum FilterType' at resample.h:33:1 changed: type size hasn't changed 2 enumerator insertions: 'FilterType::MagicKernelSharp2013Filter' value '32' 'FilterType::MagicKernelSharp2021Filter' value '33' 1 enumerator change: 'FilterType::SentinelFilter' from value '32' to '34' at resample.h:33:1
but this is entirely informative, at two levels. It's not a failure at rpminspect level, only an 'info'. And failures at rpminspect level do not gate updates unless the package opts into this in its package-level gating.yaml config.
Hm, ICBW, but, at least to me, this enum change looks like an actual breaking ABI (not API) change. If a program was compiled to call that function with the SentinelFilter value, the program code would pass 32 as a parameter and invoke the function. If loaded with the new version of the library, this would cause the function to assume that the caller wanted to pass MagicKernelSharp2013Filter and... do something unexpected.
G'luck, Peter
Le 16/11/2024 à 22:46, Peter Pentchev a écrit :
Hm, ICBW, but, at least to me, this enum change looks like an actual breaking ABI (not API) change. If a program was compiled to call that function with the SentinelFilter value, the program code would pass 32 as a parameter and invoke the function. If loaded with the new version of the library, this would cause the function to assume that the caller wanted to pass MagicKernelSharp2013Filter and... do something unexpected.
No, SentinelFilter is a special value keeping track of first free value A program will never use this in an arg call (OK name is confusing)
Typical usage
if (filter < SentinelFilter) { SetResampleFilter(RF, filter); } else { printf("Bad filter value\n"); exit(1); }
Notice: the bad map change have been reverted, so 7.1.1-41 is OK with same ABI than 7.1.1-39
Remi
On Mon, Nov 18, 2024 at 09:17:48AM +0100, Remi Collet wrote:
Le 16/11/2024 à 22:46, Peter Pentchev a écrit :
Hm, ICBW, but, at least to me, this enum change looks like an actual breaking ABI (not API) change. If a program was compiled to call that function with the SentinelFilter value, the program code would pass 32 as a parameter and invoke the function. If loaded with the new version of the library, this would cause the function to assume that the caller wanted to pass MagicKernelSharp2013Filter and... do something unexpected.
No, SentinelFilter is a special value keeping track of first free value A program will never use this in an arg call (OK name is confusing)
Typical usage
if (filter < SentinelFilter) { SetResampleFilter(RF, filter); } else { printf("Bad filter value\n"); exit(1); }
Ahh, okay. Thanks a lot for the explanation!
This only leaves one possible case for confusion: a user of the library that somehow sees a now-valid value and compares it against their "remembered" value for SentinelFilter, e.g. a callback or something. But this seems to be a bit of a reach, so yeah, thanks again for clearing this up, and sorry for stepping in uninformed :)
Notice: the bad map change have been reverted, so 7.1.1-41 is OK with same ABI than 7.1.1-39
G'luck, Peter
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
See https://github.com/ImageMagick/ImageMagick/pull/7768
Remi
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
I don't know if should ignore this ABI changes honestly
fedabipkgdiff -a ImageMagick-7.1.1.39-1.fc41 ImageMagick-7.1.1.40-1.fc41 > fedabipkgdiff.txt
Comparing the ABI of binaries between ImageMagick-libs-7.1.1.39-1.fc41.x86_64.rpm and ImageMagick-libs-7.1.1.40-1.fc41.x86_64.rpm:
================ changes of 'libMagickCore-7.Q16HDRI.so.10.0.1'=============== Functions changes summary: 0 Removed, 1 Changed (575 filtered out), 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'function CacheView* AcquireAuthenticCacheView(const Image*, ExceptionInfo*)' at cache-view.c:112:1 has some indirect sub-type changes: parameter 1 of type 'const Image*' has sub-type changes: in pointed to type 'const Image': in unqualified underlying type 'typedef Image' at magick-type.h:194:1: underlying type 'struct _Image' at image.h:131:1 changed: type size hasn't changed 1 data member changes (5 filtered): type of 'FilterType filter' changed: underlying type 'enum FilterType' at resample.h:33:1 changed: type size hasn't changed 2 enumerator insertions: 'FilterType::MagicKernelSharp2013Filter' value '32' 'FilterType::MagicKernelSharp2021Filter' value '33' 1 enumerator change: 'FilterType::SentinelFilter' from value '32' to '34' at resample.h:33:1
================ end of changes of 'libMagickCore-7.Q16HDRI.so.10.0.1'===============
================ changes of 'libMagickWand-7.Q16HDRI.so.10.0.1'=============== Functions changes summary: 648 Removed, 0 Changed, 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 0 Removed, 0 Added function symbol not referenced by debug info Variable symbols changes summary: 1 Removed, 0 Added variable symbol not referenced by debug info
648 Removed functions:
[D] 'function DrawingWand* AcquireDrawingWand(const DrawInfo*, Image*)' {AcquireDrawingWand@@VERS_10.0} [D] 'function MagickCLI* AcquireMagickCLI(ImageInfo*, ExceptionInfo*)' {AcquireMagickCLI@@VERS_10.0} [D] 'function ScriptTokenInfo* AcquireScriptTokenInfo(const char*)' {AcquireScriptTokenInfo@@VERS_10.0} [D] 'function size_t AcquireWandId(void)' {AcquireWandId@@VERS_10.0} [D] 'function MagickBooleanType AnimateImageCommand(ImageInfo*, int, char**, char**, ExceptionInfo*)' {AnimateImageCommand@@VERS_10.0} [D] 'function void CLIOption(MagickCLI*, const char*, ...)' {CLIOption@@VERS_10.0} [D] 'function MagickBooleanType CLIThrowException(MagickCLI*, const char*, const char*, const size_t, const ExceptionType, const char*, const char*, ...)' {CLIThrowException@@VERS_10.0} [D] 'function void ClearDrawingWand(DrawingWand*)' {ClearDrawingWand@@VERS_10.0} [D] 'function void ClearMagickWand(MagickWand*)' {ClearMagickWand@@VERS_10.0} [D] 'function void ClearPixelIterator(PixelIterator*)' {ClearPixelIterator@@VERS_10.0} [D] 'function void ClearPixelWand(PixelWand*)' {ClearPixelWand@@VERS_10.0} [D] 'function DrawingWand* CloneDrawingWand(const DrawingWand*)' {CloneDrawingWand@@VERS_10.0} [D] 'function MagickWand* CloneMagickWand(const MagickWand*)' {CloneMagickWand@@VERS_10.0} [D] 'function PixelIterator* ClonePixelIterator(const PixelIterator*)' {ClonePixelIterator@@VERS_10.0} [D] 'function PixelWand* ClonePixelWand(const PixelWand*)' {ClonePixelWand@@VERS_10.0} [D] 'function PixelWand** ClonePixelWands(const PixelWand**, const size_t)' {ClonePixelWands@@VERS_10.0} [D] 'function WandView* CloneWandView(const WandView*)' {CloneWandView@@VERS_10.0} (...)
1 Removed variable symbol not referenced by debug info:
[D] .gomp_critical_user_MagickCore_MagickCommandGenesis@@VERS_10.0
================ end of changes of 'libMagickWand-7.Q16HDRI.so.10.0.1'===============
Comparing the ABI of binaries between ImageMagick-c++-7.1.1.39-1.fc41.x86_64.rpm and ImageMagick-c++-7.1.1.40-1.fc41.x86_64.rpm:
================ changes of 'libMagick++-7.Q16HDRI.so.5.0.0'=============== Functions changes summary: 0 Removed, 1 Changed (813 filtered out), 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'method Magick::Image::Image(MagickCore::Image*)' at Image.cpp:5018:1 has some indirect sub-type changes: parameter 1 of type 'MagickCore::Image*' has sub-type changes: in pointed to type 'typedef MagickCore::Image' at magick-type.h:194:1: underlying type 'struct MagickCore::_Image' at image.h:131:1 changed: type size hasn't changed 1 data member changes (4 filtered): type of 'MagickCore::FilterType filter' changed: underlying type 'enum MagickCore::FilterType' at resample.h:33:1 changed: type size hasn't changed 2 enumerator insertions: 'MagickCore::FilterType::MagicKernelSharp2013Filter' value '32' 'MagickCore::FilterType::MagicKernelSharp2021Filter' value '33' 1 enumerator change: 'MagickCore::FilterType::SentinelFilter' from value '32' to '34' at resample.h:33:1
================ end of changes of 'libMagick++-7.Q16HDRI.so.5.0.0'===============
Remi
Le 13/11/2024 à 04:42, Sérgio Basto a écrit :
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
I don't know if should ignore this ABI changes honestly
fedabipkgdiff -a ImageMagick-7.1.1.39-1.fc41 ImageMagick-7.1.1.40-1.fc41 > fedabipkgdiff.txt
I only see change in a enum (2 new values)
IMHO The map change is an error breaking everything map should be used to document in which version a symbol was introduced changing default from 10_0 to 10_2 doesn't make sense
Remi
On Wed, Nov 13, 2024 at 4:43 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
I don't know if should ignore this ABI changes honestly
Ignore? No. It's a breaking change (albeit probably unintentional by upstream). It causes dependent packages to fail to install against the new version (for example xine-lib).
Fabio
On Wed, 2024-11-13 at 18:14 +0100, Fabio Valentini wrote:
On Wed, Nov 13, 2024 at 4:43 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
I don't know if should ignore this ABI changes honestly
Ignore? No. It's a breaking change (albeit probably unintentional by upstream). It causes dependent packages to fail to install against the new version (for example xine-lib).
I mean, just revert the numbers of soname change, like in https://github.com/ImageMagick/ImageMagick/pull/7768/files
OK I reviewed all changes [1] and this commit [2] says that is just eliminate redundant declarations, so seems we don't have any real ABI change ...
[1] https://github.com/ImageMagick/ImageMagick/compare/7.1.1-39...7.1.1-40#diff-...
[2] https://github.com/ImageMagick/ImageMagick/commit/08de3ab435c3685266da4b27df...
Fabio
On Thu, 2024-11-14 at 00:04 +0000, Sérgio Basto wrote:
On Wed, 2024-11-13 at 18:14 +0100, Fabio Valentini wrote:
On Wed, Nov 13, 2024 at 4:43 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
I don't know if should ignore this ABI changes honestly
Ignore? No. It's a breaking change (albeit probably unintentional by upstream). It causes dependent packages to fail to install against the new version (for example xine-lib).
I mean, just revert the numbers of soname change, like in https://github.com/ImageMagick/ImageMagick/pull/7768/files
OK I reviewed all changes [1] and this commit [2] says that is just eliminate redundant declarations, so seems we don't have any real ABI change ...
Can this please be rolled back, then? It is breaking a lot of image builds because they include the eom package, whose deps are broken currently due to this.
On Thu, 2024-11-14 at 14:07 -0800, Adam Williamson wrote:
On Thu, 2024-11-14 at 00:04 +0000, Sérgio Basto wrote:
On Wed, 2024-11-13 at 18:14 +0100, Fabio Valentini wrote:
On Wed, Nov 13, 2024 at 4:43 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
Le 11/11/2024 à 11:02, Dan Horák a écrit :
Hi,
seems ImageMagick 7.1.1.40 comes with an ABI change
it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ...
I don't know if should ignore this ABI changes honestly
Ignore? No. It's a breaking change (albeit probably unintentional by upstream). It causes dependent packages to fail to install against the new version (for example xine-lib).
I mean, just revert the numbers of soname change, like in https://github.com/ImageMagick/ImageMagick/pull/7768/files
OK I reviewed all changes [1] and this commit [2] says that is just eliminate redundant declarations, so seems we don't have any real ABI change ...
Can this please be rolled back, then? It is breaking a lot of image builds because they include the eom package, whose deps are broken currently due to this.
I already rolled back , yesterday
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ec2a4c1575
-- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
-
Adam Williamson -
Dan Horák -
Fabio Valentini -
Michel Lind -
Peter Pentchev -
Remi Collet -
Sérgio Basto