Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-14 Thread Andrea Galbusera 
On Tue, Jul 11, 2017 at 10:06 AM, Jussi Kukkonen 
wrote:

> On 10 July 2017 at 17:47, Andrea Galbusera  wrote:
>
>> During bisection the failing task changed from do_prepare_recipe_sysroot
>> to do_compile with the log below. I have no idea if these things do relate
>> themselves, but if not, I was not able to figure it out while bisecting.
>>
>> | In file included from /home/gizero/work/smartliving/
>> distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4
>> -poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/incl
>> ude/epoxy/egl.h:46:0,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.h:32,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.c:24:
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c: In function
>> 'gdk_wayland_gl_context_realize':
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c:179:43:
>> error: expected expression before 'EGLContext'
>> |  : EGL_NO_CONTEXT,
>> |^
>>
>
> Your bisect seems valid: gtk+3 uses a define that comes from epoxy and was
> changed in the update. The new define uses a EGL_CAST() macro that was
> added to eglplatform.h at the same time. mesa has updated their
> eglplatform.h so it all seems to work, but userland does not seem to have
> this macro?
>
> There's probably more to the story (since the error is not about implicit
> EGL_CAST() as one would expect). My first suggestion would be that userland
> eglplatform.h is updated to match current Khronos registry or at least to
> include the EGL_CAST definition.
>
>
Can anyone of you guys with deep understanding in this matter help with
[1]. I posted a pull request on RPi userland upstream backporting changes
to eglplatform.h from mesa that seems relevant to fix builds for libepoxy
and gtk+3 but maintainers arguments needs more knowledge than I have...

[1] https://github.com/raspberrypi/userland/pull/407
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-12 Thread Burton, Ross 
On 12 July 2017 at 08:24, Jussi Kukkonen  wrote:

> I think I'll just send a patch to mesa-gl recipe to not install the
> header. If someone wants to solve this properly with the upstreams, be my
> guest.
>

Sounds like the best fix considering the alternatives, to be honest.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-12 Thread Jussi Kukkonen 
On 12 July 2017 at 08:11, Khem Raj  wrote:

> On Tue, Jul 11, 2017 at 9:56 PM, Andrea Galbusera 
> wrote:
> > I may be in the need to craft something locally to unbreak building with
> > current master... Could you please shed some light on how this should be
> > done then? Is this a matter of completely removing either mesa-gl or
> > userland from gtk+3 deps or a more selective change to avoid the clash in
> > recipe-sysroot?
>
> Firstly, determine where this file belongs to. If it is part of
> egl/gles then it should go to userland, otherwise it should be
> provided by mesa when using userland for graphics
>

It's a "generic" Khronos platform header (so not part of EGL or GLES[1-3]
but needed by all), in a perfect world we could use any version of it ...
unfortunately "Adopters may modify this file to suit their platform" and of
course that's what Userland has done.

I think I'll just send a patch to mesa-gl recipe to not install the header.
If someone wants to solve this properly with the upstreams, be my guest.

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
On Wed, Jul 12, 2017 at 7:11 AM, Khem Raj  wrote:

