[PATCH xserver] configure.ac: bump epoxy requirement to 1.2

[Eric Anholt]

Adam Jackson <ajax at redhat.com> writes:

> On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote:
>> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> > > > From: Emil Velikov <emil.velikov at collabora.com>
>> > 
>> > As pointed out in the ABI tracker[1], epoxy has gone through a few
>> > non-backwards compatible ABI changes, yet preserved the DSO name.
>
> I don't particularly object to bumping the required version, but...
>
>> > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
>> > - s/EGLDisplay */EGLDisplay/.
>
> This happens not to matter. If you read the corresponding commit you'll
> see that the parameter was always treated as an opaque pointer anyway:
>
> https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76
>
>> > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
>> > it the canonical/upstream source] and was looking for your blessing.
>> > 
>> > How is that going ? The state of the github repo looks tragic.
>> 
>> ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax.
>
> I'm honestly on anholt's side here about leaving upstream on github.
> fdo is lovely and all but the contribution model for people not already
> in posession of an fdo account is terrible. Moving epoxy to fdo would
> be a step backwards, and we should continue to hold out on that front
> until fdo grows better collaborative hosting.
>
> The more serious issue to me is that epoxy needs a release, and that
> release should involve merging up the various forks on github. (This is
> an argument _in favor_ of github: not only was it easy for people to
> create their forks, but we can track them all down easily.) I'm sure
> epoxy isn't Eric's first priority (which is entirely reasonable) so
> it's kind of up to him how to proceed here.

I've said it before a couple of times, but it stands: The next step for
epoxy is that someone needs to look into YaronCT's fork and decide if we
should just bless it as the maintained upstream.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161025/130c0be7/attachment.sig>