Re: Release schedule

[Derek Foreman]

On 2018-06-04 07:14 AM, Daniel Stone wrote:
> Hi Pekka,
> 
> On 4 June 2018 at 12:29, Pekka Paalanen  wrote:
>> On Sun, 3 Jun 2018 10:52:49 +0100
>> Daniel Stone  wrote:
>>> On 1 June 2018 at 17:52, Derek Foreman  wrote:
>>> Maybe? There's certainly a ton of change in the tree now, and a few
>>> more which look like they could land (IVI/XDG, the last bits of
>>> atomic, etc). It'd be a pretty hefty release whenever we released it.
>>> I don't have a strong opinion on when we get it out the door, to be
>>> honest.
>>
>> for a project I'm working on, it would be very nice to get the current
>> Weston master released ASAP. OTOH, I'm on vacation from July 12 to
>> Aug 1, so I definitely won't be around at that time.
> 
> I know you didn't mean it like this, but I think it's good to be clear
> that this isn't a corporate demand to fix releases at a certain point.
> That user is just another one of our downstreams and another datapoint
> to take into consideration. (But a good one!)
> 
>> We have been in the development cycle for two months now. How would you
>> feel about trying to get, say, rc1 out around July 10?
>>
>> That would mean rc1 at five weeks from now. I could be around during the
>> alpha and beta time, hoping there wouldn't be much regressions to fix
>> after rc1.
>>
>> Is it too soon? How soon could we do it?
> 
> When does it mean alpha/beta?

I'm traveling from July 16-20, and will have very poor internet access.

This would put as at:
Alpha June 12
Beta June 26
RC1 July 10
Final July 24 (normally we're 1 week between RCs but july 17 is
problematic for me.)

So that's coming up fast.

>> Does it clash with the GitLab migration?
> 
> We've already moved the repos and the site. I think it would be good
> to move our issues just before the release, so by 5.0.0rc (or beta?)
> we had all our issues already in GitLab and could have that as a clean
> cut-off point. From my (migration) point of view, we can absolutely
> have Bugzilla migrated - we could pretty much do that now - and I'm
> moderately confident of having Phabricator migrated by then as well.
> But I don't think it's so bad even if the Phab migration does slip a
> little after the Bugzilla migration.
> 
> If we have split release cycles for Wayland and Weston, we can choose
> to migrate Wayland's bugs later if that makes sense.
> 
>> What do we want to have in the 5.0.0 release?
> 
> I'd want to have the rest of the 'atomic series' (now really about
> overlay plane usage & modifiers) in for sure. It's all got positive
> review and I have some very clearly and definitively carved-out time
> coming in the next week or two to spend on just getting that landed. I
> think it's pretty important to land as it does fix some bugs, and full
> modifier support is becoming more important: we need it in order to
> run on Etnaviv/i.MX at all, it helps RPi, and we don't get composition
> bypass / direct scanout for fullscreen windows on Intel anymore, since
> we need modifiers to describe the client buffers it generates from
> Mesa.

That looks like a fair bit of stuff - can we get there with the proposed
timeline or should we push back?

> I also have some work on weston-debug and IVI shell coming up, but I
> don't think those will get finalised in the next couple of weeks, so
> I'm comfortable giving those more time.

grumble grumble xdg shell stable grumble.

>> How long do we need for the alpha and beta stages?
> 
> I don't have a good answer to this one. I think we've traditionally
> done two weeks for each, right?

That's my recollection, at least for the last release.

 I think we also no longer need to rigidly release wayland and weston at
 the same time, as wayland itself is quite mature and may not receive
 many significant patches during a weston cycle.  I'm wondering if
 libwayland releases should break from timed cycles entirely?
>>>
>>> That sounds good to me. libwayland is so quiet that I don't think we
>>> need to force it out the door every so often; I think moving it out of
>>> forced major releases could get us actually doing patch releases as
>>> well, which would be nice.
>>
>> Sounds fine to me!

Nod, I think patch releases for libwayland make sense now.

So, let's sit on this a little bit to give anyone that thinks this
release comes too soon a chance to speak, and if nobody complains by
June 11 we can go with the June 12 to July 24 plan.

This is a bit of a surprise, so anyone with any reason feel free to stop
me - on or off list if you don't want to make a scene here. ;)

Also, there's been some small change in libwayland, so I'll do them both
at the same time for this round, but in the future we'll only force them
together if there's a compelling reason.

>> Even for Weston, not the least because it would be oh so very convenient
>> for me right now, maybe it would be nice to let people request an early
>> release cycle if there are specific things they would like to have in a
>> release. In case nothing such 

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Emil Velikov]

On 7 June 2018 at 08:46, Daniel Stone  wrote:
> Hi,
>
> On 6 June 2018 at 16:41, Emil Velikov  wrote:
>> On 6 June 2018 at 15:47, Simon McVittie  wrote:
>>> On Wed, 06 Jun 2018 at 15:33:13 +0100, Emil Velikov wrote:
 On 5 June 2018 at 23:06, Daniel Stone  wrote:
 > +  - apt-get -y --no-install-recommends install build-essential automake 
 > autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev 
 > libpixman-1-dev libpng-dev libjpeg-dev libcolord-dev mesa-common-dev 
 > libglu1-mesa-dev libegl1-mesa-dev libgles2-mesa-dev libwayland-dev 
 > libxcb1-dev libxcb-composite0-dev libxcb-xfixes0-dev libxcb-xkb-dev 
 > libx11-xcb-dev libx11-dev libudev-dev libgbm-dev libxkbcommon-dev 
 > libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libxcursor-dev 
 > libmtdev-dev libpam0g-dev libvpx-dev libsystemd-dev libinput-dev 
 > libwebp-dev libjpeg-dev libva-dev liblcms2-dev git

 I think this can be simplify the explicit list to:
 apt-get -y --no-install-recommends build-dep wayland
>>>
>>> Only if the latest version of wayland has the same build-dependencies
>>> as the (likely much older) version visible in the Sources index
>>> for the container's apt configuration. If the container is
>>> Debian 9 'stretch' (released about a year ago) then apt-get build-dep
>>> will get the build-dependencies of wayland 1.12.0, according to
>>> .
>>>
>> Sure, there can be differences. Adding the odd extra piece tends to be
>> shorter and easier (imho) than trying to keep the huge list in sync.
>> Distribution maintainers already that laborious job, why not make use of it.
>
> There are a couple of reasons I typed out the full dependency list.
> One of them is what Simon said, and over time as we get further and
> further away from Stretch, the list of extra stuff we have to add
> grows. Even if we move on to newer Debian, there's also the risk that
> we build things they don't, or some kind of transient dependency drops
> out, so we end up with some breakage. So I prefer the explicit set for
> that reason: it means we can be sure about what we're doing, rather
> than effectively CI'ing the Debian packaging.
>
One could consider build-deps from backports. One could even help the
backports team?
I guess I'm too naive trying to spare the duplication effort?

> Secondly, Stretch was just the easiest starting point: I knew how to
> get it up quickly, in a way where the runtime was also fast (unlike
> with e.g. yum/dnf, where I don't know the necessary runes to speed
> them up). But it's entirely likely we'll want to be testing on other
> distros, or even a very much from-scratch build if we are able to
> reuse the work done on GitLab CI for Mesa here:
>   https://gitlab.com/igalia/graphics/mesa/pipelines/22874845
>
> Either way, having the list of dependencies explictly typed out is
> helpful for whoever's doing the conversion, and it's easy to make sure
> the lists stay in sync if we do have multiple lists.
>
IIRC of all the Linux distros only Arch does not have an equivalent of
build-deps.
Furthermore package names and split varies across distros.

 > +  - make -j4
 > +  - make check
 > +  - make install
 > +  - make distcheck
 I was under the impression that "make -j4 distcheck" is enough
>>>
>>> install and check both imply (depend on) a normal build, so that one is
>>> redundant.
>>>
>>> distcheck runs the tests like check does, but differently-configured,
>>> so for full coverage you might want to do both.
>>>
>>> Similarly, distcheck runs "make install", but into a temporary directory,
>>> not the requested $PREFIX.
>>
>> Right - did not spot that "prefix-*" is also collected as artefacts.
>
> Not just prefix, but also as far as I can see there's no way to
> collect test suite logs from a distcheck run?
If you're want the when logs everything passes, no there isn't a way.
Otherwise, yes - just tweak the regex (example below).

