Current tinderbox regression (libXi)

Paulo César Pereira de Andrade pcpa at mandriva.com.br
Thu Jan 29 19:48:36 PST 2009


Peter Hutterer wrote:
> On Fri, Jan 30, 2009 at 01:02:50AM -0200, Paulo César Pereira de Andrade
> wrote:
>> Chris Ball wrote:
>> > http://tinderbox.x.org/builds/2009-01-29-0034/logs/libXi/#configure
>> >
>> > configure: error: Package requirements (xproto >= 7.0.13 x11 >=
>> 1.1.99.1
>> > xextproto >= 7.0.3 xext >= 1.0.99.1 inputproto >= 1.9.99.6) were not
>> > met:
>> >
>> > Requested 'xext >= 1.0.99.1' but version of Xext is 1.0.5
>>
>>   I think this is kind of a flaw in
>> http://xorg.freedesktop.org/wiki/Development/Documentation/VersionNumberScheme
>> that may happen in other packages if for some reason an
>> intermediate release must be done. In this case it was done
>> to ensure people building from tarballs would not have
>> these kinds of issues.
>>
>>   The correction would be to either make git libXi require
>> xext >= 1.0.5, or change back git version of xext to 1.0.99.1.
>
> Why didn't you release libXext as 1.1, as the version numbering would have
> suggested?

  I considered it, but I thought it would be unpolite to
"somehow" officially releasing your work without consulting
you. And I did it just to match the changes in xextproto,
so that build from tarballs will happen without problems.

> Adding support for GenericEvents in a patchlevel release doesn't make
> sense,
> especially considering the version number was already on 1.0.99.1 and you
> bumped it back.

  I thought there were no tarballs with the prototypes already
available, but it appears xextproto 7.0.4 already had the
prototypes, but no implementation in libXext 1.0.4...

> Also, git has this nice feature called branching, so if you desperately
> needed
> a 1.0.5 release, why didn't you just branch off 9884a41dd028 and
> cherry-pick
> the fixes over?

  I hope to not need to do this again soon (release a
libfoo due to releasing a minor change to fooproto).
But if needing that, branching for a "quick" release
would be a better option, so that it would not push
other changes, like the addition of Xge.c.

> Cheers,
>   Peter

Paulo




More information about the xorg mailing list