[OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

[Nicolas Dechesne]

When building QTe SDK for a DISTRO that does not have x11 FEATURES,
building meta-toolchain-qte failed because it unconditionally pulls in
nativesdk-libx11. The 'culprit' is meta/recipes-qt/qt4/nativesdk-qt4-tools.inc.

The fix is inspired from the following commits:

abf2ab7 dbus: only use x11 if DISTRO_FEATURES has selected it
ba22cfa cairo: only use x11 if selected in DISTRO_FEATURES

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-qt/qt4/nativesdk-qt4-tools.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc 
b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
index cfc6fd8..3725cac 100644
--- a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
+++ b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
@@ -1,5 +1,6 @@
 DESCRIPTION = SDK tools for Qt/[X11|Mac|Embedded] version 4.x
-DEPENDS = nativesdk-zlib nativesdk-dbus nativesdk-libx11 qt4-native
+X11DEPENDS = nativesdk-libx11
+DEPENDS = nativesdk-zlib nativesdk-dbus qt4-native 
${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}
 SECTION = libs
 HOMEPAGE = http://qt.nokia.com;
 LICENSE = LGPLv2.1 | GPLv3
-- 
1.8.1.2

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

Re: [OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

[Nicolas Dechesne]

On Wed, Jun 5, 2013 at 6:30 PM, Saul Wold s...@linux.intel.com wrote:

 You could just directly put the nativesdk-libx11 in place of the variable,
 no need to have the variable there.


yes, that's what I had initially, but found it was less easy to read...
with X11DEPENDS it's more 'obvious' that there is something special.. that
said, i can make the change if that's really needed.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

[Nicolas Dechesne]

On Wed, Jun 5, 2013 at 7:19 PM, Saul Wold s...@linux.intel.com wrote:

 On 06/05/2013 10:12 AM, Otavio Salvador wrote:




 On Wed, Jun 5, 2013 at 1:58 PM, Saul Wold s...@linux.intel.com
 mailto:s...@linux.intel.com wrote:

 On 06/05/2013 09:32 AM, Nicolas Dechesne wrote:


 On Wed, Jun 5, 2013 at 6:30 PM, Saul Wold s...@linux.intel.com
 mailto:s...@linux.intel.com
 mailto:s...@linux.intel.com mailto:s...@linux.intel.com wrote:

  You could just directly put the nativesdk-libx11 in place
 of the
  variable, no need to have the variable there.


 yes, that's what I had initially, but found it was less easy to
 read...
 with X11DEPENDS it's more 'obvious' that there is something
 special..
 that said, i can make the change if that's really needed.

 We do use the X11DEPENDS elsewhere when there are multiple
 dependencies, but I also found cases where we just include the
 dependency directly in the test. I was trying pick a direction:
 single entry no X11DEPENDS, multiple entries use X11DEPENDS.

 Comments, flames, ...


 Yes; I sent this patch in Febuary:
 http://patchwork.openembedded.**org/patch/44759/http://patchwork.openembedded.org/patch/44759/

 Please use this one instead of the recent one.


 Well reading back on that, it looks like I was waiting for an EXTRA_OECONF
 or related change to the autoconf scripts.

 Sau!


hmm. ok, sorry Otavio, i missed the other patch. I will check on my side
too about EXTRA_OECONF.




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


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

Re: [OE-core] [PATCH dylan, master] Fix meta-toolchain-qte SDK build for x11-less DISTRO

[Nicolas Dechesne]

On Thu, Jun 6, 2013 at 5:46 PM, Richard Purdie 
richard.pur...@linuxfoundation.org wrote:

 On Wed, 2013-06-05 at 16:58 -0400, Denys Dmytriyenko wrote:
  On Wed, Jun 05, 2013 at 05:56:31PM -0300, Otavio Salvador wrote:
   On Wed, Jun 5, 2013 at 5:53 PM, Saul Wold s...@linux.intel.com wrote:
  
On 06/05/2013 01:10 PM, Otavio Salvador wrote:
   
   
   
   
On Wed, Jun 5, 2013 at 5:07 PM, Denys Dmytriyenko de...@denix.org
mailto:de...@denix.org wrote:
   
On Wed, Jun 05, 2013 at 02:43:07PM -0300, Otavio Salvador wrote:
  On Wed, Jun 5, 2013 at 2:23 PM, Nicolas Dechesne 
  nicolas.deche...@linaro.org mailto:nicolas.dechesne@**
 linaro.orgnicolas.deche...@linaro.org

   
wrote:
 
  
  
  
   On Wed, Jun 5, 2013 at 7:19 PM, Saul Wold 
 s...@linux.intel.com
mailto:s...@linux.intel.com wrote:
  
   On 06/05/2013 10:12 AM, Otavio Salvador wrote:
  
  
  
  
   On Wed, Jun 5, 2013 at 1:58 PM, Saul Wold
s...@linux.intel.com mailto:s...@linux.intel.com
   mailto:s...@linux.intel.com mailto:s...@linux.intel.com
 
wrote:
  
   On 06/05/2013 09:32 AM, Nicolas Dechesne wrote:
  
  
   On Wed, Jun 5, 2013 at 6:30 PM, Saul Wold
s...@linux.intel.com mailto:s...@linux.intel.com
   mailto:s...@linux.intel.com mailto:
s...@linux.intel.com
   mailto:s...@linux.intel.com
mailto:s...@linux.intel.com mailto:s...@linux.intel.com
mailto:s...@linux.intel.com**
   wrote:
  
You could just directly put the
 nativesdk-libx11
in place
   of the
variable, no need to have the variable
 there.
  
  
   yes, that's what I had initially, but found it
 was
less easy to
   read...
   with X11DEPENDS it's more 'obvious' that there is
something
   special..
   that said, i can make the change if that's really
needed.
  
   We do use the X11DEPENDS elsewhere when there are
 multiple
   dependencies, but I also found cases where we just
include the
   dependency directly in the test. I was trying pick a
direction:
   single entry no X11DEPENDS, multiple entries use
X11DEPENDS.
  
   Comments, flames, ...
  
  
   Yes; I sent this patch in Febuary:
  
http://patchwork.openembedded.org/patch/44759/http://**
patchwork.openembedded.org/**patch/44759/
 http://patchwork.openembedded.org/patch/44759/

  
   Please use this one instead of the recent one.
  
  
   Well reading back on that, it looks like I was waiting
 for an
   EXTRA_OECONF or related change to the autoconf scripts.
  
   Sau!
  
  
   hmm. ok, sorry Otavio, i missed the other patch. I will
 check
on my side
   too about EXTRA_OECONF.
  
 
  Nicolas, don't worry. It is normal to end redoing some stuff.
 
  Last time I checked it had no support in Qt build system; I
 am
not sure if
  it uses or not the host headers (in case they exist) but it
 needs
testing
  to be sure.
   
I can confirm that it does not link against host X11 when built
 w/o
that
dependency and nativesdk has no x11 libs/headers. As I
 previously
mentioned,
we've been using this fix for over 6 months on several releases
 built
on
different machines w/o problems...
   
   
In this case the patch can be merged 'as is'.
   
   
I am still concerned about a floating dependency here, imagine the
following:
   
Build the toolchain with X11 enabled, nativesdk-libx11 is build, now
rebuild with X11 disabled, the dependency is gone, but the libraries
 and
headers still exist in the sysroot and thus the configure will still
 enable
x11 in qte, bad things happen.
   
  
   I expect different distro features to have different build dirs. No?
  
  
We need to have a disable flag to autotools.
   
  
   The qmake based system does not provide this; so to support it, it will
   need to be a hack ...
 
  I agree with Otavio here - seems like you are after a rare corner case
 here...

 We need determinism in the builds. Yes in this case it might be hard to
 achieve but I do think we need to achieve it.

 So this patch isn't going in until we can avoid this option magically
 floating, sorry. I've said this before and I've not changed my mind.


I think the -embedded flag in the configure option is what makes a QT build
Embedded vs X11, at least based on [1].

what's

Re: [OE-core] qt4-embedded - image size

[Nicolas Dechesne]

On Mon, Jun 10, 2013 at 1:19 PM, John Stirling
ap.john.stirl...@gmail.comwrote:

 You suggest just cutting it down to

 IMAGE_INSTALL +=  \
 qtui \
 
 and it should work itself out ?


hi, i have observed the same issue, and I used the following 'workaround':

BAD_RECOMMENDATIONS =  \
qt4-embedded-demos \
qt4-embedded-examples \
qt4-embedded-demos-doc \
qt4-embedded-tools \
qt4-embedded-assistant \

which I added in my image recipe, that would ensure that the packages which
are RECOMMENDS don't get installed in the final image.

I would be happy to use another (nicer?) method, too.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] qt4-embedded - image size

[Nicolas Dechesne]

On Mon, Jun 10, 2013 at 2:59 PM, Eric Bénard e...@eukrea.com wrote:

 Hi Nicolas,

 Le Mon, 10 Jun 2013 14:10:15 +0200,
 Nicolas Dechesne nicolas.deche...@linaro.org a écrit :

  On Mon, Jun 10, 2013 at 1:19 PM, John Stirling
  ap.john.stirl...@gmail.comwrote:
 
   You suggest just cutting it down to
  
   IMAGE_INSTALL +=  \
   qtui \
   
   and it should work itself out ?
  

 this will work but if you need plugins they will be missing as only the
 linked libraries will be automatically integrated.

 
  hi, i have observed the same issue, and I used the following
 'workaround':
 
  BAD_RECOMMENDATIONS =  \
  qt4-embedded-demos \
  qt4-embedded-examples \
  qt4-embedded-demos-doc \
  qt4-embedded-tools \
  qt4-embedded-assistant \
  
  which I added in my image recipe, that would ensure that the packages
 which
  are RECOMMENDS don't get installed in the final image.
 
  I would be happy to use another (nicer?) method, too.


 check packagegroup-core-qt4e.bb and remove :
 qt4-embedded-demos \
 qt4-embedded-examples \
 qt-demo-init \
 qt4-embedded-assistant \

 (and also the plugins  libs you may not need)

 FWIW I'm using this to build a quite full featured qt4e base image :
 RDEPENDS_append +=  \
 qt4-embedded \
 

 QT_INSTALL =  \
 libqt-embedded3support4 \
 libqt-embeddedclucene4 \
 libqt-embeddedcore4 \
 libqt-embeddedgui4 \
 libqt-embeddednetwork4 \
 libqt-embeddedsvg4 \
 libqt-embeddedsql4 \
 libqt-embeddedxml4 \
 libqt-embeddedxmlpatterns4 \
 libqt-embeddedwebkit4 \
 libqt-embeddedscripttools4 \
 libqt-embeddedtest4 \
 libqt-embeddedmultimedia4 \
 libqt-embeddedhelp4 \
 libqt-embeddeddeclarative4 \
 libqt-embeddeddbus4 \
 libqt-embeddedphonon4 \
 \
 qt4-embedded-fonts-ttf-vera \
 qt4-embedded-fonts-ttf-dejavu \
 qt4-embedded-plugin-mousedriver-tslib \
 qt4-embedded-plugin-sqldriver-sqlite2 \
 qt4-embedded-plugin-sqldriver-sqlite \
 qt4-embedded-plugin-phonon-backend-gstreamer \
 qt4-embedded-plugin-iconengine-svgicon \
 qt4-embedded-plugin-imageformat-gif \
 qt4-embedded-plugin-imageformat-ico \
 qt4-embedded-plugin-imageformat-jpeg \
 qt4-embedded-plugin-imageformat-mng \
 qt4-embedded-plugin-imageformat-svg \
 qt4-embedded-plugin-imageformat-tiff \
 sqlite3 \
 

 QWT_INSTALL =  \
 qwt-e \
 

 IMAGE_INSTALL += \
 ${QT_INSTALL} \
 ${QWT_INSTALL} \
 

 and I add this when I want the examples :
 IMAGE_INSTALL += \
 qt4-embedded-demos qt4-embedded-examples qt-demo-init \
 qwt-e-examples \
 
 (qt-demo-init is a homemade init script).


hi Eric,

thanks for your answer. so, yes I kind of figured out I could do that. But
in fact I was hoping that re-using the existing packagegroup from oe-core
*should* be the right thing to do, instead of re-implementing another one.
and perhaps the packagegroup being called core-qt4e should be restricted to
'core' components, and we could have 1 (or more) additional packagegroups
that could be pulled into images, instead? otherwise what's the point of
having a 'core QT4e packagegroup' if it's not suitable for any real usage?

now, given the current QT4/QT5 stuff, i don't know how relevant this
discussion is.. but i wanted to point out that as a newcomer to this area,
that has been quite confusing!




 Eric

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

Re: [OE-core] Issues with Qt5/mesa and eglfs

[Nicolas Dechesne]

resending on proper mailling list, +cc Paul as it's dylan related.


On Thu, Jun 20, 2013 at 9:15 AM, Nicolas Dechesne 
nicolas.deche...@linaro.org wrote:

 hi there,

 i am trying to build Qt5/meta-qt5 with dylan branch in a non X11 distro,
 and i got failures during the Qt5 configure step (when auto-detecting EGL
 feature). Looking into the issue, the good news is that it seems to be
 fixed in oe-core/master with:

 d7033f4 mesa: upgrade to 9.1.3

 thanks to this :

 Add EGL-Mutate-NativeDisplayType-depending-on-config.patch to build
 correctly in
 a non-X11 environment.

 Drop dont-fail-if-libX11-isnt-installed.patch and
 fix-egl-compilation-without-x11-headers.patch as they were backports.


 Would you guys consider 'backporting' this patch onto dylan a viable
 thing? I will make the backport, but it would be nice if you can confirm
 that it can be merged in dylan.

 thanks

 nico

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

Re: [OE-core] Issues with Qt5/mesa and eglfs

[Nicolas Dechesne]

On Thu, Jun 20, 2013 at 11:42 AM, Paul Eggleton 
paul.eggle...@linux.intel.com wrote:

 I wasn't watching closely but my impression is there were a large number of
 changes associated with the mesa upgrade. Is the upgrade itself necessary
 for
 the fix?


no, i don't think so. I think we might be able to just update the patches
that deal with the X11/no X11 support. but i haven't tested that yet. i
just did a quick test by cherry picking the complete commit (e.g. mesa
upgrade) to verify that it's actually fixing my problem. now that i know it
does, i will try to just upgrade the patches without the mesa upgrade and
report how it goes.

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

Re: [OE-core] Issues with Qt5/mesa and eglfs

[Nicolas Dechesne]

On Thu, Jun 20, 2013 at 11:46 AM, Nicolas Dechesne 
nicolas.deche...@linaro.org wrote:

 On Thu, Jun 20, 2013 at 11:42 AM, Paul Eggleton 
 paul.eggle...@linux.intel.com wrote:

 I wasn't watching closely but my impression is there were a large number
 of
 changes associated with the mesa upgrade. Is the upgrade itself necessary
 for
 the fix?


 no, i don't think so. I think we might be able to just update the patches
 that deal with the X11/no X11 support. but i haven't tested that yet. i
 just did a quick test by cherry picking the complete commit (e.g. mesa
 upgrade) to verify that it's actually fixing my problem. now that i know it
 does, i will try to just upgrade the patches without the mesa upgrade and
 report how it goes.


ok, i was able to backport the mesa patch from 9.1.3 to 9.0.2
(EGL-Mutate-NativeDisplayType-depending-on-config.patch) , the backport was
more or less trivial. and then i did this in dylan branch:

--- a/meta/recipes-graphics/mesa/mesa-9.0.2.inc
+++ b/meta/recipes-graphics/mesa/mesa-9.0.2.inc
@@ -2,7 +2,7 @@ SRC_URI = 
ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
file://0002-cross-compile.patch \
file://cross-glsl.patch \
file://dont-fail-if-libX11-isnt-installed.patch \
-   file://fix-egl-compilation-without-x11-headers.patch \
+   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \


and it does fix the build issue i had (mesa/qt5/non X11 distro).

should that be merged into dylan (since it's merged in master already) or
do we need to wait for the 'final' patch in upstream to be ready?

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

Re: [OE-core] Issues with Qt5/mesa and eglfs

[Nicolas Dechesne]

On Thu, Jun 20, 2013 at 8:15 PM, Nicolas Dechesne 
nicolas.deche...@linaro.org wrote:


 On Thu, Jun 20, 2013 at 11:46 AM, Nicolas Dechesne 
 nicolas.deche...@linaro.org wrote:

 On Thu, Jun 20, 2013 at 11:42 AM, Paul Eggleton 
 paul.eggle...@linux.intel.com wrote:

 I wasn't watching closely but my impression is there were a large number
 of
 changes associated with the mesa upgrade. Is the upgrade itself
 necessary for
 the fix?


 no, i don't think so. I think we might be able to just update the patches
 that deal with the X11/no X11 support. but i haven't tested that yet. i
 just did a quick test by cherry picking the complete commit (e.g. mesa
 upgrade) to verify that it's actually fixing my problem. now that i know it
 does, i will try to just upgrade the patches without the mesa upgrade and
 report how it goes.


 ok, i was able to backport the mesa patch from 9.1.3 to 9.0.2
 (EGL-Mutate-NativeDisplayType-depending-on-config.patch) , the backport was
 more or less trivial. and then i did this in dylan branch:

 --- a/meta/recipes-graphics/mesa/mesa-9.0.2.inc
 +++ b/meta/recipes-graphics/mesa/mesa-9.0.2.inc
 @@ -2,7 +2,7 @@ SRC_URI = 
 ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
 file://0002-cross-compile.patch \
 file://cross-glsl.patch \
 file://dont-fail-if-libX11-isnt-installed.patch \
 -   file://fix-egl-compilation-without-x11-headers.patch \
 +   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \
 

 and it does fix the build issue i had (mesa/qt5/non X11 distro).

 should that be merged into dylan (since it's merged in master already) or
 do we need to wait for the 'final' patch in upstream to be ready?



Paul, Martin, what do you think about this? i have the (trivial) dylan
backport ready. Do you think it's the right time to get it merged?




 thanks



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

[OE-core] [dylan][PATCH] mesa: fix EGL compilation without X11 headers

[Nicolas Dechesne]

Extracted from d7033f4 mesa: upgrade to 9.1.3, already merged in master:

--
Add EGL-Mutate-NativeDisplayType-depending-on-config.patch to build correctly in
a non-X11 environment.

Drop fix-egl-compilation-without-x11-headers.patch as they were backports.
--

The new patch was also backported (trivial) to mesa 9.0.2 which is in
dylan.

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/mesa/mesa-9.0.2.inc  |   2 +-
 ...ate-NativeDisplayType-depending-on-config.patch | 361 +
 2 files changed, 362 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch

diff --git a/meta/recipes-graphics/mesa/mesa-9.0.2.inc 
b/meta/recipes-graphics/mesa/mesa-9.0.2.inc
index b88bc42..e2dcfdb 100644
--- a/meta/recipes-graphics/mesa/mesa-9.0.2.inc
+++ b/meta/recipes-graphics/mesa/mesa-9.0.2.inc
@@ -2,7 +2,7 @@ SRC_URI = 
ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
file://0002-cross-compile.patch \
file://cross-glsl.patch \
file://dont-fail-if-libX11-isnt-installed.patch \
-   file://fix-egl-compilation-without-x11-headers.patch \
+   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \

 
 SRC_URI[md5sum] = dc45d1192203e418163e0017640e1cfc
diff --git 
a/meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
 
b/meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
new file mode 100644
index 000..98c4095
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
@@ -0,0 +1,361 @@
+From 7e5846aa52c7cb00b0db9fa393975880371d2620 Mon Sep 17 00:00:00 2001
+From: Daniel Stone dan...@fooishbar.org
+Date: Fri, 24 May 2013 17:20:27 +0100
+Subject: [PATCH] EGL: Mutate NativeDisplayType depending on config
+
+If we go through ./configure without enabling X11 anywhere, then set the
+fallback types for EGL NativeDisplay and friends, rather than assuming
+X11/Xlib.
+
+Signed-off-by: Daniel Stone dan...@fooishbar.org
+
+Conflicts:
+   configure.ac
+---
+ configure.ac |   9 +++
+ include/EGL/eglplatform.h| 146 ---
+ include/EGL/eglplatform.h.in | 146 +++
+ 3 files changed, 155 insertions(+), 146 deletions(-)
+ delete mode 100644 include/EGL/eglplatform.h
+ create mode 100644 include/EGL/eglplatform.h.in
+
+diff --git a/configure.ac b/configure.ac
+index 682e0a5..a8a485d 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1577,12 +1577,20 @@ fi
+ 
+ EGL_PLATFORMS=$egl_platforms
+ 
++if echo $egl_platforms | grep 'x11' /dev/null 21; then
++MESA_EGL_NO_X11_HEADERS=0
++else
++MESA_EGL_NO_X11_HEADERS=1
++fi
++
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_X11, echo $egl_platforms | grep 'x11' 
/dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_WAYLAND, echo $egl_platforms | grep 
'wayland' /dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_DRM, echo $egl_platforms | grep 'drm' 
/dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_FBDEV, echo $egl_platforms | grep 'fbdev' 
/dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_NULL, echo $egl_platforms | grep 'null' 
/dev/null 21)
+ 
++AC_SUBST([MESA_EGL_NO_X11_HEADERS])
++
+ AM_CONDITIONAL(HAVE_EGL_DRIVER_DRI2, test x$HAVE_EGL_DRIVER_DRI2 != x)
+ AM_CONDITIONAL(HAVE_EGL_DRIVER_GLX, test x$HAVE_EGL_DRIVER_GLX != x)
+ 
+@@ -1953,6 +1961,7 @@ CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS
+ dnl Substitute the config
+ AC_CONFIG_FILES([configs/current
+   Makefile
++  include/EGL/eglplatform.h
+   src/egl/Makefile
+   src/egl/drivers/Makefile
+   src/egl/drivers/dri2/Makefile
+diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
+deleted file mode 100644
+index 17fdc61..000
+--- a/include/EGL/eglplatform.h
 /dev/null
+@@ -1,146 +0,0 @@
+-#ifndef __eglplatform_h_
+-#define __eglplatform_h_
+-
+-/*
+-** Copyright (c) 2007-2009 The Khronos Group Inc.
+-**
+-** Permission is hereby granted, free of charge, to any person obtaining a
+-** copy of this software and/or associated documentation files (the
+-** Materials), to deal in the Materials without restriction, including
+-** without limitation the rights to use, copy, modify, merge, publish,
+-** distribute, sublicense, and/or sell copies of the Materials, and to
+-** permit persons to whom the Materials are furnished to do so, subject to
+-** the following conditions:
+-**
+-** The above copyright notice and this permission notice shall be included
+-** in all copies or substantial portions of the Materials.
+-**
+-** THE MATERIALS ARE PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+-** EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+-** MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+-** IN NO EVENT

Re: [OE-core] [PATCH] Checksums for local files now stored using partial recipe path

[Nicolas Dechesne]

On Tue, Jul 16, 2013 at 6:28 PM, Paul Eggleton 
paul.eggle...@linux.intel.com wrote:

 I just got around to trying this again, only this time I cloned a new poky
 tree in a different path which should replicate your situation and used
 SSTATE_MIRRORS to point to the previous sstate-cache. It built completely
 from
 sstate as it expected. For reference I was testing with the latest dylan
 branch and core-image-minimal.

 As I said earlier, if you look at the code only the checksum value goes
 into
 the task checksum and not the filename, so the path to the base of the
 metadata
 changing cannot influence the task checksum. However, I think I can see
 how you
 would think that the paths changing influenced the checksum, since the data
 that we put into the siginfo file *does* contain the full path, and thus
 bitbake-diffsigs will report that as having changed even though that
 difference
 didn't change the task checksum. That is a bug and we should fix how we
 store
 paths either in the cache or in the siginfo file, but that fix will have
 to take
 into account different layer paths. I'd suggest a simpler and more reliable
 approach would be to just get the relative path to os.path.dirname of the
 recipe rather than TOPDIR.

 As far as I can tell though that won't actually fix the issue triggering
 rebuilds in your case. Something else must be changing. It would be
 interesting if you could dig into what that might be as I can't reproduce
 the
 rebuilding issue here.


on a related topic, we have given a 'hands on workshop' last week at our
Linaro Conference. in order to avoid potential network issues and wasting
too much time building, we had prepared 'tarballs' for 1) download folder,
2) sstate

For sstate we have prepared a couple of such archive for OpenSuse and
Ubuntu (12.04, 13.04) for both 32-bit and 64-bit variants.

We used 'dylan' in our workshop since the archives were created a couple of
days before, to avoid new commits in master.

Interesting remarks:
 - 'download' archive worked nicely for everyone
 - 'sstate' archive worked for some people, but not everyone.

In my particular case I was able to run a complete build from sstate
without rebuilding *anything* using the 13.04-64 sstate tarball. but for
some people it only used the sstate partially. I didn't get a chance to
'debug' what the problem was. but all our files are available in case some
more folks want to play with them.

You can download the archives here:
http://people.linaro.org/~trevor.woerner/LCE2013/

And the instructions to recreate the 'build env' (e.g. checkout the layers)
is described here: https://collaborate.linaro.org/x/NYBm
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] directfb: don't patch pkg-config files

[Nicolas Dechesne]

On Fri, Jul 19, 2013 at 10:39 AM, André Draszik andre.dras...@linaro.orgwrote:

 We are currently getting build failures of projects that rely on
 being able to access DirectFB's internal include directories, as
 returned via pkg-config, since the include paths returned by
 pkg-config are incomplete.

 The reason for that is the patch that is being removed with this
 change. It modified the cflags returned by pkg-config in an
 incorrect way, causing us to miss important include paths:

 For reference, pkg-config output with incorrect patch applied:
   ad@bril0118 #513 ~ pkg-config --cflags directfb-internal
 -D_GNU_SOURCE -D_REENTRANT
 -Ibuilddir/tmp/sysroots/machine/usr/include/directfb
 -Ibuilddir/tmp/sysroots/machine/usr/include

 Now, with the incorrect patch removed, the output is as expected:
   ad@bril0118 #514 ~ pkg-config --cflags directfb-internal
 -D_GNU_SOURCE -D_REENTRANT
 -Ibuilddir/tmp/sysroots/machine/usr/include/directfb-internal
 -Ibuilddir/tmp/sysroots/machine/usr/include/directfb

 Overall, the removed patch is not needed - pkg-config does the right
 thing these days and we can simply use the correctly working upstream
 versions of all DirectFB .pc files.

 Signed-off-by: André Draszik andre.dras...@linaro.org


i reviewed and tested this patch against a QT4e image build. it looks good
to me, and that offending patch being removed seems to come from quite
ancient stuff.

Tested-by: Nicolas Dechesne nicolas.deche...@linaro.org

any chance this can get into 'dylan', too?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] SRC_URI and latest HEAD revision with git

[Nicolas Dechesne]

On Mon, Jul 22, 2013 at 8:21 AM, Steffen Sledz sl...@dresearch-fe.dewrote:

 After being OE abstinent for some months i'd like to ask what is the
 current suggested method for recipes building from the HEAD revision of a
 git repository (we need this for continuous integration).

 I read some RFC's in the ml about PKGV/PKGR stuff, but i miss a final
 decision, documentation and a good example.


you can use ${AUTOREV} for this purpose. You can look at poky-bleeding
distro config for such an example.

e.g.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/include/poky-floating-revisions.inc
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [dylan][PATCH v2] mesa: fix EGL compilation without X11 headers

[Nicolas Dechesne]

Extracted from d7033f4 mesa: upgrade to 9.1.3, already merged in master.

Add EGL-Mutate-NativeDisplayType-depending-on-config.patch to build correctly in
a non-X11 environment, it replaces 
fix-egl-compilation-without-x11-headers.patch.

The new patch fixes compilation issues for components that include
EGL/eglplatform.h file. With the original patch it was required to use
-DMESA_EGL_NO_X11_HEADERS when using mesa .h files to get proper C definitions.

The new patch was backported (trivial) to mesa 9.0.2 which is in dylan.

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/mesa/mesa-9.0.2.inc  |   2 +-
 ...ate-NativeDisplayType-depending-on-config.patch | 361 +
 .../fix-egl-compilation-without-x11-headers.patch  |  32 --
 3 files changed, 362 insertions(+), 33 deletions(-)
 create mode 100644 
meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
 delete mode 100644 
meta/recipes-graphics/mesa/mesa/fix-egl-compilation-without-x11-headers.patch

diff --git a/meta/recipes-graphics/mesa/mesa-9.0.2.inc 
b/meta/recipes-graphics/mesa/mesa-9.0.2.inc
index b88bc42..e2dcfdb 100644
--- a/meta/recipes-graphics/mesa/mesa-9.0.2.inc
+++ b/meta/recipes-graphics/mesa/mesa-9.0.2.inc
@@ -2,7 +2,7 @@ SRC_URI = 
ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
file://0002-cross-compile.patch \
file://cross-glsl.patch \
file://dont-fail-if-libX11-isnt-installed.patch \
-   file://fix-egl-compilation-without-x11-headers.patch \
+   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \

 
 SRC_URI[md5sum] = dc45d1192203e418163e0017640e1cfc
diff --git 
a/meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
 
b/meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
new file mode 100644
index 000..98c4095
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
@@ -0,0 +1,361 @@
+From 7e5846aa52c7cb00b0db9fa393975880371d2620 Mon Sep 17 00:00:00 2001
+From: Daniel Stone dan...@fooishbar.org
+Date: Fri, 24 May 2013 17:20:27 +0100
+Subject: [PATCH] EGL: Mutate NativeDisplayType depending on config
+
+If we go through ./configure without enabling X11 anywhere, then set the
+fallback types for EGL NativeDisplay and friends, rather than assuming
+X11/Xlib.
+
+Signed-off-by: Daniel Stone dan...@fooishbar.org
+
+Conflicts:
+   configure.ac
+---
+ configure.ac |   9 +++
+ include/EGL/eglplatform.h| 146 ---
+ include/EGL/eglplatform.h.in | 146 +++
+ 3 files changed, 155 insertions(+), 146 deletions(-)
+ delete mode 100644 include/EGL/eglplatform.h
+ create mode 100644 include/EGL/eglplatform.h.in
+
+diff --git a/configure.ac b/configure.ac
+index 682e0a5..a8a485d 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1577,12 +1577,20 @@ fi
+ 
+ EGL_PLATFORMS=$egl_platforms
+ 
++if echo $egl_platforms | grep 'x11' /dev/null 21; then
++MESA_EGL_NO_X11_HEADERS=0
++else
++MESA_EGL_NO_X11_HEADERS=1
++fi
++
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_X11, echo $egl_platforms | grep 'x11' 
/dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_WAYLAND, echo $egl_platforms | grep 
'wayland' /dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_DRM, echo $egl_platforms | grep 'drm' 
/dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_FBDEV, echo $egl_platforms | grep 'fbdev' 
/dev/null 21)
+ AM_CONDITIONAL(HAVE_EGL_PLATFORM_NULL, echo $egl_platforms | grep 'null' 
/dev/null 21)
+ 
++AC_SUBST([MESA_EGL_NO_X11_HEADERS])
++
+ AM_CONDITIONAL(HAVE_EGL_DRIVER_DRI2, test x$HAVE_EGL_DRIVER_DRI2 != x)
+ AM_CONDITIONAL(HAVE_EGL_DRIVER_GLX, test x$HAVE_EGL_DRIVER_GLX != x)
+ 
+@@ -1953,6 +1961,7 @@ CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS
+ dnl Substitute the config
+ AC_CONFIG_FILES([configs/current
+   Makefile
++  include/EGL/eglplatform.h
+   src/egl/Makefile
+   src/egl/drivers/Makefile
+   src/egl/drivers/dri2/Makefile
+diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
+deleted file mode 100644
+index 17fdc61..000
+--- a/include/EGL/eglplatform.h
 /dev/null
+@@ -1,146 +0,0 @@
+-#ifndef __eglplatform_h_
+-#define __eglplatform_h_
+-
+-/*
+-** Copyright (c) 2007-2009 The Khronos Group Inc.
+-**
+-** Permission is hereby granted, free of charge, to any person obtaining a
+-** copy of this software and/or associated documentation files (the
+-** Materials), to deal in the Materials without restriction, including
+-** without limitation the rights to use, copy, modify, merge, publish,
+-** distribute, sublicense, and/or sell copies of the Materials, and to
+-** permit persons to whom the Materials are furnished to do so, subject to
+-** the following conditions:
+-**
+-** The above copyright

[OE-core] [masterdylan][PATCH] lib/oe/terminal.py: add support for MATE desktop terminals

[Nicolas Dechesne]

From: Andre McCurdy andre.mccu...@entropic.com

A simple clone of the corresponding Gnome class. Without this, devshell
fails completely on a default installation of MATE desktop Linux Mint 15.

Signed-off-by: Andre McCurdy andre.mccu...@entropic.com
Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/lib/oe/terminal.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 4502f34..be2a26b 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -55,6 +55,10 @@ class Gnome(XTerminal):
 command = 'gnome-terminal --disable-factory -t {title} -x {command}'
 priority = 2
 
+class Mate(XTerminal):
+command = 'mate-terminal --disable-factory -t {title} -x {command}'
+priority = 2
+
 class Xfce(XTerminal):
 command = 'Terminal -T {title} -e {command}'
 priority = 2
-- 
1.8.1.2

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

Re: [OE-core] [dylan]devshell: broken

[Nicolas Dechesne]

On Wed, Aug 14, 2013 at 7:54 AM, Andre armccu...@gmail.com wrote:

 bitbake -c devshell seems to have stopped working (tested with xterm
 and mate-terminal) in dylan since this commit:

   a749f06 terminal: Run command using a wrapper script

 It looks like the run.do_devshell.PID script is generated but then
 fails to run when passed to a terminal.

 A possible clue is that after manually editing the do_devshell script
 to replace:

   do_terminal() {
   exec pseudo /bin/bash
   }

 with:

   do_terminal() {
   exec /bin/bash
   }

 the script runs OK when passed to a terminal manually, such as:

   $ xterm -e tmp/work/.../temp/run.do_terminal.25789


I am observing the same issue here. I have tested 'devshell' against master
and dylan, and master seems to be working fine.

Here are the 2 generated run.do_terminal script for bitbake -c devshell
busybox

with dylan branch (failing) http://pastebin.com/jyBW2jEf

with master branch (working) http://pastebin.com/PHxJvj0k

 The problem when using the detault terminal (hence gnome-terminal in my
case), is that the gnome terminal windows shows up but very quickly
disappears. If I set OE_TERMINAL=screen, then i get something like that
in the failing case:
Currently 1 running tasks (67 of 67):
0: busybox-1.20.2-r8 do_devshell (pid 7566)
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded:
ignored.
There is no screen to be resumed matching devshell_7566.
Trying to run: screen -r devshell_7566
WARNING: Screen started. Please connect in another terminal with screen -r
devshell_7566
NOTE: Tasks Summary: Attempted 67 tasks of which 66 didn't need to be rerun
and all succeeded.

and it stops, and there is no screen session.

If I revert a749f06 terminal: Run command using a wrapper script from
oe-core dylan, it works again.

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

Re: [OE-core] [dylan][PATCH] classes/terminal: fix pseudo exiting when launching devshell

[Nicolas Dechesne]

On Wed, Aug 14, 2013 at 5:46 PM, Paul Eggleton 
paul.eggle...@linux.intel.com wrote:

 In dylan, since the entire bitbake process is run under pseudo,
 LD_PRELOAD is set when we collect BB_ORIGENV and thus when we construct
 the devshell environment from the latter, LD_PRELOAD is included.
 However, for a fakeroot task we explicitly run the devshell under pseudo
 (e.g. pseudo /bin/bash), and if LD_PRELOAD is set to preload
 libpseudo.so when pseudo is run, it seems to exit immediately without
 error. Since LD_PRELOAD shouldn't be exported anyway, exclude this from
 the environment so it doesn't prevent running the shell.

 Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com


thanks for fixing quickly. I have tested with gnome-terminal and screen,
and it works fine.

Tested-by: Nicolas Dechesne nicolas.deche...@linaro.org
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] New OE layer index now available

[Nicolas Dechesne]

hi,

this is a really useful addition! thanks!

On Fri, Mar 29, 2013 at 10:34 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
 The index also supports multiple branches, but for the moment there is only a
 master branch configured as I'd like to have people check the layer data 
 before
 adding the additional stable branches (danny and denzil).


i was thinking it might be useful (in fact at least it would be very
useful for me right now) to get version 'history' for each supported
branch. if i understand the design correctly, i first need to set the
branch I want to search, then search. but what about an 'all branch
search' that displays recipes version *and* layer for multiple
branches, so that we can easily see version change and recipe move
in-between layers between all branches.

does that make any sense to anyone?

nicolas

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

Re: [OE-core] [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

On Mon, Sep 9, 2013 at 2:12 PM, Burton, Ross ross.bur...@intel.com wrote:

 On 9 September 2013 13:08, Martin Jansa martin.ja...@gmail.com wrote:
  +REQUIRED_DISTRO_FEATURES = opengl
 
  Is this really needed? I was building mesa in distro without opengl for
  long time and was considering (probably incorrectly) opengl
 DISTRO_FEATURE more
  like sign of proper hw GL libraries.

 I'd always understood the opengl DISTRO_FEATURE to mean give me GL
 support.  *What* that means depends on the target hardware, could be
 entirely software rendering through Mesa or binary HW drivers.


how about gl vs gles?

i have been trying to understand over the last couple of days whether or
not 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think
it's clearly indicated anywhere.

in libsdl recipe, we have this:

DEPENDS = ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
d)} \

   ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} \

and in EXTRA_OECONF we add this:
${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
'--disable-video-opengl', d)} \


which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES. I
am building for ARM platforms with GLes support, but no GL support. I
initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being
pulled in because of libsdl, which was wrong. So we now removed 'opengl'
from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for
GPU, so we don't want mesa at all).

In weston recipe, we have this:
${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}

so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES, but
it's only used once (looking at oe-core and meta-oe).

To me having 2 different flags for opengl and opengles in DISTRO_FEATURES
does make sense...  but i could be wrong..

what do you think?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

On Mon, Sep 9, 2013 at 3:17 PM, Burton, Ross ross.bur...@intel.com wrote:

  how about gl vs gles?

 The problem of any patch that touches the opengl distro feature is
 that it causes this discussion, because the semantics of it are rather
 vague to say the least!

  i have been trying to understand over the last couple of days whether or
 not
  'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's
  clearly indicated anywhere.

 My personal opinion is it means enable support for the OpenGL
 collection of APIs, include OpenGL, GLES and/or EGL.  Last year there
 was a patch series from the early Wayland enabling that added machine
 features for each form of GL, but that wasn't finished or merged (not
 entirely required).

  in libsdl recipe, we have this:
 
  DEPENDS = ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb',
 '',
  d)} \
 ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
  '', d)} \
 
  and in EXTRA_OECONF we add this:
  ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
  '--disable-video-opengl', d)} \
 
  which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES.
 I
  am building for ARM platforms with GLes support, but no GL support. I
  initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being
  pulled in because of libsdl, which was wrong. So we now removed 'opengl'
  from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for
  GPU, so we don't want mesa at all).

 OpenGL-wrangling aside, that's a pretty good example of where
 PACKAGECONFIG should be used so your configuration can easily tweak
 SDL without changing distro features.


well, if opengl means gl or gles, then doing something like this should be
considered wrong (bug):

 ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
 '--disable-video-opengl', d)} \

since here it's clear that opengl means gl, not gles. it clearly breaks on
machine where opengl means gles and no gl support is available (here i am
considering pulling mesa as a bug, since we probably don't want it on
embedded devices).



  In weston recipe, we have this:
  ${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}
 
  so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES,
 but
  it's only used once (looking at oe-core and meta-oe).

 Not sure what I was thinking there, potentially a bad search and
 replace.  As you say its the only instance of that feature.  Patch
 incoming to fix that.

 I'm happy for DISTRO_FEATURES to be vague and just mean the GL
 collection instead of specific implementations, because OpenGL/GLX vs
 GLESv2/EGL etc is a machine-specific feature and encoding that into
 DISTRO_FEATURES would mean changing the distro features when the
 machine changes, which is obviously wrong.


well, i am not quite convinced that GL/GLX vs GLes/EGL really is machine
specific. It might have been the case before, but more and more i think
this is becoming a 'distro' (or stack, or product?) preference. things like
Qt5 or wayland now enforce the need for gles, so to me this is no longer
machine dependent. Without GLES on your machine you can't run them anymore.



  We may need some
 machine-level hints as to the GL feature set available for recipes
 that don't probe at runtime.


yes, i agree. we need to know what machines can do GL, GLX, EGL, GLES, and
what distro 'need/expect' and combine the 2 sets (and use mesa as fallback
when needed, or even we should be able to prohibit mesa too). we could get
such thing using opengl and opengles flags in DISTRO_ and
MACHINES_FEATURES.. but it's not quite nice.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] OE gcc-cross with builtin sysroot, BUG?

[Nicolas Dechesne]

hi there,

first of all, we are building dylan branch with oe-core +
meta-linaro-toolchain, not using external toolchain, hence the cross post
on OE and linaro lists.

we've been debugging some nasty build issues over the last few days on our
Jenkins server. and i'd like to bring our findings up to the list... i
suspect there could be a bug in OE gcc-cross, but i'd like to hear from you
about that.

our bug appeared because we were 'wrongly' unsetting the CFLAGS from OE in
one of our recipe, so we would loose the following from our compilation
command line

-march=armv7-a
-marm
-mthumb-interwork
-mfloat-abi=hard
-mfpu=neon
--sysroot=/work/rdk/build-genericarmv7a/tmp/sysroots/genericarmv7a

The compilation error was that stdlib.h was not found.

as a matter of fact, we build for several different machines (.conf file),
*but* we share the same sstate and downloads for all machines. We don't do
parallel builds, each machine is built sequentially in its own build folder
(.../workspace/machines/MACHINE/build), and all build folder are deleted
before each build (of course sstate and downloads aren't deleted).

What we noticed is that we end up pulling the compiler (gcc-cross) from
sstate as expected. However we pull the same 'blob' from sstate for
gcc-cross for *all* machines we build. It does seem that the compiler does
not use $MACHINE for the sstate checksum.

When the gcc-cross package was built and pushed in sstate, it was being
built for a specific machine (let's say MACHINE-A), hence the compiler has
the 'builtin' sysroot set to 'tmp/sysroots/MACHINE-A'.

Now when building our image for MACHINE-B, we pull gcc-cross from sstate,
and we get the default builtin sysroot for MACHINE-A!! That's why our build
failed, because we tried to build MACHINE-B before MACHINE-A, so stdlib.h
wasn't there yet on Jenkins..

To me the problem is that gcc-cross 'embedds' some $MACHINE data in its
package, but it is not marked as 'machine specific, but arch specific.  So
several machines will end up sharing the same gcc-cross package.

So, of course we shouldn't ignore the CFLAGS from OE, and the CFLAGS would
set the right sysroot, and of course we fixed our software so that we don't
ignore CFLAGS anymore... but that still looks like a bug to me.


cheers

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

Re: [OE-core] OE gcc-cross with builtin sysroot, BUG?

[Nicolas Dechesne]

On Wed, Sep 11, 2013 at 2:00 PM, Richard Purdie 
richard.pur...@linuxfoundation.org wrote:

  So, of course we shouldn't ignore the CFLAGS from OE, and the CFLAGS
  would set the right sysroot, and of course we fixed our software so
  that we don't ignore CFLAGS anymore... but that still looks like a bug
  to me.
 
 Not really, its actually intentionally designed like this since its
 pointless rebuilding gcc-cross multiple time just because we want to use
 it with a different sysroot. We therefore just pass in the arguments to
 the compiler to ensure it uses the right one. If you remove them, you
 hit the problems you describe.

 We should probably compile in a bogus sysroot so it never works and
 makes this kind of issue more visible.


hmm. ok. i see. it would certainly help to have a better 'error' message...
i suppose that not having a builtin sysroot at all, would be an even bigger
problem as it would default to /usr/include...
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

hi,

On Mon, Sep 9, 2013 at 2:40 PM, Nicolas Dechesne
nicolas.deche...@linaro.org wrote:
 On Mon, Sep 9, 2013 at 2:12 PM, Burton, Ross ross.bur...@intel.com wrote:

 On 9 September 2013 13:08, Martin Jansa martin.ja...@gmail.com wrote:
  +REQUIRED_DISTRO_FEATURES = opengl
 
  Is this really needed? I was building mesa in distro without opengl for
  long time and was considering (probably incorrectly) opengl
  DISTRO_FEATURE more
  like sign of proper hw GL libraries.

 I'd always understood the opengl DISTRO_FEATURE to mean give me GL
 support.  *What* that means depends on the target hardware, could be
 entirely software rendering through Mesa or binary HW drivers.


 how about gl vs gles?

 i have been trying to understand over the last couple of days whether or not
 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's
 clearly indicated anywhere.

 in libsdl recipe, we have this:

 DEPENDS = ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
 d)} \
${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
 '', d)} \

 and in EXTRA_OECONF we add this:
 ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
 '--disable-video-opengl', d)} \

back on this topic... something is weird. as i said above, we built
our OE based distro for ARM platform with *no* GL support, but with
GLES support. As soon as we pull libav in our images it DEPENS on
virtual/libsdl, and as mentioned above libdsl with 'opengl' in
DISTRO_FEATURES will end up with adding dependency on virtual/libgl
which we don't want (and don't have on our platform).

how do we get around this problem?

i am still not convinced that we should treat GL and GLES with a
single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
understand we need a mechanism to say if the platforms has 'graphics'
support, and for some recipes 'graphics' is enough, but especially for
libsdl this isn't enough since on GLES platforms we don't want
--enable-video-opengl to be enabled since that is a GL feature, not
GLES.

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

Re: [OE-core] [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

On Wed, Oct 23, 2013 at 11:00 AM, Burton, Ross ross.bur...@intel.com wrote:
 On 23 October 2013 09:53, Nicolas Dechesne nicolas.deche...@linaro.org 
 wrote:
 i am still not convinced that we should treat GL and GLES with a
 single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
 understand we need a mechanism to say if the platforms has 'graphics'
 support, and for some recipes 'graphics' is enough, but especially for
 libsdl this isn't enough since on GLES platforms we don't want
 --enable-video-opengl to be enabled since that is a GL feature, not
 GLES.

 I don't think anyone thinks that the current opengl feature is
 sufficient but there hasn't been a good enough alternative just yet.
 Are you proposing that the opengl distro feature is re-purposed as
 OpenGL, and we add opengles for OpenGLES.  Does this need to be
 GLES-version-specific, what about EGL, and what about machines which
 can support multiple drivers/GPU hardware?

well, that's more or less what I had said in that thread earlier. e.g.
make opengl vs opengles 2 distinct DISTRO_FEATURE. at least what's
sure now, is that currently it is broken, libsdl is the only instance
we have noticed the problem, there could be more, not sure.

i agree that we could easily extend the number of combos... but we
could start 'small' and add new 'feature' whenever needed. the problem
is probably even more subtle... right now opengl is a DISTRO_FEATURE
to say globally if the 'distro/stack' we build has some sort of
graphics.. if we start getting into EGL, GLX, and GL/GLES versions
then we start going into machine features.

a quick grep (in the layers i use) reveals that the situation isn't
really too good ;-)

-- 
meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:PACKAGECONFIG
??= ${@base_contains('DISTRO_FEATURES', 'opengl', 'opengl',
'openglesv2', d)}
-- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:
   ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-gl',
'--enable-gles', d)} \

here, we use opengl distro feature to switch between GL and GLES

-- meta-qt5/recipes-qt/qt5/qtbase.inc:PACKAGECONFIG_GL ?=
${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)}

here, opengl is used to enable GL , nothing about GLES. in our layer,
we have added a .bbapend with this to get Qt to work:

# By default, qtbase.inc PACKAGECONFIG_GL is either gl (if DISTRO_FEATURES
# includes opengl) or empty (if it doesn't). Over-ride and force to gles2.
PACKAGECONFIG_GL = gles2

-- openembedded-core/meta/conf/machine/include/ia32-base.inc:
 ${@base_contains('DISTRO_FEATURES', 'opengl',
'xserver-xorg-extension-glx', '', d)} \

here, used to enable GLX

-- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
   ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} \
-- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-video-opengl', '--disable-video-opengl', d)} \

here to enable GL features, incompatible with GLES.

-- openembedded-core/meta/recipes-graphics/wayland/weston_1.1.0.bb:
   ${@base_contains('DISTRO_FEATURES', 'opengles2',
'gles', '', d)} \

here, we have an instance of opengles2, which we discussed already.
that's the only place where we have that, and you agreed it was a bug.

-- 
openembedded-core/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb:PACKAGECONFIG
??= sna udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri', '',
d)}
-- 
openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc:PACKAGECONFIG
??= udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri dri2
glx', '', d)}

to enable GLX/DRI

-- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:DEPENDS
+=  ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)}

another instance, like libsdl which would break on GLES only platform.

-- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:
   ${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-webgl', '--disable-webgl', d)} \

here to enable WebGL

So i think given these examples, it's difficult to 'define' what
opengl DISTRO_FEATURE means. it is used for many different things, so
maybe this isn't the 'right level of abstraction'. what do you think?


ps: sorry, i have the feeling that gmail is going to mess up very
badly with the formatting of this email...
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] Fix grep pattern when mklibs collects executables in rootfs

[Nicolas Dechesne]

hi,

On Wed, Nov 13, 2013 at 4:05 AM, Lei Liu lay...@gmail.com wrote:

 On 2013年11月12日 18:23, Richard Purdie wrote:
  On Mon, 2013-11-11 at 17:27 +0800, Lei Liu wrote:
  From: Lei Liu lei.l...@windriver.com
 
  File command in some version could print extra space between
  LSB and executable - it causes mklibs can't find any executables
  using grep LSB executable.  Fix the grep pattern to catch
  multiple spaces.
 
  Signed-off-by: Lei Liu lei.l...@windriver.com
  ---
   meta/classes/image-mklibs.bbclass |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  I've queued this but please put the area name in the short line of the
  commit in future (image-mklibs:  in this case).
 

 Okay.  Thanks.


First of all, this patch is needed on dora branch too , and it applies
cleanly, can that be merged?

Now, the real question... i am not able to get mklibs to work at all (even
with this patch). What i am seeing is that mklibs 0.1.38 doesn't support
anymore the use of 'sysroot'. I think this is because of this upstream
change

http://anonscm.debian.org/gitweb/?p=d-i/mklibs.git;a=commit;h=60bda7e2132d197e1c88afb5012f9677b6967db2

If I revert to 0.1.34 (that we had on dylan branch), i can build my image
just fine (note that I am building an arm soft-float image), so are you
able to use image-mklibs with dora or master which have 0.1.38?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH dylan dora master] image-mklibs: ensure sysroot is correctly set when calling gcc

[Nicolas Dechesne]

[YOCTO #2519]

When getting gcc from sstate, it is possible to get a gcc with a bogus
sysroot configuration, as discussed in [1] or in [YOCTO #2519].

mklibs script will eventually call gcc, so we need to make sure that it
provides gcc with the right sysroot location.

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2013-September/084159.html

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/classes/image-mklibs.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/image-mklibs.bbclass 
b/meta/classes/image-mklibs.bbclass
index 66b0f52..beef1b4 100644
--- a/meta/classes/image-mklibs.bbclass
+++ b/meta/classes/image-mklibs.bbclass
@@ -40,6 +40,7 @@ mklibs_optimize_image_doit() {
--ldlib ${dynamic_loader} \
--libdir ${baselib} \
--sysroot ${PKG_CONFIG_SYSROOT_DIR} \
+   --gcc-options --sysroot=${PKG_CONFIG_SYSROOT_DIR} \
--root ${IMAGE_ROOTFS} \
--target `echo ${TARGET_PREFIX} | sed 's/-$//' ` \
-d ${WORKDIR}/mklibs/dest \
-- 
1.8.4.2

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

Re: [OE-core] Improving Build Speed

[Nicolas Dechesne]

On Thu, Nov 21, 2013 at 8:15 AM, Ulf Samuelsson u...@emagii.com wrote:

 I currently do not use INHERIT += rm_work
 since I want to be able to do changes on some packages.
 Is there a way to defined rm_work on a package basis?
 Then the majority of the packages can be removed.


from rm_work.bbclass:

# To inhibit rm_work for some recipes, specify them in RM_WORK_EXCLUDE.

  # For example, in conf/local.conf:


#


# RM_WORK_EXCLUDE += icu-native icu busybox
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Automated testing on real hardware

[Nicolas Dechesne]

Paul,


On Fri, Nov 29, 2013 at 4:58 PM, Paul Eggleton 
paul.eggle...@linux.intel.com wrote:

 LAVA
 -

 A number of people had suggested I look at LAVA [1]. It is split into
 different
 components for each function, some of which should be usable independently
 so
 you don't have to use the entire framework. Many of the components could be
 useful assuming they are independent, but in terms of being able to
 actually
 run our tests, the one that stands out as being most relevant is lava-
 dispatcher. This is the component that deploys images, and boots the
 hardware
 in order to run the tests.

 I've looked at lava-dispatcher a couple of times; firstly at the code, and
 yesterday I looked at actually running it. Initially it looked very
 promising
 - reasonably licensed, written in Python, has some rudimentary support for
 OE
 images. However while looking at it I found the following:

 * It requires root to run, since it mounts the images temporarily and
 modifies
 the contents. We've done quite a lot to avoid having to run as root in OE,
 so
 this is a hard sell.


i have forwarded this email to the relevant people in Linaro working on
LAVA. I hope to be able to bring more information about that, as I am not
involved with LAVA, just a 'user' of it. By 'root' here, you mean on the
server side, e.g. the LAVA instance, which will typically not be the
'builder', or do you want to couple build and test on the same 'server'?
LAVA jobs are generally submitted by a CI instance (Jenkins in our case).


 * It expects images to be created by linaro-media-create, which in turn
 requires an hwpack [2]. The hwpack concept seems primarily geared to
 Ubuntu
 and distributions like it where you'd have a generic base image upon which
 you'd install some board-specific packages in order to make it work on the
 board. OE doesn't work that way - we just build images specific to the
 board,
 which makes this mechanism completely superfluous for our usage; but the
 tool
 appears to require it.


that is no longer the case. we do have support for 'native' OE images, and
we've had that for a while. That is what I am using for my project at
Linaro. None of our projects/jobs deliverable are 'public' at the moment,
so you won't find them, but i can confirm that what we deploy for our jobs
is the output of OE (e.g. what is in the deploy/image folder). hwpack was
something mostly meant to make it simpler to work with Ubuntu and Android
root FS, and is not suited for OE.



 * There is a general lack of abstraction and far too much hardcoding. For
 example, even at the most abstract level, the Target class (which is the
 base class for defining what to do for different types of targets) has
 hardcoded
 deploy_linaro / deploy_android functions:


 https://git.linaro.org/gitweb?p=lava/lava-dispatcher.git;a=blob;f=lava_dispatcher/device/target.py

 * It's not clear to me how well it will work across different host
 distributions that we want to support; the main LAVA installer quits if it
 isn't run on Ubuntu. For convenience I happened to be using an Ubuntu VM,
 and
 I wasn't running the full installer so I avoided this check altogether. It
 just concerns me that such a check would even be there.


I agree that this is a problem and we should fix. Our IT infrastructure is
largely based on Ubuntu servers, but that should not affect what we create
that much.



 Of course, none of these problems are impossible to overcome, if we're
 prepared to put a significant amount of engineering into resolving them. In
 terms of enabling the Yocto Project QA team to test images on real
 hardware in
 the 1.6 development cycle however, I don't believe this is going to be
 deliverable.

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

[OE-core] unable to use bitbake -c populate_sdk core-image-minimal on dora

[Nicolas Dechesne]

hi,

i am unable to build a proper SDK for core-image-minimal using OE-core +
dora. I am seeing I think 2 different problems.

1- problem related to update-alternative and opkg:

update-alternatives: Error: cannot register alternative opkg to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/opkg since it
is already registered to /usr/bin/opkg


2- problem related to shadow(-native/-nativesdk)

Configuring
nativesdk-perl-module-pod-plaintex/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//var/lib/opkg/info/nativesdk-shadow.posti\
nst: line 7: pwconv: command not found
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//var/lib/opkg/info/nativesdk-shadow.postinst:
line 8: grpconv: command not found
update-alternatives: Error: cannot register alternative passwd to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/passwd since
it is already registered to /usr/bin/passwd
update-alternatives: Linking
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-oe-linux\
-gnueabi//usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/chfn
to /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/chfn.shadow
update-alternatives: Linking
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-oe-linux\
-gnueabi//usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/newgrp
to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/newgrp.shadow
update-alternatives: Linking
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-oe-linux\
-gnueabi//usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/chsh
to /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/chsh.shadow
update-alternatives: Error: cannot register alternative groups to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/groups since
it is already registered to /usr/bin/groups
update-alternatives: Linking
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-oe-linux\
-gnueabi//usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/sbin/chpasswd
to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/sbin/chpasswd.shadow
update-alternatives: Error: cannot register alternative login to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/bin/login since it is
already registered to /bin/login
update-alternatives: Linking
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-oe-linux\
-gnueabi//usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/sbin/vipw to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/sbin/vipw.shadow
update-alternatives: Linking
/work/test/oe-test/build-bbb/tmp-eglibc/work/beaglebone-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image//usr/local/oecore-x86_64/sysroots/armv7a-vfp-neon-oe-linux\
-gnueabi//usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/sbin/vigr to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/sbin/vigr.shadow
update-alternatives: Error: cannot register alternative su to
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/bin/su since it is
already registered to /bin/su

If i revert the following commits (on dora), then at least #2 seems to be
going away... but i am not completely sure if this is right or wrong...

829edcb nativesdk-packagegroup-sdk-host: Add nativesdk-shadow
f90e1a4 shadow: Add nativesdk to BBCLASSEXTEND
44fafdb shadow: Turn shadow-native into a BBCLASSEXTEND

I would expect that SDK is being tested properly, so i must be doing
something wrong along the lines... any help would be much appreciated.

thanks

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

Re: [OE-core] git fetcher sanity check for matching branch and SRCREV

[Nicolas Dechesne]

On Wed, Dec 11, 2013 at 11:51 PM, Martin Jansa martin.ja...@gmail.comwrote:

 Unfortunately we cannot disable this check by explicitly setting empty
 branch or setting tag=1.0.12

 I can ask yajl owner to push that one missing patch to 1.x branch, but
 there were no changes in last 11 months so I don't know how responsive
 he will be and there could be similar case in different recipes where
 the upstream could be completely gone.

 As side note, should bitbake do the same check when tag=foo is
 specified?


well, my 2 cents.. I think that keeping tags without a branch is a 'valid'
feature in git, whether we like it or not, and we won't be able to make
sure no upstream do that... so we probably need to support use of a tag in
SRC_URI as well, not just branches.

cheers

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

Re: [OE-core] [PATCH] libsoup-2.4: add intltool-native to DEPENDS

[Nicolas Dechesne]

On Thu, Dec 19, 2013 at 11:47 AM, Javier Viguera javier.vigu...@digi.comwrote:

 On 17/12/13 11:42, Paul Eggleton wrote:

 -DEPENDS = glib-2.0 gnutls libxml2 libproxy sqlite3
 +DEPENDS = glib-2.0 gnutls libxml2 libproxy sqlite3 intltool-native


 +1 for this change.

 I was bitten by this bug using a DISTRO with no X11 support (removed X11
 from DISTRO_FEATURES). In that case the 'intltool-native' dependence is not
 fulfilled and libsoup fails to build.

 Could it be *backported* to Dora/Dylan?


it will. Paul said on IRC the other day, that it should reach dylan by the
end of this week .
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Piglit in Poky

[Nicolas Dechesne]

On Wed, Jan 8, 2014 at 6:01 PM, Richard Purdie 
richard.pur...@linuxfoundation.org wrote:

 
  On 24 December 2013 01:09, Philip Balister phi...@balister.org wrote:
   1) Move piglit and deps to oe-core.  Piglit is for QA purposes only
   and pushes the boundaries of core platform.  In a sense this is a
   repeat of the discussion we had with Midori...  does oe-core contain
   everything needed to sufficiently exercise the core components it
   ships or not?
  
   I expect Richard will push back on this, and I would support him here.
 
  Probably best to let Richard speak for himself here. :)

 :)

 I have to admit I'm leaning towards pulling in the 4 recipes we need
 since the win is we get to test the GL stacks.

 We do support graphics in the core, we also do particularly badly at
 testing it. That is something I think we need to change. piglit lets us
 do that and its not like it has a significant number of dependencies.
 Having a couple more python modules to test the python stack probably
 isn't a bad idea ether. We pruned quite a number of recipes out, this is
 a case where we can add a small number for a significant win.


I am in favor of that too. I would like to use piglit too to test GLES on
some of our ARM projects. I am not sure when we can get to do it, but i am
definitely interested into that, and it's been on a TODO list for some time
now.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] libsdl and opengl DISTRO_FEATURE

[Nicolas Dechesne]

hi there,

it has been brought to the list already, at least in [1], but libsdl recipe
implicitely assumes that 'opengl' distro feature means GL/GLX support.

the recipe does this:

${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
'--disable-video-opengl', d)} \


and the configure checks for GL/gl.h, GL/glx.h and GL/glu.h.

this is quite an issue on ARM platforms with no such support. Based on
previous discussions i understand that nobody should assume that 'opengl'
in distro feature means GL or GLES, so I am tempted to conclude that this
is a bug in the SDL recipe. is that correct?

if we make it a PACKAGECONFIG instead, would that be considered the right
fix for this bug?

thanks



[1] http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/42830
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 12/12] xf86-video-omap: add new recipe to follow the maintained repo

[Nicolas Dechesne]

On Thu, Nov 22, 2012 at 9:59 AM, Laurentiu Palcu
laurentiu.pa...@intel.com wrote:

 The autobuilder nightly for arm (for example) does, among other things,
 the following:
 * Builds core-image-sato, core-image-sato-dev, core-image-sato-sdk,
 core-image-minimal, core-image-minimal-dev for qemuarm
 * Builds core-image-sato, core-image-sato-sdk, core-image-minimal for
 beagleboard
 * Builds the meta-toolchain-gmae

 Here's a link to one of the latest arm nightly builds. You can see that,
 for beagleboard, it includes xf86-video-omap driver:

 http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727

 This is the production autobuilder. The autobuilder server I used to
 test the patches is internal and cannot be accessed from outside.


and we can see that the build failed with

| checking for ANSI C header files... (cached) yes
| checking whether to include DRI support... checking for
/usr/include/xorg/dri.h... configure: error: cannot check for file
existence when cross compiling
| Configure failed. The contents of all config.log files follows to
aid debugging
| 
/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-arm/build/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xf86-video-omap/2_0.4.2+gitr1+ae0394e687f1a77e966cf72f895da91840dffb8f-r20.0/git/config.log
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
|
| It was created by xf86-video-omap configure 0.4.2, which was
| generated by GNU Autoconf 2.69.  Invocation command line was

from 
http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/727/steps/shell_55/logs/stdio

I am looking at Ross patch, as our configure.ac file is clearly wrong
here in xf86-video-omap (in fact most of the testing for this X11
driver was done in ubuntu, so using native compilation...). will make
sure to get that fixed upstream asap.

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

Re: [OE-core] [PATCH v3 12/12] xf86-video-omap: add new recipe to follow the maintained repo

[Nicolas Dechesne]

On Thu, Nov 22, 2012 at 3:09 PM, Martin Jansa martin.ja...@gmail.com wrote:
 As said in other thread I did that already for xf86-video-glamo in
 meta-oe, so I agree that it's not *that* difficult.

 But I'm not sending xf86-video-glamo change before it's tested not only
 to build, but also to work in runtime.

 And I cannot work on xf86-video-omapfb now, because builder is still
 rebuilding armv7a after last layout changes.

xf86-video-omap was largely developped and tested on OMAP4 and OMAP5
(Panda). it was tested at some point on OMAP3 (beagle), but not
intensively.

when i introduced it in our meta-ti layer, we took care of using it
for Panda only, see:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=410dc026f2ee24a2346e7563a83f0181c79809cf
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=95e12712ddffcc7ec0789a8700137afe2e449445

what I would suggest given the current situation is to fallback to
fbdev until either someone properly tests this new driver on OMAP3, or
someone ports omapfb on new X11. I would not recommend to remove
xf86-video-omap as we are using it for Panda.

Also note that as mentioned here, video-omap needs omapdrm driver
(from staging) as well as CMA support. these bits need to make it in
the kernel before video-omap can be safely used on OMAP3.

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

Re: [OE-core] [PATCH 0/4] Fixes for xserver and omap* drivers

[Nicolas Dechesne]

hi,

On Fri, Nov 23, 2012 at 1:47 AM, Martin Jansa martin.ja...@gmail.com wrote:
 Martin Jansa (4):
   xf86-video-omap: add xf86driproto dependency, drop --enable-neon and
 improve DESCRIPTION
   xserver-xorg: disable dri2 too when building without glx
 PACKAGECONFIG
   xf86-video-omapfb: revive driver which actually works and is tested
 on real devices
   xf86-video-omap: drop RPROVIDES/RREPLACES/RCONFLICTS

so, I have tested this serie on pandaboard, using meta-ti layer for
the BSP and poky (i used master-next branch which has these patches).
I have tested with a couple of patches that I sent to meta-ti to
revert the xf86-video-omap that we had in meta-ti. For the reference,
i tested with this:
https://github.com/ndechesne/meta-ti/commits/test_new_xf-v-o (my new
patches aren't merged yet in master).

i tested with xf86-video-omap, not -omapfb, and with a v3.4 kernel
which I know has a working omapdrm driver.

it all looks good, the driver is loaded, and I tested resolution
change, as well as rotation , both with xrandr command (i tested
core-image-x11 image).

many thanks for sorting this out...

i have some questions... xf86-video-omap now clearly depends on opengl
DISTRO_FEATURE (since dri cannot be disabled) for the xserver build.
So if i build oe-core + meta-ti, it won't build as the xserver is
built without dri/glx support there, and then xf86-video-omap won't
build.
 - how should we handle that? it doesn't sound quite right to enfore a
DISTRO feature in a recipe... but is it possible to have a check for
opengl in the recipe? that would avoid a more cryptic build error..
 - how can I make an oe-core+meta-ti to build for Panda with this
video driver? e.g. where should I set this DISTRO_FEATURE in meta-ti,
outside of 'poky' distro, e.g. in a BSP layer?. I recall that we have
this in the xserver recipe:

PACKAGECONFIG ??= udev ${@base_contains('DISTRO_FEATURES', 'opengl',
'glx', '', d)}
PACKAGECONFIG[udev] = --enable-config-udev,--disable-config-udev,udev
PACKAGECONFIG[glx] = --enable-dri --enable-dri2 --enable-glx --enable-glx-tls,\
  --disable-dri --disable-dri2 --disable-glx,\
  xf86driproto dri2proto mesa-dri

thx

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

[OE-core] Perl 'native' path

[Nicolas Dechesne]

hi,

i am getting the following build error:

ERROR: Function failed: do_rootfs (see
/data/ubuntu-omap/jenkins/jobs/yocto-meta-ti-danny/workspace/mybuild/tmp/work/pandaboard-poky-linux-gnueabi/core-image-x11-1.0-r0/temp/log.do_rootfs.28213
for further information)
ERROR: Logfile of failure stored in:
/data/ubuntu-omap/jenkins/jobs/yocto-meta-ti-danny/workspace/mybuild/tmp/work/pandaboard-poky-linux-gnueabi/core-image-x11-1.0-r0/temp/log.do_rootfs.28213
Log data follows:
| DEBUG: Executing shell function do_rootfs
| Can't locate Dpkg.pm in @INC (@INC contains:
/apps/perl/5.8.3/lib/5.8.3/x86_64-linux-thread-multi
/apps/perl/5.8.3/lib/5.8.3
/apps/perl/5.8.3/lib/site_perl/5.8.3/x86_64-linux-thread-multi
/apps/perl/5.8.3/lib/site_perl/5.8.3 /apps/perl/5.8.3/lib/site_perl .)
at 
/data/ubuntu-omap/jenkins/jobs/yocto-meta-ti-danny/workspace/mybuild/tmp/sysroots/x86_64-linux/usr/bin/dpkg-scanpackages
line 27.

i am trying to setup some daily builds on some corporate administrated
machines... and what happens is that dpkg-scanpackage perl script has
this:

$ more sysroots/x86_64-linux/usr/bin/dpkg-scanpackages
#!/usr/local/bin/perl

So in turns my build will attempt to use whatever I have in
/usr/local/bin (AFAIU), which is problematic in my case as this points
to a corporate version (/apps/perl), which then leads to build
failure.

I would expect all scripts to use the perl-native binary, instead, and
search for Perl modules in the sysroot folder.

does that make any sense? is there something wrong with what I am
doing (beyond using a corporate server which I can't administrate ;-)

thx

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

[OE-core] [PATCH 0/2] Fix SDL recipes with regards to GL/GLES/EGL

[Nicolas Dechesne]

As discussed on the list, SDL fails to build on ARM platforms where
'opengl' DISTRO FEATURES means gles/egl, since SDL assumes that
'opengl' provides gl/glx. So until we find a better mechanism to
support GL vs GLES at the DISTRO FEATURE level, this serie create the
proper PACKAGECONFIG so that SDL enable-video-opengl can be disabled
more easily in .bbappend or .conf file.

If this gets merged, I will send a backport for dora, and a slightly
different backport for dylan which does not have the _remove feature,
hence i will be using an intermediate variable like PACKACONFIG_GL.

Nicolas Dechesne (2):
  libsdl: add PACKAGECONFIG for opengl
  libsdl2: add PACKAGECONFIG for opengl

 meta/recipes-graphics/libsdl/libsdl_1.2.15.bb  | 12 +---
 meta/recipes-graphics/libsdl2/libsdl2_2.0.1.bb | 12 +---
 2 files changed, 18 insertions(+), 6 deletions(-)

-- 
1.8.5.3

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

[OE-core] [PATCH 2/2] libsdl2: add PACKAGECONFIG for opengl

[Nicolas Dechesne]

As discussed in [1], SDL recipe makes the wrong assumption that
'opengl' in DISTRO_FEATURES implies GL/GLX. However 'opengl' could
also mean GLES/EGL, and the recipe fails to build in such
situations. So we add a PACKAGECONFIG option for opengl so that the
build can be made to work on gles/egl with a simple .bbappend.

The default PACKAGECONFIG is set to the same value as previously,
e.g. 'gl' is enabled if 'opengl' is found in DISTRO_FEATURES.

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088735.html

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/libsdl2/libsdl2_2.0.1.bb | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.1.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.1.bb
index 7958f7b..57d1bd1 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.1.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.1.bb
@@ -13,7 +13,6 @@ LIC_FILES_CHKSUM = 
file://COPYING.txt;md5=0605ca7e995ab1217e0bb988731a87fe
 PROVIDES = virtual/libsdl2
 
 DEPENDS = ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} 
\
-   ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', 
d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxext 
libxrandr libxrender', '', d)} \
tslib
 DEPENDS_class-nativesdk = ${@base_contains('DISTRO_FEATURES', 'x11', 
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender 
nativesdk-libxext', '', d)}
@@ -33,14 +32,21 @@ EXTRA_OECONF = --disable-oss --disable-esd --disable-arts \
 --disable-video-dummy \
 --enable-input-tslib --enable-pthreads \
 ${@base_contains('DISTRO_FEATURES', 'directfb', 
'--enable-video-directfb', '--disable-video-directfb', d)} \
-${@base_contains('DISTRO_FEATURES', 'opengl', 
'--enable-video-opengl', '--disable-video-opengl', d)} \
 ${@base_contains('DISTRO_FEATURES', 'x11', 
'--enable-video-x11', '--disable-video-x11', d)} \
 --enable-sdl-dlopen \
 --disable-rpath \
 --disable-pulseaudio
 
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}
+PACKAGECONFIG ??=  \
+${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \
+${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)} \
+
+
 PACKAGECONFIG[alsa] = --enable-alsa 
--disable-alsatest,--disable-alsa,alsa-lib,
+# SDL wrongly assumes that opengl means GL/GLX, when using GLES/EGL, do:
+# PACKAGECONFIG_remove = gl in .bbappend
+# or PACKAGECONFIG_remove_pn-libdsl2 = gl in .conf
+PACKAGECONFIG[gl] = 
--enable-video-opengl,--disable-video-opengl,virtual/libgl
 
 PARALLEL_MAKE = 
 
-- 
1.8.5.3

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

[OE-core] [PATCH 1/2] libsdl: add PACKAGECONFIG for opengl

[Nicolas Dechesne]

As discussed in [1], SDL recipe makes the wrong assumption that
'opengl' in DISTRO_FEATURES implies GL/GLX. However 'opengl' could
also mean GLES/EGL, and the recipe fails to build in such
situations. So we add a PACKAGECONFIG option for opengl so that the
build can be made to work on gles/egl with a simple .bbappend.

The default PACKAGECONFIG is set to the same value as previously,
e.g. 'gl' is enabled if 'opengl' is found in DISTRO_FEATURES.

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088735.html

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb 
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index 4b4ff63..492e228 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -13,7 +13,6 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4
 PROVIDES = virtual/libsdl
 
 DEPENDS = ${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} 
\
-   ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', 
d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxext 
libxrandr libxrender', '', d)} \
tslib
 DEPENDS_class-nativesdk = ${@base_contains('DISTRO_FEATURES', 'x11', 
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender 
nativesdk-libxext', '', d)}
@@ -40,15 +39,22 @@ EXTRA_OECONF = --disable-static --enable-cdrom 
--enable-threads --enable-timers
 --disable-xbios --disable-gem --disable-video-dummy \
 --enable-input-events --enable-input-tslib --enable-pthreads \
 ${@base_contains('DISTRO_FEATURES', 'directfb', 
'--enable-video-directfb', '--disable-video-directfb', d)} \
-${@base_contains('DISTRO_FEATURES', 'opengl', 
'--enable-video-opengl', '--disable-video-opengl', d)} \
 ${@base_contains('DISTRO_FEATURES', 'x11', 
'--enable-video-x11', '--disable-video-x11', d)} \
 --disable-video-svga \
 --disable-video-picogui --disable-video-qtopia 
--enable-sdl-dlopen \
 --disable-rpath \
 --disable-pulseaudio
 
-PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}
+PACKAGECONFIG ??=  \
+${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \
+${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)} \
+
+
 PACKAGECONFIG[alsa] = --enable-alsa 
--disable-alsatest,--disable-alsa,alsa-lib,
+# SDL wrongly assumes that opengl means GL/GLX, when using GLES/EGL, do:
+# PACKAGECONFIG_remove = gl in .bbappend
+# or PACKAGECONFIG_remove_pn-libdsl = gl in .conf
+PACKAGECONFIG[gl] = 
--enable-video-opengl,--disable-video-opengl,virtual/libgl
 
 PARALLEL_MAKE = 
 
-- 
1.8.5.3

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

Re: [OE-core] [PATCH 1/1] subversion: fix build problem when sysroot contains '-D' or '-I'

[Nicolas Dechesne]

Robert,

can we get the patch below merged into dora? I just tried it, it
applies cleanly as-is. the thing is i stumbled upon this issue on dora
this week, and debugged it for a while to later figure out it was
fixed in master ;-)

fwiw, you can add

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org

thanks

nicolas

On Sat, Nov 16, 2013 at 4:19 AM,  qi.c...@windriver.com wrote:
 From: Chen Qi qi.c...@windriver.com

 If sysroot contains '-D' or '-I' characters, the SVN_NEON_INCLUDES and
 the corresponding CFLAGS will not get the correct value.

 This will cause build failures.

 This patch fixes the above problem.

 [YOCTO #5458]

 Signed-off-by: Chen Qi qi.c...@windriver.com
 ---
  .../neon.m4-fix-includes-and-cflags.patch  |   32 
 
  .../subversion/subversion_1.7.10.bb|1 +
  2 files changed, 33 insertions(+)
  create mode 100644 
 meta/recipes-devtools/subversion/subversion-1.7.10/neon.m4-fix-includes-and-cflags.patch

 diff --git 
 a/meta/recipes-devtools/subversion/subversion-1.7.10/neon.m4-fix-includes-and-cflags.patch
  
 b/meta/recipes-devtools/subversion/subversion-1.7.10/neon.m4-fix-includes-and-cflags.patch
 new file mode 100644
 index 000..013d0c3
 --- /dev/null
 +++ 
 b/meta/recipes-devtools/subversion/subversion-1.7.10/neon.m4-fix-includes-and-cflags.patch
 @@ -0,0 +1,32 @@
 +Fix to get correct SVN_NEON_CONFIG and CFLAGS when sysroot path contains 
 '-D' and '-I'
 +characters.
 +
 +Upstream-Status: Pending
 +
 +Signed-off-by: Chen Qi qi.c...@windriver.com
 +
 +index f951039..a813145 100644
 +--- a/build/ac-macros/neon.m4
  b/build/ac-macros/neon.m4
 +@@ -105,8 +105,8 @@ AC_DEFUN(SVN_NEON_CONFIG,
 +test $svn_allowed_neon = any; then
 + svn_allowed_neon_on_system=yes
 + if test $NEON_PKG_CONFIG = yes; then
 +-  SVN_NEON_INCLUDES=[`$PKG_CONFIG neon --cflags | $SED -e 
 's/-D[^ ]*//g'`]
 +-  CFLAGS=[$CFLAGS `$PKG_CONFIG neon --cflags | $SED -e 's/-I[^ 
 ]*//g'`]
 ++  SVN_NEON_INCLUDES=[`$PKG_CONFIG neon --cflags | $SED -e 
 's/^-D[^ ]*//g' -e 's/ -D[^ ]*//g'`]
 ++  CFLAGS=[$CFLAGS `$PKG_CONFIG neon --cflags | $SED -e 
 's/^-I[^ ]*//g' -e 's/ -I[^ ]*//g'`]
 +   old_CFLAGS=$CFLAGS
 +   old_LIBS=$LIBS
 +   NEON_LIBS=`$PKG_CONFIG neon --libs`
 +@@ -126,8 +126,8 @@ int main()
 +   CFLAGS=$old_CFLAGS
 +   LIBS=$old_LIBS
 + else
 +-  SVN_NEON_INCLUDES=[`$neon_config --cflags | $SED -e 's/-D[^ 
 ]*//g'`]
 +-  CFLAGS=[$CFLAGS `$neon_config --cflags | $SED -e 's/-I[^ 
 ]*//g'`]
 ++  SVN_NEON_INCLUDES=[`$neon_config --cflags | $SED -e 's/^-D[^ 
 ]*//g' -e 's/ -D[^ ]*//g'`]
 ++  CFLAGS=[$CFLAGS `$neon_config --cflags | $SED -e 's/^-I[^ 
 ]*//g' -e 's/ -I[^ ]*//g'`]
 +   NEON_LIBS=`$neon_config --libs`
 + fi
 + svn_lib_neon=yes
 diff --git a/meta/recipes-devtools/subversion/subversion_1.7.10.bb 
 b/meta/recipes-devtools/subversion/subversion_1.7.10.bb
 index 4acd70b..489bddf 100644
 --- a/meta/recipes-devtools/subversion/subversion_1.7.10.bb
 +++ b/meta/recipes-devtools/subversion/subversion_1.7.10.bb
 @@ -13,6 +13,7 @@ SRC_URI = ${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
 file://libtool2.patch \
 file://fix-install-depends.patch \
 file://allow-updated-neon.patch \
 +   file://neon.m4-fix-includes-and-cflags.patch \
  
  SRC_URI[md5sum] = 4088a77e14232876c9b4ff1541e6e200
  SRC_URI[sha256sum] = 
 c1df222bec83d014d17785e2ceba6bc80962f64b280967de0285836d8d77a8e7
 --
 1.7.9.5

 ___
 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] iw in place of wireless-tools

[Nicolas Dechesne]

On Fri, Jan 31, 2014 at 8:01 PM, Iorga, Cristian
cristian.io...@intel.com wrote:
 On my Ubuntu 13.10 dev machine, wireless-tools and iw are both installed by
 default (I might be wrong here, maybe I installed them some time ago by
 hand).

you are right, they are both on the default install, see

http://releases.ubuntu.com/13.10/ubuntu-13.10-desktop-amd64.manifest
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Conf notes

[Nicolas Dechesne]

On Fri, Feb 21, 2014 at 8:06 PM, Laszlo Papp lp...@kde.org wrote:

 I have just put a conf notes file into my own layer, but when I source
 the oe-init-build-env script, I am still getting the notes from Yocto
 rather than my customized.

 What am I doing wrong? I see this in the ./scripts/oe-setup-builddir file:

 TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}

 and other references, but I have not pin the issue down just yet.

are you setting TEMPLATECONF variable? if so, how?

also, if you provide conf-notes.txt you need to provide
local.conf.sample and bblayers.conf.sample.

if TEMPLATECONF is set, it will use these files:

OECORELAYERCONF=$TEMPLATECONF/bblayers.conf.sample
OECORELOCALCONF=$TEMPLATECONF/local.conf.sample
OECORENOTESCONF=$TEMPLATECONF/conf-notes.txt
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Conf notes

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 10:35 AM, Laszlo Papp lp...@kde.org wrote:
 are you setting TEMPLATECONF variable? if so, how?

 cat setup.sh
 #!/bin/bash

 TEMPLATECONF=meta-foo/conf . oe-init-build-env

hmm. do you get any error message?

meta-foo needs to be a folder in OEROOT (along with 'meta' folder), or
TEMPLATECONF can be an absolute path otherwise, as you can see from
this code snippet (from oe-setup-builddir)

if ! (test -d $TEMPLATECONF); then
# Allow TEMPLATECONF=meta-xyz/conf as a shortcut
if [ -d $OEROOT/$TEMPLATECONF ]; then
TEMPLATECONF=$OEROOT/$TEMPLATECONF
fi
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Conf notes

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 12:47 PM, Laszlo Papp lp...@kde.org wrote:
 hmm. do you get any error message?

 Nope, I have been using this construction for several weeks now. The
 local and bblayer samples have been extracted properly into the build
 folder, so in that sense, there is no infrastructural change
 introduced in here, just yet another file added in the folder.

well, i don't see what can possibly go wrong then... especially if
layers.conf.sample and bblayer sample files work fine... maybe adding
set -x in the script would reveal something..

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

Re: [OE-core] Conf notes

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 2:15 PM, Gary Thomas g...@mlbassoc.com wrote:
 I just tried this with the latest master and it is only looking in
 the meta-yocto layer even though there is a conf-notes.txt in one of
 my local layers as well.

hmm. i just tried too. i create meta-layer with:

$ find meta-mylayer/
meta-mylayer/
meta-mylayer/conf
meta-mylayer/conf/conf-notes.txt
meta-mylayer/conf/bblayers.conf.sample
meta-mylayer/conf/layer.conf
meta-mylayer/conf/local.conf.sample
meta-mylayer/conf/site.conf.sample

then, if I run

$ TEMPLATECONF=meta-mylayer/conf . oe-init-build-env bbb

It is working fine:

### Shell environment set up for builds. ###

You can now run 'bitbake target'

Common targets are:
   my-custom-image

You can also run generated qemu images with a command like 'runqemu qemux86'

I tried with up-to-date poky, e.g.

commit a1faa7df2a0972fa631d3aee98c59f6b0e8eb43c
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date:   Mon Feb 24 12:57:38 2014 +
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Conf notes

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 3:09 PM, Laszlo Papp lp...@kde.org wrote:
 It works with dylan, too?

yep. same output using:

commit e2bb4a70a99a057d45316bbac65d6044ea54c484
Author: Chen Qi qi.c...@windriver.com
Date:   Sat Nov 16 03:19:55 2013 +

subversion: fix build problem when sysroot contains '-D' or '-I'
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Conf notes

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 2:50 PM, Gary Thomas g...@mlbassoc.com wrote:
 It is working fine:

 Indeed, that does work, but only for the first time of if you specify 
 TEMPLATECONF.

 I often have build trees that live for a very long time (think months) and 
 I'll
 do something like this:
   TEMPLATECONF=my-layer/conf . ${POKY}/oe-init-build-env somedir
 then later, e.g. after a reboot of my build host, I do just this:
   . ${POKY}/oe-init-build-env somedir
 This renews the build setting for that setup just fine, but in this case, I'll
 get the default conf-notes.txt, not my layer specific ones.

right, this is expected. TEMPLATECONF needs to be set each time you
source the init scripts.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: Separate build dir for autotools

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 5:09 PM, Martin Jansa martin.ja...@gmail.com wrote:

 That list is opt-in and mainly covers oe-core, so this gets tested
 every time the YP autobuilder does a world build.  We need a meta-oe
 world build where autotools.bbclass sets B=${WORKDIR}/build: it's
 literally just this one-line patch.

 But doesn't cover oe-core built with different combinations for
 PACKAGECONFIGs, .bbappends etc, so including this file in
 defaultsetup.conf can still reveal few issues in oe-core recipes.

right. I have recently (on dora) noticed that mesa build is broken
when using separate build dir, i have the following extra config:

PACKAGECONFIG_append =  gallium gallium-egl gallium-gbm gallium-llvm

since gallium-egl needs the egl.h files generated during mesa build.
the generated files stay in $B while gallium-egl is looking for them
in $S (or sysroot)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: Separate build dir for autotools

[Nicolas Dechesne]

On Tue, Feb 25, 2014 at 7:43 PM, Burton, Ross ross.bur...@intel.com wrote:
 On 25 February 2014 17:36, Nicolas Dechesne nicolas.deche...@linaro.org 
 wrote:
 right. I have recently (on dora) noticed that mesa build is broken
 when using separate build dir, i have the following extra config:

 PACKAGECONFIG_append =  gallium gallium-egl gallium-gbm gallium-llvm

 since gallium-egl needs the egl.h files generated during mesa build.
 the generated files stay in $B while gallium-egl is looking for them
 in $S (or sysroot)

 Pretty sure I fixed that:  oe-core fbc7092f0ae07538d4363679b1597ba4e556d1a8

 It looks like that's in Dora so we've possibly regressed again, can
 you file a bug (CCing me) with the build log?

oops. you're right. it's fixed in both dora and master. in fact i got
hit by that on dylan... but they i switched to dora anyways... so this
one is fine.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: Separate build dir for autotools

[Nicolas Dechesne]

Ross,

On Tue, Feb 25, 2014 at 11:10 PM, Nicolas Dechesne
nicolas.deche...@linaro.org wrote:
 oops. you're right. it's fixed in both dora and master. in fact i got
 hit by that on dylan... but they i switched to dora anyways... so this
 one is fine.

I guess i spoke too quickly... i just retried a dora and master after
cleansstate on mesa, and master seems to build fine, but dora failed
to build. see

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5882
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [dora][PATCH] mesa: build fix for gallium-egl

[Nicolas Dechesne]

On Wed, Feb 26, 2014 at 4:30 PM, Valentin Popa valentin.p...@intel.com wrote:
 Avoid altering eglplatform.h from {top_srcdir}/include
 using an alternative to
 0003-EGL-Mutate-NativeDisplayType-depending-on-config
 patch.

i don't think this is the right fix. i get the following build failures now:

| i586-rdk-linux-libtool: compile:  i586-rdk-linux-gcc -m32
-march=i586 --sysroot=/work/rdk-dora/build-qemux86/tmp/sysroots/qemux86
-DPACKAGE_NAME=\Mesa\ -DPACKAGE_TARNAME=\mesa\
-DPACKAGE_VERSION=\9.1.6\ -DPACKAGE_STRING=\Mesa 9.1.6\
-DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\;
-DPACKAGE_URL=\\ -DPACKAGE=\mesa\ -DVERSION=\9.1.6\
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -DHAVE_LIBEXPAT=1 -I.
-I/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/src/egl/main
-I/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/include
-I../../../include
-I/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/src/gbm/main
-D_GNU_SOURCE -DHAVE_PTHREAD -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN
-DIN_DRI_DRIVER -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0303
-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_DRM
-D_EGL_DRIVER_SEARCH_DIR=\/usr/lib/egl\ -D_EGL_OS_UNIX=1
-DHAVE_DRM_PLATFORM -DHAVE_FBDEV_PLATFORM -D_EGL_BUILT_IN_DRIVER_DRI2
-DHAVE_XCB_DRI2 -O2 -pipe -g -feliminate-unused-debug-types
-fno-omit-frame-pointer -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -c
/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/src/egl/main/eglconfig.c
 -fPIC -DPIC -o .libs/eglconfig.o
| make[3]: *** [eglapi.lo] Error 1
| In file included from
/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/include/EGL/egl.h:36:0,
|  from
/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/src/egl/main/egltypedefs.h:36,
|  from
/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/src/egl/main/egllog.h:34,
|  from
/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/src/egl/main/eglarray.c:32:
| 
/work/rdk-dora/build-qemux86/tmp/work/i586-rdk-linux/mesa/2_9.1.6-r0/Mesa-9.1.6/include/EGL/eglplatform.h:118:22:
fatal error: X11/Xlib.h: No such file or directory
|  #include X11/Xlib.h

I am building with x11 removed from DISTRO_FEATURES, btw.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Signed-off-by: Andrey Belous abel...@broadcom.com

[Nicolas Dechesne]

Hi,

On Wed, Mar 5, 2014 at 7:11 AM, Andrey Belous abel...@broadcom.com wrote:
 Yes I overwriting more  , but other variable already with ?= and allow to 
 override them

I think I am okay with the patch proposed here. i don't see why the
late assignment is missing just for this specific variable while it's
used for every other variables and in the eglibc include file we
already use the ?= for virtual/libc.

as far as I am concerned, assuming the commit log gets rewritten
properly, you can add:

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org

cheers,

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

Re: [OE-core] [PATCH] Signed-off-by: Andrey Belous abel...@broadcom.com

[Nicolas Dechesne]

Hi Khem,

On Fri, Mar 7, 2014 at 6:43 AM, Khem Raj raj.k...@gmail.com wrote:
 On Tue, Mar 4, 2014 at 1:55 PM, Andrey Belous abel...@broadcom.com wrote:
 Hi Phil,
 I have prebuild uclibc library that I would like to use, without that change 
 I cannot force to use my prebuild library


 OK so write a uclibc recipe for it and let it provide virtual/libc
 and, we can very well have multiple version of recipes, this is no
 different. Then use higher DEFAULT_PREFERENCE for your recipe.

I still don't get it why in distro/include/tclibc-uclibc.inc we have

PREFERRED_PROVIDER_virtual/libc = uclibc
PREFERRED_PROVIDER_virtual/libiconv ?= libiconv
PREFERRED_PROVIDER_virtual/libintl ?= gettext
PREFERRED_PROVIDER_virtual/nativesdk-libintl ?= nativesdk-eglibc
PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= nativesdk-eglibc

and in distro/include/tclibc-eglibc.inc, we have:

PREFERRED_PROVIDER_virtual/libiconv ?= eglibc
PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= nativesdk-eglibc
PREFERRED_PROVIDER_virtual/nativesdk-libintl ?= nativesdk-eglibc
PREFERRED_PROVIDER_virtual/libintl ?= eglibc
PREFERRED_PROVIDER_virtual/libc ?= eglibc
PREFERRED_PROVIDER_virtual/nativesdk-libc ?= nativesdk-eglibc
PREFERRED_PROVIDER_virtual/libc-locale ?= eglibc-locale

Is a specific reason why in the first case we use = and not ?=
like used everywhere else? This file is loaded last, so we have no
chance to override the value. regardless of the actual reason, don't
we need the change anyways?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] --conf Was: Features in Yocto Project 1.7