> We've also had
> inexplicable bugs in the past where 'make check' failed but 'make
> distcheck' succeeded (or was it vice-versa?), and given the test
> runtime is still quite short, seemed reasonable enough to explicitly
> test out all of those.
>
Everything aside, this in itself is a fairly valid reason. Currently
the distcheck logs are not fetched though.
The following should help ;-)

- build-*/weston*/_build/sub/*.log
- build-*/weston*/_build/sub/logs

 Alternatively it's worth setting MAKEFLAGS="-jX" once so it's used across 
 all.
>>>
>>> Using -j would definitely help for "make distcheck".
>>>
>>> If parallel install works, it would be good to test it so that it stays
>>> that way: quite a lot of projects can build correctly in parallel, but
>>> don't work reliably for "make -jX install".
>>
>> There has been issues in the past and everything ran fine last time
>> I've checked.
>> That's why I'm suggesting adding the toggle ;-)
>>
>> I'm slightly confused if the 

Re: [PATCH weston 2/2] libweston: Reset repaint schedule for all repainted outputs when repaint cancel

[Pekka Paalanen]

On Tue,  5 Jun 2018 10:37:06 +0900
Tomohito Esaki  wrote:

> All outputs is canceled repaint when a output repaint is failed. At that
> time, the output whose repaint is success is not scheduled because the
> repaint status of that is still REPAINT_AWAITING_COMPLETION. Therefore,
> we need to reset repaint schedule for all repainted outputs.
> 
> Signed-off-by: Tomohito Esaki 
> ---
>  libweston/compositor.c | 8 
>  libweston/compositor.h | 3 +++
>  2 files changed, 11 insertions(+)

Hi Esaki-san,

this is a good first step towards making Weston deal with failing
output updates. Pushed both patches:
   3a80ca06..7f4d9ffe  master -> master


Thanks,
pq

