On 06/ 7/12 10:33 PM, Jeremy Huddleston wrote:
> Ah, if we could only throw out *everything* and start again...
Then we wouldn't be working on X! 8-)
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
On Jun 7, 2012, at 05:22, Josh Triplett wrote:
> On Thu, Jun 07, 2012 at 01:22:47AM -0700, Jeremy Huddleston wrote:
>> On Jun 6, 2012, at 15:13, Josh Triplett wrote:
>>> On Wed, Jun 06, 2012 at 02:10:47PM -0700, Jeremy Huddleston wrote:
On Jun 6, 2012, at 4:04 AM, Josh Triplett wrote:
>>>
On Thu, Jun 07, 2012 at 01:22:47AM -0700, Jeremy Huddleston wrote:
> On Jun 6, 2012, at 15:13, Josh Triplett wrote:
> > On Wed, Jun 06, 2012 at 02:10:47PM -0700, Jeremy Huddleston wrote:
> >> On Jun 6, 2012, at 4:04 AM, Josh Triplett wrote:
> >>> On Tue, Jun 05, 2012 at 10:03:44PM -0700, Jeremy H
On Jun 6, 2012, at 15:13, Josh Triplett wrote:
> On Wed, Jun 06, 2012 at 02:10:47PM -0700, Jeremy Huddleston wrote:
>> On Jun 6, 2012, at 4:04 AM, Josh Triplett wrote:
>>> On Tue, Jun 05, 2012 at 10:03:44PM -0700, Jeremy Huddleston wrote:
On Jun 5, 2012, at 6:35 PM, Josh Triplett wrote:
>
On Wed, Jun 06, 2012 at 02:10:47PM -0700, Jeremy Huddleston wrote:
> On Jun 6, 2012, at 4:04 AM, Josh Triplett wrote:
> > On Tue, Jun 05, 2012 at 10:03:44PM -0700, Jeremy Huddleston wrote:
> >> On Jun 5, 2012, at 6:35 PM, Josh Triplett wrote:
> >>> I agree with your statement that from a function
On Jun 6, 2012, at 4:04 AM, Josh Triplett wrote:
> On Tue, Jun 05, 2012 at 10:03:44PM -0700, Jeremy Huddleston wrote:
>> On Jun 5, 2012, at 6:35 PM, Josh Triplett wrote:
>>>
>>> I agree with your statement that from a functional standpoint this holds
>>> true: the linker doesn't seem to enforc
On Tue, Jun 05, 2012 at 10:03:44PM -0700, Jeremy Huddleston wrote:
> On Jun 5, 2012, at 6:35 PM, Josh Triplett wrote:
> >> Take libXi for example, since it's probably fresh in most of our minds.
> >> With Xi2, libXi added a ton of new functionality and remained backwards
> >> compatible. Thus,
On Jun 5, 2012, at 6:35 PM, Josh Triplett wrote:
> [Side note: your mails show up with ridiculously long uwrapped lines,
> which makes them harder to reply to.]
Interesting, the one in my sent folder is quoted-printable with proper-length
lines.
The mail that I see from the list server is 7bi
[Side note: your mails show up with ridiculously long uwrapped lines,
which makes them harder to reply to.]
On Tue, Jun 05, 2012 at 10:37:45AM -0700, Jeremy Huddleston wrote:
> On Jun 4, 2012, at 11:22 PM, Josh Triplett wrote:
> > On Mon, Jun 04, 2012 at 04:24:10PM -0700, Jeremy Huddleston wrote:
On Jun 4, 2012, at 11:22 PM, Josh Triplett wrote:
> On Mon, Jun 04, 2012 at 04:24:10PM -0700, Jeremy Huddleston wrote:
>>
>> On Jun 4, 2012, at 3:25 PM, Josh Triplett wrote:
>>
>>> On Mon, Jun 04, 2012 at 02:52:51PM -0700, Jeremy Huddleston wrote:
On Jun 4, 2012, at 2:19 PM, Adam Jackson
On Mon, Jun 4, 2012 at 16:24:10 -0700, Jeremy Huddleston wrote:
> I guess this is where the "OS X" paradigm and the GNU paradigm just
> break down. Is there actually annotation done to specify that a
> specific function was added for a given minor version bump of a
> library? Does the loader ju
On Mon, Jun 04, 2012 at 04:24:10PM -0700, Jeremy Huddleston wrote:
>
> On Jun 4, 2012, at 3:25 PM, Josh Triplett wrote:
>
> > On Mon, Jun 04, 2012 at 02:52:51PM -0700, Jeremy Huddleston wrote:
> >> On Jun 4, 2012, at 2:19 PM, Adam Jackson wrote:
> >>> On Mon, 2012-06-04 at 14:03 -0700, Jeremy H
Jeremy Huddleston writes:
> Ah, ok. Thanks, it sounded like it was private API. That sounds
> fine, but please try to avoid doing this in the future. IMO, it's
> better to keep around deprecated functionality than it is to bump the
> major version of the library ...
>
> ... also, if
On Mon, Jun 04, 2012 at 02:52:51PM -0700, Jeremy Huddleston wrote:
> On Jun 4, 2012, at 2:19 PM, Adam Jackson wrote:
> > On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote:
> >> On Jun 4, 2012, at 1:34 PM, Julien Cristau wrote:
> >> Think about this from the libc perspective. libc *may h
On Jun 4, 2012, at 6:56 PM, Arnaud Fontaine wrote:
> Hi,
>
> Jeremy Huddleston writes:
>
>> Based on the commit logs, I was under the impression that these
>> functions were only meaningful to already-removed functionality. If
>> the removal of that functionality didn't even warran
Hi,
Jeremy Huddleston writes:
> Based on the commit logs, I was under the impression that these
> functions were only meaningful to already-removed functionality. If
> the removal of that functionality didn't even warrant a version bump,
> why would removing its support APIs?
This f
On Jun 4, 2012, at 3:25 PM, Josh Triplett wrote:
> On Mon, Jun 04, 2012 at 02:52:51PM -0700, Jeremy Huddleston wrote:
>> On Jun 4, 2012, at 2:19 PM, Adam Jackson wrote:
>>> On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote:
On Jun 4, 2012, at 1:34 PM, Julien Cristau wrote:
T
On Jun 4, 2012, at 2:19 PM, Adam Jackson wrote:
> On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote:
>> On Jun 4, 2012, at 1:34 PM, Julien Cristau wrote:
>>> How are the xcb_atom_get_predefined/xcb_atom_get_name_predefined
>>> removals not binary incompatible??
>>
>> Nothing else chan
On Mon, 4 Jun 2012, Jeremy Huddleston wrote:
> On Jun 4, 2012, at 1:34 PM, Julien Cristau wrote:
>
> > On Sat, Jun 2, 2012 at 16:41:02 -0700, Jeremy Huddleston wrote:
> >
> >> Why did "Do not rely anymore on gperf and m4 following removal of
> >> deprecated atoms." do this:
> >>
> >> -libxcb
On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote:
> On Jun 4, 2012, at 1:34 PM, Julien Cristau wrote:
> > How are the xcb_atom_get_predefined/xcb_atom_get_name_predefined
> > removals not binary incompatible??
>
> Nothing else changed, just the removal of the symbols. All other
> funct
On Jun 4, 2012, at 1:34 PM, Julien Cristau wrote:
> On Sat, Jun 2, 2012 at 16:41:02 -0700, Jeremy Huddleston wrote:
>
>> Why did "Do not rely anymore on gperf and m4 following removal of deprecated
>> atoms." do this:
>>
>> -libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined
>> +libx
On Sat, Jun 2, 2012 at 16:41:02 -0700, Jeremy Huddleston wrote:
> Why did "Do not rely anymore on gperf and m4 following removal of deprecated
> atoms." do this:
>
> -libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined
> +libxcb_util_la_LDFLAGS = -version-info 1:0:0 -no-undefined
>
> I
On Jun 3, 2012, at 18:54, Arnaud Fontaine wrote:
> Hello,
>
> Jeremy Huddleston writes:
>
>> Why did "Do not rely anymore on gperf and m4 following removal of
>> deprecated atoms." do this:
>>
>> -libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined
>> +libxcb_util_la_LDFLAGS = -
Arnaud Fontaine writes:
>> How do you want to fix this? Is this a flag day, and it won't happen
>> again, or do you want to do a quick turn-around release of 0.3.10 and
>> recommend that nobody ship 0.3.9?
>
> If I would have to revert this change, I would prefer the first
> option.
Sorr
Hello,
Jeremy Huddleston writes:
> Why did "Do not rely anymore on gperf and m4 following removal of
> deprecated atoms." do this:
>
> -libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined
> +libxcb_util_la_LDFLAGS = -version-info 1:0:0 -no-undefined
>
> I don't see this change requi
Why did "Do not rely anymore on gperf and m4 following removal of deprecated
atoms." do this:
-libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined
+libxcb_util_la_LDFLAGS = -version-info 1:0:0 -no-undefined
I don't see this change requiring a major version bump which should only be
done
26 matches
Mail list logo