[Nicolas Dechesne]

On Wed, Mar 26, 2014 at 3:38 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
 As a concrete example, currently I'm flipping between dora and master
 builds. For some reason I can't seem to reuse the same TMPDIR between
 them. So every time I repo init -b newbranch I then also have to
 edit conf/local.conf before bitbaking.

 Use separated build directories for this, so you don't need to mangle
 conf/local.conf every time.

 Personally I have different trees for Dora and Master and inside it I
 have several build directories when working in this kind of test
 (different distro features and like) and this is easy to maintain. For
 auto builder, we cooked a script to abstract the configuration in
 command line options so we can easily extend it and get it used in
 several build jobs.

I do that too. build folders are 'cheap' assuming good use of sstate
and rm_work. my typical setup is:
- one workspace for each OE release branch (trees checkout)
- one build folder for each combination of distro-machine
- one shared downloads folder for *all* builds across all workspace
- one shared ssate for each workspace . i am not sharing sstate across
OE releases, mostly because sstate-cache-management would always
delete the wrong stuff otherwise.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] git: update to v2.0.1

[Nicolas Dechesne]

Also fetch source code from kernel.org. As per the Git release announcement, see
[1], Git source tarball are now located back on kernel.org, at [2].

[1] https://lkml.org/lkml/2014/6/25/760
[2] https://www.kernel.org/pub/software/scm/git/

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-devtools/git/git.inc| 1 +
 meta/recipes-devtools/git/{git_1.9.0.bb = git_2.0.1.bb} | 6 ++
 2 files changed, 3 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/git/{git_1.9.0.bb = git_2.0.1.bb} (52%)

