[OE-core] [PATCH 0/1] fetch2/git.py: fix _latest_revision for local PREMIRROR

[Robert Yang]

The following changes since commit 64da20b8555350e1b0d761c36499532e83ca9827:

  multilib_global.bbclass: fix PREFERRED_VERSION for cross-canadian (2015-08-12 
23:51:13 -0700)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib rbt/auto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/auto

Robert Yang (1):
  fetch2/git.py: fix _latest_revision for local PREMIRROR

 bitbake/lib/bb/fetch2/git.py |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
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 0/1] fetch2/git.py: fix _latest_revision for local PREMIRROR

[Robert Yang]

Sorry, please ignore this one, wrong mailing list.

// Robert

On 08/13/2015 03:08 PM, Robert Yang wrote:

The following changes since commit 64da20b8555350e1b0d761c36499532e83ca9827:

   multilib_global.bbclass: fix PREFERRED_VERSION for cross-canadian 
(2015-08-12 23:51:13 -0700)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib rbt/auto
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/auto

Robert Yang (1):
   fetch2/git.py: fix _latest_revision for local PREMIRROR

  bitbake/lib/bb/fetch2/git.py |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)


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

[OE-core] [PATCH 0/3] populate_sdk_base.bbclass: fixes for multilib sdk

[Robert Yang]

Fixed for multilib sdk:
MACHINE ?= "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

$ bitbake core-image-minimal -cpopulate_sdk 

Extrat the sdk, both environment-setup-core2-64-poky-linux and
environment-setup-x86-pokymllib32-linux can compile hello.c after
sourced.

This has fixed "bitbake core-image-minimal -cpopulate_sdk", but the sdk
of "bitbake lib32-core-image-minimal -cpopulate_sdk" doesn't work, I'm
not sure what is preferred, include both 32 and 64 bit sdk as "bitbake
core-image-minimal -cpopulate_sdk" does or only 32bit ? What's your
opinion, please ?

// Robert

The following changes since commit cb8d309ff0ea0ca11edc2aae75ddd869491cb330:

  perf: fix build breakage on kernels after 4.1 (2015-08-12 11:31:01 -0700)

are available in the git repository at:

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

Robert Yang (3):
  toolchain-shar-extract.sh: add a space in the end
  populate_sdk_base.bbclass: help rpm to pull in multilib toolchain
  packagegroup-core-standalone-sdk-target: remove qemuwrapper-cross

 meta/classes/populate_sdk_base.bbclass |   32 
 meta/files/toolchain-shar-extract.sh   |4 +--
 .../packagegroup-core-standalone-sdk-target.bb |1 -
 3 files changed, 34 insertions(+), 3 deletions(-)

-- 
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/3] packagegroup-core-standalone-sdk-target: remove qemuwrapper-cross

[Robert Yang]

Remove qemuwrapper-cross from RDEPENDS, install a cross pkg in sysroots
isn't useful, if we really need run qemuwrapper in SDK, we should add it
as nativesdk, and it has multilib conflicts when populate_ sdk:

error: file /usr/bin/crossscripts/qemuwrapper from install of
qemuwrapper-cross-1.0-r0.lib32_x86 conflicts with file from package
qemuwrapper-cross-1.0-r0.core2_64

[YOCTO #8089]

Signed-off-by: Robert Yang 
---
 .../packagegroup-core-standalone-sdk-target.bb |1 -
 1 file changed, 1 deletion(-)

diff --git 
a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
index 5d1ce97..37f5e43 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
@@ -10,5 +10,4 @@ RDEPENDS_${PN} = "\
 libstdc++ \
 libstdc++-dev \
 ${LIBC_DEPENDENCIES} \
-qemuwrapper-cross \
 "
-- 
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/3] toolchain-shar-extract.sh: add a space in the end

[Robert Yang]

For a clear look when input.

[YOCTO #8089]

Signed-off-by: Robert Yang 
---
 meta/files/toolchain-shar-extract.sh |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/files/toolchain-shar-extract.sh 
b/meta/files/toolchain-shar-extract.sh
index 0a33ee8..3a50991 100644
--- a/meta/files/toolchain-shar-extract.sh
+++ b/meta/files/toolchain-shar-extract.sh
@@ -92,11 +92,11 @@ fi
 
 if [ -e "$target_sdk_dir/environment-setup-@REAL_MULTIMACH_TARGET_SYS@" ]; then
echo "The directory \"$target_sdk_dir\" already contains a SDK for this 
architecture."
-   printf "If you continue, existing files will be overwritten! 
Proceed[y/N]?"
+   printf "If you continue, existing files will be overwritten! 
Proceed[y/N]? "
 
default_answer="n"
 else
-   printf "You are about to install the SDK to \"$target_sdk_dir\". 
Proceed[Y/n]?"
+   printf "You are about to install the SDK to \"$target_sdk_dir\". 
Proceed[Y/n]? "
 
default_answer="y"
 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 2/3] populate_sdk_base.bbclass: help rpm to pull in multilib toolchain

[Robert Yang]

When configure multilib, "bitbake  -c populate_sdk" should
install all arch toolchains (for example, 32 and 64bit), but rpm not
handle the multilib requires correctly, for example:
lib32-packagegroup-core-standalone-sdk-target requires lib32-libc6, rpm
may pull in libc6 rather than lib32-libc6, if we directly use something
like IMAGE_INSTALL_append = " lib32-libc6", then it works well, so
update TOOLCHAIN_TARGET_TASK to include the RDEPENDS packages will fix
the issue.