> 
> diff --git a/libweston/compositor.c b/libweston/compositor.c
> index d11a655..91f311d 100644
> --- a/libweston/compositor.c
> +++ b/libweston/compositor.c
> @@ -2450,6 +2450,8 @@ weston_output_maybe_repaint(struct weston_output 
> *output, struct timespec *now,
>   int ret = 0;
>   int64_t msec_to_repaint;
>  
> + output->repainted = false;
> +
>   /* We're not ready yet; come back to make a decision later. */
>   if (output->repaint_status != REPAINT_SCHEDULED)
>   return ret;
> @@ -2479,6 +2481,7 @@ weston_output_maybe_repaint(struct weston_output 
> *output, struct timespec *now,
>   if (ret != 0)
>   goto err;
>  
> + output->repainted = true;
>   return ret;
>  
>  err:
> @@ -2550,6 +2553,11 @@ output_repaint_timer_handler(void *data)
>   compositor->backend->repaint_flush(compositor,
>  repaint_data);
>   } else {
> + wl_list_for_each(output, >output_list, link) {
> + if (output->repainted)
> + weston_output_schedule_repaint_reset(output);
> + }
> +
>   if (compositor->backend->repaint_cancel)
>   compositor->backend->repaint_cancel(compositor,
>   repaint_data);
> diff --git a/libweston/compositor.h b/libweston/compositor.h
> index c2c40ee..8942ab9 100644
> --- a/libweston/compositor.h
> +++ b/libweston/compositor.h
> @@ -212,6 +212,9 @@ struct weston_output {
>*  if set, a repaint will eventually occur. */
>   bool repaint_needed;
>  
> + /** Used only between repaint_begin and repaint_cancel. */
> + bool repainted;
> +
>   /** State of the repaint loop */
>   enum {
>   REPAINT_NOT_SCHEDULED = 0, /**< idle; no repaint will occur */



pgpzDfG_YYfs3.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] scanner: allow referencing foreign enums

[Pekka Paalanen]

On Thu, 7 Jun 2018 10:40:11 +0300
Pekka Paalanen  wrote:

> On Wed, 06 Jun 2018 08:54:16 -0400
> Simon Ser  wrote:
> 
> > On May 29, 2018 9:52 AM, Pekka Paalanen  wrote:  
> > > On Sat, 26 May 2018 09:51:18 +0200
> > > Silvan Jegen  wrote:
> > >
> > > > Hi
> > > >
> > > > On Fri, May 25, 2018 at 05:24:41PM -0400, Simon Ser wrote:
> > > > > It's already possible to reference foreign interfaces, so it
> > > > > should also be possible to reference foreign enums.
> > > > >
> > > > > Signed-off-by: Simon Ser 
> > > > > ---
> > > > >  src/scanner.c | 7 +--
> > > > >  1 file changed, 1 insertion(+), 6 deletions(-)
> > > >
> > > > It looks good to me and I can confirm that this works as intended. If
> > > > no solution allowing for the passing of reference protocols is desired,
> > > > this should be applied.
> > > >
> > > > Reviewed-by: Silvan Jegen 
> > >
> > > Reviewed-by: Pekka Paalanen 
> > >
> > > If no-one objects, I will push this next week. Do ping me if I forget.
> > 
> > Ping :)  
> 
> Hi,
> 
> thanks for the reminder. I'm waiting for the gitlab-ci patch to land,
> so I can see it in action, when I push this patch. Sorry for the delay.

Hi,

this patch is pushed:
   a060822..8b2ba84  master -> master

https://gitlab.freedesktop.org/wayland/wayland/-/jobs/1254
Whee! \o/


Thanks,
pq


pgpWYaB929sLw.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Pekka Paalanen]

On Wed, 6 Jun 2018 15:33:13 +0100
Emil Velikov  wrote:

> Hi Dan,
> 
> On 5 June 2018 at 23:06, Daniel Stone  wrote:
> 
> > +  - apt-get -y --no-install-recommends install build-essential automake 
> > autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev 
> > libpixman-1-dev libpng-dev libjpeg-dev libcolord-dev mesa-common-dev 
> > libglu1-mesa-dev libegl1-mesa-dev libgles2-mesa-dev libwayland-dev 
> > libxcb1-dev libxcb-composite0-dev libxcb-xfixes0-dev libxcb-xkb-dev 
> > libx11-xcb-dev libx11-dev libudev-dev libgbm-dev libxkbcommon-dev 
> > libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libxcursor-dev 
> > libmtdev-dev libpam0g-dev libvpx-dev libsystemd-dev libinput-dev 
> > libwebp-dev libjpeg-dev libva-dev liblcms2-dev git  
> 
> I think this can be simplify the explicit list to:
> apt-get -y --no-install-recommends build-dep wayland

Hi Emil,

you mean weston, not wayland?

Weston's dependencies change more often than wayland's, and now that
there is a list (any list) that works, I'm fine with it.

> > +  - mkdir -p /tmp/.X11-unix
> > +  - chmod 777 /tmp/.X11-unix
> > +
> > +build-native:
> > +  stage: build
> > +  script:
> > +  - git clone --depth=1 
> > git://anongit.freedesktop.org/git/wayland/wayland-protocols
> > +  - export WAYLAND_PROTOCOLS_DIR="$(pwd)/prefix-wayland-protocols"
> > +  - export 
> > PKG_CONFIG_PATH="$WAYLAND_PROTOCOLS_DIR/share/pkgconfig:$PKG_CONFIG_PATH"
> > +  - cd wayland-protocols
> > +  - git show -s HEAD  
> Is this needed?

I have forgot if we decided that it's ok for unreleased commits in
weston to depend on unreleased wayland-protocols. If yes, it makes
sense to me to always use the latest git wayland-protocols.

For the other comments, I agree with Daniel's recent reply.


Thanks,
pq


pgp1Ityi2GaN_.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Daniel Stone]

Hi Emil,
I replied to the rest further down-thread, but:

On 6 June 2018 at 15:33, Emil Velikov  wrote:
> On 5 June 2018 at 23:06, Daniel Stone  wrote:
>> +  - git clone --depth=1 
>> git://anongit.freedesktop.org/git/wayland/wayland-protocols
>> +  - export WAYLAND_PROTOCOLS_DIR="$(pwd)/prefix-wayland-protocols"
>> +  - export 
>> PKG_CONFIG_PATH="$WAYLAND_PROTOCOLS_DIR/share/pkgconfig:$PKG_CONFIG_PATH"
>> +  - cd wayland-protocols
>> +  - git show -s HEAD
> Is this needed?

It's not entirely necessary, but we do get quite verbose output from
the package manager as to which versions etc it's installing; I
figured being more verbose in the logs was better here, so people
could figure out what a particular job was built against.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Daniel Stone]

