Attendees:
PaulE, MihaiL, MichaelH, LaurentuiS, TomZ, ScottR, SeanH, EranT, Amit, JessicaZ, Nitin, KevinS, BruceA, CorneliuxS, RossB, Saul and possibly others lurking

Minutes:
* Opens collection - 5 min (Song)

* Yocto 1.4 status - 10 min (Song/team)
- 1.4 / Master: Master is moving slower through the holidays due to Richard on vacation. Saul will be consolidating patches in stage/master_under_test. Milestone 2 will be delayed into the New Year and will be getting the SMART and SystemD changes, expect a systemd RFC in the next day or so.
- 1.3.1 / Danny (Ross): Richard merged Ross's danny-next into danny, expecting QA in early Jan with release time of Late Jan/ Early Feb.
- 1.2.2 / Denzil: Full pass testing due today, may have more patches pending.
- QA: Xmas break means people gone, expect lighter testing until 1/7
AR for QA Team: Plan 3 Full pass test cycles in Jan for M2, 1.2.2 and 1.3.1 (in that order).

* SWAT team rotation: Cristian I -> Andrei Dinu
- Thanks to Mihai L to point out the wiki page
- I will send email rotation reminders as we progress through the holidays.

* Opens - 2 min
- Eren: BSP for ALIX 3D3 BSP
He has started on the BSP and is working on graphics (x drivers), wanted some suggestions on kernel building strategies, Bruce mentioned the ELC-E talk and Darren's recent writeup.
- Cornel: Testopia
Announce it's usage and open to the Community as a way for Community Members and QA Teams can better collaborate. Wiki page is available
https://wiki.yoctoproject.org/wiki/Testopia and via Bugzilla http://www.bugzilla.yoctoproject.org (click on Product Dashboard)

* Team Sharing - 10 min
Amit: Checked in quickly say he will be gone about 1 month
Nitin: NUC BSP is now available in meta-intel layer, http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/next-unit-computing-introduction.html
PaulE: Working on Web-based layer Index tool to replace current manual wiki page see: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272
He will also be gone until 1/11/13.

Quick meeting thanks all

Sau!


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


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

On 12-12-18 10:45 AM, Marco C. wrote:

2012/12/9 Bruce Ashfield <bruce.ashfield@...>:

As Chris said, this way should still work, and it does work here for me.
There's
one thing that you may notice with kernel's that have split source/build
dirs
(like linux-yocto), is that once you have gone through the configure phase
and drop into the devshell you may not have KBUILT_OUTPUT set to the
build directory, and end up dropping files in the source dir .. which causes
you
mrproper and build issue.

I have a local append to devshell that sets:

d.setVar("KBUILD_OUTPUT", "${B}")

To make sure things work. If you need something like this as well, or have
problems with linux-yocot, I can arrange to have something like this added
by default. But since no one else has asked about it, I assumed no one else
is either using devshell, or they haven't run into it.

Cheers,

Bruce

Dear Bruce,
I'd like to have the same behaviour as before, so what you suggested
would suit me.
Could you please tell me where to add that line?
Fileneme and function.

Apply the patch to your yocto/oe-core repository (master branch, but
it should apply to danny as well). This will be part of my next
consolidated kernel pull request, so you'll only need to carry
it locally for a short time.

Cheers,

Bruce

Thank you
--
Marco Cavallini

2012/12/9 Bruce Ashfield <bruce.ashfield@...>:

On Sun, Dec 9, 2012 at 3:05 PM, Marco <koansoftware@...> wrote:

Hello,
I was used to work with oe-classic.
When I used oe-classic, often I used the 'devshell' option to try to
compile (make uImage) the kernel with the entire environment set up
correctly.
Now if I do the same procedure with Yocto 8 Danny it does not work.
For example I'm using a default configuration below:

1st step
---
MACHINE="beagleboard" bitbake -c devshell virtual/kernel

Build Configuration:
BB_VERSION = "1.16.0"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "poky"
DISTRO_VERSION = "1.3"
TUNE_FEATURES = "armv7a vfp neon cortexa8"
TARGET_FPU = "vfp-neon"
meta
meta-yocto
meta-yocto-bsp = "danny:09031ac2fc0f30ec577ee823fc61ff0e5d852e21"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 912 tasks of which 912 didn't need to be
rerun and all succeeded.


2nd step just after 1st
------------------------
MACHINE="beagleboard" bitbake -c devshell virtual/kernel

