[yocto] [meta-security][PATCH] samhain: Avoid empty source archiver

It is better to put necessary work into do_patch task than add a new task. Otherwise,you can not get correct source code in some functions(such as archiver.bbclass). Signed-off-by: Lei Maohui --- recipes-security/samhain/samhain.inc | 17 +++-- 1 file

[yocto] [eclipse-poky][PATCH] Documentation: add check for adt-manual vs sdk-manual build

[YOCTO #9622] For older YP releases (prior to krogoth/2.1) adt-manual was the norm. Since krogoth/2.1, sdk-manual should replace it. - adt-manual dropped in commit 84abe03de1cff7952b5d0428e7433f094dde2b02 - sdk-manual added in commit ab591831a97a97d405d13ed75e9fb01e0452c292 Signed-off-by: Tim

[linux-yocto] [PATCH 1/2] iio: tmp006: Set correct iio name

When load the driver using the below command: echo tmp006 0x40 > /sys/bus/i2c/devices/i2c-0/new_device In sysfs, the i2c name is tmp006, however the iio name is 0-0040, they are inconsistent. With this patch, the iio name will be the same as the i2c device name Signed-off-by: Yong Li

[linux-yocto] [PATCH 2/2] iio: si7020: Set correct iio name

When load the driver using the below command: echo si7020 0x40 > /sys/bus/i2c/devices/i2c-0/new_device In sysfs, the i2c name is si7020, however the iio name is 0-0040, they are inconsistent. With this patch, the iio name will be the same as the i2c device name Signed-off-by: Yong Li

[linux-yocto] [PATCH 0/2] iio: Set correct iio name

Dear Maintainers, This patch fixes the “incorrect IIO device name” issue. Please merge it into standard/base branch for linux-yocto-4.4 if this looks okay. Thanks Yong Li Yong Li (2): iio: tmp006: Set correct iio name iio: si7020: Set correct iio name drivers/iio/humidity/si7020.c|

[yocto] On target gdb support for multiple architectures?

Hello, We're trying to setup our target for onboard debugging. We have multiple architectures being built with multilib. An armv7 variant which is 32 bit and an armv8 variant which is 64 bit. We would like the gdb installed in the image to support both architectures. Right now, even when

Re: [yocto] DEPENDS problem with core-image-full-cmdline

>> I guess we don't cover that explicitly, other than in the reference manual >> entries for each variable. We probably need a small section on dependencies >> in the "Writing a new Recipe" section: >> >> >> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-rec >>

Re: [yocto] DEPENDS problem with core-image-full-cmdline

On Fri, 27 May 2016 09:01:31 Paul Eggleton wrote: > On Thu, 26 May 2016 17:03:13 Jonathan Haws wrote: > > > DEPENDS is built-time for the recipe, so the concept of per-package > > > build dependencies doesn't really make sense. > > > > > > DEPENDS = "foo bar" are build dependencies > > >

Re: [yocto] DEPENDS problem with core-image-full-cmdline

On 26 May 2016 at 18:03, Jonathan Haws wrote: > > DEPENDS is built-time for the recipe, so the concept of per-package > > build dependencies doesn't really make sense. > > > > DEPENDS = "foo bar" are build dependencies > > RDEPENDS_${PN} = "foo bar" are

[linux-yocto] [PATCH 1/1] Revert "common-pc*: Have *-standard BSPs use standard/intel"

This reverts commit 1c4353d569cb037064fdb378d3be9ac7e4bc08d1. Restrict standard/intel visibility to meta-intel i.e. don't touch common-pc*. --- bsp/common-pc-64/common-pc-64-standard.scc | 1 - bsp/common-pc/common-pc-standard.scc | 1 - 2 files changed, 2 deletions(-) diff --git

[linux-yocto] [PATCH 0/1] Revert 4.4 common-pc* standard/intel change

I got a little overzealous with moving BSPs to standard/intel - we should have started with meta-intel only and not touched genericX86 or anything else. This reverts the common-pc* changes that did that (and should also get rid of the new warnings for qemux86*). The following changes since

[linux-yocto] [PATCH 0/1] Revert 4.1 common-pc* standard/intel change

I got a little overzealous with moving BSPs to standard/intel - we should have started with meta-intel only and not touched genericX86 or anything else. This reverts the common-pc* changes that did that (and should also get rid of the new warnings for qemux86*). The following changes since

Re: [yocto] DEPENDS problem with core-image-full-cmdline

> DEPENDS is built-time for the recipe, so the concept of per-package > build dependencies doesn't really make sense. > > DEPENDS = "foo bar" are build dependencies > RDEPENDS_${PN} = "foo bar" are package-specific runtime dependencies. Ross, thanks for clearing that up. Is there anything in the

Re: [yocto] DEPENDS problem with core-image-full-cmdline

On 26 May 2016 at 17:36, Jonathan Haws wrote: > I did find that if I do: > > DEPENDS += " batman-adv libnl" > > instead of > > DEPENDS_${PN} += " batman-adv libnl" > DEPENDS is built-time for the recipe, so the concept of per-package build dependencies doesn't really

Re: [yocto] DEPENDS problem with core-image-full-cmdline

> However, when building core-image-full-cmdline, I get the following > errors. > > > The error is in the batctl recipe, does that also have a DEPENDS=libnl? > Oh geez...I feel sheepish! Attached is my updated batctl recipe - still giving the same errors. ERROR: oe_runmake failed ERROR:

Re: [yocto] DEPENDS problem with core-image-full-cmdline

On 26 May 2016 at 17:01, Jonathan Haws wrote: > However, when building core-image-full-cmdline, I get the following errors. > The error is in the batctl recipe, does that also have a DEPENDS=libnl? Ross -- ___ yocto

[yocto] DEPENDS problem with core-image-full-cmdline

I'm working on a recipe for batman-adv, which depends on libnl at build time. I've attached my recipe for batman-adv. It's pretty straightforward, but the DEPENDS variable doesn't seem to work when I build core-image-full-cmdline. If I clean both libnl and batman-adv, then bitbake

Re: [linux-yocto] [PATCH 0/6] linux-yocto-4.4: Use */intel branches

On 2016-05-24 5:49 PM, Tom Zanussi wrote: In order to provide more timely support for Intel platforms, this patchset makes use of a set of dedicated */intel branches to be created for the linux-yocto 4.4 kernel. These branches and the corresponding kernel metadata branches provide a place to

Re: [yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

Ok, this looks right. Let me test it and then pull. On 25 May 2016 at 21:28, Bill Randle wrote: > Fixed a bug where GetLayerVersion set the layerversion to -1 when a > meta-poky layer.conf was not found. > > Signed-off-by: Bill Randle >

[yocto] Ethernet issues in Yocto

Hello all, Recently i have builded yocto rootfs for am335x. I am getting some strange issues with eth0 & eth1 port. As i am trying to make eth0 port down manually by "ifconfig eth0 down", but its not happening as per expected. It suddenly turns up within 2/3 seconds. Scenario:

[yocto] [meta-selinux][PATCH] libselinux_git: fix warnings of unavailable patches

From: Shrikant Bobade Drop unavailable patches entry to fix the warning, even we are using libselinux v2.5 these warnings pop-up during recipes parsing. WARNING:..libselinux_git.bb: Unable to get checksum for libselinux SRC_URI entry

[yocto] [meta-selinux][PATCH] refpolicy-minimum_git: add systemd dependent policy modules

From: Shrikant Bobade with systemd enabled refpolicy-minimum build breaks due to missing dependent policy modules, so add the dependent modules: clock, systemd, udev conditionally based on DISTRO_FEATURES. dependent systemd policy modules needed to fix these errors: