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 sugg
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
https://admin.fedoraproject.org/mailman/lis
Frank Ch. Eigler wrote:
> "Horst H. von Brand" 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 a reason
for keeping autoge
On 04/15/2012 12:33 PM, Kevin Kofler wrote:
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,
You guys seem to be unable to comprehend the differe
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
usa
"Horst H. von Brand" 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
https://admin.fedoraproject.org/mailman/listinfo/devel
Colin Walters 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 generated code chang
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 - keep
m thinking that a
Subject: Re: disruptive libffi upgrade
On Fri, 13 Apr 2012 16:34:55 -0500
Michael Cronenworth 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 simp
On Fri, 13 Apr 2012 16:34:55 -0500
Michael Cronenworth 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 packages.
>
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
Hi,
On Fri, Apr 13, 2012 at 10:06 AM, Colin Walters 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? Or, have you co
On 04/13/2012 03: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.
This affects a number of GNOME packages (~ one
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
> re
On Fri, Apr 13, 2012 at 7:49 AM, Andrew Haley 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 for depen
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.
On Fri, Apr 13, 2012 at 1:59 AM, Anthony Green 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 changes are si
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 h
18 matches
Mail list logo