- Devshell starts in a new screen
------------------------
$ pwd

~/yocto-8-danny/poky/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.4.11+git1+a201268353c030d9fafe00f2041976f7437d9386_1+449f7f520350700858f21a5554b81cc8ad23267d-r4.3/linux

- lauch a kernel build (as I was used to do)
------------------------
$ make
scripts/kconfig/conf --silentoldconfig Kconfig
***
*** Configuration file ".config" not found!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
***
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by
`include/config/kernel.release'. Stop.


I would like to find out whether you can still do this and what is the new
way to go

As Chris said, this way should still work, and it does work here for me.
There's
one thing that you may notice with kernel's that have split source/build
dirs
(like linux-yocto), is that once you have gone through the configure phase
and drop into the devshell you may not have KBUILT_OUTPUT set to the
build directory, and end up dropping files in the source dir .. which causes
you
mrproper and build issue.

I have a local append to devshell that sets:

d.setVar("KBUILD_OUTPUT", "${B}")

To make sure things work. If you need something like this as well, or have
problems with linux-yocot, I can arrange to have something like this added
by default. But since no one else has asked about it, I assumed no one else
is either using devshell, or they haven't run into it.

Cheers,

Bruce

TIA
--
Marco Cavallini
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at
its end"

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

Hi Sean,

Your summary is correct as far as current ADT installer's capabilities goes. I think in the ADT manual we talked about besides using ADT installer to setup an application cross development environment, user can also using a toolchain tarball. This is discussed in another email thread atm. Originally the toolchain tarball sysroot is pretty much canned so very limited for user to customize to match their target images. For 1.3, Mark has added the capability to generate the toolchain tarball that matching the target image via bitbake -c populate_sdk image. As far as eclipse plug-in goes, you can specify you desired toolchain and sysroot combination whether they're installed via adt-installer or toolchain tarball.

BTW, one of the features that we will be working on for adt-installer is to make it base on sstate instead of the current opkg and ipk adt-repo. In this way, we eliminate the dependency on particular ipk package format also, gives user the flexibility to customized their sysroot instead of the the predefined images rootfs.

Thanks,
Jessica

On Sat, Dec 15, 2012 at 5:22 AM, Wolfgang Denk <wd@...> wrote:

Hi,

can anybody explain to me the systematics of the git tags ysed to mark
the Yocto / Poky releases?

For example, for Yocto 1.2 and before, we have release tags like
denzil-7.0, edison-6.0, bernard-5.0, laverne-4.0, etc.

Some parts of the current 1.3 Yocto release refer to it as "Poky 8.0"
or Version "8.0 Danny", see for example here:
https://www.yoctoproject.org/download/yocto-project-13-poky-80

However, there is no such release tag as "danny-8.0".

You are correct. That was an oversight on my part. I've corrected it.

Instead, there is a tag "1.3" - but there are no similar tags as "1.1"
or "1.2" for the earlier releases?


What is the system in this numbering / tagging?

Milestones: 1.x_My.rcz
Major releases: 1.x and they should also get the name-x.y.z tag

Releated: is there any document which explains the branch names being
used for development. for example, how can I find out ("officially")
what the branch name for Yocto 1.4 will be / is ?

When Richard tells me :)

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
A committee is a group that keeps the minutes and loses hours.
-- Milton Berle
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--
Elizabeth Flanagan
Yocto Project
Build and Release

Jessica and Mark,

Thank you for the responses. It appears that there is another thread on the
same subject. Let me feedback what I am seeing and hearing:

The quick start guide
(http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.
html) and various presentation slides showing the Poky Work Flow / Yocto
Project Development Environment show an output of the image and Application
Development SDK. When I include the option to build the SDK in a Yoicto1.3
Danny build, I see in the /../tmp/deploy/sdk is the ADT installer. To me the
ADT installer installs the toolchain and the rootfs to build applications.
Also, the ADT installer only installs a rootfs based on pre-set images like
core-image-sato, core-image-minimal, etc., and doesn't address a custom
rootfs that may have more or less support than the standard images. The
Eclipse plug in adds the capability to Eclipse to link to the toolchain and
rootfs installed by the ADT installer.

Does this sound correct?

Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176

On 12/18/2012 11:56 AM, Tom Zanussi wrote:

On Tue, 2012-12-18 at 11:37 -0500, Philip Balister wrote:

On 12/18/2012 09:33 AM, Tom Zanussi wrote:

On Tue, 2012-12-18 at 09:13 -0500, Philip Balister wrote:

On 12/17/2012 12:51 PM, tom.zanussi@... wrote:

From: Tom Zanussi <tom.zanussi@...>

Add a new yocto_layer_create() function that will be used to generate
a generic yocto layer (for the new 'yocto-layer' command).

How is a "yocto layer" different from an OpenEmbedded layer? If you
insist on "yocto layter", wouldn't "Yocto Project layer" be more accurate.

Technically it isn't any different, but it's based on the template
engine code and templates that make up the 'Yocto BSP Tools', which for
various reasons (they create Yocto-compliant BSP layers, something not
of interest to OpenEmbedded proper, and it probably doesn't make sense
to clutter oe-core with a bunch of 'template data', etc) live in poky
and not oe-core.

Actually, BSP's should work standalone with oe-core, so it is of interest.

As such, the new tool is named 'yocto-layer' to match the other existing
Yocto BSP tools, 'yocto-bsp' and 'yocto-kernel'.

I will now get pedantic. <rday mode on>

The meta-yocto layer functions as a distro layer. So referring to things
as yocto this and yocto that, suggests they only work with the
meta-yocto layer.

So it doesn't make sense to me to put general purpose tools in a distro
layer.

<rday mode off>

Right, none of the yocto- tools has anything to do with the meta-yocto
layer, so if that's how it's taken, then, yeah, it's misleading.

It wouldn't bother me to do a global search and replace of 'yocto' with
'oe' for the tools - I guess that would imply it would all be moving
into oe-core, though. Is that what you're suggesting?

I am not sure what the best way to clear up terminology is at the
moment, and given it is he week before Christmas, a number of people I
would like to discuss this with are on holiday, so we can defer the
solution until next year.

In the meantime, I have no problem with people getting work done, so I
have no objection to the patch moving forward.

Philip

Tom

Tom

One of our goals for next year should be to clean up our terminology to
reduce confusion in the user community.

Philip

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 56 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8985544..d406e79 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1352,6 +1352,62 @@ def expand_targets(context, bsp_output_dir):
return target_files


+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ if os.path.exists(bsp_output_dir):
+ print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
+ sys.exit(1)
+
+ properties = None
+
+ if properties_file:
+ try:
+ infile = open(properties_file, "r")
+ except IOError:
+ print "Couldn't open properties file %s for reading, exiting" % properties_file
+ sys.exit(1)
+
+ properties = json.load(infile)
+
+ os.mkdir(bsp_output_dir)
+
+ context = create_context(machine, arch, scripts_path)
+ target_files = expand_targets(context, bsp_output_dir)
+
+ input_lines = gather_inputlines(target_files)
+
+ program_lines = []
+
+ gen_program_header_lines(program_lines)
+
+ gen_initial_property_vals(input_lines, program_lines)
+
+ if properties:
+ gen_supplied_property_vals(properties, program_lines)
+
+ gen_program_machine_lines(machine, program_lines)
+
+ if not properties:
+ gen_program_input_lines(input_lines, program_lines, context)
+
+ gen_program_lines(target_files, program_lines)
+
+ run_program_lines(program_lines, codedump)
+
+ print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+
def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
"""
Create bsp

On Tue, 2012-12-18 at 11:37 -0500, Philip Balister wrote:

On 12/18/2012 09:33 AM, Tom Zanussi wrote:

On Tue, 2012-12-18 at 09:13 -0500, Philip Balister wrote:

On 12/17/2012 12:51 PM, tom.zanussi@... wrote:

From: Tom Zanussi <tom.zanussi@...>

Add a new yocto_layer_create() function that will be used to generate
a generic yocto layer (for the new 'yocto-layer' command).

How is a "yocto layer" different from an OpenEmbedded layer? If you
insist on "yocto layter", wouldn't "Yocto Project layer" be more accurate.

Technically it isn't any different, but it's based on the template
engine code and templates that make up the 'Yocto BSP Tools', which for
various reasons (they create Yocto-compliant BSP layers, something not
of interest to OpenEmbedded proper, and it probably doesn't make sense
to clutter oe-core with a bunch of 'template data', etc) live in poky
and not oe-core.

Actually, BSP's should work standalone with oe-core, so it is of interest.

As such, the new tool is named 'yocto-layer' to match the other existing
Yocto BSP tools, 'yocto-bsp' and 'yocto-kernel'.

I will now get pedantic. <rday mode on>

The meta-yocto layer functions as a distro layer. So referring to things
as yocto this and yocto that, suggests they only work with the
meta-yocto layer.

So it doesn't make sense to me to put general purpose tools in a distro
layer.

<rday mode off>

Right, none of the yocto- tools has anything to do with the meta-yocto
layer, so if that's how it's taken, then, yeah, it's misleading.

It wouldn't bother me to do a global search and replace of 'yocto' with
'oe' for the tools - I guess that would imply it would all be moving
into oe-core, though. Is that what you're suggesting?

Tom

Tom

One of our goals for next year should be to clean up our terminology to
reduce confusion in the user community.

Philip

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 56 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8985544..d406e79 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1352,6 +1352,62 @@ def expand_targets(context, bsp_output_dir):
return target_files


+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ if os.path.exists(bsp_output_dir):
+ print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
+ sys.exit(1)
+
+ properties = None
+
+ if properties_file:
+ try:
+ infile = open(properties_file, "r")
+ except IOError:
+ print "Couldn't open properties file %s for reading, exiting" % properties_file
+ sys.exit(1)
+
+ properties = json.load(infile)
+
+ os.mkdir(bsp_output_dir)
+
+ context = create_context(machine, arch, scripts_path)
+ target_files = expand_targets(context, bsp_output_dir)
+
+ input_lines = gather_inputlines(target_files)
+
+ program_lines = []
+
+ gen_program_header_lines(program_lines)
+
+ gen_initial_property_vals(input_lines, program_lines)
+
+ if properties:
+ gen_supplied_property_vals(properties, program_lines)
+
+ gen_program_machine_lines(machine, program_lines)
+
+ if not properties:
+ gen_program_input_lines(input_lines, program_lines, context)
+
+ gen_program_lines(target_files, program_lines)
+
+ run_program_lines(program_lines, codedump)
+
+ print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+
def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
"""
Create bsp

On 12/18/2012 09:33 AM, Tom Zanussi wrote:

On Tue, 2012-12-18 at 09:13 -0500, Philip Balister wrote:

On 12/17/2012 12:51 PM, tom.zanussi@... wrote:

From: Tom Zanussi <tom.zanussi@...>

Add a new yocto_layer_create() function that will be used to generate
a generic yocto layer (for the new 'yocto-layer' command).

How is a "yocto layer" different from an OpenEmbedded layer? If you
insist on "yocto layter", wouldn't "Yocto Project layer" be more accurate.

Technically it isn't any different, but it's based on the template
engine code and templates that make up the 'Yocto BSP Tools', which for
various reasons (they create Yocto-compliant BSP layers, something not
of interest to OpenEmbedded proper, and it probably doesn't make sense
to clutter oe-core with a bunch of 'template data', etc) live in poky
and not oe-core.

Actually, BSP's should work standalone with oe-core, so it is of interest.

As such, the new tool is named 'yocto-layer' to match the other existing
Yocto BSP tools, 'yocto-bsp' and 'yocto-kernel'.

I will now get pedantic. <rday mode on>

The meta-yocto layer functions as a distro layer. So referring to things
as yocto this and yocto that, suggests they only work with the
meta-yocto layer.

So it doesn't make sense to me to put general purpose tools in a distro
layer.

<rday mode off>

Tom

One of our goals for next year should be to clean up our terminology to
reduce confusion in the user community.

Philip

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 56 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8985544..d406e79 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1352,6 +1352,62 @@ def expand_targets(context, bsp_output_dir):
return target_files


+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ if os.path.exists(bsp_output_dir):
+ print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
+ sys.exit(1)
+
+ properties = None
+
+ if properties_file:
+ try:
+ infile = open(properties_file, "r")
+ except IOError:
+ print "Couldn't open properties file %s for reading, exiting" % properties_file
+ sys.exit(1)
+
+ properties = json.load(infile)
+
+ os.mkdir(bsp_output_dir)
+
+ context = create_context(machine, arch, scripts_path)
+ target_files = expand_targets(context, bsp_output_dir)
+
+ input_lines = gather_inputlines(target_files)
+
+ program_lines = []
+
+ gen_program_header_lines(program_lines)
+
+ gen_initial_property_vals(input_lines, program_lines)
+
+ if properties:
+ gen_supplied_property_vals(properties, program_lines)
+
+ gen_program_machine_lines(machine, program_lines)
+
+ if not properties:
+ gen_program_input_lines(input_lines, program_lines, context)
+
+ gen_program_lines(target_files, program_lines)
+
+ run_program_lines(program_lines, codedump)
+
+ print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+
def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
"""
Create bsp

On Tue, Dec 18, 2012 at 08:28:32PM +0800, Biao wrote:

http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/

I will try to give some feedback after finishing the reading.
But for now, there are some silly questions:
1. There is a base_do_fetch() {}, I did not find the explanation of the keyword of 'base' in the manual, do i miss something?

I don't know the internals of bitbake on that level but as far as I
understand, bitbake uses the name of the bbclass file as a prefix in the
function names for the sake of abstraction. So, as in autotools.bbclass,
the tasks defined in base.bbclass gets prefixes with "base_" keyword.
Probably, it's related with mapping the function names when 'inherit'
keyword is used.

I'm not clear on this topic either. A hand from an experienced bitbake
guru would be really helpful here. The type of abstraction in bitbake
should be explained in detail as well as how EXPORT_FUNCTION works.

Any volunteers?

2. There is 'bb.note' and 'bbnote' in the code example, is it a type-mistake or something else?

No, this is not a mistake. You can use python as well as shell functions
in bitbake recipes and classes. See 'python' keyword in function
definitons where bb.note is used. That's why python function "bb.note()"
is used to print log information. Without python keyword, the bitbake
function is treated as shell.

Regards,
Eren

--
. 73! DE TA1AET
http://linkedin.com/in/erenturkay

2012/12/9 Bruce Ashfield <bruce.ashfield@...>:

As Chris said, this way should still work, and it does work here for me.
There's
one thing that you may notice with kernel's that have split source/build
dirs
(like linux-yocto), is that once you have gone through the configure phase
and drop into the devshell you may not have KBUILT_OUTPUT set to the
build directory, and end up dropping files in the source dir .. which causes
you
mrproper and build issue.

I have a local append to devshell that sets:

d.setVar("KBUILD_OUTPUT", "${B}")

To make sure things work. If you need something like this as well, or have
problems with linux-yocot, I can arrange to have something like this added
by default. But since no one else has asked about it, I assumed no one else
is either using devshell, or they haven't run into it.

Cheers,

Bruce

Dear Bruce,
I'd like to have the same behaviour as before, so what you suggested
would suit me.
Could you please tell me where to add that line?
Fileneme and function.

Thank you
--
Marco Cavallini

2012/12/9 Bruce Ashfield <bruce.ashfield@...>:

On Sun, Dec 9, 2012 at 3:05 PM, Marco <koansoftware@...> wrote:

Hello,
I was used to work with oe-classic.
When I used oe-classic, often I used the 'devshell' option to try to
compile (make uImage) the kernel with the entire environment set up
correctly.
Now if I do the same procedure with Yocto 8 Danny it does not work.
For example I'm using a default configuration below:

1st step
---
MACHINE="beagleboard" bitbake -c devshell virtual/kernel

Build Configuration:
BB_VERSION = "1.16.0"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "poky"
DISTRO_VERSION = "1.3"
TUNE_FEATURES = "armv7a vfp neon cortexa8"
TARGET_FPU = "vfp-neon"
meta
meta-yocto
meta-yocto-bsp = "danny:09031ac2fc0f30ec577ee823fc61ff0e5d852e21"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 912 tasks of which 912 didn't need to be
rerun and all succeeded.


2nd step just after 1st
------------------------
MACHINE="beagleboard" bitbake -c devshell virtual/kernel

- Devshell starts in a new screen
------------------------
$ pwd

~/yocto-8-danny/poky/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.4.11+git1+a201268353c030d9fafe00f2041976f7437d9386_1+449f7f520350700858f21a5554b81cc8ad23267d-r4.3/linux

- lauch a kernel build (as I was used to do)
------------------------
$ make
scripts/kconfig/conf --silentoldconfig Kconfig
***
*** Configuration file ".config" not found!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
***
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by
`include/config/kernel.release'. Stop.


I would like to find out whether you can still do this and what is the new
way to go

As Chris said, this way should still work, and it does work here for me.
There's
one thing that you may notice with kernel's that have split source/build
dirs
(like linux-yocto), is that once you have gone through the configure phase
and drop into the devshell you may not have KBUILT_OUTPUT set to the
build directory, and end up dropping files in the source dir .. which causes
you
mrproper and build issue.

I have a local append to devshell that sets:

d.setVar("KBUILD_OUTPUT", "${B}")

To make sure things work. If you need something like this as well, or have
problems with linux-yocot, I can arrange to have something like this added
by default. But since no one else has asked about it, I assumed no one else
is either using devshell, or they haven't run into it.

Cheers,

Bruce

TIA
--
Marco Cavallini
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at
its end"

On Tue, 2012-12-18 at 09:13 -0500, Philip Balister wrote:

On 12/17/2012 12:51 PM, tom.zanussi@... wrote:

From: Tom Zanussi <tom.zanussi@...>

Add a new yocto_layer_create() function that will be used to generate
a generic yocto layer (for the new 'yocto-layer' command).

How is a "yocto layer" different from an OpenEmbedded layer? If you
insist on "yocto layter", wouldn't "Yocto Project layer" be more accurate.

Technically it isn't any different, but it's based on the template
engine code and templates that make up the 'Yocto BSP Tools', which for
various reasons (they create Yocto-compliant BSP layers, something not
of interest to OpenEmbedded proper, and it probably doesn't make sense
to clutter oe-core with a bunch of 'template data', etc) live in poky
and not oe-core.