Hi,

On 6 June 2018 at 16:41, Emil Velikov  wrote:
> On 6 June 2018 at 15:47, Simon McVittie  wrote:
>> On Wed, 06 Jun 2018 at 15:33:13 +0100, Emil Velikov wrote:
>>> On 5 June 2018 at 23:06, Daniel Stone  wrote:
>>> > +  - apt-get -y --no-install-recommends install build-essential automake 
>>> > autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev 
>>> > libpixman-1-dev libpng-dev libjpeg-dev libcolord-dev mesa-common-dev 
>>> > libglu1-mesa-dev libegl1-mesa-dev libgles2-mesa-dev libwayland-dev 
>>> > libxcb1-dev libxcb-composite0-dev libxcb-xfixes0-dev libxcb-xkb-dev 
>>> > libx11-xcb-dev libx11-dev libudev-dev libgbm-dev libxkbcommon-dev 
>>> > libcairo2-dev libpango1.0-dev libgdk-pixbuf2.0-dev libxcursor-dev 
>>> > libmtdev-dev libpam0g-dev libvpx-dev libsystemd-dev libinput-dev 
>>> > libwebp-dev libjpeg-dev libva-dev liblcms2-dev git
>>>
>>> I think this can be simplify the explicit list to:
>>> apt-get -y --no-install-recommends build-dep wayland
>>
>> Only if the latest version of wayland has the same build-dependencies
>> as the (likely much older) version visible in the Sources index
>> for the container's apt configuration. If the container is
>> Debian 9 'stretch' (released about a year ago) then apt-get build-dep
>> will get the build-dependencies of wayland 1.12.0, according to
>> .
>>
> Sure, there can be differences. Adding the odd extra piece tends to be
> shorter and easier (imho) than trying to keep the huge list in sync.
> Distribution maintainers already that laborious job, why not make use of it.

There are a couple of reasons I typed out the full dependency list.
One of them is what Simon said, and over time as we get further and
further away from Stretch, the list of extra stuff we have to add
grows. Even if we move on to newer Debian, there's also the risk that
we build things they don't, or some kind of transient dependency drops
out, so we end up with some breakage. So I prefer the explicit set for
that reason: it means we can be sure about what we're doing, rather
than effectively CI'ing the Debian packaging.

Secondly, Stretch was just the easiest starting point: I knew how to
get it up quickly, in a way where the runtime was also fast (unlike
with e.g. yum/dnf, where I don't know the necessary runes to speed
them up). But it's entirely likely we'll want to be testing on other
distros, or even a very much from-scratch build if we are able to
reuse the work done on GitLab CI for Mesa here:
  https://gitlab.com/igalia/graphics/mesa/pipelines/22874845

Either way, having the list of dependencies explictly typed out is
helpful for whoever's doing the conversion, and it's easy to make sure
the lists stay in sync if we do have multiple lists.

>>> > +  - make -j4
>>> > +  - make check
>>> > +  - make install
>>> > +  - make distcheck
>>> I was under the impression that "make -j4 distcheck" is enough
>>
>> install and check both imply (depend on) a normal build, so that one is
>> redundant.
>>
>> distcheck runs the tests like check does, but differently-configured,
>> so for full coverage you might want to do both.
>>
>> Similarly, distcheck runs "make install", but into a temporary directory,
>> not the requested $PREFIX.
>
> Right - did not spot that "prefix-*" is also collected as artefacts.

Not just prefix, but also as far as I can see there's no way to
collect test suite logs from a distcheck run? We've also had
inexplicable bugs in the past where 'make check' failed but 'make
distcheck' succeeded (or was it vice-versa?), and given the test
runtime is still quite short, seemed reasonable enough to explicitly
test out all of those.

>>> Alternatively it's worth setting MAKEFLAGS="-jX" once so it's used across 
>>> all.
>>
>> Using -j would definitely help for "make distcheck".
>>
>> If parallel install works, it would be good to test it so that it stays
>> that way: quite a lot of projects can build correctly in parallel, but
>> don't work reliably for "make -jX install".
>
> There has been issues in the past and everything ran fine last time
> I've checked.
> That's why I'm suggesting adding the toggle ;-)
>
> I'm slightly confused if the reply is a) for, b) against or c) simply
> provides more info.
> In either way, the background info is always appreciated.