> On Tue, Jul 11, 2017 at 9:56 PM, Andrea Galbusera 
> wrote:
> > On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj  wrote:
> >>
> >> On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera 
> >> wrote:
> >> >
> >> >
> >> > Il 11 lug 2017 8:00 PM, "Khem Raj"  ha scritto:
> >> >
> >> > On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
> >> >  wrote:
> >> >> On 11 July 2017 at 11:27, Jussi Kukkonen 
> >> >> wrote:
> >> >>>
> >> >>> On 11 July 2017 at 10:42, Jussi Kukkonen 
> >> >>> wrote:
> >> >
> >> > Exception: FileExistsError: [Errno 17] File exists:
> >> >
> >> >
> >> > '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/
> sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
> >> > ->
> >> >
> >> >
> >> > '/home/gizero/work/smartliving/distro/repo-
> master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-
> linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/
> KHR/khrplatform.h'
> >> 
> >> 
> >>  /usr/include/KHR/khrplatform.h is the egl platform header file,
> >>  provided
> >>  by both mesa and RPI userland. Does mesa end up in your gtk+3
> >>  recipe-sysroot
> >>  somehow?
> >> 
> >>  For clarity: this could be a bug but it is unlikely to be related
> to
> >>  the
> >>  libepoxy change (it does not use or ship the actual header file).
> >> 
> >> >>>
> >> >>>
> >> >>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 --
> >> >>> mesa
> >> >>> accidentally shipped khrplatform.h even when egl was disabled (which
> >> >>> is
> >> >>> what
> >> >>> mesa-gl in oe-core does).
> >> >>>
> >> >>
> >> >> Sorry, I've not had enough  coffee. It was the other way round:
> >> >> khrplatform.h is the platform header that mesa now thinks is needed
> >> >> whether
> >> >> egl is enabled or not -- so they've started installing it in any case
> >> >> from
> >> >> 17.1.4 which means mesa-gl now provides khrplatform.h and thus
> >> >> conflicts
> >> >> with userland.
> >> >>
> >> >> I don't know what the correct fix is yet, just wanted to correct my
> >> >> original
> >> >> wrong info.
> >> >>
> >> >
> >> > Post an update to sync this header for userland package.
> >> >
> >> >
> >> > Will this help solving the gtk+3 issue of mesa-gl and userland now
> both
> >> > providing the same header and causing recipe-sysroot construction to
> >> > fail?
> >>
> >> No it certainly would not. But we can then decide who provides it, in
> >> a easy way.
> >
> >
> > I may be in the need to craft something locally to unbreak building with
> > current master... Could you please shed some light on how this should be
> > done then? Is this a matter of completely removing either mesa-gl or
> > userland from gtk+3 deps or a more selective change to avoid the clash in
> > recipe-sysroot?
>
> Firstly, determine where this file belongs to. If it is part of
> egl/gles then it should go to userland, otherwise it should be
> provided by mesa when using userland for graphics
>

If I understand correctly your point, you mean it is about having the two
upstream agreeing on where the header belongs to and fixing either one or
the other to stop providing it. In the meanwhile, from an oe perspective,
having such a patch in place for any of the two or even removing the file
in an appropriate do_install_append should do the job, right?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Khem Raj 
On Tue, Jul 11, 2017 at 9:56 PM, Andrea Galbusera  wrote:
> On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj  wrote:
>>
>> On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera 
>> wrote:
>> >
>> >
>> > Il 11 lug 2017 8:00 PM, "Khem Raj"  ha scritto:
>> >
>> > On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
>> >  wrote:
>> >> On 11 July 2017 at 11:27, Jussi Kukkonen 
>> >> wrote:
>> >>>
>> >>> On 11 July 2017 at 10:42, Jussi Kukkonen 
>> >>> wrote:
>> >
>> > Exception: FileExistsError: [Errno 17] File exists:
>> >
>> >
>> > '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>> > ->
>> >
>> >
>> > '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>> 
>> 
>>  /usr/include/KHR/khrplatform.h is the egl platform header file,
>>  provided
>>  by both mesa and RPI userland. Does mesa end up in your gtk+3
>>  recipe-sysroot
>>  somehow?
>> 
>>  For clarity: this could be a bug but it is unlikely to be related to
>>  the
>>  libepoxy change (it does not use or ship the actual header file).
>> 
>> >>>
>> >>>
>> >>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 --
>> >>> mesa
>> >>> accidentally shipped khrplatform.h even when egl was disabled (which
>> >>> is
>> >>> what
>> >>> mesa-gl in oe-core does).
>> >>>
>> >>
>> >> Sorry, I've not had enough  coffee. It was the other way round:
>> >> khrplatform.h is the platform header that mesa now thinks is needed
>> >> whether
>> >> egl is enabled or not -- so they've started installing it in any case
>> >> from
>> >> 17.1.4 which means mesa-gl now provides khrplatform.h and thus
>> >> conflicts
>> >> with userland.
>> >>
>> >> I don't know what the correct fix is yet, just wanted to correct my
>> >> original
>> >> wrong info.
>> >>
>> >
>> > Post an update to sync this header for userland package.
>> >
>> >
>> > Will this help solving the gtk+3 issue of mesa-gl and userland now both
>> > providing the same header and causing recipe-sysroot construction to
>> > fail?
>>
>> No it certainly would not. But we can then decide who provides it, in
>> a easy way.
>
>
> I may be in the need to craft something locally to unbreak building with
> current master... Could you please shed some light on how this should be
> done then? Is this a matter of completely removing either mesa-gl or
> userland from gtk+3 deps or a more selective change to avoid the clash in
> recipe-sysroot?

Firstly, determine where this file belongs to. If it is part of
egl/gles then it should go to userland, otherwise it should be
provided by mesa when using userland for graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj  wrote:

> On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera 
> wrote:
> >
> >
> > Il 11 lug 2017 8:00 PM, "Khem Raj"  ha scritto:
> >
> > On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
> >  wrote:
> >> On 11 July 2017 at 11:27, Jussi Kukkonen 
> wrote:
> >>>
> >>> On 11 July 2017 at 10:42, Jussi Kukkonen 
> >>> wrote:
> >
> > Exception: FileExistsError: [Errno 17] File exists:
> >
> > '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/
> sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
> > ->
> >
> > '/home/gizero/work/smartliving/distro/repo-
> master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-
> linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/
> KHR/khrplatform.h'
> 
> 
>  /usr/include/KHR/khrplatform.h is the egl platform header file,
> provided
>  by both mesa and RPI userland. Does mesa end up in your gtk+3
>  recipe-sysroot
>  somehow?
> 
>  For clarity: this could be a bug but it is unlikely to be related to
> the
>  libepoxy change (it does not use or ship the actual header file).
> 
> >>>
> >>>
> >>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
> >>> accidentally shipped khrplatform.h even when egl was disabled (which is
> >>> what
> >>> mesa-gl in oe-core does).
> >>>
> >>
> >> Sorry, I've not had enough  coffee. It was the other way round:
> >> khrplatform.h is the platform header that mesa now thinks is needed
> >> whether
> >> egl is enabled or not -- so they've started installing it in any case
> from
> >> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> >> with userland.
> >>
> >> I don't know what the correct fix is yet, just wanted to correct my
> >> original
> >> wrong info.
> >>
> >
> > Post an update to sync this header for userland package.
> >
> >
> > Will this help solving the gtk+3 issue of mesa-gl and userland now both
> > providing the same header and causing recipe-sysroot construction to
> fail?
>
> No it certainly would not. But we can then decide who provides it, in
> a easy way.
>

I may be in the need to craft something locally to unbreak building with
current master... Could you please shed some light on how this should be
done then? Is this a matter of completely removing either mesa-gl or
userland from gtk+3 deps or a more selective change to avoid the clash in
recipe-sysroot?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Khem Raj 
On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera  wrote:
>
>
> Il 11 lug 2017 8:00 PM, "Khem Raj"  ha scritto:
>
> On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
>  wrote:
>> On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:
>>>
>>> On 11 July 2017 at 10:42, Jussi Kukkonen 
>>> wrote:
>
> Exception: FileExistsError: [Errno 17] File exists:
>
> '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
> ->
>
> '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'


 /usr/include/KHR/khrplatform.h is the egl platform header file, provided
 by both mesa and RPI userland. Does mesa end up in your gtk+3
 recipe-sysroot
 somehow?

 For clarity: this could be a bug but it is unlikely to be related to the
 libepoxy change (it does not use or ship the actual header file).

>>>
>>>
>>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>>> accidentally shipped khrplatform.h even when egl was disabled (which is
>>> what
>>> mesa-gl in oe-core does).
>>>
>>
>> Sorry, I've not had enough  coffee. It was the other way round:
>> khrplatform.h is the platform header that mesa now thinks is needed
>> whether
>> egl is enabled or not -- so they've started installing it in any case from
>> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
>> with userland.
>>
>> I don't know what the correct fix is yet, just wanted to correct my
>> original
>> wrong info.
>>
>
> Post an update to sync this header for userland package.
>
>
> Will this help solving the gtk+3 issue of mesa-gl and userland now both
> providing the same header and causing recipe-sysroot construction to fail?

No it certainly would not. But we can then decide who provides it, in
a easy way.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
Il 11 lug 2017 8:00 PM, "Khem Raj"  ha scritto:

On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
 wrote:
> On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:
>>
>> On 11 July 2017 at 10:42, Jussi Kukkonen 
wrote:

 Exception: FileExistsError: [Errno 17] File exists:
 '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/
sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
 ->
 '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/
cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-
r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>
>>>
>>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
recipe-sysroot
>>> somehow?
>>>
>>> For clarity: this could be a bug but it is unlikely to be related to the
>>> libepoxy change (it does not use or ship the actual header file).
>>>
>>
>>
>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>> accidentally shipped khrplatform.h even when egl was disabled (which is
what
>> mesa-gl in oe-core does).
>>
>
> Sorry, I've not had enough  coffee. It was the other way round:
> khrplatform.h is the platform header that mesa now thinks is needed
whether
> egl is enabled or not -- so they've started installing it in any case from
> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> with userland.
>
> I don't know what the correct fix is yet, just wanted to correct my
original
> wrong info.
>

