On Sat, 2012-04-14 at 10:09 -0400, Colin Walters wrote:
On Fri, 2012-04-13 at 20:58 -0400, Anthony Green wrote:
Sorry folks -- thanks for untagging. I'll ping the list again after May 9,
as was suggested earlier in this thread.
Here's a lightly tested patch which implements my suggestion
Horst H. von Brand wrote:
keeping generated files in git is just dumb.
+1, but IMHO this is true even without the in git addition. Generated
files also have no business being in a source tarball, and IMHO the fact
that the autotools get that wrong entirely disqualifies them from being a
Frank Ch. Eigler f...@redhat.com wrote:
Horst H. von Brand vonbr...@inf.utfsm.cl writes:
[...]
Please go with (3), keeping generated files in git is just dumb.
Please don't demean those who do it for well-considered reasons.
I'm sorry if it came through too abrasive, but I just can't see
Ralf Corsepius wrote:
You guys seem to be unable to comprehend the differences between
generated sources and generated intermediate files.
generated sources is an oxymoron.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
On Fri, 2012-04-13 at 20:58 -0400, Anthony Green wrote:
Sorry folks -- thanks for untagging. I'll ping the list again after May 9,
as was suggested earlier in this thread.
Here's a lightly tested patch which implements my suggestion of keeping
the symbols as empty stubs.
Incidentally -
Colin Walters walt...@verbum.org wrote:
[...]
Incidentally - keeping the generated autotools stuff in git makes
tracking down what *really* changed extremely painful. It looks
like the ABI was bumped in ee6696fdf4768ba6dd037fb6dd99435afa13816e
but that commit has thousands of lines of
Horst H. von Brand vonbr...@inf.utfsm.cl writes:
[...]
Please go with (3), keeping generated files in git is just dumb.
Please don't demean those who do it for well-considered reasons.
- FChE
--
devel mailing list
devel@lists.fedoraproject.org
On Fri, Apr 13, 2012 at 1:59 AM, Anthony Green gr...@redhat.com wrote:
Hello,
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required for dependent packages.
The ABI
On 04/13/2012 01:59 AM, Anthony Green wrote:
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required for dependent packages.
The ABI changes are simply:
1. Some
On Fri, Apr 13, 2012 at 7:49 AM, Andrew Haley a...@redhat.com wrote:
On 04/13/2012 01:59 AM, Anthony Green wrote:
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required
On Thu, 2012-04-12 at 20:59 -0400, Anthony Green wrote:
2. A new function has been introduced to support
variadic functions (ffi_prep_cif_var).
Libtool's guidelines for .so versioning mandate that I move from
libffi.so.5.0.11 to libffi.so.6.0.0 (because functions have been
Hi,
On Fri, Apr 13, 2012 at 10:06 AM, Colin Walters walt...@verbum.org wrote:
You have to temper guidelines with some thought. How recently
have these symbols been introduced? Are you aware of anything that
actually calls them? If nothing does, have you considered simply
removing them?
Anthony Green wrote:
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required for dependent packages.
Can you untag your build for a few weeks? It is too disruptive at the
On Fri, 13 Apr 2012 16:34:55 -0500
Michael Cronenworth m...@cchtml.com wrote:
Anthony Green wrote:
I recently release libffi 3.0.11, and ABI changes are mandating
a .so number change. Despite the ABI change, I suspect that simple
rebuilds are all that will be required for dependent
thinking that a
Subject: Re: disruptive libffi upgrade
On Fri, 13 Apr 2012 16:34:55 -0500
Michael Cronenworth m...@cchtml.com wrote:
Anthony Green wrote:
I recently release libffi 3.0.11, and ABI changes are mandating
a .so number change. Despite the ABI change, I suspect that simple
Hello,
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required for dependent packages.
The ABI changes are simply:
1. Some internal debugging functions that should never
16 matches
Mail list logo
