5:11 p.m.
I released a new version of libffi a month or so ago, the first one in 5
years. There's an ABI change that was unavoidable in order to
accommodate the aarch64 port, and the sonumber was bumped.
I am also the Fedora package maintainer for libffi, but admit that I
don't have the time or expertise required to manage an ABI-breaking
libffi upgrade in Fedora (assuming the temporary requirement of a
'compat' package, etc), as there are many packages that depend on this
library.
Should I simply orphan libffi and hope that somebody picks it up? I'm
looking for the best path forward.
Thanks!
AG
--
Anthony Green <green(a)redhat.com>
5:57 p.m.
Il giorno lun, 06/01/2020 alle 18.11 -0500, Anthony Green ha scritto:
I released a new version of libffi a month or so ago, the first one
in 5
years. There's an ABI change that was unavoidable in order to
accommodate the aarch64 port, and the sonumber was bumped.
I am also the Fedora package maintainer for libffi, but admit that I
don't have the time or expertise required to manage an ABI-breaking
libffi upgrade in Fedora (assuming the temporary requirement of a
'compat' package, etc), as there are many packages that depend on
this
library.
If you know all depending packages will get updated in an acceptable
time to the new ABI, you can wait for this to happen, and then rebuild
all in rawhide.
Should I simply orphan libffi and hope that somebody picks it
up? I'm
looking for the best path forward.
I don't think this would be the best
solution! And you are surely the
best packager of your own software.
Thanks!
AG
--
Anthony Green <green(a)redhat.com>
Ciao
Guido
10:02 p.m.
Guido Aulisi <guido.aulisi(a)gmail.com> writes:
If you know all depending packages will get updated in an acceptable
time to the new ABI, you can wait for this to happen, and then rebuild
all in rawhide.
The API is mostly the same. Virtually everything should already build
with the new version (Debian has tested this already). But the upgrade
just isn't that simple. A number of key packages (eg. RPM) depend on
libffi. My understanding is that we'll have to make a 'compat' version
of libffi using the current version, then build/deploy the new version,
and then go back and rebuild all of the dependent packages before
deleting the compat package.
I just don't have time to do this and am looking for help.
AG
--
Anthony Green <green(a)redhat.com>
10:31 p.m.
On Mon, Jan 6, 2020 at 11:02 PM Anthony Green <green(a)redhat.com> wrote:
Guido Aulisi <guido.aulisi(a)gmail.com> writes:
> If you know all depending packages will get updated in an acceptable
> time to the new ABI, you can wait for this to happen, and then rebuild
> all in rawhide.
The API is mostly the same. Virtually everything should already build
with the new version (Debian has tested this already). But the upgrade
just isn't that simple. A number of key packages (eg. RPM) depend on
libffi. My understanding is that we'll have to make a 'compat' version
of libffi using the current version, then build/deploy the new version,
and then go back and rebuild all of the dependent packages before
deleting the compat package.
RPM does not use libffi at all. That said, it's quite easy to do a
rebuild of libffi's reverse dependencies in a side-tag and then merge
it back in. You can always ask for help from releng or other folks
around here to help get it done.
--
真実はいつも一つ！/ Always, there's only one truth!
9:20 a.m.
Neal Gompa <ngompa13(a)gmail.com> writes:
RPM does not use libffi at all.
My bad.. rpmbuild, through it's use of gdb, which requires python, which
requires libffi. So my naive use of mock to try to build a new version
of libffi and all of it's dependencies fail.
That said, it's quite easy to do a
rebuild of libffi's reverse dependencies in a side-tag and then merge
it back in.
Ok, I suppose I'm willing to try, but I have no idea what a side-tag is.
Repoquery tells me there are 192 packages that depend directly on
libffi.
You can always ask for help from releng or other folks
around here to help get it done.
Could somebody please walk me through the first few steps? Maybe start
by explaining side tags?
AG
--
Anthony Green <green(a)redhat.com>
12:48 p.m.
On Tue, Jan 07, 2020 at 10:20:59AM -0500, Anthony Green wrote:
Neal Gompa <ngompa13(a)gmail.com> writes:
> RPM does not use libffi at all.
My bad.. rpmbuild, through it's use of gdb, which requires python, which
requires libffi. So my naive use of mock to try to build a new version
of libffi and all of it's dependencies fail.
> That said, it's quite easy to do a
> rebuild of libffi's reverse dependencies in a side-tag and then merge
> it back in.
Ok, I suppose I'm willing to try, but I have no idea what a side-tag is.
Repoquery tells me there are 192 packages that depend directly on
libffi.
> You can always ask for help from releng or other folks
> around here to help get it done.
Could somebody please walk me through the first few steps? Maybe start
by explaining side tags?
A side tag is a tag in koji where you can build things and they don't
affect other packagers/the real buildroot/tags.
In your libffi master checkout:
fedpkg request-side-tag
and it should give you a tag you can build things into.
Unfortunately since things in the buildroot depend on libffi, you can't
just simply build the new libffi and then rebuild everything in the side
tag, because after you build the new libffi there, the buildroot would
break.
You can make a compat package, but if everything is fine to move to the
new one thats overkill. I don't know if there's anything guideline wise
about this, but easiest might be to add a compat subpackage in the
existing libffi package where you simply copy the old so files from the
existing build in the buildroot, then rebuild against the new libfii in
the side tag, then drop the compat subpackage. I suppose you could also
add both old and new libffi source to the libffi package and build them
both (old to compat), rebuild in side tag and drop the old
sources/compat.
Does that make sense?
If you don't want to/have time to do it, perhaps file a releng ticket
and we can coordinate folks to do it there.
kevin
1 p.m.
If you push changes to the dist-git, I can handle builds and rebuilds.
On Wed, Jan 8, 2020, 19:58 Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, Jan 07, 2020 at 10:20:59AM -0500, Anthony Green wrote:
> Neal Gompa <ngompa13(a)gmail.com> writes:
>
> > RPM does not use libffi at all.
>
> My bad.. rpmbuild, through it's use of gdb, which requires python, which
> requires libffi. So my naive use of mock to try to build a new version
> of libffi and all of it's dependencies fail.
>
> > That said, it's quite easy to do a
> > rebuild of libffi's reverse dependencies in a side-tag and then merge
> > it back in.
>
> Ok, I suppose I'm willing to try, but I have no idea what a side-tag is.
> Repoquery tells me there are 192 packages that depend directly on
> libffi.
>
> > You can always ask for help from releng or other folks
> > around here to help get it done.
>
> Could somebody please walk me through the first few steps? Maybe start
> by explaining side tags?
A side tag is a tag in koji where you can build things and they don't
affect other packagers/the real buildroot/tags.
In your libffi master checkout:
fedpkg request-side-tag
and it should give you a tag you can build things into.
Unfortunately since things in the buildroot depend on libffi, you can't
just simply build the new libffi and then rebuild everything in the side
tag, because after you build the new libffi there, the buildroot would
break.
You can make a compat package, but if everything is fine to move to the
new one thats overkill. I don't know if there's anything guideline wise
about this, but easiest might be to add a compat subpackage in the
existing libffi package where you simply copy the old so files from the
existing build in the buildroot, then rebuild against the new libfii in
the side tag, then drop the compat subpackage. I suppose you could also
add both old and new libffi source to the libffi package and build them
both (old to compat), rebuild in side tag and drop the old
sources/compat.
Does that make sense?
If you don't want to/have time to do it, perhaps file a releng ticket
and we can coordinate folks to do it there.
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
8:53 p.m.
Kevin Fenzi <kevin(a)scrye.com> writes:
I suppose you could also
add both old and new libffi source to the libffi package and build them
both (old to compat), rebuild in side tag and drop the old
sources/compat.
Does that make sense?
I like this idea because it seems simple.
Thanks for the tip!
AG
--
Anthony Green <green(a)redhat.com>
5:24 a.m.
Anthony Green <green(a)redhat.com> writes:
Kevin Fenzi <kevin(a)scrye.com> writes:
> I suppose you could also
> add both old and new libffi source to the libffi package and build them
> both (old to compat), rebuild in side tag and drop the old
> sources/compat.
> Does that make sense?
I like this idea because it seems simple.
I did go this route. I now have a libffi spec file that installs both
the .6 and .7 versions of the library (I didn't even break out the .6
version into a compat package). I'm currently doing local mock builds
of the 90+ packages that depend directly on libffi. Once all of them
build locally, my plan is to commit my franken-package to rawhide and
arrange for those 90+ rawhide packages to be built. Once those are
rebuilt, I simply clean up the libffi spec, removing the .6 version.
Objections?
AG
--
Anthony Green <green(a)redhat.com>
11:46 a.m.
On Fri, Jan 10, 2020 at 06:24:35AM -0500, Anthony Green wrote:
Anthony Green <green(a)redhat.com> writes:
> Kevin Fenzi <kevin(a)scrye.com> writes:
>> I suppose you could also
>> add both old and new libffi source to the libffi package and build them
>> both (old to compat), rebuild in side tag and drop the old
>> sources/compat.
>> Does that make sense?
>
> I like this idea because it seems simple.
I did go this route. I now have a libffi spec file that installs both
the .6 and .7 versions of the library (I didn't even break out the .6
version into a compat package). I'm currently doing local mock builds
of the 90+ packages that depend directly on libffi. Once all of them
build locally, my plan is to commit my franken-package to rawhide and
arrange for those 90+ rawhide packages to be built. Once those are
rebuilt, I simply clean up the libffi spec, removing the .6 version.
Objections?
Sounds good to me. If you run into any issues let me know.
kevin
6:38 a.m.
Kevin Fenzi <kevin(a)scrye.com> writes:
Sounds good to me. If you run into any issues let me know.
I've run three kinds of problems so far...
* programs that link against both libffi and other libraries that link
to libffi (eg. glib2, gobject-introspection). We need to push new
versions of these libraries at the same time as the new libffi. So
once libffi is pushed, many things will be broken until the new glib2
and gobject-introspection are pushed (a case for static linking?)
* I can't get any python to mockbuild, even without the new libffi.
There's an error in the %install process. Known problem?
* ecl fail to build, but it requires code changes. But I am also an admin
on that package and fix it myself. The upstream ecl is already fixed.
AG
--
Anthony Green <green(a)redhat.com>
Senior Principal Solutions Architect, Financial Services
+1 647 477-3809
2:28 p.m.
On Sun, Jan 12, 2020 at 07:38:01AM -0500, Anthony Green wrote:
Kevin Fenzi <kevin(a)scrye.com> writes:
> Sounds good to me. If you run into any issues let me know.
I've run three kinds of problems so far...
* programs that link against both libffi and other libraries that link
to libffi (eg. glib2, gobject-introspection). We need to push new
versions of these libraries at the same time as the new libffi. So
once libffi is pushed, many things will be broken until the new glib2
and gobject-introspection are pushed (a case for static linking?)
Well, this is why the side tag is good... you can build everything there
and then merge the completed side tag builds back in at the same time.
Of course that assumes those things work enough with the mismatched libs
to use in the buildroot, but I would hope so?
* I can't get any python to mockbuild, even without the new
libffi.
There's an error in the %install process. Known problem?
Dunno. Python maintainers?
* ecl fail to build, but it requires code changes. But I am also an
admin
on that package and fix it myself. The upstream ecl is already fixed.
Great!
kevin
4:12 p.m.
On 12. 01. 20 13:38, Anthony Green wrote:
* I can't get any python to mockbuild, even without the new
libffi.
There's an error in the %install process. Known problem?
What does "any python" mean? python26, python27, python3, python39, python37,
python36, python35, python34, pypy, pypy3 all end with the same error?
Could you please share the error here? We track our packages via Koschei and
they should all build fine (in Koji, not sure about mock -- but a difference
like this usually happens during %check, not %install).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:07 p.m.
Hi,
On Mon, Jan 6, 2020, at 6:11 PM, Anthony Green wrote:
I released a new version of libffi a month or so ago, the first one in 5
years. There's an ABI change that was unavoidable in order to
accommodate the aarch64 port, and the sonumber was bumped.
Anthony, I think all of the work you've done on libffi has been very valuable to the
FOSS community. It's good code that has gained widespread use in critical projects
such as glib, python, etc.
But, the burden of being widely used is one needs to be more conservative in changes.
You may remember in fact we discussed this exact same thing a bit less than 7 years ago:
https://lists.fedoraproject.org/pipermail/devel/2012-April/166357.html
At that time, you bumped the soname for a reason that I still don't think was
necessary (removing a debug symbol that probably no one was calling anyways).
Which commit to libffi for aarch64 porting required the ABI bump across all architectures?
8:51 p.m.
"Colin Walters" <walters(a)verbum.org> writes:
Anthony, I think all of the work you've done on libffi has been
very valuable to the FOSS community. It's good code that has gained widespread use in
critical projects such as glib, python, etc.
Thanks Colin!
Which commit to libffi for aarch64 porting required the ABI bump
across all architectures?
It's from 2016...
commit c02c3414440e816aa13a2fe8446484173d3edb0e
Author: Richard Henderson <rth(a)twiddle.net>
Date: Thu Mar 3 13:51:44 2016 -0800
Use ELF symbol versioning
At the same time, we must bump the (major) ABI version. This needed to be
done anyway due to ABI breakage in the AArch64 port (see 12cf89ee and the
corresponding GCC PR70024).
AG
--
Anthony Green <green(a)redhat.com>
1591
days inactive
1597
days old
14 comments
7 participants
participants (7)
-
Anthony Green -
Colin Walters -
Guido Aulisi -
Igor Gnatenko -
Kevin Fenzi -
Miro Hrončok -
Neal Gompa