Post an update to sync this header for userland package.


Will this help solving the gtk+3 issue of mesa-gl and userland now both
providing the same header and causing recipe-sysroot construction to fail?


>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Khem Raj 
On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
 wrote:
> On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:
>>
>> On 11 July 2017 at 10:42, Jussi Kukkonen  wrote:

 Exception: FileExistsError: [Errno 17] File exists:
 '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
 ->
 '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>
>>>
>>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>>> by both mesa and RPI userland. Does mesa end up in your gtk+3 recipe-sysroot
>>> somehow?
>>>
>>> For clarity: this could be a bug but it is unlikely to be related to the
>>> libepoxy change (it does not use or ship the actual header file).
>>>
>>
>>
>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>> accidentally shipped khrplatform.h even when egl was disabled (which is what
>> mesa-gl in oe-core does).
>>
>
> Sorry, I've not had enough  coffee. It was the other way round:
> khrplatform.h is the platform header that mesa now thinks is needed whether
> egl is enabled or not -- so they've started installing it in any case from
> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> with userland.
>
> I don't know what the correct fix is yet, just wanted to correct my original
> wrong info.
>

Post an update to sync this header for userland package.

>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
On Tue, Jul 11, 2017 at 10:34 AM, Jussi Kukkonen 
wrote:

> On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:
>
>> On 11 July 2017 at 10:42, Jussi Kukkonen 
>> wrote:
>>>
>>> Exception: FileExistsError: [Errno 17] File exists:
 '/home/gizero/work/smartliving/distro/repo-master/build-poky
 /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
 -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
 /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.2
 2.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'

>>>
>>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
>>> recipe-sysroot somehow?
>>>
>>> For clarity: this could be a bug but it is unlikely to be related to the
>>> libepoxy change (it does not use or ship the actual header file).
>>>
>>>
>>
>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>> accidentally shipped khrplatform.h even when egl was disabled (which is
>> what mesa-gl in oe-core does).
>>
>>
> Sorry, I've not had enough  coffee. It was the other way round:
> khrplatform.h is the platform header that mesa now thinks is needed whether
> egl is enabled or not -- so they've started installing it in any case from
> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
> with userland.
>
> I don't know what the correct fix is yet, just wanted to correct my
> original wrong info.
>

Ok, got it That was also my initial interpretation of mentioned commit
message which states:

mesa: Upgrade to 17.1.4 release

This includes following upstream bug fixes:

Bug 77240 - khrplatform.h not installed if EGL is disabled
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
On Tue, Jul 11, 2017 at 10:27 AM, Jussi Kukkonen 
wrote:

> On 11 July 2017 at 10:42, Jussi Kukkonen  wrote:
>>
>> Exception: FileExistsError: [Errno 17] File exists:
>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>>> /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>>> -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>>> /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.2
>>> 2.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>
>>
>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>> by both mesa and RPI userland. Does mesa end up in your gtk+3
>> recipe-sysroot somehow?
>>
>> For clarity: this could be a bug but it is unlikely to be related to the
>> libepoxy change (it does not use or ship the actual header file).
>>
>>
>
> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
> accidentally shipped khrplatform.h even when egl was disabled (which is
> what mesa-gl in oe-core does).
>
> Make sure you have oe-core commit f0762f5bad3 (poky: 773d10873).
>

Yes I have it, and the cleansstate mentioned above makes me think it got
used as expected. Indeed the commit you mention is part of the bunch of
commits after pulling which I got my builds broken... I'm confused! Any
idea how to figure out which recipe get considered first in gtk+3's
do_prepare_recipe_sysroot and effectively deliver khrplatform.h to the
recipe-sysroot?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Jussi Kukkonen 
On 11 July 2017 at 11:27, Jussi Kukkonen  wrote:

> On 11 July 2017 at 10:42, Jussi Kukkonen  wrote:
>>
>> Exception: FileExistsError: [Errno 17] File exists:
>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>>> /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>>> -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>>> /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.2
>>> 2.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>
>>
>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>> by both mesa and RPI userland. Does mesa end up in your gtk+3
>> recipe-sysroot somehow?
>>
>> For clarity: this could be a bug but it is unlikely to be related to the
>> libepoxy change (it does not use or ship the actual header file).
>>
>>
>
> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
> accidentally shipped khrplatform.h even when egl was disabled (which is
> what mesa-gl in oe-core does).
>
>
Sorry, I've not had enough  coffee. It was the other way round:
khrplatform.h is the platform header that mesa now thinks is needed whether
egl is enabled or not -- so they've started installing it in any case from
17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
with userland.

