[yocto] Openvswitch integration in yocto

Hi All, i am new to yocto environment. i want to build openvswitch in yocto_1.4. The openvswitch is path : *QorIQ-SDK-V1.4-20130814-yocto/meta-virtualization/recipes-networking/openvswitch. * For compiling openvswitch i perform following steps:- 1. bitbake -f -c compile openvswitch. 2.

Re: [yocto] Out of tree build yocto dylan

On 28.10.2013 19:46, Trevor Woerner wrote: On 28 October 2013 03:22, Volker Vogelhuber wrote: I'm currently trying to have the TMPDIR moved out of the normal repository path under dylan. If I set it to TMPDIR = "${TOPDIR}/../../build/tmp" Does it work better if you use an absolute path (you

Re: [yocto] [PATCH] perf: mips64: Convert __u64 to unsigned long long

On Tue, Oct 29, 2013 at 1:38 AM, Khem Raj wrote: > On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi wrote: >> On MIPS64, "__u64" is "unsigned long" type, so the "%llu" specifier will >> cause >> build error on MIPS64. >> >> Convert __u64 to unsigned long long in those sprintf calls to avoid the build

Re: [yocto] Openvswitch integration in yocto

Hi Sonia, On Tuesday 29 October 2013 12:33:04 sonia verma wrote: > For compiling openvswitch i perform following steps:- > >1. bitbake -f -c compile openvswitch. >2. bitbake openvswitch. >3. bitbake fsl-image-core. > > but when i get fsl-image-core-t4240rdb-20131028123337.rootfs.e

Re: [yocto] Custom defconfig is not used

2013/10/28 Bruce Ashfield > I'm using dylan for my yocto checkout (not oe-core standalone, since > this is a yocto list/question), > I thought that opemenbedded-core and poky were sharing the same core components, classes and functions. > My build shows: > > meta > meta-yocto > meta-yocto-bsp

Re: [yocto] yocto-dora problems building python

Hi, > python build system is very stubborn and does not respect cross > compilation many times. You might have uncovered some case > that hasnt been seen yet. You should put your build logs for python > somewhere so we can take a look and understand better > whats going on > > I found in my $HO

Re: [yocto] Custom defconfig is not used

On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro wrote: > > 2013/10/28 Bruce Ashfield >> >> I'm using dylan for my yocto checkout (not oe-core standalone, since >> this is a yocto list/question), > > I thought that opemenbedded-core and poky were sharing the same core > components, classes and func

[yocto] SRCREV how is it supposed to work?

Hi. I am wondering if we are using SRCREV wrong somehow. Is it expected that if we use SRCREV = "${AUTOREV}", that any changes to the remote should be automatically detected and downloaded/fetched? I can no see that this is actually what happens. Any changes made to the remote still need to be manu

Re: [yocto] SRCREV how is it supposed to work?

On Tue, Oct 29, 2013 at 12:46:18PM +0100, Hans Beckérus wrote: > Hi. I am wondering if we are using SRCREV wrong somehow. > Is it expected that if we use SRCREV = "${AUTOREV}", that any changes > to the remote should be automatically detected and downloaded/fetched? > I can no see that this is actu

Re: [yocto] [PATCH] perf: mips64: Convert __u64 to unsigned long long

On 13-10-29 05:28 AM, Hans Beckérus wrote: On Tue, Oct 29, 2013 at 1:38 AM, Khem Raj wrote: On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi wrote: On MIPS64, "__u64" is "unsigned long" type, so the "%llu" specifier will cause build error on MIPS64. Convert __u64 to unsigned long long in those spr

Re: [yocto] SRCREV how is it supposed to work?

On Tue, Oct 29, 2013 at 12:00 PM, Martin Jansa wrote: > On Tue, Oct 29, 2013 at 12:46:18PM +0100, Hans Beckérus wrote: >> Hi. I am wondering if we are using SRCREV wrong somehow. >> Is it expected that if we use SRCREV = "${AUTOREV}", that any changes >> to the remote should be automatically detec

Re: [yocto] SRCREV how is it supposed to work?

On Tue, Oct 29, 2013 at 02:27:30PM +0100, Hans Beckérus wrote: > On Tue, Oct 29, 2013 at 12:00 PM, Martin Jansa wrote: > > On Tue, Oct 29, 2013 at 12:46:18PM +0100, Hans Beckérus wrote: > >> Hi. I am wondering if we are using SRCREV wrong somehow. > >> Is it expected that if we use SRCREV = "${AUT

Re: [yocto] SRCREV how is it supposed to work?

On Tue, Oct 29, 2013 at 2:42 PM, Martin Jansa wrote: > On Tue, Oct 29, 2013 at 02:27:30PM +0100, Hans Beckérus wrote: >> On Tue, Oct 29, 2013 at 12:00 PM, Martin Jansa >> wrote: >> > On Tue, Oct 29, 2013 at 12:46:18PM +0100, Hans Beckérus wrote: >> >> Hi. I am wondering if we are using SRCREV wr

