Date   

Minutes: Yocto Project Technical Team Meeting - Tuesday, December 11, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Saul Wold <sgw@...>
 

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


Re: bitbake -c devshell option

Bruce Ashfield <bruce.ashfield@...>
 

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


Re: IMHO, cross-compile/toolchain examples should use non-x86 arches

Zhang, Jessica
 

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

-----Original Message-----
From: Sean Liming [mailto:sean.liming@...]
Sent: Tuesday, December 18, 2012 9:36 AM
To: Zhang, Jessica; 'Mark Hatle'; yocto@...
Subject: RE: [yocto] IMHO, cross-compile/toolchain examples should use non-x86 arches

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

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Zhang, Jessica
Sent: Monday, December 17, 2012 8:40 AM
To: Mark Hatle; yocto@...
Subject: Re: [yocto] IMHO, cross-compile/toolchain examples should use
non-x86 arches

Or in Yocto Project context, we kind of use ADT more inclusive that
referring
what Mark talked about SDK, the eclipse plug-in and other developers
tools.
And we don't call out SDK that much.

--Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Mark Hatle
Sent: Monday, December 17, 2012 7:48 AM
To: yocto@...
Subject: Re: [yocto] IMHO, cross-compile/toolchain examples should use
non-x86 arches

On 12/16/12 4:57 PM, Sean Liming wrote:

My 2c (USD) is for clarity on ADT vs. SDK vs. Toolchain.
The biggest clarify problem I've seen is the terms being intermingled.
There
are clear definitions for each.

Toolchain, the compiler and related tools that enable compiling
software
for
a given target.

SDK - Software Development Kit - On OE-Core this purpose of this is to
enable developing software to be run on a specific target environment,
generally also constructed from OE-Core. The SDK consists of three
primary
components:
1) environment setup files - these configure the compilation
environment
with the right settings
2) nativesdk software - these are applications that run on the
-host-
system
to assist in compiling software for the target (this includes the
target
toolchain.)
3) target sysroot - The sysroot is the collection of libraries,
headers
and
assorted items that are compiled for the target. A sysroot is setup
in a
similar
fashion as a target's root filesystem.

ADT - Application Developer Tool - This is an Eclipse component that
can
use
the SDK, generated by OE-Core, to enable application development
within the Eclipse framework. (I may be slightly wrong on this item,
as people
have
told me in the past there are command line parts to the ADT.... but
the
ADT
itself is -not- the
SDK.)

--Mark

Regards,

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

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Sunday, December 16, 2012 8:55 AM
To: Yocto discussion list
Subject: [yocto] IMHO, cross-compile/toolchain examples should use
non-
x86 arches


a general preference on my part, but i think it would be useful
if any
yocto
docs that are discussing toolchains or cross-compilation or the
like use
*non*-x86 architectures to get the point across.

for example, consider the current application developer's guide.
part of it uses, as an example, the toolchain installer
poky-eglibc-x86_64-i586-
toolchain-gmae-1.4.sh. while this works just fine, of course, what
it
does is
potentially co-mingle both the dev host content and target host
content, making it harder than necessary for the reader to draw a
clear distinction between the two.

if any example related to compilation or a toolchain involves,
say, an
*arm*
target, then it's *immediately* obvious (using the "file"
command) whether something belongs on the dev host or on the target.

also, if you're using x86 for both dev content and target
content, you
run
the risk of an example working by accident since you're picking up
natively-
installed tools when you shouldn't be. if you use a non-x86 arch,
there's
little
chance of that happening.

just my $0.02 (Cdn).

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


Re: Git tag systematics ?

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

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


Re: IMHO, cross-compile/toolchain examples should use non-x86 arches

Sean Liming <sean.liming@...>
 

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

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Zhang, Jessica
Sent: Monday, December 17, 2012 8:40 AM
To: Mark Hatle; yocto@...
Subject: Re: [yocto] IMHO, cross-compile/toolchain examples should use
non-x86 arches

Or in Yocto Project context, we kind of use ADT more inclusive that
referring
what Mark talked about SDK, the eclipse plug-in and other developers
tools.
And we don't call out SDK that much.

--Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Mark Hatle
Sent: Monday, December 17, 2012 7:48 AM
To: yocto@...
Subject: Re: [yocto] IMHO, cross-compile/toolchain examples should use
non-x86 arches

On 12/16/12 4:57 PM, Sean Liming wrote:

My 2c (USD) is for clarity on ADT vs. SDK vs. Toolchain.
The biggest clarify problem I've seen is the terms being intermingled.
There
are clear definitions for each.

Toolchain, the compiler and related tools that enable compiling software
for
a given target.