I don't know what the correct fix is yet, just wanted to correct my
original wrong info.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
On Tue, Jul 11, 2017 at 10:06 AM, Jussi Kukkonen 
wrote:

> On 10 July 2017 at 17:47, Andrea Galbusera  wrote:
>
>> During bisection the failing task changed from do_prepare_recipe_sysroot
>> to do_compile with the log below. I have no idea if these things do relate
>> themselves, but if not, I was not able to figure it out while bisecting.
>>
>> | In file included from /home/gizero/work/smartliving/
>> distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4
>> -poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/incl
>> ude/epoxy/egl.h:46:0,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.h:32,
>> |  from ../../../gtk+-3.22.16/gdk/wayl
>> and/gdkglcontext-wayland.c:24:
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c: In function
>> 'gdk_wayland_gl_context_realize':
>> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c:179:43:
>> error: expected expression before 'EGLContext'
>> |  : EGL_NO_CONTEXT,
>> |^
>>
>
> Your bisect seems valid: gtk+3 uses a define that comes from epoxy and was
> changed in the update. The new define uses a EGL_CAST() macro that was
> added to eglplatform.h at the same time. mesa has updated their
> eglplatform.h so it all seems to work, but userland does not seem to have
> this macro?
>
> There's probably more to the story (since the error is not about implicit
> EGL_CAST() as one would expect). My first suggestion would be that userland
> eglplatform.h is updated to match current Khronos registry or at least to
> include the EGL_CAST definition.
>

I looked at the userland upstream repo and they don't seem to have updates
on their eglplatform.h since 2015...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Andrea Galbusera 
On Tue, Jul 11, 2017 at 9:42 AM, Jussi Kukkonen 
wrote:

> On 10 July 2017 at 17:47, Andrea Galbusera  wrote:
>
>> On Tue, Jun 27, 2017 at 3:16 PM, Jussi Kukkonen > > wrote:
>>
>>> Imports the current EGL API registry from Khronos.
>>>
>>> Makes EGL support optional: this is reflected in the recipe but
>>> egl is enabled by default as before.
>>>
>>> Signed-off-by: Jussi Kukkonen 
>>> ---
>>>  .../libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb}| 9
>>> +
>>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>>  rename meta/recipes-graphics/libepoxy/{libepoxy_1.4.2.bb =>
>>> libepoxy_1.4.3.bb} (70%)
>>>
>>> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>>> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> similarity index 70%
>>> rename from meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>>> rename to meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> index e69e828..c8b398f 100644
>>> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>>> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> @@ -6,15 +6,16 @@ LICENSE = "MIT"
>>>  LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d4
>>> 01e07bd9ee8b6b58cf464b"
>>>
>>>  SRC_URI = "https://github.com/anholt/${BPN}/releases/download/${PV}/${
>>> BP}.tar.xz"
>>> -SRC_URI[md5sum] = "632fcfd7ae9d21f5a634326d753a89c4"
>>> -SRC_URI[sha256sum] = "bea6fdec3d10939954495da898d87
>>> 2ee836b75c35699074cbf02a64fcb80d5b3"
>>> +SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
>>> +SRC_URI[sha256sum] = "0b808a06c9685a62fca34b680abb8
>>> bc7fb2fda074478e329b063c1f872b826f6"
>>>  UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
>>>
>>>  inherit autotools pkgconfig distro_features_check
>>>
>>>  REQUIRED_DISTRO_FEATURES = "opengl"
>>>
>>> -DEPENDS = "util-macros virtual/egl"
>>> +DEPENDS = "util-macros"
>>>
>>> +PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
>>>  PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
>>> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>>> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}
>>> egl"
>>> --
>>> 2.1.4
>>>
>>
>> Beside the issue with recent patch to mesa, also this one seems to have
>> caused nasty effects on raspberrypi builds... I got to it after bisecting
>> poky from 854c8c2 that failed with:
>>
>> ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Error executing a
>> python function in exec_python_func() autogenerated:
>>
>> The stack trace of python calls that resulted in this exception/failure
>> was:
>> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>>  0001:
>>  *** 0002:extend_recipe_sysroot(d)
>>  0003:
>> File: '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /conf/../../layers/poky/meta/classes/staging.bbclass', lineno: 510,
>> function: extend_recipe_sysroot
>>  0506:dest = newmanifest[l]
>>  0507:if l.endswith("/"):
>>  0508:staging_copydir(l, targetdir, dest,
>> seendirs)
>>  0509:continue
>>  *** 0510:staging_copyfile(l, targetdir, dest,
>> postinsts, seendirs)
>>  0511:
>>  0512:for f in fixme:
>>  0513:if f == '':
>>  0514:staging_processfixme(fixme[f], recipesysroot,
>> recipesysroot, recipesysrootnative, d)
>> File: '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /conf/../../layers/poky/meta/classes/staging.bbclass', lineno: 151,
>> function: staging_copyfile
>>  0147:os.symlink(linkto, dest)
>>  0148:#bb.warn(c)
>>  0149:else:
>>  0150:try:
>>  *** 0151:os.link(c, dest)
>>  0152:except OSError as err:
>>  0153:if err.errno == errno.EXDEV:
>>  0154:bb.utils.copyfile(c, dest)
>>  0155:else:
>> Exception: FileExistsError: [Errno 17] File exists:
>> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>> -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.
>> 22.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>
>
> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
> by both mesa and RPI userland. Does mesa end up in your gtk+3
> recipe-sysroot somehow?
>

