[dora][regression] mesa failed to build

[dora][regression] mesa failed to build

[Otavio Salvador]

Hello,

In one of our custom BSPs we saw a build failure in mesa:

| make[1]: Leaving directory
`.../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/build'
| sed: can't read
.../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/image/usr/include/EGL/eglplatform.h:
No such file or directory
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_install (log file is located at
.../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/temp/log.do_install.17155)
recipe mesa-2_9.1.6-r0: task do_install: Failed
ERROR: Task 2643
(.../sources/poky/meta/recipes-graphics/mesa/mesa_9.1.6.bb,
do_install) failed with exit code '1'
recipe gnutls-2.12.23-r8.4: task do_configure: Succeeded

This seems not related to the bbappend we have in meta-fsl-arm[1], in
Dora. I think this came in today's changes in the branch.

1. http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/mesa/mesa_9.1.6.bbappend?h=dora

This builder has PRServer enabled.

As I am going to be traveling so won't have time to debug this bug I
preferred to report it so someone can debug.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [dora][regression] mesa failed to build

[Robert Yang]

Yes, seems related to the following one, add Valentin Popa in the loop:

commit bcfbddd8fa9760f681d7366c8d507fd0bef3a854
Author: Valentin Popa <valentin.popa@intel.com>
Date:   Thu Feb 27 11:51:17 2014 +0200

     mesa: build fix for gallium-egl

// Robert

On 04/05/2014 12:38 PM, Otavio Salvador wrote:
> Hello,
>
> In one of our custom BSPs we saw a build failure in mesa:
>
> | make[1]: Leaving directory
> `.../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/build'
> | sed: can't read
> .../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/image/usr/include/EGL/eglplatform.h:
> No such file or directory
> | WARNING: exit code 2 from a shell command.
> | ERROR: Function failed: do_install (log file is located at
> .../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/temp/log.do_install.17155)
> recipe mesa-2_9.1.6-r0: task do_install: Failed
> ERROR: Task 2643
> (.../sources/poky/meta/recipes-graphics/mesa/mesa_9.1.6.bb,
> do_install) failed with exit code '1'
> recipe gnutls-2.12.23-r8.4: task do_configure: Succeeded
>
> This seems not related to the bbappend we have in meta-fsl-arm[1], in
> Dora. I think this came in today's changes in the branch.
>
> 1. http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/mesa/mesa_9.1.6.bbappend?h=dora
>
> This builder has PRServer enabled.
>
> As I am going to be traveling so won't have time to debug this bug I
> preferred to report it so someone can debug.
>

Re: [dora][regression] mesa failed to build

[Valentin Popa]

Indeed the build failure was introduced by that patch, which enters a 
logical conflict with the bbappend file for mesa.
To remain compatible with the future releases I suggest to  not 
remove/add flags from/to EXTRA_OECONF explicitly, and make  use of what 
PACKAGECONFIG contains.
The first part of the __anonymous function from the bbappend file can be 
simply replaced with:

PACKAGECONFIG_remove = "egl"

and the second part with:

PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
and
PROVIDES_remove = "virtual/libgl" if mx6 is in SOC_FAMILY.



