Re: [OE-core] [PATCH] arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above

2018-05-22 Thread Jef.Driesen
Andre McCurdy wrote:
> Although there may still be specific cases which can benefit from the
> ARM instruction set, the Thumb2 instruction set is generally a better
> default for armv7a class CPUs. Distros such as Debian and Fedora have
> been targeting Thumb2 by default for some time.
>
> Note that setting ARM_INSTRUCTION_SET has no effect unless
> TUNE_FEATURES contains "thumb" (which is controlled by the "t" suffix
> in DEFAULTTUNE, e.g. armv7vehf-neon -vs- armv7vethf-neon, etc) so out
> of tree machine configs may need to update their DEFAULTTUNE to take
> advantage of this change.

I recently ran into some major problems due to thumb vs arm. It turns out glibc 
doesn't support systems with thumb disabled anymore. See this bug report for 
details:

https://sourceware.org/bugzilla/show_bug.cgi?id=23031

This might be useful input for this discussion also.

Jef
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] Small improvement for the initscripts package

2017-09-29 Thread Jef.Driesen
Hi,

Attached is a small patch to remove the empty initscripts-{dev,doc,dbg} 
packages.

For our system, we are using some custom initscripts. Because of that, some 
files conflict with the initscripts package, and thus the initscript package 
gets removed from our build. But when trying to build an sdk, somehow the 
initscripts-dev package gets pulled in, and since that has an automatic 
dependency on initscripts, our build fails.

I've been trying to find out why this happens, but without much success so far. 
But I did found a simple workaround: remove the initscripts-dev package 
completely. Since the initscripts recipe contains some shell scripts the 
initscript-dev is empty anyway.

I've fixed this locally with a bbappend, but this is probably something that 
can be applied upstream.

Jef
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
From 93904b97ed3678f6c4a77e6504d2d05e967b0d71 Mon Sep 17 00:00:00 2001
From: Jef Driesen 
Date: Fri, 29 Sep 2017 09:09:43 +0200
Subject: [PATCH] Remove empty packages

Because the initscripts recipe contains only some shell scripts, the standard
packages (e.g. ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc, etc) are all
empty and can be removed.

Signed-off-by: Jef Driesen 
---
 meta/recipes-core/initscripts/initscripts_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb b/meta/recipes-core/initscripts/initscripts_1.0.bb
index f90de6e..cb056b7 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -46,7 +46,7 @@ inherit update-alternatives
 DEPENDS_append = " update-rc.d-native"
 DEPENDS_append = " ${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd-systemctl-native','',d)}"
 
-PACKAGES =+ "${PN}-functions"
+PACKAGES = "${PN}-functions ${PN}"
 RDEPENDS_${PN} = "${PN}-functions \
   ${@bb.utils.contains('DISTRO_FEATURES','selinux','bash','',d)} \
 		 "
-- 
2.7.4

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


Re: [OE-core] [PATCH] Small improvement for the initscripts package

2017-09-29 Thread Jef.Driesen
On 09/29/2017 11:38 AM, jef.drie...@niko.eu wrote:
>> For our system, we are using some custom initscripts. Because of
>> that, some files conflict with the initscripts package, and thus the
>> initscript package gets removed from our build. But when trying to
>> build an sdk, somehow the initscripts-dev package gets pulled in, and
>> since that has an automatic dependency on initscripts, our build
>> fails.
>
> Please do find out why this happens; that's what you really need to fix.

I tried, but I couldn't figure out where this came from.

>> I've been trying to find out why this happens, but without much
>> success so far. But I did found a simple workaround: remove the
>> initscripts-dev package completely. Since the initscripts recipe
>> contains some shell scripts the initscript-dev is empty anyway.
>>
>> I've fixed this locally with a bbappend, but this is probably
>> something that can be applied upstream.
>
> You can use bbappend to instead replace the standard files with the ones
> that you want installed. Or you can add PROVIDES = "initscripts" to your
> recipe with the 'custom' initscripts, and set
> PREFERRED_PROVIDER_initscripts = "my-custom-initscripts" to have that
> installed.