Indeed, both mesa-gl and userland are listed in
tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/sysroot-providers.
Are these two conflicting? Something I can do to help nailing it down? I
managed to call cleansstate for all recipes in userland, gtk+3 and mesa but
I end up with the same recipe-sysroot...


>
> For clarity: this could be a bug but it is unlikely to be

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Jussi Kukkonen 
On 11 July 2017 at 10:42, Jussi Kukkonen  wrote:
>
> Exception: FileExistsError: [Errno 17] File exists:
>> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>> -> '/home/gizero/work/smartliving/distro/repo-master/build-poky
>> /tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.2
>> 2.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>
>
> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
> by both mesa and RPI userland. Does mesa end up in your gtk+3
> recipe-sysroot somehow?
>
> For clarity: this could be a bug but it is unlikely to be related to the
> libepoxy change (it does not use or ship the actual header file).
>
>

Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
accidentally shipped khrplatform.h even when egl was disabled (which is
what mesa-gl in oe-core does).

Make sure you have oe-core commit f0762f5bad3 (poky: 773d10873).

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Jussi Kukkonen 
On 10 July 2017 at 17:47, Andrea Galbusera  wrote:

> During bisection the failing task changed from do_prepare_recipe_sysroot
> to do_compile with the log below. I have no idea if these things do relate
> themselves, but if not, I was not able to figure it out while bisecting.
>
> | In file included from /home/gizero/work/smartliving/
> distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4
> -poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/
> include/epoxy/egl.h:46:0,
> |  from ../../../gtk+-3.22.16/gdk/wayl
> and/gdkglcontext-wayland.h:32,
> |  from ../../../gtk+-3.22.16/gdk/wayl
> and/gdkglcontext-wayland.c:24:
> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c: In function
> 'gdk_wayland_gl_context_realize':
> | ../../../gtk+-3.22.16/gdk/wayland/gdkglcontext-wayland.c:179:43: error:
> expected expression before 'EGLContext'
> |  : EGL_NO_CONTEXT,
> |^
>

Your bisect seems valid: gtk+3 uses a define that comes from epoxy and was
changed in the update. The new define uses a EGL_CAST() macro that was
added to eglplatform.h at the same time. mesa has updated their
eglplatform.h so it all seems to work, but userland does not seem to have
this macro?

There's probably more to the story (since the error is not about implicit
EGL_CAST() as one would expect). My first suggestion would be that userland
eglplatform.h is updated to match current Khronos registry or at least to
include the EGL_CAST definition.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-11 Thread Jussi Kukkonen 
On 10 July 2017 at 17:47, Andrea Galbusera  wrote:

> On Tue, Jun 27, 2017 at 3:16 PM, Jussi Kukkonen 
> wrote:
>
>> Imports the current EGL API registry from Khronos.
>>
>> Makes EGL support optional: this is reflected in the recipe but
>> egl is enabled by default as before.
>>
>> Signed-off-by: Jussi Kukkonen 
>> ---
>>  .../libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb}| 9
>> +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>  rename meta/recipes-graphics/libepoxy/{libepoxy_1.4.2.bb =>
>> libepoxy_1.4.3.bb} (70%)
>>
>> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> similarity index 70%
>> rename from meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>> rename to meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> index e69e828..c8b398f 100644
>> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
>> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>> @@ -6,15 +6,16 @@ LICENSE = "MIT"
>>  LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d401e07bd9ee8b6b58cf464b"
>>
>>  SRC_URI = "https://github.com/anholt/${BPN}/releases/download/${PV}/${
>> BP}.tar.xz"
>> -SRC_URI[md5sum] = "632fcfd7ae9d21f5a634326d753a89c4"
>> -SRC_URI[sha256sum] = "bea6fdec3d10939954495da898d87
>> 2ee836b75c35699074cbf02a64fcb80d5b3"
>> +SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
>> +SRC_URI[sha256sum] = "0b808a06c9685a62fca34b680abb8
>> bc7fb2fda074478e329b063c1f872b826f6"
>>  UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
>>
>>  inherit autotools pkgconfig distro_features_check
>>
>>  REQUIRED_DISTRO_FEATURES = "opengl"
>>
>> -DEPENDS = "util-macros virtual/egl"
>> +DEPENDS = "util-macros"
>>
>> +PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
>>  PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
>> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
>> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>> --
>> 2.1.4
>>
>
> Beside the issue with recent patch to mesa, also this one seems to have
> caused nasty effects on raspberrypi builds... I got to it after bisecting
> poky from 854c8c2 that failed with:
>
> ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Error executing a
> python function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:extend_recipe_sysroot(d)
>  0003:
> File: '/home/gizero/work/smartliving/distro/repo-master/build-
> poky/conf/../../layers/poky/meta/classes/staging.bbclass', lineno: 510,
> function: extend_recipe_sysroot
>  0506:dest = newmanifest[l]
>  0507:if l.endswith("/"):
>  0508:staging_copydir(l, targetdir, dest,
> seendirs)
>  0509:continue
>  *** 0510:staging_copyfile(l, targetdir, dest,
> postinsts, seendirs)
>  0511:
>  0512:for f in fixme:
>  0513:if f == '':
>  0514:staging_processfixme(fixme[f], recipesysroot,
> recipesysroot, recipesysrootnative, d)
> File: '/home/gizero/work/smartliving/distro/repo-master/build-
> poky/conf/../../layers/poky/meta/classes/staging.bbclass', lineno: 151,
> function: staging_copyfile
>  0147:os.symlink(linkto, dest)
>  0148:#bb.warn(c)
>  0149:else:
>  0150:try:
>  *** 0151:os.link(c, dest)
>  0152:except OSError as err:
>  0153:if err.errno == errno.EXDEV:
>  0154:bb.utils.copyfile(c, dest)
>  0155:else:
> Exception: FileExistsError: [Errno 17] File exists:
> '/home/gizero/work/smartliving/distro/repo-master/build-
> poky/tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
> -> '/home/gizero/work/smartliving/distro/repo-master/build-
> poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+
> 3/3.22.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>

/usr/include/KHR/khrplatform.h is the egl platform header file, provided by
both mesa and RPI userland. Does mesa end up in your gtk+3 recipe-sysroot
somehow?

For clarity: this could be a bug but it is unlikely to be related to the
libepoxy change (it does not use or ship the actual header file).

 - Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-07-10 Thread Andrea Galbusera 
On Tue, Jun 27, 2017 at 3:16 PM, Jussi Kukkonen 
wrote:

> Imports the current EGL API registry from Khronos.
>
> Makes EGL support optional: this is reflected in the recipe but
> egl is enabled by default as before.
>
> Signed-off-by: Jussi Kukkonen 
> ---
>  .../libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb}| 9
> +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>  rename meta/recipes-graphics/libepoxy/{libepoxy_1.4.2.bb =>
> libepoxy_1.4.3.bb} (70%)
>
> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> similarity index 70%
> rename from meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
> rename to meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> index e69e828..c8b398f 100644
> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> @@ -6,15 +6,16 @@ LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d401e07bd9ee8b6b58cf464b"
>
>  SRC_URI = "https://github.com/anholt/${BPN}/releases/download/${PV}/${
> BP}.tar.xz"
> -SRC_URI[md5sum] = "632fcfd7ae9d21f5a634326d753a89c4"
> -SRC_URI[sha256sum] = "bea6fdec3d10939954495da898d87
> 2ee836b75c35699074cbf02a64fcb80d5b3"
> +SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
> +SRC_URI[sha256sum] = "0b808a06c9685a62fca34b680abb8
> bc7fb2fda074478e329b063c1f872b826f6"
>  UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
>
>  inherit autotools pkgconfig distro_features_check
>
>  REQUIRED_DISTRO_FEATURES = "opengl"
>
> -DEPENDS = "util-macros virtual/egl"
> +DEPENDS = "util-macros"
>
> +PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
>  PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
> --
> 2.1.4
>