On 04/05/2014 07:50 AM, Robert Yang wrote:
>
> Yes, seems related to the following one, add Valentin Popa in the loop:
>
> commit bcfbddd8fa9760f681d7366c8d507fd0bef3a854
> Author: Valentin Popa <valentin.popa@intel.com>
> Date:   Thu Feb 27 11:51:17 2014 +0200
>
>     mesa: build fix for gallium-egl
>
> // Robert
>
> On 04/05/2014 12:38 PM, Otavio Salvador wrote:
>> Hello,
>>
>> In one of our custom BSPs we saw a build failure in mesa:
>>
>> | make[1]: Leaving directory
>> `.../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/build' 
>>
>> | sed: can't read
>> .../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/image/usr/include/EGL/eglplatform.h: 
>>
>> No such file or directory
>> | WARNING: exit code 2 from a shell command.
>> | ERROR: Function failed: do_install (log file is located at
>> .../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/temp/log.do_install.17155) 
>>
>> recipe mesa-2_9.1.6-r0: task do_install: Failed
>> ERROR: Task 2643
>> (.../sources/poky/meta/recipes-graphics/mesa/mesa_9.1.6.bb,
>> do_install) failed with exit code '1'
>> recipe gnutls-2.12.23-r8.4: task do_configure: Succeeded
>>
>> This seems not related to the bbappend we have in meta-fsl-arm[1], in
>> Dora. I think this came in today's changes in the branch.
>>
>> 1. 
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/mesa/mesa_9.1.6.bbappend?h=dora
>>
>> This builder has PRServer enabled.
>>
>> As I am going to be traveling so won't have time to debug this bug I
>> preferred to report it so someone can debug.
>>

Re: [dora][regression] mesa failed to build

[Robert Yang]

On 04/07/2014 10:55 PM, Valentin Popa wrote:
>
> Indeed the build failure was introduced by that patch, which enters a logical
> conflict with the bbappend file for mesa.
> To remain compatible with the future releases I suggest to  not remove/add flags
> from/to EXTRA_OECONF explicitly, and make  use of what PACKAGECONFIG contains.
> The first part of the __anonymous function from the bbappend file can be simply
> replaced with:
>
> PACKAGECONFIG_remove = "egl"
>
> and the second part with:
>
> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
> and
> PROVIDES_remove = "virtual/libgl" if mx6 is in SOC_FAMILY.
>

Hi Otavio,

Does Valentin's suggestions work for you, please?

// Robert

>
>
> On 04/05/2014 07:50 AM, Robert Yang wrote:
>>
>> Yes, seems related to the following one, add Valentin Popa in the loop:
>>
>> commit bcfbddd8fa9760f681d7366c8d507fd0bef3a854
>> Author: Valentin Popa <valentin.popa@intel.com>
>> Date:   Thu Feb 27 11:51:17 2014 +0200
>>
>>     mesa: build fix for gallium-egl
>>
>> // Robert
>>
>> On 04/05/2014 12:38 PM, Otavio Salvador wrote:
>>> Hello,
>>>
>>> In one of our custom BSPs we saw a build failure in mesa:
>>>
>>> | make[1]: Leaving directory
>>> `.../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/build'
>>>
>>> | sed: can't read
>>> .../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/image/usr/include/EGL/eglplatform.h:
>>>
>>> No such file or directory
>>> | WARNING: exit code 2 from a shell command.
>>> | ERROR: Function failed: do_install (log file is located at
>>> .../build/tmp/work/cortexa9hf-vfp-neon-mx6-oel-linux-gnueabi/mesa/2_9.1.6-r0/temp/log.do_install.17155)
>>>
>>> recipe mesa-2_9.1.6-r0: task do_install: Failed
>>> ERROR: Task 2643
>>> (.../sources/poky/meta/recipes-graphics/mesa/mesa_9.1.6.bb,
>>> do_install) failed with exit code '1'
>>> recipe gnutls-2.12.23-r8.4: task do_configure: Succeeded
>>>
>>> This seems not related to the bbappend we have in meta-fsl-arm[1], in
>>> Dora. I think this came in today's changes in the branch.
>>>
>>> 1.
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/mesa/mesa_9.1.6.bbappend?h=dora
>>>
>>>
>>> This builder has PRServer enabled.
>>>
>>> As I am going to be traveling so won't have time to debug this bug I
>>> preferred to report it so someone can debug.
>>>
>
>
>

Re: [dora][regression] mesa failed to build

[Otavio Salvador]

Hello,

On Wed, Apr 9, 2014 at 12:13 AM, Robert Yang <liezhi.yang@windriver.com> wrote:
> On 04/07/2014 10:55 PM, Valentin Popa wrote:
>> Indeed the build failure was introduced by that patch, which enters a
>> logical
>> conflict with the bbappend file for mesa.
>> To remain compatible with the future releases I suggest to  not remove/add
>> flags
>> from/to EXTRA_OECONF explicitly, and make  use of what PACKAGECONFIG
>> contains.
>> The first part of the __anonymous function from the bbappend file can be
>> simply
>> replaced with:
>>
>> PACKAGECONFIG_remove = "egl"
>>
>> and the second part with:
>>
>> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
>> and
>> PROVIDES_remove = "virtual/libgl" if mx6 is in SOC_FAMILY.
>>
>
> Hi Otavio,
>
> Does Valentin's suggestions work for you, please?

I am traveling and won't be able to test it.

