Re: ABI change in ImageMagick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:
> 
> > On Mon, Nov 11, 2024, 11:03 Dan Horák <dan@xxxxxxxx> 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.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
https://www.happyassassin.net




-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux