Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)

[Michel Alexandre Salim]

Hi all,

Per the incompatible upgrade policy[1] I'm proposing upgrading
libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.

Bugzilla issues:
- https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 in
general)
- https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)

Up to 0.4.1, libkdumpfile was packaged without the test suite being
run, and when I started work on packaging it in Debian I noticed a lot
of test failures on non-x86_64 architectures:
https://github.com/ptesarik/libkdumpfile/issues/40

This is now fixed (0.5.0 is the first version to pass tests cleanly
without additional patches on Fedora), but prior to its release we were
basically building in Fedora from a post-0.4.1 snapshot
(https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af8326562a1...)
that is likely not ABI compatible with the original 0.4.1 anyway, so
there's no reasonable way to backport the architecture fixes to 0.4.1.

Change in sonames:

[michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora rawhide --
provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-stream
9 --provides libkdumpfile 2>/dev/null)
	libaddrxlat.so.2()(64bit)
	libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
libaddrxlat.so.3
libaddrxlat.so.3()(64bit)
libaddrxlat.so.3(LIBADDRXLAT_0)
libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
	libkdumpfile = 0.4.1-5.el9
libkdumpfile = 0.5.0-3.fc38
libkdumpfile(x86-32) = 0.5.0-3.fc38
	libkdumpfile(x86-64) = 0.4.1-5.el9
libkdumpfile(x86-64) = 0.5.0-3.fc38
libkdumpfile.so.10
libkdumpfile.so.10()(64bit)
libkdumpfile.so.10(LIBKDUMPFILE_0)
libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
	libkdumpfile.so.9()(64bit)
	libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)

Only drgn currently depends on libkdumpfile, and I plan to rebuild it
in the same updates:

[michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
whatrequires "libaddrxlat.so.2()(64bit)"
Last metadata expiration check: 0:12:30 ago on Wed Feb  8 11:02:35
2023.
libkdumpfile-devel-0:0.4.1-5.el9.x86_64
libkdumpfile-util-0:0.4.1-5.el9.x86_64
python3-libkdumpfile-0:0.4.1-5.el9.x86_64
[michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
whatrequires "libkdumpfile.so.9()(64bit)"
Last metadata expiration check: 0:12:40 ago on Wed Feb  8 11:02:35
2023.
drgn-0:0.0.22-1.el9.x86_64
libkdumpfile-devel-0:0.4.1-5.el9.x86_64
libkdumpfile-util-0:0.4.1-5.el9.x86_64
python3-libkdumpfile-0:0.4.1-5.el9.x86_64

[michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
whatrequires "libaddrxlat.so.2()(64bit)"
Last metadata expiration check: 0:00:08 ago on Wed Feb  8 11:15:35
2023.
libkdumpfile-devel-0:0.4.1-5.el8.x86_64
libkdumpfile-util-0:0.4.1-5.el8.x86_64
python3-libkdumpfile-0:0.4.1-5.el8.x86_64
[michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
whatrequires "libkdumpfile.so.9()(64bit)"
Last metadata expiration check: 0:00:16 ago on Wed Feb  8 11:15:35
2023.
drgn-0:0.0.22-1.el8.x86_64
libkdumpfile-devel-0:0.4.1-5.el8.x86_64
libkdumpfile-util-0:0.4.1-5.el8.x86_64
python3-libkdumpfile-0:0.4.1-5.el8.x86_64

[1]:
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/

Thanks,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Troy Dawson]

On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim <
salimma(a)fedoraproject.org&gt; wrote:

>  Hi all,
>
>  Per the incompatible upgrade policy[1] I'm proposing upgrading
>  libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
>
>  Bugzilla issues:
>  - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 in
>  general)
>  - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
>
>  Up to 0.4.1, libkdumpfile was packaged without the test suite being
>  run, and when I started work on packaging it in Debian I noticed a lot
>  of test failures on non-x86_64 architectures:
>  https://github.com/ptesarik/libkdumpfile/issues/40
>
>  This is now fixed (0.5.0 is the first version to pass tests cleanly
>  without additional patches on Fedora), but prior to its release we were
>  basically building in Fedora from a post-0.4.1 snapshot
>  (
>
> https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af8326562a1...
>  )
>  that is likely not ABI compatible with the original 0.4.1 anyway, so
>  there's no reasonable way to backport the architecture fixes to 0.4.1.
>
>  Change in sonames:
>
>  [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora rawhide --
>  provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-stream
>  9 --provides libkdumpfile 2>/dev/null)
>          libaddrxlat.so.2()(64bit)
>          libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
>  libaddrxlat.so.3
>  libaddrxlat.so.3()(64bit)
>  libaddrxlat.so.3(LIBADDRXLAT_0)
>  libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
>          libkdumpfile = 0.4.1-5.el9
>  libkdumpfile = 0.5.0-3.fc38
>  libkdumpfile(x86-32) = 0.5.0-3.fc38
>          libkdumpfile(x86-64) = 0.4.1-5.el9
>  libkdumpfile(x86-64) = 0.5.0-3.fc38
>  libkdumpfile.so.10
>  libkdumpfile.so.10()(64bit)
>  libkdumpfile.so.10(LIBKDUMPFILE_0)
>  libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
>          libkdumpfile.so.9()(64bit)
>          libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
>
>  Only drgn currently depends on libkdumpfile, and I plan to rebuild it
>  in the same updates:
>
>  [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>  whatrequires "libaddrxlat.so.2()(64bit)"
>  Last metadata expiration check: 0:12:30 ago on Wed Feb  8 11:02:35
>  2023.
>  libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>  libkdumpfile-util-0:0.4.1-5.el9.x86_64
>  python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>  [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>  whatrequires "libkdumpfile.so.9()(64bit)"
>  Last metadata expiration check: 0:12:40 ago on Wed Feb  8 11:02:35
>  2023.
>  drgn-0:0.0.22-1.el9.x86_64
>  libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>  libkdumpfile-util-0:0.4.1-5.el9.x86_64
>  python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>
>  [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
>  whatrequires "libaddrxlat.so.2()(64bit)"
>  Last metadata expiration check: 0:00:08 ago on Wed Feb  8 11:15:35
>  2023.
>  libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>  libkdumpfile-util-0:0.4.1-5.el8.x86_64
>  python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>  [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
>  whatrequires "libkdumpfile.so.9()(64bit)"
>  Last metadata expiration check: 0:00:16 ago on Wed Feb  8 11:15:35
>  2023.
>  drgn-0:0.0.22-1.el8.x86_64
>  libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>  libkdumpfile-util-0:0.4.1-5.el8.x86_64
>  python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>
>  [1]:
>
>  https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
>  Thanks,
>  
If I am reading this correctly, the only package affected would be drgn
(from python-drgn).
It should hopefully just need a rebuild.
Is that correct?
Were you planning on rebuilding python-drgn, or contacting the package
maintainer and having them do it?

Troy

[Neal Gompa]

On Wed, Feb 8, 2023 at 12:37 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>  On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim <salimma(a)fedoraproject.org&gt;
> wrote:
> >
> > Hi all,
> >
> > Per the incompatible upgrade policy[1] I'm proposing upgrading
> > libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
> >
> > Bugzilla issues:
> > - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 in
> > general)
> > - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
> >
> > Up to 0.4.1, libkdumpfile was packaged without the test suite being
> > run, and when I started work on packaging it in Debian I noticed a lot
> > of test failures on non-x86_64 architectures:
> > https://github.com/ptesarik/libkdumpfile/issues/40
> >
> > This is now fixed (0.5.0 is the first version to pass tests cleanly
> > without additional patches on Fedora), but prior to its release we were
> > basically building in Fedora from a post-0.4.1 snapshot
> >
> (https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af8326562a1...)
> > that is likely not ABI compatible with the original 0.4.1 anyway, so
> > there's no reasonable way to backport the architecture fixes to 0.4.1.
> >
> > Change in sonames:
> >
> > [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora rawhide --
> > provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-stream
> > 9 --provides libkdumpfile 2>/dev/null)
> >         libaddrxlat.so.2()(64bit)
> >         libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
> > libaddrxlat.so.3
> > libaddrxlat.so.3()(64bit)
> > libaddrxlat.so.3(LIBADDRXLAT_0)
> > libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
> >         libkdumpfile = 0.4.1-5.el9
> > libkdumpfile = 0.5.0-3.fc38
> > libkdumpfile(x86-32) = 0.5.0-3.fc38
> >         libkdumpfile(x86-64) = 0.4.1-5.el9
> > libkdumpfile(x86-64) = 0.5.0-3.fc38
> > libkdumpfile.so.10
> > libkdumpfile.so.10()(64bit)
> > libkdumpfile.so.10(LIBKDUMPFILE_0)
> > libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
> >         libkdumpfile.so.9()(64bit)
> >         libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
> >
> > Only drgn currently depends on libkdumpfile, and I plan to rebuild it
> > in the same updates:
> >
> > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
> > whatrequires "libaddrxlat.so.2()(64bit)"
> > Last metadata expiration check: 0:12:30 ago on Wed Feb  8 11:02:35
> > 2023.
> > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
> > libkdumpfile-util-0:0.4.1-5.el9.x86_64
> > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
> > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
> > whatrequires "libkdumpfile.so.9()(64bit)"
> > Last metadata expiration check: 0:12:40 ago on Wed Feb  8 11:02:35
> > 2023.
> > drgn-0:0.0.22-1.el9.x86_64
> > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
> > libkdumpfile-util-0:0.4.1-5.el9.x86_64
> > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
> >
> > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
> > whatrequires "libaddrxlat.so.2()(64bit)"
> > Last metadata expiration check: 0:00:08 ago on Wed Feb  8 11:15:35
> > 2023.
> > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
> > libkdumpfile-util-0:0.4.1-5.el8.x86_64
> > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
> > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
> > whatrequires "libkdumpfile.so.9()(64bit)"
> > Last metadata expiration check: 0:00:16 ago on Wed Feb  8 11:15:35
> > 2023.
> > drgn-0:0.0.22-1.el8.x86_64
> > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
> > libkdumpfile-util-0:0.4.1-5.el8.x86_64
> > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
> >
> > [1]:
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> >
> > Thanks,
>
>
>  If I am reading this correctly, the only package affected would be drgn (from
> python-drgn).
>  It should hopefully just need a rebuild.
>  Is that correct?
>  Were you planning on rebuilding python-drgn, or contacting the package maintainer and
> having them do it?
>  
He's a co-maintainer of python-drgn, so I assume he's going to
rebuild it himself.




--
真実はいつも一つ！/ Always, there's only one truth!

[Michel Alexandre Salim]

On Wed, 2023-02-08 at 14:09 -0500, Neal Gompa wrote:
>  On Wed, Feb 8, 2023 at 12:37 PM Troy Dawson
> <tdawson(a)redhat.com&gt;
>  wrote:
>  > 
>  > On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim
>  > <salimma(a)fedoraproject.org&gt; wrote:
>  > > 
>  > > Hi all,
>  > > 
>  > > Per the incompatible upgrade policy[1] I'm proposing upgrading
>  > > libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
>  > > 
>  > > Bugzilla issues:
>  > > - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1
>  > > in
>  > > general)
>  > > - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
>  > > 
>  > > Up to 0.4.1, libkdumpfile was packaged without the test suite
>  > > being
>  > > run, and when I started work on packaging it in Debian I noticed
>  > > a lot
>  > > of test failures on non-x86_64 architectures:
>  > > https://github.com/ptesarik/libkdumpfile/issues/40
>  > > 
>  > > This is now fixed (0.5.0 is the first version to pass tests
>  > > cleanly
>  > > without additional patches on Fedora), but prior to its release
>  > > we were
>  > > basically building in Fedora from a post-0.4.1 snapshot
>  > > (
>  > > https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af83
>  > > 26562a155581d77f04f2ae84197/f/libkdumpfile.spec)
>  > > that is likely not ABI compatible with the original 0.4.1 anyway,
>  > > so
>  > > there's no reasonable way to backport the architecture fixes to
>  > > 0.4.1.
>  > > 
>  > > Change in sonames:
>  > > 
>  > > [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora
>  > > rawhide --
>  > > provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-
>  > > stream
>  > > 9 --provides libkdumpfile 2>/dev/null)
>  > >         libaddrxlat.so.2()(64bit)
>  > >         libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
>  > > libaddrxlat.so.3
>  > > libaddrxlat.so.3()(64bit)
>  > > libaddrxlat.so.3(LIBADDRXLAT_0)
>  > > libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
>  > >         libkdumpfile = 0.4.1-5.el9
>  > > libkdumpfile = 0.5.0-3.fc38
>  > > libkdumpfile(x86-32) = 0.5.0-3.fc38
>  > >         libkdumpfile(x86-64) = 0.4.1-5.el9
>  > > libkdumpfile(x86-64) = 0.5.0-3.fc38
>  > > libkdumpfile.so.10
>  > > libkdumpfile.so.10()(64bit)
>  > > libkdumpfile.so.10(LIBKDUMPFILE_0)
>  > > libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
>  > >         libkdumpfile.so.9()(64bit)
>  > >         libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
>  > > 
>  > > Only drgn currently depends on libkdumpfile, and I plan to
>  > > rebuild it
>  > > in the same updates:
>  > > 
>  > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>  > > whatrequires "libaddrxlat.so.2()(64bit)"
>  > > Last metadata expiration check: 0:12:30 ago on Wed Feb  8
>  > > 11:02:35
>  > > 2023.
>  > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>  > > libkdumpfile-util-0:0.4.1-5.el9.x86_64
>  > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>  > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>  > > whatrequires "libkdumpfile.so.9()(64bit)"
>  > > Last metadata expiration check: 0:12:40 ago on Wed Feb  8
>  > > 11:02:35
>  > > 2023.
>  > > drgn-0:0.0.22-1.el9.x86_64
>  > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>  > > libkdumpfile-util-0:0.4.1-5.el9.x86_64
>  > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>  > > 
>  > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-
>  > > legacy 8 --
>  > > whatrequires "libaddrxlat.so.2()(64bit)"
>  > > Last metadata expiration check: 0:00:08 ago on Wed Feb  8
>  > > 11:15:35
>  > > 2023.
>  > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>  > > libkdumpfile-util-0:0.4.1-5.el8.x86_64
>  > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>  > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-
>  > > legacy 8 --
>  > > whatrequires "libkdumpfile.so.9()(64bit)"
>  > > Last metadata expiration check: 0:00:16 ago on Wed Feb  8
>  > > 11:15:35
>  > > 2023.
>  > > drgn-0:0.0.22-1.el8.x86_64
>  > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>  > > libkdumpfile-util-0:0.4.1-5.el8.x86_64
>  > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>  > > 
>  > > [1]:
>  > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>  > > 
>  > > Thanks,
>  > 
>  > 
>  > If I am reading this correctly, the only package affected would be
>  > drgn (from python-drgn).
>  > It should hopefully just need a rebuild.
>  > Is that correct?
>  > Were you planning on rebuilding python-drgn, or contacting the
>  > package maintainer and having them do it?
>  > 
>  
>  He's a co-maintainer of python-drgn, so I assume he's going to
>  rebuild it himself.
>   
Correct to both. Only drgn is affected, and Davide and I maintain it so
we'll get it rebuilt as a set.

Thanks,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Troy Dawson]

On Wed, Feb 8, 2023 at 1:19 PM Michel Alexandre Salim <
salimma(a)fedoraproject.org&gt; wrote:

>  On Wed, 2023-02-08 at 14:09 -0500, Neal Gompa wrote:
>  > On Wed, Feb 8, 2023 at 12:37 PM Troy Dawson <tdawson(a)redhat.com&gt;
>  > wrote:
>  > >
>  > > On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim
>  > > <salimma(a)fedoraproject.org&gt; wrote:
>  > > >
>  > > > Hi all,
>  > > >
>  > > > Per the incompatible upgrade policy[1] I'm proposing upgrading
>  > > > libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
>  > > >
>  > > > Bugzilla issues:
>  > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1
>  > > > in
>  > > > general)
>  > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
>  > > >
>  > > > Up to 0.4.1, libkdumpfile was packaged without the test suite
>  > > > being
>  > > > run, and when I started work on packaging it in Debian I noticed
>  > > > a lot
>  > > > of test failures on non-x86_64 architectures:
>  > > > https://github.com/ptesarik/libkdumpfile/issues/40
>  > > >
>  > > > This is now fixed (0.5.0 is the first version to pass tests
>  > > > cleanly
>  > > > without additional patches on Fedora), but prior to its release
>  > > > we were
>  > > > basically building in Fedora from a post-0.4.1 snapshot
>  > > > (
>  > > > https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af83
>  > > > 26562a155581d77f04f2ae84197/f/libkdumpfile.spec)
>  > > > that is likely not ABI compatible with the original 0.4.1 anyway,
>  > > > so
>  > > > there's no reasonable way to backport the architecture fixes to
>  > > > 0.4.1.
>  > > >
>  > > > Change in sonames:
>  > > >
>  > > > [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora
>  > > > rawhide --
>  > > > provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-
>  > > > stream
>  > > > 9 --provides libkdumpfile 2>/dev/null)
>  > > >         libaddrxlat.so.2()(64bit)
>  > > >         libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
>  > > > libaddrxlat.so.3
>  > > > libaddrxlat.so.3()(64bit)
>  > > > libaddrxlat.so.3(LIBADDRXLAT_0)
>  > > > libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
>  > > >         libkdumpfile = 0.4.1-5.el9
>  > > > libkdumpfile = 0.5.0-3.fc38
>  > > > libkdumpfile(x86-32) = 0.5.0-3.fc38
>  > > >         libkdumpfile(x86-64) = 0.4.1-5.el9
>  > > > libkdumpfile(x86-64) = 0.5.0-3.fc38
>  > > > libkdumpfile.so.10
>  > > > libkdumpfile.so.10()(64bit)
>  > > > libkdumpfile.so.10(LIBKDUMPFILE_0)
>  > > > libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
>  > > >         libkdumpfile.so.9()(64bit)
>  > > >         libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
>  > > >
>  > > > Only drgn currently depends on libkdumpfile, and I plan to
>  > > > rebuild it
>  > > > in the same updates:
>  > > >
>  > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>  > > > whatrequires "libaddrxlat.so.2()(64bit)"
>  > > > Last metadata expiration check: 0:12:30 ago on Wed Feb  8
>  > > > 11:02:35
>  > > > 2023.
>  > > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>  > > > libkdumpfile-util-0:0.4.1-5.el9.x86_64
>  > > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>  > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>  > > > whatrequires "libkdumpfile.so.9()(64bit)"
>  > > > Last metadata expiration check: 0:12:40 ago on Wed Feb  8
>  > > > 11:02:35
>  > > > 2023.
>  > > > drgn-0:0.0.22-1.el9.x86_64
>  > > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>  > > > libkdumpfile-util-0:0.4.1-5.el9.x86_64
>  > > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>  > > >
>  > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-
>  > > > legacy 8 --
>  > > > whatrequires "libaddrxlat.so.2()(64bit)"
>  > > > Last metadata expiration check: 0:00:08 ago on Wed Feb  8
>  > > > 11:15:35
>  > > > 2023.
>  > > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>  > > > libkdumpfile-util-0:0.4.1-5.el8.x86_64
>  > > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>  > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-
>  > > > legacy 8 --
>  > > > whatrequires "libkdumpfile.so.9()(64bit)"
>  > > > Last metadata expiration check: 0:00:16 ago on Wed Feb  8
>  > > > 11:15:35
>  > > > 2023.
>  > > > drgn-0:0.0.22-1.el8.x86_64
>  > > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>  > > > libkdumpfile-util-0:0.4.1-5.el8.x86_64
>  > > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>  > > >
>  > > > [1]:
>  > > >
>  https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>  > > >
>  > > > Thanks,
>  > >
>  > >
>  > > If I am reading this correctly, the only package affected would be
>  > > drgn (from python-drgn).
>  > > It should hopefully just need a rebuild.
>  > > Is that correct?
>  > > Were you planning on rebuilding python-drgn, or contacting the
>  > > package maintainer and having them do it?
>  > >
>  >
>  > He's a co-maintainer of python-drgn, so I assume he's going to
>  > rebuild it himself.
>  >
>  Correct to both. Only drgn is affected, and Davide and I maintain it so
>  we'll get it rebuilt as a set.
>
>  Thanks,
>  
Sounds good.
Thank you for announcing it and following the steps.

[Michel Alexandre Salim]

On Wed, Feb 08, 2023 at 02:31:39PM -0800, Troy Dawson wrote:
>  > > >
>  > > >
>  > > > If I am reading this correctly, the only package affected would be
>  > > > drgn (from python-drgn).
>  > > > It should hopefully just need a rebuild.
>  > > > Is that correct?
>  > > > Were you planning on rebuilding python-drgn, or contacting the
>  > > > package maintainer and having them do it?
>  > > >
>  > >
>  > > He's a co-maintainer of python-drgn, so I assume he's going to
>  > > rebuild it himself.
>  > >
>  > Correct to both. Only drgn is affected, and Davide and I maintain it so
>  > we'll get it rebuilt as a set.
>  >
>  > Thanks,
>  >
>  
>  Sounds good.
>  Thank you for announcing it and following the steps. 
Per the discussion in the EPEL meeting today, this is good to go ahead;
I have done the builds and put up Bodhi updates:

https://bodhi.fedoraproject.org/updates/?search=0.5.1&packages=libkdu...

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2