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.
On 28.10.2013 19:46, Trevor Woerner wrote:
On 28 October 2013 03:22, Volker Vogelhuber
v.vogelhu...@digitalendoscopy.de 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
On Tue, Oct 29, 2013 at 1:38 AM, Khem Raj raj.k...@gmail.com wrote:
On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi yang@windriver.com 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
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
2013/10/28 Bruce Ashfield bruce.ashfi...@windriver.com
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
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 $HOME a
On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro diego.sue...@gmail.com wrote:
2013/10/28 Bruce Ashfield bruce.ashfi...@windriver.com
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
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 actually
On 13-10-29 05:28 AM, Hans Beckérus wrote:
On Tue, Oct 29, 2013 at 1:38 AM, Khem Raj raj.k...@gmail.com wrote:
On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi yang@windriver.com wrote:
On MIPS64, __u64 is unsigned long type, so the %llu specifier will cause
build error on MIPS64.
Convert __u64
On Tue, Oct 29, 2013 at 12:00 PM, Martin Jansa martin.ja...@gmail.com 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
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 martin.ja...@gmail.com 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
On 10/28/2013 5:38 PM, Khem Raj wrote:
On Fri, Oct 25, 2013 at 12:17 PM, Yang Shi yang@windriver.com 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.
2013/10/29 Andrea Adami andrea.ad...@gmail.com
I'll jump in one more time...
Have you tried putting defconfig and patch under machine subdir?
recipes-kernel/linux/linux-yocto-3.2/machine
defconfig
my-own.patch
I've recently added two similar entries for 3.10 and it works.
Afaik it was
On Tuesday 29 October 2013 09:08:01 Gary Thomas wrote:
Since this commit:
commit 8b42409dca729b7abbbdac04f533e161de86a3ef
Author: Paul Eggleton paul.eggle...@linux.intel.com
Date: Fri Oct 18 15:19:58 2013 +0100
scripts/oe-pkgdata-util: improve help text and command line
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
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:
Hi
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
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
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
http://fsl-image-core.bb.*
It's not necessary (and indeed, poor practice) to make a change to the main
On Tue, Jul 23, 2013 at 6:01 PM, Christian Gagneraud chg...@gna.org 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
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
On Tue, Oct 29, 2013 at 5:04 PM, Brian Hutchinson b.hutch...@gmail.comwrote:
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
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 to
On Tue, Oct 29, 2013 at 3:55 PM, Markus Svilans msvil...@aeonyx.ca 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
On Tue, Oct 29, 2013 at 2:21 PM, Brian Hutchinson b.hutch...@gmail.com wrote:
On Tue, Oct 29, 2013 at 5:04 PM, Brian Hutchinson b.hutch...@gmail.com
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
This is the default policy type used by most (all?) distros that
support SELinux.
Signed-off-by: Philip Tricca fl...@twobit.us
---
.../refpolicy/refpolicy-mcs_2.20130424.bb | 23
1 file changed, 23 insertions(+)
create mode 100644
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
Use default assignment to allow variables to be overriden by recipes
that include refpolicy_common.inc
Signed-off-by: Philip Tricca fl...@twobit.us
---
recipes-security/refpolicy/refpolicy_common.inc | 12
1 file changed, 12 insertions(+)
diff --git
Signed-off-by: Philip Tricca fl...@twobit.us
---
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
Signed-off-by: Philip Tricca fl...@twobit.us
---
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
Signed-off-by: Philip Tricca fl...@twobit.us
---
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
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.
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 b.hutch...@gmail.com
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
33 matches
Mail list logo