As such, the new tool is named 'yocto-layer' to match the other existing
Yocto BSP tools, 'yocto-bsp' and 'yocto-kernel'.

Tom

One of our goals for next year should be to clean up our terminology to
reduce confusion in the user community.

Philip

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 56 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8985544..d406e79 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1352,6 +1352,62 @@ def expand_targets(context, bsp_output_dir):
return target_files


+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ if os.path.exists(bsp_output_dir):
+ print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
+ sys.exit(1)
+
+ properties = None
+
+ if properties_file:
+ try:
+ infile = open(properties_file, "r")
+ except IOError:
+ print "Couldn't open properties file %s for reading, exiting" % properties_file
+ sys.exit(1)
+
+ properties = json.load(infile)
+
+ os.mkdir(bsp_output_dir)
+
+ context = create_context(machine, arch, scripts_path)
+ target_files = expand_targets(context, bsp_output_dir)
+
+ input_lines = gather_inputlines(target_files)
+
+ program_lines = []
+
+ gen_program_header_lines(program_lines)
+
+ gen_initial_property_vals(input_lines, program_lines)
+
+ if properties:
+ gen_supplied_property_vals(properties, program_lines)
+
+ gen_program_machine_lines(machine, program_lines)
+
+ if not properties:
+ gen_program_input_lines(input_lines, program_lines, context)
+
+ gen_program_lines(target_files, program_lines)
+
+ run_program_lines(program_lines, codedump)
+
+ print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+
def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
"""
Create bsp

On 12/17/2012 12:51 PM, tom.zanussi@... wrote:

From: Tom Zanussi <tom.zanussi@...>

Add a new yocto_layer_create() function that will be used to generate
a generic yocto layer (for the new 'yocto-layer' command).

How is a "yocto layer" different from an OpenEmbedded layer? If you
insist on "yocto layter", wouldn't "Yocto Project layer" be more accurate.

One of our goals for next year should be to clean up our terminology to
reduce confusion in the user community.

Philip

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
scripts/lib/bsp/engine.py | 56 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)

diff --git a/scripts/lib/bsp/engine.py b/scripts/lib/bsp/engine.py
index 8985544..d406e79 100644
--- a/scripts/lib/bsp/engine.py
+++ b/scripts/lib/bsp/engine.py
@@ -1352,6 +1352,62 @@ def expand_targets(context, bsp_output_dir):
return target_files


+def yocto_layer_create(layer_name, scripts_path, layer_output_dir, codedump, properties_file):
+ """
+ Create yocto layer
+
+ layer_name - user-defined layer name
+ scripts_path - absolute path to yocto /scripts dir
+ bsp_output_dir - dirname to create for BSP
+ codedump - dump generated code to bspgen.out
+ properties_file - use values from here if nonempty i.e no prompting
+
+ arch - the arch for a generic layer is 'generic-layer', defined in
+ scripts/lib/bsp/substrate/target/generic-layer
+ """
+ if os.path.exists(bsp_output_dir):
+ print "\nBSP output dir already exists, exiting. (%s)" % bsp_output_dir
+ sys.exit(1)
+
+ properties = None
+
+ if properties_file:
+ try:
+ infile = open(properties_file, "r")
+ except IOError:
+ print "Couldn't open properties file %s for reading, exiting" % properties_file
+ sys.exit(1)
+
+ properties = json.load(infile)
+
+ os.mkdir(bsp_output_dir)
+
+ context = create_context(machine, arch, scripts_path)
+ target_files = expand_targets(context, bsp_output_dir)
+
+ input_lines = gather_inputlines(target_files)
+
+ program_lines = []
+
+ gen_program_header_lines(program_lines)
+
+ gen_initial_property_vals(input_lines, program_lines)
+
+ if properties:
+ gen_supplied_property_vals(properties, program_lines)
+
+ gen_program_machine_lines(machine, program_lines)
+
+ if not properties:
+ gen_program_input_lines(input_lines, program_lines, context)
+
+ gen_program_lines(target_files, program_lines)
+
+ run_program_lines(program_lines, codedump)
+
+ print "New %s BSP created in %s" % (arch, bsp_output_dir)
+
+
def yocto_bsp_create(machine, arch, scripts_path, bsp_output_dir, codedump, properties_file):
"""
Create bsp

On 15 December 2012 13:22, Wolfgang Denk <wd@...> wrote:

can anybody explain to me the systematics of the git tags ysed to mark
the Yocto / Poky releases?

For example, for Yocto 1.2 and before, we have release tags like
denzil-7.0, edison-6.0, bernard-5.0, laverne-4.0, etc.

Some parts of the current 1.3 Yocto release refer to it as "Poky 8.0"
or Version "8.0 Danny", see for example here:
https://www.yoctoproject.org/download/yocto-project-13-poky-80

However, there is no such release tag as "danny-8.0".

Instead, there is a tag "1.3" - but there are no similar tags as "1.1"
or "1.2" for the earlier releases?


What is the system in this numbering / tagging?

I think the problem is that there isn't a system - there's a mix of tag naming.

If you know the name of a release and the corresponding oe-core/Poky
versions all the tags are present, but that's not ideal.

Releated: is there any document which explains the branch names being
used for development. for example, how can I find out ("officially")
what the branch name for Yocto 1.4 will be / is ?

The name for 1.4 is top top secret until the release. It will be
decided by Richard and he keeps it a mystery until the release.

The names are in themes, the Inky / Clyde / Blinky series is easily
googlable, as is Laverne / Bernard / Edison. Denzil and Danny, well,
Richard thought he told me what the theme was but I can't remember and
he won't tell me again. :(

Ross

Hi Jessica,

Zhang, Jessica wrote, On 15.12.2012 00:37:

Hi Timo,

Sorry for the delay, but finally got a chance to look into these
patches. I like how it automate the docgen and integrate them into
eclipse. The concern that I'm having is, it seems converting all the
Yocto Project Docs, originally I thought only for ADT manual.

The first version of this RFC was meant to be a proof of concept,
that's why I only included the ADT manual.
One of the reasons why I integrated all manuals are the links between
the different documents. The links pointing to documentation at
yoctoprojects.org are rewritten to point to the documentation inside
eclipse (I'm using the same mechanism as the mega-manual). So there's
no need for internet connectivity and the user doesn't have to leave
eclipse.

So to view
these doc in eclipse are nice, but since we don't have some
corresponding feature support in eclipse plug-in, it'll look awkward to
combine these docs with ADT plugin.

I guess for some manuals it makes more sense to have them inside of
eclipse than for others. But I personally like that everything is in
one place, either just on the website, in the PDFs or in eclipse.

BTW, to support our bitbake
commander plug-in running on windows usage, we recently split the
plug-in into 2 features: ADT and bitbake commander and the doc plug-in
is part of ADT feature. So I'd suggest, if we want to show all the docs,
probably create a separate Yocto Doc Feature. If we want to combine with
ADT plug-in, then probably only covert the ADT manual content generation
and integration. Make sense?

Yes. Creating a separate feature seems like a good idea. I will rewrite the patch series accordingly.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Timo Müller
Sent: Wednesday, December 12, 2012 5:10 AM
To: yocto@...
Cc: Timo Mueller
Subject: Re: [yocto] [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse

Hi,

mail@... wrote, On 06.12.2012 16:48:

From: Timo Mueller <timo.mueller@...>

Hi,

since the last proposal some things have changed:
1. Eclipse help generation is now part of the yocto-docs project
(currently available in the origin/timo branch) 2. We agreed that the
plugin should be licensed under the EPL v1.0 instead of having a
separate documentation plugin licensed under the CCA-SA 2.0 UK.

The last patch set was adding generated eclipse help files (html) to
the repository. One major change in this patch series is that I
extended the plugin build system to integrate the generation into the
build process. Thus keeping the eclipse help and the official
documentation in sync is now automated.
Also the eclipse help is now part of the user.doc plugin and no longer
contained in a separate plugin/feature.

Rational from the original patch:
<snip>
the documentation of the yocto project can currently be viewed online
or as a separate pdf. When using the eclipse ide to develop software
on base of a yocto sysroot and toolchain it would be convenient to
access the relevant parts of the documentation from within the ide.
</snip>
<snip>
I have intergrated this
documentation in the ide and it can now be accessed through the
eclipse help center (Help -> Help Contents).
</snip>

Best regards
Timo

Timo Mueller (7):
plugins/sdk.ide.doc.user: Add empty eclipse help
plugins/sdk.ide.doc.user: Add about.html to prepare addition of yocto
documentation
scripts/generate_doc.sh: Add script to handle eclipse help generation
plugins/sdk.ide.doc.user: Add yocto documentation to the table of
contents
scripts/generat-doc.sh: Copy generated eclipse help into the user.doc
plugin
scripts/build.sh: Add documentation generation to the default build
(TEMPORARY): Use origin/timo branch of yocto docs project

.../META-INF/MANIFEST.MF | 3 +-
plugins/org.yocto.sdk.ide.doc.user/about.html.in | 166 ++++++++++++++++++++
.../org.yocto.sdk.ide.doc.user/build.properties | 9 +-
plugins/org.yocto.sdk.ide.doc.user/html/book.css | 1 +
plugins/org.yocto.sdk.ide.doc.user/plugin.xml | 31 ++++
plugins/org.yocto.sdk.ide.doc.user/toc.xml | 21 +++
scripts/build.sh | 7 +
scripts/generate_doc.sh | 91 +++++++++++
8 files changed, 326 insertions(+), 3 deletions(-)
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/about.html.in
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/html/book.css
create mode 100644 plugins/org.yocto.sdk.ide.doc.user/toc.xml
create mode 100755 scripts/generate_doc.sh

The name of the poky-ref-manual will be changed to ref-manual. This
change has an impact on this patch series, since the name is used in the
generate-doc shell script.
But with the temporary fix in patch 7, the timo branch is used, which
will for the time being remain unaffected by the name changes. This
way you can test the documentation integration proposed in this patch
set.I would like to get your opinion on the general approach to
integrate the documentation into eclipse. If it fits into the
eclipse-poky project in general, I will rewrite this patch series to
reflect the changes. The rewrite will also remove the "the" from the
different help chapters (as Scott pointed out to me).
I also agreed with Scott that once this approach is agreed on I will
provide the necessary patches to the timo branch of the yocto-docs
project and he will merge the eclipse generation into the master of the
project.

Best regards,
Timo

PS: I also apologize for not signing off the patch series. I will
make up for that in the reworked patches.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

Best regards,
Timo

In message <20121215132238.503DC201C62@...> I wrote:

Hi,

can anybody explain to me the systematics of the git tags ysed to mark
the Yocto / Poky releases?

For example, for Yocto 1.2 and before, we have release tags like
denzil-7.0, edison-6.0, bernard-5.0, laverne-4.0, etc.

Some parts of the current 1.3 Yocto release refer to it as "Poky 8.0"
or Version "8.0 Danny", see for example here:
https://www.yoctoproject.org/download/yocto-project-13-poky-80

However, there is no such release tag as "danny-8.0".

Instead, there is a tag "1.3" - but there are no similar tags as "1.1"
or "1.2" for the earlier releases?


What is the system in this numbering / tagging?


Releated: is there any document which explains the branch names being
used for development. for example, how can I find out ("officially")
what the branch name for Yocto 1.4 will be / is ?

No comments anybody? Thanks in advance!

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.

On 12/15/2012 04:18 AM, Trevor Woerner wrote:

Is there a chance this can get included?
____________________

I believe a rebase is needed and please sent to oe-core mailing list.

Thanks
Sau!

___________________________

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

Hi,

I'm glad to hear that the bitbake manual is getting an update, and I'm sure you guys know a lot of debugging tricks that I don't know.

Can you please include a section on debugging bitbake build errors (beyond logs, -D, and -v)? In other words, what's the best way to instrument or hack bitbake when debugging errors in the build process?

I sometimes hack at the python to better understand what's going on, so I'm interested to see what the experts do.

Thanks,

Bob