[YOCTO #8089]

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

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index a9e9bd7..c2491ea 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -83,8 +83,40 @@ POPULATE_SDK_POST_HOST_COMMAND_append = " 
write_host_sdk_manifest; "
 fakeroot python do_populate_sdk() {
 from oe.sdk import populate_sdk
 from oe.manifest import create_manifest, Manifest
+import oe.packagedata
 
 pn = d.getVar('PN', True)
+# Help rpm to pull in multilib requires since it may not pull in
+# them correctly, for example,
+# lib32-packagegroup-core-standalone-sdk-target requires
+# lib32-libc6, rpm may pull in libc6 rather than lib32-libc6, but
+# directly use
+# TOOLCHAIN_TARGET_TASK_append = " lib32-libc6" works well.
+for pkg in (d.getVar('TOOLCHAIN_TARGET_TASK', True) or "").split():
+sub_data = oe.packagedata.read_subpkgdata(pkg, d)
+sub_rdep = sub_data.get("RDEPENDS_" + pkg)
+if not sub_rdep:
+continue
+done = sub_rdep.split()
+next = done
+# Find all the rdepends on the dependency chain
+while next:
+new = []
+for sub_pkg in next:
+sub_data = oe.packagedata.read_subpkgdata(sub_pkg, d)
+sub_pkg_rdep = sub_data.get("RDEPENDS_" + sub_pkg)
+if not sub_pkg_rdep:
+continue
+for p in sub_pkg_rdep.split():
+if p in done:
+continue
+if not p.startswith('(') and \
+oe.packagedata.has_subpkgdata(p, d):
+# It's a new rdep
+done.append(p)
+new.append(p)
+next = new
+d.appendVar('TOOLCHAIN_TARGET_TASK', ' ' + " ".join(done))
 runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", pn, d)
 runtime_mapping_rename("TOOLCHAIN_TARGET_TASK_ATTEMPTONLY", pn, d)
 
-- 
1.7.9.5

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

[OE-core] [PATCH] glibc: package nscd related files

[rongqing.li]

From: Roy Li 

install nscd related configuration file, startup files, and package them,
make nscd easy to startup

Signed-off-by: Roy Li 
---
 meta/recipes-core/glibc/glibc-package.inc | 37 ++-
 meta/recipes-core/glibc/glibc.inc |  2 +-
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 8ea5915..5f7c8a9 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -49,7 +49,8 @@ FILES_libsotruss = "${libdir}/audit/sotruss-lib.so"
 FILES_SOLIBSDEV = "${libdir}/lib*${SOLIBSDEV}"
 FILES_${PN}-dev += "${bindir}/rpcgen ${libdir}/*_nonshared.a 
${base_libdir}/*_nonshared.a ${base_libdir}/*.o ${datadir}/aclocal"
 FILES_${PN}-staticdev += "${libdir}/*.a ${base_libdir}/*.a"
-FILES_nscd = "${sbindir}/nscd*"
+FILES_nscd = "${sbindir}/nscd* ${sysconfdir}/init.d/nscd 
${systemd_unitdir}/system/nscd* ${sysconfdir}/tmpfiles.d/nscd.conf \
+  ${sysconfdir}/nscd.conf ${sysconfdir}/default/volatiles/98_nscd 
${localstatedir}/db/nscd"
 FILES_${PN}-mtrace = "${bindir}/mtrace"
 FILES_tzcode = "${bindir}/tzselect ${sbindir}/zic ${sbindir}/zdump"
 FILES_${PN}-utils = "${bindir}/* ${sbindir}/*"
@@ -105,6 +106,29 @@ do_install_append () {
rmdir ${D}${sysconfdir}
fi
fi
+
+   if echo ${PN}|grep -q "glibc-initial"; then
+   return
+   fi
+
+   install -d ${D}${sysconfdir}/init.d
+   install -d ${D}${localstatedir}/db/nscd
+   install -m 0755 ${S}/nscd/nscd.init ${D}${sysconfdir}/init.d/nscd
+   install -m 0755 ${S}/nscd/nscd.conf ${D}${sysconfdir}/nscd.conf
+   sed -i "s%daemon%start-stop-daemon --start --exec%g" 
${D}${sysconfdir}/init.d/nscd
+
+   install -d ${D}${systemd_unitdir}/system
+   install -m 0644 ${S}/nscd/nscd.service ${D}${systemd_unitdir}/system/
+
+   if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
d)}; then
+   install -d ${D}${sysconfdir}/tmpfiles.d
+   echo "d /run/nscd 755 root root -" \
+   > ${D}${sysconfdir}/tmpfiles.d/nscd.conf
+   else
+   install -d ${D}${sysconfdir}/default/volatiles
+   echo "d root root 0755 /var/run/nscd none" \
+   > ${D}${sysconfdir}/default/volatiles/98_nscd
+   fi
 }
 
 do_install_append_aarch64 () {
@@ -174,3 +198,14 @@ glibc_package_preprocess () {
rm -rf ${PKGD}${exec_prefix}/lib
fi
 }
+
+pkg_postinst_nscd () {
+   if [ -z "$D" ]; then
+   if command -v systemd-tmpfiles >/dev/null; then
+   systemd-tmpfiles --create 
${sysconfdir}/tmpfiles.d/nscd.conf
+   elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
+   ${sysconfdir}/init.d/populate-volatile.sh update
+   fi
+   fi
+}
+CONFFILES_nscd="${sysconfdir}/nscd.conf"
diff --git a/meta/recipes-core/glibc/glibc.inc 
b/meta/recipes-core/glibc/glibc.inc
index 74ad0b5..03ffb2f 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -41,7 +41,7 @@ DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial 
linux-libc-headers
 #RDEPENDS_${PN} += "${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}"
 PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc"
 PROVIDES += "virtual/libintl virtual/libiconv"
-inherit autotools texinfo distro_features_check
+inherit autotools texinfo distro_features_check systemd
 require glibc-options.inc
 
 # The main purpose of setting this variable is to prevent users from accidently
-- 
1.9.1

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

Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Philip Balister]

On 08/11/2015 10:46 PM, Otavio Salvador wrote:
> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross  wrote:
>>
>> On 11 August 2015 at 16:46, Khem Raj  wrote:
>>>
>>> can we freeze this thread please.
>>
>>
>> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
>> someone on this list asks what Poky is, 99% of the time they're trolling.
>> :)
>>
>> The original and unanswered question was "should oe-core continue to
>> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
>> recipes move to a standalone layer" with various implied questions:
>>
>> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
>> - Should there be v2 recipes for every recipe that has moved to v3, or only
>> (as is now) the "more-core" recipes (currently YP tests that core-image-base
>> builds without GPLv3, nothing else more complicated)
>> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
>> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
>> have), what makes oe-core special?
>>
>> I'm torn, Richard is torn.  Neither of those are useful to forming a
>> decision.  Does anyone else have any *useful* feedback?
> 
> I think it is a matter of resource usage.
> 
> Up to now, the GPLv2 maintenance has not been so hard and thus I would
> say for us to stay as is for now. We should revisit this for every
> release and review if it is time for split it or not.
> 

This would be a good time to remind us who the audience is for the gplv2
recipes so we understand the amount of manpower behind their maintenance.

My concern keeping then in core is that the commnunity who uses them
will reduce over time and they will bitrot. If that happens, we should
create a layer for them and remove them from core.

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

[OE-core] [PATCH] archiver.bbclass: Run after do_unpack

[Clemens Lang]

In recipes that are exempt from source code archiving due to
COPYLEFT_LICENSE_EXCLUDE, do_deploy_archives does not have a transitive
dependency on do_unpack. Given enough parallelism, this means
do_deploy_archives can run at the same time or before do_unpack.

Because do_deploy_archives does not specify a working directory, its
working directory is ${B}, which defaults to ${S}, which may be set by
a recipe to a directory that is created by do_unpack.

In this case, do_deploy_archives fails because it cannot change into the
non-existent directory. Avoid this problem by always running
do_deploy_archives after do_unpack.

Signed-off-by: Clemens Lang 
---
 meta/classes/archiver.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index d908d16..407e538 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -373,7 +373,7 @@ addtask do_ar_patched after do_unpack_and_patch
 addtask do_ar_configured after do_unpack_and_patch
 addtask do_dumpdata
 addtask do_ar_recipe
-addtask do_deploy_archives before do_build
+addtask do_deploy_archives after do_unpack before do_build
 
 addtask do_deploy_all_archives after do_deploy_archives
 do_deploy_all_archives[recrdeptask] = "do_deploy_archives"
-- 
2.1.0

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

[OE-core] Avoid race condition between do_unpack and do_deploy_archives in archiver.bbclass

[Clemens Lang]

Hi,

the following patch fixes a race condition in archiver.bbclass that can
occur when a very specific set of preconditions is fulfilled:
 - a recipe sets $S to a directory that will be created by do_unpack
 - $B is at its default value of $S
 - the license of the recipe is in COPYLEFT_LICENSE_EXCLUDE, skipping
   source code archiving
When this happens, do_deploy_archives (which is a no-op task that only
prints a single line) does not depend indirectly on do_unpack, as it
would usually do via a dependency on
  do_ar_${@d.getVarFlag('ARCHIVER_MODE', 'src', True)}.
Because do_deploy_archives does not specify a working directory, it
defaults to $B, which does not exist when do_deploy_archives is run in
parallel (or before) do_unpack.

The attached patch fixes this by making do_deploy_archives run after
do_unpack in all cases (which is already does for recipes not excluded
due their license).

This problem is also present on dizzy (and thus probably also on fido).

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

Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Anders Darander]

* Mark Hatle  [150812 16:50]:

> On 8/11/15 3:36 PM, Burton, Ross wrote:

> > Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
> > someone on this list asks what Poky is, 99% of the time they're trolling.  
> > :)

> > The original and unanswered question was "should oe-core continue to 
> > maintain
> > GPLv2 recipes where upstream has moved to GPLv3 or should those recipes 
> > move to
> > a standalone layer" with various implied questions:

> > - If the v2 recipes move to a separate layer, who own/maintains/tests it?
> > - Should there be v2 recipes for every recipe that has moved to v3, or only 
> > (as
> > is now) the "more-core" recipes (currently YP tests that core-image-base 
> > builds
> > without GPLv3, nothing else more complicated)
> > - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If 
> > other
> > layers decide to hold both v3 and v2 recipes (not that I'm aware any have), 
> > what
> > makes oe-core special?

> > I'm torn, Richard is torn.  Neither of those are useful to forming a 
> > decision. 
> > Does anyone else have any *useful* feedback?

> Not sure how useful, but I can give what I remember as the history behind the
> GPLv2 work and my opinion as someone who has a lot of customers who don't want
> GPLv3 software on the target.

I'm basically agreeing with Mark, as quite often, customers want a
non-GPLv3 image (and this is one of the strong selling points during
training sessions on OpenEmbedded / Yocto Project, that we have the
INCOMPATIBLE_LICENSE option). And having that option, and testing it,
requires that we have at least enough for a core-image-minimal to be
built and deployed.

I'm also using non-GPLv3 builds internally, for the same reasons...

>From reading earlier discussions, when recipe updates are proposed,
which replaces GPLv2-versions with GPLv3-versions, there usually are a
few people complaining (if they notice the change).

> Originally when this work was proposed (keeping older GPLv2 software in 
> oe-core)
> the decision was made to keep a small core set of components.  Things that the
> system wouldn't work without.  I.e. coreutils, util-linux, gettext, etc..  I
> believe the bar was set just above core-image-minimal.

> Anything more then a small (busybox or discrete component) filesystem can
> require GPLv3 and at that point it's up to others to figure out how they want 
> to
> deal with it.

> So based on the original theory here, parted (GPLv2) is right on the edge of
> small system or not.  It wasn't originally included because were were not
> considering (embedded) systems that would have to be partition at runtime.  (I
> did much of the original scoping for GPLv2 components... so at least that is 
> why
> I left it off the list.)

> (opinion part) That however doesn't mean we have to just reject this as being
> out of scope, but I think it does push this more toward the "not part of
> oe-core" side of things.

Sure, we need to revise that "core" part, and which of the components
are required in order to really state that we can support non-GPLv3
builds. Both as SW migrates from GPLv2 -> GPLv3, but also as HW and
system changes, as that might make new applications "really core".

> As someone who has a lot of customers that need non-GPLv2 components for 
> various
> reasons, I would like an ecosystem for components above and beyond what is
> allowed into oe-core for contributed things like this older version of parted,
> but not concern is bit-rot.  If it's in oe-core, it's (generally) being used 
> and
> tested and we get discussions like this... if it's shifted off into another
> layer, that layer needs a maintainer or it's going to fall away.

Yep, it's that part, the testing of non-GPLv3 builds that's so
attrictive to a lot of potential new-comers.

> So I honestly don't want to move any of the existing GPLv2 items out of 
> oe-core
> at this time.. possibly someday, but not now.  

I have to agree with Mark here; the GPLv2 components in oe-core should
really stay in core at this time. (And for quite some time)

> Additional (old) GPLv2 versions
> really should be able to go somewhere and be shared, but I don't have a good
> idea as to "where".  This is an opportunity for a new layer to focus on
> non-oe-core GPLv2 or possibly a layer as part of meta-openembedded.  (I'm not
> sure though Martin wants to take on that, even if it turns out to be minimal
> additional work.)

Sure, a meta-legacy or meta-gplv2 layer for the rest of non-core
applications and libraries would likely be a good idea. The main
question is as always, can we get enough to help maintain that stuff.

> (rant part)
> In the end for people who can't use GPLv3 for whatever reason, there really
> should be a coordinated effort to either update old versions of software 
> (GPLv2)
> or simply replace the items with BSD/MIT or other appropriately sourced and
> licensed code.  I just don't see much coordination beyond oe-core (and the 
> Yocto
>

Re: [OE-core] [PATCH 1/1][RFC] devtool: Upgrade feature

[Paul Eggleton]

Hi Leo,

On Tuesday 11 August 2015 14:04:14 leonardo.sandoval.gonza...@linux.intel.com 
wrote:
> This is a new devtool's feature, which upgrades a recipe to a
> particular version number. Code was taken from [1] where some modifications
> were done (remove all email, buildhistory and statistics features,
> use devtool logger instead of AUH logger) to adapt the devtool framework.
> Once the upgrade is over, the new recipe will be located under the
> devtool's workspace. This is a first approach to this feature; pending
> tasks include:
> 
> 1. The AUH [1] is used to rename and update the recipe. AUH is not
> using the lib/oe/recipeutils library to do this work. AUH ported code should
> use this library which is the one being used by the rest of the devtool
> features.
>
> 2. Currently, when 'update-recipe' is executed, the recipe under workspace
> is updated with latest commits. The only task missing is to replace the new
> recipe with the old one, commonly located under the meta layer.
>
> 3. When patches fail to apply, follow the PATCHRESOLVE behavior instead of
> just failing.
> 
> 4. Patches most of the time do not apply correctly on the new recipe
> version, so include a command line option to indicate the system not to
> apply these, so it can be applied manually later on.

So, this is a good first implementation and gives an idea of how the command 
will work - and I'm quite keen for us to have this, I've had several people 
asking me recently about when we'll be adding it, so it's definitely something 
we want.

However, I'm concerned about the volume of code we're adding here, some of 
which duplicates what we already have in devtool or elsewhere in lib/oe. I 
know this is the easiest approach and you've noted it's todo item #1 above to 
work on - I'll be a lot happier if you can improve that before the final 
version.

In particular, I see the upgrade() function is duplicating a bunch of code 
from modify() - we should split the common parts out to separate function(s) 
that can be called from both places instead.

Some other comments:

* I can see it's actually making changes to the original recipe - I found this 
because I'd run a devtool upgrade on dropbear and specified the wrong version 
to --version Ctrl+C'd out during the fetch part, and the original dropbear.inc 
was modified instead of the one in the workspace. We don't want to touch the 
original recipe, not until you run update-recipe at least.

* As far as the source tree is concerned I think that this is doing things 
slightly backwards - it's using the AUH code to do the upgrade, and then it's 
extracting the code. What I'd like to see happen is it extract the code for 
the old version (including applying patches), use the AUH code to figure out 
how to fetch the new version, fetch it into a different branch (assuming it's 
not already there since it was fetched from git), then rebase the patches onto 
the new version - the user can then use git to fix things up if patches don't 
apply.

* I'm not sure if using an existing source tree is a reasonable default for 
this command - I'm not even sure it's something people will want to do at all 
in the context of an upgrade. I'm willing to be convinced otherwise though - 
any opinions (from anyone)?

* We need oe-selftest tests for this that test as much of the functionality as 
possible. This may require adding some simple "synthetic" recipes to meta-
selftest so that we have something that's always there to upgrade. Based upon 
my recent experience in devtool (with my own code), the sooner we add these 
the better.

* I'd like to see the implementation for this in its own file rather than in 
standard.py.

* Probably just a result of this being WIP, but I found that if I don't 
specify a version with --version then it says "NOTE: Upgrading to None" and 
then fails with "ERROR: cannot concatenate 'str' and 'NoneType' objects".

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] Avoid race condition between do_unpack and do_deploy_archives in archiver.bbclass

[Burton, Ross]

On 13 August 2015 at 10:09, Clemens Lang  wrote:

> Because do_deploy_archives does not specify a working directory, it
> defaults to $B, which does not exist when do_deploy_archives is run in
> parallel (or before) do_unpack.
>

I'm not sure I follow this.  Functions are executed using exec_func() will
create and cd to the default directory, so if that is ${B} then exec_func
will create ${B} before executing the function.

(I've a branch - ross/dirs - to remove this undesired OE-specific knowledge
in BitBake)

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

[OE-core] [PATCH] libpfm4: Fix GNU_HASH warning.

[Noor, Ahsan]

From: Noor 

* Add a patch which updated add LDFLAGS variable to SLDFLAGS
  in Makefile.

Signed-off-by: Noor Ahsan 
---
 ...Makefile-Add-LDFLAGS-variable-to-SLDFLAGS.patch |   31 
 meta/recipes-kernel/libpfm/libpfm4_4.6.0.bb|4 ++-
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git 
a/meta/recipes-kernel/libpfm/files/0001-Makefile-Add-LDFLAGS-variable-to-SLDFLAGS.patch
 
b/meta/recipes-kernel/libpfm/files/0001-Makefile-Add-LDFLAGS-variable-to-SLDFLAGS.patch
new file mode 100644
index 000..be58706
--- /dev/null
+++ 
b/meta/recipes-kernel/libpfm/files/0001-Makefile-Add-LDFLAGS-variable-to-SLDFLAGS.patch
@@ -0,0 +1,31 @@
+From 272a8a069a8f5f06a1e5dfa0ef12f5f92984728b Mon Sep 17 00:00:00 2001
+From: Noor 
+Date: Wed, 12 Aug 2015 20:54:00 +0500
+Subject: [PATCH] Makefile: Add LDFLAGS variable to SLDFLAGS.
+
+* Add LDFLAGS variable to SLDFLAGS so that extra linker
+  flags can be sent via this variable.
+
+Upstream status Sumbitted [perfmon2-libpfm4-comm...@lists.sourceforge.net]
+
+Signed-off-by: Noor Ahsan 
+---
+ lib/Makefile |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/Makefile b/lib/Makefile
+index 1cc8765..4bd92ef 100644
+--- a/lib/Makefile
 b/lib/Makefile
+@@ -187,7 +187,7 @@ CFLAGS += -DCONFIG_PFMLIB_CELL
+ endif
+ 
+ ifeq ($(SYS),Linux)
+-SLDFLAGS=-shared -Wl,-soname -Wl,$(VLIBPFM)
++SLDFLAGS=$(LDFLAGS) -shared -Wl,-soname -Wl,$(VLIBPFM)
+ SLIBPFM=libpfm.so.$(VERSION).$(REVISION).$(AGE)
+ VLIBPFM=libpfm.so.$(VERSION)
+ SOLIBEXT=so
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-kernel/libpfm/libpfm4_4.6.0.bb 
b/meta/recipes-kernel/libpfm/libpfm4_4.6.0.bb
index b66fbd1..2dfda90 100644
--- a/meta/recipes-kernel/libpfm/libpfm4_4.6.0.bb
+++ b/meta/recipes-kernel/libpfm/libpfm4_4.6.0.bb
@@ -12,7 +12,9 @@ SECTION = "devel"
 
 COMPATIBLE_HOST = "powerpc64"
 
-SRC_URI = 
"http://downloads.sourceforge.net/project/perfmon2/${BPN}/libpfm-${PV}.tar.gz";
+SRC_URI = 
"http://downloads.sourceforge.net/project/perfmon2/${BPN}/libpfm-${PV}.tar.gz \
+   file://0001-Makefile-Add-LDFLAGS-variable-to-SLDFLAGS.patch \
+  "
 
 SRC_URI[md5sum] = "5077b9022440e4951d96f2d0e73bd487"
 SRC_URI[sha256sum] = 
"5ab1e5b0472550f9037a8800834f6bc3b927690070f69fac0b67284b4b05fd5f"
-- 
1.7.9.5

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

[OE-core] gnutls/nettle/gmp licensing and versions

[Jussi Kukkonen]

On 12 August 2015 at 17:14, Jussi Kukkonen  wrote:
> Hi,
>
> I realise I'm a bit late (with the commit in master already) but I'm
> looking at upgrading this recipe and had some questions on this patch
> and the recipe in general.
>
> On 9 August 2015 at 08:28, Armin Kuster  wrote:
>> adding the license definitions on the few packages that
>> deviate from the overall package license.
>>
>> based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
>> and spot checking files.
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb 
>> b/meta/recipes-support/nettle/nettle_2.7.1.bb
>> index f53afcc..f9d331f 100644
>> --- a/meta/recipes-support/nettle/nettle_2.7.1.bb
>> +++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
>> @@ -2,6 +2,15 @@ SUMMARY = "A low level cryptographic library"
>>  HOMEPAGE = "http://www.lysator.liu.se/~nisse/nettle/";
>>  SECTION = "libs"
>>  LICENSE = "LGPLv2.1 & GPLv2"
>
> I think this is wrong, whichever version you look at -- our current
> version is just "LGPLv2.1+", the current upstream release is "LGPLv3+
> | GPLv2+"
>
> I'm going to send a patch upgrading the recipe to the current upstream
> release (and setting license to "LGPLv3+ | GPLv2+"): it might seem
> like this makes gnutls effectively LGPLv3 but that actually happened
> last year with the gmp upgrade. Comments on this welcome.

Alexander just pointed out to me that there was a discussion on gnutls
and nettle already in July (which I missed in my
back-from-holiday-email-binge). It seems that the consensus was to
preserve LGPLv2 versions.

This is what the current situation looks to me -- please correct if I'm wrong:
* gmp is "GPLv2+ | LGPLv3+"
* nettle is "LGPLv2.1+" but depends on gmp
* gnutls "LGPLv2.1+" but depends on nettle

This effectively makes gnutls "GPLv2+ | LGPLv3+" as far as I can see.
If we want to preserve a LGPLv2 gnutls, we need to bring back an older
version of gmp (I think 4.2.1).


>> +LICENSE_${PN}-cast = "CC0"
>> +LICENSE_${PN}-gosthash = "MIT"
>> +
>> +# both public and GPL license listed
>> +LICENSE_${PN}-md2 = "CC0 & LGPLv2.1+"
>> +LICENSE_${PN}-md4 = "CC0 & LGPLv2.1+"
>
> From the reference I had the impression this "LICENSE_something"
> construct would imply there is a package "something". But the nettle
> recipe does not produce "nettle-cast" or any of these. What is the
> purpose here?
>
> Thanks,
>  Jussi
>
>> +
>> +
>>  LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 
>> \
>>  
>> file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
>>  \
>>  
>> file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d"
>> --
>> 2.3.5
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] screen update, take two

[Jussi Kukkonen]

I'm resending only the screen patch as the others are in already.

Changes since v1:
* remove the old GPLv2 version

I'm not taking any stance on tmux vs screen debate: we can still
change to tmux. Just wanted to get rid of some very old and
potentially bit rotted code.

Jussi

The following changes since commit a533776d6ff83b6e3e830137455b8382d002768b:

  perf: fix build breakage on kernels after 4.1 (2015-08-12 11:31:49 -0700)

are available in the git repository at:

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

Jussi Kukkonen (1):
  screen: Upgrade 4.0.3 -> 4.3.1

 .../screen/screen-4.0.3/configure.patch| 979 -
 .../screen-4.0.3/screen-4.0.2-CVE-2009-1215.patch  |  27 -
 .../screen-4.0.3/screen-4.0.3-CVE-2009-1214.patch  |  86 --
 .../Avoid-mis-identifying-systems-as-SVR4.patch|  57 ++
 ...cross-compile-alternatives-for-AC_TRY_RUN.patch | 137 +++
 .../Remove-redundant-compiler-sanity-checks.patch  |  65 ++
 ...t-file-system-checks-when-cross-compiling.patch | 135 +++
 .../fix-parallel-make.patch|   0
 .../screen/{screen-4.0.3 => screen}/screen.pam |   0
 .../screen/{screen_4.0.3.bb => screen_4.3.1.bb}|  34 +-
 10 files changed, 408 insertions(+), 1112 deletions(-)
 delete mode 100644 meta/recipes-extended/screen/screen-4.0.3/configure.patch
 delete mode 100644 
meta/recipes-extended/screen/screen-4.0.3/screen-4.0.2-CVE-2009-1215.patch
 delete mode 100644 
meta/recipes-extended/screen/screen-4.0.3/screen-4.0.3-CVE-2009-1214.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Avoid-mis-identifying-systems-as-SVR4.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Provide-cross-compile-alternatives-for-AC_TRY_RUN.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Remove-redundant-compiler-sanity-checks.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Skip-host-file-system-checks-when-cross-compiling.patch
 rename meta/recipes-extended/screen/{screen-4.0.3 => 
screen}/fix-parallel-make.patch (100%)
 rename meta/recipes-extended/screen/{screen-4.0.3 => screen}/screen.pam (100%)
 rename meta/recipes-extended/screen/{screen_4.0.3.bb => screen_4.3.1.bb} (58%)

-- 
2.1.4

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

[OE-core] [PATCHv2 1/1] screen: Upgrade 4.0.3 -> 4.3.1

[Jussi Kukkonen]

* License is now GPLv3+
* Remove patches that are already in upstream or not applicable
  anymore
* Add a patchset to enable cross-compiling 4.3.1 (modified from
  http://savannah.gnu.org/bugs/?43223)

Signed-off-by: Jussi Kukkonen 
---
 .../screen/screen-4.0.3/configure.patch| 979 -
 .../screen-4.0.3/screen-4.0.2-CVE-2009-1215.patch  |  27 -
 .../screen-4.0.3/screen-4.0.3-CVE-2009-1214.patch  |  86 --
 .../Avoid-mis-identifying-systems-as-SVR4.patch|  57 ++
 ...cross-compile-alternatives-for-AC_TRY_RUN.patch | 137 +++
 .../Remove-redundant-compiler-sanity-checks.patch  |  65 ++
 ...t-file-system-checks-when-cross-compiling.patch | 135 +++
 .../fix-parallel-make.patch|   0
 .../screen/{screen-4.0.3 => screen}/screen.pam |   0
 .../screen/{screen_4.0.3.bb => screen_4.3.1.bb}|  34 +-
 10 files changed, 408 insertions(+), 1112 deletions(-)
 delete mode 100644 meta/recipes-extended/screen/screen-4.0.3/configure.patch
 delete mode 100644 
meta/recipes-extended/screen/screen-4.0.3/screen-4.0.2-CVE-2009-1215.patch
 delete mode 100644 
meta/recipes-extended/screen/screen-4.0.3/screen-4.0.3-CVE-2009-1214.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Avoid-mis-identifying-systems-as-SVR4.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Provide-cross-compile-alternatives-for-AC_TRY_RUN.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Remove-redundant-compiler-sanity-checks.patch
 create mode 100644 
meta/recipes-extended/screen/screen/Skip-host-file-system-checks-when-cross-compiling.patch
 rename meta/recipes-extended/screen/{screen-4.0.3 => 
screen}/fix-parallel-make.patch (100%)
 rename meta/recipes-extended/screen/{screen-4.0.3 => screen}/screen.pam (100%)
 rename meta/recipes-extended/screen/{screen_4.0.3.bb => screen_4.3.1.bb} (58%)

diff --git a/meta/recipes-extended/screen/screen-4.0.3/configure.patch 
b/meta/recipes-extended/screen/screen-4.0.3/configure.patch
deleted file mode 100644
index e29bcc6..000
--- a/meta/recipes-extended/screen/screen-4.0.3/configure.patch
+++ /dev/null
@@ -1,979 +0,0 @@
-Upstream-Status: Inappropriate [embedded specific]
-
-# The patch is borrowed from OE:
-# 
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=4ee790cc6974bdfe1c9b06c0567b1c56f56d6615
-# and was rebased to screen-4.0.3's configure.in
-# by Dexuan Cui (dexuan@intel.com).
-#
-# The description of the original patch is:
-#
-# Patch by Hannes Reich (han...@skynet.ie) 22-Jul-2005
-# Resolves _some_ of the cross-compilation issues in screen's configure.in
-#
-diff --git a/configure.in b/configure.in
-index 34c9372..d5ed48a 100644
 a/configure.in
-+++ b/configure.in
-@@ -37,6 +37,325 @@ pat=`sed < ${srcdir}/patchlevel.h -n -e '/#define 
PATCHLEVEL/s/#define PATCHLEVE
- VERSION="$rev.$vers.$pat"
- AC_NOTE(this is screen version $VERSION)
- AC_SUBST(VERSION)
-+
-+AH_TOP([
-+/* Copyright (c) 1993-2000
-+ *  Juergen Weigert (jnwei...@immd4.informatik.uni-erlangen.de)
-+ *  Michael Schroeder (mlsch...@immd4.informatik.uni-erlangen.de)
-+ * Copyright (c) 1987 Oliver Laumann
-+ *
-+ * This program is free software; you can redistribute it and/or modify
-+ * it under the terms of the GNU General Public License as published by
-+ * the Free Software Foundation; either version 2, or (at your option)
-+ * any later version.
-+ *
-+ * This program is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+ * GNU General Public License for more details.
-+ *
-+ * You should have received a copy of the GNU General Public License
-+ * along with this program (see the file COPYING); if not, write to the
-+ * Free Software Foundation, Inc.,
-+ * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA
-+ *
-+ */
-+
-+
-+/**
-+ *
-+ *User Configuration Section
-+ */
-+
-+/*
-+ * Maximum of simultaneously allowed windows per screen session.
-+ */
-+#ifndef MAXWIN
-+# define MAXWIN 40
-+#endif
-+
-+/*
-+ * Define SOCKDIR to be the directory to contain the named sockets
-+ * screen creates. This should be in a common subdirectory, such as
-+ * /usr/local or /tmp. It makes things a little more secure if you
-+ * choose a directory which is not writable by everyone or where the
-+ * "sticky" bit is on, but this isn't required.
-+ * If SOCKDIR is not defined screen will put the named sockets in
-+ * the user's home directory. Notice that this can cause you problems
-+ * if some user's HOME directories are AFS- or NFS-mounted. Especially
-+ * AFS is unlikely to support named sockets.
-+ *
-+ * Screen will name the subdirectories "S-$USER" (e.g /tmp/S-davison).
-+ */
-+#undef SOCKDIR
-+
-+/*
-+ * Define this if the SOCKDIR is not shared between hosts.
-+ */
-+#define SOCKDIR_IS_LOCAL_TO_HOST
-+
-+/*
-+ * Scre

[OE-core] [PATCHv2 3/4] nfs-utils: Upgrade 1.3.1 -> 1.3.2

[Jussi Kukkonen]

Add PACKAGECONFIG[ipv6] that is enabled based on ipv6 distro feature.

Signed-off-by: Jussi Kukkonen 
---

Changes since v1:
* Add PACKAGECONFIG[ipv6] as Khem suggested

I also modified and force pushed the branch at:
  git://git.yoctoproject.org/poky-contrib jku/nss-openssh-nfsutils
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/nss-openssh-nfsutils


 .../nfs-utils/{nfs-utils_1.3.1.bb => nfs-utils_1.3.2.bb}   | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)
 rename meta/recipes-connectivity/nfs-utils/{nfs-utils_1.3.1.bb => 
nfs-utils_1.3.2.bb} (92%)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
similarity index 92%
rename from meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
rename to meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
index 6da8509..0953850 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
@@ -33,8 +33,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://nfs-utils-debianize-start-statd.patch \
 "
 
-SRC_URI[md5sum] = "8de676b9ff34b8f9addc1d0800fabdf8"
-SRC_URI[sha256sum] = 
"ff79d70b7b58b2c8f9b798c58721127e82bb96022adc04a5c4cb251630e696b8"
+SRC_URI[md5sum] = "4cdffb2c7f7fd2bdceaba55ab1b881da"
+SRC_URI[sha256sum] = 
"2966bb431c06e9ba35a54f48f89db03a5132bc2d8ed8084ac8ccb34e25a9b739"
 
 # Only kernel-module-nfsd is required here (but can be built-in)  - the nfsd 
module will
 # pull in the remainder of the dependencies.
@@ -58,14 +58,16 @@ EXTRA_OECONF = "--with-statduser=rpcuser \
 --disable-nfsv41 \
 --enable-uuid \
 --disable-gss \
---disable-tirpc \
 --disable-nfsdcltrack \
 --with-statdpath=/var/lib/nfs/statd \
"
 
-PACKAGECONFIG ??= "tcp-wrappers"
+PACKAGECONFIG ??= "tcp-wrappers \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', 'ipv6', '', 
d)} \
+   "
 PACKAGECONFIG[tcp-wrappers] = 
"--with-tcp-wrappers,--without-tcp-wrappers,tcp-wrappers"
 PACKAGECONFIG[nfsidmap] = "--enable-nfsidmap,--disable-nfsidmap,keyutils"
+PACKAGECONFIG[ipv6] = "--enable-ipv6 --enable-tirpc,--disable-ipv6 
--disable-tirpc,libtirpc"
 
 INHIBIT_AUTO_STAGE = "1"
 
-- 
2.1.4

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

Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Mark Hatle]

On 8/13/15 3:42 AM, Philip Balister wrote:
> On 08/11/2015 10:46 PM, Otavio Salvador wrote:
>> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross  wrote:
>>>
>>> On 11 August 2015 at 16:46, Khem Raj  wrote:

 can we freeze this thread please.
>>>
>>>
>>> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
>>> someone on this list asks what Poky is, 99% of the time they're trolling.
>>> :)
>>>
>>> The original and unanswered question was "should oe-core continue to
>>> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
>>> recipes move to a standalone layer" with various implied questions:
>>>
>>> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
>>> - Should there be v2 recipes for every recipe that has moved to v3, or only
>>> (as is now) the "more-core" recipes (currently YP tests that core-image-base
>>> builds without GPLv3, nothing else more complicated)
>>> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
>>> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
>>> have), what makes oe-core special?
>>>
>>> I'm torn, Richard is torn.  Neither of those are useful to forming a
>>> decision.  Does anyone else have any *useful* feedback?
>>
>> I think it is a matter of resource usage.
>>
>> Up to now, the GPLv2 maintenance has not been so hard and thus I would
>> say for us to stay as is for now. We should revisit this for every
>> release and review if it is time for split it or not.
>>
> 
> This would be a good time to remind us who the audience is for the gplv2
> recipes so we understand the amount of manpower behind their maintenance.

I can only speak for the customers I know of directly.  They are:

* People whose lawyers tell them they can't use GPLv3, for no other reason that
FUD.  (This is diminishing.)

The follow are all around the 'TiVo-ization clause' concerns...

* People in the medical space
  - Some devices if modified have serious safety concerns.  So they want to be
able to lock down the device and must due so to get things like FDA 
certification.

* People in the automotive space (IVI, etc)
  - In some countries if a user modifies the device, due to the automaker
permitting modifications, the automake suddenly becomes liable for the users
changes.  This is a pretty nasty catch in their laws.  So the automakes want the
ability again to lock down the device to prevent liability issues, as well as
for potential safety concerns.

* Aeronautics
  - I've only talked to a few people on this, so I don't know if it is accurate
or not.. but again the issue is for FAA certification and similar they can't
permit changes to various flight systems.  If they permit a user to modify the
device it may fail FAA certification.

* Consumer Electronics
  - Some devices may be built in such a way that the designer does not want to
permit the user from modifying the device.  This is generally around things like
DRM, or devices that have physical components (like tape control) that can be
damaged due to improper control.

  - DRM if implemented in software can be a concern simply due to contractural
issues..

  - Physical device issues are all about warranty concerns.  (Personally I think
it's a red herring, but I've heard the concern on a number of devices from a few
large manufacturers.)

> My concern keeping then in core is that the commnunity who uses them
> will reduce over time and they will bitrot. If that happens, we should
> create a layer for them and remove them from core.

I think GPLv2 is a limited set of the community, but I also think that it's an
important set.  It removes some of the traditional embedded Linux concerns from
various markets.  As for bitrot, for the existing components, I don't see this
as a concern for the next few years at least.  There is still a health
(commercial) community using these components regularly, and worst case fixes
are being developed and sent back to the community via OSVs and integrators.

--Mark

> Philip
> 

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

Re: [OE-core] [meta-ti] Valgrind doesn't give stack trace

[Khem Raj]

> On Aug 13, 2015, at 2:36 AM, Anders Darander  wrote:
> 
> * Ankur Tyagi  [150813 06:26]:
>> I am using Valgrind coming from yocto on my AM335x-EVM kit.
> 
>> But when I try to use valgrind, it doesn't give me stack trace. Following
>> is what I get :
> 
> See my reply on meta-arago:
> http://arago-project.org/pipermail/meta-arago/2015-August/006016.html
> 

You need just symbols not complete debug info. Adding
INHIBIT_PACKAGE_STRIP = “1” to valgrind recipe  should take care of this.

> Cheers,
> Anders
> 
> --
> Anders Darander
> ChargeStorm AB / eStorm AB
> --
> ___
> meta-ti mailing list
> meta...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: package nscd related files

[Khem Raj]

> On Aug 13, 2015, at 1:09 AM, rongqing...@windriver.com wrote:
> 
> From: Roy Li 
> 
> install nscd related configuration file, startup files, and package them,
> make nscd easy to startup
> 

please test this change on top of glibc 2.22 recipe upgrade patches which are 
in flight right now

> Signed-off-by: Roy Li 
> ---
> meta/recipes-core/glibc/glibc-package.inc | 37 ++-
> meta/recipes-core/glibc/glibc.inc |  2 +-
> 2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/glibc/glibc-package.inc 
> b/meta/recipes-core/glibc/glibc-package.inc
> index 8ea5915..5f7c8a9 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -49,7 +49,8 @@ FILES_libsotruss = "${libdir}/audit/sotruss-lib.so"
> FILES_SOLIBSDEV = "${libdir}/lib*${SOLIBSDEV}"
> FILES_${PN}-dev += "${bindir}/rpcgen ${libdir}/*_nonshared.a 
> ${base_libdir}/*_nonshared.a ${base_libdir}/*.o ${datadir}/aclocal"
> FILES_${PN}-staticdev += "${libdir}/*.a ${base_libdir}/*.a"
> -FILES_nscd = "${sbindir}/nscd*"
> +FILES_nscd = "${sbindir}/nscd* ${sysconfdir}/init.d/nscd 
> ${systemd_unitdir}/system/nscd* ${sysconfdir}/tmpfiles.d/nscd.conf \
> +  ${sysconfdir}/nscd.conf 
> ${sysconfdir}/default/volatiles/98_nscd ${localstatedir}/db/nscd"
> FILES_${PN}-mtrace = "${bindir}/mtrace"
> FILES_tzcode = "${bindir}/tzselect ${sbindir}/zic ${sbindir}/zdump"
> FILES_${PN}-utils = "${bindir}/* ${sbindir}/*"
> @@ -105,6 +106,29 @@ do_install_append () {
>   rmdir ${D}${sysconfdir}
>   fi
>   fi
> +
> + if echo ${PN}|grep -q "glibc-initial"; then
> + return
> + fi
> +
> + install -d ${D}${sysconfdir}/init.d
> + install -d ${D}${localstatedir}/db/nscd
> + install -m 0755 ${S}/nscd/nscd.init ${D}${sysconfdir}/init.d/nscd
> + install -m 0755 ${S}/nscd/nscd.conf ${D}${sysconfdir}/nscd.conf
> + sed -i "s%daemon%start-stop-daemon --start --exec%g" 
> ${D}${sysconfdir}/init.d/nscd
> +
> + install -d ${D}${systemd_unitdir}/system
> + install -m 0644 ${S}/nscd/nscd.service ${D}${systemd_unitdir}/system/
> +
> + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
> d)}; then
> + install -d ${D}${sysconfdir}/tmpfiles.d
> + echo "d /run/nscd 755 root root -" \
> + > ${D}${sysconfdir}/tmpfiles.d/nscd.conf
> + else
> + install -d ${D}${sysconfdir}/default/volatiles
> + echo "d root root 0755 /var/run/nscd none" \
> + > ${D}${sysconfdir}/default/volatiles/98_nscd
> + fi
> }
> 
> do_install_append_aarch64 () {
> @@ -174,3 +198,14 @@ glibc_package_preprocess () {
>   rm -rf ${PKGD}${exec_prefix}/lib
>   fi
> }
> +
> +pkg_postinst_nscd () {
> + if [ -z "$D" ]; then
> + if command -v systemd-tmpfiles >/dev/null; then
> + systemd-tmpfiles --create 
> ${sysconfdir}/tmpfiles.d/nscd.conf
> + elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
> + ${sysconfdir}/init.d/populate-volatile.sh update
> + fi
> + fi
> +}
> +CONFFILES_nscd="${sysconfdir}/nscd.conf"
> diff --git a/meta/recipes-core/glibc/glibc.inc 
> b/meta/recipes-core/glibc/glibc.inc
> index 74ad0b5..03ffb2f 100644
> --- a/meta/recipes-core/glibc/glibc.inc
> +++ b/meta/recipes-core/glibc/glibc.inc
> @@ -41,7 +41,7 @@ DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial 
> libgcc-initial linux-libc-headers
> #RDEPENDS_${PN} += "${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}"
> PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc"
> PROVIDES += "virtual/libintl virtual/libiconv"
> -inherit autotools texinfo distro_features_check
> +inherit autotools texinfo distro_features_check systemd
> require glibc-options.inc
> 
> # The main purpose of setting this variable is to prevent users from 
> accidently
> --
> 1.9.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] Check non-ASCII characters on recipe metadata

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

* First patch creates a QA check on insane.bbclass
* Second patch handles a string encode exception, reported on [1]

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6693

The following changes since commit 0f7df92e3d2dbbb4c94299171d5d0287887e0d28:

  clutter-gst: update to 3.0.8 (2015-08-11 09:28:52 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib 
lsandov1/package_deb-handle-non-ascii-6693
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/package_deb-handle-non-ascii-6693

Leonardo Sandoval (2):
  insane.bbclass: Check non-ASCII characters on metadata
  package_deb.bbclass: Handle exception when encoding non-ASCII
characters

 meta/classes/insane.bbclass  | 24 +++-
 meta/classes/package_deb.bbclass |  4 
 2 files changed, 27 insertions(+), 1 deletion(-)

-- 
1.8.4.5

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

[OE-core] [PATCH 2/2] package_deb.bbclass: Handle exception when encoding non-ASCII characters

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

On package creation, handle exception when encoding non-ASCII characteres.

[YOCTO #6693]

Signed-off-by: Leonardo Sandoval 
---
 meta/classes/package_deb.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 9e1ed28..374adb6 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -171,6 +171,10 @@ python do_package_deb () {
 bb.utils.unlockfile(lf)
 ctrlfile.close()
 raise bb.build.FuncFailed("Missing field for deb generation: %s" % 
value)
+except UnicodeDecodeError:
+bb.utils.unlockfile(lf)
+ctrlfile.close()
+raise bb.build.FuncFailed("Non-ASCII characters found in one of 
the fields")
 # more fields
 
 custom_fields_chunk = get_package_additional_metadata("deb", localdata)
-- 
1.8.4.5

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

[OE-core] [PATCH 1/2] insane.bbclass: Check non-ASCII characters on metadata

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

Check if non-ASCII characters are present on recipe's metadata. Fields
taken into account: 'DESCRIPTION', 'SUMMARY', 'LICENSE' and 'SECTION'.

Signed-off-by: Leonardo Sandoval 
---
 meta/classes/insane.bbclass | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 9c05c86..d560eed 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -11,6 +11,7 @@
 #  -Check if packages contains .debug directories or .so files
 #   where they should be in -dev or -dbg
 #  -Check if config.log contains traces to broken autoconf tests
+#  -Check non-ascii characters on some package metadata
 #  -Ensure that binaries in base_[bindir|sbindir|libdir] do not link
 #   into exec_prefix
 #  -Check that scripts in base_[bindir|sbindir|libdir] do not reference
@@ -36,7 +37,7 @@ WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir 
xorg-driver-abi \
 ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
 perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
 split-strip packages-list pkgv-undefined var-undefined \
-version-going-backwards expanded-d \
+version-going-backwards expanded-d non-ascii \
 "
 
 ALL_QA = "${WARN_QA} ${ERROR_QA}"
@@ -947,6 +948,24 @@ def package_qa_check_expanded_d(path,name,d,elf,messages):
 sane = False
 return sane
 
+def package_qa_check_ascii_encoding(keys, d):
+def check_ascii_encoding(key):
+sane = True
+value = d.getVar(key, True)
+if value:
+try:
+s = unicode(value)
+except UnicodeDecodeError as e:
+error_msg = "%s has non-ASCII characters" % key
+sane = False
+package_qa_handle_error("non-ascii", error_msg, d)
+return sane
+
+for key in keys:
+sane = check_ascii_encoding(key)
+if not sane:
+break
+
 # The PACKAGE FUNC to scan each package
 python do_package_qa () {
 import subprocess
@@ -956,6 +975,9 @@ python do_package_qa () {
 
 bb.build.exec_func("read_subpackage_metadata", d)
 
+# Check non-ascii characters on recipe's metadata
+package_qa_check_ascii_encoding(['DESCRIPTION', 'SUMMARY', 'LICENSE', 
'SECTION'], d)
+
 logdir = d.getVar('T', True)
 pkg = d.getVar('PN', True)
 
-- 
1.8.4.5

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

Re: [OE-core] [PATCH 1/1][RFC] devtool: Upgrade feature

[Leonardo Sandoval]

Hi Paul,

On 08/13/2015 05:06 AM, Paul Eggleton wrote:

Hi Leo,

On Tuesday 11 August 2015 14:04:14 leonardo.sandoval.gonza...@linux.intel.com
wrote:

This is a new devtool's feature, which upgrades a recipe to a
particular version number. Code was taken from [1] where some modifications
were done (remove all email, buildhistory and statistics features,
use devtool logger instead of AUH logger) to adapt the devtool framework.
Once the upgrade is over, the new recipe will be located under the
devtool's workspace. This is a first approach to this feature; pending
tasks include:

1. The AUH [1] is used to rename and update the recipe. AUH is not
using the lib/oe/recipeutils library to do this work. AUH ported code should
use this library which is the one being used by the rest of the devtool
features.

2. Currently, when 'update-recipe' is executed, the recipe under workspace
is updated with latest commits. The only task missing is to replace the new
recipe with the old one, commonly located under the meta layer.

3. When patches fail to apply, follow the PATCHRESOLVE behavior instead of
just failing.

4. Patches most of the time do not apply correctly on the new recipe
version, so include a command line option to indicate the system not to
apply these, so it can be applied manually later on.


So, this is a good first implementation and gives an idea of how the command
will work - and I'm quite keen for us to have this, I've had several people
asking me recently about when we'll be adding it, so it's definitely something
we want.

However, I'm concerned about the volume of code we're adding here, some of
which duplicates what we already have in devtool or elsewhere in lib/oe. I
know this is the easiest approach and you've noted it's todo item #1 above to
work on - I'll be a lot happier if you can improve that before the final
version.

In particular, I see the upgrade() function is duplicating a bunch of code
from modify() - we should split the common parts out to separate function(s)
that can be called from both places instead.


As you noticed, there is code duplication specially on the standard.py. 
Code on this file needs to be refactor somehow so the function upgrade 
can call these new functions.




Some other comments:

* I can see it's actually making changes to the original recipe - I found this
because I'd run a devtool upgrade on dropbear and specified the wrong version
to --version Ctrl+C'd out during the fetch part, and the original dropbear.inc
was modified instead of the one in the workspace. We don't want to touch the
original recipe, not until you run update-recipe at least.



Ok. This is definitely a bug. All work must be done in the workspace. 
This is contrary to the AUH code, which works on poky default layers, so 
this bug may be something I did not change on the ported code.



* As far as the source tree is concerned I think that this is doing things
slightly backwards - it's using the AUH code to do the upgrade, and then it's
extracting the code. What I'd like to see happen is it extract the code for
the old version (including applying patches), use the AUH code to figure out
how to fetch the new version, fetch it into a different branch (assuming it's
not already there since it was fetched from git), then rebase the patches onto
the new version - the user can then use git to fix things up if patches don't
apply.



got it. Looks good to me. I also though using the recipetool script 
(instead of AUH), but this one creates a recipe from scratch so it is 
not really useful at this moment.



* I'm not sure if using an existing source tree is a reasonable default for
this command - I'm not even sure it's something people will want to do at all
in the context of an upgrade. I'm willing to be convinced otherwise though -
any opinions (from anyone)?

* We need oe-selftest tests for this that test as much of the functionality as
possible. This may require adding some simple "synthetic" recipes to meta-
selftest so that we have something that's always there to upgrade. Based upon
my recent experience in devtool (with my own code), the sooner we add these
the better.


good point. I will add these on v2.



* I'd like to see the implementation for this in its own file rather than in
standard.py.


Good. What about the other features (add, update-recipe, modify, etc.)? 
will these remain in the same place?




* Probably just a result of this being WIP, but I found that if I don't
specify a version with --version then it says "NOTE: Upgrading to None" and
then fails with "ERROR: cannot concatenate 'str' and 'NoneType' objects".



Bug. I will also add it on V2.



Cheers,
Paul



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

Re: [OE-core] [scripts][PATCH] yocto-layer: Stops duplication of "meta-" prefix

[Ibarra Lopez, Humberto]

I didn’t see any more comments regarding this, are there any updates? I am not 
entirely sure about Ross’ question either.


From: Benjamin Esquivel [mailto:benjamin.esqui...@linux.intel.com]
Sent: Thursday, July 30, 2015 10:59 AM
To: Burton, Ross; Ibarra Lopez, Humberto
Cc: OE-core
Subject: Re: [OE-core] [scripts][PATCH] yocto-layer: Stops duplication of 
"meta-" prefix

On Thu, 2015-07-30 at 14:28 +0100, Burton, Ross wrote:

On 29 July 2015 at 20:50, 
mailto:humberto.ibarra.lo...@intel.com>> wrote:

The yocto-layer script puts an extra "meta-" prefix to the given layer
name even when the prefix is already there. This fix avoids
duplicating the prefix in these situations.


If the scripts expects the layer name to not have a meta- prefix, should it 
also strip a prefix if its present before passing it to yocto_layer_create()?
I'm failing to understand the question, I think the yocto_layer_create() is 
receiving a layer_output_dir argument with 'meta-' checked to not be 
duplicated.  The fix is right above the yocto_layer_create() call.
Ross

--

___

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] nettle: clean up license information

[akuster808]

On 08/12/2015 07:14 AM, Jussi Kukkonen wrote:

Hi,

I realise I'm a bit late (with the commit in master already) but I'm
looking at upgrading this recipe and had some questions on this patch
and the recipe in general.

On 9 August 2015 at 08:28, Armin Kuster  wrote:

adding the license definitions on the few packages that
deviate from the overall package license.

based on http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright
and spot checking files.

Signed-off-by: Armin Kuster 
---
  meta/recipes-support/nettle/nettle_2.7.1.bb | 9 +
  1 file changed, 9 insertions(+)

diff --git a/meta/recipes-support/nettle/nettle_2.7.1.bb 
b/meta/recipes-support/nettle/nettle_2.7.1.bb
index f53afcc..f9d331f 100644
--- a/meta/recipes-support/nettle/nettle_2.7.1.bb
+++ b/meta/recipes-support/nettle/nettle_2.7.1.bb
@@ -2,6 +2,15 @@ SUMMARY = "A low level cryptographic library"
  HOMEPAGE = "http://www.lysator.liu.se/~nisse/nettle/";
  SECTION = "libs"
  LICENSE = "LGPLv2.1 & GPLv2"


I think this is wrong, whichever version you look at -- our current
version is just "LGPLv2.1+", the current upstream release is "LGPLv3+
| GPLv2+"

I'm going to send a patch upgrading the recipe to the current upstream
release (and setting license to "LGPLv3+ | GPLv2+"): it might seem
like this makes gnutls effectively LGPLv3 but that actually happened
last year with the gmp upgrade. Comments on this welcome.


I believe that conversation should be in the mailing list archive.

For me LGPLv2+ makes is all version above GPL2, but since I am not a 
lawyer it makes not sense on how to play that game. So I decided to drop 
pressuring the update.


- Armin





+LICENSE_${PN}-cast = "CC0"
+LICENSE_${PN}-gosthash = "MIT"
+
+# both public and GPL license listed
+LICENSE_${PN}-md2 = "CC0 & LGPLv2.1+"
+LICENSE_${PN}-md4 = "CC0 & LGPLv2.1+"


 From the reference I had the impression this "LICENSE_something"
construct would imply there is a package "something". But the nettle
recipe does not produce "nettle-cast" or any of these. What is the
purpose here?

Thanks,
  Jussi


+
+
  LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
  
file://serpent-decrypt.c;beginline=53;endline=67;md5=bcfd4745d53ca57f82907089898e390d
 \
  
file://serpent-set-key.c;beginline=56;endline=70;md5=bcfd4745d53ca57f82907089898e390d"
--
2.3.5

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

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

Re: [OE-core] [PATCH 2/2] package_deb.bbclass: Handle exception when encoding non-ASCII characters

[Burton, Ross]

On 13 August 2015 at 09:58, 
wrote:

> On package creation, handle exception when encoding non-ASCII characteres.
>

Debian control files are defined to be UTF-8, so the use of an ASCII
encoding method is wrong (
https://www.debian.org/doc/debian-policy/ch-controlfields.html).

(RPM appears to assume UTF-8 too)

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

Re: [OE-core] [PATCH 2/2] package_deb.bbclass: Handle exception when encoding non-ASCII characters

[Khem Raj]

On Thu, Aug 13, 2015 at 12:05 PM, Burton, Ross  wrote:
> Debian control files are defined to be UTF-8, so the use of an ASCII
> encoding method is wrong
> (https://www.debian.org/doc/debian-policy/ch-controlfields.html).
>
> (RPM appears to assume UTF-8 too)

but check it still fine isnt it.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] nettle: clean up license information

[Khem Raj]

On Thu, Aug 13, 2015 at 11:40 AM, akuster808  wrote:
>
> For me LGPLv2+ makes is all version above GPL2, but since I am not a lawyer
> it makes not sense on how to play that game. So I decided to drop pressuring
> the update.

We should represent what the license text says

" This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version."

then you say GPL-2.0+
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] package_deb.bbclass: Handle exception when encoding non-ASCII characters

[Mark Hatle]

On 8/13/15 2:21 PM, Khem Raj wrote:
> On Thu, Aug 13, 2015 at 12:05 PM, Burton, Ross  wrote:
>> Debian control files are defined to be UTF-8, so the use of an ASCII
>> encoding method is wrong
>> (https://www.debian.org/doc/debian-policy/ch-controlfields.html).
>>
>> (RPM appears to assume UTF-8 too)
> 
> but check it still fine isnt it.
> 

RPM isn't really utf-8.. it's more single 8-bit characters...  UTF-8 (1 byte
characters) work fine.. multibyte are not promised to work.

If you need special encoding (more then 8-bit characters) then you should be
using 'po' style files to translate the 8-bit chars to localized versions...

So checking (and fixing) the strings for various things is a good idea for RPM
at least.

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

Re: [OE-core] [PATCH 2/2] package_deb.bbclass: Handle exception when encoding non-ASCII characters

[Burton, Ross]

On 13 August 2015 at 20:31, Mark Hatle  wrote:

> RPM isn't really utf-8.. it's more single 8-bit characters...  UTF-8 (1
> byte
> characters) work fine.. multibyte are not promised to work.
>
> If you need special encoding (more then 8-bit characters) then you should
> be
> using 'po' style files to translate the 8-bit chars to localized
> versions...
>
> So checking (and fixing) the strings for various things is a good idea for
> RPM
> at least.
>

In the common case of "maintainer's name isn't ASCII" you don't want it
translated, and assuming UTF-8 everywhere mostly works.

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

Re: [OE-core] [PATCH 2/2] package_deb.bbclass: Handle exception when encoding non-ASCII characters

[Burton, Ross]

On 13 August 2015 at 20:21, Khem Raj  wrote:

> but check it still fine isnt it.
>

Of course, gracefully handling encoding failures is still sensible.

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

Re: [OE-core] [PATCH 2/4] glibc: remove invalid ac_cv_path_KSH

[Khem Raj]

On Mon, Jul 13, 2015 at 3:04 AM, Robert Yang  wrote:
> There is no ac_cv_path_KSH in configure, can't find it
> in config.log after remove, either.

starting 2.21 ksh checks has been removed so this patch is ok.

>
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-core/glibc/glibc.inc |1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/meta/recipes-core/glibc/glibc.inc 
> b/meta/recipes-core/glibc/glibc.inc
> index da56bc9..74ad0b5 100644
> --- a/meta/recipes-core/glibc/glibc.inc
> +++ b/meta/recipes-core/glibc/glibc.inc
> @@ -52,7 +52,6 @@ REQUIRED_DISTRO_FEATURES = "${DISTRO_FEATURES_LIBC}"
>  LEAD_SONAME = "libc.so"
>
>  CACHED_CONFIGUREVARS += " \
> -  ac_cv_path_KSH=${base_bindir}/bash \
>ac_cv_path_BASH_SHELL=${base_bindir}/bash \
>libc_cv_slibdir=${base_libdir} \
>libc_cv_rootsbindir=${base_sbindir} \
> --
> 1.7.9.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] quilt: fix the deps for ptest

[Maxin B. John]

quilt ptest requires getopt and perl-module-overloading.

[YCOTO #8062]

Signed-off-by: Maxin B. John 
---
 meta/recipes-devtools/quilt/quilt.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/quilt/quilt.inc 
b/meta/recipes-devtools/quilt/quilt.inc
index ac7ef93..837b36b 100644
--- a/meta/recipes-devtools/quilt/quilt.inc
+++ b/meta/recipes-devtools/quilt/quilt.inc
@@ -57,5 +57,6 @@ do_install_ptest() {
 RDEPENDS_${PN}-ptest = "make file sed gawk diffutils findutils ed perl \
 perl-module-filehandle perl-module-getopt-std \
 perl-module-posix perl-module-file-temp \
-perl-module-text-parsewords bash \
-"
+perl-module-text-parsewords perl-module-overloading \
+bash util-linux-getopt \
+   "
-- 
1.9.1

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

[OE-core] [PATCH] curl: upgrade to 7.44

[Maxin B. John]

Bump to version 7.44

Signed-off-by: Maxin B. John 
---
 meta/recipes-support/curl/{curl_7.43.0.bb => curl_7.44.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/curl/{curl_7.43.0.bb => curl_7.44.0.bb} (93%)

diff --git a/meta/recipes-support/curl/curl_7.43.0.bb 
b/meta/recipes-support/curl/curl_7.44.0.bb
similarity index 93%
rename from meta/recipes-support/curl/curl_7.43.0.bb
rename to meta/recipes-support/curl/curl_7.44.0.bb
index 15713e1..b293303 100644
--- a/meta/recipes-support/curl/curl_7.43.0.bb
+++ b/meta/recipes-support/curl/curl_7.44.0.bb
@@ -14,8 +14,8 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
 #
 SRC_URI += " file://configure_ac.patch"
 
-SRC_URI[md5sum] = "11bddbb452a8b766b932f859aaeeed39"
-SRC_URI[sha256sum] = 
"baa654a1122530483ccc1c58cc112fec3724a82c11c6a389f1e6a37dc8858df9"
+SRC_URI[md5sum] = "6b952ca00e5473b16a11f05f06aa8dae"
+SRC_URI[sha256sum] = 
"1e2541bae6582bb697c0fbae49e1d3e6fad5d05d5aa80dbd6f072e0a44341814"
 
 inherit autotools pkgconfig binconfig multilib_header
 
-- 
1.9.1

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

Re: [OE-core] [PATCH] glibc: package nscd related files

[Rongqing Li]

On 2015年08月14日 00:31, Khem Raj wrote:



On Aug 13, 2015, at 1:09 AM, rongqing...@windriver.com wrote:

From: Roy Li 

install nscd related configuration file, startup files, and package them,
make nscd easy to startup



please test this change on top of glibc 2.22 recipe upgrade patches which are 
in flight right now



if glibc 2.22 is merged, I will test it

thanks

-Roy


Signed-off-by: Roy Li 
---
meta/recipes-core/glibc/glibc-package.inc | 37 ++-
meta/recipes-core/glibc/glibc.inc |  2 +-
2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 8ea5915..5f7c8a9 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -49,7 +49,8 @@ FILES_libsotruss = "${libdir}/audit/sotruss-lib.so"
FILES_SOLIBSDEV = "${libdir}/lib*${SOLIBSDEV}"
FILES_${PN}-dev += "${bindir}/rpcgen ${libdir}/*_nonshared.a 
${base_libdir}/*_nonshared.a ${base_libdir}/*.o ${datadir}/aclocal"
FILES_${PN}-staticdev += "${libdir}/*.a ${base_libdir}/*.a"
-FILES_nscd = "${sbindir}/nscd*"
+FILES_nscd = "${sbindir}/nscd* ${sysconfdir}/init.d/nscd 
${systemd_unitdir}/system/nscd* ${sysconfdir}/tmpfiles.d/nscd.conf \
+  ${sysconfdir}/nscd.conf ${sysconfdir}/default/volatiles/98_nscd 
${localstatedir}/db/nscd"
FILES_${PN}-mtrace = "${bindir}/mtrace"
FILES_tzcode = "${bindir}/tzselect ${sbindir}/zic ${sbindir}/zdump"
FILES_${PN}-utils = "${bindir}/* ${sbindir}/*"
@@ -105,6 +106,29 @@ do_install_append () {
rmdir ${D}${sysconfdir}
fi
fi
+
+   if echo ${PN}|grep -q "glibc-initial"; then
+   return
+   fi
+
+   install -d ${D}${sysconfdir}/init.d
+   install -d ${D}${localstatedir}/db/nscd
+   install -m 0755 ${S}/nscd/nscd.init ${D}${sysconfdir}/init.d/nscd
+   install -m 0755 ${S}/nscd/nscd.conf ${D}${sysconfdir}/nscd.conf
+   sed -i "s%daemon%start-stop-daemon --start --exec%g" 
${D}${sysconfdir}/init.d/nscd
+
+   install -d ${D}${systemd_unitdir}/system
+   install -m 0644 ${S}/nscd/nscd.service ${D}${systemd_unitdir}/system/
+
+   if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
d)}; then
+   install -d ${D}${sysconfdir}/tmpfiles.d
+   echo "d /run/nscd 755 root root -" \
+   > ${D}${sysconfdir}/tmpfiles.d/nscd.conf
+   else
+   install -d ${D}${sysconfdir}/default/volatiles
+   echo "d root root 0755 /var/run/nscd none" \
+   > ${D}${sysconfdir}/default/volatiles/98_nscd
+   fi
}

do_install_append_aarch64 () {
@@ -174,3 +198,14 @@ glibc_package_preprocess () {
rm -rf ${PKGD}${exec_prefix}/lib
fi
}
+
+pkg_postinst_nscd () {
+   if [ -z "$D" ]; then
+   if command -v systemd-tmpfiles >/dev/null; then
+   systemd-tmpfiles --create 
${sysconfdir}/tmpfiles.d/nscd.conf
+   elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
+   ${sysconfdir}/init.d/populate-volatile.sh update
+   fi
+   fi
+}
+CONFFILES_nscd="${sysconfdir}/nscd.conf"
diff --git a/meta/recipes-core/glibc/glibc.inc 
b/meta/recipes-core/glibc/glibc.inc
index 74ad0b5..03ffb2f 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -41,7 +41,7 @@ DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial 
linux-libc-headers
#RDEPENDS_${PN} += "${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}"
PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc"
PROVIDES += "virtual/libintl virtual/libiconv"
-inherit autotools texinfo distro_features_check
+inherit autotools texinfo distro_features_check systemd
require glibc-options.inc

# The main purpose of setting this variable is to prevent users from accidently
--
1.9.1

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




--
Best Reagrds,
Roy | RongQing Li
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]

[Andre McCurdy]

On Thu, Aug 13, 2015 at 1:42 AM, Philip Balister  wrote:
> On 08/11/2015 10:46 PM, Otavio Salvador wrote:
>> On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross  wrote:
>>>
>>> On 11 August 2015 at 16:46, Khem Raj  wrote:

 can we freeze this thread please.
>>>
>>>
>>> Or more usefully, reboot it.  Philip, you're turning into Koen!  Alex, if
>>> someone on this list asks what Poky is, 99% of the time they're trolling.
>>> :)
>>>
>>> The original and unanswered question was "should oe-core continue to
>>> maintain GPLv2 recipes where upstream has moved to GPLv3 or should those
>>> recipes move to a standalone layer" with various implied questions:
>>>
>>> - If the v2 recipes move to a separate layer, who own/maintains/tests it?
>>> - Should there be v2 recipes for every recipe that has moved to v3, or only
>>> (as is now) the "more-core" recipes (currently YP tests that core-image-base
>>> builds without GPLv3, nothing else more complicated)
>>> - Should meta-gplv2 only contain recipes from oe-core, or all layers?  If
>>> other layers decide to hold both v3 and v2 recipes (not that I'm aware any
>>> have), what makes oe-core special?
>>>
>>> I'm torn, Richard is torn.  Neither of those are useful to forming a
>>> decision.  Does anyone else have any *useful* feedback?
>>
>> I think it is a matter of resource usage.
>>
>> Up to now, the GPLv2 maintenance has not been so hard and thus I would
>> say for us to stay as is for now. We should revisit this for every
>> release and review if it is time for split it or not.
>>
>
> This would be a good time to remind us who the audience is for the gplv2
> recipes so we understand the amount of manpower behind their maintenance.
>
> My concern keeping then in core is that the commnunity who uses them
> will reduce over time and they will bitrot. If that happens, we should
> create a layer for them and remove them from core.

As others have also mentioned, there are certain classes of product
(set-top boxes, automotive, medical, etc, etc) where secure boot and
signed firmware images are a non-negotiable requirement. I don't see
these classes of product going away any time soon, so it's hard to see
the overall need for "GPLv3-free" embedded distros reducing.

Some forward-thinking companies making these types of products are
already switching to OE [1], but I guess the majority are still using
legacy build environments and home-grown distros. Since these
home-grown distros typically take a "conservative" approach to
updating packages, the pain of sticking with older, pre-GPLv3 versions
might not be felt very strongly yet. It will inevitably increase over
time though and as it does there's going to be a growing number of
developers working to maintain pre-GPLv3 versions (or working to
switch to replacement packages with more permissive licenses).

 [1] 
http://www.slideshare.net/linaroorg/hkg15506-comcast-lessons-learned-from-migrating-the-rdk-code-base-to-the-openembeddedyocto-build-framework


> Philip
> --
> ___
> 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 0/1] kernel: Correct mishandling of linux.bin for building uImage

[He Zhe]

Ping.

On 08/11/2015 04:22 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>
>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
> 13:58:02 -0700)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zhe/kernel-uboot
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/kernel-uboot
>
> for you to fetch changes up to 925eb33167a5510d9d2ec76b0d3e1c2f3f109008:
>
>   kernel: Correct mishandling of linux.bin for building uImage (2015-08-11 
> 03:37:27 -0400)
>
> 
> He Zhe (1):
>   kernel: Correct mishandling of linux.bin for building uImage
>
>  meta/classes/kernel-uboot.bbclass | 1 -
>  1 file changed, 1 deletion(-)
>

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

Re: [OE-core] [PATCH 0/1] meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb

[He Zhe]

Ping.

On 08/11/2015 05:08 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>
>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
> 13:58:02 -0700)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zhe/kernel_devicetree
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zhe/kernel_devicetree
>
> for you to fetch changes up to 648173de6f77371c4e0b803af12b23cd514b2d9f:
>
>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb 
> (2015-08-11 04:58:28 -0400)
>
> 
> He Zhe (1):
>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb
>
>  meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

Re: [OE-core] Avoid race condition between do_unpack and do_deploy_archives in archiver.bbclass

[Clemens Lang]

On Thu, Aug 13, 2015 at 12:09:07PM +0100, Burton, Ross wrote:
> I'm not sure I follow this.  Functions are executed using exec_func()
> will create and cd to the default directory, so if that is ${B} then
> exec_func will create ${B} before executing the function.

I see this in the code, but my error messages speak a very different
language. Maybe it's a race condition with do_unpack, which actually
deletes and re-creates these directories again? In any case, there is a
race condition that causes the directory to be missing when it should be
there.

For reference, here's one that fails to chdir in Python code:

> 00:07:32.460 NOTE: Running task 2381 of 6712 (ID: 1986, 
> /home/builder/src/base/meta-mgu-swint-testing/recipes-test-components/bci-test-component/bci-test-component.bb,
>  do_deploy_archives)
> [...]
> 00:07:32.461 NOTE: Running task 2382 of 6712 (ID: 1972, 
> /home/builder/src/base/meta-mgu-swint-testing/recipes-test-components/bci-test-component/bci-test-component.bb,
>  do_unpack)
> [...]
> 00:07:32.464 NOTE: recipe bci-test-component-0.0.2-r0: task 
> do_deploy_archives: Started
> 00:07:32.465 NOTE: recipe bci-test-component-0.0.2-r0: task do_unpack: Started
> 00:07:32.465 ERROR: Build of do_deploy_archives failed
> 00:07:32.465 ERROR: Traceback (most recent call last):
> 00:07:32.466   File "/home/builder/src/base/poky/bitbake/lib/bb/build.py", 
> line 497, in exec_task
> 00:07:32.466 return _exec_task(fn, task, d, quieterr)
> 00:07:32.467   File "/home/builder/src/base/poky/bitbake/lib/bb/build.py", 
> line 440, in _exec_task
> 00:07:32.467 exec_func(func, localdata)
> 00:07:32.467   File "/home/builder/src/base/poky/bitbake/lib/bb/build.py", 
> line 212, in exec_func
> 00:07:32.468 exec_func_python(func, d, runfile, cwd=adir)
> 00:07:32.468   File "/home/builder/src/base/poky/bitbake/lib/bb/build.py", 
> line 237, in exec_func_python
> 00:07:32.469 os.chdir(cwd)
> 00:07:32.469 OSError: [Errno 2] No such file or directory: 
> '/home/builder/src/base/build_vmwx86/tmp/work/core2-32-linux/bci-test-component/0.0.2-r0/git'
> 00:07:32.469 
> 00:07:32.470 NOTE: recipe bci-test-component-0.0.2-r0: task 
> do_deploy_archives: Failed

And here's another one that shows the same problem for a Shell function:

> 00:09:40.943 NOTE: Running task 3484 of 7306 (ID: 2653, 
> /home/builder/src/base/meta-mgu-swint-sdk/recipes-extended/dlt-daemon/dlt-daemon-sdktests_2.10.0.bb,
>  do_deploy_archives)
> 00:09:40.944 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task do_fetch: 
> Succeeded
> [...]
> 00:09:40.946 NOTE: Running task 3485 of 7306 (ID: 2640, 
> /home/builder/src/base/meta-mgu-swint-sdk/recipes-extended/dlt-daemon/dlt-daemon-sdktests_2.10.0.bb,
>  do_unpack)
> [...]
> 00:09:40.953 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task 
> do_deploy_archives: Started
> 00:09:41.930 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task do_unpack: 
> Started
> [...]
> 00:09:41.931 ERROR: Function failed: do_deploy_archives (log file is located 
> at 
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/log.do_deploy_archives.25418)
> 00:09:41.932 ERROR: Logfile of failure stored in: 
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/log.do_deploy_archives.25418
> 00:09:41.933 Log data follows:
> 00:09:41.934 | DEBUG: Executing python function sstate_task_prefunc
> 00:09:41.934 | DEBUG: Python function sstate_task_prefunc finished
> 00:09:41.934 | DEBUG: Executing shell function do_deploy_archives
> 00:09:41.935 | 
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/run.do_deploy_archives.25418:
>  102: cd: can't cd to 
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/git
> 00:09:41.936 | WARNING: exit code 2 from a shell command.
> 00:09:41.936 | ERROR: Function failed: do_deploy_archives (log file is 
> located at 
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/log.do_deploy_archives.25418)
> 00:09:41.937 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task 
> do_deploy_archives: Failed

I do not see any of these issues with my patch applied.

-- 
Clemens Lang • Development Specialist
BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com
-
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Reinhard Stolle
Sitz und Registergericht: München HRB 134810
-
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core