Beside the issue with recent patch to mesa, also this one seems to have
caused nasty effects on raspberrypi builds... I got to it after bisecting
poky from 854c8c2 that failed with:

ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '/home/gizero/work/smartliving/distro/repo-
master/build-poky/conf/../../layers/poky/meta/classes/staging.bbclass',
lineno: 510, function: extend_recipe_sysroot
 0506:dest = newmanifest[l]
 0507:if l.endswith("/"):
 0508:staging_copydir(l, targetdir, dest,
seendirs)
 0509:continue
 *** 0510:staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
 0511:
 0512:for f in fixme:
 0513:if f == '':
 0514:staging_processfixme(fixme[f], recipesysroot,
recipesysroot, recipesysrootnative, d)
File: '/home/gizero/work/smartliving/distro/repo-
master/build-poky/conf/../../layers/poky/meta/classes/staging.bbclass',
lineno: 151, function: staging_copyfile
 0147:os.symlink(linkto, dest)
 0148:#bb.warn(c)
 0149:else:
 0150:try:
 *** 0151:os.link(c, dest)
 0152:except OSError as err:
 0153:if err.errno == errno.EXDEV:
 0154:bb.utils.copyfile(c, dest)
 0155:else:
Exception: FileExistsError: [Errno 17] File exists: '/home/gizero/work/
smartliving/distro/repo-master/build-poky/tmp/sysroots-components/
raspberrypi3/userland/usr/include/KHR/khrplatform.h' -> '/home/gizero/work/
smartliving/distro/repo-master/build-poky/tmp/work/
cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-
r0/recipe-sysroot/usr/include/KHR/khrplatform.h'

ERROR: gtk+3-3.22.16-r0 do_prepare_recipe_sysroot: Function failed:
extend_recipe_sysroot
ERROR: Logfile of failure stored in: /home/gizero/work/smartliving/
distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-
vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/temp/log.do_
prepare_recipe_sysroot.31798
ERROR: Task (/home/gizero/work/smartliving/distro/repo-
master/build-poky/conf/../../layers/poky/meta/recipes-
gnome/gtk+/gtk+3_3.22.16.bb:do_prepare_recipe_sysroot) failed with exit
code '1'

During bisection the failing task changed from do_prepare_recipe_sysroot to
do_compile with the log below. I have no idea if these things do relate
themselves, but if not, I was not able to figure it out while bisecting.

| In file included from /home/gizero/work/smartliving/
distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-
vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/
usr/include/epoxy/egl.h:46:0,
|  from ../../../gtk+-3.22.16/gdk/

[OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

2017-06-27 Thread Jussi Kukkonen 
Imports the current EGL API registry from Khronos.

Makes EGL support optional: this is reflected in the recipe but
egl is enabled by default as before.

Signed-off-by: Jussi Kukkonen 
---
 .../libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb}| 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)
 rename meta/recipes-graphics/libepoxy/{libepoxy_1.4.2.bb => libepoxy_1.4.3.bb} 
(70%)

diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb 
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
similarity index 70%
rename from meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
rename to meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index e69e828..c8b398f 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.2.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -6,15 +6,16 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=58ef4c80d401e07bd9ee8b6b58cf464b"
 
 SRC_URI = 
"https://github.com/anholt/${BPN}/releases/download/${PV}/${BP}.tar.xz;
-SRC_URI[md5sum] = "632fcfd7ae9d21f5a634326d753a89c4"
-SRC_URI[sha256sum] = 
"bea6fdec3d10939954495da898d872ee836b75c35699074cbf02a64fcb80d5b3"
+SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
+SRC_URI[sha256sum] = 
"0b808a06c9685a62fca34b680abb8bc7fb2fda074478e329b063c1f872b826f6"
 UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
 
 inherit autotools pkgconfig distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
 
-DEPENDS = "util-macros virtual/egl"
+DEPENDS = "util-macros"
 
+PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
 PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core