On Tue, Oct 02, 2012 at 12:43:27PM -0400, Jerrod Peach wrote:
> I was thinking about doing something very close to that in actual Yocto,
> except I'd store only the revisions/branches that were different from what
> the bb file prescribed in local.conf. I ran that idea by a couple of
> colleagues
> And one final question: Have I been putting this on the wrong mailing
list?
Possibly, kind of, but you would not have gotten my response because I do
not follow to bitbake-devel :)
:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yocto
> And one final question: Have I been putting this on the wrong mailing
list?
Kind of, but you would not have gotten my response because I do not
subscribe to bitbake-devel :)
:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject
Disclaimer: I am no Bitbake expert. I just put this together by rummaging
through the Bitbake code for a couple of minutes. I am reasonably confident
that what I am saying below is rather accurate but the Bitbake experts know
better.
Indeed it is. One of my first tasks will be to *remove* as muc
From: Kishore Bodke
Hi,
This patch set adds the new recipe for Zlib QAT Kernel Module for
building the Quick Assist Technology driver by adding it to the
custom Image.
Please pull into meta-intel/master.
Thanks
Kishore.
The following changes since commit bc6f631c1eaa7154e667325da8fd636a0562
And one final question: Have I been putting this on the wrong mailing list?
I just discovered the mailing lists at OpenEmbedded, specifically:
bitbake-de...@lists.openembedded.org
Apologies if I've been bothering the wrong people.
On Oct 4, 2012, at 7:47 PM, Patrick Turley
wrote:
> *Very
*Very* helpful stuff.
I have re-created the tree you described, and everything seems to work. In
particular, bitbake-layers seems happy. I tried executing it against BitBake
1.12.0 and it succeeded. FYI, it failed against the current BitBake master,
which is 1.16.0.
I have some additional que
On 10/04/2012 03:23 PM, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble
>
> This is recommended in the EMGD User Guide.
>
> My understanding is the emgd kernel driver need to allocate memory
> dynamically, and the "vmalloc=256MB" parameter ensures enough will
> be available for the driver
> -Original Message-
> From: Hart, Darren
> Sent: Thursday, October 04, 2012 3:14 PM
> To: Kamble, Nitin A
> Cc: Zanussi, Tom; yocto@yoctoproject.org
> Subject: Re: [PATCH 0/1] meta-intel misc commits
>
> I'm familiar with the user-guide and have read through it. What I'm saying is
> that
From: Nitin A Kamble
This is recommended in the EMGD User Guide.
My understanding is the emgd kernel driver need to allocate memory
dynamically, and the "vmalloc=256MB" parameter ensures enough will
be available for the driver.
Signed-off-by: Nitin A Kamble
---
meta-crownbay/conf/machine/crow
From: Nitin A Kamble
Updated the commit log as per Darren's recommendations.
Thanks,
Nitin
The following changes since commit bc6f631c1eaa7154e667325da8fd636a05628f87:
jasperforest: uprev v3.4 kernel commit ids (2012-10-04 14:21:55 -0500)
are available in the git repository at:
git://git.
I'm familiar with the user-guide and have read through it. What I'm
saying is that there should be a technical reason for adding a kernel
command line and we should cite it in the commit. How does this improve
the current state of things?
--
Darren
On 10/04/2012 02:56 PM, Kamble, Nitin A wrote:
>
Thanks, this is great! I was looking for something exactly like this.
I'm going to have a play wit it right now. If you (or anyone) can think
of any ways this example doesn't adhere to current bitbake best
practices (other than not inheriting from OECore's more full-featured
base classes), please
On 10/04/2012 01:16 PM, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble
>
> This is recommended in the EMGD User Guide.
What does this actually do? It seems to work fine without it.
--
Darren
>
> Signed-off-by: Nitin A Kamble
> ---
> meta-crownbay/conf/machine/crownbay.conf |2 +-
>
> hmmm clearing sstate generally should not be needed. I wonder if there
> is something to fix here
> but now you have blown up you cache :)
>
Fair enough. Hindsight. I should have moved it. There will be a next
time
___
yocto mailing list
yocto@yo
On Thu, Oct 4, 2012 at 12:09 PM, Rudolf Streif wrote:
> I eventually had to clean out the sstate-cache to make it work. Not a big
> deal and not probably not worth any further investigation. Thanks for
> helping.
hmmm clearing sstate generally should not be needed. I wonder if there
is something
From: Nitin A Kamble
This is recommended in the EMGD User Guide.
Signed-off-by: Nitin A Kamble
---
meta-crownbay/conf/machine/crownbay.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.
From: Nitin A Kamble
Here is a commit to add a kernel parameter to crownbay BSP. It is recommended
in the EMGD 1.14 User Guide for video acceleration with the EMGD driver.
Darren,
Other EMGD based BSPs like FRI2 & sys940x should add the vmalloc=256MB kernel
parameter too. (not needed for noemg
On 10/04/2012 03:15 PM, Jim Abernathy wrote:
Build Configuration:
BB_VERSION= "1.16.0"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "crownbay"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapsh
Build Configuration:
BB_VERSION= "1.16.0"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "crownbay"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20121004"
TUNE_FEATURES = "
I eventually had to clean out the sstate-cache to make it work. Not a big
deal and not probably not worth any further investigation. Thanks for
helping.
:rjs
On Thu, Oct 4, 2012 at 1:22 AM, Martin Jansa wrote:
> On Thu, Oct 04, 2012 at 09:43:58AM +0300, Andrei Gherzan wrote:
> > There were some
[Warning: lengthy post, and probably boring to most.]
My Bitbake "Hello World" is a little more than a basic "Hello World". It's
idea is to incorporate a layer and use a structure similar to what OE and
Yocto are using. You can do it simpler if you want to. I did this a while
ago with Bitbake 1.12
I successfully build the meta-crownbay BSP using the latest pull from
master branch. I did get some warning, that I wonder what they mean or
the significance of them:
NOTE: preferred version 7.11 of mesa-dri not available (for item
virtual/libgl)
NOTE: versions of mesa-dri available: 2:8.0.4
Hi Mihai,
On Thursday 04 October 2012 20:47:08 Mihai Lindner wrote:
> Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used
> SRC_URI_append instead of SRC_URI.
> Also placed all variables in an .inc file to be required by all
> linux-yocto recipes in here, since all versions use
Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used
SRC_URI_append instead of SRC_URI.
Also placed all variables in an .inc file to be required by all
linux-yocto recipes in here, since all versions use the same.
[YOCTO #3217]
Signed-off-by: Mihai Lindner
---
meta-tlk/recipes
Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used
SRC_URI_append instead of SRC_URI.
Also placed all variables in an .inc file to be required by all
linux-yocto recipes in here, since all versions use the same.
[YOCTO #3217]
Signed-off-by: Mihai Lindner
---
The following ch
That is excellent news. I very much look forward to seeing that.
On Oct 3, 2012, at 6:03 PM, Rudolf Streif
mailto:rudolf.str...@linux.com>>
wrote:
Hi Patrick,
I think I understand what you are looking for. I created this Bitbake Hello
World for a training class. It just uses 'raw' Bitbake an
From: Marc Olzheim
Signed-off-by: Martin Jansa
---
opkg-make-index | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/opkg-make-index b/opkg-make-index
index 1c3a8e1..44fa64d 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -213,7 +213,7 @@ if filelist_filename:
The following changes since commit 423ecd36b4782327c16f516885d1248249c7724a:
Changed call to subprocess.check_output which isn't compatible with Python
2.6 (2012-06-19 08:34:48 +0100)
are available in the git repository at:
git://github.com/shr-project/opkg-utils master
https://github.com
From: Atanas Gegov
The cheat sheet added provides an interactive tutorial for creating
and building the 'Hello World C++ Autotools Project' provided with the
yocto ide. The tutorial starts of by configuring the yocto project
settings and then guides the user through the process of creating and
f
From: Atanas Gegov
Hi Jessica,
Please excuse my late reaction, but I was on vacation in August and had some
high-priority organisational issues at work in Septmeber. I improved the cheat
sheet accroding to your feedback. I used conditional subitems to make it both
fit for the "Hello World C++
From: Atanas Gegov
This currently empty plugin will in the future contain yocto ide
specific user help documents such as eclipse help documents or cheat
sheets.
---
plugins/org.yocto.sdk.ide.doc.user/.classpath |6
plugins/org.yocto.sdk.ide.doc.user/.project| 28 +
From: Atanas Gegov
The added doc plugin org.yocto.sdk.ide.doc.user will provide help
contents for this feature (e.g help documents, cheat sheets).
---
features/org.yocto.sdk/feature.xml |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/features/org.yocto.sdk/feature
On 2012-10-04 06:27, Jonas Jonsson L wrote:
Hi,
I'm trying to get a working python on a 'core-image-minimal' type of image but
with no luck. Loads of stuff from the standard python library aren't installed
on the target
(qemuppc), as an example I can't run 'python-config' since the
'distutils
Hi,
I'm trying to get a working python on a 'core-image-minimal' type of image but
with no luck. Loads of stuff from the standard python library aren't installed
on the target (qemuppc), as an example I can't run 'python-config' since the
'distutils'-module isn't available. I need the 'shutil
On Thu, 2012-10-04 at 10:02 +, Szankin, Maciej wrote:
> Hi,
> I’m having a hard time building yocto.
> I’m trying to build a tiny-poky / core-image-rt , but it doesn’t even
> matter as in every configuration it just fails on eglibc.
> Target architecture is x86.
>
> I will keep it clean so th
removed all the depenencies of gypsy in meta-yocto.
Signed-off-by: Andrei Dinu
---
meta-yocto/conf/distro/include/maintainers.inc |1 -
.../distro/include/poky-floating-revisions.inc |1 -
2 files changed, 2 deletions(-)
diff --git a/meta-yocto/conf/distro/include/maintainers.in
Hi,
I'm having a hard time building yocto.
I'm trying to build a tiny-poky / core-image-rt , but it doesn't even matter as
in every configuration it just fails on eglibc.
Target architecture is x86.
I will keep it clean so the error log returned by build is here ->
http://pastebin.com/RNv5u8H8
I
On Wed, Oct 3, 2012 at 11:27 PM, Khem Raj wrote:
> Hi
>
> On danny branch I am seeing below error when multilib is enabled for
> x86-64 anyone seen it ?
>
> ERROR: Multiple .bb files are due to be built which each provide
> virtual/lib32-libintl
> (virtual:multilib:lib32:/work/yocto/poky/meta/reci
On Thu, Oct 04, 2012 at 09:43:58AM +0300, Andrei Gherzan wrote:
> There were some issues with libffi while updating the package. Maybe some
> bumps were missed. So:
> 1. This is not new build. In this case a pull on master should fix it. I
> think I saw some pr bumps sent as patch.
Yes but I did
40 matches
Mail list logo
