date:20161205

Re: [OE-core] [PATCH 0/4] Load devtool and reciptool plugins in a well-defined manner

2016-12-05 Thread Ola x Nilsson

Ping?

-- 
Ola x Nilsson

> -Original Message-
> From: Ola x Nilsson [mailto:ol...@axis.com]
> Sent: den 25 oktober 2016 13:04
> To: Ola x Nilsson; openembedded-core@lists.openembedded.org
> Subject: [PATCH 0/4] Load devtool and reciptool plugins in a well-defined
> manner
> 
> From: Ola x Nilsson 
> 
> Make devtool and recipetool load plugins in a well-defined and expected
> manner.
> 
> devtool and reciptool search for pluings first in scripts/lib/ and then 
> in
> BBPATH.  Each found plugin is loaded, which means that any plugin found
> later in BBPATH shadows previously loaded plugins.
> plugin_init is loaded for all plugins, no matter whether they are later
> replaced.  register_plugin is called once for each time a plugin with a 
> certain
> name is found, but it is always called on the last loaded plugin.
> 
> Change the scriptutils.load_plugins function to never load a plugin file if 
> one
> with the same filename has already been loaded.  This means that the first
> found plugin wins.
> 
> Change the load order to first search BBPATH and then scripts/lib/tools.  This
> means that plugins in scripts/lib/ can be shadowed by plugins in layers.
> 
> Ola x Nilsson (4):
>   devtool: selftest: add test for devtool plugin loading
>   recipetool: selftest: Add test for recipetool plugin loading
>   devtool: Load plugins in a well defined order
>   recipetool: Load plugins in a well defined order
> 
>  meta-selftest/lib/devtool/bbpath.py| 44
> ++
>  meta-selftest/lib/recipetool/bbpath.py | 41
> +++
>  meta/lib/oeqa/selftest/devtool.py  | 43
> +
>  meta/lib/oeqa/selftest/recipetool.py   | 44
> ++
>  scripts/devtool|  3 ++-
>  scripts/lib/scriptutils.py |  8 +--
>  scripts/recipetool |  4 ++--
>  7 files changed, 182 insertions(+), 5 deletions(-)  create mode 100644 meta-
> selftest/lib/devtool/bbpath.py
>  create mode 100644 meta-selftest/lib/recipetool/bbpath.py
> 
> --
> 2.1.4

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

Re: [OE-core] [PATCH 1/2] diffutils: do_configure: fix "Argument list too long"

2016-12-05 Thread Khem Raj


> On Dec 5, 2016, at 6:11 PM, Robert Yang  wrote:
> 
> 
> 
> On 12/06/2016 02:23 AM, Khem Raj wrote:
>> On Mon, Dec 5, 2016 at 6:54 AM, Robert Yang  
>> wrote:
>>> Fixed when len(TMPDIR) =  410:
>>> aclocal: error: cannot open echo [snip]: Argument list too long
>>> 
>>> This is becuase it has a lot of m4 files, use relative path for them
>>> can fix the problem.
>>> 
>>> It doesn't happen when MACHINE="qemux86", I think it is because
>>> intel-x86-64 is longer than qemux86.
>>> 
>>> Signed-off-by: Robert Yang 
>>> ---
>>> meta/recipes-extended/diffutils/diffutils_3.4.bb | 3 +++
>>> 1 file changed, 3 insertions(+)
>>> 
>>> diff --git a/meta/recipes-extended/diffutils/diffutils_3.4.bb 
>>> b/meta/recipes-extended/diffutils/diffutils_3.4.bb
>>> index cb7092b..be280ec 100644
>>> --- a/meta/recipes-extended/diffutils/diffutils_3.4.bb
>>> +++ b/meta/recipes-extended/diffutils/diffutils_3.4.bb
>>> @@ -10,6 +10,9 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.xz 
>>> \
>>> 
>>> EXTRA_OECONF += "--without-libsigsegv-prefix"
>>> 
>>> +# Fix "Argument list too long" error when len(TMPDIR) = 410
>>> +acpaths = "-I ./m4"
>> 
>> it looks ok if this work ok with externalsrc
> 
> Hi Khem,
> 
> What did mean about externalsrc, please ? Did you mean when B != S?

yeah, 

> If yes, it works well since it is for aclocal, which always runs in S.

seems to be the case. Then we should be fine.

> We have already such a fix in several recipes.
> 
> meta/recipes-extended/tar/tar.inc:acpaths = "-I ./m4"
> meta/recipes-extended/wget/wget.inc:acpaths = "-I ./m4"
> meta/recipes-core/coreutils/coreutils_6.9.bb:acpaths = "-I ./m4"
> meta/recipes-core/coreutils/coreutils_8.25.bb:acpaths = "-I ./m4"
> 
> // Robert
> 
>> 
>>> +
>>> do_configure_prepend () {
>>># Need to remove gettext macros with weird mix of versions
>>>for i in codeset.m4 gettext_gl.m4 intlmacosx.m4 inttypes-pri.m4 
>>> lib-ld_gl.m4 lib-prefix_gl.m4 po_gl.m4 ssize_t.m4 wchar_t.m4 wint_t.m4; do
>>> --
>>> 2.9.0
>>> 
>>> --
>>> ___
>>> 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

[OE-core] oetest.py construction of pkgmanifest is probably wrong

2016-12-05 Thread Slater, Joseph

This variable is a dictionary with entries based on package, but for multillib 
a package might exist in only some variants.  Perhaps
each entry should be a dictionary of multilib variants?

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

Re: [OE-core] [PATCH 1/2] diffutils: do_configure: fix "Argument list too long"

2016-12-05 Thread Robert Yang




On 12/06/2016 02:23 AM, Khem Raj wrote:

On Mon, Dec 5, 2016 at 6:54 AM, Robert Yang  wrote:

Fixed when len(TMPDIR) =  410:
aclocal: error: cannot open echo [snip]: Argument list too long

This is becuase it has a lot of m4 files, use relative path for them
can fix the problem.

It doesn't happen when MACHINE="qemux86", I think it is because
intel-x86-64 is longer than qemux86.

Signed-off-by: Robert Yang 
---
 meta/recipes-extended/diffutils/diffutils_3.4.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/diffutils/diffutils_3.4.bb 
b/meta/recipes-extended/diffutils/diffutils_3.4.bb
index cb7092b..be280ec 100644
--- a/meta/recipes-extended/diffutils/diffutils_3.4.bb
+++ b/meta/recipes-extended/diffutils/diffutils_3.4.bb
@@ -10,6 +10,9 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.xz \

 EXTRA_OECONF += "--without-libsigsegv-prefix"

+# Fix "Argument list too long" error when len(TMPDIR) = 410
+acpaths = "-I ./m4"


it looks ok if this work ok with externalsrc


Hi Khem,

What did mean about externalsrc, please ? Did you mean when B != S?
If yes, it works well since it is for aclocal, which always runs in S.
We have already such a fix in several recipes.

meta/recipes-extended/tar/tar.inc:acpaths = "-I ./m4"
meta/recipes-extended/wget/wget.inc:acpaths = "-I ./m4"
meta/recipes-core/coreutils/coreutils_6.9.bb:acpaths = "-I ./m4"
meta/recipes-core/coreutils/coreutils_8.25.bb:acpaths = "-I ./m4"

// Robert




+
 do_configure_prepend () {
# Need to remove gettext macros with weird mix of versions
for i in codeset.m4 gettext_gl.m4 intlmacosx.m4 inttypes-pri.m4 
lib-ld_gl.m4 lib-prefix_gl.m4 po_gl.m4 ssize_t.m4 wchar_t.m4 wint_t.m4; do
--
2.9.0

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



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

Re: [OE-core] [PATCH 3/5] libsdl2: add EXTRA_OECONF[vardepsexclude] = "MACHINE"

2016-12-05 Thread Khem Raj

There probably is no need to use this additional variable. We can just use
PKG_CONFIG_SYSROOT

On Dec 5, 2016 4:19 PM, "Andreas Müller" 
wrote:

> fixes Martin's MACHINE checksum test [1]
>
> [1] http://lists.openembedded.org/pipermail/openembedded-core/
> 2016-November/129464.html
>
> Signed-off-by: Andreas Müller 
> ---
>  meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> index ac7312b..b104a43 100644
> --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
> @@ -34,6 +34,7 @@ EXTRA_OECONF = "--disable-oss --disable-esd
> --disable-arts \
>  --enable-sdl-dlopen \
>  --disable-rpath \
>  WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}"
> +EXTRA_OECONF[vardepsexclude] = "MACHINE"
>
>  # opengl packageconfig factored out to make it easy for distros
>  # and BSP layers to pick either (desktop) opengl, gles2, or no GL
> --
> 2.5.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

[OE-core] [PATCH 1/5] mesa: update to 13.0.2

2016-12-05 Thread Andreas Müller

Signed-off-by: Andreas Müller 
---
 meta/recipes-graphics/mesa/{mesa-gl_13.0.1.bb => mesa-gl_13.0.2.bb} | 0
 meta/recipes-graphics/mesa/{mesa_13.0.1.bb => mesa_13.0.2.bb}   | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_13.0.1.bb => mesa-gl_13.0.2.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_13.0.1.bb => mesa_13.0.2.bb} (91%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_13.0.1.bb 
b/meta/recipes-graphics/mesa/mesa-gl_13.0.2.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_13.0.1.bb
rename to meta/recipes-graphics/mesa/mesa-gl_13.0.2.bb
diff --git a/meta/recipes-graphics/mesa/mesa_13.0.1.bb 
b/meta/recipes-graphics/mesa/mesa_13.0.2.bb
similarity index 91%
rename from meta/recipes-graphics/mesa/mesa_13.0.1.bb
rename to meta/recipes-graphics/mesa/mesa_13.0.2.bb
index 7c9a4b7..ffdd5b4 100644
--- a/meta/recipes-graphics/mesa/mesa_13.0.1.bb
+++ b/meta/recipes-graphics/mesa/mesa_13.0.2.bb
@@ -17,8 +17,8 @@ SRC_URI = 
"ftp://ftp.freedesktop.org/pub/mesa/${PV}/mesa-${PV}.tar.xz \

file://0012-vc4-Try-compiling-our-FSes-in-multithreaded-mode-on-.patch \
 "
 
-SRC_URI[md5sum] = "72b7f4d0c2407f367484abd201cb8276"
-SRC_URI[sha256sum] = 
"71962fb2bf77d33b0ad4a565b490dbbeaf4619099c6d9722f04a73187957a731"
+SRC_URI[md5sum] = "9442c2dee914cde3d1f090371ab04113"
+SRC_URI[sha256sum] = 
"a6ed622645f4ed61da418bf65adde5bcc4bb79023c36ba7d6b45b389da4416d5"
 
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
-- 
2.5.5

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

[OE-core] [PATCH 4/5] libsdl2: add wayland--protocols to to depends of PACKAGECONFIG[wayland]

2016-12-05 Thread Andreas Müller

Signed-off-by: Andreas Müller 
---
 meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index b104a43..bb75316 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -54,7 +54,7 @@ PACKAGECONFIG[gles2]  = 
"--enable-video-opengles,--disable-video-opengles,vi
 PACKAGECONFIG[opengl] = 
"--enable-video-opengl,--disable-video-opengl,virtual/libgl"
 PACKAGECONFIG[pulseaudio] = 
"--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
 PACKAGECONFIG[tslib]  = "--enable-input-tslib,--disable-input-tslib,tslib"
-PACKAGECONFIG[wayland]= 
"--enable-video-wayland,--disable-video-wayland,wayland libxkbcommon"
+PACKAGECONFIG[wayland]= 
"--enable-video-wayland,--disable-video-wayland,wayland wayland-protocols 
libxkbcommon"
 PACKAGECONFIG[x11]= 
"--enable-video-x11,--disable-video-x11,virtual/libx11 libxext libxrandr 
libxrender"
 
 EXTRA_AUTORECONF += "--include=acinclude --exclude=autoheader"
-- 
2.5.5

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

[OE-core] [PATCH 3/5] libsdl2: add EXTRA_OECONF[vardepsexclude] = "MACHINE"

2016-12-05 Thread Andreas Müller

fixes Martin's MACHINE checksum test [1]

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129464.html

Signed-off-by: Andreas Müller 
---
 meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index ac7312b..b104a43 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -34,6 +34,7 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
 --enable-sdl-dlopen \
 --disable-rpath \
 WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}"