Those custom initscripts are not in our own layer. It's in a layer we build 
upon. So it's a bit more complex.

Anyway, what we have there is the following. In the machine conf file there is:

VIRTUAL-RUNTIME_initscripts = ""

This replaces the default 
meta/recipes-core/packagegroups/packagegroup-core-boot.bb:

VIRTUAL-RUNTIME_initscripts ?= "initscripts"

So I assume that's how they remove the initscripts package. And then in the 
image recipe they have:

PACKAGE_EXCLUDE += "initscripts-dev"

But for some reason this doesn't work for us. It fails with this error:

ERROR: Unable to install packages. Command 
'/home/bob/nhc2/yocto/build/tmp/sysroots/x86_64-linux/usr/bin/smart 
--log-level=warning 
--data-dir=/home/bob/nhc2/yocto/build/tmp/work/emperor-poky-linux-gnueabi/image-sdk-niko/1.0-r0/sdk/image/opt/yotta/2.0.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/var/lib/smart
 install --attempt -y initscripts-dbg@armv7a_vfp_neon 
initscripts-dev@armv7a_vfp_neon ...' returned 1:
Loading cache...
Updating cache...    [100%
Computing transaction...warning: Can't install 
initscripts-dev-1.0-r155.0@armv7a_vfp_neon: it's locked
Traceback (most recent call last):
  File 
"/home/bob/nhc2/yocto/build/tmp/sysroots/x86_64-linux/usr/bin/smart.real", line 
200, in 
main(sys.argv[1:])
  File 
"/home/bob/nhc2/yocto/build/tmp/sysroots/x86_64-linux/usr/bin/smart.real", line 
173, in main
exitcode = iface.run(opts.command, opts.argv)
  File 
"/home/bob/nhc2/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/interface.py",
 line 53, in run
result = _command.main(self._ctrl, opts)
  File 
"/home/bob/nhc2/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/commands/install.py",
 line 192, in main
trans.run()
  File 
"/home/bob/nhc2/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/transaction.py",
 line 1235, in run
del changeset[pkg]
KeyError: initscripts-dev-1.0-r155.0@armv7a_vfp_neon

DEBUG: Python function do_populate_sdk finished
ERROR: Function failed: do_populate_sdk


I'm not even sure whether PACKAGE_EXCLUDE is supposed to be used from an image 
recipe, because the documentation refers to local.conf. So that might explain 
why it doesn't work.

Jef
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] Small improvement for the initscripts package

2017-10-03 Thread Jef.Driesen
Alexander Kanavin:
> You can use bbappend to instead replace the standard files with the ones
> that you want installed. Or you can add PROVIDES = "initscripts" to your
> recipe with the 'custom' initscripts, and set
> PREFERRED_PROVIDER_initscripts = "my-custom-initscripts" to have that
> installed.

If I try that, I get a different error:

ERROR: The recipe base-files-emperor is trying to install files into a shared 
area when those files already exist. Those files and their manifest location 
are:
   
/home/jdi/develop/yocto/build/tmp/sysroots/emperor/sysroot-providers/initscripts
 Matched in manifest-emperor-initscripts.populate_sysroot