diff --git a/meta/recipes-devtools/git/git.inc 
b/meta/recipes-devtools/git/git.inc
index 4e0527c..7633577 100644
--- a/meta/recipes-devtools/git/git.inc
+++ b/meta/recipes-devtools/git/git.inc
@@ -5,6 +5,7 @@ DEPENDS = openssl curl zlib expat
 
 PROVIDES_append_class-native =  git-replacement-native
 
+SRC_URI = ${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz
 S = ${WORKDIR}/git-${PV}
 
 LIC_FILES_CHKSUM = file://COPYING;md5=7c0d7ef03a7eb04ce795b0f60e68e7e1
diff --git a/meta/recipes-devtools/git/git_1.9.0.bb 
b/meta/recipes-devtools/git/git_2.0.1.bb
similarity index 52%
rename from meta/recipes-devtools/git/git_1.9.0.bb
rename to meta/recipes-devtools/git/git_2.0.1.bb
index 4eb6c99..dbf32e1 100644
--- a/meta/recipes-devtools/git/git_1.9.0.bb
+++ b/meta/recipes-devtools/git/git_2.0.1.bb
@@ -1,9 +1,7 @@
 require git.inc
 
-SRC_URI = http://git-core.googlecode.com/files/git-${PV}.tar.gz;
-
-SRC_URI[md5sum] = e16c14b27c644b8e0dd72bdb5ff77450
-SRC_URI[sha256sum] = 
de3097fdc36d624ea6cf4bb853402fde781acdb860f12152c5eb879777389882
+SRC_URI[md5sum] = 981f5937840716cb563be1cc6292c8d7
+SRC_URI[sha256sum] = 
02609a06fb40db1f6a968867c0e82bcb959b85902747830de0fda53228712daf
 
 EXTRA_OECONF += ac_cv_snprintf_returns_bogus=no ac_cv_c_c99_format=yes \
  
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
-- 
2.0.1

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

Re: [OE-core] [PATCH] git: update to v2.0.1

[Nicolas Dechesne]

On Thu, Jul 10, 2014 at 9:37 PM, Burton, Ross ross.bur...@intel.com wrote:
 On 10 July 2014 18:32, Nicolas Dechesne nicolas.deche...@linaro.org wrote:
 Also fetch source code from kernel.org. As per the Git release announcement, 
 see
 [1], Git source tarball are now located back on kernel.org, at [2].

 Were there any big changes in 2.0 that we should be aware of, or was
 that just an arbitrary version bump?

I think the most notable change is about git push when no branch is
specified. the default changed from 'matching' to 'simple'. it should
not come as a surprise since it's been announced for some time now.
and in fact it is a much better default anyways..  other than that,
it's just business/improvements as usual. see
http://blogs.atlassian.com/2014/06/happened-git-2-0-full-goodies/
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libdrm: upgrade to 2.4.54

[Nicolas Dechesne]

Version 2.4.54 was released a couple of months ago, see [1] for list of
changes.

The upgrade is required for using recent freedreno X11 driver on QCOM SoC. This
was tested on IFC6410 board.

[1] http://lists.x.org/archives/xorg-announce/2014-May/002426.html

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/drm/libdrm_2.4.53.bb | 8 
 meta/recipes-graphics/drm/libdrm_2.4.54.bb | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)
 delete mode 100644 meta/recipes-graphics/drm/libdrm_2.4.53.bb
 create mode 100644 meta/recipes-graphics/drm/libdrm_2.4.54.bb

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.53.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.53.bb
deleted file mode 100644
index 323bef5..000
--- a/meta/recipes-graphics/drm/libdrm_2.4.53.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require libdrm.inc
-
-SRC_URI += file://installtests.patch \
-file://GNU_SOURCE_definition.patch \
-   
-SRC_URI[md5sum] = 342886a137ddd9ed4341675d132388ad
-SRC_URI[sha256sum] = 
1b0c28fd2f2b92d2df0a73d1aed88f43cb0dee1267aea6bc52ccb5fca5757a08
-
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.54.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.54.bb
new file mode 100644
index 000..12eefc7
--- /dev/null
+++ b/meta/recipes-graphics/drm/libdrm_2.4.54.bb
@@ -0,0 +1,8 @@
+require libdrm.inc
+
+SRC_URI += file://installtests.patch \
+file://GNU_SOURCE_definition.patch \
+   
+SRC_URI[md5sum] = 56e98a9c2073c3fab7f95e003b657f46
+SRC_URI[sha256sum] = 
d94001ebfbe80e1523d1228ee2df57294698d1c734fad9ccf53efde8932fe4e9
+
-- 
2.0.1

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

[OE-core] [PATCH] libdrm: enable freedreno experimental support

[Nicolas Dechesne]

The freedreno project is a free and open source linux driver for the 2D/3D GPUs
in Qualcomm snapdragon SoCs.

Support for freedreno in libdrm was added around 2.4.43.

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/drm/libdrm.inc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/drm/libdrm.inc 
b/meta/recipes-graphics/drm/libdrm.inc
index 1b2ffeb..5ec6307 100644
--- a/meta/recipes-graphics/drm/libdrm.inc
+++ b/meta/recipes-graphics/drm/libdrm.inc
@@ -21,14 +21,15 @@ inherit autotools pkgconfig
 
 EXTRA_OECONF += --disable-cairo-tests \
  --enable-omap-experimental-api \
+ --enable-freedreno-experimental-api \
  --enable-install-test-programs \
 
 ALLOW_EMPTY_${PN}-drivers = 1
 PACKAGES =+ ${PN}-tests ${PN}-drivers ${PN}-radeon ${PN}-nouveau ${PN}-omap \
- ${PN}-intel ${PN}-exynos ${PN}-kms
+ ${PN}-intel ${PN}-exynos ${PN}-kms ${PN}-freedreno
 
 RRECOMMENDS_${PN}-drivers = ${PN}-radeon ${PN}-nouveau ${PN}-omap ${PN}-intel 