However I am quite surprise this didn't come out /before/ when the
dora updates were in test in AB since meta-fsl-arm is tested in AB
too. We need to figure /why/ this broke and for now I think we ought
to revert this dora patch.

This kind of change needs to be coordinated and raise a build break in
an Yocto Project is unacceptable IMO.

For me it is clear this didn't run in AB before merging. :(

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [dora][regression] mesa failed to build

[Robert Yang]

On 04/11/2014 09:56 PM, Otavio Salvador wrote:
> Hello,
>
> On Wed, Apr 9, 2014 at 12:13 AM, Robert Yang <liezhi.yang@windriver.com> wrote:
>> On 04/07/2014 10:55 PM, Valentin Popa wrote:
>>> Indeed the build failure was introduced by that patch, which enters a
>>> logical
>>> conflict with the bbappend file for mesa.
>>> To remain compatible with the future releases I suggest to  not remove/add
>>> flags
>>> from/to EXTRA_OECONF explicitly, and make  use of what PACKAGECONFIG
>>> contains.
>>> The first part of the __anonymous function from the bbappend file can be
>>> simply
>>> replaced with:
>>>
>>> PACKAGECONFIG_remove = "egl"
>>>
>>> and the second part with:
>>>
>>> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
>>> and
>>> PROVIDES_remove = "virtual/libgl" if mx6 is in SOC_FAMILY.
>>>
>>
>> Hi Otavio,
>>
>> Does Valentin's suggestions work for you, please?
>
> I am traveling and won't be able to test it.
>
> However I am quite surprise this didn't come out /before/ when the
> dora updates were in test in AB since meta-fsl-arm is tested in AB
> too. We need to figure /why/ this broke and for now I think we ought
> to revert this dora patch.
>
> This kind of change needs to be coordinated and raise a build break in
> an Yocto Project is unacceptable IMO.
>
> For me it is clear this didn't run in AB before merging. :(
>

I'm sorry about that, I had run it on my *local* AB before merging, but
the local AB is less powerful and doesn't include the meta-fsl-arm layer,
I'm fine to revert it, what's RP and valentin's opinion, please ?

// Robert

Re: [dora][regression] mesa failed to build

[Valentin Popa]

On 04/12/2014 06:33 AM, Robert Yang wrote:
>
>
> On 04/11/2014 09:56 PM, Otavio Salvador wrote:
>> Hello,
>>
>> On Wed, Apr 9, 2014 at 12:13 AM, Robert Yang 
>> <liezhi.yang@windriver.com> wrote:
>>> On 04/07/2014 10:55 PM, Valentin Popa wrote:
>>>> Indeed the build failure was introduced by that patch, which enters a
>>>> logical
>>>> conflict with the bbappend file for mesa.
>>>> To remain compatible with the future releases I suggest to not 
>>>> remove/add
>>>> flags
>>>> from/to EXTRA_OECONF explicitly, and make  use of what PACKAGECONFIG
>>>> contains.
>>>> The first part of the __anonymous function from the bbappend file 
>>>> can be
>>>> simply
>>>> replaced with:
>>>>
>>>> PACKAGECONFIG_remove = "egl"
>>>>
>>>> and the second part with:
>>>>
>>>> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
>>>> and
>>>> PROVIDES_remove = "virtual/libgl" if mx6 is in SOC_FAMILY.
>>>>
>>>
>>> Hi Otavio,
>>>
>>> Does Valentin's suggestions work for you, please?
>>
>> I am traveling and won't be able to test it.
>>
>> However I am quite surprise this didn't come out /before/ when the
>> dora updates were in test in AB since meta-fsl-arm is tested in AB
>> too. We need to figure /why/ this broke and for now I think we ought
>> to revert this dora patch.
>>
>> This kind of change needs to be coordinated and raise a build break in
>> an Yocto Project is unacceptable IMO.
>>
>> For me it is clear this didn't run in AB before merging. :(
>>
>
> I'm sorry about that, I had run it on my *local* AB before merging, but
> the local AB is less powerful and doesn't include the meta-fsl-arm layer,
> I'm fine to revert it, what's RP and valentin's opinion, please ?
>
> // Robert
>
>
>

I'll send a patch to handle this special case for meta-fsl-arm (mutate 
eglplatform.h only if it exists)