Please verify which recipe should provide the above files.
The build has stopped as continuing in this scenario WILL break things, if not 
now, possibly in the future (we've seen builds fail several months later). If 
the system knew how to recover from this automatically it would however there 
are several different scenarios which can result in this and we don't know 
which one this is. It may be you have switched providers of something like 
virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you 
need to execute the clean task for both recipes and it will resolve this error. 
It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. 
Cleaning those recipes should again resolve this error however switching 
DISTRO_FEATURES on an existing build directory is not supported, you should 
really clean out tmp and rebuild (reusing sstate should be safe). It could be 
the overlapping files detected are harmless in which case adding them to 
SSTATE_DUPWHITELIST may be the correct solution. It could also be your buil
 d is including two different conflicting versions of things (e.g. bluez 4 and 
bluez 5 and the correct solution for that would be to resolve the conflict. If 
in doubt, please ask on the mailing list, sharing the error and filelist above.
ERROR: If the above message is too much, the simpler version is you're advised 
to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix 
things in most (but not all) cases.
ERROR: Function failed: sstate_task_postfunc
ERROR: Logfile of failure stored in: 
/home/jdi/develop/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/base-files-emperor/1.0-r0/temp/log.do_populate_sysroot.8244
ERROR: Task 676 
(/home/jdi/develop/yocto/meta-fifthplay-bsp/recipes-fifthplay-bsp/base-files-emperor/base-files-emperor.bb,
 do_populate_sysroot) failed with exit code '1'

Note: base-files-emperor is the package with the custom init scripts. I added:

PROVIDES = "initscripts"

And in conf/machine/emperor.conf, I added:

PREFERRED_PROVIDER_initscripts = "base-files-emperor"

Jef
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] Small improvement for the initscripts package

2017-10-03 Thread Jef.Driesen
> I'd definitely be curious as to where initscripts is coming from in the SDK.  
> You can use bitbake -g  to generate dependency charts.

There are quite some packages which depend on initscripts:

$ bitbake -g image-sdk-niko -c populate_sdk
NOTE: Started PRServer with DBfile: 
/home/jdi/develop/yocto/build/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 42323, 
PID: 3577
Loading cache: 100% 
||
 ETA:  00:00:00
Loaded 2701 entries from dependency cache.
Parsing recipes: 100% 
|##|
 Time: 00:00:06
Parsing of 2167 .bb files complete (2138 cached, 29 parsed). 2729 targets, 350 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing RunQueue
NOTE: PN build list saved to 'pn-buildlist'
NOTE: PN dependencies saved to 'pn-depends.dot'
NOTE: Package dependencies saved to 'package-depends.dot'
NOTE: Task dependencies saved to 'task-depends.dot'

$ grep initscripts package-depends.dot
"dnsmasq-staticdev" -> "initscripts"
"eudev-dbg" -> "initscripts"
"avahi" -> "initscripts"
"run-postinsts-staticdev" -> "initscripts"
"avahi-doc" -> "initscripts"
"openssh-dev" -> "initscripts"
"syslog-ng-libs-dbg" -> "initscripts"
"ofono-staticdev" -> "initscripts"
"ntp-doc" -> "initscripts"
"syslog-ng-staticdev" -> "initscripts"
"ntp" -> "initscripts"
"eudev" -> "initscripts"
"openssh" -> "initscripts"
"initscripts-functions" [label="initscripts-functions(initscripts) 
:1.0-r155\n/home/jdi/develop/yocto/meta/recipes-core/initscripts/initscripts_1.0.bb"]
"initscripts-functions" -> "update-rc.d-native"
"initscripts-functions" -> "virtual/update-alternatives"
"ntpdate" -> "initscripts"
"dbus-lib" -> "initscripts"
"openssh-locale" -> "initscripts"
"busybox-staticdev" -> "initscripts"
"cronie" -> "initscripts"
"ofono" -> "initscripts"
"ntp-dbg" -> "initscripts"
"openssh-dbg" -> "initscripts"
"busybox-mdev" -> "initscripts"
"ofono-tests" -> "initscripts"
"watchdog-dbg" -> "initscripts"
"hostapd" -> "initscripts"
"libavahi-common" -> "initscripts"
"dnsmasq-dev" -> "initscripts"
"cronie-doc" -> "initscripts"
"eudev-hwdb" -> "initscripts"
"dbus-locale" -> "initscripts"
"busybox-doc" -> "initscripts"
"initscripts-locale" [label="initscripts-locale(initscripts) 
:1.0-r155\n/home/jdi/develop/yocto/meta/recipes-core/initscripts/initscripts_1.0.bb"]
"initscripts-locale" -> "update-rc.d-native"
"initscripts-locale" -> "virtual/update-alternatives"
"busybox-locale" -> "initscripts"
"avahi-staticdev" -> "initscripts"
"connman-tools" -> "initscripts"
"avahi-daemon" -> "initscripts"
"openssh-sshd" -> "initscripts"
"libavahi-glib" -> "initscripts"
"ofono-doc" -> "initscripts"
"ntp-utils" -> "initscripts"
"hostapd-dbg" -> "initscripts"
"libavahi-client" -> "initscripts"
"syslog-ng-dbg" -> "initscripts"
"connman-locale" -> "initscripts"
"hostapd-staticdev" -> "initscripts"
"busybox-hwclock" -> "initscripts"
"openssh-sftp" -> "initscripts"
"libavahi-ui" -> "initscripts"
"hostapd-locale" -> "initscripts"
"eudev-doc" -> "initscripts"
"initscripts-staticdev" [label="initscripts-staticdev(initscripts) 
:1.0-r155\n/home/jdi/develop/yocto/meta/recipes-core/initscripts/initscripts_1.0.bb"]
"initscripts-staticdev" -> "update-rc.d-native"
"initscripts-staticdev" -> "virtual/update-alternatives"
"avahi-dnsconfd" -> "initscripts"
"dbus-doc" -> "initscripts"
"busybox-syslog" -> "initscripts"
"syslog-ng-locale" -> "initscripts"
"syslog-ng-libs-dev" -> "initscripts"
"run-postinsts-dev" -> "initscripts"
"connman-dev" -> "initscripts"
"dnsmasq" -> "initscripts"
"busybox-httpd" -> "initscripts"
"watchdog" -> "initscripts"
"connman-dbg" -> "initscripts"
"eudev-locale" -> "initscripts"
"avahi-dev" -> "initscripts"
"avahi-autoipd" -> "initscripts"
"libavahi-gobject" -> "initscripts"
"connman-tests" -> "initscripts"
"ofono-locale" -> "initscripts"
"openssh-ssh" -> "initscripts"
"busybox" -> "initscripts"
"ofono-dbg" -> "initscripts"
"openssh-keygen" -> "initscripts"
"hostapd-doc" -> "initscripts"
"connman-client" -> "initscripts"
"busybox-dbg" -> "initscripts"
"syslog-ng" -> "initscripts"
"libavahi-core" -> "initscripts"
"initscripts-dev" [label="initscripts-dev(initscripts) 
:1.0-r155\n/home/jdi/develop/yocto/meta/recipes-core/initscripts/initscripts_1.0.bb"]
"initscripts-dev" -> "update-rc.d-native"
"initscripts-dev" -> "virtual/update-alternatives"
"syslog-ng-dev" -> "initscripts"
"connman" -> "initscripts"
"initscripts-dbg" [label="initscripts-dbg(initscripts) 
:1.0-r155\n/home/jdi/develop/yocto/meta/recipes-core/initscripts/initscripts_1.0.bb"]
"initscripts-dbg" -> "update-rc.d-native"
"initscripts-dbg" -> "virtual/update-alternatives"
"openssh-s

Re: [OE-core] [PATCH] Small improvement for the initscripts package

2017-10-03 Thread Jef.Driesen
Burton, Ross [ross.bur...@intel.com]
> On 3 October 2017 at 11:03,  wrote:
>> Note: base-files-emperor is the package with the custom init scripts. I 
>> added:
>>
>> PROVIDES = "initscripts"
>>
>> And in conf/machine/emperor.conf, I added:
>>
>> PREFERRED_PROVIDER_initscripts = "base-files-emperor"
>>
>  If your initscripts package is a replacement for the oe-core initscripts 
> package, then also set RPROVIDES_${PN} += "initscripts".

I tried your suggest, but I still get the error:

"The recipe base-files-emperor is trying to install files into a shared area 
when those files already exist." error

With base-files-emperor.bb containing:

PROVIDES += "initscripts"
RPROVIDES_${PN} += "initscripts"

What am I still doing wrong?

(I'll try to re-build after wiping the tmp directory tonight. A simple "bitbake 
-c cleanall initscripts base-files-emperor" didn't help.)

Jef
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] Small improvement for the initscripts package

2017-10-04 Thread Jef.Driesen
Alexander Kanavin:
>On 10/03/2017 06:03 PM, jef.drie...@niko.eu wrote:
>> Burton, Ross [ross.bur...@intel.com]
>>> On 3 October 2017 at 11:03,  wrote:
 Note: base-files-emperor is the package with the custom init scripts. I 
 added:

 PROVIDES = "initscripts"

 And in conf/machine/emperor.conf, I added:

 PREFERRED_PROVIDER_initscripts = "base-files-emperor"

>>>   If your initscripts package is a replacement for the oe-core initscripts 
>>> package, then also set RPROVIDES_${PN} += "initscripts".
>>
>> I tried your suggest, but I still get the error:
>>
>> "The recipe base-files-emperor is trying to install files into a shared area 
>> when those files already exist." error
>>
>> With base-files-emperor.bb containing:
>>
>> PROVIDES += "initscripts"
>> RPROVIDES_${PN} += "initscripts"
>>
>> What am I still doing wrong?
>>
>> (I'll try to re-build after wiping the tmp directory tonight. A simple 
>> "bitbake -c cleanall initscripts base-files-emperor" didn't help.)
>
> I might be reading it wrong, but the full error message seems to
> indicate you also have a recipe called emperor-intscripts that provides
> (some of) the same files as base-files-emperor, and they clash?

It's the oe-core initscripts recipe that clashes with base-files-emperor. Both 
recipies have their own /etc/init.d/halt script.

The full rebuild failed as well, with the error "Can't install 
ntp-4.2.8p8-r0.7@armv7a_vfp_neon: no package provides initscripts-functions"

And that's probably because the oe-core recipe produces a initscripts-functions 
package. We stil need that package in our image. I assume that due to using 
PROVIDES, the oe-core initscripts recipe is replaced completely with our own 
base-files-emperor recipe. And since our custom package doesn't produce an 
initscripts-functions package (because we still want the one from the oe-core 
initscripts), the build fails. So it looks like using PROVIDES doesn't work.

Alex
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Yocto rocko ssh fetcher error: scp not found

2018-03-27 Thread Jef.Driesen
Hi,

I have a recipe which uses the ssh fetcher:

SRC_URI = "ssh://username@sshserver/~/demo-${PV}.zip"

I'm trying to upgrade from pyro to rocko, and now I'm getting errors

ERROR: demo-2.0.47.0-r0 do_fetch: Fetcher failure: Fetch command export 
DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-XZhnQDkmvV"; export 
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export 
PATH="/home/jdi/develop/yocto/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/jdi/develop/yocto/scripts:/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi:/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/usr/sbin:/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/usr/bin:/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/sbin:/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux
 
-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/bin:/home/jdi/develop/yocto/bitbake/bin:/home/jdi/develop/yocto/build/tmp/hosttools";
 export HOME="/home/jdi"; scp -B -r  username@sshserver/~/demo-2.0.47.0.zip 
/home/jdi/develop/yocto/build/downloads/ failed with exit code 127, output:
/bin/sh: 1: scp: not found

Thus the PATH gets set to:

/home/jdi/develop/yocto/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
/home/jdi/develop/yocto/scripts
/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi
/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot/usr/bin/crossscripts
/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/usr/sbin
/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/usr/bin
/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/sbin
/home/jdi/develop/yocto/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/demo/2.0.47.0-r0/recipe-sysroot-native/bin
/home/jdi/develop/yocto/bitbake/bin
/home/jdi/develop/yocto/build/tmp/hosttools

But none of these contain an scp binary. So I think scp needs to be added to 
HOSTTOOLS.

Jef
Disclaimer

This e-mail and its attachments is intended only for the person(s) or entity to 
which it is addressed. If you receive this e-mail by mistake, please delete 
this e-mail from your system and destroy all copies of it. It may contain 
confidential and/or privileged information. You should not copy it or use it 
for any purpose nor disclose its contents to any person unless allowed by a 
written document between the sender and the addressee.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core