\
- ${PN}-exynos
+ ${PN}-exynos ${PN}-freedreno
 
 FILES_${PN}-tests = ${bindir}/dr* ${bindir}/mode* ${bindir}/*test
 FILES_${PN}-radeon = ${libdir}/libdrm_radeon.so.*
@@ -37,3 +38,4 @@ FILES_${PN}-omap = ${libdir}/libdrm_omap.so.*
 FILES_${PN}-intel = ${libdir}/libdrm_intel.so.*
 FILES_${PN}-exynos = ${libdir}/libdrm_exynos.so.*
 FILES_${PN}-kms = ${libdir}/libkms*.so.*
+FILES_${PN}-freedreno = ${libdir}/libdrm_freedreno.so.*
-- 
2.0.1

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

Re: [OE-core] [yocto] RFC: Improving the developer workflow

[Nicolas Dechesne]

On Thu, Aug 7, 2014 at 3:05 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
 Personally with how fragile package management can end up being, I'm convinced
 that full-image updates are the way to go for a lot of cases, but ideally with
 some intelligence so that you only ship the changes (at a filesystem level
 rather than a package or file level). This ensures that an upgraded image on
 one device ends up exactly identical to any other device including a newly
 deployed one. Of course it does assume that you have a read-only rootfs and
 keep your configuration data / logs / other writeable data on a separate
 partition or storage medium. However, beyond improvements to support for
 having a read-only rootfs we haven't really achieved anything in terms of out-
 of-the-box support for this, mainly due to lack of resources.

 However, whilst I haven't had a chance to look at it closely, there has been
 some work on this within the community:

 http://sbabic.github.io/swupdate/swupdate.html
 https://github.com/sbabic/swupdate
 https://github.com/sbabic/meta-swupdate/


fwiw, Ubuntu has started to do something like that for their phone images, see

https://wiki.ubuntu.com/ImageBasedUpgrades

I haven't used nor looked into the details... i just had heard about
it, and thought it was worth mentioning it here. however the main
design idea from that wiki page is exactly what we are discussing
here. e.g. build images on the 'server' side using our regular tools,
but deploy binary differences on targets.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: Improving the developer workflow

[Nicolas Dechesne]

On Thu, Aug 7, 2014 at 11:10 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
 Example workflow
 

 I won't give a workflow for every possible usage, but just to give a basic
 example - let's assume you want to build a new piece of software for which
 you have your own source tree on your machine. The rough set of steps required
 would be something like this (rough, e.g. the command names given shouldn't be
 read as final):

 1. Install the SDK

 2. Run a setup script to make the SDK tools available

 3. Add a new recipe with sdktool add recipename - interactive process. The
 tool records that recipename is being worked on, creates a recipe that can
 be used to build the software using your external source tree, and places the
 recipe where it will be used automatically by other steps.

 4. Build the recipe with sdktool build recipename. This probably only goes
 as far as do_install or possibly do_package_qa; in any case the QA process
 would be less stringent than with the standard build system however in order
 to avoid putting too many barriers in the way of testing on the target.

 5. Fix any failures and repeat from the previous step as necessary.

 6. Deploy changes to target with sdktool deploy-target ip address assuming
 SSH is available on the target. Alternatively sdktool build-image
 imagename can be used to regenerate an image with the changes in it;
 sdktool runqemu could do that (if necessary) and then run the result within
 QEMU with the appropriate options set.

coincidentally, i was giving an OE workshop this week, and when I
explained about the OE SDK, someone immediately brought up that it was
quite limited because:

 1- SDK cannot be used to generate deployable packages, e.g.  using
the SDK to create ipk/deb/rpm that can be delivered to
targets/clients, not just for debugging, but also for production when
production system has package management support.
 2- SDK cannot be used to regenerate updated images. e.g. Company A
delivers a SDK + board, Company B is making a product using the SDK
(adding content) and wants to be able to make new images with the new
content in order to sell/deploy it.
 3- SDK itself cannot be upgraded when the 'base image' and SDK are updated
 4- SDK users cannot add content to the SDK. e.g. I am a SDK user I
create a library and I want that library to be in the SDK now.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Two distros with same MACHINE

[Nicolas Dechesne]

On Wed, Aug 13, 2014 at 12:46 PM, Yevhen Kyriukha kirg...@gmail.com wrote:
 I have 2 distro configs that use different PACKAGECONFIG settings for the
 same package. I'm building all distros for single MACHINE. Do I need to set
 different TMPDIR to build these two distros or I can use same dir?


yes, you should. i generally recommend to use 1 build dir for each
combination of machine, distro and OE version. keep in mind that
TMPDIR are 'cheap', assuming you are sharing ssate-cache, downloads
and using rm_work..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] mesa: Upgrade to 10.3.3

[Nicolas Dechesne]

On Mon, Dec 1, 2014 at 11:36 PM, Aníbal Limón
anibal.li...@linux.intel.com wrote:
 -SRCREV = 0028eb1083e6adc110a23a5f02c993cda217067a
 -PV = 10.1.3+git${SRCPV}
 +SRCREV = 9cc26056ee13f25c5785fef81b31487f1429baa4
 +PV = 10.3.3+git${SRCPV}

10.3.4 has been ~2 weeks ago, can't we use this one instead?

in the mean time, I am going to test this series on a non Intel
platform (ARM based Snapdragon using Mesa/gallium freedreno driver)


 -SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;branch=10.1 \
 -   
 file://0002-pipe_loader_sw-include-xlib_sw_winsys.h-only-when-HA.patch \
 -   file://0006-fix-out-of-tree-egl.patch \
 -   

awesome to get rid of those , and finally use a vanilla upstream..

 +SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;branch=10.3

  S = ${WORKDIR}/git
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] xorg-xserver: Upgrade to 1.16.2

[Nicolas Dechesne]

On Mon, Dec 1, 2014 at 11:36 PM, Aníbal Limón
anibal.li...@linux.intel.com wrote:
 Remove crosscompile, mips64-compile and present-module because are already in
 upstream.

 Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
 ---
  .../xorg-xserver/xserver-xorg/crosscompile.patch   | 22 
  .../xserver-xorg/mips64-compiler.patch | 29 --
  .../xorg-xserver/xserver-xorg/present-module.patch | 66 
 --
  ...erver-xorg_1.15.1.bb = xserver-xorg_1.16.2.bb} |  9 +--
  4 files changed, 3 insertions(+), 123 deletions(-)
  delete mode 100644 
 meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
  delete mode 100644 
 meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
  delete mode 100644 
 meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
  rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.15.1.bb = 
 xserver-xorg_1.16.2.bb} (75%)


I am seeing the following warning when building this patch:

WARNING: QA Issue: xserver-xorg rdepends on dbus-lib, but it isn't a
build dependency? [build-deps]
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] xorg-xserver: Upgrade to 1.16.2

[Nicolas Dechesne]

On Tue, Dec 2, 2014 at 3:50 PM, Aníbal Limón
anibal.li...@linux.intel.com wrote:
 I don't see this warning, i ran with (log attached),

 $ bitbake xserver-xorg -v -D


xserver-xorg does auto-detection for dbus in configure.ac

==
PKG_CHECK_MODULES(DBUS, $LIBDBUS, [HAVE_DBUS=yes], [HAVE_DBUS=no])
if test x$HAVE_DBUS = xyes; then
AC_DEFINE(HAVE_DBUS, 1, [Have D-Bus support])
fi
AM_CONDITIONAL(HAVE_DBUS, [test x$HAVE_DBUS = xyes])
==

i am building core-image-x11 , which pulls in dbus i believe. hence
the warning in my case, since I have dbus in my sysroot..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

[Nicolas Dechesne]

hi,

On Mon, Dec 1, 2014 at 11:36 PM, Aníbal Limón
anibal.li...@linux.intel.com wrote:
 Testing was made building and running core-image-sato in qemux86, qemumips,
 and qemuarm also core-image-sato/core-image-weston in Intel NUC.

 Tests freedesktop piglit was run in Intel NUC with 95% of tests passes
 (9251/9694), you can found full results at [1].

 [YOCTO #6805]

 [1] https://bugzilla.yoctoproject.org/attachment.cgi?id=2267

 The following changes since commit b8631416f12b8a904ce3deb036f9d5ce632937b0:

   package_regex.inc: Update REGEX'es in order to find upstream versions 
 correctly (2014-11-28 14:03:02 +)

 are available in the git repository at:

   git://git.yoctoproject.org/poky-contrib alimon/linux_intel_graphics_2014q3
   
 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=alimon/linux_intel_graphics_2014q3

 Aníbal Limón (3):
   libdrm: Upgrade to 2.4.58.
   mesa: Upgrade to 10.3.3
   xorg-xserver: Upgrade to 1.16.2

I have tested this series on IFC6410 board (Snapdragon 600, with
Adreno 320 GPU) using freedreno Mesa/Gallium driver, using [1].

tested GLX and EGL with Xorg 1.16. Also tested the OutputClass feature
available in 1.16.

it all looks good to me, so fwiw, all patches can have:

Tested-by: Nicolas Dechesne nicolas.deche...@linaro.org

cheers.

[1] 
https://git.linaro.org/people/nicolas.dechesne/meta-qualcomm.git/shortlog/refs/heads/xorg-1.16
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH] mesa: add PACKAGECONFIG support for gallium XA state tracker

[Nicolas Dechesne]

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/mesa/mesa.inc | 6 ++
 1 file changed, 6 insertions(+)
---
I have tested:
- on IFC6410 with Snapdragon 600 and Adreno 320 running the freedreno
  Gallium driver from mesa
- with Mesa 10.3 so i would recommend we wait for 10.3 to be merged first
- with branch xorg-1.16 from this BSP layer [1]

Sending as RFC to see if this is the right way to enable this
feature...

[1] https://git.linaro.org/people/nicolas.dechesne/meta-qualcomm.git/

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 1857f3c..cb1837a 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -65,6 +65,7 @@ MESA_LLVM_RELEASE ?= 3.3
 PACKAGECONFIG[gallium-llvm] = --enable-gallium-llvm --with-llvm-shared-libs, 
--disable-gallium-llvm, llvm${MESA_LLVM_RELEASE} \
${@'elfutils' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}
 export WANT_LLVM_RELEASE = ${MESA_LLVM_RELEASE}
+PACKAGECONFIG[xa]  = --enable-xa, --disable-xa
 
 # llvmpipe is slow if compiled with -fomit-frame-pointer (e.g. -O2)
 FULL_OPTIMIZATION_append =  -fno-omit-frame-pointer
@@ -87,6 +88,7 @@ PACKAGES =+ libegl-mesa libegl-mesa-dev \
  libegl-gallium libgbm-gallium \
  libopenvg libopenvg-dev \
  libxvmcsoftpipe libxvmcsoftpipe-dev \
+ libxatracker libxatracker-dev \
  mesa-megadriver \
 
 
@@ -171,6 +173,7 @@ FILES_libegl-gallium = ${libdir}/egl/egl_gallium.so*
 FILES_libgbm-gallium = ${libdir}/gbm/gbm_gallium_drm.so*
 FILES_libopenvg = ${libdir}/libOpenVG.so.*
 FILES_libxvmcsoftpipe = ${libdir}/libXvMCsoftpipe.so.*
+FILES_libxatracker = ${libdir}/libxatracker.so.*
 
 FILES_${PN}-dev = ${libdir}/pkgconfig/dri.pc
 FILES_libegl-mesa-dev = ${libdir}/libEGL.* ${includedir}/EGL 
${includedir}/KHR ${libdir}/pkgconfig/egl.pc
@@ -185,5 +188,8 @@ FILES_libwayland-egl-dev = 
${libdir}/pkgconfig/wayland-egl.pc ${libdir}/libwayl
 FILES_libopenvg-dev = ${libdir}/libOpenVG.so ${libdir}/libOpenVG.la* \
${includedir}/VG ${libdir}/pkgconfig/vg.pc
 FILES_libxvmcsoftpipe-dev = ${libdir}/libXvMCsoftpipe.so 
${libdir}/libXvMCsoftpipe.la
+FILES_libxatracker-dev = ${libdir}/libxatracker.so ${libdir}/libxatracker.la \
+  ${includedir}/xa_tracker.h 
${includedir}/xa_composite.h ${includedir}/xa_context.h \
+  ${libdir}/pkgconfig/xatracker.pc
 
 FILES_${PN}-dbg += ${libdir}/dri/.debug/* ${libdir}/egl/.debug/* 
${libdir}/gbm/.debug/* ${libdir}/gallium-pipe/.debug
-- 
2.1.3

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

Re: [OE-core] [PATCH 1/3] libdrm: Upgrade to 2.4.58.

[Nicolas Dechesne]

On Thu, Dec 4, 2014 at 12:30 AM, Burton, Ross ross.bur...@intel.com wrote:
  | I/O error : Attempt to load network entity
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
 | warning: failed to load external entity
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
 | cannot parse
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
 | Makefile:612: recipe for target 'drmAvailable.3' failed

 https://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/114/steps/BuildImages_1/logs/stdio

 I guess it found some documentation tools at configure time and is
 attempting to build the docs, but not enough was present.  An easy solution
 for now would be to disable the documentation with either a configure option
 or patch.

hmm. it worked for me, libdrm-doc was generated fine, and nothing
really has changed upstream in this area. my buildhistory shows that
libdrm-doc has:

==
PV = 2.4.58
PR = r0
RPROVIDES =
RDEPENDS =
RRECOMMENDS =
PKGSIZE = 40390
FILES = /usr/share/doc /usr/share/man /usr/share/info
/usr/share/gtk-doc /usr/share/gnome/help
FILELIST = /usr/share/man/man3/drmAvailable.3
/usr/share/man/man3/drmHandleEvent.3 /usr/share/man/man3/drmModeG\
etResources.3 /usr/share/man/man7/drm-gem.7
/usr/share/man/man7/drm-kms.7 /usr/share/man/man7/drm-memory.7 /usr\
/share/man/man7/drm-mm.7 /usr/share/man/man7/drm-ttm.7 /usr/share/man/man7/drm.7
==

could it be a temporary network issue that prevented access to
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
when the package was built?

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

Re: [OE-core] [PATCH 1/3] libdrm: Upgrade to 2.4.58.

[Nicolas Dechesne]

On Thu, Dec 4, 2014 at 3:40 PM, Burton, Ross ross.bur...@intel.com wrote:
 On 4 December 2014 at 07:14, Nicolas Dechesne nicolas.deche...@linaro.org
 wrote:

 hmm. it worked for me, libdrm-doc was generated fine, and nothing
 really has changed upstream in this area. my buildhistory shows that
 libdrm-doc has:


 And my libdrm has no documentation, because it's checking for xsltproc and
 the docbook stylesheets, which I don't have installed..  You had
 dependencies, I don't, the autobuilder may have had transient failure or an
 incomplete set of build deps.  Either way, this should be an option as
 currently this isn't deterministic.  We need a packageconfig for manpages
 with xsltproc-native and the xslt stylesheets as build depends.

you're right.. i have xsltproc in my sysroot..

i didn't find any other package in -core where we really used a
PACKAGECONFIG for doc. so i would vote to simply do like we do in
every other packages, e.g.

--- a/meta/recipes-graphics/drm/libdrm.inc
+++ b/meta/recipes-graphics/drm/libdrm.inc
@@ -20,6 +20,7 @@ DEPENDS +=  libpciaccess
 inherit autotools pkgconfig

 EXTRA_OECONF += --disable-cairo-tests \
+ --disable-manpages \
  --enable-omap-experimental-api \
  --enable-freedreno-experimental-api \
  --enable-install-test-programs \

With that change, I am getting:

==
--- a/packages/armv7at2hf-vfp-neon-oe-linux-gnueabi/libdrm/libdrm-doc/latest
+++ b/packages/armv7at2hf-vfp-neon-oe-linux-gnueabi/libdrm/libdrm-doc/latest
@@ -3,6 +3,6 @@ PR = r0
 RPROVIDES =
 RDEPENDS =
 RRECOMMENDS =
-PKGSIZE = 40390
+PKGSIZE = 0
 FILES = /usr/share/doc /usr/share/man /usr/share/info
/usr/share/gtk-doc /usr/share/gnome/help
-FILELIST = /usr/share/man/man3/drmAvailable.3
/usr/share/man/man3/drmHandleEvent.3 /usr/share/man/man3/drmModeG
+FILELIST =
==

By the way, this is not a new problem (sorry I know i reported it on
that thread ;-). This change for manpages was done in 2.4.42. So we
should not really block the update to 2.4.58, and if you agree on the
patch above, i can send it separately.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

[Nicolas Dechesne]

On Fri, Dec 5, 2014 at 12:18 AM, Aníbal Limón
anibal.li...@linux.intel.com wrote:
 Testing was made building and running core-image-sato in qemux86, qemumips,
 and qemuarm also core-image-sato/core-image-weston in Intel NUC.

 Tests freedesktop piglit was run in Intel NUC with 95% of tests passes
 (9251/9694), you can found full results at [1].

 [YOCTO #6805]

 [1] https://bugzilla.yoctoproject.org/attachment.cgi?id=2267

 The following changes since commit a862bf045109d213c301121961bd8d389e48b13d:

   upstream_tracking.inc: update entries for dbus (2014-12-03 12:24:01 +)

 are available in the git repository at:

   git://git.yoctoproject.org/poky-contrib 
 alimon/linux_intel_graphics_2014q3_v2
   
 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=alimon/linux_intel_graphics_2014q3_v2

 Aníbal Limón (3):
   libdrm: Upgrade to 2.4.58.
   mesa: Upgrade to 10.3.4.
   xorg-xserver: Upgrade to 1.16.2.


I have tested the last 2 patches on top of this morning master-tip
which already included the libdrm upgrade. mesa 10.3.4 and Xorg 1.16.2
worked fine for me on Snapdragon 600, using mesa/gallium freedreno.

thanks for making the update!

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

Re: [OE-core] [PATCHv2 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

[Nicolas Dechesne]

On Tue, Dec 9, 2014 at 9:06 PM, Burton, Ross ross.bur...@intel.com wrote:
 On 9 December 2014 at 18:14, Aníbal Limón anibal.li...@linux.intel.com
 wrote:

 I don't know, maybe Ross knows?.


 I ask for Piglit results to verify that approx 95% passes as that's the
 expected pass rate.  I don't bother tracking the exact count as how it
 changes as there's almost ten thousand tests and at some point you have to
 let upstream deal with this.

are you using the oe-core piglit recipe for testing? i didn't realize
we had such recipe.. just want to make sure that the one we have is
ok, then I can run it on my hw as well.

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

Re: [OE-core] [PATCH] gstreamer1.0-omx: use mulitple SCMs to fetch submodules

[Nicolas Dechesne]

On Mon, Dec 29, 2014 at 10:46 AM, Awais Belal awais_be...@mentor.com wrote:
 The gstreamer omx package uses a submodule 'common' which
 is fetched by the configure script. This approach fails
 on non-network builds as the fetcher tries to look upstream
 for the submodule.
 We now use multiple SCMs, one for the main omx package and
 the other for the 'common' submodule so it is available in
 the downloads_dir for later use.


we have the same issues with all the others gstreamer1.0-*_git.bb
recipes, don't we? maybe we should fix them all. i am not sure if
there is a nice way to do it for all recipes, like with a .inc file,
to avoid duplication..

also, the autogen.sh script will still run git submodule update, even
if the 'common' folder already exist, so we will need to be extra
careful when upgrading the _git.bb recipes to update both
SRCREV_gst-omx and SRCREV_common or we will have the same issue
again..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gstreamer1.0-omx: use mulitple SCMs to fetch submodules

[Nicolas Dechesne]

On Mon, Dec 29, 2014 at 1:55 PM, Belal, Awais awais_be...@mentor.com wrote:
 Hi Nicolas,

 I sent this against the omx package only because I wanted to see if there's 
 any feedback on this for improvement or anything that I might be doing wrong. 
 If this gets accepted I will submit updates for the other 
 gstreamer1.0-*_git.bb recipes as you've correctly pointed out that they 
 suffer from the same dilemma. Doing it through a .inc wouldn't be a good idea 
 because the dependency from one package to the other lies not just only the 
 package but the exact rev as well so it should be done in this way for all in 
 my opinion.


right... sorry, i missed the discussion from last week... that's the
problem with vacations ;-)

so, the changes look good. i have a branch with gstreamer 1.4.5
updates which i am testing at the moment, i will send the patches
later this week.

 The SRC_REVs will obviously need to be taken care of when an update is made 
 but I think this is the way to go.

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

Re: [OE-core] [PATCH 1/7] gstreamer1.0: upgrade to 1.4.5

[Nicolas Dechesne]

On Tue, Dec 30, 2014 at 7:03 PM, Ross Burton ross.bur...@intel.com wrote:
 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
  .../gstreamer/{gstreamer1.0_1.4.1.bb = gstreamer1.0_1.4.5.bb}|5 
 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
  rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.4.1.bb = 
 gstreamer1.0_1.4.5.bb} (72%)

 diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.1.bb 
 b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
 similarity index 72%
 rename from meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.1.bb
 rename to meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
 index 56fc4f2..94be846 100644
 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.1.bb
 +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.4.5.bb
 @@ -7,7 +7,8 @@ SRC_URI =  \
  http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
  file://0001-Fix-crash-with-gst-inspect.patch \
  
 -SRC_URI[md5sum] = bd0938d680d657249b885162f310702d
 -SRC_URI[sha256sum] = 
 5638f75003282135815c0077d491da11e9a884ad91d4ba6ab3cc78bae0fb452e
 +SRC_URI[md5sum] = 88a9289c64a4950ebb4f544980234289
 +SRC_URI[sha256sum] = 
 40801aa7f979024526258a0e94707ba42b8ab6f7d2206e56adbc4433155cb0ae
 +
  S = ${WORKDIR}/gstreamer-${PV}

thanks.. you beat me at sending the patches on the list... i have been
testing a similar patchset locally today.

i have reviewed all your patches, and look the same as mine.

however you are adding extra empty lines in the first 6 patches in the
series. was is intentionally done?

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

Re: [OE-core] [meta-oe][V2][PATCH] mesa: Upgrade to 10.4.3

[Nicolas Dechesne]

On Sat, Jan 31, 2015 at 5:39 AM, Pengyu Ma pengyu...@windriver.com wrote:
 flags for EGL and GBM Gallium had been removed in 10.4,
 so remove these flags.


I tested this patch on Snapdragon running freedreno driver with
OE-core as of this morning, it worked fine. and i could play
supertuxkart fine ;-)

so:
Tested-by: Nicolas Dechesne nicolas.deche...@linaro.org

However, i think we need a bit more clean up, since we removed the
support for EGL/GBM, we need to remove them from PACKAGES and
FILES_xxx as well since they are no longer needed.

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

Re: [OE-core] [oe-core][V2][PATCH] mesa: Upgrade to 10.4.0

[Nicolas Dechesne]

On Thu, Jan 29, 2015 at 11:05 AM, Pengyu Ma pengyu...@windriver.com wrote:
 On 01/29/2015 05:53 PM, Nicolas Dechesne wrote:

 On Wed, Jan 28, 2015 at 9:57 AM, Pengyu Ma pengyu...@windriver.com
 wrote:

 diff --git a/meta/recipes-graphics/mesa/mesa-gl_10.3.4.bb
 b/meta/recipes-graphics/mesa/mesa-gl_10.4.0.bb
 similarity index 100%
 rename from meta/recipes-graphics/mesa/mesa-gl_10.3.4.bb
 rename to meta/recipes-graphics/mesa/mesa-gl_10.4.0.bb
 diff --git a/meta/recipes-graphics/mesa/mesa_10.3.4.bb
 b/meta/recipes-graphics/mesa/mesa_10.4.0.bb
 similarity index 78%
 rename from meta/recipes-graphics/mesa/mesa_10.3.4.bb
 rename to meta/recipes-graphics/mesa/mesa_10.4.0.bb

 why not 10.4.3 directly, instead?

 10.4.0 is intel graphic stack 2014 Q4 Release version
 https://01.org/linuxgraphics/downloads/2014/2014q4-intel-graphics-stack-release

 It is stable and verified with other packages libdrm xorg-video-intel and
 xserver-xorg in oe-core master.

well, i am not sure this is right... at least probably not the right
argument. oe-core is not meant to be tied to specific intel stable
releases, whether it is about content or  schedule..

i would believe our goal is to provide the most recent stable release
instead. so that each OE (well, Yocto) release ends up with the most
recent versions.

fwiw, for the boards/platforms i care about, 10.4.3 would be fine.




 index 50092c9..7d3723e 100644
 --- a/meta/recipes-graphics/mesa/mesa_10.3.4.bb
 +++ b/meta/recipes-graphics/mesa/mesa_10.4.0.bb
 @@ -2,8 +2,8 @@ require ${BPN}.inc

   SRC_URI =
 ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2;

 -SRC_URI[md5sum] = fa0558a3d02c2bb8c208c030ccdc992e
 -SRC_URI[sha256sum] =
 e6373913142338d10515daf619d659433bfd2989988198930c13b0945a15e98a
 +SRC_URI[md5sum] = b7b37117eecbdfaaf3075acfb063d5a3
 +SRC_URI[sha256sum] =
 98a7dff3a1a6708c79789de8b9a05d8042e867067f70e8f30387c15026233219

   S = ${WORKDIR}/Mesa-${PV}

 diff --git a/meta/recipes-graphics/mesa/mesa_git.bb
 b/meta/recipes-graphics/mesa/mesa_git.bb
 index b046ae2..e554ff4 100644
 --- a/meta/recipes-graphics/mesa/mesa_git.bb
 +++ b/meta/recipes-graphics/mesa/mesa_git.bb
 @@ -4,8 +4,8 @@ DEFAULT_PREFERENCE = -1

   LIC_FILES_CHKSUM =
 file://docs/license.html;md5=6a23445982a7a972ac198e93cc1cb3de

 -SRCREV = c7b9a2e38a3e471562b50dab8be65db8ac6819f8
 -PV = 10.3.4+git${SRCPV}
 +SRCREV = f70e4d4afd16e66506ce3b055edb3b71b1464890
 +PV = 10.4.3+git${SRCPV}

 that's the commit for 10.4.3 tag, this isn't consistent with the
 change you did in the non _git recipe.

 _git version include the latest stable version of mesa.
 So that's why we keep 2 versions.


ok, that makes sense. i wasn't sure about what the _git was supposed to be.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][V2][PATCH] mesa: Upgrade to 10.4.0

[Nicolas Dechesne]

On Wed, Jan 28, 2015 at 9:57 AM, Pengyu Ma pengyu...@windriver.com wrote:

 diff --git a/meta/recipes-graphics/mesa/mesa-gl_10.3.4.bb 
 b/meta/recipes-graphics/mesa/mesa-gl_10.4.0.bb
 similarity index 100%
 rename from meta/recipes-graphics/mesa/mesa-gl_10.3.4.bb
 rename to meta/recipes-graphics/mesa/mesa-gl_10.4.0.bb
 diff --git a/meta/recipes-graphics/mesa/mesa_10.3.4.bb 
 b/meta/recipes-graphics/mesa/mesa_10.4.0.bb
 similarity index 78%
 rename from meta/recipes-graphics/mesa/mesa_10.3.4.bb
 rename to meta/recipes-graphics/mesa/mesa_10.4.0.bb

why not 10.4.3 directly, instead?


 index 50092c9..7d3723e 100644
 --- a/meta/recipes-graphics/mesa/mesa_10.3.4.bb
 +++ b/meta/recipes-graphics/mesa/mesa_10.4.0.bb
 @@ -2,8 +2,8 @@ require ${BPN}.inc

  SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2;

 -SRC_URI[md5sum] = fa0558a3d02c2bb8c208c030ccdc992e
 -SRC_URI[sha256sum] = 
 e6373913142338d10515daf619d659433bfd2989988198930c13b0945a15e98a
 +SRC_URI[md5sum] = b7b37117eecbdfaaf3075acfb063d5a3
 +SRC_URI[sha256sum] = 
 98a7dff3a1a6708c79789de8b9a05d8042e867067f70e8f30387c15026233219

  S = ${WORKDIR}/Mesa-${PV}

 diff --git a/meta/recipes-graphics/mesa/mesa_git.bb 
 b/meta/recipes-graphics/mesa/mesa_git.bb
 index b046ae2..e554ff4 100644
 --- a/meta/recipes-graphics/mesa/mesa_git.bb
 +++ b/meta/recipes-graphics/mesa/mesa_git.bb
 @@ -4,8 +4,8 @@ DEFAULT_PREFERENCE = -1

  LIC_FILES_CHKSUM = 
 file://docs/license.html;md5=6a23445982a7a972ac198e93cc1cb3de

 -SRCREV = c7b9a2e38a3e471562b50dab8be65db8ac6819f8
 -PV = 10.3.4+git${SRCPV}
 +SRCREV = f70e4d4afd16e66506ce3b055edb3b71b1464890
 +PV = 10.4.3+git${SRCPV}

that's the commit for 10.4.3 tag, this isn't consistent with the
change you did in the non _git recipe.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libdrm: upgrade to 2.4.59

[Nicolas Dechesne]

* Refreshed installtests.patch
* Removed --enable-freedreno-experimental-api, since it is now enabled by
  default upstream

Tested on Snapdragon 600 with freedreno and X11.

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/drm/libdrm.inc| 1 -
 meta/recipes-graphics/drm/libdrm/installtests.patch | 2 +-
 meta/recipes-graphics/drm/libdrm_2.4.58.bb  | 6 --
 meta/recipes-graphics/drm/libdrm_2.4.59.bb  | 6 ++
 4 files changed, 7 insertions(+), 8 deletions(-)
 delete mode 100644 meta/recipes-graphics/drm/libdrm_2.4.58.bb
 create mode 100644 meta/recipes-graphics/drm/libdrm_2.4.59.bb

diff --git a/meta/recipes-graphics/drm/libdrm.inc 
b/meta/recipes-graphics/drm/libdrm.inc
index cfac9e2..d3e1e92 100644
--- a/meta/recipes-graphics/drm/libdrm.inc
+++ b/meta/recipes-graphics/drm/libdrm.inc
@@ -21,7 +21,6 @@ inherit autotools pkgconfig
 
 EXTRA_OECONF += --disable-cairo-tests \
  --enable-omap-experimental-api \
- --enable-freedreno-experimental-api \
  --enable-install-test-programs \
  --disable-manpages \
 
diff --git a/meta/recipes-graphics/drm/libdrm/installtests.patch 
b/meta/recipes-graphics/drm/libdrm/installtests.patch
index 7d443af..03d6254 100644
--- a/meta/recipes-graphics/drm/libdrm/installtests.patch
+++ b/meta/recipes-graphics/drm/libdrm/installtests.patch
@@ -18,6 +18,6 @@ index bf1987f..d909e19 100644
drmstat
  
 +check_PROGRAMS =
- SUBDIRS = modeprint
+ SUBDIRS = modeprint proptest
  
  if HAVE_LIBKMS
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.58.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.58.bb
deleted file mode 100644
index 7b1207e..000
--- a/meta/recipes-graphics/drm/libdrm_2.4.58.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-require libdrm.inc
-
-SRC_URI += file://installtests.patch 
-
-SRC_URI[md5sum] = 2421391d72b36c16463ed92e522a
-SRC_URI[sha256sum] = 
b155fae6b9c9a3b02ef8b77f58c7c219194c996a4018dc55ba66c03996a365dd
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.59.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.59.bb
new file mode 100644
index 000..14bf44a
--- /dev/null
+++ b/meta/recipes-graphics/drm/libdrm_2.4.59.bb
@@ -0,0 +1,6 @@
+require libdrm.inc
+
+SRC_URI += file://installtests.patch 
+
+SRC_URI[md5sum] = d32a1d37c2546ee11fc5924abeedb23e
+SRC_URI[sha256sum] = 
68d26e1fd85582f4243d66864f9b43ca4ee93662825de32b5506fc8e181ea41b
-- 
1.9.1

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

Re: [OE-core] [oe-core][PATCH] mesa: Upgrade to 10.4.3

[Nicolas Dechesne]

On Fri, Jan 30, 2015 at 11:36 AM, Burton, Ross ross.bur...@intel.com wrote:

 WARNING: QA Issue: mesa: configure was passed unrecognised options:
 --disable-gallium-egl --disable-gallium-gbm [unknown-configure-option]

 Presumably they changed the configure options, so can you verify all of
 these please.

yes, they did:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.4id=c46c551c56f78c6bf9e63524c89478695fc4f525
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] mesa: update 10.4.3 - 10.4.4

[Nicolas Dechesne]

On Tue, Feb 10, 2015 at 11:23 AM, Andre McCurdy armccu...@gmail.com wrote:
 Signed-off-by: Andre McCurdy armccu...@gmail.com
 ---
  meta/recipes-graphics/mesa/{mesa-gl_10.4.3.bb = mesa-gl_10.4.4.bb} | 0
  meta/recipes-graphics/mesa/{mesa_10.4.3.bb = mesa_10.4.4.bb}   | 4 ++--
  meta/recipes-graphics/mesa/mesa_git.bb  | 6 
 ++
  3 files changed, 4 insertions(+), 6 deletions(-)
  rename meta/recipes-graphics/mesa/{mesa-gl_10.4.3.bb = mesa-gl_10.4.4.bb} 
 (100%)
  rename meta/recipes-graphics/mesa/{mesa_10.4.3.bb = mesa_10.4.4.bb} (78%)

 diff --git a/meta/recipes-graphics/mesa/mesa-gl_10.4.3.bb 
 b/meta/recipes-graphics/mesa/mesa-gl_10.4.4.bb
 similarity index 100%
 rename from meta/recipes-graphics/mesa/mesa-gl_10.4.3.bb
 rename to meta/recipes-graphics/mesa/mesa-gl_10.4.4.bb
 diff --git a/meta/recipes-graphics/mesa/mesa_10.4.3.bb 
 b/meta/recipes-graphics/mesa/mesa_10.4.4.bb
 similarity index 78%
 rename from meta/recipes-graphics/mesa/mesa_10.4.3.bb
 rename to meta/recipes-graphics/mesa/mesa_10.4.4.bb
 index 9669bcb..8140411 100644
 --- a/meta/recipes-graphics/mesa/mesa_10.4.3.bb
 +++ b/meta/recipes-graphics/mesa/mesa_10.4.4.bb


looks good to me. tested on Snapdragon 600, with freedreno mesa/gallium.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] so, which mailing list is for what?

[Nicolas Dechesne]

On Tue, Jan 6, 2015 at 5:59 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
 apparently, i still don't have a handle on the correct mailing list
 for particular patch submissions -- where's the explanation as to what
 goes where?

http://www.openembedded.org/wiki/Mailing_lists


   in particular, i want to submit some cleanups for some oe-core
 packagegroup recipe files, which list does that go to? thanks. i'll
 figure this out eventually.

oe-core patches should go to openembedded-core@lists.openembedded.org
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][V2][PATCH] mesa: Upgrade to 10.4.0

[Nicolas Dechesne]

On Fri, Jan 30, 2015 at 2:51 AM, Pengyu Ma pengyu...@windriver.com wrote:
 mesa_git bb will keep sync the latest version 10.4.3, that's why we keep
 both _git and 10.4.0.
 Now all all the version of xorg-video-intel, libdrm, and xserver-xorg are
 the same with Intel Graphic stack 2014 Q4.
 So mesa_10.4.0 will make a stable and verified solution here,
 and _git version will make the latest version here.


i think you missed the point. you cannot justify the need for 10.4.0
because it is the 'prefered' Intel version. the policy is that we
provide in OE-core the most recent stable releases of upstream
components. when/if I need a specific version of mesa (or anything
else) for my project, i have a recipe in my own project layer, but
OE-core is agnostic to that.

now, if a specific version of mesa is known to be broken, upstream, or
in very special circumstances, we might want to not use it... but that
isn't the case here, especially since both Ross and I are asking you
to upgrade to 10.4.3..

if you don't submit 10.4.3, someone else will anyways. and actually i
have submitted a libdrm upgrade yesterday which is likely to be merged
soon..

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

Re: [OE-core] [oe-core][V2][PATCH] mesa: Upgrade to 10.4.0

[Nicolas Dechesne]

On Fri, Jan 30, 2015 at 8:56 AM, Pengyu Ma pengyu...@windriver.com wrote:
 Understood, but there are 2 version mesa_xxx.bb and mesa_git.bb.
 Is there any reason why keep two versions?

right. this is indeed a good question. I am not sure what the
'semantics' of the _git.bb recipe really is. In my minds the _git was
supposed to point to development branch, or -rc release... looking at
history it seems we keep it in sync with the other mesa recipe.. so i
am not actually sure why we do that.. maybe someone else can answer.

 If I updated mesa_xxx.bb to 10.4.3, it will be the same as mesa_git.bb.

yep, like it is today...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] media player (gtk-play)

[Nicolas Dechesne]

On Tue, May 19, 2015 at 5:15 PM, Gary Thomas g...@mlbassoc.com wrote:
 Do you know if there is a way to tell gtk-play what gstreamer
 back-end(s) to use?  In particular, for my i.MX6 board, it is
 not choosing the video plugin I think it should and it would be
 nice to test if it does the right thing if the correct plugin
 is used.

by video plugin, you mean the decoder or the video sink?

if it's the sink:

gst-play --videosink foo --audiosink bar

if it's the decoder, you can't choose on the command line, the
application will just rely on playbin, so you need to configure your
plugins (and their priorities) so that playbin would pick the most
appropriate plugin.

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

Re: [OE-core] media player (gtk-play)

[Nicolas Dechesne]

On Tue, May 19, 2015 at 5:43 PM, Gary Thomas g...@mlbassoc.com wrote:
 This is what I'm looking for except I need to send these to gtk-play,
 the GUI front-end.

oops.. sorry.. read the email too quickly ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] mesa: upgrade 10.5.8 - 10.6.3

[Nicolas Dechesne]

* Removed openvg references in PACKAGECONFIG, FILES and PACKAGES since OpenVG
  support was removed in mesa 10.6
* Tested with X11 :
 * xf86-video-freedreno on IFC6410 and DragonBoard 410c
 * softpipe on DragonBoard 410c
 * using meta-qualcomm BSP

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 * Since v1
  * remove openvg support

 meta/recipes-graphics/mesa/{mesa-gl_10.5.8.bb = mesa-gl_10.6.3.bb} | 0
 meta/recipes-graphics/mesa/mesa.inc | 6 --
 meta/recipes-graphics/mesa/{mesa_10.5.8.bb = mesa_10.6.3.bb}   | 4 ++--
 3 files changed, 2 insertions(+), 8 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_10.5.8.bb = mesa-gl_10.6.3.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_10.5.8.bb = mesa_10.6.3.bb} (78%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_10.5.8.bb 
b/meta/recipes-graphics/mesa/mesa-gl_10.6.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_10.5.8.bb
rename to meta/recipes-graphics/mesa/mesa-gl_10.6.3.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 09e80e8..af7a2c4 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -49,8 +49,6 @@ EGL_PLATFORMS .=${@bb.utils.contains('PACKAGECONFIG', 'x11', 
',x11', '', d)}
 EGL_PLATFORMS .=${@bb.utils.contains('PACKAGECONFIG', 'wayland', ',wayland', 
'', d)}
 PACKAGECONFIG[egl] = --enable-egl --with-egl-platforms=${EGL_PLATFORMS}, 
--disable-egl
 
-PACKAGECONFIG[openvg] = --enable-openvg, --disable-openvg
-
 GALLIUMDRIVERS = swrast
 GALLIUMDRIVERS_LLVM33 = ${@bb.utils.contains('PACKAGECONFIG', 'r600', 
'radeonsi,r600', '', d)}
 PACKAGECONFIG[r600] = 
@@ -84,7 +82,6 @@ PACKAGES =+ libegl-mesa libegl-mesa-dev \
  libgles2-mesa libgles2-mesa-dev \
  libgles3-mesa libgles3-mesa-dev \
  libwayland-egl libwayland-egl-dev \
- libopenvg libopenvg-dev \
  libxvmcsoftpipe libxvmcsoftpipe-dev \
  libxatracker libxatracker-dev \
  mesa-megadriver \
@@ -167,7 +164,6 @@ FILES_libgl-mesa = ${libdir}/libGL.so.*
 FILES_libglapi = ${libdir}/libglapi.so.*
 FILES_libosmesa = ${libdir}/libOSMesa.so.*
 FILES_libwayland-egl = ${libdir}/libwayland-egl.so.*
-FILES_libopenvg = ${libdir}/libOpenVG.so.*
 FILES_libxvmcsoftpipe = ${libdir}/libXvMCsoftpipe.so.*
 FILES_libxatracker = ${libdir}/libxatracker.so.*
 
@@ -181,8 +177,6 @@ FILES_libgles2-mesa-dev = ${libdir}/libGLESv2.* 
${includedir}/GLES2 ${libdir}/p
 FILES_libgles3-mesa-dev = ${includedir}/GLES3
 FILES_libosmesa-dev = ${libdir}/libOSMesa.* ${includedir}/osmesa.h 
${libdir}/pkgconfig/osmesa.pc
 FILES_libwayland-egl-dev = ${libdir}/pkgconfig/wayland-egl.pc 
${libdir}/libwayland-egl.*
-FILES_libopenvg-dev = ${libdir}/libOpenVG.so ${libdir}/libOpenVG.la* \
-   ${includedir}/VG ${libdir}/pkgconfig/vg.pc
 FILES_libxvmcsoftpipe-dev = ${libdir}/libXvMCsoftpipe.so 
${libdir}/libXvMCsoftpipe.la
 FILES_libxatracker-dev = ${libdir}/libxatracker.so ${libdir}/libxatracker.la \
   ${includedir}/xa_tracker.h 
${includedir}/xa_composite.h ${includedir}/xa_context.h \
diff --git a/meta/recipes-graphics/mesa/mesa_10.5.8.bb 
b/meta/recipes-graphics/mesa/mesa_10.6.3.bb
similarity index 78%
rename from meta/recipes-graphics/mesa/mesa_10.5.8.bb
rename to meta/recipes-graphics/mesa/mesa_10.6.3.bb
index 072cde9..8c55064 100644
--- a/meta/recipes-graphics/mesa/mesa_10.5.8.bb
+++ b/meta/recipes-graphics/mesa/mesa_10.6.3.bb
@@ -2,8 +2,8 @@ require ${BPN}.inc
 
 SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/${PV}/mesa-${PV}.tar.xz;
 
-SRC_URI[md5sum] = 5332a3576c5e3a0c3947ee6668dd4157
-SRC_URI[sha256sum] = 
2866b855c5299a4aed066338c77ff6467c389b2c30ada7647be8758663da2b54
+SRC_URI[md5sum] = 553e525d2f20ed48fca8f1ec3176fd83
+SRC_URI[sha256sum] = 
58592e07c350cd2e8969b73fa83048c657a39fe2f13f3b88f5e5818fe2e4676d
 
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
-- 
2.3.5

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

Re: [OE-core] meta/lib/oe/rootfs.py: dont' remove any packages by default

[Nicolas Dechesne]

On Fri, Jul 31, 2015 at 1:12 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
 I am not sure to understand the relationship between runtime package
 management, and adding/removing users? Why would no runtime package
 management, imply no need to add/remove users?

 I guess the underlying assumption is that if you have no package manager, in a
 typical embedded context (if there is such a thing) that implies you won't be
 changing the system after setup.

well, that still sounds like 2 separate 'features'.. i think it might
be a good idea to split them out...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] mesa: upgrade 10.5.8 - 10.6.3

[Nicolas Dechesne]

Tested with X11 :

* xf86-video-freedreno (and w/ XA) on IFC6410 and DragonBoard 410c
* softpipe on DragonBoard 410c
* using meta-qualcomm BSP

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/recipes-graphics/mesa/{mesa-gl_10.5.8.bb = mesa-gl_10.6.3.bb} | 0
 meta/recipes-graphics/mesa/{mesa_10.5.8.bb = mesa_10.6.3.bb}   | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_10.5.8.bb = mesa-gl_10.6.3.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_10.5.8.bb = mesa_10.6.3.bb} (78%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_10.5.8.bb 
b/meta/recipes-graphics/mesa/mesa-gl_10.6.3.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_10.5.8.bb
rename to meta/recipes-graphics/mesa/mesa-gl_10.6.3.bb
diff --git a/meta/recipes-graphics/mesa/mesa_10.5.8.bb 
b/meta/recipes-graphics/mesa/mesa_10.6.3.bb
similarity index 78%
rename from meta/recipes-graphics/mesa/mesa_10.5.8.bb
rename to meta/recipes-graphics/mesa/mesa_10.6.3.bb
index 072cde9..8c55064 100644
--- a/meta/recipes-graphics/mesa/mesa_10.5.8.bb
+++ b/meta/recipes-graphics/mesa/mesa_10.6.3.bb
@@ -2,8 +2,8 @@ require ${BPN}.inc
 
 SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/${PV}/mesa-${PV}.tar.xz;
 
-SRC_URI[md5sum] = 5332a3576c5e3a0c3947ee6668dd4157
-SRC_URI[sha256sum] = 
2866b855c5299a4aed066338c77ff6467c389b2c30ada7647be8758663da2b54
+SRC_URI[md5sum] = 553e525d2f20ed48fca8f1ec3176fd83
+SRC_URI[sha256sum] = 
58592e07c350cd2e8969b73fa83048c657a39fe2f13f3b88f5e5818fe2e4676d
 
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
-- 
2.3.5

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

Re: [OE-core] meta/lib/oe/rootfs.py: dont' remove any packages by default

[Nicolas Dechesne]

On Fri, Jul 31, 2015 at 12:46 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
 I think that we should not remove any pkgs by default, we can add some
 interfaces/ways to let the user decide whether to remove them or any
 other pkgs, for example, add a REMOVE_PACKAGS variable, leave it as NULL
 or only add run-postinsts to it by default.

 There is a reason for these not to be there by default when you don't have
 runtime package management - the assumption is you won't be adding or removing
 any users, thus the binaries that those packages install aren't needed.


I am not sure to understand the relationship between runtime package
management, and adding/removing users? Why would no runtime package
management, imply no need to add/remove users?

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

Re: [OE-core] How to handle mesa customization in BSP layers

[Nicolas Dechesne]

Le 25 oct. 2015 00:00, "Trevor Woerner" <twoer...@gmail.com> a écrit :
>
> On 10/20/15 05:37, Koen Kooi wrote:
> >> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne <
nicolas.deche...@linaro.org> het volgende geschreven:
> >>
> >>
> >> The issue is that mesa is arch specific, not machine specific. So if
> >> you start mixing machines from the same arch, we are getting
> >> unexpected/wrong rebuilds.
> > In this specific case I think we should enable freedreno for
armv7/armv8 in OE-core, but the problem remains for other recipes like this.
>
> Are you suggesting that every armv7 device should have their mesa tuned
> for freedreno and freedreno added to their filesystem? That seems quite
> overly-broad!

No. Only building the driver. It won't be installed unless you add it into
your image.

>
> On the surface[1] it would seem as though the decisions as to how one
> builds mesa and which graphics solution to install is more similar to
> the decision as to which DEFAULTTUNE to use, rather than which
> architecture is involved?
>

DEFAULTTUNE is a generic config that impacts all packages. What Koen
proposed is to change mesa to build more drivers by default.

>
>
>
>
>
>
> [1] which is my way of saying "I don't have the experience of actually
> having done this, unlike you people" ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/7] linux-dtb.inc: fix detection of ending '.dts'

[Nicolas Dechesne]

On Mon, Oct 19, 2015 at 11:03 AM, Stefan Christ  wrote:
> Hmm, the meaning of the code seems to be non obvious. I just looked at sed
> replacement and concluded that it's about the file name ending.
>
> Using the full path to the dtb file is not supported by the code anyway, e.g.
>
>DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
>
> would be wrong.
>
> So the correct solution would check both cases
>
>- full path or only filename and
>- ending is dts or dtb
>
> Correct?


If you look at the commit that introduced this code, e.g. 72980d5b,
you can see that this code was added to support the 'legacy' case
which was the absolute path of the .dts file, or the new case which is
the .dtb file name. e.g.:

==
,[ Original definition ]
| KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx6q-sabresd.dts"
`

Becomes:

,[ New definition ]
| KERNEL_DEVICETREE = "imx6q-sabresd.dtb"
`
==

so the '/dts/' was used to detect the legacy case, and print a warning
in that condition.

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

Re: [OE-core] [PATCH 1/7] linux-dtb.inc: fix detection of ending '.dts'

[Nicolas Dechesne]

On Mon, Oct 19, 2015 at 11:21 AM, Stefan Christ  wrote:
>
> What about my rework patches? I will resend them if they are ok.

i (very) quickly looked at them..
#3, #4, #5 look sane.
#6, #7, i am not sure if this is worth doing this change.. we'll see
what others think about them..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/7] linux-dtb.inc: fix detection of ending '.dts'

[Nicolas Dechesne]

On Mon, Oct 19, 2015 at 10:15 AM, Stefan Christ  wrote:
>
> Device tree files ending with ".dts" are not recognized correctly
> because of unnecessary front slashes.
>
> Signed-off-by: Stefan Christ 
> ---
>  meta/recipes-kernel/linux/linux-dtb.inc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
> b/meta/recipes-kernel/linux/linux-dtb.inc
> index ee3a5e1..db2afb8 100644
> --- a/meta/recipes-kernel/linux/linux-dtb.inc
> +++ b/meta/recipes-kernel/linux/linux-dtb.inc
> @@ -8,7 +8,7 @@ python __anonymous () {
>  do_compile_append() {
> if test -n "${KERNEL_DEVICETREE}"; then
> for DTB in ${KERNEL_DEVICETREE}; do
> -   if echo ${DTB} | grep -q '/dts/'; then
> +   if echo ${DTB} | grep -q 'dts'; then



My understanding is that the '/dts/' was here to catch 'boot/dts/' in
order to detect the absolute path name, not the trailing '.dts'. In
which case this patch might not be appropriate.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] issues with gcc 5 + mesa

[Nicolas Dechesne]

hi,

I am seeing this error on my board when compilng core-image-x11 based image:

root@ifc6410:~# glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
[   50.359341] Alignment trap: not handling instruction f4008a1f at
[]
[   50.364408] Unhandled fault: alignment exception (0x801) at 0x000cd5bc
[   50.371419] pgd = ec024000
[   50.377885] [000cd5bc] *pgd=fb85f835
Bus error

While I initially thought it was something to do with my kernel or
firmware, I just thought about trying a build with GCCVERSION="4.9.3" and
the issue is gone.

I was having this issue as soon as EGL/GLES is being used, and I could get
it with both X11 or Weston/Wayland. This is running on IFC6410 (e.g. an
ARMv7 platform). The same images built for ARMv8 (DragonBoard 410c) work
fine.

I am using Mesa Gallium/freedreno for the GPU. I have tried armv7athf-neon
and armv7at-neon, and both show the same issue.

I would be curious to hear from others using similar platforms , though it
is likely something in mesa/gallium (so possibly in freedreno bits)..
Maybe someone using etnaviv ? Or is anyone building images for qemuarm v7?

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

[OE-core] How to handle mesa customization in BSP layers

[Nicolas Dechesne]

hi there,

in the meta-qcom BSP layer, I need to customize mesa to enable
Gallium/freedreno driver which is not enabled in OE-core by default. I
have been using a bbappend , see [1] so far.

However it was reported by Koen that his is causing issues, at least
in Angstrom, though it's not specific to this distro.. See github
comments on [2].

The issue is that mesa is arch specific, not machine specific. So if
you start mixing machines from the same arch, we are getting
unexpected/wrong rebuilds.

How am I supposed to handle that properly in a BSP layer? I don't
think that enabling the freedreno driver should be a distro config, am
i right?

thanks
nico

[1] 
https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_10.%25.bbappend
[2] 
https://github.com/ndechesne/meta-qcom/commit/dc00771aaba1051a3c679dd8f782089b499cbdbb
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Too late for mesa upgrade before jethro?

[Nicolas Dechesne]

Hi,

I am testing right now a patch to upgrade mesa from 10.6.3 to 10.6.9, is it
too late for including it in jethro?

I should be able to send it on Monday.. If it's too late, i will switch to
mesa 11 directly.

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

[OE-core] [RFC PATCH 2/2] image_types.bbclass: add support for fastboot image type

[Nicolas Dechesne]

Fastboot images are images that can be flashed using the fastboot protocol
implemented in many popular bootloader for SBCs or even real world products
(such as Android phones and tablets).

This image type was implemented in meta-smartphone, and is being moved in
oe-core.

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 meta/classes/image_types.bbclass | 16 
 1 file changed, 16 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 8547574..4c53dc9 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -156,6 +156,19 @@ IMAGE_CMD_ubifs = mkfs.ubifs -r ${IMAGE_ROOTFS} -o 
${DEPLOY_DIR_IMAGE}/${IMAGE_
 
 EXTRA_IMAGECMD = 
 
+FASTBOOT_PARTITION_SIZE ?= 16384
+
+IMAGE_CMD_ext4.fastboot () {
+   if [ ${ROOTFS_SIZE} -lt ${FASTBOOT_PARTITION_SIZE} ]; then
+   make_ext4fs -l `expr ${FASTBOOT_PARTITION_SIZE} \* 1024` \
+   ${EXTRA_IMAGECMD} \
+   ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext4.fastboot \
+   ${IMAGE_ROOTFS}
+   else
+   bbfatal Rootfs is too small for partition (Rootfs Actual Size: 
${ROOTFS_SIZE}, Partition size: ${FASTBOOT_PARTITION_SIZE})
+   fi
+}
+
 inherit siteinfo
 JFFS2_ENDIANNESS ?= ${@base_conditional('SITEINFO_ENDIANNESS', 'le', '-l', 
'-b', d)}
 JFFS2_ERASEBLOCK ?= 0x4
@@ -167,6 +180,7 @@ EXTRA_IMAGECMD_ext3 ?= -i 4096
 EXTRA_IMAGECMD_ext4 ?= -i 4096
 EXTRA_IMAGECMD_btrfs ?= 
 EXTRA_IMAGECMD_elf ?= 
+EXTRA_IMAGECMD_ext4.fastboot ?= -s -b 4096
 
 IMAGE_DEPENDS = 
 IMAGE_DEPENDS_jffs2 = mtd-utils-native
@@ -182,6 +196,7 @@ IMAGE_DEPENDS_elf = virtual/kernel mkelfimage-native
 IMAGE_DEPENDS_ubi = mtd-utils-native
 IMAGE_DEPENDS_ubifs = mtd-utils-native
 IMAGE_DEPENDS_multiubi = mtd-utils-native
+IMAGE_DEPENDS_ext4.fastboot = android-tools-native
 
 # This variable is available to request which values are suitable for 
IMAGE_FSTYPES
 IMAGE_TYPES =  \
@@ -201,6 +216,7 @@ IMAGE_TYPES =  \
 vdi \
 qcow2 \
 elf \
+ext4.fastboot \
 
 
 COMPRESSIONTYPES = gz bz2 lzma xz lz4 sum
-- 
2.3.5

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

[OE-core] [RFC PATCH 1/2] android-tools: import android-tools from meta-smartphone into oe-core

[Nicolas Dechesne]

The following changes were done to trim down the recipe size:
* removed adbd support
* removed android-tools-conf

The main idea is to keep only what is strictly needed for make_ext4fs tool.

Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org
---
 .../android-tools/disable-selinux-support.patch| 137 +
 .../android-tools/reboot-syscall.patch |  25 
 .../android-tools/remove-libselinux.patch  |  13 ++
 .../android-tools/android-tools_4.2.2.bb   |  51 
 4 files changed, 226 insertions(+)
 create mode 100644 
meta/recipes-devtools/android-tools/android-tools/disable-selinux-support.patch
 create mode 100644 
meta/recipes-devtools/android-tools/android-tools/reboot-syscall.patch
 create mode 100644 
meta/recipes-devtools/android-tools/android-tools/remove-libselinux.patch
 create mode 100644 meta/recipes-devtools/android-tools/android-tools_4.2.2.bb

diff --git 
a/meta/recipes-devtools/android-tools/android-tools/disable-selinux-support.patch
 
b/meta/recipes-devtools/android-tools/android-tools/disable-selinux-support.patch
new file mode 100644
index 000..738f575
--- /dev/null
+++ 
b/meta/recipes-devtools/android-tools/android-tools/disable-selinux-support.patch
@@ -0,0 +1,137 @@
+diff --git a/extras/ext4_utils/make_ext4fs.c b/extras/ext4_utils/make_ext4fs.c
+index b2d1426..94e92d6 100644
+--- a/extras/ext4_utils/make_ext4fs.c
 b/extras/ext4_utils/make_ext4fs.c
+@@ -59,9 +59,11 @@
+ 
+ #else
+ 
++#if 0
+ #include selinux/selinux.h
+ #include selinux/label.h
+ #include selinux/android.h
++#endif
+ 
+ #define O_BINARY 0
+ 
+@@ -178,6 +180,7 @@ static u32 build_directory_structure(const char 
*full_path, const char *dir_path
+   error(can't set android permissions - built without 
android support);
+ #endif
+   }
++#if 0
+ #ifndef USE_MINGW
+   if (sehnd) {
+   if (selabel_lookup(sehnd, dentries[i].secon, 
dentries[i].path, stat.st_mode)  0) {
+@@ -188,6 +191,7 @@ static u32 build_directory_structure(const char 
*full_path, const char *dir_path
+   printf(Labeling %s as %s\n, dentries[i].path, 
dentries[i].secon);
+   }
+ #endif
++#endif
+ 
+   if (S_ISREG(stat.st_mode)) {
+   dentries[i].file_type = EXT4_FT_REG_FILE;
+@@ -229,10 +233,12 @@ static u32 build_directory_structure(const char 
*full_path, const char *dir_path
+   dentries[0].file_type = EXT4_FT_DIR;
+   dentries[0].uid = 0;
+   dentries[0].gid = 0;
++#if 0
+   if (sehnd) {
+   if (selabel_lookup(sehnd, dentries[0].secon, 
dentries[0].path, dentries[0].mode)  0)
+   error(cannot lookup security context for %s, 
dentries[0].path);
+   }
++#endif
+   entries++;
+   dirs++;
+   }
+@@ -270,9 +276,11 @@ static u32 build_directory_structure(const char 
*full_path, const char *dir_path
+   dentries[i].mtime);
+   if (ret)
+   error(failed to set permissions on %s\n, 
dentries[i].path);
++#if 0
+   ret = inode_set_selinux(entry_inode, dentries[i].secon);
+   if (ret)
+   error(failed to set SELinux context on %s\n, 
dentries[i].path);
++#endif
+ 
+   free(dentries[i].path);
+   free(dentries[i].full_path);
+@@ -562,6 +570,7 @@ int make_ext4fs_internal(int fd, const char *_directory,
+   root_mode = S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH;
+   inode_set_permissions(root_inode_num, root_mode, 0, 0, 0);
+ 
++#if 0
+ #ifndef USE_MINGW
+   if (sehnd) {
+   char *secontext = NULL;
+@@ -578,6 +587,7 @@ int make_ext4fs_internal(int fd, const char *_directory,
+   freecon(secontext);
+   }
+ #endif
++#endif
+ 
+   ext4_update_free();
+ 
+diff --git a/extras/ext4_utils/make_ext4fs_main.c 
b/extras/ext4_utils/make_ext4fs_main.c
+index b6c740d..ce31764 100644
+--- a/extras/ext4_utils/make_ext4fs_main.c
 b/extras/ext4_utils/make_ext4fs_main.c
+@@ -29,6 +29,7 @@
+ #include private/android_filesystem_config.h
+ #endif
+ 
++#if 0
+ #ifndef USE_MINGW
+ #include selinux/selinux.h
+ #include selinux/label.h
+@@ -36,6 +37,7 @@
+ #else
+ struct selabel_handle;
+ #endif
++#endif
+ 
+ #include make_ext4fs.h
+ #include ext4_utils.h
+@@ -72,9 +74,11 @@ int main(int argc, char **argv)
+   int exitcode;
+   int verbose = 0;
+   struct selabel_handle *sehnd = NULL;
++#if 0
+ #ifndef USE_MINGW
+   struct selinux_opt seopts[] = { { SELABEL_OPT_PATH,  } };
+ #endif
++#endif
+ 
+   while ((opt = getopt(argc, argv, l:j:b:g:i:I:L:a:S:fwzJsctv)) != -1) {
+   switch (opt) {
+@@ -131,6 +135,7 @@ int main(int argc, char **argv)
+   fprintf(stderr, Warning: -t (initialize inode tables) 
is deprecated\n

[OE-core] [RFC PATCH 0/2] Add support for fastboot images

[Nicolas Dechesne]

Some (many?) embedded SBCs and Android devices (such as Nexus devices) come with
Android bootloaders/BSP by default, and often the fastboot protocol may be even
the only way we can flash the device. So this RFC series is an attempt to be
able to easily use such devices while building OE images. I believe the use case
is common enough so that we can have this feature in OE Core.

First we import the android-tools recipe from meta-smartphone. That provides
make_ext4fs utility that can be used to create sparse images suitable for
fastboot. The original android-tools recipe had support for adb (and adbd) which
has been removed during the import since it's huge, and not strictly needed for
building the images. Alternatively I found a standalone fork for make_ext4fs at
[1], from the OpenWrt project, but it is quite new, and i have not tested it
yet. I would appreciate any feedback on that.

Then we add a new image type called ext4.fastboot that uses make_ext4fs to
create the appropriate images. A specific variable can be used to set the image
size which defaults to 16MB.

These patches have been tested on various devices such as IFC6410, DragonBoard
410c, and a few other Qualcomm based devices.

I understand these patches would break meta-smartphone, but this is an RFC, so
let's discuss how to best handle that.

[1] http://git.openwrt.org/?p=project/make_ext4fs.git;a=summary

Nicolas Dechesne (2):
  android-tools: import android-tools from meta-smartphone into oe-core
  image_types.bbclass: add support for fastboot image type

 meta/classes/image_types.bbclass   |  16 +++
 .../android-tools/disable-selinux-support.patch| 137 +
 .../android-tools/reboot-syscall.patch |  25 
 .../android-tools/remove-libselinux.patch  |  13 ++
 .../android-tools/android-tools_4.2.2.bb   |  51 
 5 files changed, 242 insertions(+)
 create mode 100644 
meta/recipes-devtools/android-tools/android-tools/disable-selinux-support.patch
 create mode 100644 
meta/recipes-devtools/android-tools/android-tools/reboot-syscall.patch
 create mode 100644 
meta/recipes-devtools/android-tools/android-tools/remove-libselinux.patch
 create mode 100644 meta/recipes-devtools/android-tools/android-tools_4.2.2.bb

-- 
2.3.5

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