+EXTRA_OECONF[vardepsexclude] = "MACHINE"
 
 # opengl packageconfig factored out to make it easy for distros
 # and BSP layers to pick either (desktop) opengl, gles2, or no GL
-- 
2.5.5

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

[OE-core] [PATCH 5/5] libsdl2: fix build on wayland(-dev)less hosts

2016-12-05 Thread Andreas Müller

* add sysroot prefix to wayland core protocols
* do not use pkg-config to find wayland-scanner

Signed-off-by: Andreas Müller 
---
 ...-sysroot-path-so-that-make-finds-our-wayl.patch |  8 +++---
 ...void-finding-build-host-s-wayland-scanner.patch | 31 ++
 meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb |  1 +
 3 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch

diff --git 
a/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
 
b/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
index d042430..efc8418 100644
--- 
a/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
+++ 
b/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
@@ -11,18 +11,20 @@ Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Andreas Müller 
 ---
- configure.in | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
+ configure.in | 4 +-
+ 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/configure.in b/configure.in
 index 726ded3..3376600 100644
 --- a/configure.in
 +++ b/configure.in
 @@ -1206,7 +1206,7 @@ AC_HELP_STRING([--enable-video-wayland-qt-touch], 
[QtWayland server support for
+ WAYLAND_CFLAGS=`$PKG_CONFIG --cflags wayland-client 
wayland-egl wayland-cursor xkbcommon`
  WAYLAND_LIBS=`$PKG_CONFIG --libs wayland-client wayland-egl 
wayland-cursor xkbcommon`
  WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`
- WAYLAND_CORE_PROTOCOL_DIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-client`
+-WAYLAND_CORE_PROTOCOL_DIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-client`
 -WAYLAND_PROTOCOLS_DIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
++
WAYLAND_CORE_PROTOCOL_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG 
--variable=pkgdatadir wayland-client`
 +
WAYLAND_PROTOCOLS_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG 
--variable=pkgdatadir wayland-protocols`
  video_wayland=yes
  fi
diff --git 
a/meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch
 
b/meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch
new file mode 100644
index 000..7837315
--- /dev/null
+++ 
b/meta/recipes-graphics/libsdl2/libsdl2/0002-Avoid-finding-build-host-s-wayland-scanner.patch
@@ -0,0 +1,31 @@
+From ae879091cf65cb70293b375ec7e61ed12a96d8a7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Fri, 2 Dec 2016 09:39:25 +0100
+Subject: [PATCH] Avoid finding build host's wayland-scanner
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Andreas Müller 
+---
+ configure.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.in b/configure.in
+index 3376600..2aa6ed4 100644
+--- a/configure.in
 b/configure.in
+@@ -1204,7 +1204,7 @@ AC_HELP_STRING([--enable-video-wayland-qt-touch], 
[QtWayland server support for
+ if $PKG_CONFIG --exists wayland-client wayland-scanner 
wayland-protocols wayland-egl wayland-cursor egl xkbcommon ; then
+ WAYLAND_CFLAGS=`$PKG_CONFIG --cflags wayland-client 
wayland-egl wayland-cursor xkbcommon`
+ WAYLAND_LIBS=`$PKG_CONFIG --libs wayland-client wayland-egl 
wayland-cursor xkbcommon`
+-WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`
++AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+ 
WAYLAND_CORE_PROTOCOL_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG 
--variable=pkgdatadir wayland-client`
+ 
WAYLAND_PROTOCOLS_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG 
--variable=pkgdatadir wayland-protocols`
+ video_wayland=yes
+-- 
+2.7.4
+
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index bb75316..606e6fb 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -18,6 +18,7 @@ SRC_URI = " \
 http://www.libsdl.org/release/SDL2-${PV}.tar.gz \
 file://linkage.patch \
 file://0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch \
+file://0002-Avoid-finding-build-host-s-wayland-scanner.patch \
 "
 
 S = "${WORKDIR}/SDL2-${PV}"
-- 
2.5.5

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

[OE-core] [PATCH 2/5] libdrm: update to 2.4.74

2016-12-05 Thread Andreas Müller

Signed-off-by: Andreas Müller 
---
 meta/recipes-graphics/drm/{libdrm_2.4.73.bb => libdrm_2.4.74.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/drm/{libdrm_2.4.73.bb => libdrm_2.4.74.bb} (93%)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.73.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.74.bb
similarity index 93%
rename from meta/recipes-graphics/drm/libdrm_2.4.73.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.74.bb
index 3315014..c67d356 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.73.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.74.bb
@@ -16,8 +16,8 @@ SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \

file://0001-configure.ac-Allow-explicit-enabling-of-cunit-tests.patch \
   "
 
-SRC_URI[md5sum] = "bc1cee09cde72ffe3b952e8f50ccdaa8"
-SRC_URI[sha256sum] = 
"96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d"
+SRC_URI[md5sum] = "31964aa15bdea1a40c5941d4ce0962ee"
+SRC_URI[sha256sum] = 
"d80dd5a76c401f4c8756dcccd999c63d7e0a3bad258d96a829055cfd86ef840b"
 
 inherit autotools pkgconfig manpages
 
-- 
2.5.5

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

Re: [OE-core] [PATCH] gdb-cross-canadian: Depend on nativesdk-python3-misc

2016-12-05 Thread George McCollister

On Mon, Dec 5, 2016 at 3:21 PM, Burton, Ross  wrote:
>
> On 5 December 2016 at 16:38, George McCollister
>  wrote:
>>
>> Add missing dependency on nativesdk-python3-misc so the imp Python
>> module is installed.
>
>
> So imp is the Python-facing API for 'import', and python-misc is a grab-bag
> of random stuff.  Should imp be moved to be in python3-importlib (where its
> replacement already lives) or moved into python3-core?

importlib is the replacement for imp (it's deprecated since version
3.4) so this sounds reasonable to me. Shall I send a patch to add
imp.py to python3-importlib and another to add python3-importlib to
PACKAGECONFIG[python] in gdb-cross-canadian.inc?

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

Re: [OE-core] [oe-core][PATCH] webkitgtk: drop patch 0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch

2016-12-05 Thread Khem Raj

Carlos

webkitgtk fails now e.g. see

http://errors.yoctoproject.org/Errors/Details/111221/ 


fatal error: 'stdlib.h' file not found
#include_next 

This is when building with clang, I think its too early to drop this patch. 

> On Nov 8, 2016, at 9:52 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
> * This patch is not longer needed. Upstream has fixed this issue in:
>   https://trac.webkit.org/changeset/205672 which is already included
>   in WebKitGTK+ >= 2.14.0
> 
> Signed-off-by: Carlos Alberto Lopez Perez 
> ---
> ...bKitMacros-Append-to-I-and-not-to-isystem.patch | 181 -
> meta/recipes-sato/webkit/webkitgtk_2.14.1.bb   |   1 -
> 2 files changed, 182 deletions(-)
> delete mode 100644 
> meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
> 
> diff --git 
> a/meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
>  
> b/meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
> deleted file mode 100644
> index ef209c8..000
> --- 
> a/meta/recipes-sato/webkit/files/0001-WebKitMacros-Append-to-I-and-not-to-isystem.patch
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -From 20ee11dd188e1538f8cdd17a289dc6f9c63a011e Mon Sep 17 00:00:00 2001
> -From: Khem Raj 
> -Date: Sun, 17 Apr 2016 12:35:41 -0700
> -Subject: [PATCH] WebKitMacros: Append to -I and not to -isystem
> -
> -gcc-6 has now introduced stdlib.h in libstdc++ for better
> -compliance and its including the C library stdlib.h using
> -include_next which is sensitive to order of system header
> -include paths. Its infact better to not tinker with the
> -system header include paths at all. Since adding /usr/include
> -to -system is redundant and compiler knows about it moreover
> -now with gcc6 it interferes with compiler's functioning
> -and ends up with compile errors e.g.
> -
> -/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such file or 
> directory
> -
> -Signed-off-by: Khem Raj 
> -Upstream-Status: Pending
> 
> - Source/JavaScriptCore/shell/CMakeLists.txt | 2 +-
> - Source/WebCore/PlatformGTK.cmake   | 6 +++---
> - Source/WebKit2/PlatformGTK.cmake   | 2 +-
> - Source/cmake/WebKitMacros.cmake| 2 +-
> - Tools/DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt | 2 +-
> - Tools/ImageDiff/CMakeLists.txt | 2 +-
> - Tools/MiniBrowser/gtk/CMakeLists.txt   | 2 +-
> - Tools/TestWebKitAPI/PlatformGTK.cmake  | 2 +-
> - Tools/TestWebKitAPI/Tests/WebKit2Gtk/CMakeLists.txt| 2 +-
> - Tools/WebKitTestRunner/CMakeLists.txt  | 2 +-
> - 10 files changed, 12 insertions(+), 12 deletions(-)
> -
> -diff --git a/Source/JavaScriptCore/shell/CMakeLists.txt 
> b/Source/JavaScriptCore/shell/CMakeLists.txt
> -index 155c797..80fe22b 100644
>  a/Source/JavaScriptCore/shell/CMakeLists.txt
> -+++ b/Source/JavaScriptCore/shell/CMakeLists.txt
> -@@ -20,7 +20,7 @@ WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS()
> - 
> - WEBKIT_WRAP_SOURCELIST(${JSC_SOURCES})
> - include_directories(./ ${JavaScriptCore_INCLUDE_DIRECTORIES})
> --include_directories(SYSTEM ${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})
> -+include_directories(${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})
> - add_executable(jsc ${JSC_SOURCES})
> - target_link_libraries(jsc ${JSC_LIBRARIES})
> - 
> -diff --git a/Source/WebCore/PlatformGTK.cmake 
> b/Source/WebCore/PlatformGTK.cmake
> -index 567bd79..1fabea8 100644
>  a/Source/WebCore/PlatformGTK.cmake
> -+++ b/Source/WebCore/PlatformGTK.cmake
> -@@ -340,7 +340,7 @@ if (ENABLE_PLUGIN_PROCESS_GTK2)
> - ${GTK2_INCLUDE_DIRS}
> - ${GDK2_INCLUDE_DIRS}
> - )
> --target_include_directories(WebCorePlatformGTK2 SYSTEM PRIVATE
> -+target_include_directories(WebCorePlatformGTK2 PRIVATE
> - ${WebCore_SYSTEM_INCLUDE_DIRECTORIES}
> - )
> - target_link_libraries(WebCorePlatformGTK2
> -@@ -365,7 +365,7 @@ WEBKIT_SET_EXTRA_COMPILER_FLAGS(WebCorePlatformGTK)
> - target_include_directories(WebCorePlatformGTK PRIVATE
> - ${WebCore_INCLUDE_DIRECTORIES}
> - )
> --target_include_directories(WebCorePlatformGTK SYSTEM PRIVATE
> -+target_include_directories(WebCorePlatformGTK PRIVATE
> - ${WebCore_SYSTEM_INCLUDE_DIRECTORIES}
> - ${GTK_INCLUDE_DIRS}
> - ${GDK_INCLUDE_DIRS}
> -@@ -383,7 +383,7 @@ include_directories(
> - "${DERIVED_SOURCES_GOBJECT_DOM_BINDINGS_DIR}"
> - )
> - 
> --include_directories(SYSTEM
> -+include_directories(
> - ${WebCore_SYSTEM_INCLUDE_DIRECTORIES}
> - )
> - 
> -diff --git a/Source/WebKit2/PlatformGTK.cmake 
> b/Source/WebKit2/PlatformGTK.cmake
> -index e4805a4..c57df5d 100644
>  a/Source/WebKit2/PlatformGTK.cmake
> -+++ b/Source/WebKit2/PlatformGTK.cmake
> -@@ -822,7 +822,7 @@ if (ENABLE_PLUGIN_PROCESS_GTK2)
> - target_include_directories(WebKitPluginProcess2 PRIVATE

Re: [OE-core] [PATCH] run-postinsts: Print message before running deferred postinst scripts

2016-12-05 Thread Burton, Ross

On 5 December 2016 at 21:48, Haris Okanovic  wrote:

> Opkg can defer running postinst scripts to first boot, which can take
> a while on some systems. The output of `opkg configure` (or whatever pm
> is used) is redirected to a file when logging is enabled
> (I.e. $POSTINST_LOGGING == 1), making the machine appear hung during
> this process. This change simply prints a wait message on the console
> to inform the user of this potentially long and silent operation so
> that they do not mistakenly reboot their machine.
>

This isn't opkg specific, all backends can do it.


> Why not simply `tee` the output instead?
> Tee might be provided by BusyBox in some distros, which may need to run
> update-alternatives in the very postinst scripts being executed by this
> process. It's therefore not safe to assume Tee (or any other packaged
> util) is available until the configure process finishes.
>

Are the alternatives not configured at rootfs time, so it should be fine to
run tee?  (as if tee isn't safe, then neither is sed).

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

[OE-core] [PATCH] connman: Simplify and fix packaging of VPN plug-ins

2016-12-05 Thread Andreas Oberritter

- Use simple static packaging.
- Move VPN runtime dependencies from connman to the individual plug-ins.
- Create a connmann-ppp package containing libppp-plugin.so, which is
  a shared library needed by l2tp and pptp plug-ins.
- Let connman suggest VPN packages instead of recommending them, so they
  don't get installed by default.
- Remove unknown configure options (--with-pptp --with-l2tp)

Signed-off-by: Andreas Oberritter 
---
 v2: Made dependencies from meta-networking conditional. Now the reported
 errors should appear only if meta-network is not available and a
 packageconfig option related to VPN was enabled.

 Note: I can't build-test it right now, because python3-native has weird
   conflicts populating sysroot. But this patch doesn't cause parse
   errors, so I guess syntax is fine.

 meta/recipes-connectivity/connman/connman.inc | 95 +--
 1 file changed, 32 insertions(+), 63 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman.inc 
b/meta/recipes-connectivity/connman/connman.inc
index 35a7eed..671d533 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -46,24 +46,17 @@ PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, 
wpa-supplicant, wpa-suppli
 PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}, 
${BLUEZ}"
 PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono, ofono"
 PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
-PACKAGECONFIG[openvpn] = "--enable-openvpn 
--with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
-PACKAGECONFIG[vpnc] = "--enable-vpnc 
--with-vpnc=${sbindir}/vpnc,--disable-vpnc,,vpnc"
-PACKAGECONFIG[l2tp] = "--enable-l2tp 
--with-l2tp=${sbindir}/xl2tpd,--disable-l2tp,,xl2tpd"
-PACKAGECONFIG[pptp] = "--enable-pptp 
--with-pptp=${sbindir}/pptp,--disable-pptp,,pptp-linux"
+PACKAGECONFIG[openvpn] = "--enable-openvpn 
--with-openvpn=${sbindir}/openvpn,--disable-openvpn"
+PACKAGECONFIG[vpnc] = "--enable-vpnc 
--with-vpnc=${sbindir}/vpnc,--disable-vpnc"
+PACKAGECONFIG[l2tp] = "--enable-l2tp,--disable-l2tp"
+PACKAGECONFIG[pptp] = "--enable-pptp,--disable-pptp"
 # WISPr support for logging into hotspots, requires TLS
 PACKAGECONFIG[wispr] = "--enable-wispr,--disable-wispr,gnutls,"
 
 INITSCRIPT_NAME = "connman"
 INITSCRIPT_PARAMS = "start 05 5 2 3 . stop 22 0 1 6 ."
 
-python __anonymous () {
-systemd_packages = "${PN}"
-pkgconfig = d.getVar('PACKAGECONFIG', True)
-if ('openvpn' or 'vpnc' or 'l2tp' or 'pptp') in pkgconfig.split():
-systemd_packages += " ${PN}-vpn"
-d.setVar('SYSTEMD_PACKAGES', systemd_packages)
-}
-
+SYSTEMD_PACKAGES = "${PN} ${PN}-vpn"
 SYSTEMD_SERVICE_${PN} = "connman.service"
 SYSTEMD_SERVICE_${PN}-vpn = "connman-vpn.service"
 SYSTEMD_SERVICE_${PN}-wait-online = "connman-wait-online.service"
@@ -103,36 +96,6 @@ RDEPENDS_${PN} = "\
dbus \
"
 
-PACKAGES_DYNAMIC += "^${PN}-plugin-.*"
-
-def add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, add_insane_skip):
-plugintype = pkg.split( '-' )[-1]
-if plugintype in depmap:
-rdepends = map(lambda x: multilib_prefix + x, \
-   depmap[plugintype].split())
-d.setVar("RDEPENDS_%s" % pkg, " ".join(rdepends))
-if add_insane_skip:
-d.appendVar("INSANE_SKIP_%s" % pkg, "dev-so")
-
-python populate_packages_prepend() {
-depmap = dict(pppd="ppp")
-multilib_prefix = (d.getVar("MLPREFIX", True) or "")
-
-hook = lambda file,pkg,x,y,z: \
-add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, False)
-plugin_dir = d.expand('${libdir}/connman/plugins/')
-plugin_name = d.expand('${PN}-plugin-%s')
-do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, \
-'${PN} plugin for %s', extra_depends='', hook=hook, prepend=True )
-
-hook = lambda file,pkg,x,y,z: \
-add_rdepends(bb, d, file, pkg, depmap, multilib_prefix, True)
-plugin_dir = d.expand('${libdir}/connman/plugins-vpn/')
-plugin_name = d.expand('${PN}-plugin-vpn-%s')
-do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, \
-'${PN} VPN plugin for %s', extra_depends='', hook=hook, prepend=True )
-}
-
 PACKAGES =+ "${PN}-tools ${PN}-tests ${PN}-client"
 
 FILES_${PN}-tools = "${bindir}/wispr"
@@ -152,7 +115,12 @@ FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* 
${libdir}/lib*.so.* \
 
 FILES_${PN}-dev += "${libdir}/connman/*/*.la"
 
-PACKAGES =+ "${PN}-vpn ${PN}-wait-online"
+PACKAGES =+ "${PN}-vpn ${PN}-wait-online \
+ ${PN}-ppp \
+ ${PN}-plugin-vpn-l2tp \
+ ${PN}-plugin-vpn-openvpn \
+ ${PN}-plugin-vpn-pptp \
+ ${PN}-plugin-vpn-vpnc"
 
 SUMMARY_${PN}-vpn = "A daemon for managing VPN connections within embedded 
devices"
 DESCRIPTION_${PN}-vpn = "The ConnMan VPN provides a daemon for \
@@ -161,10 +129,10 @@ operating system.  The connman-vpnd handles all the VPN 
connections \
 and sta

[OE-core] [PATCH] run-postinsts: Print message before running deferred postinst scripts

2016-12-05 Thread Haris Okanovic

Opkg can defer running postinst scripts to first boot, which can take
a while on some systems. The output of `opkg configure` (or whatever pm
is used) is redirected to a file when logging is enabled
(I.e. $POSTINST_LOGGING == 1), making the machine appear hung during
this process. This change simply prints a wait message on the console
to inform the user of this potentially long and silent operation so
that they do not mistakenly reboot their machine.

Why not simply `tee` the output instead?
Tee might be provided by BusyBox in some distros, which may need to run
update-alternatives in the very postinst scripts being executed by this
process. It's therefore not safe to assume Tee (or any other packaged
util) is available until the configure process finishes.

Signed-off-by: Haris Okanovic 
---
 meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts 
b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
index 04ba394..660ddc2 100755
--- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
@@ -46,6 +46,9 @@ if [ -z "$pi_dir" ]; then
exit 0
 fi
 
+echo "Configuring packages on first boot"
+echo " (This may take several minutes. Please do not power off the machine.)"
+
 [ -e #SYSCONFDIR#/default/postinst ] && . #SYSCONFDIR#/default/postinst
 
 if [ "$POSTINST_LOGGING" = "1" ]; then
-- 
2.10.1

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

Re: [OE-core] [PATCH] gdb-cross-canadian: Depend on nativesdk-python3-misc

2016-12-05 Thread Burton, Ross

On 5 December 2016 at 16:38, George McCollister <
george.mccollis...@gmail.com> wrote:

> Add missing dependency on nativesdk-python3-misc so the imp Python
> module is installed.
>

So imp is the Python-facing API for 'import', and python-misc is a grab-bag
of random stuff.  Should imp be moved to be in python3-importlib (where its
replacement already lives) or moved into python3-core?

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

Re: [OE-core] [PATCH] u-boot: Add RPROVIDES bootloader

2016-12-05 Thread Otavio Salvador

On Mon, Dec 5, 2016 at 5:56 PM, Paul Eggleton
 wrote:
> On Mon, 05 Dec 2016 17:45:40 Otavio Salvador wrote:
>> On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
>>
>>  wrote:
>> > On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
>> >> This change allow to install u-boot in /boot partition using
>> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>> >>
>> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>> >>
>> >> This is usefull when system has only one partition and u-boot,
>> >> kernel and device tree need to be installed in /boot.
>> >
>> > If the intention is that other packages also have "bootloader" in
>> > RPROVIDES, I thought that these kinds of "virtual provides" weren't
>> > supported well by all of the package managers. (We might get away with it
>> > here since they probably will all be in their own separate
>> > machine-specific feeds, though).
>>
>> The point in having the bootloader is because different bootloaders
>> may provide the functionality for the board. This is especially keen
>> for commercial distributions where a U-Boot fork may include fixes and
>> this should be used on top of the BSP default and without many changes
>> on the layer.
>>
>> As you pointed out, the U-Boot usually has a single provider as it is
>> a MACHINE_ARCH package. I think it is a safe addition, isn't it?
>
> If we can guarantee that there will only be one runtime provider of
> "bootloader", then I would assume so, yes.
>
> One question - at OEDEM (based on the minutes, I wasn't there) the
> proliferation of u-boot recipes across BSPs was discussed and there was at
> least a desire to try to move to a single recipe where practically possible.
> Do you have any opinions on that? I bring it up because if there was only
> "u-boot" presumably we wouldn't need the "bootloader" RPROVIDES at all.

I agree and I think this should be a continuous goal for the entire
project and Yocto Project members, however, this is unlikely to happen
as internal BSPs and custom boards will always keep forked versions
around.

Even though having a single recipe is not going to happen, reducing
the fragmentation is very possible and desirable. We did some of work
on meta-freescale on this direction making many board to use
u-boot-fslc as provider. Some vendors moved to it while others keep
using their forks.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.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] u-boot: Add RPROVIDES bootloader

2016-12-05 Thread Paul Eggleton

On Mon, 05 Dec 2016 17:45:40 Otavio Salvador wrote:
> On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
> 
>  wrote:
> > On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
> >> This change allow to install u-boot in /boot partition using
> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
> >> 
> >> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
> >> 
> >> This is usefull when system has only one partition and u-boot,
> >> kernel and device tree need to be installed in /boot.
> > 
> > If the intention is that other packages also have "bootloader" in
> > RPROVIDES, I thought that these kinds of "virtual provides" weren't
> > supported well by all of the package managers. (We might get away with it
> > here since they probably will all be in their own separate
> > machine-specific feeds, though).
>
> The point in having the bootloader is because different bootloaders
> may provide the functionality for the board. This is especially keen
> for commercial distributions where a U-Boot fork may include fixes and
> this should be used on top of the BSP default and without many changes
> on the layer.
> 
> As you pointed out, the U-Boot usually has a single provider as it is
> a MACHINE_ARCH package. I think it is a safe addition, isn't it?

If we can guarantee that there will only be one runtime provider of 
"bootloader", then I would assume so, yes.

One question - at OEDEM (based on the minutes, I wasn't there) the 
proliferation of u-boot recipes across BSPs was discussed and there was at 
least a desire to try to move to a single recipe where practically possible. 
Do you have any opinions on that? I bring it up because if there was only 
"u-boot" presumably we wouldn't need the "bootloader" RPROVIDES at all.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Add RPROVIDES bootloader

2016-12-05 Thread Otavio Salvador

On Mon, Dec 5, 2016 at 5:31 PM, Paul Eggleton
 wrote:
> On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
>> This change allow to install u-boot in /boot partition using
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>>
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>>
>> This is usefull when system has only one partition and u-boot,
>> kernel and device tree need to be installed in /boot.
>
> If the intention is that other packages also have "bootloader" in RPROVIDES, I
> thought that these kinds of "virtual provides" weren't supported well by all
> of the package managers. (We might get away with it here since they probably
> will all be in their own separate machine-specific feeds, though).

The point in having the bootloader is because different bootloaders
may provide the functionality for the board. This is especially keen
for commercial distributions where a U-Boot fork may include fixes and
this should be used on top of the BSP default and without many changes
on the layer.

As you pointed out, the U-Boot usually has a single provider as it is
a MACHINE_ARCH package. I think it is a safe addition, isn't it?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.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] u-boot: Add RPROVIDES bootloader

2016-12-05 Thread Paul Eggleton

Hi Fabio,

On Fri, 02 Dec 2016 11:59:52 Fabio Berton wrote:
> This change allow to install u-boot in /boot partition using
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
> 
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
> 
> This is usefull when system has only one partition and u-boot,
> kernel and device tree need to be installed in /boot.

If the intention is that other packages also have "bootloader" in RPROVIDES, I 
thought that these kinds of "virtual provides" weren't supported well by all 
of the package managers. (We might get away with it here since they probably 
will all be in their own separate machine-specific feeds, though).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] RFC BuildAppliance future

2016-12-05 Thread Brian Avery

Excellent Questions!

Dogfooding – Good point.  The
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9502 bug is intended to
address that. With this, we can build and test container images just as we
can do with the Build Appliance. As an added win, those folks building
Busybox based minimal sized containers would have a different way to do
that...

OS availability: Docker is available for Windows, Mac, and Linux.  Were
there fears about specific Linux distributions?

It does not seem to be too much harder to try Docker on Windows than it was
to try Virtualbox.  That being said, Docker is moving/changing more quickly
so it may have more bumps in the road but more features too…

Windows explained more in depth or one of those bumps…:

  The answer is a little complicated, so please bear with me.  There are 2
different versions of Docker for Windows.  The original version is known as
“Docker Toolbox” https://www.docker.com/products/docker-toolbox.  This is
basically Docker running in a minimal VirtualBox Linux VM.  They made a
separate host binary called docker-machine to help manage the images. This
is, in my opinion, a little clunky and does add some complexity when
switching from Docker running on Linux to Docker Toolbox running on
Windows. The clunkiness is largely due to the VirtualBox VM being “between”
the host and the Docker Engine. This version is targeted to people whose
Windows version does not meet the requirements specified below.

  If you have 64bit Windows 10 Pro, Enterprise and Education (1511 November
update, Build 10586 or later) and Microsoft Hyper-V, then you can download
“Docker for Windows” https://docs.docker.com/docker-for-windows/.  This is
a Docker implementation for Windows that relies on Hyper-V and a much
smaller vm.  It is also better integrated into the host environment so that
the discontinuity between the host side and the Docker  Engine is no longer
as jarring.  For example, you get a disk tray icon for Docker, can set up
http proxies for it, can manage how much memory and how many cpus it will
get…

This (https://docs.docker.com/docker-for-mac/docker-toolbox/) is nice page
that addresses the difference between the newer hypervisor approach and the
older "Docker Toolbox aka VirtualBox" approach.  The page is discussing it
from a Mac perspective but if you replace xhyve with Windows 10 Hyper-V,
the page is relevant to Windows as well.

The Mac implementation is functionally equivalent to “Docker for Windows”
and is called “Docker for Mac”
https://docs.docker.com/engine/installation/mac/.  It runs on a modified
xhyve hypervisor.

The Linux implementation runs as a container and uses the same kernel as
the host.

Thanks for the feedback and if I missed or shortchanged something please
let me know,

-Brian

an intel employee

On Mon, Dec 5, 2016 at 10:42 AM, Khem Raj  wrote:

> On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery 
> wrote:
> >   Please note, this is going out to 3 lists in an attempt to insure that
> no
> > one who would be impacted by this change misses it. Implied spam apology
> > included.
> >
> >   The Yocto Project currently provides a virtual machine image called the
> > Build Appliance
> > (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-
> appliance/).
> > This image can be run using either VirtualBox or VMware. It enables you
> to
> > build and boot a custom embedded Linux image with the Yocto Project on a
> > non-Linux development system.  It is not intended for day to day
> development
> > use, but instead, is intended to allow users to “try out” the tools even
> if
> > they do not have access to a Linux system.
> >
> >   We are considering replacing the VM based Build Appliance with a set of
> > containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> > interface (https://hub.docker.com/r/crops/toaster-master/ ).  These
> > containers currently provide most of the functionality of the Build
> > Appliance and should shortly be at feature parity with the Build
> Appliance.
> > We are actively adding to and supporting the containers as some of our
> > developers are using them in their day to day development in order to
> > benefit from the host isolation and ease with which other distributions
> can
> > be tested.
> >
> >   This is an RFC to see what features in the Build Appliance are
> important
> > to you but would not be provided by the container solutions.  If the
> > community would be just as content using the container approach as using
> the
> > VM based Build Appliance image, then we’d be better off deprecating the
> > Build Appliance and applying those resources elsewhere.  If there are
> > important features the Build Appliance provides which the container
> solution
> > does not, or cannot provide, we’d love to hear what they are!
>
> Personally, I dont use build appliance but I think using containers is a
> good
> step forward, provided, we can address all build host OSes that
> virtual appli

Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: Add PKG_CONFIG_SYSROOT_DIR to output of pkg-config

2016-12-05 Thread Khem Raj


> On Dec 5, 2016, at 5:20 AM, Jussi Kukkonen  wrote:
> 
> 
> 
> On 1 December 2016 at 10:37, Khem Raj  > wrote:
> When configure pokes for wayland-protocols isntallations it ended up
> using the ones from host, which is because it did not account for sysroot
> prefix
> 
> Signed-off-by: Khem Raj mailto:raj.k...@gmail.com>>
> ---
>  .../gstreamer/gstreamer1.0-plugins-bad.inc |  2 +-
>  ...G_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch | 37 
> ++
>  .../gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb 
>    |  1 +
>  3 files changed, 39 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> 
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> index d26a6a9..d3c5326 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> @@ -64,7 +64,7 @@ PACKAGECONFIG[srtp]= 
> "--enable-srtp,--disable-srtp,libsrtp"
>  PACKAGECONFIG[uvch264] = "--enable-uvch264,--disable-uvch264,libusb1 
> libgudev"
>  PACKAGECONFIG[voaacenc]= 
> "--enable-voaacenc,--disable-voaacenc,vo-aacenc"
>  PACKAGECONFIG[voamrwbenc]  = 
> "--enable-voamrwbenc,--disable-voamrwbenc,vo-amrwbenc"
> -PACKAGECONFIG[wayland] = 
> "--enable-wayland,--disable-wayland,wayland-native wayland"
> +PACKAGECONFIG[wayland] = 
> "--enable-wayland,--disable-wayland,wayland-native wayland wayland-protocols"
>  PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
> 
>  # these plugins have not been ported to 1.0 (yet):
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> new file mode 100644
> index 000..eb789df
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> @@ -0,0 +1,37 @@
> +From c271503d7e233428ac0323c51d6517113e26bef7 Mon Sep 17 00:00:00 2001
> +From: Khem Raj mailto:raj.k...@gmail.com>>
> +Date: Thu, 1 Dec 2016 00:27:13 -0800
> +Subject: [PATCH] Prepend PKG_CONFIG_SYSROOT_DIR to pkg-config output
> +
> +In cross environment we have to prepend the sysroot to the path found by
> +pkgconfig since the path returned from pkgconfig does not have sysroot 
> prefixed
> +it ends up using the files from host system. If build host has wayland 
> installed
> +the build will succeed but if you dont have wayland-protocols installed on 
> build host then
> +it wont find the files on build host
> +
> +This should work ok with non sysrooted builds too since in those cases 
> PKG_CONFIG_SYSROOT_DIR
> +will be empty
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj mailto:raj.k...@gmail.com>>
> +---
> + configure.ac  | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/configure.ac  b/configure.ac 
> 
> +index f8ac96b..dc87b08 100644
> +--- a/configure.ac 
>  b/configure.ac 
> +@@ -2233,7 +2233,7 @@ AG_GST_CHECK_FEATURE(WAYLAND, [wayland sink], wayland 
> , [
> + PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, wayland-protocols >= 1.4, [
> +   if test "x$wayland_scanner" != "x"; then
> + HAVE_WAYLAND="yes"
> +-AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG 
> --variable=pkgdatadir wayland-protocols`)
> ++AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, 
> ${PKG_CONFIG_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir 
> wayland-protocols`)
> 
> I believe this breaks multilib because wayland-protocols is allarch so 
> PKG_CONFIG_SYSROOT_DIR may then be incorrect.

Realized my last reply is too terse. expanding on it a bit more.
this is not really the case. Since PKG_CONFIG_SYSROOT_DIR is set to  
STAGING_DIR_HOST which is then set to ${STAGING_DIR}/${MACHINE} so effectively 
its just
reusing an existing var compared to your case where a new redundant variable is 
introduced. 

having said that, there could be a multilib issue if pkgdatadir thats in .pc 
file from wayland-protocols package is using variables like ${libdir} which 
then are
multilib dependent, if this is the case then we need to fix .pc file. however 
when I look at the /usr/share/pkgconfig/wayland-protocols.pc it 
has

prefix=/usr
datarootdir=${prefix}/share
pkgdatadir=/usr/share/wayland-protocols

seems to be free of multilib deps.

> 
> I've set "WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}" in 
> EXTRA_OECONF in other recipes and used that variable in the patche

Re: [OE-core] [Openembedded-architecture] RFC BuildAppliance future

2016-12-05 Thread Khem Raj

On Mon, Dec 5, 2016 at 10:04 AM, Brian Avery  wrote:
>   Please note, this is going out to 3 lists in an attempt to insure that no
> one who would be impacted by this change misses it. Implied spam apology
> included.
>
>   The Yocto Project currently provides a virtual machine image called the
> Build Appliance
> (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
> This image can be run using either VirtualBox or VMware. It enables you to
> build and boot a custom embedded Linux image with the Yocto Project on a
> non-Linux development system.  It is not intended for day to day development
> use, but instead, is intended to allow users to “try out” the tools even if
> they do not have access to a Linux system.
>
>   We are considering replacing the VM based Build Appliance with a set of
> containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> interface (https://hub.docker.com/r/crops/toaster-master/ ).  These
> containers currently provide most of the functionality of the Build
> Appliance and should shortly be at feature parity with the Build Appliance.
> We are actively adding to and supporting the containers as some of our
> developers are using them in their day to day development in order to
> benefit from the host isolation and ease with which other distributions can
> be tested.
>
>   This is an RFC to see what features in the Build Appliance are important
> to you but would not be provided by the container solutions.  If the
> community would be just as content using the container approach as using the
> VM based Build Appliance image, then we’d be better off deprecating the
> Build Appliance and applying those resources elsewhere.  If there are
> important features the Build Appliance provides which the container solution
> does not, or cannot provide, we’d love to hear what they are!

Personally, I dont use build appliance but I think using containers is a good
step forward, provided, we can address all build host OSes that
virtual appliance
could.

Build appliance is also a sort of "eat your own dog-food" for ensuring that we
are doing ok on preparing cloud images for deployment. Hopefully we wont
lose that testing, may be we can add another image to cover that.

>
> Thanks in advance for any feedback,
>
> -Brian
>
> an Intel Employee
>
>
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] RFC BuildAppliance future

2016-12-05 Thread Mark Hatle

On 12/5/16 12:04 PM, Brian Avery wrote:
>   Please note, this is going out to 3 lists in an attempt to insure that no 
> one
> who would be impacted by this change misses it. Implied spam apology included.
> 
>   The Yocto Project currently provides a virtual machine image called the 
> Build
> Appliance
> (https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
> This image can be run using either VirtualBox or VMware. It enables you to 
> build
> and boot a custom embedded Linux image with the Yocto Project on a non-Linux
> development system.  It is not intended for day to day development use, but
> instead, is intended to allow users to “try out” the tools even if they do not
> have access to a Linux system.

What are the requirements for a Windows user to use this, instead of the VM
approach.  (In the past it was easy for a Windows user to get the VM, and just
run it to test out things.)

--Mark

>   We are considering replacing the VM based Build Appliance with a set of
> containers (https://hub.docker.com/r/crops/poky/, or if you want a user
> interface (https://hub.docker.com/r/crops/toaster-master/ ).  These containers
> currently provide most of the functionality of the Build Appliance and should
> shortly be at feature parity with the Build Appliance.  We are actively adding
> to and supporting the containers as some of our developers are using them in
> their day to day development in order to benefit from the host isolation and
> ease with which other distributions can be tested. 
> 
>   This is an RFC to see what features in the Build Appliance are important to
> you but would not be provided by the container solutions.  If the community
> would be just as content using the container approach as using the VM based
> Build Appliance image, then we’d be better off deprecating the Build Appliance
> and applying those resources elsewhere.  If there are important features the
> Build Appliance provides which the container solution does not, or cannot
> provide, we’d love to hear what they are!
> 
>  Thanks in advance for any feedback,
> 
> -Brian
> 
> an Intel Employee
> 
> 
> 
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

Re: [OE-core] [PATCH 1/2] diffutils: do_configure: fix "Argument list too long"

2016-12-05 Thread Khem Raj

On Mon, Dec 5, 2016 at 6:54 AM, Robert Yang  wrote:
> Fixed when len(TMPDIR) =  410:
> aclocal: error: cannot open echo [snip]: Argument list too long
>
> This is becuase it has a lot of m4 files, use relative path for them
> can fix the problem.
>
> It doesn't happen when MACHINE="qemux86", I think it is because
> intel-x86-64 is longer than qemux86.
>
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-extended/diffutils/diffutils_3.4.bb | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-extended/diffutils/diffutils_3.4.bb 
> b/meta/recipes-extended/diffutils/diffutils_3.4.bb
> index cb7092b..be280ec 100644
> --- a/meta/recipes-extended/diffutils/diffutils_3.4.bb
> +++ b/meta/recipes-extended/diffutils/diffutils_3.4.bb
> @@ -10,6 +10,9 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.xz \
>
>  EXTRA_OECONF += "--without-libsigsegv-prefix"
>
> +# Fix "Argument list too long" error when len(TMPDIR) = 410
> +acpaths = "-I ./m4"

it looks ok if this work ok with externalsrc

> +
>  do_configure_prepend () {
> # Need to remove gettext macros with weird mix of versions
> for i in codeset.m4 gettext_gl.m4 intlmacosx.m4 inttypes-pri.m4 
> lib-ld_gl.m4 lib-prefix_gl.m4 po_gl.m4 ssize_t.m4 wchar_t.m4 wint_t.m4; do
> --
> 2.9.0
>
> --
> ___
> 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] non-standard library locations and rpath

2016-12-05 Thread Khem Raj

On Mon, Dec 5, 2016 at 9:41 AM, Jack Mitchell  wrote:
>
>
> On 05/12/16 16:43, Khem Raj wrote:
>>
>> On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell  wrote:
>>>
>>>
>>>
>>> On 05/12/16 10:44, Jack Mitchell wrote:


 On 02/12/16 07:08, Khem Raj wrote:
>
>
> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell  wrote:
>>
>>
>> I'm having some troubles with shared library, shared library
>> dependencies
>> and rpaths. I have libfoo, which depends on libbar when I try to link
>> libfoo
>> with my app, it requires libbar to be found. libbar is in a
>> non-standard
>> location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
>> ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
>> when I
>> come to try link my app with libfoo, it fails to link as it can't find
>> libbar, which I assume means the rpath in libfoo isn't being properly
>> prepending with sysroot what is the proper way to support this in OE?
>> My
>> library has the following rpath information:
>>
>> 0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>
>> So why isn't the rpath being prepended with the sysroot when I
>> compile my
>> app and link libfoo? The apps build system is using cmake, but this
>> should
>> be a built in linker feature, correct?
>
>
>
> Only first path ( before :) is relative to location of binary at
> runtime
>

 Exactly, so how can you make an OE build use the rpaths of libs that
 point to the build sysroot. What I have at the moment is

 0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

 Which would be correct if I was linking on the target. However when OE
 sees the rpath in it's cross compile environment it should prepend it
 with the build sysroot so you end up with something like

 0x000f (RPATH) Library rpath:
 [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]

 And then the SDK should end up with something like

 0x000f (RPATH) Library rpath:
 [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]

 Is this what is expected to happen, or am I stumbling into an
 unsupported scenario.

 Cheers,
>>>
>>>
>>>
>>> I think basically what I'm saying is that does the linker prepend it's
>>> --sysroot value to absolute rpaths, and if not, should it?
>>
>>
>> having absolute build paths into rpaths is not a good thing. Linker
>> will search the libs during link in sysroot its configured to do so.
>>
>
> Ok, that makes sense. So something like this would be more appropriate?
>
> rel_path = relative_path(mylib, otherlib)
>
> -Wl,-rpath $ORIGIN${relpath}

This could work.

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

[OE-core] RFC BuildAppliance future

2016-12-05 Thread Brian Avery

  Please note, this is going out to 3 lists in an attempt to insure that no
one who would be impacted by this change misses it. Implied spam apology
included.

  The Yocto Project currently provides a virtual machine image called the
Build Appliance (
https://downloads.yoctoproject.org/releases/yocto/yocto-2.2/build-appliance/).
This image can be run using either VirtualBox or VMware. It enables you to
build and boot a custom embedded Linux image with the Yocto Project on a
non-Linux development system.  It is not intended for day to day
development use, but instead, is intended to allow users to “try out” the
tools even if they do not have access to a Linux system.

  We are considering replacing the VM based Build Appliance with a set of
containers (https://hub.docker.com/r/crops/poky/, or if you want a user
interface (https://hub.docker.com/r/crops/toaster-master/ ).  These
containers currently provide most of the functionality of the Build
Appliance and should shortly be at feature parity with the Build
Appliance.  We are actively adding to and supporting the containers as some
of our developers are using them in their day to day development in order
to benefit from the host isolation and ease with which other distributions
can be tested.

  This is an RFC to see what features in the Build Appliance are important
to you but would not be provided by the container solutions.  If the
community would be just as content using the container approach as using
the VM based Build Appliance image, then we’d be better off deprecating the
Build Appliance and applying those resources elsewhere.  If there are
important features the Build Appliance provides which the container
solution does not, or cannot provide, we’d love to hear what they are!

Thanks in advance for any feedback,

-Brian

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

Re: [OE-core] non-standard library locations and rpath

2016-12-05 Thread Jack Mitchell




On 05/12/16 16:43, Khem Raj wrote:

On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell  wrote:



On 05/12/16 10:44, Jack Mitchell wrote:


On 02/12/16 07:08, Khem Raj wrote:


On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell  wrote:


I'm having some troubles with shared library, shared library
dependencies
and rpaths. I have libfoo, which depends on libbar when I try to link
libfoo
with my app, it requires libbar to be found. libbar is in a non-standard
location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
when I
come to try link my app with libfoo, it fails to link as it can't find
libbar, which I assume means the rpath in libfoo isn't being properly
prepending with sysroot what is the proper way to support this in OE? My
library has the following rpath information:

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I
compile my
app and link libfoo? The apps build system is using cmake, but this
should
be a built in linker feature, correct?



Only first path ( before :) is relative to location of binary at runtime



Exactly, so how can you make an OE build use the rpaths of libs that
point to the build sysroot. What I have at the moment is

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE
sees the rpath in it's cross compile environment it should prepend it
with the build sysroot so you end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]

And then the SDK should end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]

Is this what is expected to happen, or am I stumbling into an
unsupported scenario.

Cheers,



I think basically what I'm saying is that does the linker prepend it's
--sysroot value to absolute rpaths, and if not, should it?


having absolute build paths into rpaths is not a good thing. Linker
will search the libs during link in sysroot its configured to do so.



Ok, that makes sense. So something like this would be more appropriate?

rel_path = relative_path(mylib, otherlib)

-Wl,-rpath $ORIGIN${relpath}



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

Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: Add PKG_CONFIG_SYSROOT_DIR to output of pkg-config

2016-12-05 Thread Khem Raj

On Mon, Dec 5, 2016 at 5:20 AM, Jussi Kukkonen  wrote:
>
>
> On 1 December 2016 at 10:37, Khem Raj  wrote:
>>
>> When configure pokes for wayland-protocols isntallations it ended up
>> using the ones from host, which is because it did not account for sysroot
>> prefix
>>
>> Signed-off-by: Khem Raj 
>> ---
>>  .../gstreamer/gstreamer1.0-plugins-bad.inc |  2 +-
>>  ...G_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch | 37
>> ++
>>  .../gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb   |  1 +
>>  3 files changed, 39 insertions(+), 1 deletion(-)
>>  create mode 100644
>> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>>
>> diff --git
>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> index d26a6a9..d3c5326 100644
>> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> @@ -64,7 +64,7 @@ PACKAGECONFIG[srtp]=
>> "--enable-srtp,--disable-srtp,libsrtp"
>>  PACKAGECONFIG[uvch264] =
>> "--enable-uvch264,--disable-uvch264,libusb1 libgudev"
>>  PACKAGECONFIG[voaacenc]=
>> "--enable-voaacenc,--disable-voaacenc,vo-aacenc"
>>  PACKAGECONFIG[voamrwbenc]  =
>> "--enable-voamrwbenc,--disable-voamrwbenc,vo-amrwbenc"
>> -PACKAGECONFIG[wayland] =
>> "--enable-wayland,--disable-wayland,wayland-native wayland"
>> +PACKAGECONFIG[wayland] =
>> "--enable-wayland,--disable-wayland,wayland-native wayland
>> wayland-protocols"
>>  PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
>>
>>  # these plugins have not been ported to 1.0 (yet):
>> diff --git
>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>> new file mode 100644
>> index 000..eb789df
>> --- /dev/null
>> +++
>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>> @@ -0,0 +1,37 @@
>> +From c271503d7e233428ac0323c51d6517113e26bef7 Mon Sep 17 00:00:00 2001
>> +From: Khem Raj 
>> +Date: Thu, 1 Dec 2016 00:27:13 -0800
>> +Subject: [PATCH] Prepend PKG_CONFIG_SYSROOT_DIR to pkg-config output
>> +
>> +In cross environment we have to prepend the sysroot to the path found by
>> +pkgconfig since the path returned from pkgconfig does not have sysroot
>> prefixed
>> +it ends up using the files from host system. If build host has wayland
>> installed
>> +the build will succeed but if you dont have wayland-protocols installed
>> on build host then
>> +it wont find the files on build host
>> +
>> +This should work ok with non sysrooted builds too since in those cases
>> PKG_CONFIG_SYSROOT_DIR
>> +will be empty
>> +
>> +Upstream-Status: Pending
>> +
>> +Signed-off-by: Khem Raj 
>> +---
>> + configure.ac | 2 +-
>> + 1 file changed, 1 insertion(+), 1 deletion(-)
>> +
>> +diff --git a/configure.ac b/configure.ac
>> +index f8ac96b..dc87b08 100644
>> +--- a/configure.ac
>>  b/configure.ac
>> +@@ -2233,7 +2233,7 @@ AG_GST_CHECK_FEATURE(WAYLAND, [wayland sink],
>> wayland , [
>> + PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, wayland-protocols >= 1.4, [
>> +   if test "x$wayland_scanner" != "x"; then
>> + HAVE_WAYLAND="yes"
>> +-AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG
>> --variable=pkgdatadir wayland-protocols`)
>> ++AC_SUBST(WAYLAND_PROTOCOLS_DATADIR,
>> ${PKG_CONFIG_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir
>> wayland-protocols`)
>
>
> I believe this breaks multilib because wayland-protocols is allarch so
> PKG_CONFIG_SYSROOT_DIR may then be incorrect.

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

Re: [OE-core] non-standard library locations and rpath

2016-12-05 Thread Khem Raj

On Mon, Dec 5, 2016 at 2:54 AM, Jack Mitchell  wrote:
>
>
> On 05/12/16 10:44, Jack Mitchell wrote:
>>
>> On 02/12/16 07:08, Khem Raj wrote:
>>>
>>> On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell  wrote:

 I'm having some troubles with shared library, shared library
 dependencies
 and rpaths. I have libfoo, which depends on libbar when I try to link
 libfoo
 with my app, it requires libbar to be found. libbar is in a non-standard
 location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
 ${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
 when I
 come to try link my app with libfoo, it fails to link as it can't find
 libbar, which I assume means the rpath in libfoo isn't being properly
 prepending with sysroot what is the proper way to support this in OE? My
 library has the following rpath information:

 0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

 So why isn't the rpath being prepended with the sysroot when I
 compile my
 app and link libfoo? The apps build system is using cmake, but this
 should
 be a built in linker feature, correct?
>>>
>>>
>>> Only first path ( before :) is relative to location of binary at runtime
>>>
>>
>> Exactly, so how can you make an OE build use the rpaths of libs that
>> point to the build sysroot. What I have at the moment is
>>
>> 0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]
>>
>> Which would be correct if I was linking on the target. However when OE
>> sees the rpath in it's cross compile environment it should prepend it
>> with the build sysroot so you end up with something like
>>
>> 0x000f (RPATH) Library rpath:
>> [$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]
>>
>> And then the SDK should end up with something like
>>
>> 0x000f (RPATH) Library rpath:
>> [$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]
>>
>> Is this what is expected to happen, or am I stumbling into an
>> unsupported scenario.
>>
>> Cheers,
>
>
> I think basically what I'm saying is that does the linker prepend it's
> --sysroot value to absolute rpaths, and if not, should it?

having absolute build paths into rpaths is not a good thing. Linker
will search the libs during link in sysroot its configured to do so.

>
> --
> ___
> 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

[OE-core] [PATCH] gdb-cross-canadian: Depend on nativesdk-python3-misc

2016-12-05 Thread George McCollister

Add missing dependency on nativesdk-python3-misc so the imp Python
module is installed.

Before this patch, running gdb from the sdk would give the following
error:

Python Exception  No module named 'imp':

Signed-off-by: George McCollister 
---
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc 
b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
index e53081d..844daf2 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
@@ -14,7 +14,8 @@ GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'"
 PACKAGECONFIG ??= "python readline"
 PACKAGECONFIG[python] = 
"--with-python=${WORKDIR}/python,--without-python,nativesdk-python3, \
  nativesdk-python3-core nativesdk-python3-lang 
nativesdk-python3-re \
- nativesdk-python3-codecs nativesdk-python3-netclient"
+ nativesdk-python3-codecs nativesdk-python3-netclient \
+ nativesdk-python3-misc"
 PACKAGECONFIG[readline] = 
"--with-system-readline,--without-system-readline,nativesdk-readline"
 
 SSTATE_DUPWHITELIST += "${STAGING_DATADIR}/gdb"
-- 
2.9.3

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

Re: [OE-core] [PATCH] u-boot: Add RPROVIDES bootloader

2016-12-05 Thread Fabio Berton

Use MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "u-boot" without apply any patch?

On Mon, Dec 5, 2016 at 2:18 PM, Burton, Ross  wrote:

>
> On 2 December 2016 at 13:59, Fabio Berton 
> wrote:
>
>> This change allow to install u-boot in /boot partition using
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>>
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>>
>> This is usefull when system has only one partition and u-boot,
>> kernel and device tree need to be installed in /boot.
>>
>
> What does this give you over just MACHINE_ESSENTIAL_EXTRA_RDEPENDS +=
> "u-boot"?
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Update to v2016.11 release

2016-12-05 Thread Marek Vasut

On 12/05/2016 05:19 PM, Burton, Ross wrote:
> This doesn't apply to master cleanly, I suspect it's part of a series
> that has managed to become split up in my inbox.
> 
> Is there a branch with this on?

Afaict you applied the update to 2016.09 and squashed some patches and
that never made it into master. Anyway, I'm attaching all the patches,
for completeness.

> Ross
> 
> On 18 November 2016 at 19:29, Marek Vasut  > wrote:
> 
> Upgrade U-Boot to the latest version.
> 
> Signed-off-by: Marek Vasut mailto:ma...@denx.de>>
> Cc: Richard Purdie  >
> Cc: Denys Dmytriyenko mailto:de...@denix.org>>
> Cc: Ross Burton mailto:ross.bur...@intel.com>>
> ---
>  .../{u-boot-common_2016.09.01.inc => u-boot-common_2016.11.inc}   
>| 4 ++--
>  .../{u-boot-fw-utils_2016.09.01.bb
>  => u-boot-fw-utils_2016.11.bb
> } | 0
>  .../{u-boot-mkimage_2016.09.01.bb
>  => u-boot-mkimage_2016.11.bb
> }   | 0
>  meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb
>  => u-boot_2016.11.bb
> }   | 0
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-bsp/u-boot/{u-boot-common_2016.09.01.inc =>
> u-boot-common_2016.11.inc} (71%)
>  rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2016.09.01.bb
>  => u-boot-fw-utils_2016.11.bb
> } (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2016.09.01.bb
>  => u-boot-mkimage_2016.11.bb
> } (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb
>  => u-boot_2016.11.bb
> } (100%)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> similarity index 71%
> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> index f706a6b..84adc1c 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> @@ -7,8 +7,8 @@ PE = "1"
> 
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
> 
> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y
> "
> +SRC_URI = "git://git.denx.de/u-boot.git
> "
> 
>  S = "${WORKDIR}/git"
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> 
> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> 
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> 
> rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> 
> b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> 
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> 
> rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> 
> b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb 
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> 
> rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> 
> --
> 2.10.2
> 
> 


-- 
Best regards,
Marek Vasut
>From 7e9976663a73881023ac9cf9814f9ba16e41 Mon Sep 17 00:00:00 2001
From: Marek Vasut 
Date: Sun, 4 Sep 2016 12:50:01 +0200
Subject: [PATCH 1/6] u-boot: Update to 2016.09.01 release

Upgrade U-Boot to the latest version.

Signed-off-by: Marek Vasut 
Cc: Richard Purdie 
Cc: Denys Dmytriyenko 
---
 .../{u-boot-common_2016.03.inc => u-boot-common_2016.09.01.inc}   | 8 
 .../{u-boot-fw-utils_2016.03.bb => u-boot-fw-utils_2016.09.01.bb} | 0
 .../{u-boot-mkimage_2016.03.bb => u-boot-mkimage_2016.09.01.bb}   | 0
 .../u-boot/{u-boot_2016.03.bb => u-boot_2016.09.01.bb}| 0
 4 files ch

Re: [OE-core] [PATCH] u-boot: Update to v2016.11 release

2016-12-05 Thread Burton, Ross

This doesn't apply to master cleanly, I suspect it's part of a series that
has managed to become split up in my inbox.

Is there a branch with this on?

Ross

On 18 November 2016 at 19:29, Marek Vasut  wrote:

> Upgrade U-Boot to the latest version.
>
> Signed-off-by: Marek Vasut 
> Cc: Richard Purdie 
> Cc: Denys Dmytriyenko 
> Cc: Ross Burton 
> ---
>  .../{u-boot-common_2016.09.01.inc => u-boot-common_2016.11.inc}   |
> 4 ++--
>  .../{u-boot-fw-utils_2016.09.01.bb => u-boot-fw-utils_2016.11.bb} | 0
>  .../{u-boot-mkimage_2016.09.01.bb => u-boot-mkimage_2016.11.bb}   | 0
>  meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb}   | 0
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-bsp/u-boot/{u-boot-common_2016.09.01.inc =>
> u-boot-common_2016.11.inc} (71%)
>  rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2016.09.01.bb =>
> u-boot-fw-utils_2016.11.bb} (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2016.09.01.bb =>
> u-boot-mkimage_2016.11.bb} (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb}
> (100%)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> similarity index 71%
> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> index f706a6b..84adc1c 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> @@ -7,8 +7,8 @@ PE = "1"
>
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
>
> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
> +SRC_URI = "git://git.denx.de/u-boot.git"
>
>  S = "${WORKDIR}/git"
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> --
> 2.10.2
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Add RPROVIDES bootloader

2016-12-05 Thread Burton, Ross

On 2 December 2016 at 13:59, Fabio Berton 
wrote:

> This change allow to install u-boot in /boot partition using
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS variable e.g.:
>
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "bootloader"
>
> This is usefull when system has only one partition and u-boot,
> kernel and device tree need to be installed in /boot.
>

What does this give you over just MACHINE_ESSENTIAL_EXTRA_RDEPENDS +=
"u-boot"?

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

Re: [OE-core] [PATCH 1/2] connman: Simplify and fix packaging of VPN plug-ins

2016-12-05 Thread Burton, Ross

On 30 November 2016 at 12:22, Andreas Oberritter 
wrote:

> - Use simple static packaging.
> - Move VPN runtime dependencies from connman to the individual plug-ins.
> - Create a connmann-ppp package containing libppp-plugin.so, which is
>   a shared library needed by l2tp and pptp plug-ins.
> - Let connman suggest VPN packages instead of recommending them, so they
>   don't get installed by default.
> - Remove unknown configure options (--with-pptp --with-l2tp)
>

Lines like this break with just oe-core:

+RDEPENDS_${PN}-plugin-vpn-l2tp = "${PN}-vpn ${PN}-ppp xl2tpd"

ERROR: Nothing RPROVIDES 'vpnc' (but
/home/ross/Yocto/poky/meta/recipes-connectivity/connman/connman_1.33.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'vpnc' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['vpnc']
ERROR: Required build target 'connman' has no buildable providers.
Missing or unbuildable dependency chain was: ['connman', 'vpnc']

(repeat for all the other RDEPENDS that are not in oe-core).

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

Re: [OE-core] [PATCH] u-boot: Update to v2016.11 release

2016-12-05 Thread Bill Randle

On Fri, Nov 18, 2016 at 11:29 AM, Marek Vasut  wrote:
> Upgrade U-Boot to the latest version.
>
> Signed-off-by: Marek Vasut 
> Cc: Richard Purdie 
> Cc: Denys Dmytriyenko 
> Cc: Ross Burton 
> ---
>  .../{u-boot-common_2016.09.01.inc => u-boot-common_2016.11.inc}   | 4 
> ++--
>  .../{u-boot-fw-utils_2016.09.01.bb => u-boot-fw-utils_2016.11.bb} | 0
>  .../{u-boot-mkimage_2016.09.01.bb => u-boot-mkimage_2016.11.bb}   | 0
>  meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb}   | 0
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-bsp/u-boot/{u-boot-common_2016.09.01.inc => 
> u-boot-common_2016.11.inc} (71%)
>  rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2016.09.01.bb => 
> u-boot-fw-utils_2016.11.bb} (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2016.09.01.bb => 
> u-boot-mkimage_2016.11.bb} (100%)
>  rename meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb} 
> (100%)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc 
> b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> similarity index 71%
> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> index f706a6b..84adc1c 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> @@ -7,8 +7,8 @@ PE = "1"
>
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
>
> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
> +SRC_URI = "git://git.denx.de/u-boot.git"
>
>  S = "${WORKDIR}/git"
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> --

Ross, any chance of getting this staged soon? I'm using it in a
project and I checked poky/master-next and poky-contrib/ross/mut but
don't see it there yet.

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

[OE-core] Yocto Project Status WW50

2016-12-05 Thread Jolley, Stephen K

Current Dev Position: YP 2.3 M1

Next Deadline: YP 2.3 M1 by Dec. 12, 2016


SWAT team rotation: Anibal -> Tracy

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*We're now coming to the end of the M1 development period with it 
closing next Monday.

*The recipe specific sysroot patchset has been updated with a number of 
the key issues being addressed.

*Patches are being merged but we're continue to struggle to track down 
which patches in testing are causing which failures which does slow down the 
overall merge progress. The work Ross has been doing here is much appreciated. 
We have seen many recipe upgrades being merged.

*Performance of bitbake on systems with large numbers of cores appears 
to have bottlenecks in bitbake-worker. One patch has already merged for this 
and there are some further patches pending. Python3 appears to have made this 
issue worse.

*The monthly tech meeting is tomorrow at 8am PST.  US Phone: 
8007302996/9139049836, Bridge: 2705751


Proposed upcoming dot releases:

YP 2.0.3 Release by Dec. 9, 2016

YP 2.2.1 Release by Jan. 20, 2017

YP 2.1.3 Release by May. 19, 2017


Key YP 2.3 Dates:

YP 2.3 M1 Cutoff is Dec. 12, 2016

YP 2.3 M1 Release is Dec. 23, 2016

YP 2.3 M2 Cutoff is Jan. 23, 2017

YP 2.3 M2 Release is Feb. 3, 2017

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 3, 2017

YP 2.3 M4 Release is April 28, 2017


Tracking Metrics:

WDD 2507 (last week 2552)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features


[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

Re: [OE-core] [PATCH] classes/cpan-base: fix for PERLVERSION

2016-12-05 Thread Burton, Ross

On 9 November 2016 at 05:51,  wrote:

> -PERLVERSION := "${@get_perl_version(d)}"
> +PERLVERSION = "${@get_perl_version(d)}"
>

This uses := as the get_perl_version is a non-trivial amount of python
which doesn't need to be re-evaluated all the time.  Have you looked at how
bad the performance hit is, and whether there is an alternative?

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

[OE-core] [PATCH 2/2] image.bbclass: inherit image_types_uboot when needed

2016-12-05 Thread Robert Yang

Fixed:
MACHINE = "qemuarm"
IMAGE_FSTYPES += "ext3.bz2.u-boot"
[snip]
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'ext3.bz2.u-boot' - possibly 
invalid type name or missing support class
[snip]

This is because image_types_uboot is not inherited, inherit it when
needed will fix the problem.

Signed-off-by: Robert Yang 
---
 meta/classes/image.bbclass | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 6111f6d..b10272a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -144,6 +144,15 @@ inherit ${IMAGE_TYPE_live}
 IMAGE_TYPE_vm = '${@bb.utils.contains_any("IMAGE_FSTYPES", ["vmdk", "vdi", 
"qcow2", "hdddirect"], "image-vm", "", d)}'
 inherit ${IMAGE_TYPE_vm}
 
+def build_uboot(d):
+if 'u-boot' in (d.getVar('IMAGE_FSTYPES', True) or ''):
+return "image_types_uboot"
+else:
+return ""
+
+IMAGE_TYPE_uboot = "${@build_uboot(d)}"
+inherit ${IMAGE_TYPE_uboot}
+
 python () {
 deps = " " + imagetypes_getdepends(d)
 d.appendVarFlag('do_rootfs', 'depends', deps)
-- 
2.9.0

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

[OE-core] [PATCH 1/2] diffutils: do_configure: fix "Argument list too long"

2016-12-05 Thread Robert Yang

Fixed when len(TMPDIR) =  410:
aclocal: error: cannot open echo [snip]: Argument list too long

This is becuase it has a lot of m4 files, use relative path for them
can fix the problem.

It doesn't happen when MACHINE="qemux86", I think it is because
intel-x86-64 is longer than qemux86.

Signed-off-by: Robert Yang 
---
 meta/recipes-extended/diffutils/diffutils_3.4.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/diffutils/diffutils_3.4.bb 
b/meta/recipes-extended/diffutils/diffutils_3.4.bb
index cb7092b..be280ec 100644
--- a/meta/recipes-extended/diffutils/diffutils_3.4.bb
+++ b/meta/recipes-extended/diffutils/diffutils_3.4.bb
@@ -10,6 +10,9 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.xz \
 
 EXTRA_OECONF += "--without-libsigsegv-prefix"
 
+# Fix "Argument list too long" error when len(TMPDIR) = 410
+acpaths = "-I ./m4"
+
 do_configure_prepend () {
# Need to remove gettext macros with weird mix of versions
for i in codeset.m4 gettext_gl.m4 intlmacosx.m4 inttypes-pri.m4 
lib-ld_gl.m4 lib-prefix_gl.m4 po_gl.m4 ssize_t.m4 wchar_t.m4 wint_t.m4; do
-- 
2.9.0

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

[OE-core] [PATCH 0/2] Fixes for diffutils and u-boot

2016-12-05 Thread Robert Yang

The following changes since commit 11063a01d4511b2688ea7ba2d7359e4e07328c66:

  ruby: upgrade to 2.3.1 (2016-11-30 15:47:17 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/2fixes
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/2fixes

Robert Yang (2):
  diffutils: do_configure: fix "Argument list too long"
  image.bbclass: inherit image_types_uboot when needed

 meta/classes/image.bbclass   | 9 +
 meta/recipes-extended/diffutils/diffutils_3.4.bb | 3 +++
 2 files changed, 12 insertions(+)

-- 
2.9.0

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

Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: Add PKG_CONFIG_SYSROOT_DIR to output of pkg-config

2016-12-05 Thread Jussi Kukkonen

On 1 December 2016 at 10:37, Khem Raj  wrote:

> When configure pokes for wayland-protocols isntallations it ended up
> using the ones from host, which is because it did not account for sysroot
> prefix
>
> Signed-off-by: Khem Raj 
> ---
>  .../gstreamer/gstreamer1.0-plugins-bad.inc |  2 +-
>  ...G_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch | 37
> ++
>  .../gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb   |  1 +
>  3 files changed, 39 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
>
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> index d26a6a9..d3c5326 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> @@ -64,7 +64,7 @@ PACKAGECONFIG[srtp]=
> "--enable-srtp,--disable-srtp,libsrtp"
>  PACKAGECONFIG[uvch264] = "--enable-uvch264,--disable-uvch264,libusb1
> libgudev"
>  PACKAGECONFIG[voaacenc]= "--enable-voaacenc,--disable-
> voaacenc,vo-aacenc"
>  PACKAGECONFIG[voamrwbenc]  = "--enable-voamrwbenc,--
> disable-voamrwbenc,vo-amrwbenc"
> -PACKAGECONFIG[wayland] = 
> "--enable-wayland,--disable-wayland,wayland-native
> wayland"
> +PACKAGECONFIG[wayland] = 
> "--enable-wayland,--disable-wayland,wayland-native
> wayland wayland-protocols"
>  PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
>
>  # these plugins have not been ported to 1.0 (yet):
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> new file mode 100644
> index 000..eb789df
> --- /dev/null
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-bad/0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> @@ -0,0 +1,37 @@
> +From c271503d7e233428ac0323c51d6517113e26bef7 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Thu, 1 Dec 2016 00:27:13 -0800
> +Subject: [PATCH] Prepend PKG_CONFIG_SYSROOT_DIR to pkg-config output
> +
> +In cross environment we have to prepend the sysroot to the path found by
> +pkgconfig since the path returned from pkgconfig does not have sysroot
> prefixed
> +it ends up using the files from host system. If build host has wayland
> installed
> +the build will succeed but if you dont have wayland-protocols installed
> on build host then
> +it wont find the files on build host
> +
> +This should work ok with non sysrooted builds too since in those cases
> PKG_CONFIG_SYSROOT_DIR
> +will be empty
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj 
> +---
> + configure.ac | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/configure.ac b/configure.ac
> +index f8ac96b..dc87b08 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -2233,7 +2233,7 @@ AG_GST_CHECK_FEATURE(WAYLAND, [wayland sink],
> wayland , [
> + PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, wayland-protocols >= 1.4, [
> +   if test "x$wayland_scanner" != "x"; then
> + HAVE_WAYLAND="yes"
> +-AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG
> --variable=pkgdatadir wayland-protocols`)
> ++AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, 
> ${PKG_CONFIG_SYSROOT_DIR}`$PKG_CONFIG
> --variable=pkgdatadir wayland-protocols`)
>

I believe this breaks multilib because wayland-protocols is allarch so
PKG_CONFIG_SYSROOT_DIR may then be incorrect.

I've set "WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}"
in EXTRA_OECONF in other recipes and used that variable in the patches.
It's not pretty but seems to work.

Jussi

+   else
> + AC_MSG_RESULT([wayland-scanner is required to build the wayland
> plugin])
> + HAVE_WAYLAND="no"
> +--
> +2.10.2
> +
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-bad_1.10.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-bad_1.10.1.bb
> index 9cd892e..6c6f011 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.1.bb
> @@ -14,6 +14,7 @@ SRC_URI = " \
>  file://0001-gstreamer-gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch
> \
>  file://0009-glimagesink-Downrank-to-marginal.patch \
>  file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch
> \
> +file://0001-Prepend-PKG_CONFIG_SYSROOT_DIR-to-pkg-config-output.patch
> \
>  "
>  SRC_URI[md5sum] = "491d2d5aab55ffc60c66e714d3d664ea"
>  SRC_URI[sha256sum] = "133e0ed9fe21011b15d3898e3d3a9d
> 17ab74eed31996da2e353353e688ca921d"
> --
> 2.10.2
>
> --
> ___
> Open

Re: [OE-core] [PATCH v2] uninative: rebuild uninative for gcc 4.8 and 4.9

2016-12-05 Thread Burton, Ross

This fails on the AB when generating a eSDK, eg
http://errors.yoctoproject.org/Errors/Details/110635/

I suspect the cause is that the sstate is generated using the (eg)
universal-4.9 name, but populate_sdk_ext still uses just "universal" when
creating a mirror of the sstate archive.

Ross

On 8 November 2016 at 08:11, Ed Bartosh  wrote:

> Some c++ libraries fail to build if uninative is built
> with gcc 5.x and host gcc version is either 4.8 or 4.9.
>
> The issue should be solved by making separate uninative sstate
> directory structure sstate-cache/universal- for host gcc
> versions 4.8 and 4.9. This causes rebuilds of uninative if host gcc
> is either 4.8 or 4.9 and it doesn't match gcc version used to build
> uninative.
>
> [YOCTO #10441]
>
> Signed-off-by: Ed Bartosh 
> ---
>  meta/classes/uninative.bbclass | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.
> bbclass
> index 89cec07..3862b31 100644
> --- a/meta/classes/uninative.bbclass
> +++ b/meta/classes/uninative.bbclass
> @@ -95,11 +95,25 @@ python uninative_event_enable() {
>  enable_uninative(d)
>  }
>
> +def gcc_version(d):
> +compiler = d.getVar("BUILD_CC", True)
> +retval, output = oe.utils.getstatusoutput("%s --version" % compiler)
> +if retval:
> +bb.fatal("Error running %s --version: %s" % (compiler, output))
> +
> +import re
> +match = re.match(".* (\d\.\d)\.\d.*", output.split('\n')[0])
> +if not match:
> +bb.fatal("Can't get compiler version from %s --version output" %
> compiler)
> +
> +version = match.group(1)
> +return "-%s" % version if version in ("4.8", "4.9") else ""
> +
>  def enable_uninative(d):
>  loader = d.getVar("UNINATIVE_LOADER", True)
>  if os.path.exists(loader):
>  bb.debug(2, "Enabling uninative")
> -d.setVar("NATIVELSBSTRING", "universal")
> +d.setVar("NATIVELSBSTRING", "universal%s" % gcc_version(d))
>  d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
>  d.prependVar("PATH", "${STAGING_DIR}-uninative/${
> BUILD_ARCH}-linux${bindir_native}:")
>
> --
> 2.1.4
>
> --
> ___
> 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] non-standard library locations and rpath

2016-12-05 Thread Jack Mitchell




On 05/12/16 10:44, Jack Mitchell wrote:

On 02/12/16 07:08, Khem Raj wrote:

On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell  wrote:

I'm having some troubles with shared library, shared library
dependencies
and rpaths. I have libfoo, which depends on libbar when I try to link
libfoo
with my app, it requires libbar to be found. libbar is in a non-standard
location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now
when I
come to try link my app with libfoo, it fails to link as it can't find
libbar, which I assume means the rpath in libfoo isn't being properly
prepending with sysroot what is the proper way to support this in OE? My
library has the following rpath information:

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I
compile my
app and link libfoo? The apps build system is using cmake, but this
should
be a built in linker feature, correct?


Only first path ( before :) is relative to location of binary at runtime



Exactly, so how can you make an OE build use the rpaths of libs that
point to the build sysroot. What I have at the moment is

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE
sees the rpath in it's cross compile environment it should prepend it
with the build sysroot so you end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]

And then the SDK should end up with something like

0x000f (RPATH) Library rpath:
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]

Is this what is expected to happen, or am I stumbling into an
unsupported scenario.

Cheers,


I think basically what I'm saying is that does the linker prepend it's 
--sysroot value to absolute rpaths, and if not, should it?

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

Re: [OE-core] non-standard library locations and rpath

2016-12-05 Thread Jack Mitchell


On 02/12/16 07:08, Khem Raj wrote:

On Thu, Dec 1, 2016 at 8:18 AM, Jack Mitchell  wrote:

I'm having some troubles with shared library, shared library dependencies
and rpaths. I have libfoo, which depends on libbar when I try to link libfoo
with my app, it requires libbar to be found. libbar is in a non-standard
location, /usr/local/bar when I compiled libfoo, I used -Wl,rpath-link
${STAGING_SYSROOT}/usr/local/bar and -Wl,rpath /usr/local/bar. Now when I
come to try link my app with libfoo, it fails to link as it can't find
libbar, which I assume means the rpath in libfoo isn't being properly
prepending with sysroot what is the proper way to support this in OE? My
library has the following rpath information:

0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

So why isn't the rpath being prepended with the sysroot when I compile my
app and link libfoo? The apps build system is using cmake, but this should
be a built in linker feature, correct?


Only first path ( before :) is relative to location of binary at runtime



Exactly, so how can you make an OE build use the rpaths of libs that 
point to the build sysroot. What I have at the moment is


0x000f (RPATH) Library rpath: [$ORIGIN/../lib:/usr/local/bar]

Which would be correct if I was linking on the target. However when OE 
sees the rpath in it's cross compile environment it should prepend it 
with the build sysroot so you end up with something like


0x000f (RPATH) Library rpath: 
[$ORIGIN/../lib:/path/to/build/sysroot/usr/local/bar]


And then the SDK should end up with something like

0x000f (RPATH) Library rpath: 
[$ORIGIN/../lib:/path/to/sdk/sysroot/usr/local/bar]


Is this what is expected to happen, or am I stumbling into an 
unsupported scenario.


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

[OE-core] [PATCH][krogoth] bash: fix CVE-2016-7543

2016-12-05 Thread Sona Sarmadi

Specially crafted SHELLOPTS+PS4 variables allows command substitution

References:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7543
http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html

Signed-off-by: Sona Sarmadi 
---
 .../recipes-extended/bash/bash/CVE-2016-7543.patch | 38 ++
 meta/recipes-extended/bash/bash_4.3.30.bb  |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 meta/recipes-extended/bash/bash/CVE-2016-7543.patch

diff --git a/meta/recipes-extended/bash/bash/CVE-2016-7543.patch 
b/meta/recipes-extended/bash/bash/CVE-2016-7543.patch
new file mode 100644
index 000..7c9a9c6
--- /dev/null
+++ b/meta/recipes-extended/bash/bash/CVE-2016-7543.patch
@@ -0,0 +1,38 @@
+bash: fix CVE-2016-7543
+
+Bug-Reference-URL:
+http://lists.gnu.org/archive/html/bug-bash/2015-12/msg00054.html
+
+Bug-Description:
+
+If a malicious user can inject a value of $SHELLOPTS containing `xtrace'
+and a value for $PS4 that includes a command substitution into a shell
+running as root, bash will expand the command substitution as part of
+expanding $PS4 when it executes a traced command.
+
+Patch (apply with `patch -p0'):
+
+CVE: CVE-2016-7543
+Upstream-Status: Backport
+[changes in patchlevel.h has been removed from original patch]
+
+Reference to upstream patch:
+http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html
+
+Signed-off-by: Sona Sarmadi 
+diff -Nurp a/variables.c b/variables.c
+--- a/variables.c  2016-12-05 09:49:39.552587211 +0100
 b/variables.c  2016-12-05 09:52:00.406522230 +0100
+@@ -495,7 +495,11 @@ initialize_shell_variables (env, privmod
+ #endif
+   set_if_not ("PS2", secondary_prompt);
+ }
+-  set_if_not ("PS4", "+ ");
++
++  if (current_user.euid == 0)
++bind_variable ("PS4", "+ ", 0);
++  else
++set_if_not ("PS4", "+ ");
+ 
+   /* Don't allow IFS to be imported from the environment. */
+   temp_var = bind_variable ("IFS", " \t\n", 0);
diff --git a/meta/recipes-extended/bash/bash_4.3.30.bb 
b/meta/recipes-extended/bash/bash_4.3.30.bb
index fcd6caf..fdad39b 100644
--- a/meta/recipes-extended/bash/bash_4.3.30.bb
+++ b/meta/recipes-extended/bash/bash_4.3.30.bb
@@ -22,6 +22,7 @@ SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
file://run-ptest \
   file://fix-run-builtins.patch \
file://CVE-2016-0634.patch;striplevel=0 \
+   file://CVE-2016-7543.patch \
"
 
 SRC_URI[tarball.md5sum] = "a27b3ee9be83bd3ba448c0ff52b28447"
-- 
1.9.1

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

Re: [OE-core] [PATCH] strace: 4.13 -> 4.14

2016-12-05 Thread Burton, Ross

This and your other patches are under testing now.

On 5 December 2016 at 02:38, Huang, Qiyu 
wrote:

> ping
>
> > -Original Message-
> > From: Huang, Qiyu/黄 琦宇
> > Sent: Wednesday, November 30, 2016 8:03 PM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Huang, Qiyu/黄 琦宇 
> > Subject: [OE-core] [PATCH] strace: 4.13 -> 4.14
> >
> > From: Huang Qiyu 
> >
> > Upgrade strace from 4.13 to 4.14.
> >
> > Signed-off-by: Huang Qiyu 
> > ---
> >  meta/recipes-devtools/strace/{strace_4.13.bb => strace_4.14.bb} | 4
> ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)  rename
> > meta/recipes-devtools/strace/{strace_4.13.bb => strace_4.14.bb} (91%)
> >
> > diff --git a/meta/recipes-devtools/strace/strace_4.13.bb
> > b/meta/recipes-devtools/strace/strace_4.14.bb
> > similarity index 91%
> > rename from meta/recipes-devtools/strace/strace_4.13.bb
> > rename to meta/recipes-devtools/strace/strace_4.14.bb
> > index cae7f21..452925c 100644
> > --- a/meta/recipes-devtools/strace/strace_4.13.bb
> > +++ b/meta/recipes-devtools/strace/strace_4.14.bb
> > @@ -15,8 +15,8 @@ SRC_URI =
> > "${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.xz \
> > file://mips-SIGEMT.patch \
> > "
> >
> > -SRC_URI[md5sum] = "4b78c7febdd24c79d5147824d1a080a3"
> > -SRC_URI[sha256sum] =
> > "d48f732576c91ece36a5843d63f9be054c40ef59f1e4773986042636861625d7"
> > +SRC_URI[md5sum] = "1e39b5f7583256d7dc21170b9da529ae"
> > +SRC_URI[sha256sum] =
> > "5bed5110b243dce6864bedba269446c18c8c63f553cdd7fd4f808d89a764712f"
> >
> >  inherit autotools ptest bluetooth
> >
> > --
> > 2.7.4
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v1] wic: Add --exclude-path option to rootfs source plugin.

2016-12-05 Thread Kristian Amlie

On 02/12/16 16:05, Ed Bartosh wrote:
> On Fri, Dec 02, 2016 at 03:36:47PM +0100, Kristian Amlie wrote:
>> What are the thoughts on having a similar --exclude-path mechanism for
>> the standard rootfs building? IOW, the do_image_ext4 and friends?
> 
> That's a great idea! If source rootfs direcotry contains only requred
> content then we don't even need to change wic code. It's much better
> then implementing the same functionality in wic and in oe code.

Right, I didn't even consider it like that. But yeah, theoretically we
could drop the wic variant if you only use fsimage in your wks file.

But I think they sort of complement each other though. Since the rootfs
plugin does exist in wic, it makes sense that it would also support
--exclude-path. If you have a partition setup like this:

part1: Everything except /usr
part2: Everything inside /usr except /usr/share
part3: /usr/share

This would not be possible without --exclude-path support in wic, since
part2 would have to be constructed using the wic rootfs plugin, but
would need to exclude /usr/share.

In any case, I will definitely look at implementing the do_image_ext4
variant as well. I'll post more info about that when I have it.

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

Re: [OE-core] [PATCHv2 2/3] oeqa/utils/metadata.py: Add metadata library

2016-12-05 Thread Markus Lehtonen

On Thu, 2016-12-01 at 09:37 -0600, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> Adds functions to get metadata from the host running the tests.
> 
> [YOCTO #9954]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  meta/lib/oeqa/utils/metadata.py | 83
> +
>  1 file changed, 83 insertions(+)
>  create mode 100644 meta/lib/oeqa/utils/metadata.py
> 
> diff --git a/meta/lib/oeqa/utils/metadata.py
> b/meta/lib/oeqa/utils/metadata.py
> new file mode 100644
> index 000..ecbe763
> --- /dev/null
> +++ b/meta/lib/oeqa/utils/metadata.py
> @@ -0,0 +1,83 @@
> +# Copyright (C) 2016 Intel Corporation
> +#
> +# Released under the MIT license (see COPYING.MIT)
> +#
> +# Functions to get metadata from the testing host used
> +# for analytics of test results.
> +
> +from git import Repo, InvalidGitRepositoryError, NoSuchPathError

We introduce a dependency on GitPython(?) If we do this, it should at least
be mentioned somewhere as a new required dependency. There is also
oeqa.utils.git which could be used (and extended).



> +from collections import OrderedDict
> +from collections.abc import MutableMapping
> +from xml.dom.minidom import parseString
> +from xml.etree.ElementTree import Element, tostring
> +
> +from oe.lsb import distro_identifier
> +from oeqa.utils.commands import runCmd, get_bb_var, get_bb_vars
> +
> +metadata_vars = ['MACHINE', 'DISTRO', 'DISTRO_VERSION']
> +
> +def metadata_from_bb():
> +""" Returns test's metadata as OrderedDict.
> +
> +Data will be gathered using bitbake -e thanks to get_bb_vars.
> +"""
> +
> +info_dict = OrderedDict()
> +hostname = runCmd('hostname')
> +info_dict['hostname'] = hostname.output
> +data_dict = get_bb_vars(metadata_vars)
> +for var in metadata_vars:
> +info_dict[var.lower()] = data_dict[var]
> +host_distro= distro_identifier()
> +host_distro, _, host_distro_release = host_distro.partition('-')
> +info_dict['host_distro'] = host_distro
> +info_dict['host_distro_release'] = host_distro_release
> +info_dict['layers'] = get_layers(get_bb_var('BBLAYERS'))
> +return info_dict

I think it would be better to have a distro revision (i.e. the "main
revision" or "revision of the main repository", for example oe-core or
poky) and only list additional layers that are not included in the main
repository.


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

50 matches

Mail list logo