Re: [yocto] [PATCH] perf: mips64: Convert __u64 to unsigned long long

On 10/28/2013 5:38 PM, Khem Raj wrote: On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi wrote: On MIPS64, "__u64" is "unsigned long" type, so the "%llu" specifier will cause build error on MIPS64. Convert __u64 to unsigned long long in those sprintf calls to avoid the build error. Signed-off-by: Ya

Re: [yocto] [PATCH] perf: mips64: Convert __u64 to unsigned long long

On 10/29/2013 5:40 AM, Bruce Ashfield wrote: On 13-10-29 05:28 AM, Hans Beckérus wrote: On Tue, Oct 29, 2013 at 1:38 AM, Khem Raj wrote: On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi wrote: On MIPS64, "__u64" is "unsigned long" type, so the "%llu" specifier will cause build error on MIPS64. C

Re: [yocto] Custom defconfig is not used

2013/10/29 Andrea Adami > I'll jump in one more time... > > Have you tried putting defconfig and patch under subdir? > > recipes-kernel/linux/linux-yocto-3.2/ > defconfig > my-own.patch > > I've recently added two similar entries for 3.10 and it works. > Afaik it was impossible to put a common p

[yocto] Can't build any images

Since this commit: commit 8b42409dca729b7abbbdac04f533e161de86a3ef Author: Paul Eggleton Date: Fri Oct 18 15:19:58 2013 +0100 scripts/oe-pkgdata-util: improve help text and command line parsing * Use optparse to parse command line * Make help text actually helpful by describ

Re: [yocto] Can't build any images

On Tuesday 29 October 2013 09:08:01 Gary Thomas wrote: > Since this commit: >commit 8b42409dca729b7abbbdac04f533e161de86a3ef >Author: Paul Eggleton >Date: Fri Oct 18 15:19:58 2013 +0100 > > scripts/oe-pkgdata-util: improve help text and command line parsing > > * Use optp

Re: [yocto] Custom defconfig is not used

Bruce, I've created new build setup with this configuration: BB_VERSION= "1.18.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-12.10" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "beaglebone" DISTRO= "poky" DISTRO_VERSION= "1.4.2" TUNE

Re: [yocto] Can't build any images

On 2013-10-29 09:15, Paul Eggleton wrote: On Tuesday 29 October 2013 09:08:01 Gary Thomas wrote: Since this commit: commit 8b42409dca729b7abbbdac04f533e161de86a3ef Author: Paul Eggleton Date: Fri Oct 18 15:19:58 2013 +0100 scripts/oe-pkgdata-util: improve help text and comm

[yocto] HG Fetch with username and password in url

We currently use an company internal mercurial server with username and password authentication that will be accessed during the build of a firmware image from within a custom recipe. The only way to access it from within the yocto toolchain seems to have the username and password stored within

Re: [yocto] Openvswitch integration in yocto

Hi Sonia, Add this line IMAGE_INSTALL_append += "openvswitch" to * QorIQ-SDK-V1.4-20130814-yocto/meta-fsl-networking/images/fsl-image-core.bb.* * * And do step 3 and openvswitch will be on T4240QDS. On Tue, Oct 29, 2013 at 4:11 AM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: >

[yocto] [Package Report System]Upgrade recipes name list

This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this recipe remainder until newer u

[yocto] [Package Report System]Manual check recipes name list

This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName

Re: [yocto] Openvswitch integration in yocto

On 2013-10-29 11:31, Sandeep G.R wrote: Hi Sonia, Add this line IMAGE_INSTALL_append += "openvswitch" to*QorIQ-SDK-V1.4-20130814-yocto/meta-fsl-networking/images/fsl-image-core.bb .* It's not necessary (and indeed, poor practice) to make a change to the mai

Re: [yocto] Should I be worried about this nativesdk-packagegroup-sdk-host warning while building meta-toolchain

On Tue, Jul 23, 2013 at 6:01 PM, Christian Gagneraud wrote: > > I got these ones as well (using poky, meta-oe, meta-ti and meta-qt5 all on > Dylan), good to hear they are harmless. > > Thanks, > Chris > > > Hi, I hate to revive an old thread but I still see the same kind of thing with Yocto 1.5.

[yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

Hi, I tried to research this issue I'm seeing but hit a bunch of noise. I generated a Yocto 1.5 sdk with my image and -c populate_sdk for i686. When a collegue tries to install the sdk on his Centos box with Python 2.6.7, he gets: sudo ./poky-eglibc-i686-core-image-wcs-armv7a-vfp-neon-toolchain

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

On Tue, Oct 29, 2013 at 5:04 PM, Brian Hutchinson wrote: > Hi, > > I tried to research this issue I'm seeing but hit a bunch of noise. I > generated a Yocto 1.5 sdk with my image and -c populate_sdk for i686. When > a collegue tries to install the sdk on his Centos box with Python 2.6.7, he > ge

Re: [yocto] Fail to build core-image-minimal when MACHINE=genericx86-64

Dear list, A quick update: - The same build failure occurred when I tried "bitbake core-image-minimal" using a fresh poky 1.5 downloaded from the Yocto web site, with MACHINE set to genericx86-64. - The same build failure occurred when I manually created a recipe for syslinux 6.02 and tried t

Re: [yocto] Fail to build core-image-minimal when MACHINE=genericx86-64

On Tue, Oct 29, 2013 at 3:55 PM, Markus Svilans wrote: > Dear list, > > A quick update: > > - The same build failure occurred when I tried "bitbake core-image-minimal" > using a fresh poky 1.5 downloaded from the Yocto web site, with MACHINE set > to genericx86-64. > - The same build failure occur

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

On Tue, Oct 29, 2013 at 2:21 PM, Brian Hutchinson wrote: > On Tue, Oct 29, 2013 at 5:04 PM, Brian Hutchinson > wrote: >> >> Hi, >> >> I tried to research this issue I'm seeing but hit a bunch of noise. I >> generated a Yocto 1.5 sdk with my image and -c populate_sdk for i686. When >> a collegue

[yocto] [meta-selinux][PATCH] Add recipe to build the MCS refpolicy.

This is the default policy type used by most (all?) distros that support SELinux. Signed-off-by: Philip Tricca --- .../refpolicy/refpolicy-mcs_2.20130424.bb | 23 1 file changed, 23 insertions(+) create mode 100644 recipes-security/refpolicy/refpolicy-mcs_2.20130

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, October 29, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Attendees: Richard, IonutC, Mark, MatthewW, ScottR, Nitin, Björn, JeffP, Cristiana, Belen, Paul, Saul, AlexG, TomZ, LaurentiuP, Song Agenda: * Opens collection - 5 min (Song) * Yocto 1.5 status & 1.6 planning - 10 min (Song/team) - 1.6 feature set is almost done. Richard and others will work

[yocto] [meta-selinux][PATCH 0/4] refpolicy: Move common POLICY_* variables to refpolicy_common.inc

This is a simple clean-up patch set to move the POLICY_* variables to the refpolicy_common.inc file. The only variable that needs to be set by the top level refpolicy recipes now is POLICY_TYPE. Philip Tricca (4): Move common POLICY_* variables to refpolicy_common.inc refpolicy-mcs: Use defaul

[yocto] [meta-selinux][PATCH 1/4] Move common POLICY_* variables to refpolicy_common.inc

Use default assignment to allow variables to be overriden by recipes that include refpolicy_common.inc Signed-off-by: Philip Tricca --- recipes-security/refpolicy/refpolicy_common.inc | 12 1 file changed, 12 insertions(+) diff --git a/recipes-security/refpolicy/refpolicy_common.

[yocto] [meta-selinux][PATCH 3/4] refpolicy-mls: Use default variables from refpolicy_common.inc

Signed-off-by: Philip Tricca --- recipes-security/refpolicy/refpolicy-mls_2.20130424.bb | 12 1 file changed, 12 deletions(-) diff --git a/recipes-security/refpolicy/refpolicy-mls_2.20130424.bb b/recipes-security/refpolicy/refpolicy-mls_2.20130424.bb index 3541611..b20f130 10064

[yocto] [meta-selinux][PATCH 2/4] refpolicy-mcs: Use default variables from refpolicy_common.inc

Signed-off-by: Philip Tricca --- recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb | 10 -- 1 file changed, 10 deletions(-) diff --git a/recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb b/recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb index 38b78f1..adb8e4a 100644

[yocto] [meta-selinux][PATCH 4/4] refpolicy-standard: Use default variables from refpolicy_common.inc

Signed-off-by: Philip Tricca --- recipes-security/refpolicy/refpolicy-standard_2.20130424.bb |8 1 file changed, 8 deletions(-) diff --git a/recipes-security/refpolicy/refpolicy-standard_2.20130424.bb b/recipes-security/refpolicy/refpolicy-standard_2.20130424.bb index 1f3030a..922

Re: [yocto] Fail to build core-image-minimal when MACHINE=genericx86-64

Thanks, Khem. Following your suggestion, I tried removing the com32/ subdirectory from the build, by modifying the do_configure() routine in syslinux_6.01.bb recipe. It did not work, there were errors related to missing .o files in a later step. Your response prompted me to look further. It

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

Hi Brian, On Tue, Oct 29, 2013 at 05:21:53PM -0400, Brian Hutchinson wrote: > On Tue, Oct 29, 2013 at 5:04 PM, Brian Hutchinson > wrote: > > Hi, > > I tried to research this issue I'm seeing but hit a bunch of noise. I > generated a Yocto 1.5 sdk with my image and -c populate_sdk