mx6q: fix virtual/libgl dependencies

mx6q: fix virtual/libgl dependencies

[Simon Braunschmidt]

Hi

I am still new to Yocto, so bear with me if some of the following
is not correct, you are welcome to open my eyes though ;-)

I have observed a problem to compile libglu in a configuration
for cgtqmx6 (imx6, from meta-fsl-arm-extra).
For a completely clean rebuild, sometimes compilation succeeds,
but sometimes it fails, not finding libGL for linking:

/home/devel/yocto/ ... /arm-poky-linux-gnueabi/4.8.1/ld: cannot find -lGL
collect2: error: ld returned 1 exit status

It looks like a race condition, sometimes the package/task providing
libGL is ready when libglu is compiled, sometimes not.

Some findings:

- meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
  delete libGL.* after compilation of mesa

- ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
  gpu-viv-bin-mx6q.inc, provides its own version of libGL

- gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="

- but mesa (via mesa.inc) does:
  PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"

- so the statement in imx-base.inc
   PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
  does not have effect, because mesa is still the only provider of virtual/libgl

- packages depending on virtual/libgl only get mesa, which will not contain
  the libGL library

- in fact, we still use the gl headers from mesa, but the binary blob library
  from gpu-viv-bin-mx6q (i have no words to describe this ...),
        so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q

- so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
  gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
  via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
  .bbappend file


Would the following patch be appropriate?

Kindest Regards,
Simon
-- 
Simon Braunschmidt, emlix GmbH, http://www.emlix.com Maxfeldstraße 9,
90409 Nürnberg, Germany Fon +49 911 / 36 77 11 - 7, Fax -8 
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

[meta-fsl-arm][PATCH] mx6q: fix virtual/libgl dependencies

[Simon Braunschmidt]

findings:
* meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
  delete libGL.* after compilation of mesa

* ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
  gpu-viv-bin-mx6q.inc, provides its own version of libGL

* gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="

* but mesa (via mesa.inc) does:
  PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"

* so the statement in imx-base.inc
   PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
  does not have effect, because mesa is still the only provider
  of virtual/libgl

* packages depending on virtual/libgl only get mesa, which will not contain
  the libGL library

* in fact, we still use the gl headers from mesa, but the binary blob library
  from gpu-viv-bin-mx6q (i have no words to describe this ...),
  so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q

conclusion:
* so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
  gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
  via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
  .bbappend file

Signed-off-by: Simon Braunschmidt <sb@emlix.com>
---
 .../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc          |    4 ++--
 recipes-graphics/mesa/mesa_9.1.3.bbappend          |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index b007079..3354854 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -6,8 +6,8 @@ DESCRIPTION = "GPU driver and apps for imx6"
 SECTION = "libs"
 LICENSE = "Proprietary"
 LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=19f5925343fa3da65596eeaa4ddb5fd3"
-DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)}"
-PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)} mesa"
+PROVIDES += "virtual/libgl virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
 
 INC_PR = "r5"
 
diff --git a/recipes-graphics/mesa/mesa_9.1.3.bbappend b/recipes-graphics/mesa/mesa_9.1.3.bbappend
index b0535a7..9308952 100644
--- a/recipes-graphics/mesa/mesa_9.1.3.bbappend
+++ b/recipes-graphics/mesa/mesa_9.1.3.bbappend
@@ -23,7 +23,7 @@ python __anonymous () {
 
         # Remove itens from provides
         provides = d.getVar('PROVIDES', True).split()
-        take_out = ['virtual/libgles1', 'virtual/libgles2', 'virtual/egl']
+        take_out = ['virtual/libgles1', 'virtual/libgles2', 'virtual/egl', 'virtual/libgl']
         new_provides = []
         for i in provides:
             if i not in take_out:
-- 
1.7.9.5

Re: mx6q: fix virtual/libgl dependencies

[Otavio Salvador]

On Thu, Jul 18, 2013 at 9:03 AM, Simon Braunschmidt <sb@emlix.com> wrote:
> Hi
>
> I am still new to Yocto, so bear with me if some of the following
> is not correct, you are welcome to open my eyes though ;-)
>
> I have observed a problem to compile libglu in a configuration
> for cgtqmx6 (imx6, from meta-fsl-arm-extra).
> For a completely clean rebuild, sometimes compilation succeeds,
> but sometimes it fails, not finding libGL for linking:
>
> /home/devel/yocto/ ... /arm-poky-linux-gnueabi/4.8.1/ld: cannot find -lGL
> collect2: error: ld returned 1 exit status
>
> It looks like a race condition, sometimes the package/task providing
> libGL is ready when libglu is compiled, sometimes not.
>
> Some findings:
>
> - meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
>   delete libGL.* after compilation of mesa
>
> - ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
>   gpu-viv-bin-mx6q.inc, provides its own version of libGL
>
> - gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="
>
> - but mesa (via mesa.inc) does:
>   PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
>
> - so the statement in imx-base.inc
>    PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
>   does not have effect, because mesa is still the only provider of virtual/libgl
>
> - packages depending on virtual/libgl only get mesa, which will not contain
>   the libGL library
>
> - in fact, we still use the gl headers from mesa, but the binary blob library
>   from gpu-viv-bin-mx6q (i have no words to describe this ...),
>         so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q
>
> - so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
>   gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
>   via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
>   .bbappend file
>
>
> Would the following patch be appropriate?

It does and your analysis is right.

John, please give this patch a try as it does seem to fix your issue
at https://bugzilla.yoctoproject.org/show_bug.cgi?id=4850

Simon,

Can you please put a note about this issue in your commit log? like:

Fixes [YOCTO #4850].


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

Re: mx6q: fix virtual/libgl dependencies

[Otavio Salvador]

On Thu, Jul 18, 2013 at 9:28 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Thu, Jul 18, 2013 at 9:03 AM, Simon Braunschmidt <sb@emlix.com> wrote:
>> Hi
>>
>> I am still new to Yocto, so bear with me if some of the following
>> is not correct, you are welcome to open my eyes though ;-)
>>
>> I have observed a problem to compile libglu in a configuration
>> for cgtqmx6 (imx6, from meta-fsl-arm-extra).
>> For a completely clean rebuild, sometimes compilation succeeds,
>> but sometimes it fails, not finding libGL for linking:
>>
>> /home/devel/yocto/ ... /arm-poky-linux-gnueabi/4.8.1/ld: cannot find -lGL
>> collect2: error: ld returned 1 exit status
>>
>> It looks like a race condition, sometimes the package/task providing
>> libGL is ready when libglu is compiled, sometimes not.
>>
>> Some findings:
>>
>> - meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
>>   delete libGL.* after compilation of mesa
>>
>> - ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
>>   gpu-viv-bin-mx6q.inc, provides its own version of libGL
>>
>> - gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="
>>
>> - but mesa (via mesa.inc) does:
>>   PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
>>
>> - so the statement in imx-base.inc
>>    PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
>>   does not have effect, because mesa is still the only provider of virtual/libgl
>>
>> - packages depending on virtual/libgl only get mesa, which will not contain
>>   the libGL library
>>
>> - in fact, we still use the gl headers from mesa, but the binary blob library
>>   from gpu-viv-bin-mx6q (i have no words to describe this ...),
>>         so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q
>>
>> - so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
>>   gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
>>   via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
>>   .bbappend file
>>
>>
>> Would the following patch be appropriate?
>
> It does and your analysis is right.
>
> John, please give this patch a try as it does seem to fix your issue
> at https://bugzilla.yoctoproject.org/show_bug.cgi?id=4850
>
> Simon,
>
> Can you please put a note about this issue in your commit log? like:
>
> Fixes [YOCTO #4850].

Another minor fix, use:

gpu-viv-bin-mx6q, mesa: fix virtual/libgl dependencies

as shortlog, so it is clear which recipes it changes.

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

Re: mx6q: fix virtual/libgl dependencies

[Simon Braunschmidt]

Hi Otavio, John

Sorry, wrong @yoctoproject.com address in the first mail.

I applied the suggestions (and also changed my wording regarding
the mixed nature of the packaging).

The bug #4850 looks indeed like this one.

Regards,
Simon

[PATCH] gpu-viv-bin-mx6q, mesa: fix virtual/libgl dependencies

[Simon Braunschmidt]

Fixes [YOCTO #4850]

findings:
* meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
  delete libGL.* after compilation of mesa

* ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
  gpu-viv-bin-mx6q.inc, provides its own version of libGL

* gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="

* but mesa (via mesa.inc) does:
  PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"

* so the statement in imx-base.inc
   PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
  does not have effect, because mesa is still the only provider
  of virtual/libgl

* packages depending on virtual/libgl only get mesa, which will not contain
  the libGL library

* in fact, we still use the gl headers from mesa, but the binary blob library
  from gpu-viv-bin-mx6q (gpu-viv-bin-mx6q does not provide the headers),
  so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q

conclusion:
* so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
  gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
  via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
  .bbappend file

Signed-off-by: Simon Braunschmidt <sb@emlix.com>
---
 .../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc          |    4 ++--
 recipes-graphics/mesa/mesa_9.1.3.bbappend          |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index b007079..3354854 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -6,8 +6,8 @@ DESCRIPTION = "GPU driver and apps for imx6"
 SECTION = "libs"
 LICENSE = "Proprietary"
 LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=19f5925343fa3da65596eeaa4ddb5fd3"
-DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)}"
-PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)} mesa"
+PROVIDES += "virtual/libgl virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
 
 INC_PR = "r5"
 