Right, we have certainly had bugs with 'install' in the past.
Hopefully it's improved now; let's find out, I suppose.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Daniel Stone]

Hi Pekka,

On 7 June 2018 at 08:46, Pekka Paalanen  wrote:
> On Wed, 6 Jun 2018 15:37:01 +0100
> Emil Velikov  wrote:
>> On 6 June 2018 at 09:56, Pekka Paalanen  wrote:
>> > On Wed, 6 Jun 2018 09:22:59 +0100
>> > Daniel Stone  wrote:
>> >> On 6 June 2018 at 09:12, Daniel Stone  wrote:
>> >> > On 6 June 2018 at 09:03, Pekka Paalanen  wrote:
>> >> >> Distcheck does not --disable-xwayland-test, does it? So should we match
>> >> >> it with the autogen.sh arguments?
>> >> >
>> distcheck uses AM_DISTCHECK_CONFIGURE_FLAGS (if set in the
>> Makefile.am) to override the defaults.
>> Plus the user can further tweak things via the non AM_ version. For example
>>
>> DISTCHECK_CONFIGURE_FLAGS="--disable-xwayland-test" make distcheck
>
> Yeah, that's my point.
>
> DISTCHECK_CONFIGURE_FLAGS is not set and Makefile.am has
>
> AM_DISTCHECK_CONFIGURE_FLAGS = --disable-setuid-install
>
> There is no benefit in using --disable-xwayland-test for autogen.sh,
> because distcheck will use it anyway and it works already it seems.

Right, I just removed it for the meantime.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

[Pekka Paalanen]

On Wed, 6 Jun 2018 15:37:01 +0100
Emil Velikov  wrote:

> On 6 June 2018 at 09:56, Pekka Paalanen  wrote:
> > On Wed, 6 Jun 2018 09:22:59 +0100
> > Daniel Stone  wrote:
> >  
> >> On 6 June 2018 at 09:12, Daniel Stone  wrote:  
> >> > On 6 June 2018 at 09:03, Pekka Paalanen  wrote:  
> >> >> Distcheck does not --disable-xwayland-test, does it? So should we match
> >> >> it with the autogen.sh arguments?  
> >> >  
> distcheck uses AM_DISTCHECK_CONFIGURE_FLAGS (if set in the
> Makefile.am) to override the defaults.
> Plus the user can further tweak things via the non AM_ version. For example
> 
> DISTCHECK_CONFIGURE_FLAGS="--disable-xwayland-test" make distcheck

Yeah, that's my point.

DISTCHECK_CONFIGURE_FLAGS is not set and Makefile.am has

AM_DISTCHECK_CONFIGURE_FLAGS = --disable-setuid-install

There is no benefit in using --disable-xwayland-test for autogen.sh,
because distcheck will use it anyway and it works already it seems.


Thanks,
pq


pgpBiYJhzUndE.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] scanner: allow referencing foreign enums

[Pekka Paalanen]

On Wed, 06 Jun 2018 08:54:16 -0400
Simon Ser  wrote:

> On May 29, 2018 9:52 AM, Pekka Paalanen  wrote:
> > On Sat, 26 May 2018 09:51:18 +0200
> > Silvan Jegen  wrote:
> >  
> > > Hi
> > >
> > > On Fri, May 25, 2018 at 05:24:41PM -0400, Simon Ser wrote:  
> > > > It's already possible to reference foreign interfaces, so it
> > > > should also be possible to reference foreign enums.
> > > >
> > > > Signed-off-by: Simon Ser 
> > > > ---
> > > >  src/scanner.c | 7 +--
> > > >  1 file changed, 1 insertion(+), 6 deletions(-)  
> > >
> > > It looks good to me and I can confirm that this works as intended. If
> > > no solution allowing for the passing of reference protocols is desired,
> > > this should be applied.
> > >
> > > Reviewed-by: Silvan Jegen   
> >
> > Reviewed-by: Pekka Paalanen 
> >
> > If no-one objects, I will push this next week. Do ping me if I forget.  
> 
> Ping :)

Hi,

thanks for the reminder. I'm waiting for the gitlab-ci patch to land,
so I can see it in action, when I push this patch. Sorry for the delay.


Thanks,
pq


pgpeZdPqx7lxV.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel