Re: [yocto] How do you release distros produced with Yocto? How should I?

[Venkata ramana gollamudi]

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 separately and they both immediately pointed out a concern: they
> didn't want to have two different places that could manage the revision of
> the package, i.e. local.conf and the package bb file.  They don't like how
> that works in the system we have today.  Instead, they wanted to branch all
> the metadata and have people update individual bb files with different
> revisions as necessary.  That leaves only one place to manage the revision:
> the package bb file.  Doing all that branching concerns me (it seems
> heavier-weight than it needs to be, at the very least), but I can't say
> specifically why branching the bb files is harmful.  If you guys can think
> of a reason why, let me know.  If you think it's reasonable, let me know
> that too.

We have solved this issue by adding OS_VERSION variable to local.conf
Lets say your product (OS) should be released in versions, Ex: 1.0 , 1.1 or 
1.1.1 etc.
Which is built from packages of different versions. So each package contains 
.inc and _.bb file.
revision number and patches are maintained in _.bb and all 
common part under .inc.

Now the problem comes to mapping the package versions to your product(OS) 
version.
This is done having a file included into disto file listing out all the 
PREFERRED_VERSIONS and PREFERRED_PROVIDERS for all packages.
  ex: conf/disto/include/osversion_1.0.inc
And this is included to disto file like
  require conf/disto/include/osversion_${OS_VERSION}.inc

The file osversion_1.0.inc is freezed after your one version release.
Next version will add a new file osversion_1.1.inc overiding to pick all the 
required package version changes to make your product version.

This will allow you to release multiple product(OS) versions and clearly maps 
the package version, creating individual distributions.
You can even build older version product by just giving OS_VERSION=1.0 in 
local.conf
This eliminates branching all together.

Regards,
Ramana
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Rudolf Streif]

> 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.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Rudolf Streif]

> 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.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Rudolf Streif]

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 much as
> possible from this until the only thing it does is print out "Hello,
> World!"  I'll be happy to share my results if anyone is interested.
>
> You can just do a recipe and overwrite do_build() in it e.g.

python do_build() {
bb.note("Hello World")
}

>
> If I understand correctly, the name of the task is "build", and the name
> of the Python function that implements it is "do_build()".  So, it appears
> BitBake prefixes all task names with "do_" to derive the name of the
> function that implements the task.  Have I got that right?
>

Yes. All tasks defined in recipes or classes have to follow the naming
convention do_ when defining them. However, when adding them to
the queue you have to omit the do_ e.g. addtask .


>
>  The "build" task is *required*, and it's the *only* one that's required?
>

No task is really required. The build task is only the default task if you
do not specify a specific task with -c. However, if you use -c Bitbake will
only execute that task and not check and run any task that this task is
depending on. But that's a whole different story.


>
>  I've been looking around in the BitBake source code a lot, so I'm
> *somewhat* familiar with it.  I tried to find the "hard" reference to
> "do_build" you described,  but I couldn't.  Can you give me a hint?
>
> In /lib/bb/cooker.py:

class BBCooker:
"""
Manages one bitbake build run
"""

def __init__(self, configuration, server_registration_cb):

# stuff omitted

if not self.configuration.cmd:
self.configuration.cmd = bb.data.getVar("BB_DEFAULT_TASK",
self.configuration.data, True) or "build"

  # more stuff

Bitbake checks if the variable BB_DEFAULT_TASK is set and if not uses
"build" as default task. You could set BB_DEFAULT_TASK in a configuration
file e.g. bitbake.conf to any task you like (as long as it is defined).


>  I see here that you're creating the recipe-specific "do_fetch()"
> function, which seems intended to "override" the default "do_fetch()"
> provided by the base class.  This prompts some questions:
>

My  base.bbclass file does not have a do_fetch function. What am I missing?


>
>  1) Must a "task function" be a Python function?  Or will a bash function
> do?
>

Tasks must be Python functions.

>
>  2) Is it absolutely necessary to follow a recipe-specific task function
> with an "addtask"?  Based on experience from "real" object-oriented
> languages, a naive observer (like me) would guess the simple presence of
> "do_fetch()" in the recipe is all that's necessary.  Or is it the "addtask"
> that actually "slots" the new function in?
>
>   You have to use addtask to make your Python function, given it follows
the naming convention, known to Bitbake as a task. You can put addtask with
the tasks name anywhere in your recipe. It does not need to follow the task
but it makes it easier to read. If you just add a task using addtask it is
kind of standalone. If you use addtask with the before/after directives you
establish an execution order.

:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/2][meta-intel] Add a new recipe for Zlib QAT Kernel Module.

[kishore . k . bodke]

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 bc6f631c1eaa7154e667325da8fd636a05628f87:

  jasperforest: uprev v3.4 kernel commit ids (2012-10-04 14:21:55 -0500)

are available in the git repository at:

  git://git.pokylinux.org/meta-intel-contrib Kishore/Zlib-qat-module
  
http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=Kishore/Zlib-qat-module

Kishore Bodke (2):
  meta-crystalforest: Add a new recipe for Zlib QAT Kernel Module.
  meta-crystalforest: Add zlib kernel module to the qat Image.

 .../zlib-qat-module/zlib-qat-module.bb |   53 +
 .../zlib-1.2.7-qat.L.0.4.0-005.patch   | 8559 
 .../zlib-qat-module/zlib_qat_module.patch  |   27 +
 .../recipes-qat-image/images/core-image-qat-sdk.bb |1 +
 .../recipes-qat-image/images/core-image-qat.bb |1 +
 5 files changed, 8641 insertions(+)
 create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-module.bb
 create mode 100644 
common/recipes-core/zlib-qat-module/zlib-qat-module/zlib-1.2.7-qat.L.0.4.0-005.patch
 create mode 100644 
common/recipes-core/zlib-qat-module/zlib-qat-module/zlib_qat_module.patch

-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Patrick Turley]

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* helpful stuff.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Patrick Turley]

*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 questions below.  You've already been so helpful that 
I'm reluctant to impose … but I'm going to try anyway :)

On Oct 4, 2012, at 1:58 PM, Rudolf Streif 
mailto:rudolf.str...@linux.com>> wrote:


My Bitbake "Hello World" is a little more than a basic "Hello World".


Indeed it is.  One of my first tasks will be to *remove* as much as possible 
from this until the only thing it does is print out "Hello, World!"  I'll be 
happy to share my results if anyone is interested.


Bitbake will require a base.bbclass file somewhere in a classes subdirectory of 
BBPATH. I used the base.bbclass file from the Bitbake download. As a minimum it 
should contain a do_build task. That's the target that Bitbake invokes by 
default if you do not use the -c option explicitly.

…

addtask build
do_build[dirs] = "${TOPDIR}"
do_build[nostamp] = "1"
python base_do_build () {
bb.note("The included, default BB base.bbclass does not define a useful 
default task.")
bb.note("Try running the 'listtasks' task against a .bb to see what 
tasks are defined.")
}


If I understand correctly, the name of the task is "build", and the name of the 
Python function that implements it is "do_build()".  So, it appears BitBake 
prefixes all task names with "do_" to derive the name of the function that 
implements the task.  Have I got that right?

The "build" task is *required*, and it's the *only* one that's required?

I've been looking around in the BitBake source code a lot, so I'm *somewhat* 
familiar with it.  I tried to find the "hard" reference to "do_build" you 
described,  but I couldn't.  Can you give me a hint?


Finally a recipe to build the Nano editor:

DESCRIPTION = "Recipe to build the 'nano' editor"

PN = "nano"
PV = "2.2.6"

SRC_URI = "http://www.nano-editor.org/dist/v2.2/nano-2.2.6.tar.gz";

python do_fetch() {
   bb.note("Downloading source tarball from ${SRC_URI} ...")

   src_uri = (bb.data.getVar('SRC_URI', d, True) or "").split()
   if len(src_uri) == 0:
  bb.fatal("Empty URI")

   try:
  bb.fetch.init(src_uri, d)
  bb.fetch.go(d)
   except FetchError:
  bb.fatal("Could not fetch source tarball.")

   bb.note("Download successful.")
}

addtask fetch before do_build


I see here that you're creating the recipe-specific "do_fetch()" function, 
which seems intended to "override" the default "do_fetch()" provided by the 
base class.  This prompts some questions:

1) Must a "task function" be a Python function?  Or will a bash function do?

2) Is it absolutely necessary to follow a recipe-specific task function with an 
"addtask"?  Based on experience from "real" object-oriented languages, a naive 
observer (like me) would guess the simple presence of "do_fetch()" in the 
recipe is all that's necessary.  Or is it the "addtask" that actually "slots" 
the new function in?

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCHv2 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration

[Darren Hart]

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.

OK, this explains the change to vmalloc.

Why the change of vga=current and the drop of video=vesafb ?

--
Darren

> 
> 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.conf
> index 40dbd1d..f02615e 100644
> --- a/meta-crownbay/conf/machine/crownbay.conf
> +++ b/meta-crownbay/conf/machine/crownbay.conf
> @@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
>  PREFERRED_VERSION_mesa-dri ?= "7.11"
>  PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
>  
> -APPEND += "video=vesafb vga=0x318"
> +APPEND += "vga=current vmalloc=256MB"
>  
>  VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
>   "commercial", "gst-va-intel va-intel", "va-intel", d)}"
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 0/1] meta-intel misc commits

[Kamble, Nitin A]

> -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 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?

I have seen once the EMGD kernel driver throwing unable to allocate the memory 
errors while playing a video file. I guess the issue is scratched only in 
shortage of memory conditions.

Nitin
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCHv2 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration

[nitin . a . kamble]

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/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.conf
index 40dbd1d..f02615e 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
 PREFERRED_VERSION_mesa-dri ?= "7.11"
 PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
 
-APPEND += "video=vesafb vga=0x318"
+APPEND += "vga=current vmalloc=256MB"
 
 VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
"commercial", "gst-va-intel va-intel", "va-intel", d)}"
-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCHv2 0/1] meta-intel misc pull request

[nitin . a . kamble]

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.yoctoproject.org/meta-intel-contrib nitin/misc
  http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc

Nitin A Kamble (1):
  crownbay.conf: add kernel parameters for EMGD video acceleration

 meta-crownbay/conf/machine/crownbay.conf |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 0/1] meta-intel misc commits

[Darren Hart]

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:
> Darren,
>The EMGD user guide is attached for reference.
> Thanks,
> Nitin
> 
> 
>> -Original Message-
>> From: Kamble, Nitin A
>> Sent: Thursday, October 04, 2012 1:17 PM
>> To: Hart, Darren; Zanussi, Tom; yocto@yoctoproject.org
>> Cc: Kamble, Nitin A
>> Subject: [PATCH 0/1] meta-intel misc commits
>>
>> 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 noemgd BSPs)
>>
>> 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.yoctoproject.org/meta-intel-contrib nitin/misc
>>   http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc
>>
>> Nitin A Kamble (1):
>>   crownbay.conf: add kernel parameters for EMGD video acceleration
>>
>>  meta-crownbay/conf/machine/crownbay.conf |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> --
>> 1.7.3.4

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Evade Flow]

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 let me know...


On Thu, Oct 4, 2012 at 2:58 PM, Rudolf Streif  wrote:
> [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.0. I would think it works with newer versions too
> although I have not tested it. This is the layout I am using:
>
> bbtest/
> ├── conf
> │   ├── bblayers.conf
> │   └── bitbake.conf
> ├── downloads
> │   └── /* need to create but will be populated with downloads */
> ├── meta-test
> │   ├── classes
> │   │   └── base.bbclass
> │   ├── conf
> │   │   └── layer.conf
> │   └── recipes-test
> │   └── nano
> │ └── nano.bb
> └── tmp
> └── /* will be created and populated when building */
>
> The first thing Bitbake looks for is a conf/bblayers.conf file in the
> directory you started it from. This file must provide an initial setting for
> BBPATH:
>
> bblayers.conf:
>
> BBPATH := "${TOPDIR}"
> BBFILES ?= ""
> BBLAYERS = " \
>   ${TOPDIR}/meta-test \
>   "
>
> Without BBPATH Bitbake will not find any conf/.conf files and
> recipe files at all. It will also not find bitbake.conf. I simply copied
> bitbake.conf from the Bitbake download and edited DL_DIR:
>
> bitbake.conf:
>
> # comments omitted
> B = "${S}"
> CVSDIR = "${DL_DIR}/cvs"
> DEPENDS = ""
> DEPLOY_DIR = "${TMPDIR}/deploy"
> DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images"
> DL_DIR = "${TOPDIR}/downloads"
> FETCHCOMMAND = ""
> FETCHCOMMAND_cvs = "/usr/bin/env cvs -d${CVSROOT} co ${CVSCOOPTS}
> ${CVSMODULE}"
> FETCHCOMMAND_svn = "/usr/bin/env svn co ${SVNCOOPTS} ${SVNROOT}
> ${SVNMODULE}"
> FETCHCOMMAND_wget = "/usr/bin/env wget -t 5 --passive-ftp -P ${DL_DIR}
> ${URI}"
> FILESDIR = "${@bb.utils.which(bb.data.getVar('FILESPATH', d, 1), '.')}"
> FILESPATH =
> "${FILE_DIRNAME}/${PF}:${FILE_DIRNAME}/${P}:${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}"
> FILE_DIRNAME = "${@os.path.dirname(bb.data.getVar('FILE', d))}"
> GITDIR = "${DL_DIR}/git"
> IMAGE_CMD = "_NO_DEFINED_IMAGE_TYPES_"
> IMAGE_ROOTFS = "${TMPDIR}/rootfs"
> MKTEMPCMD = "mktemp -q ${TMPBASE}"
> MKTEMPDIRCMD = "mktemp -d -q ${TMPBASE}"
> OVERRIDES = "local:${MACHINE}:${TARGET_OS}:${TARGET_ARCH}"
> P = "${PN}-${PV}"
> PERSISTENT_DIR = "${TMPDIR}/cache"
> PF = "${PN}-${PV}-${PR}"
> PN = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[0] or
> 'defaultpkgname'}"
> PR = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[2] or
> 'r0'}"
> PROVIDES = ""
> PV = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[1] or
> '1.0'}"
> RESUMECOMMAND = ""
> RESUMECOMMAND_wget = "/usr/bin/env wget -c -t 5 --passive-ftp -P ${DL_DIR}
> ${URI}"
> S = "${WORKDIR}/${P}"
> SRC_URI = "file://${FILE}"
> STAMP = "${TMPDIR}/stamps/${PF}"
> SVNDIR = "${DL_DIR}/svn"
> T = "${WORKDIR}/temp"
> TARGET_ARCH = "${BUILD_ARCH}"
> TMPDIR = "${TOPDIR}/tmp"
> UPDATECOMMAND = ""
> UPDATECOMMAND_cvs = "/usr/bin/env cvs -d${CVSROOT} update ${CVSCOOPTS}"
> UPDATECOMMAND_svn = "/usr/bin/env svn update ${SVNCOOPTS}"
> WORKDIR = "${TMPDIR}/work/${PF}"
> PERSISTENT_DIR = "${TMPDIR}/cache"
>
> That's more than you need but it's convenient.
>
> Bitbake will require a base.bbclass file somewhere in a classes subdirectory
> of BBPATH. I used the base.bbclass file from the Bitbake download. As a
> minimum it should contain a do_build task. That's the target that Bitbake
> invokes by default if you do not use the -c option explicitly. It's empty
> and does not do anything but it functions as an anchor for tasks you define
> in your recipes:
>
> base.bbclass:
>
> # comments omitted
> die() {
> bbfatal "$*"
> }
>
> bbnote() {
> echo "NOTE:" "$*"
> }
>
> bbwarn() {
> echo "WARNING:" "$*"
> }
>
> bbfatal() {
> echo "FATAL:" "$*"
> exit 1
> }
>
> addtask showdata
> do_showdata[nostamp] = "1"
> python do_showdata() {
> import sys
> # emit variables and shell functions
> bb.data.emit_env(sys.__stdout__, d, True)
> # emit the metadata which isnt valid shell
> for e in bb.data.keys(d):
> if bb.data.getVarFlag(e, 'python', d):
> sys.__stdout__.write("\npython %s () {\n%s}\n" % (e,
> bb.data.getVar(e, d, 1)))
> }
>
> addtask listtasks
> do_listtasks[nostamp] = "1"
> python do_listtasks() {
> import sys
> for e in bb.data.keys(d):
> if bb.data.getVarFlag(e, 'task', d):
> sys.__stdout__.write("%s\n" % e)
> }
>
> addtask build
> do_build[dirs] = "${TOPDI

Re: [yocto] [PATCH 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration

[Darren Hart]

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 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta-crownbay/conf/machine/crownbay.conf 
> b/meta-crownbay/conf/machine/crownbay.conf
> index 40dbd1d..f02615e 100644
> --- a/meta-crownbay/conf/machine/crownbay.conf
> +++ b/meta-crownbay/conf/machine/crownbay.conf
> @@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
>  PREFERRED_VERSION_mesa-dri ?= "7.11"
>  PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
>  
> -APPEND += "video=vesafb vga=0x318"
> +APPEND += "vga=current vmalloc=256MB"
>  
>  VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
>   "commercial", "gst-va-intel va-intel", "va-intel", d)}"
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Rudolf Streif]

>
> 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@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Khem Raj]

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 to fix here
but now you have blown up you cache :)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration

[nitin . a . kamble]

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.conf
index 40dbd1d..f02615e 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
 PREFERRED_VERSION_mesa-dri ?= "7.11"
 PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
 
-APPEND += "video=vesafb vga=0x318"
+APPEND += "vga=current vmalloc=256MB"
 
 VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
"commercial", "gst-va-intel va-intel", "va-intel", d)}"
-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/1] meta-intel misc commits

[nitin . a . kamble]

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 noemgd BSPs)

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.yoctoproject.org/meta-intel-contrib nitin/misc
  http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc

Nitin A Kamble (1):
  crownbay.conf: add kernel parameters for EMGD video acceleration

 meta-crownbay/conf/machine/crownbay.conf |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] log

[Jim Abernathy]

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+snapshot-20121004"
TUNE_FEATURES = "m32 core2"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:ee76b805f96f00aec386a1c34d176eea7d66f526"
meta-intel
meta-crownbay = "master:c4a86a2ad5df3a94b47e394090f67f7e324b1483"
meta-jfa  = ":"


My bad.  meant to send this to my other computer.

Jim A
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] log

[Jim Abernathy]

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 = "m32 core2"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:ee76b805f96f00aec386a1c34d176eea7d66f526"
meta-intel
meta-crownbay = "master:c4a86a2ad5df3a94b47e394090f67f7e324b1483"
meta-jfa  = ":"

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Rudolf Streif]

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 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 PR bumps only of packages in my feed
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029759.html
>
> > 2. If 1. won't work, recompile libowl si libclutter as a workaround.
>
> wont fix it on target
>
> Cheers,
>
> >
> > ag
> >  On Oct 4, 2012 4:40 AM, "Rudolf Streif" 
> wrote:
> >
> > > No, nothing extra. But you are right about the number of tasks. I
> checked
> > > out master a while ago, built successfully back then, now pulled the
> latest
> > > today, and reused the build environment. I will try again with a fresh
> > > environment.
> > >
> > > :rjs
> > > On Oct 3, 2012 6:35 PM, "Saul Wold"  wrote:
> > >
> > >> On 10/03/2012 04:21 PM, Rudolf Streif wrote:
> > >>
> > >>> I checked out Poky from Master and tried to build core-image-minimal.
> > >>> do_rootfs failed on the libffi dependency [1]. Is that
> known/expected?
> > >>>
> > >>>  This is interesting, I just tried it also, and it is working, see
> below.
> > >>
> > >>
> > >>  :rjs
> > >>>
> > >>> 
> > >>>
> > >>> [1]
> > >>>
> > >>> bitbake core-image-minimal
> > >>> Loading cache: 100%
> > >>> |#**##**
> > >>> #|
> > >>> ETA:  00:00:00
> > >>> Loaded 1131 entries from dependency cache.
> > >>>
> > >>> Build Configuration:
> > >>> BB_VERSION= "1.16.0"
> > >>> TARGET_ARCH   = "i586"
> > >>> TARGET_OS = "linux"
> > >>> MACHINE   = "qemux86"
> > >>> DISTRO= "poky"
> > >>> DISTRO_VERSION= "1.2+snapshot-20121003"
> > >>> TUNE_FEATURES = "m32 i586"
> > >>> TARGET_FPU= ""
> > >>> meta
> > >>> meta-yocto
> > >>> meta-yocto-bsp= "master:**09aaad16be178bd675750aa6cfe7a3**
> > >>> 73d7c9a8a6"
> > >>>
> > >>> NOTE: Resolving any missing task queue dependencies
> > >>> NOTE: Preparing runqueue
> > >>> NOTE: Executing SetScene Tasks
> > >>> NOTE: Executing RunQueue Tasks
> > >>> ERROR: Function failed: do_rootfs (see
> > >>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
> > >>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
> > >>> for further information)
> > >>> ERROR: Logfile of failure stored in:
> > >>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
> > >>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
> > >>> Log data follows:
> > >>> | DEBUG: Executing shell function do_rootfs
> > >>> | Generating solve db for
> > >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/qemux86...
> > >>> | Generating solve db for
> > >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/i586...
> > >>> | Generating solve db for
> > >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
> > >>> | Generating solve db for
> > >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
> > >>> | Processing packagegroup-core-tools-**profile...
> > >>> | Processing packagegroup-core-boot...
> > >>> | Processing packagegroup-core-tools-**testapps...
> > >>> | Processing packagegroup-core-tools-debug.**..
> > >>> | error: Failed dependencies:
> > >>> |   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
> > >>> |   libffi.so.5 is needed by
> > >>> clutter-box2d-0.12.1+git1+**de5452e56b537a11fd7f9453d048ff**
> > >>> 4b4793b5a2-r1.qemux86
> > >>> |   libffi.so.5 is needed by
> > >>>
> libowl-av0-0.1+git1+**03030c41ea578cfa74a2ffceb87567**5b248318ae-r3.i586
> > >>> |   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.**i586
> > >>> | ERROR: Function failed: do_rootfs (see
> > >>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
> > >>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
> > >>> for further information)
> > >>> ERROR: Task 7
> > >>> (/data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
> > >>> core-image-minimal.bb 
> > >>> **, do_rootfs) failed with exit code
> '1'
> > >>> NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need
> to
> > >>> be rerun and 1 failed.
> > >>> No currently running tasks (3890 of 3892)
> > >>>
> > >>>  The number of tasks and including lttng-viewer and clutter seems to
> be
> > >> lartger than core-image-minimal, do you have anything in the
> local.conf?
> > >>
> > >> Sau!
> > >>
> > >>  Summary: 1 task failed:
> > >>>
> > >>> /data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
> > >>> core-image-minimal.bb 
> > >>> 

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Rudolf Streif]

[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.0. I would think it works with newer versions too
although I have not tested it. This is the layout I am using:

bbtest/
├── conf
│   ├── bblayers.conf
│   └── bitbake.conf
├── downloads
│   └── /* need to create but will be populated with downloads */
├── meta-test
│   ├── classes
│   │   └── base.bbclass
│   ├── conf

│   │   └── layer.conf

│   └── recipes-test

│   └── nano

│ └── nano.bb

└── tmp

└── /* will be created and populated when building */

The first thing Bitbake looks for is a conf/bblayers.conf file in the
directory you started it from. This file must provide an initial setting
for BBPATH:

bblayers.conf:

BBPATH := "${TOPDIR}"
BBFILES ?= ""
BBLAYERS = " \
  ${TOPDIR}/meta-test \
  "

Without BBPATH Bitbake will not find any conf/.conf files and
recipe files at all. It will also not find bitbake.conf. I simply copied
bitbake.conf from the Bitbake download and edited DL_DIR:

bitbake.conf:

# comments omitted
B = "${S}"

CVSDIR = "${DL_DIR}/cvs"

DEPENDS = ""

DEPLOY_DIR = "${TMPDIR}/deploy"
DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images"
DL_DIR = "${TOPDIR}/downloads"
FETCHCOMMAND = ""
FETCHCOMMAND_cvs = "/usr/bin/env cvs -d${CVSROOT} co ${CVSCOOPTS}
${CVSMODULE}"
FETCHCOMMAND_svn = "/usr/bin/env svn co ${SVNCOOPTS} ${SVNROOT}
${SVNMODULE}"
FETCHCOMMAND_wget = "/usr/bin/env wget -t 5 --passive-ftp -P ${DL_DIR}
${URI}"
FILESDIR = "${@bb.utils.which(bb.data.getVar('FILESPATH', d, 1), '.')}"
FILESPATH =
"${FILE_DIRNAME}/${PF}:${FILE_DIRNAME}/${P}:${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}"
FILE_DIRNAME = "${@os.path.dirname(bb.data.getVar('FILE', d))}"
GITDIR = "${DL_DIR}/git"
IMAGE_CMD = "_NO_DEFINED_IMAGE_TYPES_"
IMAGE_ROOTFS = "${TMPDIR}/rootfs"
MKTEMPCMD = "mktemp -q ${TMPBASE}"
MKTEMPDIRCMD = "mktemp -d -q ${TMPBASE}"
OVERRIDES = "local:${MACHINE}:${TARGET_OS}:${TARGET_ARCH}"
P = "${PN}-${PV}"
PERSISTENT_DIR = "${TMPDIR}/cache"
PF = "${PN}-${PV}-${PR}"
PN = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[0]
or 'defaultpkgname'}"
PR = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[2]
or 'r0'}"
PROVIDES = ""
PV = "${@bb.parse.BBHandler.vars_from_file(bb.data.getVar('FILE',d),d)[1]
or '1.0'}"
RESUMECOMMAND = ""
RESUMECOMMAND_wget = "/usr/bin/env wget -c -t 5 --passive-ftp -P ${DL_DIR}
${URI}"
S = "${WORKDIR}/${P}"
SRC_URI = "file://${FILE}"
STAMP = "${TMPDIR}/stamps/${PF}"
SVNDIR = "${DL_DIR}/svn"
T = "${WORKDIR}/temp"
TARGET_ARCH = "${BUILD_ARCH}"
TMPDIR = "${TOPDIR}/tmp"
UPDATECOMMAND = ""
UPDATECOMMAND_cvs = "/usr/bin/env cvs -d${CVSROOT} update ${CVSCOOPTS}"
UPDATECOMMAND_svn = "/usr/bin/env svn update ${SVNCOOPTS}"
WORKDIR = "${TMPDIR}/work/${PF}"
PERSISTENT_DIR = "${TMPDIR}/cache"

That's more than you need but it's convenient.

Bitbake will require a base.bbclass file somewhere in a classes
subdirectory of BBPATH. I used the base.bbclass file from the Bitbake
download. As a minimum it should contain a do_build task. That's the target
that Bitbake invokes by default if you do not use the -c option explicitly.
It's empty and does not do anything but it functions as an anchor for tasks
you define in your recipes:

base.bbclass:

# comments omitted
die() {
bbfatal "$*"
}

bbnote() {
echo "NOTE:" "$*"
}

bbwarn() {
echo "WARNING:" "$*"
}

bbfatal() {
echo "FATAL:" "$*"
exit 1
}

addtask showdata
do_showdata[nostamp] = "1"
python do_showdata() {
import sys
# emit variables and shell functions
bb.data.emit_env(sys.__stdout__, d, True)
# emit the metadata which isnt valid shell
for e in bb.data.keys(d):
if bb.data.getVarFlag(e, 'python', d):
sys.__stdout__.write("\npython %s () {\n%s}\n" %
(e, bb.data.getVar(e, d, 1)))
}