SDK - Software Development Kit - On OE-Core this purpose of this is to
enable developing software to be run on a specific target environment,
generally also constructed from OE-Core. The SDK consists of three
primary
components:
1) environment setup files - these configure the compilation
environment
with the right settings
2) nativesdk software - these are applications that run on the -host-
system
to assist in compiling software for the target (this includes the target
toolchain.)
3) target sysroot - The sysroot is the collection of libraries, headers
and
assorted items that are compiled for the target. A sysroot is setup in a
similar
fashion as a target's root filesystem.

ADT - Application Developer Tool - This is an Eclipse component that can
use
the SDK, generated by OE-Core, to enable application development within
the Eclipse framework. (I may be slightly wrong on this item, as people
have
told me in the past there are command line parts to the ADT.... but the
ADT
itself is -not- the
SDK.)

--Mark

Regards,

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

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Sunday, December 16, 2012 8:55 AM
To: Yocto discussion list
Subject: [yocto] IMHO, cross-compile/toolchain examples should use
non-
x86 arches


a general preference on my part, but i think it would be useful if
any
yocto
docs that are discussing toolchains or cross-compilation or the like
use
*non*-x86 architectures to get the point across.

for example, consider the current application developer's guide.
part of it uses, as an example, the toolchain installer
poky-eglibc-x86_64-i586-
toolchain-gmae-1.4.sh. while this works just fine, of course, what
it
does is
potentially co-mingle both the dev host content and target host
content, making it harder than necessary for the reader to draw a
clear distinction between the two.

if any example related to compilation or a toolchain involves,
say, an
*arm*
target, then it's *immediately* obvious (using the "file"
command) whether something belongs on the dev host or on the target.

also, if you're using x86 for both dev content and target content,
you
run
the risk of an example working by accident since you're picking up
natively-
installed tools when you shouldn't be. if you use a non-x86 arch,
there's
little
chance of that happening.

just my $0.02 (Cdn).

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


Re: [PATCH 1/5] scripts/lib/bsp/engine.py: add yocto_layer_create()

Philip Balister
 

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





Re: [PATCH 1/5] scripts/lib/bsp/engine.py: add yocto_layer_create()

Tom Zanussi <tom.zanussi@...>
 

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



Re: [PATCH 1/5] scripts/lib/bsp/engine.py: add yocto_layer_create()

Philip Balister
 

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



Re: Where does the bitbake get the variable "TOPDIR"

Eren Türkay <eren@...>
 

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


Re: bitbake -c devshell option

Marco C. <koansoftware@...>
 

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"


Re: [PATCH 1/5] scripts/lib/bsp/engine.py: add yocto_layer_create()

Tom Zanussi <tom.zanussi@...>
 

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


Re: [PATCH 1/5] scripts/lib/bsp/engine.py: add yocto_layer_create()

Philip Balister
 

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


How to use JRE (Java Runtime) in Yocto Projects

Raul Mu?oz
 

Hello all,

I'm using yocto project to create a linux for a IMX28.

I currently insert these layers:

poky/meta
poky/meta-yocto
meta-fsl-arm
meta-openembedded/meta-oe

I want to use JRE (Java Runtime) like openJDK, and I saw that have some existing layers that provide this features.

Specifically:

meta-java
meta-oracle-java

What is the easy way to use JAVA with yocto?

Thans for all help.

--
Raul Rosetto Muñoz


Re: Where does the bitbake get the variable "TOPDIR"

Bill Traynor <wmat@...>
 




On Tue, Dec 18, 2012 at 7:28 AM, Biao <huanmateme@...> wrote:

At 2012-12-17 23:37:52,"Eren Türkay" <eren@...> wrote:
>On Mon, Dec 17, 2012 at 05:06:26PM +0800, Biao wrote:
>> Greetings, 
>> 
>> I am a newbie tying to understand how bitbake works.
>> There is one line as BBPATH = "${TOPDIR}" in the mybuild/conf/bblayers.conf, i would like to know where the TOPDIR is defined? 
>
>It's defind in "lib/bb/parse/parse_py/ConfHandler.py:36". When TOPDIR is
>not defined in any of the bitbake configuration files, it's set to
>current working directory automatically.
>
The whole picture of how bitbake works is missing from the Manual of the bitbake, which typically should be(I guess) :
1. Set some environment variables like "TOPDIR, THISDIR..."

2. Looking for and parsing the conf/bblayers.conf.
3. Set the LAYERDIR and parsing each of the ONELAYER/conf/layer.conf
4. Locate and parsing the conf/bitbake.conf.
5. Go over of each of the .bb and setup all the global variables to get a dependency tree...
6. Start the build
7....

Have a look at the Bitbake section of the Yocto Project Reference manual (Chapter 6), as it provides a little more information. 

I am trying to draw a picture like the list above,which is from the bitbake's point of view,
 some of the list is not right, since lots things are still not clear to me. If someone could draw such picture, it helps a lot to understand the bitbake.
>(...)
>
>def init(data):
>    topdir = data.getVar('TOPDIR')
>    if not topdir:
>        data.setVar('TOPDIR', os.getcwd())
>
>(...)
>
>You may want to read the newly-written documentation about bitbake and
>open embedded. I tried to explain how things fit together. I would like
>to have your feedback.
>
>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?
2. There is 'bb.note' and 'bbnote' in the code example, is it a type-mistake or something else?
>
>-- 
>    . 73! DE TA1AET
>      http://linkedin.com/in/erenturkay

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



Re: Where does the bitbake get the variable "TOPDIR"

Biao <huanmateme@...>
 


At 2012-12-17 23:37:52,"Eren Türkay" <eren@...> wrote:
>On Mon, Dec 17, 2012 at 05:06:26PM +0800, Biao wrote:
>> Greetings, 
>> 
>> I am a newbie tying to understand how bitbake works.
>> There is one line as BBPATH = "${TOPDIR}" in the mybuild/conf/bblayers.conf, i would like to know where the TOPDIR is defined? 
>
>It's defind in "lib/bb/parse/parse_py/ConfHandler.py:36". When TOPDIR is
>not defined in any of the bitbake configuration files, it's set to
>current working directory automatically.
>
The whole picture of how bitbake works is missing from the Manual of the bitbake, which typically should be(I guess) :
1. Set some environment variables like "TOPDIR, THISDIR..."
2. Looking for and parsing the conf/bblayers.conf.
3. Set the LAYERDIR and parsing each of the ONELAYER/conf/layer.conf
4. Locate and parsing the conf/bitbake.conf.
5. Go over of each of the .bb and setup all the global variables to get a dependency tree...
6. Start the build
7....
I am trying to draw a picture like the list above,which is from the bitbake's point of view,
 some of the list is not right, since lots things are still not clear to me. If someone could draw such picture, it helps a lot to understand the bitbake.
>(...)
>
>def init(data):
>    topdir = data.getVar('TOPDIR')
>    if not topdir:
>        data.setVar('TOPDIR', os.getcwd())
>
>(...)
>
>You may want to read the newly-written documentation about bitbake and
>open embedded. I tried to explain how things fit together. I would like
>to have your feedback.
>
>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?
2. There is 'bb.note' and 'bbnote' in the code example, is it a type-mistake or something else?
>
>-- 
>    . 73! DE TA1AET
>      http://linkedin.com/in/erenturkay


Re: Git tag systematics ?

Burton, Ross <ross.burton@...>
 

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


Re: [RFCv3 0/7][eclipse-poky] Integrate yocto documentation into eclipse

Timo Müller <mail@...>
 

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


Re: Git tag systematics ?

Wolfgang Denk <wd@...>
 

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.


Re: [PATCH runqemu] runqemu: add support for FSTYPE=vmdk

Saul Wold <sgw@...>
 

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


Re: bitbake user manual vs mega manual, and more info on local file fetcher?

Bob Cochran
 

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

On 12/13/2012 10:18 AM, Rifenbark, Scott M wrote:
Hey Robert,

Great questions... we are revising the BitBake manual as part of the YP 1.4 release. And, we are currently discussing exactly how to position it. So the answers to your questions are in the works.

Scott

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Thursday, December 13, 2012 6:09 AM
To: Yocto discussion list
Subject: [yocto] bitbake user manual vs mega manual, and more info on
local file fetcher?


first question -- is the bitbake user manual that comes bundled with
the bitbake source considered part of the yocto doc collection? as
in, if one wants detailed info on bitbake, does one read the bitbake
user manual (which is not mentioned on the yocto docs page), or is
bitbake user info assumed to now be scattered throughout the yocto
docs? i think it's important to identify the canonical location for
that documentation.

following on that, i'm asking since the bitbake user manual is
definitely a *little* deficient on info for the local file fetcher.
here's the sum total of its examples:

SRC_URI= "file://relativefile.patch"
SRC_URI= "file://relativefile.patch;this=ignored"
SRC_URI= "file:///Users/ich/very_important_software"

but there's no mention that (as i read it) that protocol accepts
wildcards:

meta-angstrom/recipes-angstrom/angstrom/angstrom-uboot-
scripts.bb:SRC_URI = "file://*.cmd"

i had no idea that was even true until i stumbled over the above (if
that's indeed what it means).

there's also no comprehensive coverage of how to define and use
patches in the yocto docs. the only mention i see is in the ref
manual, in the variable glossary under SRC_URI, which isn't even
complete (no mention of apply= or patchdir=).

so basic question -- is the bitbake user manual still under active
maintenance and is it considered part of the yocto docs collection?
since all that bitbake information should be *somewhere* but it's not
clear where.

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