[Xcb] New libxcb and xcb-proto releases (code name: "Oh, shit")

[Ran Benita]

On Sat, Nov 16, 2013 at 03:45:09PM +0100, Uli Schlachter wrote:
> Hi,

Hi Uli and everyone working on this release :)

> On 15.11.2013 21:59, Uli Schlachter wrote:
> > On 15.11.2013 08:18, Arnaud Fontaine wrote:
> [...]
> >> If we follow this idea, it would mean there are the following things to
> >> do before the release from master branch:
> > 
> > Ok, so I guess the "another release from a branch"-idea is dead then and we try
> > to get master into a sane state. I'll try to collect a new todo list for this
> > and send it off tomorrow. But this means that people can review the needed
> > patches and commit them already... :-)
> 
> So here is my list of patches:
> 
> xcb-proto
> - "remove reference to nonexistant enum"
> - "[PATCH libxcb] Fix alignment issues in FD passing code"
> - "sync: add missing namespace for the INT64 struct"
> - "Add NEWS entries for release 1.9"
> 
> libxcb-master:
> - "Add NEWS entries for releases 1.9.1 to 1.9.3"
> - bump XKB soname due to ABI break

I think the conclusion was not to revert, but bump soname instead. This
should be done regardless of xkb enabled by default or not.

> - bump XCB soname (no idea why this would be needed, but Arnaud suggested this.
>   See [1] for vetos ;-) )

[I did not follow the conversation about this, but hopefully this is not
done lightly!].

> - revert 9ae84ad187e2ba440c40f44b8eb21c82c2fdbf12 "fix deadlock with
>   xcb_take_socket/return_socket v3"
> - revert bc6a4f557ff4e497acdafdcebb006e5a7b4c5b11 "Build xcb-xkb by default"
>   (is this needed? xkb's current state confuses me. Someone please tell me.)

Well xcb-xkb is already de-facto enabled by several distros and is used
by several projects. If we wait until we're completely satisfied with it
and certain no more abi/api changes are necessary, then it will simply
never be done...

Instead we should try and be careful not to break ABI again, and if we do,
bump the soname. As for API, I suspect anything substantial will not be
confined to XKB alone, and we should discuss it when it happens (most
likely by Daniel Martin). Finally, Daniel has commented out several of
the more problematic (and least useful) sections of xkb.xml. We can fix
and uncomment them as we wish without committing to them right now.

So my vote here is "yes".

> - Depend on newest xcb-proto release

Yes this is needed.

> Issues left (or at least "Things I collected from the 'Next Release?'-thread"):
> - http://lists.freedesktop.org/archives/xcb/2013-August/008541.html
>   "xkb: Unify events into single event"

This should not go in, it will break existing users which already handle
it themselves (and it's working). A proper fix will hopefully be a part of
the future/theoretical API changes I've mentioned above.

> - https://bugs.freedesktop.org/show_bug.cgi?id=68387
>   "xinput2 XIQueryDevice reply not read correctly"

I've attached a patch with commit message, I think it's safe to apply,
but a third eye would be nice :)

> - http://lists.freedesktop.org/archives/xcb/2013-October/008689.html
>   "every structure having a fixed size field after a variadic field/list is
>   broken!" (Does this have a Bugzilla entry that I didn't find yet? If not, we
>   should create one)

This is somewhat related around the same issues with the code generator:
https://bugs.freedesktop.org/show_bug.cgi?id=70956

But I haven't looked at the issues Daniel mentioned in the mail, so we
should hear his opinion. A bug would be useful indeed.

> - We are renaming things in xcb_ge_event_t (this time on purpose). How are
>   people supposed to deal with it so that they work both with old and new
>   libxcb? There doesn't seem to be a #define which could easily be used for
>   deciding if pad0 or extension is the right field to use.

[Can always use the version string, no?]

Thanks,
Ran