diff --git a/recipes-graphics/mesa/mesa_9.1.3.bbappend b/recipes-graphics/mesa/mesa_9.1.3.bbappend
index b0535a7..9308952 100644
--- a/recipes-graphics/mesa/mesa_9.1.3.bbappend
+++ b/recipes-graphics/mesa/mesa_9.1.3.bbappend
@@ -23,7 +23,7 @@ python __anonymous () {
 
         # Remove itens from provides
         provides = d.getVar('PROVIDES', True).split()
-        take_out = ['virtual/libgles1', 'virtual/libgles2', 'virtual/egl']
+        take_out = ['virtual/libgles1', 'virtual/libgles2', 'virtual/egl', 'virtual/libgl']
         new_provides = []
         for i in provides:
             if i not in take_out:
-- 
1.7.9.5

Re: [PATCH] gpu-viv-bin-mx6q, mesa: fix virtual/libgl dependencies

[Eric Bénard]

Hi Simon,

Le Thu, 18 Jul 2013 15:19:25 +0200,
Simon Braunschmidt <sb@emlix.com> a écrit :

> Fixes [YOCTO #4850]
> 
> findings:
> * meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
>   delete libGL.* after compilation of mesa
> 
> * ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
>   gpu-viv-bin-mx6q.inc, provides its own version of libGL
> 
> * gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="
> 
> * but mesa (via mesa.inc) does:
>   PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
> 
> * so the statement in imx-base.inc
>    PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
>   does not have effect, because mesa is still the only provider
>   of virtual/libgl
> 
> * packages depending on virtual/libgl only get mesa, which will not contain
>   the libGL library
> 
> * in fact, we still use the gl headers from mesa, but the binary blob library
>   from gpu-viv-bin-mx6q (gpu-viv-bin-mx6q does not provide the headers),
>   so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q
> 
> conclusion:
> * so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
>   gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
>   via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
>   .bbappend file
> 
> Signed-off-by: Simon Braunschmidt <sb@emlix.com>
> ---
>  .../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc          |    4 ++--
>  recipes-graphics/mesa/mesa_9.1.3.bbappend          |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> index b007079..3354854 100644
> --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> @@ -6,8 +6,8 @@ DESCRIPTION = "GPU driver and apps for imx6"
>  SECTION = "libs"
>  LICENSE = "Proprietary"
>  LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=19f5925343fa3da65596eeaa4ddb5fd3"
> -DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)}"
> -PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
> +DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)} mesa"
> +PROVIDES += "virtual/libgl virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
>  
this may also fix this problem :
| Collected errors:
|  * satisfy_dependencies_for: Cannot satisfy the following
dependencies for packagegroup-core-x11-base: |  *    libgl-mesa (>=
9.0.2) * |  * opkg_install_cmd: Cannot install package
packagegroup-core-x11-base.

Eric

Re: [PATCH] gpu-viv-bin-mx6q, mesa: fix virtual/libgl dependencies

[Otavio Salvador]

On Thu, Jul 18, 2013 at 10:26 AM, Eric Bénard <eric@eukrea.com> wrote:
> Hi Simon,
>
> Le Thu, 18 Jul 2013 15:19:25 +0200,
> Simon Braunschmidt <sb@emlix.com> a écrit :
>
>> Fixes [YOCTO #4850]
>>
>> findings:
>> * meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
>>   delete libGL.* after compilation of mesa
>>
>> * ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
>>   gpu-viv-bin-mx6q.inc, provides its own version of libGL
>>
>> * gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="
>>
>> * but mesa (via mesa.inc) does:
>>   PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
>>
>> * so the statement in imx-base.inc
>>    PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
>>   does not have effect, because mesa is still the only provider
>>   of virtual/libgl
>>
>> * packages depending on virtual/libgl only get mesa, which will not contain
>>   the libGL library
>>
>> * in fact, we still use the gl headers from mesa, but the binary blob library
>>   from gpu-viv-bin-mx6q (gpu-viv-bin-mx6q does not provide the headers),
>>   so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q
>>
>> conclusion:
>> * so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
>>   gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
>>   via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
>>   .bbappend file
>>
>> Signed-off-by: Simon Braunschmidt <sb@emlix.com>
>> ---
>>  .../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc          |    4 ++--
>>  recipes-graphics/mesa/mesa_9.1.3.bbappend          |    2 +-
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> index b007079..3354854 100644
>> --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> @@ -6,8 +6,8 @@ DESCRIPTION = "GPU driver and apps for imx6"
>>  SECTION = "libs"
>>  LICENSE = "Proprietary"
>>  LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=19f5925343fa3da65596eeaa4ddb5fd3"
>> -DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)}"
>> -PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
>> +DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxdamage libxext libxfixes', '', d)} mesa"
>> +PROVIDES += "virtual/libgl virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2"
>>
> this may also fix this problem :
> | Collected errors:
> |  * satisfy_dependencies_for: Cannot satisfy the following
> dependencies for packagegroup-core-x11-base: |  *    libgl-mesa (>=
> 9.0.2) * |  * opkg_install_cmd: Cannot install package
> packagegroup-core-x11-base.

I think so. Can you give it a try Eric? I am putting this in my
autobuilder (master-next) and will let it building for a while.

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

Re: mx6q: fix virtual/libgl dependencies

[John Weber]

This works to fix the build issues I was having with libglu. Thanks!

On 7/18/13 8:19 AM, Simon Braunschmidt wrote:
> Hi Otavio, John
>
> Sorry, wrong @yoctoproject.com address in the first mail.
>
> I applied the suggestions (and also changed my wording regarding
> the mixed nature of the packaging).
>
> The bug #4850 looks indeed like this one.
>
> Regards,
> Simon
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>