addtask listtasks
do_listtasks[nostamp] = "1"
python do_listtasks() {
import sys
for e in bb.data.keys(d):
if bb.data.getVarFlag(e, 'task', d):
sys.__stdout__.write("%s\n" % e)
}

addtask build
do_build[dirs] = "${TOPDIR}"
do_build[nostamp] = "1"
python base_do_build () {
bb.note("The included, default BB base.bbclass does not define a
useful default task.")
bb.note("Try running the 'listtasks' task against a .bb to see what
tasks are defined.")
}

EXPORT_FUNCTIONS do_clean do_mrproper do_build

Again, it's more than you need. It's just convenient to use it. I put this
file inside the layer but you can also create a classes directory in
${TOPDIR} (bbtest in this example). Next, create a layer (meta-bbtest in my
example, name does not matter, meta-* is convention). It needs a
conf/layer.con file:

layer.conf:

# We have a metad

[yocto] Building crownbay from master

[Jim Abernathy]

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 
2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7

NOTE: preferred version 7.11 of mesa-dri not available (for item mesa-dri)
NOTE: versions of mesa-dri available: 2:8.0.4 
2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7
NOTE: preferred version 7.11 of mesa-dri not available (for item 
mesa-dri-dev)
NOTE: versions of mesa-dri available: 2:8.0.4 
2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7

NOTE: preferred version 7.11 of mesa-dri not available (for item mesa-dri)
NOTE: versions of mesa-dri available: 2:8.0.4 
2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7



WARNING: bzip2: No generic license file exists for: bzip2 in any provider
WARNING: bzip2-native: No generic license file exists for: bzip2 in any 
provider
WARNING: emgd-driver-bin: No generic license file exists for: 
Intel-binary-only in any provider

WARNING: busybox: No generic license file exists for: bzip2 in any provider

Also a number of warning about the recipe trying to install files into a 
shared area when those files already existed.


Jim A

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends

[Paul Eggleton]

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 the same.
> 
> [YOCTO #3217]
> 
> Signed-off-by: Mihai Lindner 
> ---
>  meta-tlk/recipes-kernel/linux/linux-yocto.inc  | 3 +++
>  meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +--
>  meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +--
>  meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +--
>  4 files changed, 6 insertions(+), 18 deletions(-)
>  create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc
> 
> diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto.inc
> b/meta-tlk/recipes-kernel/linux/linux-yocto.inc new file mode 100644
> index 000..96a3adf
> --- /dev/null
> +++ b/meta-tlk/recipes-kernel/linux/linux-yocto.inc
> @@ -0,0 +1,3 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +SRC_URI_append += "file://time-limited-kernel.cfg"

You should use SRC_URI_append = " file://time-limited-kernel.cfg" (note leading 
space) here. Obviously what you have done does work, but we want to avoid 
_append += as it can be confusing.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends

[Mihai Lindner]

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-kernel/linux/linux-yocto.inc  | 3 +++
 meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +--
 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +--
 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +--
 4 files changed, 6 insertions(+), 18 deletions(-)
 create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc

diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto.inc 
b/meta-tlk/recipes-kernel/linux/linux-yocto.inc
new file mode 100644
index 000..96a3adf
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+SRC_URI_append += "file://time-limited-kernel.cfg"
+PR .= ".2"
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend 
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 138cc21..bd54419 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-# enable the time limited kernel configuration options
-SRC_URI += "file://time-limited-kernel.cfg"
-
-PR .= ".1"
+require ${PN}.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend 
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
index 138cc21..bd54419 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-# enable the time limited kernel configuration options
-SRC_URI += "file://time-limited-kernel.cfg"
-
-PR .= ".1"
+require ${PN}.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend 
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
index 138cc21..bd54419 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-# enable the time limited kernel configuration options
-SRC_URI += "file://time-limited-kernel.cfg"
-
-PR .= ".1"
+require ${PN}.inc
-- 
1.7.12

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/1] meta-tlk: fix ignored SRC_URI appends

[Mihai Lindner]

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 changes since commit c4a86a2ad5df3a94b47e394090f67f7e324b1483:

  meta-crystalforest: Create a custom build Image recipe. (2012-10-03 23:56:13 
-0500)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib mihai/bug3217
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mihai/bug3217

Mihai Lindner (1):
  meta-tlk: fix ignored SRC_URI appends

 meta-tlk/recipes-kernel/linux/linux-yocto.inc  | 3 +++
 meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +--
 meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +--
 meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +--
 4 files changed, 6 insertions(+), 18 deletions(-)
 create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc

-- 
1.7.12

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Patrick Turley]

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 and a very basic recipe 
to build the Nano editor (including download from the project site).

You need to have a couple of things in place to make this work. I got to run 
but I will get back to it and post it.

:rjs

On Wed, Oct 3, 2012 at 3:56 PM, Patrick Turley 
mailto:patricktur...@gamestop.com>> wrote:
In my previous message, some of the indentation in the representation of
my file tree was wrong (because we're using Outlook, which destroy all
indentation when you paste it into an e-mail message). The errors are
small, but I want to avoid annoying anyone who might think I don't even
have the file tree constructed correctly.

The following is accurate:

>/home/pturley/Workspace/woohoo
>|
>+-- build
>|   |
>|   +-- classes
>|   |   |
>|   |   +-- base.bbclass
>|   |
>|   | +---
>|   | | do_hello() {
>|   | | echo Hello
>|   | | }
>|   | |
>|   | | addtask hello
>|   | +---
>|   |
>|   +-- conf
>|   |
>|   +-- bblayers.conf
>|   |
>|   | +---
>|   | | BBLAYERS ?= " \
>|   | |   /home/pturley/Workspace/woohoo/LayerA \
>|   | |   "
>|   | +---
>|   |
>|   +-- bitbake.conf
>|
>| +---
>| | CACHE = "${TOPDIR}/cache"
>| +---
>|
>+-- LayerA
>|   |
>|   +-- a.bb
>|   |
>|   | +---
>|   | | PN = 'a'
>|   | | PV = '1'
>|   | +---
>|   |
>|   +-- conf
>|   |
>|   +-- layer.conf
>|
>| +---
>| | BBPATH .= ":${LAYERDIR}"
>| | BBFILES += "${LAYERDIR}/*.bb"
>| +---
>|
>+-- BitBake ...
>
>The BitBake directory origin is:
>
>http://git.openembedded.org/bitbake/
>
>I have the 1.15.2 tag checked out, which is what
>Yocto denzil uses.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 1/1] opkg-make-index: fix mis-indented else:

[Martin Jansa]

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:
 (h,t) = os.path.split(fn)
 if not t: continue
 if t not in files: files[t] = name+':'+fn
-else: files[t] = files[t] + ',' + name+':'+fn
+else: files[t] = files[t] + ',' + name+':'+fn
 
 tmp_filelist_filename = ("%s.%d" % (filelist_filename, os.getpid()))
 f = open(tmp_filelist_filename, "w")
-- 
1.7.12

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 0/1] opkg-make-index: small fix for filelist

[Martin Jansa]

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/shr-project/opkg-utils/tree/jansa/pull

Marc Olzheim (1):
  opkg-make-index: fix mis-indented else:

 opkg-make-index | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.7.12

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFCv2 3/3] plugins/sdk.ide.doc.user: Added cheat sheet for hello world project

[Atanas Gegov]

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
finally building the project.
---
 .../META-INF/MANIFEST.MF   |1 +
 .../OSGI-INF/l10n/bundle.properties|4 +
 .../org.yocto.sdk.ide.doc.user/build.properties|4 +-
 .../cheatsheets/createNewHelloWorldProject.xml |  222 
 plugins/org.yocto.sdk.ide.doc.user/plugin.xml  |9 +
 5 files changed, 239 insertions(+), 1 deletions(-)
 create mode 100644 
plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml

diff --git a/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF 
b/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
index 1c8ae05..87079ce 100644
--- a/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
@@ -5,3 +5,4 @@ Bundle-SymbolicName: org.yocto.sdk.ide.doc.user;singleton:=true
 Bundle-Version: 1.2.0.qualifier
 Bundle-Vendor: %Bundle-Vendor
 Bundle-RequiredExecutionEnvironment: JavaSE-1.6
+Require-Bundle: org.eclipse.ui.cheatsheets
diff --git a/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties 
b/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
index 99f8fce..2cf9956 100644
--- a/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
@@ -1,3 +1,7 @@
 #Properties file for org.yocto.sdk.ide.doc.user
 Bundle-Vendor = yoctoproject.org
 Bundle-Name = Yocto User Help
+
+category.name = Yocto Project
+
+cheatsheet.name = Creating a Hello World ANSI C or C++ Autotools Project
diff --git a/plugins/org.yocto.sdk.ide.doc.user/build.properties 
b/plugins/org.yocto.sdk.ide.doc.user/build.properties
index 31e0140..caf850b 100644
--- a/plugins/org.yocto.sdk.ide.doc.user/build.properties
+++ b/plugins/org.yocto.sdk.ide.doc.user/build.properties
@@ -1,4 +1,6 @@
 bin.includes = plugin.xml,\
.,\
META-INF/,\
-   OSGI-INF/
+   OSGI-INF/,\
+   cheatsheets/
+src.includes = cheatsheets/
diff --git 
a/plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml 
b/plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml
new file mode 100644
index 000..310dce6
--- /dev/null
+++ 
b/plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml
@@ -0,0 +1,222 @@
+
+
+
+   
+   
+   This cheat sheet will guide you through the process of 
creating and
+   building a "Hello World ANSI C Autotools 
Project" or
+   a "Hello World C++ Autotools Project"
+   application that uses a Yocto Project template.
+   
+   
+   
+   
+   Select Window > Open Perspective >
+   Other... from the menu bar.
+   Choose C/C++ from the Open Perspective 
dialog.
+   Click OK.
+   
+   
+   
+   
+   
+   
+   You need to specify a toolchain and sysroot location 
before
+   building any project in the workspace.
+   
+   
+   
+   The global settings can be modified in the Yocto 
Project ADT
+   section of the eclipse preferences. Select 
Window >
+   Preferences from the menu bar and then select 
the section
+   Yocto Project ADT. These settings are the 
default ones for
+   every project you create in the workspace.
+   
+   
+   
+   
+   
+   
+   Choose in the Cross Compiler Options the
+   Standalone pre-built toolchain.
+   
+   
+   
+   
+   Provide a Toolchain Root Location (e.g.
+   /opt/poky/1.3 or some other location on the filesystem).
+   
+   
+   
+   
+   Provide a Sysroot Location. This is the 
filesystem
+   containing libraries, headers etc. used while 
cross-building
+   binaries for the target.
+   
+   
+   
+   
+   If more than one toolchain is found in the Toolchain
+   Root Location, use the drop-down box to s

[yocto] [RFCv2 0/3] [eclipse-poky] Cheat sheet for hello world project

[Atanas Gegov]

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++ Autotools Project" and the "Hello World ANSI C 
Project". The user can now choose its preferred programming language and the 
cheat sheet adapts itself accordingly. I also took into account that the SDK is 
now relocatable. 

The patches apply both on the "master" and on the "master-indigo" branches.

Cheers,
Atanas

Atanas Gegov (3):
  plugins/sdk.ide.doc.user: Added plugin for ide specific user help
  feature/sdk: Added user doc plugin
  plugins/sdk.ide.doc.user: Added cheat sheet for hello world project

 features/org.yocto.sdk/feature.xml |8 +
 plugins/org.yocto.sdk.ide.doc.user/.classpath  |6 +
 plugins/org.yocto.sdk.ide.doc.user/.project|   28 +++
 .../.settings/org.eclipse.jdt.core.prefs   |8 +
 .../META-INF/MANIFEST.MF   |8 +
 .../OSGI-INF/l10n/bundle.properties|7 +
 .../org.yocto.sdk.ide.doc.user/build.properties|6 +
 .../cheatsheets/createNewHelloWorldProject.xml |  222 
 plugins/org.yocto.sdk.ide.doc.user/plugin.xml  |   13 ++
 9 files changed, 306 insertions(+), 0 deletions(-)
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.classpath
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.project
 create mode 100644 
plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
 create mode 100644 
plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/build.properties
 create mode 100644 
plugins/org.yocto.sdk.ide.doc.user/cheatsheets/createNewHelloWorldProject.xml
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/plugin.xml

-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFCv2 1/3] plugins/sdk.ide.doc.user: Added plugin for ide specific user help

[Atanas Gegov]

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 
 .../.settings/org.eclipse.jdt.core.prefs   |8 +
 .../META-INF/MANIFEST.MF   |7 +
 .../OSGI-INF/l10n/bundle.properties|3 ++
 .../org.yocto.sdk.ide.doc.user/build.properties|4 +++
 plugins/org.yocto.sdk.ide.doc.user/plugin.xml  |4 +++
 7 files changed, 60 insertions(+), 0 deletions(-)
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.classpath
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/.project
 create mode 100644 
plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
 create mode 100644 
plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/build.properties
 create mode 100644 plugins/org.yocto.sdk.ide.doc.user/plugin.xml

diff --git a/plugins/org.yocto.sdk.ide.doc.user/.classpath 
b/plugins/org.yocto.sdk.ide.doc.user/.classpath
new file mode 100644
index 000..bc74aab
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/.classpath
@@ -0,0 +1,6 @@
+
+
+   
+   
+   
+
diff --git a/plugins/org.yocto.sdk.ide.doc.user/.project 
b/plugins/org.yocto.sdk.ide.doc.user/.project
new file mode 100644
index 000..ccc3e39
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/.project
@@ -0,0 +1,28 @@
+
+
+   org.yocto.sdk.ide.doc.user
+   
+   
+   
+   
+   
+   org.eclipse.jdt.core.javabuilder
+   
+   
+   
+   
+   org.eclipse.pde.ManifestBuilder
+   
+   
+   
+   
+   org.eclipse.pde.SchemaBuilder
+   
+   
+   
+   
+   
+   org.eclipse.pde.PluginNature
+   org.eclipse.jdt.core.javanature
+   
+
diff --git 
a/plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs 
b/plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs
new file mode 100644
index 000..f90fa9c
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/.settings/org.eclipse.jdt.core.prefs
@@ -0,0 +1,8 @@
+#Fri Mar 04 13:59:33 CET 2011
+eclipse.preferences.version=1
+org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
+org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.6
+org.eclipse.jdt.core.compiler.compliance=1.6
+org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
+org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
+org.eclipse.jdt.core.compiler.source=1.6
diff --git a/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF 
b/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
new file mode 100644
index 000..1c8ae05
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/META-INF/MANIFEST.MF
@@ -0,0 +1,7 @@
+XFManifest-Version: 1.0
+Bundle-ManifestVersion: 2
+Bundle-Name: %Bundle-Name
+Bundle-SymbolicName: org.yocto.sdk.ide.doc.user;singleton:=true
+Bundle-Version: 1.2.0.qualifier
+Bundle-Vendor: %Bundle-Vendor
+Bundle-RequiredExecutionEnvironment: JavaSE-1.6
diff --git a/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties 
b/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
new file mode 100644
index 000..99f8fce
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/OSGI-INF/l10n/bundle.properties
@@ -0,0 +1,3 @@
+#Properties file for org.yocto.sdk.ide.doc.user
+Bundle-Vendor = yoctoproject.org
+Bundle-Name = Yocto User Help
diff --git a/plugins/org.yocto.sdk.ide.doc.user/build.properties 
b/plugins/org.yocto.sdk.ide.doc.user/build.properties
new file mode 100644
index 000..31e0140
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/build.properties
@@ -0,0 +1,4 @@
+bin.includes = plugin.xml,\
+   .,\
+   META-INF/,\
+   OSGI-INF/
diff --git a/plugins/org.yocto.sdk.ide.doc.user/plugin.xml 
b/plugins/org.yocto.sdk.ide.doc.user/plugin.xml
new file mode 100644
index 000..f422d55
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide.doc.user/plugin.xml
@@ -0,0 +1,4 @@
+
+
+
+
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFCv2 2/3] feature/sdk: Added user doc plugin

[Atanas Gegov]

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.xml 
b/features/org.yocto.sdk/feature.xml
index 785a7be..e82cec2 100644
--- a/features/org.yocto.sdk/feature.xml
+++ b/features/org.yocto.sdk/feature.xml
@@ -8,6 +8,7 @@

 Contributors:
 Intel - initial API and implementation
+BMW Car IT - added user documentation plugin to the feature
  -->
 
 
+   
+
 
-- 
1.7.5.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python-installation on target (qemuppc) image ....

[Gary Thomas]

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'-module isn't available.  I need the 'shutil' module on my image but 
I can't figure out how to achive
that.  Python seems to work on the target but it seems to lack lots of standard 
functionality.
The shutil.py & shutil.pyo exists in 
.../build/tmp/work/ppc603e-poky-linux/python-2.7.3-r0.2/package/usr/lib/python2.7 
folder but it doesn't exist on the target image...
Also, in /deploy-rpms/ppc603e/python-shell-2.7.3-r0.2.ppc603e.rpm, the 
shutil-files exist ...
Somehow, it seems as if this rpm isn't installed on my target-image, what 
controls that?
Examining the log.do_package-file shows ~5700 lines of "error: Couldn't exec 
/sysroot//*x86_64-linux*//usr/lib/rpm/pythoneggs.py: No such file or directory" 
(shouldn't it be
qemupcc??) from function package_do_filedeps.
Examining the log.do_populate_sysroot-file shows "WARNING: The recipe is trying 
to install files into a shared area when those files already exist. Those files are: 
pyconfig.h,
libpython2.7.so, libpython2.7.so.1.0 and Makefile" 


Python packages are split up into functionality and you'll need
to install the pieces that you need.  Remember that these systems
are presumed to be [somewhat] small, embedded devices and there's
no sense to install what you will never use...

For example, you need to install 'python-distutils' to get the distutils module.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Python-installation on target (qemuppc) image ....

[Jonas Jonsson L]

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' module on my image but 
I can't figure out how to achive that.  Python seems to work on the target but 
it seems to lack lots of standard functionality.

The shutil.py & shutil.pyo exists in 
.../build/tmp/work/ppc603e-poky-linux/python-2.7.3-r0.2/package/usr/lib/python2.7
 folder but it doesn't exist on the target image...

Also, in /deploy-rpms/ppc603e/python-shell-2.7.3-r0.2.ppc603e.rpm, the 
shutil-files exist ...

Somehow, it seems as if this rpm isn't installed on my target-image, what 
controls that?

Examining the log.do_package-file shows ~5700 lines of "error: Couldn't exec 
/sysroot/x86_64-linux/usr/lib/rpm/pythoneggs.py: No such file or directory" 
(shouldn't it be qemupcc??) from function package_do_filedeps.

Examining the log.do_populate_sysroot-file shows "WARNING: The recipe is trying 
to install files into a shared area when those files already exist. Those files 
are: pyconfig.h, libpython2.7.so, libpython2.7.so.1.0 and Makefile" 

Best regards,

Jonas Jonsson

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eglibc fails to build

[Richard Purdie]

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 the error log returned by build is here ->
> http://pastebin.com/RNv5u8H8
>
> I think that only the last line are what matters the most. The only
> issue that I see is multiple reference (starts @ 241 line).
>  
> Before this I had problems with building elfutils but adding
> libc-ftraverse and libc-posix-clang-wchar to
> DISTRO_FEATURES_LIBC_DEFAULTS fixed this.
>  
> Is there anything that I can do with eglibc?

It sounds like those libc options you've added have some dependencies or
other configuration you're missing. I'm not sure what those are but it
definitely looks like an unsupported set of eglibc configuration options
combinations.

Cheers,

Richard


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] gypsy: removed dependencies in meta-yocto

[Andrei Dinu]

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.inc 
b/meta-yocto/conf/distro/include/maintainers.inc
index 38b6974..288557b 100644
--- a/meta-yocto/conf/distro/include/maintainers.inc
+++ b/meta-yocto/conf/distro/include/maintainers.inc
@@ -225,7 +225,6 @@ RECIPE_MAINTAINER_pn-guile = "Bogdan Marinescu 
"
 RECIPE_MAINTAINER_pn-gupnp = "Radu Moisan "
 RECIPE_MAINTAINER_pn-gupnp-av = "Cristian Iorga "
 RECIPE_MAINTAINER_pn-gupnp-tools = "Cristian Iorga "
-RECIPE_MAINTAINER_pn-gypsy = "Cristian Iorga "
 RECIPE_MAINTAINER_pn-gzip = "Scott Garman "
 RECIPE_MAINTAINER_pn-hal = "Saul Wold "
 RECIPE_MAINTAINER_pn-hal-info = "Saul Wold "
diff --git a/meta-yocto/conf/distro/include/poky-floating-revisions.inc 
b/meta-yocto/conf/distro/include/poky-floating-revisions.inc
index af8ef11..6f6ee90 100644
--- a/meta-yocto/conf/distro/include/poky-floating-revisions.inc
+++ b/meta-yocto/conf/distro/include/poky-floating-revisions.inc
@@ -45,7 +45,6 @@ SRCREV_pn-xvideo-tests ?= "${AUTOREV}"
 SRCREV_pn-clutter ?= "${AUTOREV}"
 SRCREV_pn-clutter-gst ?= "${AUTOREV}"
 SRCREV_pn-gaku ?= "${AUTOREV}"
-SRCREV_pn-gypsy ?= "${AUTOREV}"
 #SRCREV_pn-webkit-gtk ?= "${AUTOREV}"
 SRCREV_pn-aaina ?= "${AUTOREV}"
 SRCREV_pn-clutter-cairo ?= "${AUTOREV}"
-- 
1.7.9.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] eglibc fails to build

[Szankin, Maciej]

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 think that only the last line are what matters the most. The only issue that 
I see is multiple reference (starts @ 241 line).

Before this I had problems with building elfutils but adding libc-ftraverse and 
libc-posix-clang-wchar to DISTRO_FEATURES_LIBC_DEFAULTS fixed this.

Is there anything that I can do with eglibc?



Regards,
Maciej Szankin
+ 48 58 766 50 47
Intel Technology Poland Sp. z o.o.
ul. Slowackiego 173
80-298 Gdansk

-
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [danny] multilib ends up with multiple provider error for virtual/lib32-libintl

[Khem Raj]

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/recipes-core/eglibc/eglibc_2.16.bb
> virtual:multilib:lib32:/work/yocto/poky/meta/recipes-core/gettext/gettext_0.18.1.1.bb).

I think my problem is due to the fact that MULTILIBS var is used in
preferred_ml_updates ()
which is called upon ConfigParsed event

and I have been trying to use arch overrides to define MULTILIBS
variable to accommodate
it in distro.conf but at that point overrides are not evaluated yet
and hence when I do

MULTILIBS_x86-64 = "multilib:lib32"
MULTILIB ?= ""

in distro.conf, preferred_ml_updates () gets the value before
overrides which is ""
and hence it thinks there is no multilib and does not add to
MULTI_PROVIDER_WHITELIST

so essentially the recommended usage to have multilib defined in
distro.conf wont work
for more than one machine builds. To get it to work for more than 1
machine include conf/multilib.conf in desired machine.conf  and then


DEFAULTTUNE_virtclass-multilib-lib32 = "${MULTILIBARCH}"

# Currently we only support multilib on ppc64 and x86_64
MULTILIBARCH_x86-64 = "x86"
MULTILIBARCH_e5500-64b = "ppce5500"
MULTILIBARCH ?= ""

in distro.conf would make sure the right stuff happens.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[Martin Jansa]

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 PR bumps only of packages in my feed
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029759.html

> 2. If 1. won't work, recompile libowl si libclutter as a workaround.

wont fix it on target

Cheers,

> 
> ag
>  On Oct 4, 2012 4:40 AM, "Rudolf Streif"  wrote:
> 
> > No, nothing extra. But you are right about the number of tasks. I checked
> > out master a while ago, built successfully back then, now pulled the latest
> > today, and reused the build environment. I will try again with a fresh
> > environment.
> >
> > :rjs
> > On Oct 3, 2012 6:35 PM, "Saul Wold"  wrote:
> >
> >> On 10/03/2012 04:21 PM, Rudolf Streif wrote:
> >>
> >>> I checked out Poky from Master and tried to build core-image-minimal.
> >>> do_rootfs failed on the libffi dependency [1]. Is that known/expected?
> >>>
> >>>  This is interesting, I just tried it also, and it is working, see below.
> >>
> >>
> >>  :rjs
> >>>
> >>> 
> >>>
> >>> [1]
> >>>
> >>> bitbake core-image-minimal
> >>> Loading cache: 100%
> >>> |#**##**
> >>> #|
> >>> ETA:  00:00:00
> >>> Loaded 1131 entries from dependency cache.
> >>>
> >>> Build Configuration:
> >>> BB_VERSION= "1.16.0"
> >>> TARGET_ARCH   = "i586"
> >>> TARGET_OS = "linux"
> >>> MACHINE   = "qemux86"
> >>> DISTRO= "poky"
> >>> DISTRO_VERSION= "1.2+snapshot-20121003"
> >>> TUNE_FEATURES = "m32 i586"
> >>> TARGET_FPU= ""
> >>> meta
> >>> meta-yocto
> >>> meta-yocto-bsp= "master:**09aaad16be178bd675750aa6cfe7a3**
> >>> 73d7c9a8a6"
> >>>
> >>> NOTE: Resolving any missing task queue dependencies
> >>> NOTE: Preparing runqueue
> >>> NOTE: Executing SetScene Tasks
> >>> NOTE: Executing RunQueue Tasks
> >>> ERROR: Function failed: do_rootfs (see
> >>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
> >>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
> >>> for further information)
> >>> ERROR: Logfile of failure stored in:
> >>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
> >>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
> >>> Log data follows:
> >>> | DEBUG: Executing shell function do_rootfs
> >>> | Generating solve db for
> >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/qemux86...
> >>> | Generating solve db for
> >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/i586...
> >>> | Generating solve db for
> >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
> >>> | Generating solve db for
> >>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
> >>> | Processing packagegroup-core-tools-**profile...
> >>> | Processing packagegroup-core-boot...
> >>> | Processing packagegroup-core-tools-**testapps...
> >>> | Processing packagegroup-core-tools-debug.**..
> >>> | error: Failed dependencies:
> >>> |   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
> >>> |   libffi.so.5 is needed by
> >>> clutter-box2d-0.12.1+git1+**de5452e56b537a11fd7f9453d048ff**
> >>> 4b4793b5a2-r1.qemux86
> >>> |   libffi.so.5 is needed by
> >>> libowl-av0-0.1+git1+**03030c41ea578cfa74a2ffceb87567**5b248318ae-r3.i586
> >>> |   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.**i586
> >>> | ERROR: Function failed: do_rootfs (see
> >>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
> >>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
> >>> for further information)
> >>> ERROR: Task 7
> >>> (/data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
> >>> core-image-minimal.bb 
> >>> **, do_rootfs) failed with exit code '1'
> >>> NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need to
> >>> be rerun and 1 failed.
> >>> No currently running tasks (3890 of 3892)
> >>>
> >>>  The number of tasks and including lttng-viewer and clutter seems to be
> >> lartger than core-image-minimal, do you have anything in the local.conf?
> >>
> >> Sau!
> >>
> >>  Summary: 1 task failed:
> >>>
> >>> /data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
> >>> core-image-minimal.bb 
> >>> **, do_rootfs
> >>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> >>>
> >>>
> >>>
> >>> __**_
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.**org/listinfo/yocto
> >>>
> >>>
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yocto