Re: [yocto] [opkg-utils][PATCH 0/2] opkg-utils fix for python-2.6 and fix for missing getopts

[Martin Jansa]

On Sat, Jun 16, 2012 at 08:36:15AM +0200, Martin Jansa wrote:
> On Tue, May 29, 2012 at 05:34:13PM +0200, Martin Jansa wrote:
> > The following changes since commit 44df9dd3dc411ca1255cb4b23bde7eb71aed4778:
> > 
> >   opkg-make-index: disable filelist by default (2012-04-26 11:39:42 +0100)
> 
> ping?

Can I get push access to this repo, I know you're all busy but waiting
20+ days for small fixes to get applied is not very efficient. Another
guy on #oe asked today why package-index is always failing in oe-classic..

Cheers,
 
> > are available in the git repository at:
> >   git://github.com/shr-project/opkg-utils jansa/pull
> >   https://github.com/shr-project/opkg-utils/tree/jansa/pull
> > 
> > Chris Diamand (1):
> >   Changed call to subprocess.check_output which isn't compatible with
> > Python 2.6
> > 
> > Ondics Githubler (1):
> >   Option "C" ist shown in usage() and implemented, but was missing in
> > getopts. Added "C".
> > 
> >  opkg-build  |2 +-
> >  opkg-make-index |2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > -- 
> > 1.7.8.6
> > 
> 
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils][PATCH 0/2] opkg-utils fix for python-2.6 and fix for missing getopts

[Richard Purdie]

On Tue, 2012-05-29 at 17:34 +0200, Martin Jansa wrote:
> The following changes since commit 44df9dd3dc411ca1255cb4b23bde7eb71aed4778:
> 
>   opkg-make-index: disable filelist by default (2012-04-26 11:39:42 +0100)
> 
> are available in the git repository at:
>   git://github.com/shr-project/opkg-utils jansa/pull
>   https://github.com/shr-project/opkg-utils/tree/jansa/pull
> 
> Chris Diamand (1):
>   Changed call to subprocess.check_output which isn't compatible with
> Python 2.6
> 
> Ondics Githubler (1):
>   Option "C" ist shown in usage() and implemented, but was missing in
> getopts. Added "C".

Merged to master. Sorry about the delay, I'd missed the original
patches. I'd meant to sort this after I saw the reminder yesterday but
didn't get to it until today.

Cheers,

Richard

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

Re: [yocto] is there a summary of the proper use of all yocto-related mailing lists?

[Robert P. J. Day]

On Mon, 18 Jun 2012, Tyler Jones wrote:

> Check here: http://www.yoctoproject.org/community/mailing-lists I
> feel that this provides enough of a description of each mailing
> list.

  but that list doesn't mention the OE or bitbake mailing lists, for
which some questions will be relevant, no?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] why does yocto dev manual emphasize meta-intel BSP layer so much?

[Robert P. J. Day]

"Supported Board Support Packages (BSPs): The Yocto Project provides
a layer called meta-intel and it is maintained in its own separate Git
repository. The meta-intel layer contains many supported BSP
Layers..."

  well, yes, but that makes it sound like it's the *only* BSP layer of
any consequence.  perhaps that could be reworded?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] [PATCH] DOCS: Development manual: Some minor typoes in first couple chapters.

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/dev-manual/dev-manual-intro.xml 
b/documentation/dev-manual/dev-manual-intro.xml
index cf5471e..c5a173f 100644
--- a/documentation/dev-manual/dev-manual-intro.xml
+++ b/documentation/dev-manual/dev-manual-intro.xml
@@ -23,7 +23,7 @@

 
 The Yocto Project Development Manual, however, does provide 
detailed examples on how to create a
-Board Support Package (BSP), change the kernel source code, and 
re-configure the kernel.
+Board Support Package (BSP), change the kernel source code, and 
reconfigure the kernel.
 You can find this information in the appendices of the manual.
 
 
@@ -149,7 +149,7 @@
  for a
 Yocto Project Discussions mailing list about the 
Poky build system.
 
-for a mailing list to receive offical Yocto 
Project announcements for developments and
+for a mailing list to receive official Yocto 
Project announcements for developments and
 as well as Yocto Project 
milestones.
 
 Internet Relay Chat (IRC):
diff --git a/documentation/dev-manual/dev-manual-start.xml 
b/documentation/dev-manual/dev-manual-start.xml
index 763582d..a379047 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -60,7 +60,7 @@
 Packages:  The Yocto Project 
requires certain packages
 exist on your development system (e.g. Python 2.6 or 2.7).
 See "The 
Packages"
-section in the Yocto Project Quick start for the exact package
+section in the Yocto Project Quick Start for the exact package
 requirements and the installation commands to install them
 for the supported distributions.
 Yocto Project 
Release:
@@ -272,7 +272,7 @@
 previous section.
 Initialize the build environment by sourcing a 
build environment
 script.
-Optionally ensure the 
/conf/local.conf configuration file,
+Optionally ensure the 
conf/local.conf configuration file,
 which is found in the
 Yocto Project 
Build Directory,
 is set up how you want it.
@@ -370,7 +370,7 @@
 that runs with the root password disabled.
 This allows you to use standard ssh and
 scp commands.
-The QEMU images also contain an embedded Network 
Files
+The QEMU images also contain an embedded Network 
File
 System (NFS) server that exports the image's root filesystem.
 This allows you to make the filesystem available to the
 host.


rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] basic recipe building - iperf

[James Abernathy]

On Mon, Jun 18, 2012 at 10:40 PM, Khem Raj  wrote:

>
>
> On Monday, June 18, 2012, James Abernathy  wrote:
> >
> >
> > On Mon, Jun 18, 2012 at 5:29 PM, jfabernathy 
> wrote:
> >>
> >> On 06/18/2012 05:21 PM, Marc Ferland wrote:
> >>>
> >>> jfabernathy  writes:
> >>>
> I needed to do some network performance testing on a Crownbay
> board and
> needed iperf in that environment.  Since I had the
> core-image-sato-sdk
> image created, I just booted that and took the tarball from
> Sourceforge
> and built it  per the readme file instructions:
> ./configure
> make
> make install
> After I completed my test, I thought about why not put that in my
> list
> of personal recipes.  I found the previous version of iperf in the
> openembedded collection of benchmark recipes and just copied it
> over.
> It built and worked fine.  There were a lot of items in the .bb
> that I
> didn't understand, so I thought for fun I'd just try to build a
> recipe
> for iperf 2.0.5 and see what happened.  My recipe is simple, mostly
> taken from the openembedded 2.0.4 version had stripped down:
> >>>
> >>> Hi JF,
> >>>
> >>> I add the same problem you had with the man page stuff, try this patch.
> >>>
>
>
> >>> Marc
> >>
> >> thanks, that patch fixed it from a build point of view. now I'll build
> the image again and see what happens on the hardware.
> >>
> >> Jim A
> >>
> > As expected the new image booted and ran the iperf 2.0.5 just fine.  Are
> there any plans to add this tool to the Yocto project??
> >
>
> You could have just looked into meta-oe/recipes-benchmarks
> > Jim A
> >

You must have missed the earlier discussion.  I first got the iperf 2.0.4
from meta-oe, but wanted 2.0.5, so I just added it to my private collection
of apps.

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

[yocto] links to bitbake info throughout the docs should probably be updated

[Robert P. J. Day]

  currently in dev manual, link to bitbake doc is:

http://bitbake.berlios.de/manual/

which as you can see is out of date.  it's probably worth scanning all
the docs and deciding how to update links for bitbake documentation.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Dependency Tree

[Paul Eggleton]

On Monday 18 June 2012 13:58:03 Jim Rucker wrote:
> I'm trying to build using the code sourcery external compiler and I noticed
> that it's pulling in qemu. This brings up 2 questions-
> 1. Why? Qemu is not a prerequisite for building with GCC and shouldn't be a
> prerequisite for building with CS.

What is your MACHINE set to? If you're building for a qemu* machine then that 
would explain it.

> 2. How can I easily generate a dependency tree so I can 'fix' this?

As Khem mentioned you can use -g -u depexp, or alternatively just -g to output 
dependency graphs in graphviz format which you can grep.

Cheers,
Paul

-- 

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

[yocto] [PATCH] Docs, Development manual: Typoes/fixes to chapter 3.

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/dev-manual/dev-manual-newbie.xml 
b/documentation/dev-manual/dev-manual-newbie.xml
index 1f41d1e..9b1636c 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -23,7 +23,7 @@
 Open source philosophy is characterized by software development 
directed by peer production
 and collaboration through an active community of developers.
 Contrast this to the more standard centralized development models used 
by commercial software
-companies where a finite set of developers produce a product for sale 
using a defined set
+companies where a finite set of developers produces a product for sale 
using a defined set
 of procedures that ultimately result in an end product whose 
architecture and source material
 are closed to the public.
 
@@ -97,7 +97,7 @@
 
 Most teams have many pieces of software undergoing active development 
at any given time.
 You can derive large benefits by putting these pieces under the 
control of a source
-control system that is compatible with the Yocto Project (i.e. Git or 
Subversion (SVN).
+control system that is compatible with the Yocto Project (i.e. Git or 
Subversion (SVN)).
 You can then set the autobuilder to pull the latest revisions of the 
packages
 and test the latest commits by the builds.
 This practice quickly highlights issues.
@@ -239,14 +239,14 @@
 tools and utilities that allow you to develop software for 
targeted architectures.
 This toolchain contains cross-compilers, linkers, and 
debuggers that are specific to
 an architecture.
-You can use the Yocto Project to build cross-development 
toolchains in tarball form that when
-unpacked contain the development tools you need to 
cross-compile and test your software.
+You can use the Yocto Project to build cross-development 
toolchains in tarball form that, when
+unpacked, contain the development tools you need to 
cross-compile and test your software.
 The Yocto Project ships with images that contain toolchains 
for supported architectures
 as well.
 Sometimes this toolchain is referred to as the 
meta-toolchain.
 Image: An image is the result 
produced when
 BitBake processes a given collection of recipes and related 
metadata.
-Images are the binary output that runs on specific hardware 
and for specific
+Images are the binary output that run on specific hardware and 
for specific
 use cases.
 For a list of the supported image types that the Yocto Project 
provides, see the
 "Reference: 
Images"
@@ -530,9 +530,9 @@
  $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
 
 In this example, the name of the top-level directory of your local 
Yocto Project
-Files Git repository is poky.
-And, the name of the local working area (or local branch) you have 
created and checked
-out is named &DISTRO_NAME;.
+Files Git repository is poky,
+and the name of the local working area (or local branch) you have 
created and checked
+out is &DISTRO_NAME;.
 The files in your repository now reflect the same files that are 
in the
 &DISTRO_NAME; development branch of the Yocto 
Project's
 poky repository.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Discussion: Package testing

[Burton, Ross]

On 18 June 2012 16:04, Björn Stenberg  wrote:
> Typically the tests don't mix production and test code, since the purpose is 
> to test the production code. Rather the tests are isolated in separate files 
> that we relatively easily can build and install separately from the base 
> package.

The problem with that is that you can only test the external
interfaces, not the inner state (black box vs white box).  i.e. DBus
has test cases for each C file inside that C file, so it can exercise
both the external API and internal state.

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

[yocto] is it "IMAGE_INSTALL +=" or "IMAGE_INSTALL_append ="?

[Robert P. J. Day]

  currently, the dev manual (Section 4.2.1) proposes the use of

  IMAGE_INSTALL += "strace"

but the poky ref manual in the variable glossary explicitly
discourages that form, and instead recommends

  IMAGE_INSTALL_append = " package-name"

  can we agree that the "_append" form is preferred?  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] Help with configuring Yocto with an external toolchain except "csl"

[jojo]

@all,
I google some information about this topic and then,
i found the case is that jut support "CodeSourcery labs" toolchain.

I think my external toolchain is not standard of directory like 
"tcmode-externl-csl".
I can use "buildroot" to use this toolchian that just use three 
variables following :
BR2_TOOLCHAIN_EXTERNAL_PREFIX
BR2_TOOLCHAIN_EXTERNAL_PATH
BR2_TOOLCHAIN_EXTERNAL_SYSROOT_PATH

so there are some solution in poky ? thanks for you attention :)

B.R.
-- jojo




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

Re: [yocto] links to bitbake info throughout the docs should probably be updated

[Rifenbark, Scott M]

Good catch Robert.  I will take care of this.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Robert P. J. Day
Sent: Tuesday, June 19, 2012 3:09 AM
To: Yocto discussion list
Subject: [yocto] links to bitbake info throughout the docs should probably be 
updated


  currently in dev manual, link to bitbake doc is:

http://bitbake.berlios.de/manual/

which as you can see is out of date.  it's probably worth scanning all
the docs and deciding how to update links for bitbake documentation.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] [PATCH] Docs, Development manual: Typoes/fixes to chapter 3.

[Rifenbark, Scott M]

Implemented.  Thanks Robert

See http://git.yoctoproject.org/cgit.cgi/yocto-docs/log or 
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Robert P. J. Day
Sent: Tuesday, June 19, 2012 3:28 AM
To: Yocto discussion list
Subject: [yocto] [PATCH] Docs, Development manual: Typoes/fixes to chapter 3.


Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/dev-manual/dev-manual-newbie.xml 
b/documentation/dev-manual/dev-manual-newbie.xml
index 1f41d1e..9b1636c 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -23,7 +23,7 @@
 Open source philosophy is characterized by software development 
directed by peer production
 and collaboration through an active community of developers.
 Contrast this to the more standard centralized development models used 
by commercial software
-companies where a finite set of developers produce a product for sale 
using a defined set
+companies where a finite set of developers produces a product for sale 
using a defined set
 of procedures that ultimately result in an end product whose 
architecture and source material
 are closed to the public.
 
@@ -97,7 +97,7 @@
 
 Most teams have many pieces of software undergoing active development 
at any given time.
 You can derive large benefits by putting these pieces under the 
control of a source
-control system that is compatible with the Yocto Project (i.e. Git or 
Subversion (SVN).
+control system that is compatible with the Yocto Project (i.e. Git or 
Subversion (SVN)).
 You can then set the autobuilder to pull the latest revisions of the 
packages
 and test the latest commits by the builds.
 This practice quickly highlights issues.
@@ -239,14 +239,14 @@
 tools and utilities that allow you to develop software for 
targeted architectures.
 This toolchain contains cross-compilers, linkers, and 
debuggers that are specific to
 an architecture.
-You can use the Yocto Project to build cross-development 
toolchains in tarball form that when
-unpacked contain the development tools you need to 
cross-compile and test your software.
+You can use the Yocto Project to build cross-development 
toolchains in tarball form that, when
+unpacked, contain the development tools you need to 
cross-compile and test your software.
 The Yocto Project ships with images that contain toolchains 
for supported architectures
 as well.
 Sometimes this toolchain is referred to as the 
meta-toolchain.
 Image: An image is the result 
produced when
 BitBake processes a given collection of recipes and related 
metadata.
-Images are the binary output that runs on specific hardware 
and for specific
+Images are the binary output that run on specific hardware and 
for specific
 use cases.
 For a list of the supported image types that the Yocto Project 
provides, see the
 "Reference: 
Images"
@@ -530,9 +530,9 @@
  $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
 
 In this example, the name of the top-level directory of your local 
Yocto Project
-Files Git repository is poky.
-And, the name of the local working area (or local branch) you have 
created and checked
-out is named &DISTRO_NAME;.
+Files Git repository is poky,
+and the name of the local working area (or local branch) you have 
created and checked
+out is &DISTRO_NAME;.
 The files in your repository now reflect the same files that are 
in the
 &DISTRO_NAME; development branch of the Yocto 
Project's
 poky repository.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] basic recipe building - iperf

[Khem Raj]

On Tue, Jun 19, 2012 at 2:54 AM, James Abernathy  wrote:
> You must have missed the earlier discussion.  I first got the iperf 2.0.4
> from meta-oe, but wanted 2.0.5, so I just added it to my private collection
> of apps.

you can post the update patch for meta-oe layer
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] DOCS: Development manual: Some minor typoes in first couple chapters.

[Rifenbark, Scott M]

Implemented.  Thanks Robert

See http://git.yoctoproject.org/cgit.cgi/yocto-docs/log or 
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Robert P. J. Day
Sent: Tuesday, June 19, 2012 2:44 AM
To: Yocto discussion list
Subject: [yocto] [PATCH] DOCS: Development manual: Some minor typoes in first 
couple chapters.


Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/dev-manual/dev-manual-intro.xml 
b/documentation/dev-manual/dev-manual-intro.xml
index cf5471e..c5a173f 100644
--- a/documentation/dev-manual/dev-manual-intro.xml
+++ b/documentation/dev-manual/dev-manual-intro.xml
@@ -23,7 +23,7 @@

 
 The Yocto Project Development Manual, however, does provide 
detailed examples on how to create a
-Board Support Package (BSP), change the kernel source code, and 
re-configure the kernel.
+Board Support Package (BSP), change the kernel source code, and 
reconfigure the kernel.
 You can find this information in the appendices of the manual.
 
 
@@ -149,7 +149,7 @@
  for a
 Yocto Project Discussions mailing list about the 
Poky build system.
 
-for a mailing list to receive offical Yocto 
Project announcements for developments and
+for a mailing list to receive official Yocto 
Project announcements for developments and
 as well as Yocto Project 
milestones.
 
 Internet Relay Chat (IRC):
diff --git a/documentation/dev-manual/dev-manual-start.xml 
b/documentation/dev-manual/dev-manual-start.xml
index 763582d..a379047 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -60,7 +60,7 @@
 Packages:  The Yocto Project 
requires certain packages
 exist on your development system (e.g. Python 2.6 or 2.7).
 See "The 
Packages"
-section in the Yocto Project Quick start for the exact package
+section in the Yocto Project Quick Start for the exact package
 requirements and the installation commands to install them
 for the supported distributions.
 Yocto Project 
Release:
@@ -272,7 +272,7 @@
 previous section.
 Initialize the build environment by sourcing a 
build environment
 script.
-Optionally ensure the 
/conf/local.conf configuration file,
+Optionally ensure the 
conf/local.conf configuration file,
 which is found in the
 Yocto Project 
Build Directory,
 is set up how you want it.
@@ -370,7 +370,7 @@
 that runs with the root password disabled.
 This allows you to use standard ssh and
 scp commands.
-The QEMU images also contain an embedded Network 
Files
+The QEMU images also contain an embedded Network 
File
 System (NFS) server that exports the image's root filesystem.
 This allows you to make the filesystem available to the
 host.


rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
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] trouble building bsp for arm

[Dallas Clement]

Hi all,  Please bear with me as I am a newb to both yocto and building
bsp's.   I was able to run bitbake core-image-minimal for x86-64, just fine and
run it in qemu.

Then I got gutsy and tried to build a bsp for ARM.  Didn't go so well.
 I must be missing something.

dallasc ~/development/yocto/poky-denzil-7.0] scripts/yocto-bsp create
marvell-armada-xp-mv78260 qemu
Which qemu architecture would you like to use? [default: i386]
       1) i386    (32-bit)
       2) x86_64  (64-bit)
       3) ARM     (32-bit)
       4) PowerPC (32-bit)
       5) MIPS    (32-bit)
3
Would you like to use the default (3.2) kernel? (y/n) [default: y]
Do you need a new machine branch for this BSP (the alternative is to
re-use an existing branch)? [y/n] [default: y]
Getting branches from remote repo None...
Traceback (most recent call last):
 File "scripts/yocto-bsp", line 137, in 
   ret = main()
 File "scripts/yocto-bsp", line 132, in main
   invoke_subcommand(args, parser, yocto_bsp_help_usage, subcommands)
 File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/help.py",
line 73, in invoke_subcommand
   subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
 File "scripts/yocto-bsp", line 76, in yocto_bsp_create_subcommand
   yocto_bsp_create(machine, karch, scripts_path, bsp_output_dir,
options.codedump, options.properties_file)
 File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/engine.py",
line 1243, in yocto_bsp_create
   run_program_lines(program_lines, codedump)
SyntaxError: function specified for 'gen' property returned nothing :
input type:"choicelist" name:"new_kbranch"
gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine
branch to base this BSP on:" default:"standard/default"

Can anyone recommend what I should do to get past this?

Thanks,

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

Re: [yocto] trouble building bsp for arm

[Tom Zanussi]

On Tue, 2012-06-19 at 09:37 -0500, Dallas Clement wrote:
> Hi all,  Please bear with me as I am a newb to both yocto and building
> bsp's.   I was able to run bitbake core-image-minimal for x86-64, just fine 
> and
> run it in qemu.
> 
> Then I got gutsy and tried to build a bsp for ARM.  Didn't go so well.
>  I must be missing something.
> 

Hi,

So if I read the above correctly, you were able to create a new x86-64
bsp using yocto-bsp and build and boot the minimal image?

If so, then the below should also work - at the point you are in the
creation script, there's nothing arm-specific yet.

If not, did you source oe-init-build-env first?  Or do you have some
kind of network problem?

I can't think of anything else - I just tried the same thing here and it
worked fine.  Let me also try the same thing but using the denzil
tarball (using git denzil branch), which is what I assume your using?

Thanks,

Tom

> dallasc ~/development/yocto/poky-denzil-7.0] scripts/yocto-bsp create
> marvell-armada-xp-mv78260 qemu
> Which qemu architecture would you like to use? [default: i386]
>1) i386(32-bit)
>2) x86_64  (64-bit)
>3) ARM (32-bit)
>4) PowerPC (32-bit)
>5) MIPS(32-bit)
> 3
> Would you like to use the default (3.2) kernel? (y/n) [default: y]
> Do you need a new machine branch for this BSP (the alternative is to
> re-use an existing branch)? [y/n] [default: y]
> Getting branches from remote repo None...
> Traceback (most recent call last):
>  File "scripts/yocto-bsp", line 137, in 
>ret = main()
>  File "scripts/yocto-bsp", line 132, in main
>invoke_subcommand(args, parser, yocto_bsp_help_usage, subcommands)
>  File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/help.py",
> line 73, in invoke_subcommand
>subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
>  File "scripts/yocto-bsp", line 76, in yocto_bsp_create_subcommand
>yocto_bsp_create(machine, karch, scripts_path, bsp_output_dir,
> options.codedump, options.properties_file)
>  File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/engine.py",
> line 1243, in yocto_bsp_create
>run_program_lines(program_lines, codedump)
> SyntaxError: function specified for 'gen' property returned nothing :
> input type:"choicelist" name:"new_kbranch"
> gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine
> branch to base this BSP on:" default:"standard/default"
> 
> Can anyone recommend what I should do to get past this?
> 
> Thanks,
> 
> Dallas
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] trouble building bsp for arm

[Dallas Clement]

Hi Tom,

The first thing I tried is building a minimal distro with "bitbake
core-image-minimal".  That completed successfully and I was able to
execute it with qemu.

Then I tried to build a bsp for ARM, which failed with errors shown
earlier.  I just tried now for x86_64.  It failed too with the same
errors.

I am using the latest poky tarball - poky-denzil-7.0.tar.bz2

Thanks,

Dallas

On Tue, Jun 19, 2012 at 10:03 AM, Tom Zanussi  wrote:
> On Tue, 2012-06-19 at 09:37 -0500, Dallas Clement wrote:
>> Hi all,  Please bear with me as I am a newb to both yocto and building
>> bsp's.   I was able to run bitbake core-image-minimal for x86-64, just fine 
>> and
>> run it in qemu.
>>
>> Then I got gutsy and tried to build a bsp for ARM.  Didn't go so well.
>>  I must be missing something.
>>
>
> Hi,
>
> So if I read the above correctly, you were able to create a new x86-64
> bsp using yocto-bsp and build and boot the minimal image?
>
> If so, then the below should also work - at the point you are in the
> creation script, there's nothing arm-specific yet.
>
> If not, did you source oe-init-build-env first?  Or do you have some
> kind of network problem?
>
> I can't think of anything else - I just tried the same thing here and it
> worked fine.  Let me also try the same thing but using the denzil
> tarball (using git denzil branch), which is what I assume your using?
>
> Thanks,
>
> Tom
>
>> dallasc ~/development/yocto/poky-denzil-7.0] scripts/yocto-bsp create
>> marvell-armada-xp-mv78260 qemu
>> Which qemu architecture would you like to use? [default: i386]
>>        1) i386    (32-bit)
>>        2) x86_64  (64-bit)
>>        3) ARM     (32-bit)
>>        4) PowerPC (32-bit)
>>        5) MIPS    (32-bit)
>> 3
>> Would you like to use the default (3.2) kernel? (y/n) [default: y]
>> Do you need a new machine branch for this BSP (the alternative is to
>> re-use an existing branch)? [y/n] [default: y]
>> Getting branches from remote repo None...
>> Traceback (most recent call last):
>>  File "scripts/yocto-bsp", line 137, in 
>>    ret = main()
>>  File "scripts/yocto-bsp", line 132, in main
>>    invoke_subcommand(args, parser, yocto_bsp_help_usage, subcommands)
>>  File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/help.py",
>> line 73, in invoke_subcommand
>>    subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
>>  File "scripts/yocto-bsp", line 76, in yocto_bsp_create_subcommand
>>    yocto_bsp_create(machine, karch, scripts_path, bsp_output_dir,
>> options.codedump, options.properties_file)
>>  File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/engine.py",
>> line 1243, in yocto_bsp_create
>>    run_program_lines(program_lines, codedump)
>> SyntaxError: function specified for 'gen' property returned nothing :
>> input type:"choicelist" name:"new_kbranch"
>> gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine
>> branch to base this BSP on:" default:"standard/default"
>>
>> Can anyone recommend what I should do to get past this?
>>
>> Thanks,
>>
>> Dallas
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] trouble building bsp for arm

[Tom Zanussi]

On Tue, 2012-06-19 at 10:13 -0500, Dallas Clement wrote:
> Hi Tom,
> 
> The first thing I tried is building a minimal distro with "bitbake
> core-image-minimal".  That completed successfully and I was able to
> execute it with qemu.
> 
> Then I tried to build a bsp for ARM, which failed with errors shown
> earlier.  I just tried now for x86_64.  It failed too with the same
> errors.
> 
> I am using the latest poky tarball - poky-denzil-7.0.tar.bz2
> 

OK, so what you did was successfully build a minimal image from the BSP
tarball for x86-64, but that wasn't using a BSP generated from
yocto-bsp, since you haven't been able to successfully generate a BSP
using yocto-bsp yet.  If that's not the case please clarify, otherwise
I'll try what you're doing using the denzil tarball...

Tom

> Thanks,
> 
> Dallas
> 
> On Tue, Jun 19, 2012 at 10:03 AM, Tom Zanussi  wrote:
> > On Tue, 2012-06-19 at 09:37 -0500, Dallas Clement wrote:
> >> Hi all,  Please bear with me as I am a newb to both yocto and building
> >> bsp's.   I was able to run bitbake core-image-minimal for x86-64, just 
> >> fine and
> >> run it in qemu.
> >>
> >> Then I got gutsy and tried to build a bsp for ARM.  Didn't go so well.
> >>  I must be missing something.
> >>
> >
> > Hi,
> >
> > So if I read the above correctly, you were able to create a new x86-64
> > bsp using yocto-bsp and build and boot the minimal image?
> >
> > If so, then the below should also work - at the point you are in the
> > creation script, there's nothing arm-specific yet.
> >
> > If not, did you source oe-init-build-env first?  Or do you have some
> > kind of network problem?
> >
> > I can't think of anything else - I just tried the same thing here and it
> > worked fine.  Let me also try the same thing but using the denzil
> > tarball (using git denzil branch), which is what I assume your using?
> >
> > Thanks,
> >
> > Tom
> >
> >> dallasc ~/development/yocto/poky-denzil-7.0] scripts/yocto-bsp create
> >> marvell-armada-xp-mv78260 qemu
> >> Which qemu architecture would you like to use? [default: i386]
> >>1) i386(32-bit)
> >>2) x86_64  (64-bit)
> >>3) ARM (32-bit)
> >>4) PowerPC (32-bit)
> >>5) MIPS(32-bit)
> >> 3
> >> Would you like to use the default (3.2) kernel? (y/n) [default: y]
> >> Do you need a new machine branch for this BSP (the alternative is to
> >> re-use an existing branch)? [y/n] [default: y]
> >> Getting branches from remote repo None...
> >> Traceback (most recent call last):
> >>  File "scripts/yocto-bsp", line 137, in 
> >>ret = main()
> >>  File "scripts/yocto-bsp", line 132, in main
> >>invoke_subcommand(args, parser, yocto_bsp_help_usage, subcommands)
> >>  File "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/help.py",
> >> line 73, in invoke_subcommand
> >>subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
> >>  File "scripts/yocto-bsp", line 76, in yocto_bsp_create_subcommand
> >>yocto_bsp_create(machine, karch, scripts_path, bsp_output_dir,
> >> options.codedump, options.properties_file)
> >>  File 
> >> "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/engine.py",
> >> line 1243, in yocto_bsp_create
> >>run_program_lines(program_lines, codedump)
> >> SyntaxError: function specified for 'gen' property returned nothing :
> >> input type:"choicelist" name:"new_kbranch"
> >> gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine
> >> branch to base this BSP on:" default:"standard/default"
> >>
> >> Can anyone recommend what I should do to get past this?
> >>
> >> Thanks,
> >>
> >> Dallas
> >> ___
> >> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] basic recipe building - iperf

[James Abernathy]

On Tue, Jun 19, 2012 at 10:20 AM, Khem Raj  wrote:

> On Tue, Jun 19, 2012 at 2:54 AM, James Abernathy 
> wrote:
> > You must have missed the earlier discussion.  I first got the iperf 2.0.4
> > from meta-oe, but wanted 2.0.5, so I just added it to my private
> collection
> > of apps.
>
> you can post the update patch for meta-oe layer
>

I can pass along what I did for iperf 2.0.5 in Yocto, but I have no idea
what to do for OE.  All the commands in their 2.0.4, which worked when
copied to my meta-jfa directory, didn't mean much to me.  I just started
from scratch and created a new recipe based on autotools plus the patch
that Marc passed along.

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

Re: [yocto] trouble building bsp for arm

[Dallas Clement]

Okay, using the git poky, I was able to build the bsp.  It seems that
the tarball version is not able to complete this step:

Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...

On Tue, Jun 19, 2012 at 10:23 AM, Dallas Clement
 wrote:
> That's correct.  I have not been successful with "yocto-bsp create"
> yet.  I'm trying with the git version of poky now.
>
> On Tue, Jun 19, 2012 at 10:19 AM, Tom Zanussi  wrote:
>> On Tue, 2012-06-19 at 10:13 -0500, Dallas Clement wrote:
>>> Hi Tom,
>>>
>>> The first thing I tried is building a minimal distro with "bitbake
>>> core-image-minimal".  That completed successfully and I was able to
>>> execute it with qemu.
>>>
>>> Then I tried to build a bsp for ARM, which failed with errors shown
>>> earlier.  I just tried now for x86_64.  It failed too with the same
>>> errors.
>>>
>>> I am using the latest poky tarball - poky-denzil-7.0.tar.bz2
>>>
>>
>> OK, so what you did was successfully build a minimal image from the BSP
>> tarball for x86-64, but that wasn't using a BSP generated from
>> yocto-bsp, since you haven't been able to successfully generate a BSP
>> using yocto-bsp yet.  If that's not the case please clarify, otherwise
>> I'll try what you're doing using the denzil tarball...
>>
>> Tom
>>
>>> Thanks,
>>>
>>> Dallas
>>>
>>> On Tue, Jun 19, 2012 at 10:03 AM, Tom Zanussi  wrote:
>>> > On Tue, 2012-06-19 at 09:37 -0500, Dallas Clement wrote:
>>> >> Hi all,  Please bear with me as I am a newb to both yocto and building
>>> >> bsp's.   I was able to run bitbake core-image-minimal for x86-64, just 
>>> >> fine and
>>> >> run it in qemu.
>>> >>
>>> >> Then I got gutsy and tried to build a bsp for ARM.  Didn't go so well.
>>> >>  I must be missing something.
>>> >>
>>> >
>>> > Hi,
>>> >
>>> > So if I read the above correctly, you were able to create a new x86-64
>>> > bsp using yocto-bsp and build and boot the minimal image?
>>> >
>>> > If so, then the below should also work - at the point you are in the
>>> > creation script, there's nothing arm-specific yet.
>>> >
>>> > If not, did you source oe-init-build-env first?  Or do you have some
>>> > kind of network problem?
>>> >
>>> > I can't think of anything else - I just tried the same thing here and it
>>> > worked fine.  Let me also try the same thing but using the denzil
>>> > tarball (using git denzil branch), which is what I assume your using?
>>> >
>>> > Thanks,
>>> >
>>> > Tom
>>> >
>>> >> dallasc ~/development/yocto/poky-denzil-7.0] scripts/yocto-bsp create
>>> >> marvell-armada-xp-mv78260 qemu
>>> >> Which qemu architecture would you like to use? [default: i386]
>>> >>        1) i386    (32-bit)
>>> >>        2) x86_64  (64-bit)
>>> >>        3) ARM     (32-bit)
>>> >>        4) PowerPC (32-bit)
>>> >>        5) MIPS    (32-bit)
>>> >> 3
>>> >> Would you like to use the default (3.2) kernel? (y/n) [default: y]
>>> >> Do you need a new machine branch for this BSP (the alternative is to
>>> >> re-use an existing branch)? [y/n] [default: y]
>>> >> Getting branches from remote repo None...
>>> >> Traceback (most recent call last):
>>> >>  File "scripts/yocto-bsp", line 137, in 
>>> >>    ret = main()
>>> >>  File "scripts/yocto-bsp", line 132, in main
>>> >>    invoke_subcommand(args, parser, yocto_bsp_help_usage, subcommands)
>>> >>  File 
>>> >> "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/help.py",
>>> >> line 73, in invoke_subcommand
>>> >>    subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
>>> >>  File "scripts/yocto-bsp", line 76, in yocto_bsp_create_subcommand
>>> >>    yocto_bsp_create(machine, karch, scripts_path, bsp_output_dir,
>>> >> options.codedump, options.properties_file)
>>> >>  File 
>>> >> "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/engine.py",
>>> >> line 1243, in yocto_bsp_create
>>> >>    run_program_lines(program_lines, codedump)
>>> >> SyntaxError: function specified for 'gen' property returned nothing :
>>> >> input type:"choicelist" name:"new_kbranch"
>>> >> gen:"bsp.kernel.all_branches" prio:"20" msg:"Please choose a machine
>>> >> branch to base this BSP on:" default:"standard/default"
>>> >>
>>> >> Can anyone recommend what I should do to get past this?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Dallas
>>> >> ___
>>> >> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is there a summary of the proper use of all yocto-related mailing lists?

[Tyler Jones]

OE and bitbake are tools provided by Yocto Project in Poky. The mailing
lists are not provided or maintained by the Yocto Project thus them not
being on the Yocto Project's site. You could make a wiki page,
https://wiki.yoctoproject.org/wiki/Mailing_Lists, with the mailing lists
and their description, but I feel they do not belong on the Yocto Project's
site.

-Tyler Jones


On 19 June 2012 01:44, Robert P. J. Day  wrote:

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

Re: [yocto] why does yocto dev manual emphasize meta-intel BSP layer so much?

[Tyler Jones]

On 19 June 2012 02:29, Robert P. J. Day  wrote:

>
> "Supported Board Support Packages (BSPs): The Yocto Project provides
> a layer called meta-intel and it is maintained in its own separate Git
> repository. The meta-intel layer contains many supported BSP
> Layers..."
>
>  well, yes, but that makes it sound like it's the *only* BSP layer of
> any consequence.  perhaps that could be reworded?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

It could be reworded but you have to remember that Intel is supporting the
Yocto Project [1].
I recall that there is a link to the OE Layer Index [2] in the
documentation that has many BSP layers.
I do like how it is worded on the downloads page [3] under the BSP section,
though I feel reference to the OE Layer Index [2] should be put on this
page as well.

[1] http://www.osnews.com/story/23963/Intel_Announces_The_Yocto_Project
[2] http://www.openembedded.org/wiki/LayerIndex
[3] http://www.yoctoproject.org/download

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

Re: [yocto] trouble building bsp for arm

[Tom Zanussi]

On Tue, 2012-06-19 at 10:29 -0500, Dallas Clement wrote:
> Okay, using the git poky, I was able to build the bsp.  It seems that
> the tarball version is not able to complete this step:
> 
> Getting branches from remote repo 
> git://git.yoctoproject.org/linux-yocto-3.2...
> 

OK, glad that the git poky worked for you.  I just did a download of the
denzil tarball and wasn't able to reproduce the problem, so I'm not sure
why the git update would work for you but tarball wouldn't.  There was a
fix for Yocto bug 2219 as mentioned in the denzil release notes that
would be the only difference in the yocto-bsp tool, but it doesn't sound
like that's what you hit.

Regarding master, you should note that I submitted a patch yesterday to
fix a problem with the qemu machines and X in master, Yocto bug 2559:

http://comments.gmane.org/gmane.linux.embedded.yocto.general/7087

So if you have problems with X in the generated qemu bsp image, that
should fix it (and should be pulled into poky/master soon).

Thanks,

Tom


> On Tue, Jun 19, 2012 at 10:23 AM, Dallas Clement
>  wrote:
> > That's correct.  I have not been successful with "yocto-bsp create"
> > yet.  I'm trying with the git version of poky now.
> >
> > On Tue, Jun 19, 2012 at 10:19 AM, Tom Zanussi  wrote:
> >> On Tue, 2012-06-19 at 10:13 -0500, Dallas Clement wrote:
> >>> Hi Tom,
> >>>
> >>> The first thing I tried is building a minimal distro with "bitbake
> >>> core-image-minimal".  That completed successfully and I was able to
> >>> execute it with qemu.
> >>>
> >>> Then I tried to build a bsp for ARM, which failed with errors shown
> >>> earlier.  I just tried now for x86_64.  It failed too with the same
> >>> errors.
> >>>
> >>> I am using the latest poky tarball - poky-denzil-7.0.tar.bz2
> >>>
> >>
> >> OK, so what you did was successfully build a minimal image from the BSP
> >> tarball for x86-64, but that wasn't using a BSP generated from
> >> yocto-bsp, since you haven't been able to successfully generate a BSP
> >> using yocto-bsp yet.  If that's not the case please clarify, otherwise
> >> I'll try what you're doing using the denzil tarball...
> >>
> >> Tom
> >>
> >>> Thanks,
> >>>
> >>> Dallas
> >>>
> >>> On Tue, Jun 19, 2012 at 10:03 AM, Tom Zanussi  
> >>> wrote:
> >>> > On Tue, 2012-06-19 at 09:37 -0500, Dallas Clement wrote:
> >>> >> Hi all,  Please bear with me as I am a newb to both yocto and building
> >>> >> bsp's.   I was able to run bitbake core-image-minimal for x86-64, just 
> >>> >> fine and
> >>> >> run it in qemu.
> >>> >>
> >>> >> Then I got gutsy and tried to build a bsp for ARM.  Didn't go so well.
> >>> >>  I must be missing something.
> >>> >>
> >>> >
> >>> > Hi,
> >>> >
> >>> > So if I read the above correctly, you were able to create a new x86-64
> >>> > bsp using yocto-bsp and build and boot the minimal image?
> >>> >
> >>> > If so, then the below should also work - at the point you are in the
> >>> > creation script, there's nothing arm-specific yet.
> >>> >
> >>> > If not, did you source oe-init-build-env first?  Or do you have some
> >>> > kind of network problem?
> >>> >
> >>> > I can't think of anything else - I just tried the same thing here and it
> >>> > worked fine.  Let me also try the same thing but using the denzil
> >>> > tarball (using git denzil branch), which is what I assume your using?
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Tom
> >>> >
> >>> >> dallasc ~/development/yocto/poky-denzil-7.0] scripts/yocto-bsp create
> >>> >> marvell-armada-xp-mv78260 qemu
> >>> >> Which qemu architecture would you like to use? [default: i386]
> >>> >>1) i386(32-bit)
> >>> >>2) x86_64  (64-bit)
> >>> >>3) ARM (32-bit)
> >>> >>4) PowerPC (32-bit)
> >>> >>5) MIPS(32-bit)
> >>> >> 3
> >>> >> Would you like to use the default (3.2) kernel? (y/n) [default: y]
> >>> >> Do you need a new machine branch for this BSP (the alternative is to
> >>> >> re-use an existing branch)? [y/n] [default: y]
> >>> >> Getting branches from remote repo None...
> >>> >> Traceback (most recent call last):
> >>> >>  File "scripts/yocto-bsp", line 137, in 
> >>> >>ret = main()
> >>> >>  File "scripts/yocto-bsp", line 132, in main
> >>> >>invoke_subcommand(args, parser, yocto_bsp_help_usage, subcommands)
> >>> >>  File 
> >>> >> "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/help.py",
> >>> >> line 73, in invoke_subcommand
> >>> >>subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
> >>> >>  File "scripts/yocto-bsp", line 76, in yocto_bsp_create_subcommand
> >>> >>yocto_bsp_create(machine, karch, scripts_path, bsp_output_dir,
> >>> >> options.codedump, options.properties_file)
> >>> >>  File 
> >>> >> "/development/dallasc/yocto/poky-denzil-7.0/scripts/lib/bsp/engine.py",
> >>> >> line 1243, in yocto_bsp_create
> >>> >>run_program_lines(program_lines, codedump)
> >>> >> SyntaxError: function specified for 'gen' property returned nothing :
> >>> >> input type:"choic

Re: [yocto] is it "IMAGE_INSTALL +=" or "IMAGE_INSTALL_append ="?

[Paul Eggleton]

On Tuesday 19 June 2012 08:22:00 Robert P. J. Day wrote:
>   currently, the dev manual (Section 4.2.1) proposes the use of
> 
>   IMAGE_INSTALL += "strace"
> 
> but the poky ref manual in the variable glossary explicitly
> discourages that form, and instead recommends
> 
>   IMAGE_INSTALL_append = " package-name"
> 
>   can we agree that the "_append" form is preferred?  thoughts?

The reference manual is a little unclear on what "ordering issues" means. += 
works just fine, it's just that if you happen to use it at some point before 
core-image.bbclass line sets it with ?= (i.e. either in local.conf or before 
the "inherit core-image" line in your image recipe) the ?= line in core-
image.bbclass will do nothing and you'll end up with much less in the 
IMAGE_INSTALL list than you expected. If you use _append, you can have that 
anywhere you like and it will always work, with the caveat that if you forget 
to add a leading space in the value to be appended, things will break.

Note that the part of 4.2.1 in the dev manual you refer to is specifically 
talking about making a copy of an image recipe and putting the IMAGE_INSTALL 
+= at the end, which will always work and won't suffer from any leading space 
issues. I'm not sure what we should change to improve this...

Cheers,
Paul

-- 

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

[yocto] developing with devshell and effect of the bitbake.conf file

[Rifenbark, Scott M]

Hi,
I want to throw this out for discussion.  I recently was looking at a section 
in the YP Reference manual 
(http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell)
 where it talks about developing using devshell.  I asked Darren Hart if this 
was a valid development model and he says it is.  There is a part of the 
section though that talks about the bitbake.conf file.  That section in the 
conf file does not seem to exist anymore.  And, Darren (after some testing) 
doesn't see how what is in the bitbake.conf file affects development with 
devshell.  Any comments welcome.
Thanks,
ScottR

From: Scott Rifenbark [mailto:srifenb...@gmail.com]
Sent: Thursday, June 14, 2012 8:42 AM
To: Rifenbark, Scott M
Subject: Fwd: Next question regarding development practices


-- Forwarded message --
From: Darren Hart mailto:darren.h...@intel.com>>
Date: Wed, Jun 13, 2012 at 2:19 PM
Subject: Re: Next question regarding development practices
To: Scott Rifenbark mailto:srifenb...@gmail.com>>
On 06/12/2012 11:34 AM, Scott Rifenbark wrote:
> Hi Darren,
>
> So check out section
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell.
> This talks about the whole devshell model.  One thing in this section is
> not current and that is the UI/Interfaces Configuration section
> reference in bitbake.conf file.  Regarding the section though, is this
> still a valid development model?  Is it worth keeping around in the docs?
>
> As you can tell, I value your opinions greatly :)
As I understand it, this is still a perfectly valid working model.
Someone was just recommending it this week on the list.

As for the bitbake.conf file... I'm not sure. I thought this would have
been controlled by the following in local.conf.

# If you do not use (or have installed) gnome-terminal you will need to
# uncomment these variables and set them to the terminal you wish to use
# when resolving patches which cannot be applied
# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN ARE:
# GNOME, SCREEN, XTERM and SCREEN
TERMCMD = "${SCREEN_TERMCMD}"
TERMCMDRUN = "${SCREEN_TERMCMDRUN}"

But... it clearly is not after some testing. Hrm... I don't see anything
matching in bitbake.conf either. Where this has migrated off to would be
a good question for the list, hopefully someone like Paul E. can answer
this quickly.

--
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] is it "IMAGE_INSTALL +=" or "IMAGE_INSTALL_append ="?

[Chris Tapp]

On 19 Jun 2012, at 18:52, Paul Eggleton wrote:

> On Tuesday 19 June 2012 08:22:00 Robert P. J. Day wrote:
>>  currently, the dev manual (Section 4.2.1) proposes the use of
>> 
>>  IMAGE_INSTALL += "strace"
>> 
>> but the poky ref manual in the variable glossary explicitly
>> discourages that form, and instead recommends
>> 
>>  IMAGE_INSTALL_append = " package-name"
>> 
>>  can we agree that the "_append" form is preferred?  thoughts?
> 
> The reference manual is a little unclear on what "ordering issues" means. += 
> works just fine, it's just that if you happen to use it at some point before 
> core-image.bbclass line sets it with ?= (i.e. either in local.conf or before 
> the "inherit core-image" line in your image recipe) the ?= line in core-
> image.bbclass will do nothing and you'll end up with much less in the 
> IMAGE_INSTALL list than you expected. If you use _append, you can have that 
> anywhere you like and it will always work, with the caveat that if you forget 
> to add a leading space in the value to be appended, things will break.
> 
> Note that the part of 4.2.1 in the dev manual you refer to is specifically 
> talking about making a copy of an image recipe and putting the IMAGE_INSTALL 
> += at the end, which will always work and won't suffer from any leading space 
> issues. I'm not sure what we should change to improve this...

Is there a section that explains the order in which all these things happen? 
i.e. items in local.conf happen before/after...

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

[yocto] VERIFIED vs CLOSED in yocto bugzilla

[Serban, Laurentiu]

Hello,

I submit to your attention the following issue related to Yocto project's 
bugzilla:

Which is the most appropriate end for a the lifecycle of a bugzilla issue: 
VERIFIED or CLOSED?
Currently the bug lifecycle final point is VERIFIED and the status CLOSED is 
not used. Setting a bug to CLOSED after it was VERIFIED has no impact on the 
lifecycle itself as the bug can be reopened anyway.

My proposal is the following: keep VERIFIED as the final point of the bug 
lifecycle and use the status CLOSED for the bug only after the 1.3 release, if 
the regression testing for the bug is ran and passed.
So after the 1.3 release the ideal situation is that all the bugs related to it 
with previous status VERIFIED are CLOSED.

Waiting for your opinion on this,
Thank you,

Laurentiu Serban
QA Engineer
Open Source Technology Center
System Software Division Romania
Desk: +40 31 8604742
iNET: 88451042

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

Re: [yocto] VERIFIED vs CLOSED in yocto bugzilla

[Khem Raj]

On Tuesday, June 19, 2012, Serban, Laurentiu 
wrote:
> Hello,
>
>
>
> I submit to your attention the following issue related to Yocto project’s
bugzilla:
>
>
>
> Which is the most appropriate end for a the lifecycle of a bugzilla
issue: VERIFIED or CLOSED?
>
> Currently the bug lifecycle final point is VERIFIED and the status CLOSED
is not used. Setting a bug to CLOSED after it was VERIFIED has no impact on
the lifecycle itself as the bug can be reopened anyway.
>
>
>
> My proposal is the following: keep VERIFIED as the final point of the bug
lifecycle and use the status CLOSED for the bug only after the 1.3 release,
if the regression testing for the bug is ran and passed.
>
> So after the 1.3 release the ideal situation is that all the bugs related
to it with previous status VERIFIED are CLOSED.
>
>
>
> Waiting for your opinion on this,
>

Closed is something for the original submitter IMO
He should be the one to mark the bug closed
> Thank you,
>
>
>
> Laurentiu Serban
>
> QA Engineer
>
> Open Source Technology Center
>
> System Software Division Romania
>
> Desk: +40 31 8604742
>
> iNET: 88451042
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Liu, Song]

Attendees:
Darren, Beth, Saul, Tom, Jessica, LaurentiuS, Scott Garman, Richard, Nitin, 
ScottR, Michael, Paul, Jim, Bjorn (Enea), Ross, Jefro, Bogdan, Gilbert, Jeff, 
Sahad, Sean, Cristian, Alex, Bruce, Josh, Song
 
Agenda:
 
* Opens collection - 5 min (Song)
* 1.2.1 update - 5 min (ScottG)
  - 1 remaining open bug, pull request pending.
  - 1 more pull request for a community request for kernel patches (suggested 
by Bruce)
  - Then will be reviewed by community.
  - ETA for RC1 is this Friday.
  - Next week ScottG will be away to help run a conference. 1.2.1 will be 
shared with Saul, Beth and Michael.
* 1.1.2 update - 5 min (Josh/Beth)
  - all patches are merged.
  - Beth ran a build last week, we have a successful build. 
  - Beth: there is still one issue for the build. But the QA can use the build 
for testing.
  - ScottR: there are many doc changes that we need to merge into the release. 
Need to have the month for the release. Song to follow up.
 
* Yocto 1.3 status  - 10 min (Song/team)
  - features/bugs: most are completed and merged. 1 design feature left, moving 
that to M2. 4 M1 bugs left on the schedule. 2 from Bruce are already in patch 
review. 1 from Mark moving to M2. 1 from liming in patch review
  - weekly testing are done, moving ahead with full pass testing. No blocking 
issues so far. Preparing to release RC1.
  - Bugs: # f medium+ bugs are high, WDD number is high. The team need to focus 
more on bug fixing to bring the numbers down. (the team fixed about 27 bugs in 
last week though, it's good progress)
  - release criteria review. 
  - verify to close: Laurentiu will send an email to the mailing list proposing 
how to 'close' a bug. 
 
* SWAT team rotation: Dexuan -> Nitin
 
* Opens - 5 min
  - Laurentiu: you may receive emails for bug verification if you are the 
author or requestor for a bug or feature.
  - Bjorn: posted a mail about testing effort. Would be nice to have feedback 
on it. (Laurentiu will review and get in touch with Bjorn)
  - Song: Use IRC channel for this meeting. Will send out a note for how to use 
this.
 
* Team sharing - 20 min
  - Darren: working on poky-tiny, got patches out there with busy box config, 
ready to go in. This week, warping up some kernel drivers this week, will work 
on the accelerometer driver next week. 
  - Michael: new bugzilla category is up and alive. Upgraded RAID controller, 
replaced hard drivers. New autobuilder node is coming up today or tomorrow. 
  RP: Can we document on the wiki about the autobuilder, which machine is 
running what and with what distro. (Paul) There are some code in sanity test 
for distro identification. Beth will put together the wiki page and send out an 
email (This week).
  RP: bug counts data, auto collecting information. Michael: some issues, will 
be moving to the new server and fix them. RP: get data to RP first, without 
graphics it's ok. Data is a great start.
  - Saul: Working on package re-order, will be sending out the pull request 
this morning along with build history. Any feedback/comments, let me know. It's 
great if more people can look at them. Will fix the package reporting system. 
   - RP: a few patches: rp working some patches on fetchers. Paul's patch: 
forcing particular tasks to re-run, response to some bugs reported by Jason 
from Wind River. Make kernel config change on the fly and make sure it gets 
rebuild, etc.


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

[yocto] trouble running hob on Debian

[Dallas Clement]

I'm experiencing some grief trying to run hob from my Debian Squeeze (6.0.5).

[dallasc /development/dallasc/yocto/poky/build] hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
You have Gtk+ 2.20.1 and PyGtk 2.17.0.

I believe I have all these packages installed.  Perhaps it needs newer
versions of these packages?

i A libgtk2.0-0 - The GTK+ graphical user interface library
i   python-gtk2 - Python bindings for the GTK+ widget set
i   python-gobject  - Python bindings for the GObject library
i   python-gobject-dev  - Development headers for the GObject Python

Any advice on how to debug further?

I just installed git poky today, so should be up to date.

Thanks,

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

Re: [yocto] VERIFIED vs CLOSED in yocto bugzilla

[Darren Hart]

On 06/19/2012 12:25 PM, Serban, Laurentiu wrote:
> Hello,
> 
>  
> 
> I submit to your attention the following issue related to Yocto
> project’s bugzilla:
> 
>  
> 
> Which is the most appropriate end for a the lifecycle of a bugzilla
> issue: VERIFIED or CLOSED?
> 
> Currently the bug lifecycle final point is VERIFIED and the status
> CLOSED is not used. Setting a bug to CLOSED after it was VERIFIED has no
> impact on the lifecycle itself as the bug can be reopened anyway.
> 
>  
> 
> My proposal is the following: keep VERIFIED as the final point of the
> bug lifecycle and use the status CLOSED for the bug only after the 1.3
> release, *if* the regression testing for the bug is ran and passed.
> 
> So after the 1.3 release the ideal situation is that all the bugs
> related to it with previous status VERIFIED are CLOSED.

What is the reasoning driving this change? What does CLOSED indicate
that VERIFIED does not already convey?

Thanks,

Darren

> 
>  
> 
> Waiting for your opinion on this,
> 
> Thank you,
> 
>  
> 
> *Laurentiu Serban*
> 
> QA Engineer
> 
> Open Source Technology Center
> 
> System Software Division Romania
> 
> Desk: +40 31 8604742**
> 
> iNET: 88451042
> 
>  
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

-- 
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] trouble running hob on Debian

[Joshua Lock]

On 19/06/12 15:31, Dallas Clement wrote:

I'm experiencing some grief trying to run hob from my Debian Squeeze (6.0.5).

[dallasc /development/dallasc/yocto/poky/build] hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
You have Gtk+ 2.20.1 and PyGtk 2.17.0.


This would be much more useful if the required version were also 
reported, an oversight on my part.


Presently you need Gtk+ 2.20.0 or later and PyGtk 2.21.0 or later.

Joshua
--
Joshua Lock
Yocto Project
Intel Open Source Technology Centre


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

Re: [yocto] developing with devshell and effect of the bitbake.conf file

[Stewart, David C]

Is anybody using devshell actively who can recreate this section of 
bitbake.conf?

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Rifenbark, Scott M
Sent: Tuesday, June 19, 2012 11:14 AM
To: Yocto discussion list
Subject: [yocto] developing with devshell and effect of the bitbake.conf file

Hi,
I want to throw this out for discussion.  I recently was looking at a section 
in the YP Reference manual 
(http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell)
 where it talks about developing using devshell.  I asked Darren Hart if this 
was a valid development model and he says it is.  There is a part of the 
section though that talks about the bitbake.conf file.  That section in the 
conf file does not seem to exist anymore.  And, Darren (after some testing) 
doesn't see how what is in the bitbake.conf file affects development with 
devshell.  Any comments welcome.
Thanks,
ScottR

From: Scott Rifenbark [mailto:srifenb...@gmail.com]
Sent: Thursday, June 14, 2012 8:42 AM
To: Rifenbark, Scott M
Subject: Fwd: Next question regarding development practices


-- Forwarded message --
From: Darren Hart mailto:darren.h...@intel.com>>
Date: Wed, Jun 13, 2012 at 2:19 PM
Subject: Re: Next question regarding development practices
To: Scott Rifenbark mailto:srifenb...@gmail.com>>
On 06/12/2012 11:34 AM, Scott Rifenbark wrote:
> Hi Darren,
>
> So check out section
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell.
> This talks about the whole devshell model.  One thing in this section is
> not current and that is the UI/Interfaces Configuration section
> reference in bitbake.conf file.  Regarding the section though, is this
> still a valid development model?  Is it worth keeping around in the docs?
>
> As you can tell, I value your opinions greatly :)
As I understand it, this is still a perfectly valid working model.
Someone was just recommending it this week on the list.

As for the bitbake.conf file... I'm not sure. I thought this would have
been controlled by the following in local.conf.

# If you do not use (or have installed) gnome-terminal you will need to
# uncomment these variables and set them to the terminal you wish to use
# when resolving patches which cannot be applied
# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN ARE:
# GNOME, SCREEN, XTERM and SCREEN
TERMCMD = "${SCREEN_TERMCMD}"
TERMCMDRUN = "${SCREEN_TERMCMDRUN}"

But... it clearly is not after some testing. Hrm... I don't see anything
matching in bitbake.conf either. Where this has migrated off to would be
a good question for the list, hopefully someone like Paul E. can answer
this quickly.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


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

[yocto] using a custom pre-built toolchain

[Dallas Clement]

I have a cross-toolchain supplied by an ARM SoC vendor which I need to
use to build my distro.  What is required to use a toolchain like this
instead of one of the yocto cross-toolchain tarballs?

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

Re: [yocto] using a custom pre-built toolchain

[Khem Raj]

On Tue, Jun 19, 2012 at 9:28 PM, Dallas Clement
 wrote:
> I have a cross-toolchain supplied by an ARM SoC vendor which I need to
> use to build my distro.  What is required to use a toolchain like this
> instead of one of the yocto cross-toolchain tarballs?
>

I answered this question just today for another mail thread please
search the ml for the same.
> Thanks
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] developing with devshell and effect of the bitbake.conf file

[Tomas Frydrych]

Hi Scott,

On 19/06/12 19:13, Rifenbark, Scott M wrote:
> Hi, I want to throw this out for discussion.  I recently was looking
> at a section in the YP Reference manual
> (http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell)
> where it talks about developing using devshell.  I asked Darren Hart
> if this was a valid development model and he says it is.

Absolutely, without devshell poky would be just a distro image builder,
devshell makes into a proper development tool, e.g. devshell is by far
the easiest way to develop/maintain patches (together with quilt) or to
tweak applications when debugging and testing.


> There is a
> part of the section though that talks about the bitbake.conf file.
> That section in the conf file does not seem to exist anymore.  And,
> Darren (after some testing) doesn't see how what is in the
> bitbake.conf file affects development with devshell.  Any comments
> welcome.

I think that bit of the manual is leftover from days of distant past.
The terminal selection it mentions generally happens automatically, but
can be forced by the OE_TERMINAL variable from local.conf, where it is
also documented.

Tomas

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

Re: [yocto] is it "IMAGE_INSTALL +=" or "IMAGE_INSTALL_append ="?

[Tomas Frydrych]

Hi,

On 19/06/12 19:47, Chris Tapp wrote:
> Is there a section that explains the order in which all these things
> happen? i.e. items in local.conf happen before/after...

IIRC, the evaluation orders is:

1. variables on the command line (e.g., 'MACHINE=beagleboard bitbake
myimage') are evaluated first,

2. variables in local.conf,

3. Rest depends on the order of things in bblayers.conf *and* how any
given layer.conf is implemented (some layers preppend their stuff to the
BBPATH and some layers append; from memory the Yocto layers prepend, but
layers from OE usually append, and this inconsistency makes for lot of
fun when combining layers into custom distro).

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