On Mon, Aug 15, 2016 at 03:16:48PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> We have agreed to use the major as the ABI-version, so talk about major
> to avoid confusion.
>
> Remove unncessary or incorrect wording related to breaking ABI on minor
> bumps.
>
> Explain a little abou
On 15/08/2016 14:16, Pekka Paalanen wrote:
From: Pekka Paalanen
We have agreed to use the major as the ABI-version, so talk about major
to avoid confusion.
Remove unncessary or incorrect wording related to breaking ABI on minor
bumps.
Explain a little about the weston vs. libweston version nu
From: Pekka Paalanen
We have agreed to use the major as the ABI-version, so talk about major
to avoid confusion.
Remove unncessary or incorrect wording related to breaking ABI on minor
bumps.
Explain a little about the weston vs. libweston version numbers.
v2:
- Add a paragraph about ABI break
On Mon, 15 Aug 2016 17:11:23 +0800
Jonas Ådahl wrote:
> On Wed, Aug 10, 2016 at 03:01:13PM +0300, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > WE have agreed to use the major as the ABI-version, so talk about major
>
> Typo? Or do you emphasize WE? :P
KEY_E down event accidentally
On Wed, Aug 10, 2016 at 03:01:13PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> WE have agreed to use the major as the ABI-version, so talk about major
Typo? Or do you emphasize WE? :P
> to avoid confusion.
>
> Remove unncessary or incorrect wording related to breaking ABI on minor
From: Pekka Paalanen
WE have agreed to use the major as the ABI-version, so talk about major
to avoid confusion.
Remove unncessary or incorrect wording related to breaking ABI on minor
bumps.
Explain a little about the weston vs. libweston version numbers.
Signed-off-by: Pekka Paalanen
---
R
On Fri, 22 Jul 2016 14:51:49 +0100
Emil Velikov wrote:
> Hi all,
>
> Here is hopefully the final take on the series of the topic in question.
> The changes:
>
> - Reworked the README, elaborating on why and how to use
> REQUIRE_LIBWESTON_API_VERSION (what to write in your configure), how to
On 22/07/2016 15:51, Emil Velikov wrote:
From: Emil Velikov
Use the documented libweston-$major.so.0.$minor.$patch scheme.
An (almost) identical one is used by GLIB, GDK{2,3}, QT5, json-glib and
others.
Signed-off-by: Emil Velikov
---
I kind of agree with Quentin that the revision log isn't
ation about parallel installability, see
http://ometer.com/parallel.html
+Versioning scheme
+-
+
+In order to provide consistent, easy to use versioning, libweston
+follows the rules in the Apache Portable Runtime Project
+http://apr.apache.org/versioning.html.
+
+The document provide
From: Emil Velikov
Use the documented libweston-$major.so.0.$minor.$patch scheme.
An (almost) identical one is used by GLIB, GDK{2,3}, QT5, json-glib and
others.
Signed-off-by: Emil Velikov
---
I kind of agree with Quentin that the revision log isn't too helpful
in the commit message in this c
http://ometer.com/parallel.html
+Versioning scheme
+-
+
+In order to provide consistent, easy to use versioning, libweston
+follows the rules in the Apache Portable Runtime Project
+http://apr.apache.org/versioning.html.
+
+The document provides the full details, with the gist summed
Hi all,
Here is hopefully the final take on the series of the topic in question.
The changes:
- Reworked the README, elaborating on why and how to use
REQUIRE_LIBWESTON_API_VERSION (what to write in your configure), how to
avoid forward compat and misc working improvements.
- There is a com
On Fri, 15 Jul 2016 18:11:57 +0200 (CEST)
Jan Engelhardt wrote:
> On Friday 2016-07-15 15:30, Pekka Paalanen wrote:
> >> >OTOH, would adding a new libweston MAJOR in an already stable and
> >> >released binary distribution be absolutely forbidden? It would by
> >> >definition not affect anything
On Friday 2016-07-15 15:30, Pekka Paalanen wrote:
>> >OTOH, would adding a new libweston MAJOR in an already stable and
>> >released binary distribution be absolutely forbidden? It would by
>> >definition not affect anything the distribution was released with,
>> >unless libweston's dependencies c
On Wed, 13 Jul 2016 16:53:27 +0200 (CEST)
Jan Engelhardt wrote:
> On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote:
> >
> >I think Quentin raised a good point, though. In source-based
> >distros, well, in Gentoo at least which I use almost exclusively,
> >there are no separate -devel packages.
On Thursday 2016-07-14 17:33, Emil Velikov wrote:
>
>The keypoint here is that one should _not_ need to uninstall
>libdb-4_5-devel in order to have libdb-4_8-devel and vice-versa.
>This is what parallel installability is all about (afaict).
It is indeed what it is about.
But is it _necessary_ to
On 13 July 2016 at 15:53, Jan Engelhardt wrote:
>
> On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote:
>>
>>I think Quentin raised a good point, though. In source-based
>>distros, well, in Gentoo at least which I use almost exclusively,
>>there are no separate -devel packages.
>
> A package is,
On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote:
>
>I think Quentin raised a good point, though. In source-based
>distros, well, in Gentoo at least which I use almost exclusively,
>there are no separate -devel packages.
A package is, abstractly, merely a selected subset of `make install`
arti
ltiple libweston MAJORs.
It's good have a seasoned packager like you (thanks for the
introduction, puts your comments in whole different perspective for
me!) to comment on these things. There are more issues I'd like
someone to sanity-check after this versioning issue gets resolved.
It
On Monday 2016-07-11 16:44, Emil Velikov wrote:
>> Without pkgconfig supporting some new alias tag (hint, hint) to cover
>> such a case,
>No idea what such a "alias tag" is supposed to do/look like. Do you
>have examples ?
Proposed concept would be to make pkgconfig recognize
a new Alias directiv
On 11 July 2016 at 17:58, Jan Engelhardt wrote:
>
> On Monday 2016-07-11 16:44, Emil Velikov wrote:
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.
>>>
>>> I read it now, and I do not buy it - at least not for 2016 standards.
>>> According to the page, it was
On Monday 2016-07-11 16:44, Emil Velikov wrote:
>>>http://ometer.com/parallel.html. I would strongly recommend giving it
>>>a look.
>>
>> I read it now, and I do not buy it - at least not for 2016 standards.
>> According to the page, it was written in 2002, and I can confirm that
>> the situation
we need to keep them together for now.
>> >
>> If there were more developers, one could also move the tests into a
>> separate repo. Although that (plus libweston) would require extensive
>> audit of the private and public headers since atm, things are quite
>> fr
On 9 July 2016 at 16:32, Pekka Paalanen wrote:
> On Thu, 7 Jul 2016 20:08:40 +0200
> Quentin Glidic wrote:
>
>> On 07/07/2016 18:11, Emil Velikov wrote:
>> > On 7 July 2016 at 10:05, Pekka Paalanen wrote:
>> >>
>> >> [snip]
>> >>
>> >> Now that you mentioned the semantics could be of upper or l
On 10 July 2016 at 13:23, Jan Engelhardt wrote:
>
> On Sunday 2016-07-10 12:46, Emil Velikov wrote:
>>> PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
>>> ...repeat the fun...
>>> ])]
>>>
>>Yes, it's one line of fun for each version that you want to be
>>compatible with. It's
On Sunday 2016-07-10 13:13, Quentin Glidic wrote:
>
> If we install only one .pc file:
> - You cannot develop against an old version.
I do not feel that is true. If you have Berkeley DB 4.5 in tarball
form, you can build and `make install` it. Provided the SONAME is
different (it is; libdb-4.5.so
On Sunday 2016-07-10 12:46, Emil Velikov wrote:
>> PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
>> ...repeat the fun...
>> ])]
>>
>Yes, it's one line of fun for each version that you want to be
>compatible with. It's not ideal, but it's a price to pay, for keeping
>things c
at you "update me in lockstep" everytime you look
at them because you modify one of them.
AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27
I’d do some m4 magic. We have a well-defined versioning scheme (.90
post-release bump)
On 10 July 2016 at 11:11, Jan Engelhardt wrote:
>
> On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
>>>
>>> First, what kind of parallel installability is sought?
>>>
>>> * just runtime
>>> * parallel development environment (like what e.g. libabw,
>>> librevenge.. do)
>>
>>everything that i
On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
>>
>> First, what kind of parallel installability is sought?
>>
>> * just runtime
>> * parallel development environment (like what e.g. libabw,
>> librevenge.. do)
>
>everything that is about libweston including development enviroment
>has be
heck' in libweston to be useless,
> > so we need to keep them together for now.
> >
> If there were more developers, one could also move the tests into a
> separate repo. Although that (plus libweston) would require extensive
> audit of the private and public headers since atm, thin
On Sat, 9 Jul 2016 05:19:26 +0200 (CEST)
Jan Engelhardt wrote:
> On Thursday 2016-07-07 11:46, Pekka Paalanen wrote:
> >> >> +AC_SUBST([LIBWESTON_VERSION],
> >> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
> >> >>
> >> >
> >> > That makes packaging a pain. Al
On Thu, 7 Jul 2016 20:08:40 +0200
Quentin Glidic wrote:
> On 07/07/2016 18:11, Emil Velikov wrote:
> > On 7 July 2016 at 10:05, Pekka Paalanen wrote:
> >>
> >> [snip]
> >>
> >> Now that you mentioned the semantics could be of upper or lower
> >> limit, the name should imply the meaning. I onl
On Thursday 2016-07-07 11:46, Pekka Paalanen wrote:
>> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>> >>
>> >
>> > That makes packaging a pain. Although the whole libweston (supposedly
>> > parallel-installable) is already a
On 8 July 2016 at 12:00, Quentin Glidic wrote:
> On 08/07/2016 12:52, Emil Velikov wrote:
>>
>> On 7 July 2016 at 19:08, Quentin Glidic
>> wrote:
>>>
>>> On 07/07/2016 18:11, Emil Velikov wrote:
On 7 July 2016 at 10:05, Pekka Paalanen wrote:
>
>
>
> [snip]
>>>
>>>
On 08/07/2016 13:00, Quentin Glidic wrote:
On 08/07/2016 12:52, Emil Velikov wrote:
On 7 July 2016 at 19:08, Quentin Glidic
wrote:
On 07/07/2016 18:11, Emil Velikov wrote:
On 7 July 2016 at 10:05, Pekka Paalanen wrote:
[snip]
Now that you mentioned the semantics could be of upper or
On 08/07/2016 12:52, Emil Velikov wrote:
On 7 July 2016 at 19:08, Quentin Glidic wrote:
On 07/07/2016 18:11, Emil Velikov wrote:
On 7 July 2016 at 10:05, Pekka Paalanen wrote:
[snip]
Now that you mentioned the semantics could be of upper or lower
limit, the name should imply the meani
On 7 July 2016 at 19:08, Quentin Glidic wrote:
> On 07/07/2016 18:11, Emil Velikov wrote:
>>
>> On 7 July 2016 at 10:05, Pekka Paalanen wrote:
>>>
>>>
>>> [snip]
>
>>>
>>> Now that you mentioned the semantics could be of upper or lower
>>> limit, the name should imply the meaning. I only thought
On 07/07/2016 18:11, Emil Velikov wrote:
On 7 July 2016 at 10:05, Pekka Paalanen wrote:
>> [snip]
Now that you mentioned the semantics could be of upper or lower
limit, the name should imply the meaning. I only thought of using
it as both lower limit (as in pkg-config check) *and* upper lim
On segunda-feira, 4 de julho de 2016 15:23:51 PDT Emil Velikov wrote:
> +Similar approach is used by ATK, QT and KDE programs/libraries,
Qt, with a lowercase t.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
_
to separate
> repositories can happen any time soon, because of the test suite
> that is specific to weston. I do not want to duplicate the test
> suite, and I do not want 'make check' in libweston to be useless,
> so we need to keep them together for now.
>
If there were
N alike macros does
>> >> not get in the way of development. Yet it's up-to you guys to make the
>> >> call.
>> >>
>> >> -Emil
>> >> ---
>> >> README | 46 ++
>> >
2c again:
I don't think splitting weston and libweston to separate
repositories can happen any time soon, because of the test suite
that is specific to weston. I do not want to duplicate the test
suite, and I do not want 'make check' in libweston to be useless,
so we need to keep
gt; >> ---
> >> README | 46 ++
> >> 1 file changed, 46 insertions(+)
> >>
> >> diff --git a/README b/README
> >> index 126df4d..72e8c7c 100644
> >> --- a/README
> >> +++ b/README
> >> @@ -70,6 +7
e
>> call.
>>
>> -Emil
>> ---
>> README | 46 ++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/README b/README
>> index 126df4d..72e8c7c 100644
>> --- a/README
>> +++ b/README
>
On Mon, 4 Jul 2016 16:17:08 +0100
Emil Velikov wrote:
> On 4 July 2016 at 15:55, Pekka Paalanen wrote:
> > On Mon, 4 Jul 2016 15:23:48 +0100
> > Emil Velikov wrote:
> >
> >> Hi all,
> >>
> >> Here is a respin of the earlier series which changes how libweston is
> >> named, and thus shipped.
/README
> index 126df4d..72e8c7c 100644
> --- a/README
> +++ b/README
> @@ -70,6 +70,52 @@ For more information about parallel installability, see
> http://ometer.com/parallel.html
>
>
> +Versioning scheme
> +-
> +
> +In order to provide consist
-0}.pc.in ?
>> - Drop the s/LIBWESTON_ABI_VERSION/LIBWESTON_MAJOR/ hunk ?
>> - Keep the configure libweston_*_version variables shorter ?
>> - Yes, the LT_VERSION_INFO hunk looks a bit nasty, yet this is what GTK
>> is doing, once you unraver the 2-3 layers of variables. I
On 4 July 2016 at 15:55, Pekka Paalanen wrote:
> On Mon, 4 Jul 2016 15:23:48 +0100
> Emil Velikov wrote:
>
>> Hi all,
>>
>> Here is a respin of the earlier series which changes how libweston is
>> named, and thus shipped. I believe all the logic/reasoning is explicitly
>> stated, although if som
On Mon, 4 Jul 2016 15:23:48 +0100
Emil Velikov wrote:
> Hi all,
>
> Here is a respin of the earlier series which changes how libweston is
> named, and thus shipped. I believe all the logic/reasoning is explicitly
> stated, although if something feels amiss, please let me know.
>
> NOTE: WARN
this is what GTK
is doing, once you unraver the 2-3 layers of variables. It works as
expected though, and I'd imagine others are doing a similar trick.
fixup! libweston: use new versioning scheme
Looks good. A bit hard to read but I thing you at least build-tested it. :-)
I think you can dro
On 04/07/2016 16:23, Emil Velikov wrote:
Hi all,
Here is a respin of the earlier series which changes how libweston is
named, and thus shipped. I believe all the logic/reasoning is explicitly
stated, although if something feels amiss, please let me know.
NOTE: WARNING: The series exposes a fata
the 2-3 layers of variables. It works as
expected though, and I'd imagine others are doing a similar trick.
fixup! libweston: use new versioning scheme
---
Makefile.am | 24
compositor/weston.pc.in | 2 +-
configure.ac| 12 +---
3
Hi all,
Here is a respin of the earlier series which changes how libweston is
named, and thus shipped. I believe all the logic/reasoning is explicitly
stated, although if something feels amiss, please let me know.
NOTE: WARNING: The series exposes a fatal bug in weston thus the tests
fail to b
1 file changed, 46 insertions(+)
diff --git a/README b/README
index 126df4d..72e8c7c 100644
--- a/README
+++ b/README
@@ -70,6 +70,52 @@ For more information about parallel installability, see
http://ometer.com/parallel.html
+Versioning scheme
+-
+
+In order to provide cons
On Fri, 3 Jun 2016 14:27:39 +0100
Emil Velikov wrote:
> From: Emil Velikov
>
> Use libweston-$major.so.0.$minor.$patch over the current scheme.
Hi,
is that really a commonly used versioning pattern?
Could you add a reference to the project you used as an example?
Is that project
From: Emil Velikov
Use libweston-$major.so.0.$minor.$patch over the current scheme.
It allows for separation (distinction) of the backwards incompatible
changes from forward compatible feature/bugfix ones.
TODO:
- Check if we need the -@LIBWESTON_VERSION_MAJOR@ headers changes.
- Check where
actice in X (and in Wayland/Weston), and
> gives us an easy shorthand way to quickly communicate dependencies that
> most people will immediately understand.
The difference is that X, weston, wayland, cairo and what not will have
relevant patches in git that others depend on, while when
wayland-protocols sees re
rent git"
seems to be a widespread practice in X (and in Wayland/Weston), and
gives us an easy shorthand way to quickly communicate dependencies that
most people will immediately understand.
> > > > > I would not want to have a release of wayland-protocols before the
> >
to have a release of wayland-protocols before the
> > > > weston patches have been reviewed either.
> > > >
> > > > I suggest we make a wayland-protocols version number policy that allows
> > > > other projects to depend on master between releases. We
>
> > > I would not want to have a release of wayland-protocols before the
> > > weston patches have been reviewed either.
> > >
> > > I suggest we make a wayland-protocols version number policy that allows
> > > other projects to depend on master b
etween releases. We already do
> > this with Wayland and Weston by having a version bump to 1.x.90 right
> > after the release of 1.x.0. Another way would be to use even vs. odd
> > versions like Pixman does.
> >
> > How should we redefine the versioning, add a third number
r.
>
> I suggest we make a wayland-protocols version number policy that allows
> other projects to depend on master between releases. We already do
> this with Wayland and Weston by having a version bump to 1.x.90 right
> after the release of 1.x.0. Another way would be to use even
llows
other projects to depend on master between releases. We already do
this with Wayland and Weston by having a version bump to 1.x.90 right
after the release of 1.x.0. Another way would be to use even vs. odd
versions like Pixman does.
How should we redefine the versioning, add a third number
This isn't the final 0.8.0 API yet, but we might as well get started.
Signed-off-by: Peter Hutterer
---
src/Makefile.am | 5 ++-
src/libinput.sym | 117 +++
2 files changed, 120 insertions(+), 2 deletions(-)
create mode 100644 src/libinput.
On Thursday 2014-09-11 23:28, Peter Hutterer wrote:
>>
>> This sounds like a good idea. I have not pushed it yet though because
>> I'd want to avoid adding the symbols that will be deprecated in the
>> coming release (libinput_device_get_keys and libinput_device_calibrate).
>
>can we run the symbo
On Thursday 2014-09-11 22:55, Jonas Ådahl wrote:
>On Wed, Sep 10, 2014 at 01:32:25AM +0200, Jan Engelhardt wrote:
>> Symbol versions provide a means by which ELF utilities can determine
>> whether a program is incompatible with a too-old library version so
>> that package management tools can auto
Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.
Signed-off-by: Jan Engelhardt
---
The name chosen for symbols
Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.
Signed-off-by: Jan Engelhardt
---
src/Makefile.am | 3 +-
On Thu, Sep 11, 2014 at 11:45:24PM +0200, Jan Engelhardt wrote:
> On Thursday 2014-09-11 23:28, Peter Hutterer wrote:
> >>
> >> This sounds like a good idea. I have not pushed it yet though because
> >> I'd want to avoid adding the symbols that will be deprecated in the
> >> coming release (libinp
On Thu, Sep 11, 2014 at 10:55:43PM +0200, Jonas Ådahl wrote:
> On Wed, Sep 10, 2014 at 01:32:25AM +0200, Jan Engelhardt wrote:
> > Symbol versions provide a means by which ELF utilities can determine
> > whether a program is incompatible with a too-old library version so
> > that package management
On Wed, Sep 10, 2014 at 01:32:25AM +0200, Jan Engelhardt wrote:
> Symbol versions provide a means by which ELF utilities can determine
> whether a program is incompatible with a too-old library version so
> that package management tools can autodetect version-based
> dependencies and suggest upgrad
On Tue, Sep 09, 2014 at 07:08:46PM +0200, Jan Engelhardt wrote:
> Symbol versions provide a means by which ELF utilities can determine
> whether a program is incompatible with a too-old library version so
> that package management tools can autodetect version-based
> dependencies and suggest upgrad
There have been a lot of questions asked lately about versioning of
interfaces and protocol objects. This addition to the documentation should
clear up some of those questions.
Signed-off-by: Jason Ekstrand
---
doc/publican/sources/Protocol.xml | 61 +++
1
On Sun, Aug 18, 2013 at 1:28 AM, Bardur Arantsson wrote:
> On 2013-08-18 00:31, Jason Ekstrand wrote:
> > There have been a lot of questions asked lately about versioning of
> > interfaces and protocol objects. This addition to the documentation
> should
> > clear up
On 2013-08-18 00:31, Jason Ekstrand wrote:
> There have been a lot of questions asked lately about versioning of
> interfaces and protocol objects. This addition to the documentation should
> clear up some of those questions.
>
> +
> + In order to keep things sa
There have been a lot of questions asked lately about versioning of
interfaces and protocol objects. This addition to the documentation should
clear up some of those questions.
Signed-off-by: Jason Ekstrand
---
doc/publican/sources/Protocol.xml | 63 +++
1
In previous versions of libwayland the version of the global that was
advertised to the client was taken from the wl_interface object. This has
two problems. First it makes it impossible for a compositor to only
support a lower version than the version against which it was built.
Second, since th
This series adds version information to wl_resource and wl_global to allow
for more correct versioning. In order to not break ABI with current EGL
implementations, new versions of wl_display_add_global and
wl_client_add/new_object were added instead of simply adding arguments to
the old versions
This series converts weston to use the new resource versioning API.
Jason Ekstrand (3):
Add a MIN macro
window: Request version 3 of wl_compositor
Add version arguments to wl_client_add/new_object calls
clients/window.c| 2 +-
src/compositor.c| 16 +---
src
This patch series adds version information to wl_resource so that we can
detect invalid requests based on version at the libwayland level. This
series is based on the wl_resource_opaque patch so it is included.
P.S. Kristian, I think I'm ok with the #ifdef guards around wl_resource
etc. for whate
On Fri, May 24, 2013 at 11:40:24AM +0200, al...@redhat.com wrote:
> From: Alexander Larsson
>
> New in this version:
> * We look up the private with wl_signal_get
> * Fixed off-by-one error in method_counts array lookup
> (version 1 is at offset 0)
I talked to Jason about a different approach
From: Alexander Larsson
New in this version:
* We look up the private with wl_signal_get
* Fixed off-by-one error in method_counts array lookup
(version 1 is at offset 0)
Alexander Larsson (2):
wl_resource: Add version field and getter/setter
wayland-server: Version check requests
src/sc
Hi
While reading wayland-dev on gmane I saw some confusion about versioning.
I highly recommend reading
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf and
implementing semantic versioning for your interfaces.
It will solve all confusion about versions :-)
--
Ferry Huberts
On Fri, 30 Nov 2012 17:15:44 -0500
Kristian Høgsberg wrote:
...
> On Fri, Nov 23, 2012 at 09:49:58PM -0500, Kristian Høgsberg wrote:
> > We need to either require wayland 1.0.2 in configure.ac or make this
> > call conditionaly on wayland version > 1.0.2. We have
> > wayland-version.h, so I'd pre
85 matches
Mail list logo
