[OE-core] [PATCH] boost.inc: enable more verbose build logs

[Andre McCurdy]

The default build output is very terse. Add -d+2 (ie "Show commands
as they are executed") to BJAM_OPTS to make the do_compile logs more
informative.

Also add -q (ie "Stop at first error") to BJAM_OPTS and fix typo in
comments.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-support/boost/boost.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 79c4e63..c55221f 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -115,7 +115,7 @@ BJAM_TOOLS   = "--ignore-site-config \
'--layout=system' \
"
 
-# use PARALLEL_MAKE to speed up the build, but limit it by -j 64, greater 
paralelism causes bjam to segfault or to ignore -j
+# use PARALLEL_MAKE to speed up the build, but limit it by -j 64, greater 
parallelism causes bjam to segfault or to ignore -j
 # https://svn.boost.org/trac/boost/ticket/7634
 def get_boost_parallel_make(d):
 pm = d.getVar('PARALLEL_MAKE', True)
@@ -140,7 +140,7 @@ def get_boost_parallel_make(d):
 return ""
 
 BOOST_PARALLEL_MAKE = "${@get_boost_parallel_make(d)}"
-BJAM_OPTS= '${BOOST_PARALLEL_MAKE} \
+BJAM_OPTS= '${BOOST_PARALLEL_MAKE} -d+2 -q \
${BJAM_TOOLS} \

-sBOOST_BUILD_USER_CONFIG=${S}/tools/build/example/user-config.jam \
--builddir=${S}/${TARGET_SYS} \
-- 
1.9.1

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

Re: [OE-core] python-setuptools fetch issues Was: [oe] [meta-python][PATCH 08/11] python-mock: update to 1.3.0

[Burton, Ross]

On 24 February 2016 at 16:20, Martin Jansa  wrote:

> distutils.errors.DistutilsError: Could not find suitable distribution for
> Requirement.parse('pbr>=1.3')
>

Missing DEPENDS?

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

[OE-core] [PATCH 1/4] gstreamer1.0-libav_git: add --ranlib option to LIBAV_EXTRA_CONFIGURE_COMMON_ARG

[Andre McCurdy]

The versioned gstreamer1.0-libav recipe includes --ranlib in
LIBAV_EXTRA_CONFIGURE_COMMON_ARG, but the git recipe does not.
It appears to be a historical mistake.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
index 1957a5a..428d401 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
@@ -35,6 +35,7 @@ S = "${WORKDIR}/git"
 
 LIBAV_EXTRA_CONFIGURE_COMMON_ARG = "--target-os=linux \
   --cc='${CC}' --as='${CC}' --ld='${CC}' --nm='${NM}' --ar='${AR}' \
+  --ranlib='${RANLIB}' \
   ${GSTREAMER_1_0_DEBUG} \
   --cross-prefix='${HOST_PREFIX}'"
 
-- 
1.9.1

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

[OE-core] [PATCH 0/4] minor gstreamer recipe cleanups

[Andre McCurdy]

Andre McCurdy (4):
  gstreamer1.0-libav_git: add --ranlib option to 
LIBAV_EXTRA_CONFIGURE_COMMON_ARG
  gstreamer1.0-libav: move LIBAV_EXTRA_CONFIGURE_COMMON_ARG into .inc
  gstreamer1.0.inc: add explicit PACKAGECONFIG init
  gstreamer1.0-plugins-XXX: move inherit gettext into common .inc file

 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc| 7 +++
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.6.3.bb   | 6 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb | 5 -
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc  | 2 +-
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc | 2 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc | 2 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc | 2 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc  | 2 +-
 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc  | 2 ++
 9 files changed, 11 insertions(+), 19 deletions(-)

-- 
1.9.1

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

[OE-core] [PATCH 4/4] gstreamer1.0-plugins-XXX: move inherit gettext into common .inc file

[Andre McCurdy]

gstreamer1.0-plugins-base/good/bad/ugly.inc all independently inherit
gettext. Move into the common gstreamer1.0-plugins.inc include file.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc  | 2 +-
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc | 2 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc | 2 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc | 2 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc  | 2 +-
 5 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index cb6cbad..6117e69 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -4,7 +4,7 @@ LICENSE = "GPLv2+ & LGPLv2+ & LGPLv2.1+"
 
 DEPENDS += "gstreamer1.0-plugins-base libpng jpeg"
 
-inherit gettext bluetooth
+inherit bluetooth
 
 # opengl packageconfig factored out to make it easy for distros
 # and BSP layers to pick either (desktop) opengl, gles2, or no GL
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc
index e04096c..cde0019 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc
@@ -4,8 +4,6 @@ LICENSE = "GPLv2+ & LGPLv2+"
 
 DEPENDS += "iso-codes util-linux zlib"
 
-inherit gettext
-
 PACKAGES_DYNAMIC =+ "^libgst.*"
 
 PACKAGECONFIG ??= " \
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc
index 8f996d6..3f56d1d 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc
@@ -4,8 +4,6 @@ LICENSE = "GPLv2+ & LGPLv2.1+"
 
 DEPENDS += "gstreamer1.0-plugins-base libcap zlib bzip2"
 
-inherit gettext
-
 PACKAGECONFIG ??= " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', 
d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
index 869022a..839ff8a 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
@@ -5,8 +5,6 @@ LICENSE_FLAGS = "commercial"
 
 DEPENDS += "gstreamer1.0-plugins-base libid3tag"
 
-inherit gettext
-
 PACKAGECONFIG ??= " \
 a52dec lame mad mpeg2dec orc \
 "
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
index 6ea911e..d2b3820 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
@@ -5,7 +5,7 @@ SECTION = "multimedia"
 
 DEPENDS = "gstreamer1.0 glib-2.0-native"
 
-inherit autotools pkgconfig upstream-version-is-even
+inherit autotools pkgconfig gettext upstream-version-is-even
 
 acpaths = "-I ${S}/common/m4 -I ${S}/m4"
 
-- 
1.9.1

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

[OE-core] [PATCH 3/4] gstreamer1.0.inc: add explicit PACKAGECONFIG init

[Andre McCurdy]

Although gstreamer1.0.inc doesn't currently set any default
PACKAGECONFIG options, add explicit initialisation in order to
match the style / structure of the other gstreamer1.0 recipes.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
index 662cd1a..5c212e6 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
@@ -10,6 +10,8 @@ DEPENDS = "glib-2.0 glib-2.0-native libcap libxml2 
bison-native flex-native"
 
 inherit autotools pkgconfig gettext upstream-version-is-even
 
+PACKAGECONFIG ??= ""
+
 PACKAGECONFIG[check] = "--enable-check,--disable-check"
 PACKAGECONFIG[debug] = "--enable-debug,--disable-debug"
 PACKAGECONFIG[tests] = "--enable-tests,--disable-tests"
-- 
1.9.1

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

[OE-core] [PATCH 2/4] gstreamer1.0-libav: move LIBAV_EXTRA_CONFIGURE_COMMON_ARG into .inc

[Andre McCurdy]

The LIBAV_EXTRA_CONFIGURE_COMMON_ARG definition is now common to both
the git and the versioned gstreamer1.0-libav recipes, so move it into
gstreamer1.0-libav.inc

Signed-off-by: Andre McCurdy 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc  | 7 +++
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.6.3.bb | 6 --
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb   | 6 --
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
index c90af66..598a349 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
@@ -22,6 +22,13 @@ PACKAGECONFIG[yasm] = 
"--enable-yasm,--disable-yasm,yasm-native"
 GSTREAMER_1_0_DEBUG ?= "--disable-debug"
 
 LIBAV_EXTRA_CONFIGURE = "--with-libav-extra-configure"
+
+LIBAV_EXTRA_CONFIGURE_COMMON_ARG = "--target-os=linux \
+  --cc='${CC}' --as='${CC}' --ld='${CC}' --nm='${NM}' --ar='${AR}' \
+  --ranlib='${RANLIB}' \
+  ${GSTREAMER_1_0_DEBUG} \
+  --cross-prefix='${HOST_PREFIX}'"
+
 LIBAV_EXTRA_CONFIGURE_COMMON = \
 '${LIBAV_EXTRA_CONFIGURE}="${LIBAV_EXTRA_CONFIGURE_COMMON_ARG}"'
 
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.6.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.6.3.bb
index ba7ac7f..687230a 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.6.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.6.3.bb
@@ -18,9 +18,3 @@ SRC_URI[md5sum] = "cfe9a06913d4fd4067e9e47f6e05fac2"
 SRC_URI[sha256sum] = 
"857b9c060a0337de38c6d26238c47352433c02eabf26c2f860c854dbc35bd4ab"
 
 S = "${WORKDIR}/gst-libav-${PV}"
-
-LIBAV_EXTRA_CONFIGURE_COMMON_ARG = "--target-os=linux \
-  --cc='${CC}' --as='${CC}' --ld='${CC}' --nm='${NM}' --ar='${AR}' \
-  --ranlib='${RANLIB}' \
-  ${GSTREAMER_1_0_DEBUG} \
-  --cross-prefix='${HOST_PREFIX}'"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
index 428d401..ebc8a5e 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
@@ -33,12 +33,6 @@ SRCREV_FORMAT = "base"
 
 S = "${WORKDIR}/git"
 
-LIBAV_EXTRA_CONFIGURE_COMMON_ARG = "--target-os=linux \
-  --cc='${CC}' --as='${CC}' --ld='${CC}' --nm='${NM}' --ar='${AR}' \
-  --ranlib='${RANLIB}' \
-  ${GSTREAMER_1_0_DEBUG} \
-  --cross-prefix='${HOST_PREFIX}'"
-
 do_configure_prepend() {
${S}/autogen.sh --noconfigure
 }
-- 
1.9.1

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

[OE-core] [PATCH] boost.inc: limit ARM_INSTRUCTION_SET over-rides to armv4/armv5

[Andre McCurdy]

The original over-ride dates back to 2009:

  
http://git.openembedded.org/openembedded-core/commit/?id=43e94412c45b4b79485a64010c76d89b245bb235

There are no obvious issues seen now when building boost in thumb2
for Cortex A15.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-support/boost/boost.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 981e6ee..79c4e63 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -2,7 +2,8 @@ SUMMARY = "Free peer-reviewed portable C++ source libraries"
 SECTION = "libs"
 DEPENDS = "bjam-native zlib bzip2"
 
-ARM_INSTRUCTION_SET = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
 
 BOOST_LIBS = "\
atomic \
-- 
1.9.1

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

Re: [OE-core] [PATCH 1/3] cve-check-tool: Add recipe

[Burton, Ross]

On 24 February 2016 at 15:27,  wrote:

> +python () {
> +# If the cve-check class is inherited it is needed to populate the
> +# CVE database before checking the CVEs for all recipes.
> +pn = d.getVar("PN", True)
> +if pn.endswith("-native") and bb.data.inherits_class('cve-check', d):
> +bb.build.addtask("do_populate_cve_db", "do_build",
> "do_populate_sysroot", d)
> +}
>

Wouldn't this be better done as an explicit dependency of the class task?

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

Re: [OE-core] [PATCHv2 4/4] oeqa/sdkext: Add sdk_update.SDKUpdateTest class.

[Paul Eggleton]

Hi Aníbal,

On Mon, 22 Feb 2016 12:31:33 Aníbal Limón wrote:
> From: Aníbal Limón 
> 
> The SDKUpdateTest class test devtool sdk-update mechanism inside
> eSDK.
> 
> The SDKUpdateTest class search for new sdk if not found uses
> the main one then it publish the eSDK into known folder
> inside work and it starts a web server for serve the eSDK.
> 
> Finally it executes sdk-update over http, the local test is
> commented due to bug [1].
> 
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=9043
> 
> [YOCTO #9089]
> 
> Signed-off-by: Aníbal Limón 
> ---
>  meta/lib/oeqa/sdkext/sdk_update.py | 39
> ++ 1 file changed, 39 insertions(+)
>  create mode 100644 meta/lib/oeqa/sdkext/sdk_update.py
> 
> diff --git a/meta/lib/oeqa/sdkext/sdk_update.py
> b/meta/lib/oeqa/sdkext/sdk_update.py new file mode 100644
> index 000..16f5b10
> --- /dev/null
> +++ b/meta/lib/oeqa/sdkext/sdk_update.py
> @@ -0,0 +1,39 @@
> +import os
> +import shutil
> +import subprocess
> +
> +from oeqa.oetest import oeSDKExtTest
> +from oeqa.utils.httpserver import HTTPService
> +
> +class SdkUpdateTest(oeSDKExtTest):
> +
> +@classmethod
> +def setUpClass(self):
> +self.publish_dir = os.path.join(self.tc.sdktestdir, 'esdk_publish')
> +if os.path.exists(self.publish_dir):
> +shutil.rmtree(self.publish_dir)
> +os.mkdir(self.publish_dir)
> +
> +tcname_new = self.tc.d.expand(
> +"${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}-new.sh")
> +if not os.path.exists(tcname_new):
> +tcname_new = self.tc.tcname
> +
> +cmd = 'oe-publish-sdk %s %s' % (tcname_new, self.publish_dir)
> +subprocess.check_output(cmd, shell=True)
> +
> +self.http_service = HTTPService(self.publish_dir)
> +self.http_service.start()
> +
> +self.http_url = "http://127.0.0.1:%d; % self.http_service.port
> +
> +def test_sdk_update_http(self):
> +output = self._run("devtool sdk-update \"%s\"" % self.http_url)
> +
> +#def test_sdk_update_local(self):
> +#output = self._run("devtool sdk-update \"%s\"" % self.publish_dir)
> +
> +@classmethod
> +def tearDownClass(self):
> +self.http_service.stop()
> +shutil.rmtree(self.publish_dir)

You're testing invocation of the sdk-update command, but nothing much beyond 
that - the update isn't going to be doing anything here since nothing will 
have changed. However since this would involve modifying the metadata though I 
guess that may have to be done as an oe-selftest test.

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

[OE-core] [PATCH] package: check inherit instead of PN to decide if a recipe is a packagegroup

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/classes/package.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 93b275c..ef80e50 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1911,8 +1911,7 @@ python package_depchains() {
 for pkg in pkglibdeps:
 for k in pkglibdeps[pkg]:
 add_dep(pkglibdeplist, k)
-# FIXME this should not look at PN once all task recipes inherit from 
task.bbclass
-dbgdefaultdeps = ((d.getVar('DEPCHAIN_DBGDEFAULTDEPS', True) == '1') 
or (d.getVar('PN', True) or '').startswith('packagegroup-'))
+dbgdefaultdeps = ((d.getVar('DEPCHAIN_DBGDEFAULTDEPS', True) == '1') 
or (bb.data.inherits_class('packagegroup', d)))
 
 for suffix in pkgs:
 for pkg in pkgs[suffix]:
-- 
2.7.0

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

[OE-core] [PATCH] uninative.bbclass: if the loader can't be found disable instead of failing

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/classes/uninative.bbclass | 64 +-
 1 file changed, 38 insertions(+), 26 deletions(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 270c1b0..0ca59d0 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -1,5 +1,3 @@
-NATIVELSBSTRING = "universal"
-
 UNINATIVE_LOADER ?= 
"${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/lib/${@bb.utils.contains('BUILD_ARCH',
 'x86_64', 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
 
 UNINATIVE_URL ?= "unset"
@@ -13,19 +11,16 @@ addhandler uninative_eventhandler
 uninative_eventhandler[eventmask] = "bb.event.BuildStarted"
 
 python uninative_eventhandler() {
-loader = e.data.getVar("UNINATIVE_LOADER", True)
+enabled = True
+
+loader = d.getVar("UNINATIVE_LOADER", True)
 tarball = d.getVar("UNINATIVE_TARBALL", True)
 tarballdir = d.getVar("UNINATIVE_DLDIR", True)
 tarballpath = os.path.join(tarballdir, tarball)
 
 if not os.path.exists(loader):
-import subprocess
-
-olddir = os.getcwd()
+# If the tarball doesn't exist, try to fetch it.
 if not os.path.exists(tarballpath):
-# Copy the data object and override DL_DIR and SRC_URI
-localdata = bb.data.createCopy(d)
-
 if d.getVar("UNINATIVE_URL", True) == "unset":
 bb.fatal("Uninative selected but not configured, please set 
UNINATIVE_URL")
 
@@ -33,31 +28,48 @@ python uninative_eventhandler() {
 if not chksum:
 bb.fatal("Uninative selected but not configured correctly, 
please set UNINATIVE_CHECKSUM[%s]" % d.getVar("BUILD_ARCH", True))
 
-srcuri = d.expand("${UNINATIVE_URL}${UNINATIVE_TARBALL};md5sum=%s" 
% chksum)
-localdata.setVar('FILESPATH', tarballdir)
-localdata.setVar('DL_DIR', tarballdir)
-bb.note("Fetching uninative binary shim from %s" % srcuri)
-fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
 try:
+# Save and restore cwd as Fetch.download() does a chdir()
+olddir = os.getcwd()
+
+localdata = bb.data.createCopy(d)
+localdata.setVar('FILESPATH', "")
+localdata.setVar('DL_DIR', tarballdir)
+
+srcuri = 
d.expand("${UNINATIVE_URL}${UNINATIVE_TARBALL};md5sum=%s" % chksum)
+bb.note("Fetching uninative binary shim from %s" % srcuri)
+
+fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
 fetcher.download()
 localpath = fetcher.localpath(srcuri)
 if localpath != tarballpath and os.path.exists(localpath) and 
not os.path.exists(tarballpath):
 os.symlink(localpath, tarballpath)
 except Exception as exc:
-bb.fatal("Unable to download uninative tarball: %s" % str(exc))
-
-cmd = e.data.expand("mkdir -p ${STAGING_DIR}-uninative; cd 
${STAGING_DIR}-uninative; tar -xjf ${UNINATIVE_DLDIR}/${UNINATIVE_TARBALL}; 
${STAGING_DIR}-uninative/relocate_sdk.py 
${STAGING_DIR}-uninative/${BUILD_ARCH}-linux ${UNINATIVE_LOADER} 
${UNINATIVE_LOADER} 
${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/${bindir_native}/patchelf-uninative")
-try:
-subprocess.check_call(cmd, shell=True)
-except subprocess.CalledProcessError as exc:
-bb.fatal("Unable to install uninative tarball: %s" % str(exc))
-os.chdir(olddir)
+bb.warn("Unable to download uninative tarball: %s" % str(exc))
+enabled = False
+finally:
+os.chdir(olddir)
+
+# If we're still enabled then the fetch didn't fail, so unpack the 
tarball
+if enabled:
+import subprocess
+try:
+cmd = d.expand("mkdir -p ${STAGING_DIR}-uninative; cd 
${STAGING_DIR}-uninative; tar -xjf ${UNINATIVE_DLDIR}/${UNINATIVE_TARBALL}; 
${STAGING_DIR}-uninative/relocate_sdk.py 
${STAGING_DIR}-uninative/${BUILD_ARCH}-linux ${UNINATIVE_LOADER} 
${UNINATIVE_LOADER} 
${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/${bindir_native}/patchelf-uninative")
+subprocess.check_call(cmd, shell=True)
+except subprocess.CalledProcessError as exc:
+bb.warn("Unable to install uninative tarball: %s" % str(exc))
+enabled = False
+
+if enabled:
+bb.note("Enabling uninative")
+d.setVar("NATIVELSBSTRING", "universal")
+d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
+d.prependVar("PATH", 
"${STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:")
+else:
+bb.warn("Uninative selected but the loader isn't present and can't be 
downloaded.  Disabling uninative.\n"
+"To build your own uninative loader, please bitbake 
uninative-tarball 

[OE-core] [PATCH] uninative: use check_output instead of Popen directly

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/classes/uninative.bbclass | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 7e225e6..270c1b0 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -83,12 +83,10 @@ python uninative_changeinterp () {
 except oe.qa.NotELFFileError:
 continue
 
-#bb.warn("patchelf-uninative --set-interpreter %s %s" % 
(d.getVar("UNINATIVE_LOADER", True), f))
-cmd = "patchelf-uninative --set-interpreter %s %s" % 
(d.getVar("UNINATIVE_LOADER", True), f)
-p = subprocess.Popen(cmd, shell=True,
- stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT)
-stdout, stderr = p.communicate()
-if p.returncode:
+try:
+subprocess.check_output(("patchelf-uninative", 
"--set-interpreter",
+ d.getVar("UNINATIVE_LOADER", True), 
f))
+except subprocess.CalledProcessError as e:
 bb.fatal("'%s' failed with exit code %d and the following 
output:\n%s" %
- (cmd, p.returncode, stdout))
+ (e.cmd, e.returncode, e.output))
 }
-- 
2.7.0

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

[OE-core] [PATCH] lib/oe/qa: add explicit exception for 'file isn't an ELF'

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/classes/insane.bbclass|  3 +--
 meta/classes/uninative.bbclass |  2 +-
 meta/lib/oe/qa.py  | 15 +--
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 8548961..ebf92ac 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -792,9 +792,8 @@ def package_qa_walk(warnfuncs, errorfuncs, skip, package, 
d):
 elf = oe.qa.ELFFile(path)
 try:
 elf.open()
-except (IOError, ValueError):
+except (IOError, oe.qa.NotELFFileError):
 # IOError can happen if the packaging control files disappear,
-# ValueError means the file isn't an ELF.
 elf = None
 for func in warnfuncs:
 func(path, package, d, elf, warnings)
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index b14cec0..7e225e6 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -80,7 +80,7 @@ python uninative_changeinterp () {
 elf = oe.qa.ELFFile(f)
 try:
 elf.open()
-except ValueError:
+except oe.qa.NotELFFileError:
 continue
 
 #bb.warn("patchelf-uninative --set-interpreter %s %s" % 
(d.getVar("UNINATIVE_LOADER", True), f))
diff --git a/meta/lib/oe/qa.py b/meta/lib/oe/qa.py
index 2ad6c63..4efa21f 100644
--- a/meta/lib/oe/qa.py
+++ b/meta/lib/oe/qa.py
@@ -1,3 +1,6 @@
+class NotELFFileError(Exception):
+pass
+
 class ELFFile:
 EI_NIDENT = 16
 
@@ -23,7 +26,7 @@ class ELFFile:
 def my_assert(self, expectation, result):
 if not expectation == result:
 #print "'%x','%x' %s" % (ord(expectation), ord(result), self.name)
-raise ValueError("%s is not an ELF" % self.name)
+raise NotELFFileError("%s is not an ELF" % self.name)
 
 def __init__(self, name, bits = 0):
 self.name = name
@@ -32,7 +35,7 @@ class ELFFile:
 
 def open(self):
 if not os.path.isfile(self.name):
-raise ValueError("%s is not a normal file" % self.name)
+raise NotELFFileError("%s is not a normal file" % self.name)
 
 self.file = file(self.name, "r")
 self.data = self.file.read(ELFFile.EI_NIDENT+4)
@@ -49,24 +52,24 @@ class ELFFile:
 self.bits = 64
 else:
 # Not 32-bit or 64.. lets assert
-raise ValueError("ELF but not 32 or 64 bit.")
+raise NotELFFileError("ELF but not 32 or 64 bit.")
 elif self.bits == 32:
 self.my_assert(self.data[ELFFile.EI_CLASS], 
chr(ELFFile.ELFCLASS32))
 elif self.bits == 64:
 self.my_assert(self.data[ELFFile.EI_CLASS], 
chr(ELFFile.ELFCLASS64))
 else:
-raise ValueError("Must specify unknown, 32 or 64 bit size.")
+raise NotELFFileError("Must specify unknown, 32 or 64 bit size.")
 self.my_assert(self.data[ELFFile.EI_VERSION], chr(ELFFile.EV_CURRENT) )
 
 self.sex = self.data[ELFFile.EI_DATA]
 if self.sex == chr(ELFFile.ELFDATANONE):
-raise ValueError("self.sex == ELFDATANONE")
+raise NotELFFileError("self.sex == ELFDATANONE")
 elif self.sex == chr(ELFFile.ELFDATA2LSB):
 self.sex = "<"
 elif self.sex == chr(ELFFile.ELFDATA2MSB):
 self.sex = ">"
 else:
-raise ValueError("Unknown self.sex")
+raise NotELFFileError("Unknown self.sex")
 
 def osAbi(self):
 return ord(self.data[ELFFile.EI_OSABI])
-- 
2.7.0

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

[OE-core] [PATCH] db: use S/B more idiomatically

[Ross Burton]

Instead of setting S to a directory inside the tarball and B to another
directory inside the tarball, use the default value of S and set
AUTOTOOLS_SCRIPT_PATH to the right path to find configure.

Rebase two patches to reflect the change of patch root.

For some reason doing this results in the libtool binary appearing at the wrong
place, so always point LIBTOOL at the one in the sysroot and remove the sed
which doesn't seem to have a reason (added in a484b3 without explanation in
2013).

Signed-off-by: Ross Burton 
---
 ...akefile-let-libso_target-depend-on-bt_rec.patch |  4 +-
 .../recipes-support/db/db/fix-parallel-build.patch |  4 +-
 meta/recipes-support/db/db_6.0.30.bb   | 52 +-
 3 files changed, 25 insertions(+), 35 deletions(-)

diff --git 
a/meta/recipes-support/db/db/Makefile-let-libso_target-depend-on-bt_rec.patch 
b/meta/recipes-support/db/db/Makefile-let-libso_target-depend-on-bt_rec.patch
index 329bff5..9ec117a 100644
--- 
a/meta/recipes-support/db/db/Makefile-let-libso_target-depend-on-bt_rec.patch
+++ 
b/meta/recipes-support/db/db/Makefile-let-libso_target-depend-on-bt_rec.patch
@@ -17,8 +17,8 @@ Signed-off-by: Robert Yang 
 
 diff --git a/Makefile.in b/Makefile.in
 index e451f70..0a42375 100644
 a/Makefile.in
-+++ b/Makefile.in
+--- db/dist/Makefile.in
 db/dist/Makefile.in
 @@ -863,7 +863,7 @@ $(libdb_version): $(C_OBJS)
$(LN) -s $(libdb_version) $(libdb)
  
diff --git a/meta/recipes-support/db/db/fix-parallel-build.patch 
b/meta/recipes-support/db/db/fix-parallel-build.patch
index 2c7f1e1..88bc6b3 100644
--- a/meta/recipes-support/db/db/fix-parallel-build.patch
+++ b/meta/recipes-support/db/db/fix-parallel-build.patch
@@ -6,8 +6,8 @@ Upstream-Status: Pending
 
 Signed-off-by: Martin Jansa 
 
 dist.orig/Makefile.in  2012-05-11 19:57:48.0 +0200
-+++ dist/Makefile.in   2013-10-31 18:17:11.875532522 +0100
+--- db/dist.orig/Makefile.in   2012-05-11 19:57:48.0 +0200
 db/dist/Makefile.in2013-10-31 18:17:11.875532522 +0100
 @@ -1034,7 +1034,7 @@
db_recover@o@ util_sig@o@ $(DEF_LIB) $(LIBS)
$(POSTLINK) $@
diff --git a/meta/recipes-support/db/db_6.0.30.bb 
b/meta/recipes-support/db/db_6.0.30.bb
index 9505def..9475e82 100644
--- a/meta/recipes-support/db/db_6.0.30.bb
+++ b/meta/recipes-support/db/db_6.0.30.bb
@@ -17,11 +17,11 @@ RCONFLICTS_${PN} = "db3"
 
 RECIPE_NO_UPDATE_REASON = "Updating to 6.1.x requires also updating rpm to 
5.4.15"
 
-SRC_URI = "http://download.oracle.com/berkeley-db/db-${PV}.tar.gz;
-SRC_URI += "file://arm-thumb-mutex_db5.patch;patchdir=.. \
-file://fix-parallel-build.patch \
-file://Makefile-let-libso_target-depend-on-bt_rec.patch \
-file://Makefile-let-libdb-6.0.la-depend-os_map.l.patch;patchdir=.. 
\
+SRC_URI = "http://download.oracle.com/berkeley-db/db-${PV}.tar.gz \
+   file://arm-thumb-mutex_db5.patch \
+   file://fix-parallel-build.patch \
+   file://Makefile-let-libso_target-depend-on-bt_rec.patch \
+   file://Makefile-let-libdb-6.0.la-depend-os_map.l.patch \
"
 
 SRC_URI[md5sum] = "ad28eb86ad3203b5422844db179c585b"
@@ -31,9 +31,7 @@ SRC_URI[sha256sum] = 
"608e4b1cf390e9bf54c0ef00c5bd9ca76d36e2261b9f4d33d54516f3f6
 UPSTREAM_CHECK_REGEX = "db-(?P\d+\.\d+(\.\d+)?).tar"
 UPSTREAM_CHECK_URI = 
"http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html;
 
-LIC_FILES_CHKSUM = "file://../LICENSE;md5=1ec8b0b17cc31513fe35ab10716f8490"
-
-inherit autotools
+LIC_FILES_CHKSUM = "file://LICENSE;md5=1ec8b0b17cc31513fe35ab10716f8490"
 
 # Put virtual/db in any appropriate provider of a
 # relational database, use it as a dependency in
@@ -44,13 +42,7 @@ inherit autotools
 # to select the correct db in the build (distro) .conf
 PROVIDES += "${VIRTUAL_NAME}"
 
-# bitbake isn't quite clever enough to deal with sleepycat,
-# the distribution sits in the expected directory, but all
-# the builds must occur from a sub-directory.  The following
-# persuades bitbake to go to the right place
-S = "${WORKDIR}/db-${PV}/dist"
-B = "${WORKDIR}/db-${PV}/build_unix"
-SPDX_S = "${WORKDIR}/db-${PV}"
+inherit autotools
 
 # The executables go in a separate package - typically there
 # is no need to install these unless doing real database
@@ -60,7 +52,6 @@ inherit lib_package
 PACKAGES =+ "${PN}-cxx"
 FILES_${PN}-cxx = "${libdir}/*cxx*so"
 
-
 # The dev package has the .so link (as in db3) and the .a's -
 # it is therefore incompatible (cannot be installed at the
 # same time) as the db3 package
@@ -74,6 +65,17 @@ DB6_CONFIG ?= "--enable-o_direct --disable-cryptography 
--disable-queue --disabl
 
 EXTRA_OECONF = "${DB6_CONFIG} --enable-shared --enable-cxx --with-sysroot"
 
+# Cancel the site stuff - it's set for db3 and destroys the configure.
+CONFIG_SITE = ""
+
+AUTOTOOLS_SCRIPT_PATH = "${S}/dist"
+
+do_configure() {
+  

[OE-core] [PATCH 1/3] cve-check-tool: Add recipe

[mariano . lopez]

From: Mariano Lopez 

cve-check-tool is a program to for checking public CVEs.
This tool also seek to determine if a vulnerability has
been addressed by a patch.

The recipe also includes the do_populate_cve_db task
that will populate the database used by the tool. This
task is added when the cve-check class has been inherited.

[YOCTO #7515]

Co-authored by Elena Reshetova & Mariano Lopez

Signed-off-by: Mariano Lopez 
---
 .../cve-check-tool/cve-check-tool_5.6.bb   | 61 ++
 1 file changed, 61 insertions(+)
 create mode 100644 meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.bb

diff --git a/meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.bb 
b/meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.bb
new file mode 100644
index 000..b173eab
--- /dev/null
+++ b/meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.bb
@@ -0,0 +1,61 @@
+SUMMARY = "cve-check-tool"
+DESCRIPTION = "cve-check-tool is a tool for checking known (public) CVEs.\
+The tool will identify potentially vunlnerable software packages within Linux 
distributions through version matching."
+HOMEPAGE = "https://github.com/ikeydoherty/cve-check-tool;
+SECTION = "Development/Tools"
+LICENSE = "GPL-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=e8c1458438ead3c34974bc0be3a03ed6"
+
+SRC_URI = 
"https://github.com/ikeydoherty/${BPN}/releases/download/v${PV}/${BP}.tar.xz \
+file://change_logic_cve_get_file_parent.patch"
+
+SRC_URI[md5sum] = "30f32e6254580162eacfcc437a144463"
+SRC_URI[sha256sum] = 
"d35af2bfa014b9d7cdc9c59ec0bd7df40c22dfcd57244c9099c0aa9bdc9c0cb4"
+
+DEPENDS = "libcheck glib-2.0 json-glib curl libxml2 sqlite3 openssl"
+
+inherit pkgconfig autotools
+
+EXTRA_OECONF = "--disable-static"
+
+python () {
+# If the cve-check class is inherited it is needed to populate the
+# CVE database before checking the CVEs for all recipes.
+pn = d.getVar("PN", True)
+if pn.endswith("-native") and bb.data.inherits_class('cve-check', d):
+bb.build.addtask("do_populate_cve_db", "do_build", 
"do_populate_sysroot", d)
+}
+
+python do_populate_cve_db () {
+import subprocess
+import time
+from bb.utils import export_proxies
+
+export_proxies(d)
+fail_text = "Failed to update database"
+error_str = fail_text
+cve_dir = d.getVar("CVE_CHECK_DB_DIR", True)
+cmd = "cve-check-update -d %s" % cve_dir
+bb.debug(1, "Updating cve-check-tool database located in %s" % cve_dir)
+try:
+popen = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
+output, error = popen.communicate()
+bb.debug(2, "Command %s returned:\n%s" % (cmd, output.decode()))
+error_str = error.decode()
+bb.debug(2, "Command %s errors:\n%s" % (cmd, error_str))
+except:
+bb.warn("Error in executing cve-check-update: %s" % 
str(sys.exc_info()))
+
+if fail_text in error_str:
+bb.warn("Failed to update cve-check-tool database, CVEs won't be 
checked")
+else:
+utc_time = time.gmtime(time.time())
+format_time = "%Y-%m-%d %H:%M:%S"
+with open(d.getVar("CVE_CHECK_TMP_FILE", True), "w") as f:
+f.write("CVE database was updated on %s UTC\n\n"
+% time.strftime(format_time, utc_time))
+}
+
+do_populate_cve_db[nostamp] = "1"
+
+BBCLASSEXTEND = "native"
-- 
2.6.2

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

[OE-core] [PATCH 0/3] Add initial capability to check CVEs for recipes

[mariano . lopez]

From: Mariano Lopez 

This series add the cve-check-tool recipe, a tool used to identify
potentially vulnerable software through version matching. It will
check if a vulnerability has been addressed by a patch.

Also add the new cve-check class that will add a task for all recipes
to check for CVEs using cve-check-tool. This tool can be used by recipe,
image (will generate an image report in deploy dir), and with "world"
and "universe"

To run it just inherit the class and enter:

bitbake -c cve_check 

The following changes since commit 23056103c949b498c23b47579e8dd57ce78e6ed9:

  uclibc: Do not use immediate expansion operator (2016-02-22 20:42:48 +)

are available in the git repository at:

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

Mariano Lopez (3):
  cve-check-tool: Add recipe
  cve-check-tool patch to allow select dir for the db
  cve-check.bbclass: Add class

 meta/classes/cve-check.bbclass | 229 +
 .../change_logic_cve_get_file_parent.patch |  45 
 .../cve-check-tool/cve-check-tool_5.6.bb   |  61 ++
 3 files changed, 335 insertions(+)
 create mode 100644 meta/classes/cve-check.bbclass
 create mode 100644 
meta/recipes-devtools/cve-check-tool/cve-check-tool/change_logic_cve_get_file_parent.patch
 create mode 100644 meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.bb

-- 
2.6.2

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

[OE-core] [PATCH 3/3] cve-check.bbclass: Add class

[mariano . lopez]

From: Mariano Lopez 

This class adds a new task for all the recipes to use
cve-check-tool in order to look for public CVEs affecting
the packages generated.

It is possible to use this class when building an image,
building a recipe, or using the "world" or "universe" cases.

In order to use this class it must be inherited at some
point and it will add the task automatically to every recipe.

[YOCTO #7515]

Co-authored by Ross Burton & Mariano Lopez

Signed-off-by: Ross Burton 
Signed-off-by: Mariano Lopez 
---
 meta/classes/cve-check.bbclass | 229 +
 1 file changed, 229 insertions(+)
 create mode 100644 meta/classes/cve-check.bbclass

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
new file mode 100644
index 000..69d90f3
--- /dev/null
+++ b/meta/classes/cve-check.bbclass
@@ -0,0 +1,229 @@
+#
+CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvd.db"
+
+CVE_CHECK_LOCAL_DIR ?= "${WORKDIR}/cve"
+CVE_CHECK_LOCAL_FILE ?= "${CVE_CHECK_LOCAL_DIR}/cve.log"
+CVE_CHECK_TMP_FILE ?= "${TMPDIR}/cve_check"
+
+CVE_CHECK_DIR ??= "${DEPLOY_DIR}/cve"
+CVE_CHECK_MANIFEST ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cve"
+CVE_CHECK_COPY_FILES ??= "1"
+CVE_CHECK_CREATE_MANIFEST ??= "1"
+
+# Whitelist for packages (PN)
+cve_check_pn_whitelist () {
+glibc-locale
+}
+
+# Whitelist for CVE and version of package
+python cve_check_cve_whitelist () {
+{"CVE-2014-2524": ("6.3",), \
+}
+}
+
+python do_cve_check () {
+"""
+Check recipe for patched and unpatched CVEs
+"""
+
+if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", True)):
+patched_cves = get_patches_cves(d)
+patched, unpatched = check_cves(d, patched_cves)
+if patched or unpatched:
+cve_data = get_cve_info(d, patched + unpatched)
+cve_write_data(d, patched, unpatched, cve_data)
+else:
+bb.note("Failed to update CVE database, skipping CVE check")
+}
+
+addtask cve_check before do_build
+do_cve_check[depends] = "cve-check-tool-native:do_populate_cve_db"
+do_cve_check[nostamp] = "1"
+
+python cve_check_cleanup () {
+"""
+Delete the file used to gather all the CVE information.
+"""
+import bb.utils
+
+tmp_file = e.data.getVar("CVE_CHECK_TMP_FILE", True)
+bb.utils.remove(tmp_file)
+}
+
+addhandler cve_check_cleanup
+cve_check_cleanup[eventmask] = "bb.cooker.CookerExit"
+
+python cve_check_write_rootfs_manifest () {
+"""
+Create CVE manifest when building an image
+"""
+
+import shutil
+from bb.utils import mkdirhier
+
+if os.path.exists(d.getVar("CVE_CHECK_TMP_FILE", True)) and \
+d.getVar("CVE_CHECK_CREATE_MANIFEST", True) == "1":
+bb.note("Writing rootfs CVE manifest")
+deploy_dir = d.getVar("DEPLOY_DIR_IMAGE", True)
+link_name = d.getVar("IMAGE_LINK_NAME", True)
+manifest_name = d.getVar("CVE_CHECK_MANIFEST", True)
+cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE", True)
+
+shutil.copyfile(cve_tmp_file, manifest_name)
+
+if manifest_name is not None and os.path.exists(manifest_name):
+manifest_link = os.path.join(deploy_dir, "%s.cve" % link_name)
+if os.path.exists(manifest_link):
+if d.getVar('RM_OLD_IMAGE', True) == "1" and \
+os.path.exists(os.path.realpath(manifest_link)):
+os.remove(os.path.realpath(manifest_link))
+os.remove(manifest_link)
+os.symlink(os.path.basename(manifest_name), manifest_link)
+bb.plain("Image CVE report stored in: %s" % manifest_name)
+}
+
+ROOTFS_POSTPROCESS_COMMAND_prepend = "cve_check_write_rootfs_manifest; "
+
+
+def get_patches_cves(d):
+"""
+Get patches that solve CVEs using the "CVE: " tag.
+"""
+
+import re
+
+pn = d.getVar("PN", True)
+cve_match = re.compile("CVE:( CVE\-\d+\-\d+)+")
+patched_cves = set()
+for url in src_patches(d):
+patch_file = bb.fetch.decodeurl(url)[2]
+with open(patch_file, "r") as f:
+patch_text = f.read()
+
+# Search for the "CVE: " line
+match = cve_match.search(patch_text)
+if match:
+# Get only the CVEs without the "CVE: " tag
+cves = patch_text[match.start()+5:match.end()]
+for cve in cves.split():
+patched_cves.add(cve)
+
+return patched_cves
+
+def check_cves(d, patched_cves):
+"""
+Run cve-check-tool looking for patched and unpatched CVEs.
+"""
+
+from bb.utils import export_proxies
+import ast, csv, tempfile, subprocess, StringIO
+
+cves_patched = []
+cves_unpatched = []
+bpn = d.getVar("BPN", True)
+pv = d.getVar("PV", True)
+cves = " ".join(patched_cves)
+cve_dir = d.getVar("CVE_CHECK_DB_DIR", True)
+cve_whitelist = 

[OE-core] [PATCH 2/3] cve-check-tool patch to allow select dir for the db

[mariano . lopez]

From: Mariano Lopez 

This patch allows to select the directory for the
database used by cve-check-tool.

[YOCTO #7515]

Signed-off-by: Mariano Lopez 
---
 .../change_logic_cve_get_file_parent.patch | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 
meta/recipes-devtools/cve-check-tool/cve-check-tool/change_logic_cve_get_file_parent.patch

diff --git 
a/meta/recipes-devtools/cve-check-tool/cve-check-tool/change_logic_cve_get_file_parent.patch
 
b/meta/recipes-devtools/cve-check-tool/cve-check-tool/change_logic_cve_get_file_parent.patch
new file mode 100644
index 000..077de88
--- /dev/null
+++ 
b/meta/recipes-devtools/cve-check-tool/cve-check-tool/change_logic_cve_get_file_parent.patch
@@ -0,0 +1,45 @@
+From 22cc9186909f98f024d78a08504d0bf532806de0 Mon Sep 17 00:00:00 2001
+From: Mariano Lopez 
+Date: Thu, 18 Feb 2016 14:26:02 +
+Subject: [PATCH] util.c: Change logic in cve_get_file_parent()
+
+Function cve_get_file_parent() will try to get the
+realpath and the get the dirname. If the file used
+to get parent doesn't exist the call will fail.
+
+This problem is present when using another directory
+for the database, realpath() won't find the nvd.db
+file and the program will exit quitely.
+
+This patch will first get the dirname and the get
+the realpath to avoid failing when the doesn't exist.
+
+Upstream-Status: Accepted [Release v5.6.3]
+
+Signed-off-by: Mariano Lopez 
+---
+ src/library/util.c | 8 +++-
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+diff --git a/src/library/util.c b/src/library/util.c
+index 8a20728..4d4a576 100644
+--- a/src/library/util.c
 b/src/library/util.c
+@@ -184,11 +184,9 @@ bool cve_is_dir(const char *p)
+ 
+ char *cve_get_file_parent(const char *p)
+ {
+-char *r = realpath(p, NULL);
+-if (!r) {
+-return NULL;
+-}
+-return dirname(r);
++autofree(char) *d = strdup(p);
++char *r = realpath(dirname(d), NULL);
++return r;
+ }
+ 
+ bool cve_file_set_text(const char *path, char *text)
+-- 
+2.6.2
+
-- 
2.6.2

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

[OE-core] [PATCH] populate_sdk_ext: Add images to SDK_INSTALL_TARGETS

[Randy Witt]

When running ext-sdk-prepare.py during sdk installation a check is done to
make sure no tasks would run that aren't provided by the "leaf" recipes
specified in SDK_INSTALL_TARGETS.

However sometimes an image recipe can cause other images to be created
such as an initramfs. So make sure those additional images are
recognized by ext-sdk-prepare.py and don't flag an error.

Signed-off-by: Randy Witt 
---
 meta/classes/populate_sdk_ext.bbclass | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index a6badb8..9e2fc61 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -40,12 +40,17 @@ def get_sdk_install_targets(d):
 if d.getVar('SDK_EXT_TYPE', True) != 'minimal':
 sdk_install_targets = d.getVar('SDK_TARGETS', True)
 
+depd = d.getVar('BB_TASKDEPDATA', False)
+for v in depd.itervalues():
+if v[1] == 'do_image_complete':
+if v[0] not in sdk_install_targets:
+sdk_install_targets += ' {}'.format(v[0])
+
 if d.getVar('SDK_INCLUDE_PKGDATA', True) == '1':
 sdk_install_targets += ' meta-world-pkgdata:do_allpackagedata'
 
 return sdk_install_targets
 
-SDK_INSTALL_TARGETS = "${@get_sdk_install_targets(d)}"
 OE_INIT_ENV_SCRIPT ?= "oe-init-build-env"
 
 # The files from COREBASE that you want preserved in the COREBASE copied
@@ -344,12 +349,15 @@ SDK_POST_INSTALL_COMMAND_task-populate-sdk-ext = 
"${sdk_ext_postinst}"
 
 SDK_POSTPROCESS_COMMAND_prepend_task-populate-sdk-ext = "copy_buildsystem; 
install_tools; "
 
+SDK_INSTALL_TARGETS = ""
 fakeroot python do_populate_sdk_ext() {
 # FIXME hopefully we can remove this restriction at some point, but 
uninative
 # currently forces this upon us
 if d.getVar('SDK_ARCH', True) != d.getVar('BUILD_ARCH', True):
 bb.fatal('The extensible SDK can currently only be built for the same 
architecture as the machine being built on - SDK_ARCH is set to %s (likely via 
setting SDKMACHINE) which is different from the architecture of the build 
machine (%s). Unable to continue.' % (d.getVar('SDK_ARCH', True), 
d.getVar('BUILD_ARCH', True)))
 
+d.setVar('SDK_INSTALL_TARGETS', get_sdk_install_targets(d))
+
 bb.build.exec_func("do_populate_sdk", d)
 }
 
-- 
2.5.0

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

Re: [OE-core] what is the priority of wildcarded .bbappend files?

[Radzykewycz, T (Radzy)]

On Wednesday, February 24, 2016 3:02 PM, Paul Eggleton said:
> On Wed, 24 Feb 2016 22:59:13 Radzykewycz, T wrote:
> > On Wednesday, February 24, 2016 2:52 PM, Paul Eggleton said:
> > > On Wed, 24 Feb 2016 16:33:04 Robert P. J. Day wrote:
> > > > Quoting Christopher Larson :
> > > > > All appends that apply to a given recipe will be applied to that
> > > > > recipe.
> > > > > Order is determined solely by layer priority.
> > > > >
> > > >wait ... so *all* bbappend files that match a recipe will be applied?
> > > >
> > > > i'm embarrassed that i didn't know that, is that mentioned in the
> > > > documentation somewhere?
> > >
> > > Surprisingly we don't currently state this explicitly, though it's
> > > implied. We should work this into the relevant part of the bitbake manual
> > > and the "Using .bbappend Files" section of the dev manual. Scott could
> > > you add that to your todo list?
> >
> > If there is any way to determine the order that the bbappend files
> > are included, that would be helpful.  As well as determining what
> > order patches will be applied (which is, I suspect, determined
> > in part by what order the bbappend files are included)..
> 
> bitbake-layers show-appends will give you the former. Patches get applied
> strictly in the order they appear in SRC_URI, if you have bbappends that
> append or prepend that variable that will of course influence that, but the
> final value and hence the order should be visible through bitbake -e 
> recipename
> | less and then search for ^SRC_URI (along with history of how the value came
> to be).

I suggest this might be put into the SRC_URI section at
https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#var-SECTION
and worded something like this (at the end):

The order of patch application follows the order that
the patch files are included in the final SRC_URI value.
So patches in prepended SRC_URI additions are put before
other patches that might be contained in the base bb file or
in other bbappend files, and must not generate differences
that prevent subsequent patches from applying.

I'm not tied to any particular location in the docs, though,
so if it should go elsewhere, that's fine with me.

Enjoy!

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

Re: [OE-core] what is the priority of wildcarded .bbappend files?

[Paul Eggleton]

On Wed, 24 Feb 2016 22:59:13 Radzykewycz, T wrote:
> 
> 
> On Wednesday, February 24, 2016 2:52 PM, Paul Eggleton said:
> > On Wed, 24 Feb 2016 16:33:04 Robert P. J. Day wrote:
> > > Quoting Christopher Larson :
> > > > All appends that apply to a given recipe will be applied to that
> > > > recipe.
> > > > Order is determined solely by layer priority.
> > > > 
> > >wait ... so *all* bbappend files that match a recipe will be applied?
> > > 
> > > i'm embarrassed that i didn't know that, is that mentioned in the
> > > documentation somewhere?
> > 
> > Surprisingly we don't currently state this explicitly, though it's
> > implied. We should work this into the relevant part of the bitbake manual
> > and the "Using .bbappend Files" section of the dev manual. Scott could
> > you add that to your todo list?
> 
> If there is any way to determine the order that the bbappend files
> are included, that would be helpful.  As well as determining what
> order patches will be applied (which is, I suspect, determined
> in part by what order the bbappend files are included)..

bitbake-layers show-appends will give you the former. Patches get applied 
strictly in the order they appear in SRC_URI, if you have bbappends that 
append or prepend that variable that will of course influence that, but the 
final value and hence the order should be visible through bitbake -e recipename 
| less and then search for ^SRC_URI (along with history of how the value came 
to be).

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] what is the priority of wildcarded .bbappend files?

[Radzykewycz, T (Radzy)]

On Wednesday, February 24, 2016 2:52 PM, Paul Eggleton said:
> On Wed, 24 Feb 2016 16:33:04 Robert P. J. Day wrote:
> > Quoting Christopher Larson :
> > > All appends that apply to a given recipe will be applied to that recipe.
> > > Order is determined solely by layer priority.
> >
> >wait ... so *all* bbappend files that match a recipe will be applied?
> > i'm embarrassed that i didn't know that, is that mentioned in the
> > documentation somewhere?
> 
> Surprisingly we don't currently state this explicitly, though it's implied. We
> should work this into the relevant part of the bitbake manual and the "Using
> .bbappend Files" section of the dev manual. Scott could you add that to your
> todo list?

If there is any way to determine the order that the bbappend files
are included, that would be helpful.  As well as determining what
order patches will be applied (which is, I suspect, determined
in part by what order the bbappend files are included)..

Enjoy!

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

Re: [OE-core] [PATCH 03/10] hardlink: add new recipe

[Andre McCurdy]

On Wed, Feb 24, 2016 at 6:52 AM, Joshua Lock  wrote:
> ---
>  meta/recipes-extended/hardlink/hardlink_0.3.0.bb | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 meta/recipes-extended/hardlink/hardlink_0.3.0.bb
>
> diff --git a/meta/recipes-extended/hardlink/hardlink_0.3.0.bb 
> b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> new file mode 100644
> index 000..2e06ac2
> --- /dev/null
> +++ b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "hardlink is a tool which replaces multiple copies of a file with 
> hardlinks."
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = 
> "file://hardlink.c;endline=22;md5=168464a4fc92fa7389c53b0755b39fbb"
> +
> +SRC_URI = "http://jak-linux.org/projects/hardlink/${BPN}_${PV}.tar.xz;
> +SRC_URI[md5sum] = "72f1a460adb6874c151deab766e434ad"
> +SRC_URI[sha256sum] = 
> "e8c93dfcb24aeb44a75281ed73757cb862cc63b225d565db1c270af9dbb7300f"
> +
> +DEPENDS = "libpcre attr"

According to the style guide, DEPENDS should come between
LIC_FILES_CHKSUM and SRC_URI.

> +do_compile () {
> +   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' BINDIR='${bindir}'
> +}
> +
> +do_install () {
> +   oe_runmake install 'DESTDIR=${D}' 'PREFIX=${prefix}' 
> BINDIR='${bindir}'
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.5.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] what is the priority of wildcarded .bbappend files?

[Paul Eggleton]

On Wed, 24 Feb 2016 16:33:04 Robert P. J. Day wrote:
> Quoting Christopher Larson :
> > All appends that apply to a given recipe will be applied to that recipe.
> > Order is determined solely by layer priority.
> 
>wait ... so *all* bbappend files that match a recipe will be applied?
> i'm embarrassed that i didn't know that, is that mentioned in the
> documentation somewhere?

Surprisingly we don't currently state this explicitly, though it's implied. We 
should work this into the relevant part of the bitbake manual and the "Using 
.bbappend Files" section of the dev manual. Scott could you add that to your 
todo list?

Thanks,
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

[OE-core] [PATCH] glibc.inc: improve optimisation level sanity checking

[Andre McCurdy]

- Avoid code duplication to handle -O, -O1 and -Os cases

- Consider the effective optimisation level only (avoids spurious
  warnings if multiple optimisation flags are present).

- Prefix warnings with PN instead of hardcoding "glibc" (avoids
  confusing warnings since the test is also applied to glibc-initial,
  nativesdk-glibc, nativesdk-glibc-initial, etc, and each could
  potentually have different optimisation flags).

Signed-off-by: Andre McCurdy 
---
 meta/recipes-core/glibc/glibc.inc | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc.inc 
b/meta/recipes-core/glibc/glibc.inc
index 5711209..bf1dccd 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -8,19 +8,15 @@ PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:"
 
 TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TCBOOTSTRAP}"
 
-# glibc can't be built without optimization, if someone tries to compile an
-# entire image as -O0, break with fatal.
 python () {
-if bb.utils.contains("SELECTED_OPTIMIZATION", "-O", "x", "", d) == "x":
-bb.note("glibc can't be built with -O, -O -Wno-error will be used 
instead.")
-d.appendVar("SELECTED_OPTIMIZATION", " -Wno-error")
-elif bb.utils.contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x":
-bb.fatal("glibc can't be built with -O0, using -O1 -Wno-error or -O1 
instead.")
-elif bb.utils.contains("SELECTED_OPTIMIZATION", "-Os", "x", "", d) == "x":
-bb.note("glibc can't be built with -Os, -Os -Wno-error will be used 
instead.")
-d.appendVar("SELECTED_OPTIMIZATION", " -Wno-error")
-elif bb.utils.contains("SELECTED_OPTIMIZATION", "-O1", "x", "", d) == "x":
-bb.note("glibc can't be built with -O1, -O1 -Wno-error will be used 
instead.")
+opt_effective = "-O"
+for opt in d.getVar('SELECTED_OPTIMIZATION', True).split():
+if opt in ("-O0", "-O", "-O1", "-O2", "-O3", "-Os"):
+opt_effective = opt
+if opt_effective == "-O0":
+bb.fatal("%s can't be built with %s, try -O1 instead" % 
(d.getVar('PN', True), opt_effective))
+if opt_effective in ("-O", "-O1", "-Os"):
+bb.note("%s doesn't build cleanly with %s, adding -Wno-error to 
SELECTED_OPTIMIZATION" % (d.getVar('PN', True), opt_effective))
 d.appendVar("SELECTED_OPTIMIZATION", " -Wno-error")
 }
 
-- 
1.9.1

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

Re: [OE-core] trying to summarize the flexibility in bbappend'ing to kernel recipes

[Christopher Larson]

A bbappend basically concatenates to the recipe in bitgbake, so it can do
anything the recipe can do, within reason, so yes, use of filespath and
overrides works the way it's always worked with recipes.

On Wed, Feb 24, 2016 at 3:00 PM Robert P. J. Day 
wrote:

>let's see if i can explain this properly -- i want to enumerate all
> possible ways to .bbappend to a kernel recipe if i have multiple
> target machines and multiple kernel recipes. so let's imagine the
> following scenario -- i grab a layer that has two recipe files for
> two versions of the kernel, *and* i have two target boards. so ...
>
>   * linux-4.0.bb
>   * linux-4.1.bb
>
> and i have two target machines, "mach1" and "mach2", and the combination
> of all of these involves various patches. so what are my possibilities?
>
>first (as long as i understood chris larson properly), i can define
> two separate .bbappend files:
>
>   * linux-4.0.bbappend
>   * linux-4.1.bbappend
>
> or i can define a single wildcard .bbappend file that covers both:
>
>   * linux-4.%.bbappend
>
> so far, so good.
>
>next, in these .bbappend files, SRC_URI can refer to any of:
>
>   * .scc files
>   * .patch/.diff files
>   * .cfg files
>
> so each of my two .bbappend files can enumerate a different set
> of files to be applied to that version of the kernel. but wait ...
> there's more.
>
>in each .bbappend file, i can conditionally include files in the
> SRC_URI, as in:
>
>   * SRC_URI_mach1 += mach1.patch
>
> so depending on the target machine, i can conditionally include
> any of patch files, cfg files or scc files.
>
>in addition, i can take advantage of FILESEXTRAPATHS, that i once
> wrote up here:
>
>http://www.crashcourse.ca/wiki/index.php/Poky_bbappend_FILESEXTRAPATHS
>
> so that i have a ridiculous set of possibilities as to which patch
> files will be applied depending on the:
>
>   * architecture
>   * distro
>   * target machine
>
> am i making sense so far? because there will be more coming shortly.
>
> rday
>
>
>
> --
> ___
> 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] what is the priority of wildcarded .bbappend files?

[Robert P. J. Day]

Quoting Christopher Larson :


All appends that apply to a given recipe will be applied to that recipe.
Order is determined solely by layer priority.


  wait ... so *all* bbappend files that match a recipe will be applied?
i'm embarrassed that i didn't know that, is that mentioned in the
documentation somewhere?

rday


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

[OE-core] Enabling tab completion on host gdb

[Jonah Petri]

Hello!
Does anyone know why host gdb (as built into a yocto sdk) does not have
working tab completion?

If I type "break wr" and then press tab, it does nothing.  However, if I
type:
(gdb) complete b wr
b write
b wr...@got.plt
b write@plt
b writer.h

So, the completions are there, but something is not hooked up properly.
We're using pretty close to stock poky 1.8, and the package is specifically:
x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-arm/7.8.1-r0/

I never realized how much I depend on tab completion for productivity while
debugging, so any help would be much appreciated!

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

Re: [OE-core] [PATCH 03/10] hardlink: add new recipe

[Burton, Ross]

On 24 February 2016 at 14:52, Joshua Lock  wrote:

> +do_compile () {
> +   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' BINDIR='${bindir}'
> +}
> +
> +do_install () {
> +   oe_runmake install 'DESTDIR=${D}' 'PREFIX=${prefix}'
> BINDIR='${bindir}'
> +}
>

EXTRA_OEMAKE will make this neater.

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

Re: [OE-core] what is the priority of wildcarded .bbappend files?

[Christopher Larson]

All appends that apply to a given recipe will be applied to that recipe.
Order is determined solely by layer priority.

On Wed, Feb 24, 2016 at 1:38 PM Robert P. J. Day 
wrote:

>didn't immediately see this in the documentation anywhere, so what would
> happen in the following situation? say i have a layer that has three
> different versions of a recipe:
>
> * recipe-1.0.bb
> * recipe-1.1.bb
> * recipe-1.2.bb
>
>if i want, i can extend each one with a .bbappend file:
>
> * recipe-1.0.bbappend
> * recipe-1.1.bbappend
> * recipe-1.2.bbappend
>
>or if the same .bbappend file applies to all of them, i can just create
> the wildcard file "recipe-1.%.bbappend". but can i do this?
>
> * recipe-1.1.bbappend
> * recipe-1.%.bbappend
>
> such that the more specific match takes precedence, so that the 1.1
> bbappend
> file is used for that version, and the wildcard version is used for
> all others?
> is this written down somewhere that i just missed it?
>
> rday
>
>
> --
> ___
> 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 00/10] Integrate swupd software updater

[Philip Balister]

On 02/24/2016 02:51 PM, Paul Eggleton wrote:
> On Wed, 24 Feb 2016 11:35:25 Philip Balister wrote:
>> On 02/24/2016 11:06 AM, Trevor Woerner wrote:
>>> Ideally the work done here and the work done on meta-swupdate[1] would
>>> be somehow merged so people creating images/distros would only have to
>>> learn and integrate one software update solution, instead of having to
>>> evaluate and choose between the two (or more?).
>>>
>>> [1] https://github.com/sbabic/meta-swupdate
>>
>> Amen. I had the same thoughts reading the patch set intro.
> 
> I think it would be hard to integrate these two, since they operate quite 
> differently to eachother.
>  
>> Maybe the swupd should go in a seperate layer so we can see which
>> project works best for oe users before moving something directly into
>> oe-core?
> 
> This makes sense to me too though FWIW. The os-release patch should probably 
> go straight in, but everything else looks like it could comfortably live in a 
> separate layer without making things too difficult.

It also makes it easier to update as problems in swupd are resolved
since you do not need to go through the entire oe-core testing cycle.

Philip


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

[OE-core] what is the priority of wildcarded .bbappend files?

[Robert P. J. Day]

  didn't immediately see this in the documentation anywhere, so what would
happen in the following situation? say i have a layer that has three
different versions of a recipe:

* recipe-1.0.bb
* recipe-1.1.bb
* recipe-1.2.bb

  if i want, i can extend each one with a .bbappend file:

* recipe-1.0.bbappend
* recipe-1.1.bbappend
* recipe-1.2.bbappend

  or if the same .bbappend file applies to all of them, i can just create
the wildcard file "recipe-1.%.bbappend". but can i do this?

* recipe-1.1.bbappend
* recipe-1.%.bbappend

such that the more specific match takes precedence, so that the 1.1 bbappend
file is used for that version, and the wildcard version is used for  
all others?

is this written down somewhere that i just missed it?

rday


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

[OE-core] [jethro][PATCH 1/1] os-release: put double-quotes around variable contents

[Paul Eggleton]

From: Craig McQueen 

This makes the resulting /etc/os-release file have valid shell
assignment syntax. This makes it loadable by a shell script, using the
'source' command:

source /etc/os-release

(From OE-Core master rev: f6e0ea000fa3b9a726ab56500f643f9902371618)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/os-release/os-release.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/os-release/os-release.bb 
b/meta/recipes-core/os-release/os-release.bb
index c690b82..df19ca2 100644
--- a/meta/recipes-core/os-release/os-release.bb
+++ b/meta/recipes-core/os-release/os-release.bb
@@ -29,7 +29,7 @@ python do_compile () {
 for field in d.getVar('OS_RELEASE_FIELDS', True).split():
 value = d.getVar(field, True)
 if value:
-f.write('{0}={1}\n'.format(field, value))
+f.write('{0}="{1}"\n'.format(field, value))
 if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
 rpm_gpg_pubkey = d.getVar('RPM_GPG_PUBKEY', True)
 bb.utils.mkdirhier('${B}/rpm-gpg')
-- 
2.5.0

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

[OE-core] [jethro][PATCH 0/1] One backport for jethro

[Paul Eggleton]

This is intended for after the imminent point release of course.


The following changes since commit 0c702756dd0009c4112028fbf2479a346867b32c:

  build-appliance-image: Update to jethro head revision (2016-02-24 09:04:05 
+)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/jethro-fixes3
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/jethro-fixes3

Craig McQueen (1):
  os-release: put double-quotes around variable contents

 meta/recipes-core/os-release/os-release.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.5.0

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

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Paul Eggleton]

On Wed, 24 Feb 2016 11:35:25 Philip Balister wrote:
> On 02/24/2016 11:06 AM, Trevor Woerner wrote:
> > Ideally the work done here and the work done on meta-swupdate[1] would
> > be somehow merged so people creating images/distros would only have to
> > learn and integrate one software update solution, instead of having to
> > evaluate and choose between the two (or more?).
> > 
> > [1] https://github.com/sbabic/meta-swupdate
> 
> Amen. I had the same thoughts reading the patch set intro.

I think it would be hard to integrate these two, since they operate quite 
differently to eachother.
 
> Maybe the swupd should go in a seperate layer so we can see which
> project works best for oe users before moving something directly into
> oe-core?

This makes sense to me too though FWIW. The os-release patch should probably 
go straight in, but everything else looks like it could comfortably live in a 
separate layer without making things too difficult.

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 0/2] libsoup-2.4: cleanup + disable libsoup-gnome by default

[Andre McCurdy]

On Wed, Feb 24, 2016 at 4:51 AM, Martin Jansa  wrote:
> On Thu, Feb 18, 2016 at 11:21:23AM -0800, Andre McCurdy wrote:
>> Andre McCurdy (2):
>>   libsoup-2.4: minor formatting improvements
>>   libsoup-2.4: disable libsoup-gnome by default
>>
>>  meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 20 +---
>>  1 file changed, 9 insertions(+), 11 deletions(-)
>
> It looks like this was merged without suggested fix for upgrade-path.
>
> Will you please send follow-up patch?

I think the v2 series was merged OK. Here's the commit which tries to
prevent renaming when the gnome PACKAGECONFIG is disabled:

  
http://git.openembedded.org/openembedded-core/commit/?id=f5f95f501c8aacb3d624e683b4b5b8403115ba5d

> It also most likely breaks libgdata in meta-oe (for complete log see bitbake 
> world
> reports or errors.yoctoproject.org)
>
>   | configure: error: Package requirements (libsoup-gnome-2.4) were not met:
>   |
>   | No package 'libsoup-gnome-2.4' found
>
> Maybe it will be resolved by libgdata upgrade sent in
> gobject-introspective set, so this is just FYI.

OK. I'll look into this one.

> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Patrick Ohly]

On Wed, 2016-02-24 at 16:09 +, Lock, Joshua G wrote:
> On Wed, 2016-02-24 at 16:37 +0100, Patrick Ohly wrote:
> > Hello!
> > 
> > I haven't had a chance to play with the actual code yet and I don't
> > know
> > yet when I'll be able to. Let me ask for some clarifications about
> > the
> > approach first anyway.
> > 
> > On Wed, 2016-02-24 at 14:52 +, Joshua Lock wrote:
> > > 
> > > Approach:
> > > An image that inherits the swupd-image bbclass will automatically
> > > have bundle
> > > 'chroots' created which contain the filesystem contents of the
> > > specified
> > > bundles, with the contents of the inheriting image forming the
> > > default os-core
> > > bundle.
> > > 
> > > The mechanism to achieve this is that several virtual image recipes
> > > are created
> > > using the swupdbundle class, one for each defined bundle plus a
> > > 'mega' image
> > > recipe. The 'mega' image contains the base image plus the contents
> > > of all of the
> > > bundles, whilst bundle images contain only the base image plus the
> > > contents of a
> > > single bundle.
> > Just to be sure, the actual "content" (a term that is a bit too
> > overloaded to be used precisely in all cases) of a file and its meta
> > attributes will come from the mega image, and the virtual image
> > recipes,
> > including the base image, are merely used to generate file lists?
> 
> That's not currently true, no — the file contents for a bundle come
> from the bundle image and the file contents for os-core come from the
> base image. It shouldn't be too difficult a change to make, I'll take a
> look now.

The prime example that needs to be handled correctly is where installing
additional packages for one of the extra bundles adds a system user
to /etc/passwd (*). The content of /etc/passwd must come from the mega
rootfs.

(*) Except that swupd assumes that the distro is stateless and thus
automatically excludes /etc from bundles. The example is still valid
because preparing bundles does not need to care about that.

> > What is the content of the actual image that gets created? It has to
> > match the content (= file content and meta information) of the mega
> > image and not of the base image, otherwise there can be
> > inconsistencies
> > between the actual running image and the core os bundle. I suppose
> > swupd
> > will be able to fix that, but I'm not sure.
> > 
> > It sounds like this bundle creation is completely separated from the
> > regular image creation; if so, then I suspect that this may have to
> > change.
> 
> Right, currently bundle creation happens after image creation and as
> above bundles are populated from the rootfs of the bundle images.
> 
> You're right, of course, we'll need to construct the running image from
> the bundle contents for more complex images.

We can remove the original do_rootfs and do_image and replace it with
code that copies the relevant subset of the mega image. Then the rest of
the image creation will see the right content.

> > > We took the approach of building images, rather than populating the
> > > chroot-like
> > > bundle directories with a package manager, because various layers
> > > and recipes
> > > make changes to the rootfs contents outside of the package manager,
> > > particularly
> > > with IMAGE_POSTPROCESS_COMMAND, etc.
> > Makes sense to me.
> > 
> > Have you considered generating the file lists more efficiently? I can
> > think of some alternatives, but all have downsides.
> > 
> 
> I did consider a couple of other approaches but with a goal of
> submitting this for M3 this approach felt like the surest route within
> the time available. I'd certainly like to find a more efficient method
> and if you have any suggestions I'd be happy to hear them.

I don't have any and thus agree with this route. I was merely wondering
whether you already had a working solution in mind.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Maciej Borzecki]

> Dnia 24 luty 2016 o 17:35 Philip Balister  napisał(a):
>
>
> On 02/24/2016 11:06 AM, Trevor Woerner wrote:
> > Ideally the work done here and the work done on meta-swupdate[1] would
> > be somehow merged so people creating images/distros would only have to
> > learn and integrate one software update solution, instead of having to
> > evaluate and choose between the two (or more?).
> >
> >
> > [1] https://github.com/sbabic/meta-swupdate
>
> Amen. I had the same thoughts reading the patch set intro.
>
> Maybe the swupd should go in a seperate layer so we can see which
> project works best for oe users before moving something directly into
> oe-core?
>

Frankly, swupdate is more embedded oriented. If I was to choose which
one fits better into OE, I would say that swupdate does. However, in the
end, both projects have their uses.

`swupd` is a new thing and I'm not aware of it being used in any other
project than ClearLinux.  From what I've seen[1] there are some nice
concepts that might prove useful in embedded (maybe even automotive
applications?), but I have not tried it personally.

`swupdate` on the other hand is very much embedded oriented. It's aware
of u-boot, ubifs volumes, MTD, and is capable of updating firmware. I've
used it, even contributed some code, and so far I've had a rather
positive experience using it. There are some quirks in meta-swupdate
that might need fixing, for ex. the actual process of building of update
images is a bit convoluted, lack of systemd awareness, and certain
assumptions about the update method that I don't agree with. I have some
patches queued up, but they're more like shameful hacks than something
worth upstreaming at this point.

[1]. https://lists.clearlinux.org/pipermail/dev/2016-January/000159.html

--
Maciej Borzęcki
Senior Software Engineer at Open-RnD Sp. z o.o.
www.open-rnd.pl, Facebook, Twitter
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [jethro][PATCH] bluez5: allow D-Bus to spawn obexd in systems without systemd

[Javier Viguera]

This includes a proper D-Bus service file for obexd in systems that do
not support systemd.

Signed-off-by: Javier Viguera 
---
 meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
 ...-obexd-without-systemd-in-the-user-sessio.patch | 63 ++
 2 files changed, 64 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index df42c88b9da3..d1af31ea45cd 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -18,6 +18,7 @@ PACKAGECONFIG[experimental] = 
"--enable-experimental,--disable-experimental,"
 
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
+${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 
'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
new file mode 100644
index ..2fde7bc06923
--- /dev/null
+++ 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
@@ -0,0 +1,63 @@
+From: Giovanni Campagna 
+Date: Sat, 12 Oct 2013 17:45:25 +0200
+Subject: [PATCH] Allow using obexd without systemd in the user session
+
+Not all sessions run systemd --user (actually, the majority
+doesn't), so the dbus daemon must be able to spawn obexd
+directly, and to do so it needs the full path of the daemon.
+
+Upstream-Status: Denied
+
+Not accepted by upstream maintainer for being a distro specific
+configuration. See thread:
+
+http://thread.gmane.org/gmane.linux.bluez.kernel/38725/focus=38843
+
+Signed-off-by: Javier Viguera 
+---
+ Makefile.obexd  | 4 ++--
+ obexd/src/org.bluez.obex.service| 4 
+ obexd/src/org.bluez.obex.service.in | 4 
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+ delete mode 100644 obexd/src/org.bluez.obex.service
+ create mode 100644 obexd/src/org.bluez.obex.service.in
+
+diff --git a/Makefile.obexd b/Makefile.obexd
+index 2e33cbc72f2b..d5d858c857b4 100644
+--- a/Makefile.obexd
 b/Makefile.obexd
+@@ -2,12 +2,12 @@
+ if SYSTEMD
+ systemduserunitdir = @SYSTEMD_USERUNITDIR@
+ systemduserunit_DATA = obexd/src/obex.service
++endif
+ 
+ dbussessionbusdir = @DBUS_SESSIONBUSDIR@
+ dbussessionbus_DATA = obexd/src/org.bluez.obex.service
+-endif
+ 
+-EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service
++EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service.in
+ 
+ obex_plugindir = $(libdir)/obex/plugins
+ 
+diff --git a/obexd/src/org.bluez.obex.service 
b/obexd/src/org.bluez.obex.service
+deleted file mode 100644
+index a53808884554..
+--- a/obexd/src/org.bluez.obex.service
 /dev/null
+@@ -1,4 +0,0 @@
+-[D-BUS Service]
+-Name=org.bluez.obex
+-Exec=/bin/false
+-SystemdService=dbus-org.bluez.obex.service
+diff --git a/obexd/src/org.bluez.obex.service.in 
b/obexd/src/org.bluez.obex.service.in
+new file mode 100644
+index ..9c815f246b77
+--- /dev/null
 b/obexd/src/org.bluez.obex.service.in
+@@ -0,0 +1,4 @@
++[D-BUS Service]
++Name=org.bluez.obex
++Exec=@libexecdir@/obexd
++SystemdService=dbus-org.bluez.obex.service
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bluez5: allow D-Bus to spawn obexd in systems without systemd

[Javier Viguera]

This includes a proper D-Bus service file for obexd in systems that do
not support systemd.

Signed-off-by: Javier Viguera 
---
 meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
 ...-obexd-without-systemd-in-the-user-sessio.patch | 63 ++
 2 files changed, 64 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index ff2bdcba62a4..f38eaa503598 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -19,6 +19,7 @@ PACKAGECONFIG[experimental] = 
"--enable-experimental,--disable-experimental,"
 SRC_URI = "\
 ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
 file://init \
+${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 
'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
new file mode 100644
index ..2fde7bc06923
--- /dev/null
+++ 
b/meta/recipes-connectivity/bluez5/bluez5/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
@@ -0,0 +1,63 @@
+From: Giovanni Campagna 
+Date: Sat, 12 Oct 2013 17:45:25 +0200
+Subject: [PATCH] Allow using obexd without systemd in the user session
+
+Not all sessions run systemd --user (actually, the majority
+doesn't), so the dbus daemon must be able to spawn obexd
+directly, and to do so it needs the full path of the daemon.
+
+Upstream-Status: Denied
+
+Not accepted by upstream maintainer for being a distro specific
+configuration. See thread:
+
+http://thread.gmane.org/gmane.linux.bluez.kernel/38725/focus=38843
+
+Signed-off-by: Javier Viguera 
+---
+ Makefile.obexd  | 4 ++--
+ obexd/src/org.bluez.obex.service| 4 
+ obexd/src/org.bluez.obex.service.in | 4 
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+ delete mode 100644 obexd/src/org.bluez.obex.service
+ create mode 100644 obexd/src/org.bluez.obex.service.in
+
+diff --git a/Makefile.obexd b/Makefile.obexd
+index 2e33cbc72f2b..d5d858c857b4 100644
+--- a/Makefile.obexd
 b/Makefile.obexd
+@@ -2,12 +2,12 @@
+ if SYSTEMD
+ systemduserunitdir = @SYSTEMD_USERUNITDIR@
+ systemduserunit_DATA = obexd/src/obex.service
++endif
+ 
+ dbussessionbusdir = @DBUS_SESSIONBUSDIR@
+ dbussessionbus_DATA = obexd/src/org.bluez.obex.service
+-endif
+ 
+-EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service
++EXTRA_DIST += obexd/src/obex.service.in obexd/src/org.bluez.obex.service.in
+ 
+ obex_plugindir = $(libdir)/obex/plugins
+ 
+diff --git a/obexd/src/org.bluez.obex.service 
b/obexd/src/org.bluez.obex.service
+deleted file mode 100644
+index a53808884554..
+--- a/obexd/src/org.bluez.obex.service
 /dev/null
+@@ -1,4 +0,0 @@
+-[D-BUS Service]
+-Name=org.bluez.obex
+-Exec=/bin/false
+-SystemdService=dbus-org.bluez.obex.service
+diff --git a/obexd/src/org.bluez.obex.service.in 
b/obexd/src/org.bluez.obex.service.in
+new file mode 100644
+index ..9c815f246b77
+--- /dev/null
 b/obexd/src/org.bluez.obex.service.in
+@@ -0,0 +1,4 @@
++[D-BUS Service]
++Name=org.bluez.obex
++Exec=@libexecdir@/obexd
++SystemdService=dbus-org.bluez.obex.service
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 6/7] webkitgtk: update to 2.10.7

[akuster808]

On 02/24/2016 03:55 AM, Alexander Kanavin wrote:
> On 02/16/2016 05:55 PM, akuster808 wrote:
> 
>>> Yes, which means that jethro (which has 2.8.5) needs the same update.
>>
>> there is a bug open for that 8877. there are a huge number of CVE's that
>> need fixing.
> 
> I wrote a comment in that bug, but I think it bears repeating here:
> 
> Please read this, it's a bit long, but worth it:
> 
> https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
> 
> Summary: the upstream will not backport CVE fixes, and they will not be
> making point releases in old branches with any kind of lifecycle
> guarantee. Providing ongoing updates to the latest stable release of
> webkit is the only way to stay secure.
> 

Many vulnerability notifications will make the same statements.

Updating a package that other packages depend on can cause a cascading
set of failures. Now you have a bigger set of problems to contend with.

> So I believe that you indeed have to update webkit to 2.10.7, or
> whatever is the latest stable release, and keep doing this for as long
> as a yocto release needs to be supported.

>From the commercial side you just can't move your install base to the
latest package versions for every security issue. The Yocto maintenance
policy operates very close to this too.

Yeah, Backporting fixes to stable branches is a lot of work once it
moves away from a simple cherry-pick from master.


regards,
- armin

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

Re: [OE-core] [PATCHv2 2/2] testimage.bbclass: reuse generic test suites

[Benjamin Esquivel]

On Tue, 2016-02-23 at 16:18 -0600, Alex Franco wrote:
> I tested this with builds in my workstation and (local, internal)
> autobuilder, where TEST_SUITES is *not* specified in local.conf, so
> the
> TEST_SUITES are taken from the DEFAULT_TEST_SUITES variable for each
> image, which makes the tests work for the variables defined.
> 
> If TEST_SUITES includes "auto", then the testimage task for some
> images
> will still fail, but that's why I opened a new bug # 9129
> 
Thanks, good info.
> - Alex Franco
> 
> On 02/23/2016 03:20 PM, Benjamin Esquivel wrote:
> > Hi Franco, how did you test this? what is the behavior you get with
> > these defaults instead of how's behaving now?
> > 
> > See comments below.
> > 
> > On Tue, 2016-02-23 at 09:14 +, Alex Franco wrote:
> > > Modify existing default test suites to reuse the new
> > > generic test suites.
> > > 
> > > Related to [YOCTO #8410]
> > > 
> > > Signed-off-by: Alex Franco 
> > > ---
> > >  meta/classes/testimage.bbclass | 12 +++-
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/meta/classes/testimage.bbclass
> > > b/meta/classes/testimage.bbclass
> > > index 791cce3..e77bb11 100644
> > > --- a/meta/classes/testimage.bbclass
> > > +++ b/meta/classes/testimage.bbclass
> > > @@ -37,17 +37,19 @@ MINTESTSUITE = "ping"
> > >  NETTESTSUITE = "${MINTESTSUITE} ssh df date scp syslog"
> > >  DEVTESTSUITE = "gcc kernelmodule ldd"
> > > 
> > > -DEFAULT_TEST_SUITES = "ping auto"
> > > -DEFAULT_TEST_SUITES_pn-core-image-minimal = "ping"
> > > +DEFAULT_TEST_SUITES = "${MINTESTSUITE} auto"
> > > +DEFAULT_TEST_SUITES_pn-core-image-minimal = "${MINTESTSUITE}"
> > >  DEFAULT_TEST_SUITES_pn-core-image-minimal-dev =
> > > "${MINTESTSUITE}"
> > >  DEFAULT_TEST_SUITES_pn-core-image-full-cmdline =
> > > "${NETTESTSUITE}
> > > perl python logrotate"
> > >  DEFAULT_TEST_SUITES_pn-core-image-x11 = "${MINTESTSUITE}"
> > >  DEFAULT_TEST_SUITES_pn-core-image-lsb = "${NETTESTSUITE} pam
> > > parselogs ${RPMTESTSUITE}"
> > > -DEFAULT_TEST_SUITES_pn-core-image-sato = "ping ssh df connman
> > > syslog
> > > xorg scp date parselogs ${RPMTESTSUITE} \
> > > +DEFAULT_TEST_SUITES_pn-core-image-sato = "${NETTESTSUITE}
> > > connman
> > > xorg parselogs ${RPMTESTSUITE} \
> > >  ${@bb.utils.contains('IMAGE_PKGTYPE', 'rpm', 'python', '',
> > > d)}"
> > > -DEFAULT_TEST_SUITES_pn-core-image-sato-sdk = "ping ssh df
> > > connman
> > > syslog xorg scp date perl ldd gcc kernelmodule python parselogs
> > > ${RPMTESTSUITE}"
> > > +DEFAULT_TEST_SUITES_pn-core-image-sato-sdk = "${NETTESTSUITE}
> > > connman xorg perl python \
> > > +${DEVTESTSUITE} parselogs ${RPMTESTSUITE}"
> > >  DEFAULT_TEST_SUITES_pn-core-image-lsb-dev = "${NETTESTSUITE} pam
> > > perl python parselogs ${RPMTESTSUITE}"
> > > -DEFAULT_TEST_SUITES_pn-core-image-lsb-sdk = "ping buildcvs
> > > buildiptables buildsudoku connman date df gcc kernelmodule ldd
> > > pam
> > > parselogs perl python scp ${RPMTESTSUITE} ssh syslog logrotate"
> > > +DEFAULT_TEST_SUITES_pn-core-image-lsb-sdk = "${NETTESTSUITE}
> > > buildcvs buildiptables buildsudoku \
> > > +connman ${DEVTESTSUITE} pam perl python parselogs
> > 
> > These lots of declarations seem to be suited for a .inc file
> > instead of
> > living in the bbclass.
> > > ${RPMTESTSUITE}"
> > >  DEFAULT_TEST_SUITES_pn-meta-toolchain = "auto"
> > > 
> > >  # aarch64 has no graphics
> > > --
> > > 2.6.2
> > > 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Philip Balister]

On 02/24/2016 11:06 AM, Trevor Woerner wrote:
> Ideally the work done here and the work done on meta-swupdate[1] would
> be somehow merged so people creating images/distros would only have to
> learn and integrate one software update solution, instead of having to
> evaluate and choose between the two (or more?).
> 
> 
> [1] https://github.com/sbabic/meta-swupdate

Amen. I had the same thoughts reading the patch set intro.

Maybe the swupd should go in a seperate layer so we can see which
project works best for oe users before moving something directly into
oe-core?

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

Re: [OE-core] How to integrate third party application software to yocto image

[Maxin B. John]

Hi Winiston,

On Wed, Feb 24, 2016 at 06:20:14PM +0530, winis...@futuraautomation.com wrote:

> -- 
>Hi,
> 
> I can build yocto image for arm based product like AM437x-evm using yocto 
> project. I want to add third party software(Navit) to my image.
>  
> How can I add the third party software to my image ?. Can you provide me the 
> steps to integrate third party software with yocto image ?

Please read this documentation:
http://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#usingpoky-extend-addpkg

>   Note: Navit is a navigation software and it supports arm based product like 
> AM437x. 
>

In the case of Navit, recipe is already available in meta-oe layer:
http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-navigation/navit/navit_svn.bb?h=master

>Host system: Ubuntu 14.04
>Target system : AM437x-evm
> 
>  
>  Regards,
>  Winiston.P
>  Futura Automation Pvt Ltd.

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

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Joshua G Lock]

On Wed, 2016-02-24 at 16:37 +0100, Patrick Ohly wrote:
> Hello!
> 
> I haven't had a chance to play with the actual code yet and I don't
> know
> yet when I'll be able to. Let me ask for some clarifications about
> the
> approach first anyway.
> 
> On Wed, 2016-02-24 at 14:52 +, Joshua Lock wrote:
> > 
> > Approach:
> > An image that inherits the swupd-image bbclass will automatically
> > have bundle
> > 'chroots' created which contain the filesystem contents of the
> > specified
> > bundles, with the contents of the inheriting image forming the
> > default os-core
> > bundle.
> > 
> > The mechanism to achieve this is that several virtual image recipes
> > are created
> > using the swupdbundle class, one for each defined bundle plus a
> > 'mega' image
> > recipe. The 'mega' image contains the base image plus the contents
> > of all of the
> > bundles, whilst bundle images contain only the base image plus the
> > contents of a
> > single bundle.
> Just to be sure, the actual "content" (a term that is a bit too
> overloaded to be used precisely in all cases) of a file and its meta
> attributes will come from the mega image, and the virtual image
> recipes,
> including the base image, are merely used to generate file lists?

That's not currently true, no — the file contents for a bundle come
from the bundle image and the file contents for os-core come from the
base image. It shouldn't be too difficult a change to make, I'll take a
look now.

> What is the content of the actual image that gets created? It has to
> match the content (= file content and meta information) of the mega
> image and not of the base image, otherwise there can be
> inconsistencies
> between the actual running image and the core os bundle. I suppose
> swupd
> will be able to fix that, but I'm not sure.
> 
> It sounds like this bundle creation is completely separated from the
> regular image creation; if so, then I suspect that this may have to
> change.

Right, currently bundle creation happens after image creation and as
above bundles are populated from the rootfs of the bundle images.

You're right, of course, we'll need to construct the running image from
the bundle contents for more complex images.

> > 
> > We took the approach of building images, rather than populating the
> > chroot-like
> > bundle directories with a package manager, because various layers
> > and recipes
> > make changes to the rootfs contents outside of the package manager,
> > particularly
> > with IMAGE_POSTPROCESS_COMMAND, etc.
> Makes sense to me.
> 
> Have you considered generating the file lists more efficiently? I can
> think of some alternatives, but all have downsides.
> 

I did consider a couple of other approaches but with a goal of
submitting this for M3 this approach felt like the surest route within
the time available. I'd certainly like to find a more efficient method
and if you have any suggestions I'd be happy to hear them.

Regards,

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

[OE-core] python-setuptools fetch issues Was: [oe] [meta-python][PATCH 08/11] python-mock: update to 1.3.0

[Martin Jansa]

On Wed, Feb 24, 2016 at 02:04:13PM +0100, Martin Jansa wrote:
> On Mon, Feb 22, 2016 at 08:35:02AM -0500, Derek Straka wrote:
> > Signed-off-by: Derek Straka 

After fixing the download issue, I can see another error, which has the same
root cause (various fetch failures from my jenkins slave when SSLv2 is used).

But more important question is why are setuptools trying to fetch pbr from
outside network and how will we prevent it.

Bitbake builds should be able to create an image just from pre-populated
downloads directory (also when BB_NO_NETWORK is set), this breaks that
principle.

NOTE: recipe python-mock-1.3.0-r0: task do_compile: Started
NOTE: recipe python-mock-1.3.0-r0: task do_populate_lic: Succeeded
ERROR: python-mock-1.3.0-r0 do_compile: python setup.py build execution failed.
ERROR: python-mock-1.3.0-r0 do_compile: Function failed: do_compile (log file 
is located at 
/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/python-mock/1.3.0-r0/temp/log.do_compile.12826)
ERROR: Logfile of failure stored in: 
/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/python-mock/1.3.0-r0/temp/log.do_compile.12826
  
NOTE: recipe python-mock-1.3.0-r0: task do_compile: Failed
ERROR: Task 6 
(/home/jenkins/oe/world/shr-core/meta-openembedded/meta-python/recipes-devtools/python/python-mock_1.3.0.bb,
 do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 853 tasks of which 847 didn't need to be rerun 
and 1 failed.


DEBUG: Executing shell function do_compile
Download error on https://pypi.python.org/simple/pbr/: [SSL: UNKNOWN_PROTOCOL] 
unknown protocol (_ssl.c:590) -- Some packages may not be found!
Couldn't find index page for 'pbr' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [SSL: UNKNOWN_PROTOCOL] 
unknown protocol (_ssl.c:590) -- Some packages may not be found!
No local packages or download links found for pbr>=1.3
Traceback (most recent call last):
  File "setup.py", line 18, in 
pbr=True)
  File 
"/home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/x86_64-linux/usr/lib/python2.7/distutils/core.py",
 line 111, in setup
_setup_distribution = dist = klass(attrs)
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 269, in __init__
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 313, in 
fetch_build_eggs
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 827, in 
resolve
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 1072, in 
best_match
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 1084, in 
obtain
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 380, in 
fetch_build_egg
  File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 
634, in easy_install
distutils.errors.DistutilsError: Could not find suitable distribution for 
Requirement.parse('pbr>=1.3')
WARNING: exit code 1 from a shell command.
ERROR: python setup.py build execution failed.
ERROR: Function failed: do_compile (log file is located at 
/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/python-mock/1.3.0-r0/temp/log.do_compile.12826)




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

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Trevor Woerner]

Ideally the work done here and the work done on meta-swupdate[1] would 
be somehow merged so people creating images/distros would only have to 
learn and integrate one software update solution, instead of having to 
evaluate and choose between the two (or more?).



[1] https://github.com/sbabic/meta-swupdate
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Patrick Ohly]

Hello!

I haven't had a chance to play with the actual code yet and I don't know
yet when I'll be able to. Let me ask for some clarifications about the
approach first anyway.

On Wed, 2016-02-24 at 14:52 +, Joshua Lock wrote:
> Approach:
> An image that inherits the swupd-image bbclass will automatically have bundle
> 'chroots' created which contain the filesystem contents of the specified
> bundles, with the contents of the inheriting image forming the default os-core
> bundle.
> 
> The mechanism to achieve this is that several virtual image recipes are 
> created
> using the swupdbundle class, one for each defined bundle plus a 'mega' image
> recipe. The 'mega' image contains the base image plus the contents of all of 
> the
> bundles, whilst bundle images contain only the base image plus the contents 
> of a
> single bundle.

Just to be sure, the actual "content" (a term that is a bit too
overloaded to be used precisely in all cases) of a file and its meta
attributes will come from the mega image, and the virtual image recipes,
including the base image, are merely used to generate file lists?

What is the content of the actual image that gets created? It has to
match the content (= file content and meta information) of the mega
image and not of the base image, otherwise there can be inconsistencies
between the actual running image and the core os bundle. I suppose swupd
will be able to fix that, but I'm not sure.

It sounds like this bundle creation is completely separated from the
regular image creation; if so, then I suspect that this may have to
change.

> We took the approach of building images, rather than populating the 
> chroot-like
> bundle directories with a package manager, because various layers and recipes
> make changes to the rootfs contents outside of the package manager, 
> particularly
> with IMAGE_POSTPROCESS_COMMAND, etc.

Makes sense to me.

Have you considered generating the file lists more efficiently? I can
think of some alternatives, but all have downsides.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[OE-core] [PATCH 10/10] os-release: sanitise VERSION_ID field

[Joshua Lock]

Per os-release(5) the VERSION_ID field should be:

  a lower-case string (mostly numeric, no spaces or other characters
  outside of 0-9, a-z, ".", "_" and "-")

Do some string manipulation to try and ensure the VERSION_ID field
we write is valid.

Signed-off-by: Joshua Lock 
---
 meta/recipes-core/os-release/os-release.bb | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-core/os-release/os-release.bb 
b/meta/recipes-core/os-release/os-release.bb
index df19ca2..03abc50 100644
--- a/meta/recipes-core/os-release/os-release.bb
+++ b/meta/recipes-core/os-release/os-release.bb
@@ -23,11 +23,20 @@ PRETTY_NAME = "${DISTRO_NAME} ${VERSION}"
 BUILD_ID ?= "${DATETIME}"
 BUILD_ID[vardepsexclude] = "DATETIME"
 
+def sanitise_version(ver):
+# VERSION_ID should be (from os-release(5)):
+#lower-case string (mostly numeric, no spaces or other characters
+#outside of 0-9, a-z, ".", "_" and "-")
+ret = ver.replace('+', '-').replace(' ','_')
+return ret.lower()
+
 python do_compile () {
 import shutil
 with open(d.expand('${B}/os-release'), 'w') as f:
 for field in d.getVar('OS_RELEASE_FIELDS', True).split():
 value = d.getVar(field, True)
+if value and field == 'VERSION_ID':
+value = sanitise_version(value)
 if value:
 f.write('{0}="{1}"\n'.format(field, value))
 if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
-- 
2.5.0

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

[OE-core] [PATCH 09/10] swupd-client: enable native builds

[Joshua Lock]

This is useful for debugging swupd generated artefacts on the build
host i.e. `swupd hashdump`

Signed-off-by: Joshua Lock 
---
 meta/recipes-devtools/swupd/swupd-client_2.87.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/swupd/swupd-client_2.87.bb 
b/meta/recipes-devtools/swupd/swupd-client_2.87.bb
index 73bfeb1..8226624 100644
--- a/meta/recipes-devtools/swupd/swupd-client_2.87.bb
+++ b/meta/recipes-devtools/swupd/swupd-client_2.87.bb
@@ -18,7 +18,7 @@ DEPENDS = "glib-2.0 curl zlib bzip2 xz openssl"
 RDEPENDS_${PN} = "gzip bzip2 tar xz"
 RDEPENDS_${PN}_class-target = "oe-swupd-helpers"
 # We check /etc/os-release for the current OS version number
-RRECOMMENDS_${PN} = "os-release"
+RRECOMMENDS_${PN}_class-target = "os-release"
 
 inherit pkgconfig autotools-brokensep systemd
 
@@ -45,3 +45,5 @@ FILES_${PN} += "\
 
 SYSTEMD_SERVICE_${PN} = "check-update.timer check-update.service"
 SYSTEMD_AUTO_ENABLE_${PN} = "disable"
+
+BBCLASSEXTEND = "native"
-- 
2.5.0

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

[OE-core] [PATCH 04/10] swupd-client: Add recipe

[Joshua Lock]

From: Mariano Lopez 

This commit adds the Clear Linux client updater.
This is experimental and bleeding edge, including the comments on the recipe.

Signed-off-by: Mariano Lopez 
Signed-off-by: Joshua Lock 
---
 .../0001-Tolerate-quotes-in-os-release-files.patch | 59 ++
 ...hange-systemctl-path-to-OE-systemctl-path.patch | 31 
 .../swupd-client/Fix-build-failure-on-Yocto.patch  | 36 +
 .../Right-usage-of-AC_ARG_ENABLE-on-bzip2.patch| 38 ++
 meta/recipes-devtools/swupd/swupd-client_2.87.bb   | 49 ++
 5 files changed, 213 insertions(+)
 create mode 100644 
meta/recipes-devtools/swupd/swupd-client/0001-Tolerate-quotes-in-os-release-files.patch
 create mode 100644 
meta/recipes-devtools/swupd/swupd-client/Change-systemctl-path-to-OE-systemctl-path.patch
 create mode 100644 
meta/recipes-devtools/swupd/swupd-client/Fix-build-failure-on-Yocto.patch
 create mode 100644 
meta/recipes-devtools/swupd/swupd-client/Right-usage-of-AC_ARG_ENABLE-on-bzip2.patch
 create mode 100644 meta/recipes-devtools/swupd/swupd-client_2.87.bb

diff --git 
a/meta/recipes-devtools/swupd/swupd-client/0001-Tolerate-quotes-in-os-release-files.patch
 
b/meta/recipes-devtools/swupd/swupd-client/0001-Tolerate-quotes-in-os-release-files.patch
new file mode 100644
index 000..49c71ae
--- /dev/null
+++ 
b/meta/recipes-devtools/swupd/swupd-client/0001-Tolerate-quotes-in-os-release-files.patch
@@ -0,0 +1,59 @@
+From 586e7b927461f6604ee3a3159cd7a6d4ac22ef30 Mon Sep 17 00:00:00 2001
+From: Dmitry Rozhkov 
+Date: Thu, 11 Feb 2016 13:29:57 +0200
+Subject: [PATCH 1/2] Tolerate quotes in os-release files
+
+Some systems like Yocto or OpenSUSE prefer to wrap values in
+/etc/os-release file with quotes always and that still conforms
+to the format defined in systemd.
+
+This patch removes quotes from the values before trying to
+transform them into integer version id.
+
+Signed-off-by: Dmitry Rozhkov 
+
+Upstream-Status: Backport (v3.0.0+)
+
+---
+ src/version.c | 18 +-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/src/version.c b/src/version.c
+index 0e09cd9..83d6ad4 100644
+--- a/src/version.c
 b/src/version.c
+@@ -88,6 +88,7 @@ int read_version_from_subvol_file(char *path_prefix)
+   FILE *file;
+   int v = -1;
+   char *buildstamp;
++  char *src, *dest;
+ 
+   string_or_die(, "%s/usr/lib/os-release", path_prefix);
+   file = fopen(buildstamp, "rm");
+@@ -106,7 +107,22 @@ int read_version_from_subvol_file(char *path_prefix)
+   break;
+   }
+ 
+-  if (strncmp(line,"VERSION_ID=", 11) == 0) {
++  if (strncmp(line, "VERSION_ID=", 11) == 0) {
++  src = [11];
++
++  /* Drop quotes and newline in value */
++  dest = src;
++  while (*src) {
++  if (*src == '\'' || *src == '"' || *src == 
'\n') {
++  ++src;
++  } else {
++  *dest = *src;
++  ++dest;
++  ++src;
++  }
++  }
++  *dest = 0;
++
+   v = strtoull([11], NULL, 10);
+   break;
+   }
+-- 
+2.5.0
+
diff --git 
a/meta/recipes-devtools/swupd/swupd-client/Change-systemctl-path-to-OE-systemctl-path.patch
 
b/meta/recipes-devtools/swupd/swupd-client/Change-systemctl-path-to-OE-systemctl-path.patch
new file mode 100644
index 000..5ca6373
--- /dev/null
+++ 
b/meta/recipes-devtools/swupd/swupd-client/Change-systemctl-path-to-OE-systemctl-path.patch
@@ -0,0 +1,31 @@
+From 259d86e64146c3156eccfcce0351a9cdc4714766 Mon Sep 17 00:00:00 2001
+From: Jaska Uimonen 
+Date: Thu, 14 Jan 2016 10:17:43 +0200
+Subject: [PATCH] change systemctl path to OE systemctl path
+
+Upstream-Status: Inappropriate
+
+---
+ src/scripts.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/scripts.c b/src/scripts.c
+index e426272..9bec0f5 100644
+--- a/src/scripts.c
 b/src/scripts.c
+@@ -84,10 +84,10 @@ static void update_triggers(void)
+   int ret;
+   LOG_INFO(NULL, "calling systemd trigger", class_scripts, "");
+ 
+-  ret = system("/usr/bin/systemctl daemon-reload");
++  ret = system("/bin/systemctl daemon-reload");
+   if (ret != 0)
+   LOG_ERROR(NULL, "systemd daemon reload failed", class_scripts, 
"%d", ret);
+-  ret = system("/usr/bin/systemctl restart update-triggers.target");
++  ret = system("/bin/systemctl restart update-triggers.target");
+   if (ret != 0)
+   LOG_ERROR(NULL, "systemd 

[OE-core] [PATCH 06/10] swupd-image.bbclass: initial class to support swupd updater

[Joshua Lock]

This class takes care of generating appropriate inputs for the swupd-server
to process, specifically the separate 'chroot'-like directory structures that
swupd-server expects to represent bundles.

It will then use swupd-server to process these 'chroot'-like directories into
update artefacts that are generated in a child of ${DEPLOYDIR}.

Co-authored by Joshua Lock & Mariano Lopez

Signed-off-by: Mariano Lopez 
Signed-off-by: Joshua Lock 
---
 meta/classes/swupd-image.bbclass | 372 +++
 1 file changed, 372 insertions(+)
 create mode 100644 meta/classes/swupd-image.bbclass

diff --git a/meta/classes/swupd-image.bbclass b/meta/classes/swupd-image.bbclass
new file mode 100644
index 000..27d5f41
--- /dev/null
+++ b/meta/classes/swupd-image.bbclass
@@ -0,0 +1,372 @@
+# Class for swupd integration -- generates input artefacts for consumption by
+# swupd-server and calls swupd-server to process the inputs into update
+# artefacts for consumption by swupd-client.
+#
+# Limitations:
+# * Machine specific: generated swupd update artefacts are for a single MACHINE
+#   only as reflected in the DEPLOY_DIR directories.
+#
+# Usage:
+# * inherit this class in your core OS image. swupd-based OS's use bundles, the
+#   primary one of which, os-core, is defined as the contents of this image.
+# * Assign a list of names for bundles you wish to generate to the
+#   SWUPD_BUNDLES variable i.e. SWUPD_BUNDLES = "feature_one feature_two"
+# * Assign a list of packages for which their content should be included in
+#   a bundle to a varflag of BUNDLE_CONTENTS which matches the bundle name
+#   i.e. BUNDLE_CONTENTS[feature_one] = "package_one package_three package_six"
+# * Ensure the OS_VERSION variable is assigned an integer value and increased
+#   before each image build which should generate swupd update artefacts.
+#
+# An image that inherits this class will automatically have bundle 'chroots'
+# created which contain the filesystem contents of the specified bundles.
+# The mechanism to achieve this is that several virtual image recipes are
+# created, one for each defined bundle plus a 'mega' image recipe.
+# The 'mega' image contains the base image plus all of the bundles, whilst
+# bundle images contain only the base image plus the contents of a single
+# bundle.
+#
+# We build the mega image first, then the base image (the one which inherits
+# this class)and finally all of the bundle images  . Each non-mega image
+# has a manifest generated that lists all of the file contents of the image.
+#
+# Once the images and their manifests have been created each bundle image
+# manifest is compared to the base image manifest in order to generate a delta
+# list of files in the bundle image which don't exist in the base image.
+# Files in this list are then preserved in the bundle directory for processing
+# by swupd-server in order to generate update artefacts.
+#
+# Note: the reason for generating the mega image is to ensure that all files
+# which are staged from the shared sysroot, i.e. passwd and groups, are
+# fully populated.
+# This is not an ideal compromise and requires further thought.
+#
+# TODO: we're copying a lot of potentially duplicate files into
+# DEPLOY_DIR_SWUPD consider using hardlink to de-duplicate the files and save
+# some disk space.
+
+DEPLOY_DIR_SWUPDBASE = "${DEPLOY_DIR}/swupd/${MACHINE}"
+SWUPD_ROOTFS_MANIFEST = "${IMAGE_BASENAME}-files-in-image.txt"
+
+# User configurable variables to disable all swupd processing or deltapack
+# generation.
+SWUPD_GENERATE ??= "1"
+SWUPD_DELTAPACKS ??= "1"
+# Create delta packs for N versions back — default 2
+SWUPD_N_DELTAPACK ??= "2"
+# Amount the OS_VERSION should be increased by for each release, used by the
+# delta pack looping to generate delta packs going back up toSWUPD_N_DELTAPACK
+# releases
+SWUPD_VERSION_STEP ??= "10"
+
+# This version number *must* map to VERSION_ID in /etc/os-release and *must* be
+# a non-negative integer that fits in an int.
+OS_VERSION ??= "${DISTRO_VERSION}"
+
+IMAGE_INSTALL_append = " swupd-client os-release"
+# We need full-fat versions of these for swupd (at least as of 2.87)
+IMAGE_INSTALL_append = " gzip bzip2 tar xz"
+
+inherit distro_features_check
+REQUIRED_DISTRO_FEATURES = "systemd"
+
+python () {
+if d.getVar('VIRTUAL-RUNTIME_init_manager', True) != 'systemd':
+bb.error('swupd integration requires the systemd init manager')
+
+ver = d.getVar('OS_VERSION', True) or 'invalid'
+try:
+int(ver)
+except ValueError:
+bb.fatal("Invalid value for OS_VERSION (%s), must be a non-negative 
integer value." % ver)
+
+pn_base = d.getVar('PN_BASE', True)
+if pn_base is not None:
+# We want all virtual images from this recipe to deploy to the same
+# directory
+deploy_dir = d.getVar('DEPLOY_DIR_SWUPDBASE')
+deploy_dir = os.path.join(deploy_dir, pn_base)
+

[OE-core] [PATCH 07/10] oe-swupd-helpers: provide swupd-client required helper scripts and units

[Joshua Lock]

swup-client tries to call out to certain helper scripts during an update:
* before the update clr_pre_update.sh is called
* after the update systemdboot_updater.sh and kernel_updater.sh are called
* the systemd update-triggers.target is restarted once the update is complete

Clear Linux, the incubation OS for swupd, provides Clear specific
implementations of the systemd units in clr-systemd-units and the helper
scripts in clr-specialized-helpers.

This patch introduces a recipe which provides minimal, stub,
implementations of the required helper scripts and units. These will
need overriding by a product and will in future be improved to be generically
useful for OE-Core images.

Signed-off-by: Joshua Lock 
---
 meta/recipes-devtools/swupd/oe-swupd-helpers.bb| 39 ++
 .../swupd/oe-swupd-helpers/catalog-trigger.service |  8 +
 .../swupd/oe-swupd-helpers/clr_pre_update.sh   | 16 +
 .../swupd/oe-swupd-helpers/kernel_updater.sh   |  9 +
 .../oe-swupd-helpers/ldconfig-trigger.service  |  8 +
 .../swupd/oe-swupd-helpers/systemdboot_updater.sh  | 10 ++
 .../oe-swupd-helpers/tmpfiles-trigger.service  |  8 +
 .../swupd/oe-swupd-helpers/update-triggers.target  |  5 +++
 8 files changed, 103 insertions(+)
 create mode 100644 meta/recipes-devtools/swupd/oe-swupd-helpers.bb
 create mode 100644 
meta/recipes-devtools/swupd/oe-swupd-helpers/catalog-trigger.service
 create mode 100755 
meta/recipes-devtools/swupd/oe-swupd-helpers/clr_pre_update.sh
 create mode 100755 
meta/recipes-devtools/swupd/oe-swupd-helpers/kernel_updater.sh
 create mode 100644 
meta/recipes-devtools/swupd/oe-swupd-helpers/ldconfig-trigger.service
 create mode 100755 
meta/recipes-devtools/swupd/oe-swupd-helpers/systemdboot_updater.sh
 create mode 100644 
meta/recipes-devtools/swupd/oe-swupd-helpers/tmpfiles-trigger.service
 create mode 100644 
meta/recipes-devtools/swupd/oe-swupd-helpers/update-triggers.target

diff --git a/meta/recipes-devtools/swupd/oe-swupd-helpers.bb 
b/meta/recipes-devtools/swupd/oe-swupd-helpers.bb
new file mode 100644
index 000..4690f21
--- /dev/null
+++ b/meta/recipes-devtools/swupd/oe-swupd-helpers.bb
@@ -0,0 +1,39 @@
+SUMMARY = "OE swupd helper files"
+DESCRIPTION = "swupd-client assumes the presence of various helpers, this is a 
minimal OE \
+implementation of the required scripts and systemd units. \
+Scripts are modified versions of those in clr-specialized-updaters and units 
are modified \
+versions of those in clr-systemd-config"
+LICENSE = "GPL-2.0"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+SRC_URI = "file://update-triggers.target \
+   file://catalog-trigger.service \
+   file://ldconfig-trigger.service \
+   file://tmpfiles-trigger.service \
+   file://clr_pre_update.sh \
+   file://kernel_updater.sh \
+   file://systemdboot_updater.sh \
+   "
+
+inherit allarch distro_features_check systemd
+
+REQUIRED_DISTRO_FEATURES = "systemd"
+
+do_install () {
+install -d ${D}${systemd_system_unitdir}
+for svc in `find ${WORKDIR} -maxdepth 1 -name *.target -o -name 
*.service`; do
+install -m 0644 $svc ${D}${systemd_system_unitdir}/
+sed -i -e s#/bin#${base_bindir}# 
${D}${systemd_system_unitdir}/`basename $svc`
+sed -i -e s#/sbin#${base_sbindir}# 
${D}${systemd_system_unitdir}/`basename $svc`
+sed -i -e s#/lib#${base_libdir}# 
${D}${systemd_system_unitdir}/`basename $svc`
+done
+
+# NOTE: swupd-client hard-codes /usr/bin
+install -d ${D}/usr/bin
+for helper in `find ${WORKDIR} -maxdepth 1 -name *.sh`; do
+install $helper ${D}/usr/bin/
+done
+}
+
+RDEPENDS_${PN} += "bash"
+FILES_${PN} += "${systemd_system_unitdir}"
\ No newline at end of file
diff --git 
a/meta/recipes-devtools/swupd/oe-swupd-helpers/catalog-trigger.service 
b/meta/recipes-devtools/swupd/oe-swupd-helpers/catalog-trigger.service
new file mode 100644
index 000..8266174
--- /dev/null
+++ b/meta/recipes-devtools/swupd/oe-swupd-helpers/catalog-trigger.service
@@ -0,0 +1,8 @@
+[Unit]
+Description=Rebuild journal catalog
+Documentation=man:journalctl(1)
+BindsTo=update-triggers.target
+
+[Service]
+Type=oneshot
+ExecStart=/bin/journalctl --update-catalog
diff --git a/meta/recipes-devtools/swupd/oe-swupd-helpers/clr_pre_update.sh 
b/meta/recipes-devtools/swupd/oe-swupd-helpers/clr_pre_update.sh
new file mode 100755
index 000..6302090
--- /dev/null
+++ b/meta/recipes-devtools/swupd/oe-swupd-helpers/clr_pre_update.sh
@@ -0,0 +1,16 @@
+#!/bin/bash
+set -u
+
+###
+# Clear Linux General Purpose Pre-update helper script
+#  This is a script meant to update state information external to what swupd 
updates.
+#  The specific content of this script will vary over time, according to the 
state
+#  change needed

[OE-core] [PATCH 01/10] rsync: add native variant

[Joshua Lock]

---
 meta/recipes-devtools/rsync/rsync_3.1.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/rsync/rsync_3.1.2.bb 
b/meta/recipes-devtools/rsync/rsync_3.1.2.bb
index 71c2045..7237f43 100644
--- a/meta/recipes-devtools/rsync/rsync_3.1.2.bb
+++ b/meta/recipes-devtools/rsync/rsync_3.1.2.bb
@@ -26,3 +26,5 @@ do_configure_prepend () {
 do_configure_append () {
cp -f ${S}/configure ${S}/configure.sh
 }
+
+BBCLASSEXTEND = "native"
-- 
2.5.0

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

[OE-core] [PATCH 08/10] swupd-client: RDEPENDS on oe-swupd-helpers

[Joshua Lock]

The oe-swupd-helpers package provides scripts and units that swupd-client
calls before, during and after the update process.

Signed-off-by: Joshua Lock 
---
 meta/recipes-devtools/swupd/swupd-client_2.87.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/swupd/swupd-client_2.87.bb 
b/meta/recipes-devtools/swupd/swupd-client_2.87.bb
index a5afdd6..73bfeb1 100644
--- a/meta/recipes-devtools/swupd/swupd-client_2.87.bb
+++ b/meta/recipes-devtools/swupd/swupd-client_2.87.bb
@@ -16,9 +16,7 @@ SRC_URI[sha256sum] = 
"45df259a7dc2fed985ee9961e112120fc46670dd75476c3262fc6804b1
 
 DEPENDS = "glib-2.0 curl zlib bzip2 xz openssl"
 RDEPENDS_${PN} = "gzip bzip2 tar xz"
-# swupd requires at least an update-triggers target, should it be part of the
-# swupd-client package?
-RDEPENDS_${PN} = "swupd-units"
+RDEPENDS_${PN}_class-target = "oe-swupd-helpers"
 # We check /etc/os-release for the current OS version number
 RRECOMMENDS_${PN} = "os-release"
 
-- 
2.5.0

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

[OE-core] [PATCH 05/10] swupdbundle: new class to generate virtual images for swupd-image

[Joshua Lock]

Our initial strategy to generate bundles for consumption by swupd
is to generate images which contain the base image (os-core) plus
the additional contents of the bundle, then prune out the core
contents. By generating images in this manner we hope to accomodate
packages which modify the rootfs outside of installing files, i.e.
with postinsts.

To that end this class, to be used via BBCLASSEXTEND, will generate
virtual image recipes that add extra packages to the extended
image.

Only extensions matching entries in a SWUPD_BUNDLES variable are
valid and the bundle contents should be listed in a varFlag
matching the bundle's name on the BUNDLE_CONTENTS variable.

An example of usage in an image recipe follows:

SWUPD_BUNDLES = "foo bar"
BUNDLE_CONTENTS[foo] = "foo foo-bar foobaz"
BUNDLE_CONTENTS[bar] = "bar baz quux"

BBCLASSEXTEND = "swupdbundle:foo"

Signed-off-by: Joshua Lock 
---
 meta/classes/swupdbundle.bbclass | 59 
 1 file changed, 59 insertions(+)
 create mode 100644 meta/classes/swupdbundle.bbclass

diff --git a/meta/classes/swupdbundle.bbclass b/meta/classes/swupdbundle.bbclass
new file mode 100644
index 000..897666d
--- /dev/null
+++ b/meta/classes/swupdbundle.bbclass
@@ -0,0 +1,59 @@
+# Our initial strategy to generate bundles for consumption by swupd is to
+# generate images which contain the base image (os-core) plus the additional
+# contents of the bundle, then prune out the core contents. By generating
+# images in this manner we hope to accomodate packages which modify the rootfs
+# outside of installing files, i.e.with postinsts.
+#
+# To that end this class, to be used via BBCLASSEXTEND, will generate virtual
+# image recipes that add extra packages to the extended image.
+#
+# Only extensions matching entries in a SWUPD_BUNDLES variable are valid and
+# the bundle contents should be listed in a varFlag matching the bundle's name
+# on the BUNDLE_CONTENTS variable. i.e in foo-image.bb:
+#
+# SWUPD_BUNDLES = "foo bar"
+# BUNDLE_CONTENTS[foo] = "foo foo-bar foobaz"
+# BUNDLE_CONTENTS[bar] = "bar baz quux"
+# BBCLASSEXTEND = "swupdbundle:foo"
+
+python swupdbundle_virtclass_handler () {
+pn = e.data.getVar("PN", True)
+cls = e.data.getVar("BBEXTENDCURR", True)
+bundle = e.data.getVar("BBEXTENDVARIANT", True)
+
+if cls != 'swupdbundle':
+return
+
+if not bundle:
+bb.fatal('swupdbundle must be used with a parameter i.e. 
BBCLASSEXTEND="swupdbundle:foo"')
+
+# Rename the virtual recipe to create the desired image bundle variant.
+e.data.setVar("PN_BASE", pn)
+pn = pn + '-' + bundle
+e.data.setVar("PN", pn)
+e.data.setVar("BUNDLE_NAME", bundle)
+
+bundles = (e.data.getVar('SWUPD_BUNDLES', True) or "").split()
+if not bundles:
+bb.fatal('SWUPD_BUNDLES is not defined, this variable should list 
bundles for the image.')
+
+curr_install = (e.data.getVar('IMAGE_INSTALL', True) or "").split()
+
+def get_bundle_contents(bndl):
+contents = e.data.getVarFlag('BUNDLE_CONTENTS', bndl, True)
+if contents:
+return contents.split()
+else:
+bb.fatal('BUNDLE_CONTENTS[%s] is not set, this should list the 
packages to be included in the bundle.' % bndl)
+
+if bundle == 'mega':
+for bndl in bundles:
+curr_install += get_bundle_contents(bndl)
+else:
+curr_install += get_bundle_contents(bundle)
+
+e.data.setVar('IMAGE_INSTALL', ' '.join(curr_install))
+}
+
+addhandler swupdbundle_virtclass_handler
+swupdbundle_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
-- 
2.5.0

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

[OE-core] [PATCH 02/10] swupd-server: initial recipe 2.53

[Joshua Lock]

Include some patches to remove hard-coded state directory and backport some
fixes.

Signed-off-by: Joshua Lock 
---
 ...S-to-take-the-state-data-dir-as-an-argume.patch | 782 +
 ...argv-helper-for-safer-calls-to-system-uti.patch | 133 
 ...re-option-to-re-enable-config-files-in-ma.patch |  66 ++
 ...ression-that-introduced-a-directory-named.patch |  29 +
 meta/recipes-devtools/swupd/swupd-server_2.53.bb   |  33 +
 5 files changed, 1043 insertions(+)
 create mode 100644 
meta/recipes-devtools/swupd/swupd-server/0001-Add-option-S-to-take-the-state-data-dir-as-an-argume.patch
 create mode 100644 
meta/recipes-devtools/swupd/swupd-server/0001-Add-system_argv-helper-for-safer-calls-to-system-uti.patch
 create mode 100644 
meta/recipes-devtools/swupd/swupd-server/0002-Add-configure-option-to-re-enable-config-files-in-ma.patch
 create mode 100644 
meta/recipes-devtools/swupd/swupd-server/0002-Fix-regression-that-introduced-a-directory-named.patch
 create mode 100644 meta/recipes-devtools/swupd/swupd-server_2.53.bb

diff --git 
a/meta/recipes-devtools/swupd/swupd-server/0001-Add-option-S-to-take-the-state-data-dir-as-an-argume.patch
 
b/meta/recipes-devtools/swupd/swupd-server/0001-Add-option-S-to-take-the-state-data-dir-as-an-argume.patch
new file mode 100644
index 000..b771e0a
--- /dev/null
+++ 
b/meta/recipes-devtools/swupd/swupd-server/0001-Add-option-S-to-take-the-state-data-dir-as-an-argume.patch
@@ -0,0 +1,782 @@
+From 83fbb8a78594cf9047e37ed0aa1e931b9d691f2a Mon Sep 17 00:00:00 2001
+From: Joshua Lock 
+Date: Thu, 28 Jan 2016 10:24:56 +
+Subject: [PATCH 1/2] Add option -S to take the state data dir as an argument
+
+The optional -S option expects a full path to a directory
+swupd-server should use instead of the default /var/lib/update.
+
+Signed-off-by: Joshua Lock 
+
+Upstream-Status: Accepted (v3.0+)
+
+---
+ include/swupd.h  | 11 ++---
+ src/analyze_fs.c |  4 ++--
+ src/chroot.c | 13 ++-
+ src/globals.c| 53 +
+ src/main.c   | 50 ++-
+ src/make_fullfiles.c | 63 +
+ src/make_packs.c | 66 
+ src/pack.c   | 65 +++
+ src/rename.c |  6 ++---
+ src/versions.c   |  6 ++---
+ 10 files changed, 264 insertions(+), 73 deletions(-)
+
+diff --git a/include/swupd.h b/include/swupd.h
+index 775c28e..58307d9 100644
+--- a/include/swupd.h
 b/include/swupd.h
+@@ -16,9 +16,6 @@
+ #define SWUPD_DEFAULT_FORMAT  3
+ 
+ #define SWUPD_SERVER_STATE_DIR "/var/lib/update"
+-#define PACKSTAGE_DIR SWUPD_SERVER_STATE_DIR "/packstage"
+-#define IMAGE_DIR SWUPD_SERVER_STATE_DIR "/image"
+-#define STAGING_DIR SWUPD_SERVER_STATE_DIR "/www"
+ 
+ #if SWUPD_WITH_SELINUX
+ #define TAR_PERM_ATTR_ARGS "--preserve-permissions --xattrs 
--xattrs-include='*' --selinux"
+@@ -123,9 +120,17 @@ extern int newversion;
+ extern int minversion;
+ extern char *format_string;
+ 
++extern char *state_dir;
++extern char *packstage_dir;
++extern char *image_dir;
++extern char *staging_dir;
++
+ extern bool init_globals(void);
+ extern void free_globals(void);
+ extern bool set_format_string(char *);
++extern bool set_state_dir(char *);
++extern bool init_state_globals(void);
++extern void free_state_globals(void);
+ 
+ extern int file_sort_hash(gconstpointer a, gconstpointer b);
+ extern int file_sort_filename(gconstpointer a, gconstpointer b);
+diff --git a/src/analyze_fs.c b/src/analyze_fs.c
+index 2326237..fdc359a 100644
+--- a/src/analyze_fs.c
 b/src/analyze_fs.c
+@@ -389,7 +389,7 @@ struct manifest *full_manifest_from_directory(int version)
+ 
+   manifest = alloc_manifest(version, "full");
+ 
+-  string_or_die(, "%s/%i/full", IMAGE_DIR, version);
++  string_or_die(, "%s/%i/full", image_dir, version);
+ 
+   threadpool = g_thread_pool_new(get_hash, dir, 12, FALSE, NULL);
+ 
+@@ -413,7 +413,7 @@ struct manifest *sub_manifest_from_directory(char 
*component, int version)
+ 
+   manifest = alloc_manifest(version, component);
+ 
+-  string_or_die(, "%s/%i/%s", IMAGE_DIR, version, component);
++  string_or_die(, "%s/%i/%s", image_dir, version, component);
+ 
+   iterate_directory(manifest, dir, "", false);
+ 
+diff --git a/src/chroot.c b/src/chroot.c
+index 1d7df95..c5bb942 100644
+--- a/src/chroot.c
 b/src/chroot.c
+@@ -40,14 +40,15 @@ void chroot_create_full(int newversion)
+   char * command;
+   char *full_dir;
+ 
+-  string_or_die(_dir, "%s/%i/full/", IMAGE_DIR, newversion);
++  string_or_die(_dir, "%s/%i/full/ ", image_dir, newversion);
+ 
+   g_mkdir_with_parents(full_dir, S_IRWXU);
+ 
+ 
+   /* start with base */
+   LOG(NULL, "Copying chroot os-core to full", "");
+-  

[OE-core] [PATCH 03/10] hardlink: add new recipe

[Joshua Lock]

---
 meta/recipes-extended/hardlink/hardlink_0.3.0.bb | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 meta/recipes-extended/hardlink/hardlink_0.3.0.bb

diff --git a/meta/recipes-extended/hardlink/hardlink_0.3.0.bb 
b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
new file mode 100644
index 000..2e06ac2
--- /dev/null
+++ b/meta/recipes-extended/hardlink/hardlink_0.3.0.bb
@@ -0,0 +1,19 @@
+SUMMARY = "hardlink is a tool which replaces multiple copies of a file with 
hardlinks."
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://hardlink.c;endline=22;md5=168464a4fc92fa7389c53b0755b39fbb"
+
+SRC_URI = "http://jak-linux.org/projects/hardlink/${BPN}_${PV}.tar.xz;
+SRC_URI[md5sum] = "72f1a460adb6874c151deab766e434ad"
+SRC_URI[sha256sum] = 
"e8c93dfcb24aeb44a75281ed73757cb862cc63b225d565db1c270af9dbb7300f"
+
+DEPENDS = "libpcre attr"
+
+do_compile () {
+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' BINDIR='${bindir}'
+}
+
+do_install () {
+   oe_runmake install 'DESTDIR=${D}' 'PREFIX=${prefix}' BINDIR='${bindir}'
+}
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.5.0

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

[OE-core] [PATCH 00/10] Integrate swupd software updater

[Joshua Lock]

This series provides an initial set of changes to enable integration of the
swupd (https://clearlinux.org/features/software-update) software updater into an
image.

The changes are in the relatively early stages but I am hoping to land this work
before the M3 feature freeze so that the 2.1 release provides a foundation for
experimenting with swupd.

Approach:
An image that inherits the swupd-image bbclass will automatically have bundle
'chroots' created which contain the filesystem contents of the specified
bundles, with the contents of the inheriting image forming the default os-core
bundle.

The mechanism to achieve this is that several virtual image recipes are created
using the swupdbundle class, one for each defined bundle plus a 'mega' image
recipe. The 'mega' image contains the base image plus the contents of all of the
bundles, whilst bundle images contain only the base image plus the contents of a
single bundle.

We build the mega image first, then the base image (the one which inherits this
class) and finally all of the bundle images. Each non-mega image has a manifest
generated that lists the file contents of the image.

We took the approach of building images, rather than populating the chroot-like
bundle directories with a package manager, because various layers and recipes
make changes to the rootfs contents outside of the package manager, particularly
with IMAGE_POSTPROCESS_COMMAND, etc.

Once the images and their manifests have been created each bundle image manifest
is compared to the base image manifest in order to generate a list of files in
the bundle image which don't exist in the base image.
Files in this list are then preserved in the bundle directory for processing by
swupd-server in order to generate update artefacts.

Finally the binaries from swupd-server are called on the bundle directories to
generate the artefacts for consumption by a swupd client.

How to:
* inherit the swupd-image class in your core OS image. swupd-based OS's use
  bundles, the primary one of which, os-core, is defined as the contents of this
  image.
* Assign a list of names for bundles you wish to generate to the SWUPD_BUNDLES
  variable i.e.

  SWUPD_BUNDLES = "feature_one feature_two"
* Assign a list of packages for which their content should be included in a
  bundle to a varflag of BUNDLE_CONTENTS which matches the bundle name i.e.

  BUNDLE_CONTENTS[feature_one] = "package_one package_three package_six"
* Ensure the OS_VERSION variable is assigned an integer value and increased
  before each image build which should generate swupd update artefacts. This
  variable must echo the same version number as is used to set the VERSION_ID
  field of os-release as swupd-client will use it to check for updates.
* Publish the contents of ${DEPLOY_DIR}/swupd/${MACHINE}/${IMAGE_BASENAME}/www
  on a server for consumption by swupd-client
* Use swupd client sub-commands with the -u argument pointing to the contents
  published above

Known issues:
* shared pseudo database: the bundle chroot-like directories are generated
  per-recipe and processed by a task of the inheriting recipe. In order for the
  files generated outside of the base recipe to have correct permissions when
  processed by swupd-server we need to share a pseudo database across the
  recipes.
  This database is currently never cleaned up, which is likely to cause
  headaches due to the way pseudo operates on inodes that could be reused
  outside of pseudo's influence. We have yet to determine an appropriate time to
  perform housekeeping on this database (we essentially need the database to be
  removed when DEPLOY_DIR_SWUPD is removed).
* oe-swupd-helpers: this recipe provides stub implementations only of some
  swupd-client helpers. Anyone wishing to utilise swupd in a deployed image will
  need to at least override kernel_updater.sh and systemdboot_updater.sh.
* hard-coded paths: swupd assumes Clear Linux as a host OS and hard-codes
  several paths to directories, programs and configuration files on Clear.
* builds a lot of images: due to the approach taken there are n+2 images built,
  where n is the number of bundles defined in SWUPD_BUNDLES.
* creates a lot of duplicate files: due to the way swupd works by processing
  chroot-like bundle directories on each os release we potentially end up
  carrying a lot of duplicate files in DEPLOY_DIR_SWUPD. We intend to look at
  using the hardlink program to replace duplicate files in that directory with
  hard links in order to save disk space.
* requires far more testing: there are a lot of combinations of bundle contents,
  rootfs modification commands (IMAGE_POSTPROCESS_COMMAND,
  IMAGE_PREPROCESS_COMMAND, etc) that can affect the inputs to swupd and our
  testing has likely missed areas of issue.
* OS_VERSION: introduces a new variable for the OS version number when we
  already have a DISTRO_VERSION variable. This was done because swupd makes
  various assumptions about the version number which 

Re: [OE-core] [PATCH 1/7] ffmpeg: update to 2.8.6

[Martin Jansa]

On Wed, Feb 24, 2016 at 03:28:16PM +0200, Alexander Kanavin wrote:
> On 02/24/2016 03:16 PM, Martin Jansa wrote:
> 
> > The distro needs to set ARM_INSTRUCTION_SET to "thumb" in order to enable
> > actually using this TUNE_FEATURE.
> >
> > With recent improvements in tune files you should clearly see that
> > default qemuarm builds are using TUNE_PKGARCH without "t" in it which
> > means that "thumb" isn't enabled.
> 
> Should we actually test this on autobuilders then? The change passed 
> them fine, even though it shouldn't have.

Yes, that's what I was suggesting in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [OE-core] [PATCH 1/7] ffmpeg: update to 2.8.6

[Alexander Kanavin]

On 02/24/2016 03:16 PM, Martin Jansa wrote:


The distro needs to set ARM_INSTRUCTION_SET to "thumb" in order to enable
actually using this TUNE_FEATURE.

With recent improvements in tune files you should clearly see that
default qemuarm builds are using TUNE_PKGARCH without "t" in it which
means that "thumb" isn't enabled.


Should we actually test this on autobuilders then? The change passed 
them fine, even though it shouldn't have.


Alex

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

[OE-core] State of bitbake world, test-dependencies 2016-02-24

[Martin Jansa]

On Mon, Dec 14, 2015 at 08:03:47PM +0100, Martin Jansa wrote:
> This time full build (testing all recipes available in "my world" - 2503
> recipes), it took record-breaking 25days to finish.
> 
> Complete log:
> http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20151120_144802.log/
>  
> I've already sent patches for few of them, will send one for pulseaudio-lirc 
> as well
> as I already have it in out local recipes. For the rest I would appreciate 
> some help
> from people actually using these recipes.
> 
> I'll trigger new incremental build after that huge meta-oe patch queue from 
> master-next
> is in master.
> 
> ERROR: 34 issues were found in these recipes: clutter-gst-3.0 
> cryptodev-module ctdb gnome-panel jasper lcdproc libftdi mpd places 
> pulseaudio python python3 rain rygel samba shr-e-gadgets shr-wizard snort 
> sysdig tmux uptime vboxguestdrivers xfce4-clipman-plugin

Complete log:
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20160223_111019.log/

There are many issues in current master, but as a bonus we get separate
build log for each issue so it's easier for any contributor to check his
favourite recipe and send fix for it (please do).

ERROR: 111 issues were found in these recipes:
android-image-utils-native chkconfig-alternatives-native
compat-wireless-all core-image-rt core-image-rt-sdk core-image-sato-dev
core-image-sato-sdk core-image-testmaster cryptodev-module
dfu-util-native efivar ffmpeg firefox gnome-panel iksemel iscsitarget
libconnman-qt5 libetpan libftdi libgdata libnice ltp-ddt netmap
netmap-modules nodejs perf pidgin proxy-libintl pty-forward-native
python python-feedparser python-flufl-enum python-mock python-monotonic
python-msgpack python-tornado-redis python-txws python-ujson python3
qt4-x11-free remake samba samsung-modem-mgr samsung-rfs-mgr shr-image
shr-image-all shr-lite-image snort synergy system-config-keyboard thrift
tracker xfce4-clipman-plugin

Found differences: 
WARN: gnome-panel: gnome-panel rdepends on dbus-lib, but it isn't a build 
dependency?
WARN: libftdi: libftdi rdepends on libgcc, but it isn't a build dependency?
WARN: libftdi: libftdi rdepends on libstdc++, but it isn't a build dependency?
WARN: python: python-tkinter rdepends on glibc, but it isn't a build dependency?
WARN: python: python-tkinter rdepends on libpython2, but it isn't a build 
dependency?
WARN: python: python-tkinter rdepends on tcl-lib, but it isn't a build 
dependency?
WARN: python3: python3-tkinter rdepends on glibc, but it isn't a build 
dependency?
WARN: python3: python3-tkinter rdepends on libpython3, but it isn't a build 
dependency?
WARN: python3: python3-tkinter rdepends on tcl-lib, but it isn't a build 
dependency?
WARN: samba: samba rdepends on libpam, but it isn't a build dependency?
WARN: xfce4-clipman-plugin: xfce4-clipman-plugin rdepends on qrencode, but it 
isn't a build dependency?

Recipes failing with TMPDIR empty:
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20160223_111019.log/3_min/failed/
3_min/failed/android-image-utils-native.log
3_min/failed/compat-wireless-all.log
3_min/failed/core-image-rt-sdk.log
3_min/failed/core-image-rt.log
3_min/failed/core-image-sato-dev.log
3_min/failed/core-image-sato-sdk.log
3_min/failed/core-image-testmaster.log
3_min/failed/dfu-util-native.log
3_min/failed/efivar.log
3_min/failed/ffmpeg.log
3_min/failed/firefox.log
3_min/failed/iksemel.log
3_min/failed/iscsitarget.log
3_min/failed/libconnman-qt5.log
3_min/failed/libetpan.log
3_min/failed/libgdata.log
3_min/failed/libnice.log
3_min/failed/ltp-ddt.log
3_min/failed/nodejs.log
3_min/failed/perf.log
3_min/failed/pidgin.log
3_min/failed/proxy-libintl.log
3_min/failed/pty-forward-native.log
3_min/failed/python-feedparser.log
3_min/failed/python-flufl-enum.log
3_min/failed/python-mock.log
3_min/failed/python-monotonic.log
3_min/failed/python-msgpack.log
3_min/failed/python-tornado-redis.log
3_min/failed/python-txws.log
3_min/failed/python-ujson.log
3_min/failed/qt4-x11-free.log
3_min/failed/samsung-modem-mgr.log
3_min/failed/samsung-rfs-mgr.log
3_min/failed/shr-image-all.log
3_min/failed/shr-image.log
3_min/failed/shr-lite-image.log
3_min/failed/snort.log
3_min/failed/synergy.log
3_min/failed/system-config-keyboard.log
3_min/failed/tracker.log

Recipes failing even with TMPDIR already populated:
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20160223_111019.log/2_max/failed/
2_max/failed/chkconfig-alternatives-native.log
2_max/failed/compat-wireless-all.log
2_max/failed/core-image-rt-sdk.log
2_max/failed/core-image-rt.log
2_max/failed/core-image-sato-dev.log
2_max/failed/core-image-sato-sdk.log
2_max/failed/cryptodev-module.log
2_max/failed/dfu-util-native.log
2_max/failed/efivar.log
2_max/failed/ffmpeg.log
2_max/failed/firefox.log
2_max/failed/iksemel.log
2_max/failed/iscsitarget.log
2_max/failed/libconnman-qt5.log
2_max/failed/libetpan.log
2_max/failed/libgdata.log
2_max/failed/libnice.log

Re: [OE-core] [PATCH 1/7] ffmpeg: update to 2.8.6

[Martin Jansa]

On Wed, Feb 24, 2016 at 02:34:32PM +0200, Alexander Kanavin wrote:
> On 02/24/2016 03:55 AM, Martin Jansa wrote:
> > Fails to build for qemuarm when thumb is enabled.
> >
> > Why was:
> > ARM_INSTRUCTION_SET = "arm"
> >
> > removed in
> > http://git.openembedded.org/openembedded-core/commit/?id=77dbf07293df15cd5473422abd678930d6277bb0
> >
> > without checking if it works?
> 
> That line has no explanation of its intent and dates back to before 
> 2009. I had also checked that ffmpeg builds fine with default qemuarm 
> configuration (and just checked that it still does), so it was dropped 
> as old cruft.
> 
> I see that 'thumb' is in TUNE_FEATURES for qemuarm, but not sure if that 
> is same as 'thumb is enabled'. How do I make it break?

"thumb" in TUNE_FEATURES only means that given MACHINE (with given
DEFAULTTUNE) is capable of executing thumb binaries.

The distro needs to set ARM_INSTRUCTION_SET to "thumb" in order to enable
actually using this TUNE_FEATURE.

With recent improvements in tune files you should clearly see that
default qemuarm builds are using TUNE_PKGARCH without "t" in it which
means that "thumb" isn't enabled.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [OE-core] [PATCH 0/2] libsoup-2.4: cleanup + disable libsoup-gnome by default

[Martin Jansa]

On Thu, Feb 18, 2016 at 11:21:23AM -0800, Andre McCurdy wrote:
> Andre McCurdy (2):
>   libsoup-2.4: minor formatting improvements
>   libsoup-2.4: disable libsoup-gnome by default
> 
>  meta/recipes-support/libsoup/libsoup-2.4_2.52.2.bb | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)

It looks like this was merged without suggested fix for upgrade-path.

Will you please send follow-up patch?

It also most likely breaks libgdata in meta-oe (for complete log see bitbake 
world
reports or errors.yoctoproject.org)

  | configure: error: Package requirements (libsoup-gnome-2.4) were not met:
  | 
  | No package 'libsoup-gnome-2.4' found

Maybe it will be resolved by libgdata upgrade sent in
gobject-introspective set, so this is just FYI.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

[OE-core] How to integrate third party application software to yocto image

[winiston]

Hi,

I can build yocto image for arm based product like AM437x-evm using yocto 
project. I want to add third party software(Navit) to my image.

How can I add the third party software to my image ?. Can you provide me the 
steps to integrate third party software with yocto image ?

Note: Navit is a navigation software and it supports arm based product like 
AM437x. 

Host system: Ubuntu 14.04
Target system : AM437x-evm


Regards,
Winiston.P
Futura Automation Pvt Ltd.

Ph :91-80-28375290 / 28375295
Fax :91-80-28375291
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/7] ffmpeg: update to 2.8.6

[Alexander Kanavin]

On 02/24/2016 03:55 AM, Martin Jansa wrote:

Fails to build for qemuarm when thumb is enabled.

Why was:
ARM_INSTRUCTION_SET = "arm"

removed in
http://git.openembedded.org/openembedded-core/commit/?id=77dbf07293df15cd5473422abd678930d6277bb0

without checking if it works?


That line has no explanation of its intent and dates back to before 
2009. I had also checked that ffmpeg builds fine with default qemuarm 
configuration (and just checked that it still does), so it was dropped 
as old cruft.


I see that 'thumb' is in TUNE_FEATURES for qemuarm, but not sure if that 
is same as 'thumb is enabled'. How do I make it break?


Alex


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

[OE-core] [PATCH v3 2/2] kernel: Make symbol link to vmlinuz in boot directory

[zhe.he]

From: He Zhe 

Rename do_kernel_link_vmlinux to do_kernel_link_images and make a
symbol link to vmlinuz(if exists) for reference in arch/$arch/boot
directory.

Signen-off-by: He Zhe 
---
 meta/classes/kernel.bbclass   | 13 -
 meta/conf/documentation.conf  |  2 +-
 meta/recipes-kernel/linux/linux-yocto.inc |  2 +-
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 3f92fdc..8cc944c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -474,15 +474,18 @@ python split_kernel_packages () {
 }
 
 # Many scripts want to look in arch/$arch/boot for the bootable
-# image. This poses a problem for vmlinux based booting. This 
-# task arranges to have vmlinux appear in the normalized directory
-# location.
-do_kernel_link_vmlinux() {
+# image. This poses a problem for vmlinux and vmlinuz based
+# booting. This task arranges to have vmlinux and vmlinuz appear
+# in the normalized directory location.
+do_kernel_link_images() {
if [ ! -d "${B}/arch/${ARCH}/boot" ]; then
mkdir ${B}/arch/${ARCH}/boot
fi
cd ${B}/arch/${ARCH}/boot
ln -sf ../../../vmlinux
+   if [ -f ../../../vmlinuz ]; then
+   ln -sf ../../../vmlinuz
+   fi
 }
 
 do_strip() {
@@ -512,7 +515,7 @@ do_strip() {
 }
 do_strip[dirs] = "${B}"
 
-addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
+addtask do_strip before do_sizecheck after do_kernel_link_images
 
 # Support checking the kernel size since some kernels need to reside in 
partitions
 # with a fixed length or there is a limit in transferring the kernel to memory
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index b3969b0..f0c2399 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -28,7 +28,7 @@ do_install_ptest_base[doc] = "Copies the runtime test suite 
files from the compi
 do_kernel_checkout[doc] = "Checks out source/meta branches for a linux-yocto 
style kernel"
 do_kernel_configcheck[doc] = "Validates the kernel configuration for a 
linux-yocto style kernel"
 do_kernel_configme[doc] = "Assembles the kernel configuration for a 
linux-yocto style kernel"
-do_kernel_link_vmlinux[doc] = "Creates a symbolic link in arch/$arch/boot for 
vmlinux kernel images"
+do_kernel_link_images[doc] = "Creates a symbolic link in arch/$arch/boot for 
vmlinux and vmlinuz kernel images"
 do_listtasks[doc] = "Lists all defined tasks for a target"
 do_menuconfig[doc] = "Runs 'make menuconfig' for the kernel"
 do_package[doc] = "Analyzes the content of the holding area and splits it into 
subsets based on available packages and files"
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 6b161fc..fd68786 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -52,6 +52,6 @@ do_install_append(){
 }
 
 # extra tasks
-addtask kernel_link_vmlinux after do_compile before do_install
+addtask kernel_link_images after do_compile before do_install
 addtask validate_branches before do_patch after do_kernel_checkout
 addtask kernel_configcheck after do_configure before do_compile
-- 
1.9.1

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

[OE-core] [PATCH v3 1/2] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

[zhe.he]

From: He Zhe 

Add KERNEL_IMAGETYPES to support building packaging and installing
multi types of kernel images, such as zImage uImage, at one time.

KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.

Signed-off-by: He Zhe 
---
 meta/classes/kernel-fitimage.bbclass|  20 ++--
 meta/classes/kernel-grub.bbclass|  44 +---
 meta/classes/kernel-uimage.bbclass  |  22 ++--
 meta/classes/kernel.bbclass | 174 +++-
 meta/conf/documentation.conf|   1 +
 meta/recipes-kernel/linux/linux-dtb.inc |  49 +
 6 files changed, 208 insertions(+), 102 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index f1b409c..633668f 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
+if 'fitImage' in kerneltypes.split():
 depends = d.getVar("DEPENDS", True)
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
@@ -10,7 +10,9 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
+if 'fitImage' in typeformake.split():
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
typeformake.replace('fitImage', 'zImage'))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -154,7 +156,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
kernelcount=1
dtbcount=""
rm -f fit-image.its
@@ -217,14 +219,14 @@ addtask assemble_fitimage before do_install after 
do_compile
 
 kernel_do_deploy_append() {
# Update deploy directory
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
cd ${B}
echo "Copying fit-image.its source file..."
-   
its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+   its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its ${DEPLOYDIR}/${its_base_name}.its
-   
linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+   
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin 
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass b/meta/classes/kernel-grub.bbclass
index a63f482..f7dcc07 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -10,41 +10,44 @@
 #   updates the new kernel as the boot priority.
 #
 
-pkg_preinst_kernel-image_append () {
+python __anonymous () {
+import re
+
+preinst = '''
# Parsing confliction
[ -f "$D/boot/grub/menu.list" ] && grubcfg="$D/boot/grub/menu.list"
[ -f "$D/boot/grub/grub.cfg" ] && grubcfg="$D/boot/grub/grub.cfg"
if [ -n "$grubcfg" ]; then
# Dereference symlink to avoid confliction with new kernel name.
-   if grep -q "/${KERNEL_IMAGETYPE} \+root=" $grubcfg; then
-   if [ -L "$D/boot/${KERNEL_IMAGETYPE}" ]; then
-   kimage=`realpath $D/boot/${KERNEL_IMAGETYPE} 
2>/dev/null`
+   if grep -q "/KERNEL_IMAGETYPE \+root=" $grubcfg; then
+   if [ -L "$D/boot/KERNEL_IMAGETYPE" ]; then
+   kimage=`realpath $D/boot/KERNEL_IMAGETYPE 
2>/dev/null`
if [ -f "$D$kimage" ]; then
-   sed -i "s:${KERNEL_IMAGETYPE} 
\+root=:${kimage##*/} root=:" $grubcfg
+   sed -i "s:KERNEL_IMAGETYPE 
\+root=:${kimage##*/} root=:" $grubcfg
fi
fi
fi
 
# Rename old kernel if it conflicts with new kernel name.
-   if grep -q "/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} \+root=" 
$grubcfg; then
-   

[OE-core] [PATCH v3 0/2] Yocto Bug #6945

[zhe.he]

From: He Zhe 

v1 to v2:
 - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
 - Update related doc files
 - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
 - Link built vmlinuz to boot directory for reference

v2 to v3:
 - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in order that 
users can still use the old variables.
 - Run oe_rummake in a loop for every types so that we can add different 
configurations to them easily in the future.
 - Warn, intead of die, users if one of the types are over the size limit.
 - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2.
 - Remove the doc parts. They will be submitted yocto-docs later.
 - Change some grep usage to make it more clear.
 - Correct a typo.

The following changes since commit 23056103c949b498c23b47579e8dd57ce78e6ed9:

  uclibc: Do not use immediate expansion operator (2016-02-22 20:42:48 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib zhe/yocto-bug-6945
  
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/yocto-bug-6945

for you to fetch changes up to dc52a1efbb8248ea274a1cd0cca5734290b3025f:

  kernel: Make symbol link to vmlinuz in boot directory (2016-02-24 07:08:16 
-0500)


He Zhe (2):
  kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
  kernel: Make symbol link to vmlinuz in boot directory

 meta/classes/kernel-fitimage.bbclass  |  20 ---
 meta/classes/kernel-grub.bbclass  |  44 
+---
 meta/classes/kernel-uimage.bbclass|  22 
 meta/classes/kernel.bbclass   | 187 
---
 meta/conf/documentation.conf  |   3 ++-
 meta/recipes-kernel/linux/linux-dtb.inc   |  49 
++--
 meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
 7 files changed, 218 insertions(+), 109 deletions(-)

He Zhe (2):
  kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
  kernel: Make symbol link to vmlinuz in boot directory

 meta/classes/kernel-fitimage.bbclass  |  20 ++--
 meta/classes/kernel-grub.bbclass  |  44 ---
 meta/classes/kernel-uimage.bbclass|  22 ++--
 meta/classes/kernel.bbclass   | 187 +-
 meta/conf/documentation.conf  |   3 +-
 meta/recipes-kernel/linux/linux-dtb.inc   |  49 +---
 meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
 7 files changed, 218 insertions(+), 109 deletions(-)

-- 
1.9.1

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

Re: [OE-core] [PATCH 6/7] webkitgtk: update to 2.10.7

[Alexander Kanavin]

On 02/16/2016 05:55 PM, akuster808 wrote:


Yes, which means that jethro (which has 2.8.5) needs the same update.


there is a bug open for that 8877. there are a huge number of CVE's that
need fixing.


I wrote a comment in that bug, but I think it bears repeating here:

Please read this, it's a bit long, but worth it:

https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

Summary: the upstream will not backport CVE fixes, and they will not be 
making point releases in old branches with any kind of lifecycle 
guarantee. Providing ongoing updates to the latest stable release of 
webkit is the only way to stay secure.


So I believe that you indeed have to update webkit to 2.10.7, or 
whatever is the latest stable release, and keep doing this for as long 
as a yocto release needs to be supported.


Regards,
Alex

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

Re: [OE-core] [PATCH] base.bbclass wipe ${S} before unpacking source

[Markus Lehtonen]

On Tue, 2016-02-23 at 18:23 +, Burton, Ross wrote:
> 
> On 23 February 2016 at 18:01, Christopher Larson  > wrote:
> > db isn't the only recipe doing that. The fetcher unpack method
> > knows where it's unpacking to, I think if anyone should be clearing
> > out the destination first, it should. 
> If that's true for tarballs, I agree.  I was also wondering if this
> should just be unpack[cleandirs] = ${S}
The problem is that the fetcher does not now the target directory, i.e.
it does not examine the content of tar/zip. Implementing that logic for
different archive formats would require a lot more work.
Using cleandirs sounds good to me. I.e. something like:
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1372f38..aa107d4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -133,23 +133,15 @@ python base_do_fetch() {
 
 addtask unpack after do_fetch
 do_unpack[dirs] = "${WORKDIR}"
+do_unpack[cleandirs] = "${@d.getVar('S', True) if d.getVar('S', True)
!= d.getVar('WORKDIR', True) else ''}"
 python base_do_unpack() {
 src_uri = (d.getVar('SRC_URI', True) or "").split()
 if len(src_uri) == 0:
 return
 
-rootdir = d.getVar('WORKDIR', True)
-
-# Ensure that we cleanup ${S}/patches
-# TODO: Investigate if we can remove
-# the entire ${S} in this case.
-s_dir = d.getVar('S', True)
-p_dir = os.path.join(s_dir, 'patches')
-bb.utils.remove(p_dir, True)
-
 try:
 fetcher = bb.fetch2.Fetch(src_uri, d)
-fetcher.unpack(rootdir)
+fetcher.unpack(d.getVar('WORKDIR', True))
 except bb.fetch2.BBFetchException as e:
 raise bb.build.FuncFailed(e)
 }-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/4] sanity.bbclass: remove conflict checking for image vm and live

[Robert Yang]

[YOCTO #9161]

Signed-off-by: Robert Yang 
---
 meta/classes/sanity.bbclass |   12 
 1 file changed, 12 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 466eb49..edf49da 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -843,18 +843,6 @@ def check_sanity_everybuild(status, d):
 with open(checkfile, "w") as f:
 f.write(tmpdir)
 
-# Check vmdk and live can't be built together.
-if 'vmdk' in d.getVar('IMAGE_FSTYPES', True) and 'live' in 
d.getVar('IMAGE_FSTYPES', True):
-status.addresult("Error, IMAGE_FSTYPES vmdk and live can't be built 
together\n")
-
-# Check vdi and live can't be built together.
-if 'vdi' in d.getVar('IMAGE_FSTYPES', True) and 'live' in 
d.getVar('IMAGE_FSTYPES', True):
-status.addresult("Error, IMAGE_FSTYPES vdi and live can't be built 
together\n")
-
-# Check qcow2 and live can't be built together.
-if 'qcow2' in d.getVar('IMAGE_FSTYPES', True) and 'live' in 
d.getVar('IMAGE_FSTYPES', True):
-status.addresult("Error, IMAGE_FSTYPES qcow2 and live can't be built 
together\n")
-
 # Check /bin/sh links to dash or bash
 real_sh = os.path.realpath('/bin/sh')
 if not real_sh.endswith('/dash') and not real_sh.endswith('/bash'):
-- 
1.7.9.5

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

[OE-core] [PATCH 3/4] syslinux.bbclass: make vm and live can be built together

[Robert Yang]

* The vm image(hdddirect, vmdk, qcow2, vdi) and live image (hddimg, iso)
  couldn't be built together because the following vars settings are
  conflicted:
  - SYSLINUX_ROOT (/dev/sda2 vs /dev/ram0)
  - LABELS (boot vs boot install)
  - INITRD (None vs live install)
  - SYSLINUX_CFG (see above)
  Introduce new vars (SYSLINUX_ROOT_VM/_LIVE, the samilar to others) to
  make them can work together, now we can build all of them together:

  IMAGE_FSTYPES += "live iso hddimg hdddirect vmdk qcow2 vdi"

* Use SYSLINUX_CFG rather than SYSLINUXCFG to keep align with others
  SYSLINUX vars.

* The SYSLINUX_TIMEOUT had been set, but it didn't work since
  AUTO_SYSLINUXMENU wasn't set, this would cause confusions, so also set
  AUTO_SYSLINUXMENU.

* Move SYSLINUX_PROMPT and SYSLINUX_TIMEOUT to syslinux.bbclass rather
  than in separate classes since they are the same.

* Set SYSLINUX_TIMEOUT to 50 to have a unique timeout for syslinux.

[YOCTO #9161]

Signed-off-by: Robert Yang 
---
 meta/classes/boot-directdisk.bbclass |8 
 meta/classes/bootimg.bbclass |1 +
 meta/classes/image-live.bbclass  |   16 
 meta/classes/image-vm.bbclass|   15 +++
 meta/classes/syslinux.bbclass|   23 ++-
 5 files changed, 38 insertions(+), 25 deletions(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index 89007e3..fcdef26 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -53,14 +53,13 @@ def pcbios_class(d):
 PCBIOS = "${@pcbios(d)}"
 PCBIOS_CLASS = "${@pcbios_class(d)}"
 
+# Get the build_syslinux_cfg() function from the syslinux class
 inherit ${PCBIOS_CLASS}
 inherit ${EFI_CLASS}
 
-# Get the build_syslinux_cfg() function from the syslinux class
-
 DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
-SYSLINUX_ROOT ?= "root=/dev/sda2"
-SYSLINUX_TIMEOUT ?= "10"
+SYSLINUX_ROOT_VM ?= "root=/dev/sda2"
+SYSLINUX_CFG_VM  ?= "${S}/syslinux_hdd.cfg"
 
 boot_direct_populate() {
dest=$1
@@ -162,6 +161,7 @@ build_boot_dd() {
 python do_bootdirectdisk() {
 validate_disk_signature(d)
 if d.getVar("PCBIOS", True) == "1":
+syslinux_set_vars(d, 'VM')
 bb.build.exec_func('build_syslinux_cfg', d)
 if d.getVar("EFI", True) == "1":
 bb.build.exec_func('build_efi_cfg', d)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index b174266..7946839 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -281,6 +281,7 @@ build_hddimg() {
 
 python do_bootimg() {
 if d.getVar("PCBIOS", True) == "1":
+syslinux_set_vars(d, 'LIVE')
 bb.build.exec_func('build_syslinux_cfg', d)
 if d.getVar("EFI", True) == "1":
 bb.build.exec_func('build_efi_cfg', d)
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index badf40d..b8f21cb 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -1,10 +1,10 @@
 
-INITRD_IMAGE ?= "core-image-minimal-initramfs"
-INITRD ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz"
-SYSLINUX_ROOT ?= "root=/dev/ram0"
-SYSLINUX_TIMEOUT ?= "50"
-SYSLINUX_LABELS ?= "boot install"
-LABELS_append = " ${SYSLINUX_LABELS} "
+INITRD_IMAGE_LIVE ?= "core-image-minimal-initramfs"
+INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
+SYSLINUX_ROOT_LIVE ?= "root=/dev/ram0"
+SYSLINUX_LABELS_LIVE ?= "boot install"
+LABELS_LIVE ?= "${SYSLINUX_LABELS_LIVE}"
+SYSLINUX_CFG_LIVE ?= "${S}/syslinux_live.cfg"
 
 ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.ext4"
 
@@ -19,9 +19,9 @@ IMAGE_TYPES_MASKED += "live hddimg iso"
 
 python() {
 image_b = d.getVar('IMAGE_BASENAME', True)
-initrd_i = d.getVar('INITRD_IMAGE', True)
+initrd_i = d.getVar('INITRD_IMAGE_LIVE', True)
 if image_b == initrd_i:
-bb.error('INITRD_IMAGE %s cannot use image live, hddimg or iso.' % 
initrd_i)
+bb.error('INITRD_IMAGE_LIVE %s cannot use image live, hddimg or iso.' 
% initrd_i)
 bb.fatal('Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.')
 else:
 d.appendVarFlag('do_bootimg', 'depends', ' %s:do_image_complete' % 
initrd_i)
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index 6f3a55b..17e87a5 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -1,18 +1,17 @@
 
-SYSLINUX_PROMPT ?= "0"
-SYSLINUX_LABELS = "boot"
-LABELS_append = " ${SYSLINUX_LABELS} "
+SYSLINUX_LABELS_VM ?= "boot"
+LABELS_VM ?= "${SYSLINUX_LABELS_VM}"
 
-# Using an initramfs is optional. Enable it by setting INITRD_IMAGE.
-INITRD_IMAGE ?= ""
-INITRD ?= "${@'${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz' if 
'${INITRD_IMAGE}' else ''}"
-do_bootdirectdisk[depends] += "${@'${INITRD_IMAGE}:do_image_complete' if 
'${INITRD_IMAGE}' else ''}"
+# Using an initramfs is optional. Enable it by setting 

[OE-core] [PATCH 2/4] boot-directdisk.bbclass: drop IS_VM chechking

[Robert Yang]

The IS_VM was used for making menus for vmdk, vdi and qcow2, except
hddimg, there is no reason to not make menus for hddimg, so drop it.

Signed-off-by: Robert Yang 
---
 meta/classes/boot-directdisk.bbclass |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index ce637b8..89007e3 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -62,8 +62,6 @@ DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
 SYSLINUX_ROOT ?= "root=/dev/sda2"
 SYSLINUX_TIMEOUT ?= "10"
 
-IS_VM = '${@bb.utils.contains_any("IMAGE_FSTYPES", ["vmdk", "vdi", "qcow2"], 
"true", "false", d)}'
-
 boot_direct_populate() {
dest=$1
install -d $dest
@@ -102,12 +100,10 @@ build_boot_dd() {
efi_hddimg_populate $HDDDIR
fi
 
-   if [ "${IS_VM}" = "true" ]; then
-   if [ "x${AUTO_SYSLINUXMENU}" = "x1" ] ; then
-   install -m 0644 
${STAGING_DIR}/${MACHINE}/usr/share/syslinux/vesamenu.c32 
$HDDDIR/${SYSLINUXDIR}/
-   if [ "x${SYSLINUX_SPLASH}" != "x" ] ; then
-   install -m 0644 ${SYSLINUX_SPLASH} 
$HDDDIR/${SYSLINUXDIR}/splash.lss
-   fi
+   if [ "x${AUTO_SYSLINUXMENU}" = "x1" ] ; then
+   install -m 0644 
${STAGING_DIR}/${MACHINE}/usr/share/syslinux/vesamenu.c32 
$HDDDIR/${SYSLINUXDIR}/
+   if [ "x${SYSLINUX_SPLASH}" != "x" ] ; then
+   install -m 0644 ${SYSLINUX_SPLASH} 
$HDDDIR/${SYSLINUXDIR}/splash.lss
fi
fi
 
-- 
1.7.9.5

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

[OE-core] [PATCH 1/4] image-live/boot-directdisk.bbclass: remove AUTO_SYSLINUXCFG

[Robert Yang]

No one uses it.

Signed-off-by: Robert Yang 
---
 meta/classes/boot-directdisk.bbclass |1 -
 meta/classes/image-live.bbclass  |1 -
 2 files changed, 2 deletions(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index ee8c744..ce637b8 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -58,7 +58,6 @@ inherit ${EFI_CLASS}
 
 # Get the build_syslinux_cfg() function from the syslinux class
 
-AUTO_SYSLINUXCFG = "1"
 DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
 SYSLINUX_ROOT ?= "root=/dev/sda2"
 SYSLINUX_TIMEOUT ?= "10"
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index d2314aa..badf40d 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -1,5 +1,4 @@
 
-AUTO_SYSLINUXCFG = "1"
 INITRD_IMAGE ?= "core-image-minimal-initramfs"
 INITRD ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz"
 SYSLINUX_ROOT ?= "root=/dev/ram0"
-- 
1.7.9.5

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

[OE-core] [PATCH 0/4] make vm + live images can build together

[Robert Yang]

Hello,

These patches can make vm and live images build together, and also make
the images easier to use.

I'd like to combine the following classes if you are fine with it:
* boot-directdisk.bbclass and image-vm.bbclass into image-vm.bbclass.
  They are used for making vm images.
* bootimg.bbclass and image-live.bbclass into image-live.bbclass.
  They are used for making live images.
Combine them can make them easier to understand and also make the
structure clearer.

// Robert

The following changes since commit 205b446f3fc4a9885179a66a8dab9d81bcc63dca:

  uclibc: Do not use immediate expansion operator (2016-02-22 20:42:34 +)

are available in the git repository at:

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

Robert Yang (4):
  image-live/boot-directdisk.bbclass: remove AUTO_SYSLINUXCFG
  boot-directdisk.bbclass: drop IS_VM chechking
  syslinux.bbclass: make vm and live can be built together
  sanity.bbclass: remove conflict checking for image vm and live

 meta/classes/boot-directdisk.bbclass |   21 -
 meta/classes/bootimg.bbclass |1 +
 meta/classes/image-live.bbclass  |   17 -
 meta/classes/image-vm.bbclass|   15 +++
 meta/classes/sanity.bbclass  |   12 
 meta/classes/syslinux.bbclass|   23 ++-
 6 files changed, 42 insertions(+), 47 deletions(-)

-- 
1.7.9.5

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

Re: [OE-core] [PATCH 1/1] useradd_base.bbclass: fix simultaneous with flock

[Kang Kai]

On 2016年02月24日 01:10, Burton, Ross wrote:


On 23 February 2016 at 17:01, Burton, Ross > wrote:


The *amazing* BB_VERBOSE_LOGS option (set to 1 in local.conf to
get all shell scripts to do set -x) tells me this is due to
missing quotes around the opts assignment:


Why do some of the opts assignments just do opts=$2, and others do a sed?


In the previous version, there are:

local opts="$2"
...

opts=`echo $opts | sed s/\'/\"/g`

And I want to refactor them but lost the double quotes.

Only do sed operations for useradd and groupadd that they may be passed in 
"opts" with space but others didn't.

I'll restore to previous version.

Sorry for inconvenience that I built pass on Ubuntu 14.04 so didn't find 
this error.


--Kai



Ross



--
Regards,
Neil | Kai Kang

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