Date   

Re: [OE-core] RFC: OE-Core task rework

Philip Balister
 

On 08/21/2012 01:49 AM, Paul Eggleton wrote:
On Monday 20 August 2012 15:45:07 Mark Hatle wrote:
...


Yup, there is a logical grouping for the lsb specific tasks, as for others.
The naming needs to be made clear as to why it's there, and what it
represents. Same with the summary and descriptions -- they should list the
functionality provided by this group of components.
The main concern with LSB is that we have something called task-basic, which
seems to be intended for LSB but does not state as much, and I know at least
one person has tried to use it and then been a little puzzled as to why rpm
has been pulled in when ipk packaging has been selected. Just naming some of
these tasks more appropriately would help avoid such situations. In the
specific case of task-basic there may be a case for creating a similar but not
LSB-focused task that pulls in real shell utilities in preference to the light
versions provided by busybox.
I was seriously stumped by the presence of rpm in what I felt should have been a very basic image. If a task/group is targeted at lsb, it needs to have lsb plastered all over the name so the rest of us can avoid it :)

Philip


4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
converts some IMAGE_FEATURES into the addition of tasks to be installed
(see classes/core-image.bbclass). At the very least we should probably
rename this if we rename tasks to package groups, and there's a question
as to how IMAGE_FEATURES scales - should every task be represented in
there or only a select list? Would we be better off not trying to bring
any tasks in via IMAGE_FEATURES at all and mostly leave that to control
post-processing (e.g. package-management, debug-tweaks, etc.)?
I'd certainly prefer that images were limited to selecting software from
task (group) recipes only, and not providing their own. An image should be
able to change the selection based on an "image feature" or similar
configuration, but the underlying tasks/groups, recipes, etc should all be
'generic' to a given distribution configuration.
The first part seems reasonable to me; but I'm still short of an answer as to
what to do with the existing IMAGE_FEATURES code as mentioned above. At the
moment aside from the special features such as debug-tweaks, these are just a
thin layer on top of task recipes which doesn't add very much at all other
than extra maintenance.

I think if you go through the images today, a lot of that stuff is either
old, or could be simplified by creating appropriate tasks/groups.
OK, that's a good point. I have another task on my list to clean up our image
recipes and that would be a good segue into that.

Cheers,
Paul


Re: Toolchain rework, call for testing

Khem Raj
 

On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa <martin.jansa@gmail.com> wrote:

Maybe it's because
http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not OEBasicHash here).
yes seems so. I have stopped using OEBasic long ago, you should stop
using it too.
But feel free to send a PR bump patchlet.


Re: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

Darren Hart <darren.hart@...>
 

On 08/20/2012 09:13 PM, Bruce Ashfield wrote:

+Kernel types (ktypes) are the highest level policy containers and represent
+a significant set of kernel functionality that has been grouped (and named)
+or partitioned.
What are you trying to convey with "partitioned" vs. "grouped" ? The
"or" indicates a functional difference, but it isn't clear what that is
from this reading.
partitioned means that they are really being kept apart since they won't
work together (think BFS vs CFS, or grsec vs another security patch).
Grouped
just means that you have 15 or 20 things that you want to collectively
call a "kernel type" and validate that they work together in a particular
configuration. But there's no fundamental incompatibility between these
features and others in the system.

It's a hard vs soft partitioning.

Would the expansion that I have above help ?
Hrm, nah. Let's leave it and address it if someone else raises a
concern. I might be alone here.

+ - behaviour. A kernel type defines a default behaviour, which is often a
behaviour: a kernel type ...
You left my Canadian behaviour .. my spell checker thanks you! Fixed.
With a UK architect it seemed presumptuous to do otherwise ;-)

+named category. These typically are included by kernel types, and are not
+meant to implement a defined functionality or be included multiple times.
+
+These often contain bug fixes, backports or other small changes to the kernel
+tree, and do not typically contain any kernel configuration fragments. patches
typically? How can a patch contain a config change?
That just means that a directory called 'patches' vs 'features' wouldn't
contain associated config fragments to enable that functionality. But since
the system is flexible, there's no reason they can't, so I went with
"typically" :) I can clarify.
Yeah... I think we need to kill config vs feature vs patches and merge
them together into a single term. Having the three seems to add more
confusion than information.

What do you see as the value for maintaining the 3 concepts separately?

+Config groups are collections of configuration options that when included
+enable a specific behaviour or functionality. Configuration groups do not
+contain patches, and can be included multiple times by any other feature or
+kernel type. The impact of configuration groups is additive, and order
+matters, since the last included config group can override the behaviour of
+previous includes.
Is this the same thing as "config fragment"? If so, we should pick one
and be consistent. If not, how do they differ?
I was more thinking about the "cfg" subdir and the .scc file that includes
a .cfg when I wrote this. The foo.cfg is the config fragment, the named
group is the .scc file + the .cfg.

I'm not sure it is worth splitting the hair here. I can just go with
configuration fragment. How does that sound ?
You're right, the config .scc file is not a config fragment, the .cfg
files are. So a config group includes one or more config fragments. Got it.


+Note: Depending on the architecture of the meta data, configuration groups
+can be complete, or partitioned. Complete config groups contain all the
^ comma should be removed

+options required to enable functionality, partitioned configurations rely on
+multiple includes to build up a set of non overlapping options to enable
non-overlapping

+functionality. Complete groups are simpler to include, but make it more
+difficult to remove or disable an option (since it can appear multiple
+times),
If a config fragment includes another one - isn't the end result the same?
which part ? The appear multiple times ? Yes, you can end up with thing
via fragments that include others, but not if you've partitioned them
all.

complete.scc
include complete.cfg

complete.cfg
CONFIG_A=y
CONFIG_B=y

partitioned.scc
include partitioned_a.cfg
include partitioned_b.cfg

partitioned_a.cfg
CONFIG_A=y

partitioned_b.cfg
CONFIG_B=y

This is how I understood your description. Assuming I have this right,
there is no difference between including compelte.scc or
partitioned.scc. Each will pull in all the same CONFIG* options and
modify/overwrite/etc any existing settings in exactly the same way. This
is what I meant by "same end result".

I guess what you're saying is the partitioned approach is more modular
and allows for changing a specific option in one place (CONFIG_A in
partitioned_a.cfg which will roll up into partitioned.scc) rather than
having several scc's similar to complete.scc which all need to be
modidfied to change CONFIG_A.

That could probably be made clearer.

+supports and is the typical entry point of a build system to the
+configuration data of the meta branch.
For whatever reason, that reads as very abstract and is rather difficult
to parse. I understand it... but _I_ needed to read it several times,
and I know the system fairly well...
.. I'll try something easier on the head, I was trying to stay out
of .scc file syntax, which is probably why it reads hard. Maybe this ?

The machine is the top-level description of a board, and the hardware
that it supports. A machine/BSP .scc file is found by a build system
I would stick with machine or BSP, but not confuse the issue by using
both. In the case of the linux-yocto meta data, the term BSP is more
discoverable as it maps to the directory name.

to start the processing of a particular machine and kernel type
combination. From the machine description, all the source code changes
(patches, features) and configuration changes that are used to
configure and build the kernel are located.
It's still a bit round about. How about:

The BSP .scc files combine the policy from the kernel type with the
hardware requirements of the machine into a single place. This file
describes all the source code changes from patches and features and the
configuration changes that are used to configure and build the kernel.


Changes made and pushed to the yocto-kernel-cache, we can continue to
iterate,
but this review was very helpful!
Great. Thanks for doing the write-up Bruce.


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


Re: adding packages in my Yocto

Paul Eggleton
 

On Tuesday 21 August 2012 12:51:41 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Paul Eggleton wrote:
On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to

conf/local.conf:
IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.
Fixed.
if there's no objection, i added how to add multiple packages as
well, just below that.
Looks good to me, thanks.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: adding packages in my Yocto

Robert P. J. Day
 

On Tue, 21 Aug 2012, Paul Eggleton wrote:

On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to

conf/local.conf:
IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.
Fixed.
if there's no objection, i added how to add multiple packages as
well, just below that.

rday

--

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

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


Re: adding packages in my Yocto

Paul Eggleton
 

On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to

conf/local.conf:
IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.
Fixed.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: ia32-base.inc: Drop glibc --with-tls option, its now the only option for glibc

Darren Hart <darren.hart@...>
 

On 08/21/2012 12:13 AM, Richard Purdie wrote:
This option is unused by (e)glibc since 2011 and is the default. It has been
shown to interact badly with the configure option in atom-pc from meta-yocto
causing a rebuild of the whole system despite the only change being an
assignment with += vs =. The easiest fix is simply to drop it.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Seems clearly correct.

Acked-by: Darren Hart <dvhart@linux.intel.com>




diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc
index 99ac352..17ff714 100644
--- a/conf/machine/include/ia32-base.inc
+++ b/conf/machine/include/ia32-base.inc
@@ -21,7 +21,6 @@ SERIAL_CONSOLE ?= "115200 ttyS0"
# glibc-related variables
#
GLIBC_ADDONS ?= "nptl"
-GLIBC_EXTRA_OECONF += "--with-tls"

#
# kernel-related variables


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


Re: Documenting the mailing lists.

Darren Hart <dvhart@...>
 

On 08/20/2012 04:19 PM, Paul Eggleton wrote:
On Monday 20 August 2012 15:50:37 Darren Hart wrote:
On 08/20/2012 03:43 PM, Jeff Osier-Mixon wrote:
On Mon, Aug 20, 2012 at 3:37 PM, Darren Hart <dvhart@linux.intel.com>
wrote:
On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
The mailing lists and website stuff is generally my responsibility,
but please fix anything you like. :) Be aware that the new website is
No intent to take over anything, I've just had to answer the "what goes
where" question a few too many times these last couple of weeks and felt
I should do something about it :-)
Oh, I'm not joking - please fix anything you want! or Scott or I can
do it. Thanks for getting the ball rolling. I'll catch up on this
thread.

I made sure you were on CC so you could help guide this.

under construction, so I am loathe to change much on the old website
at this point. For the new one, it may be possible to dynamically
grab the description from mailman.
We'll still need descriptions of the non-yocto-project lists, so that
may not be particularly helpful.
The only YP-related, non-YP lists I currently track are
openembedded-core and bitbake-devel. Both are OE lists, and I have
recently volunteered to help admin, so can make sure they have valid
Descriptions. If there are other lists we should track, please let me
know and I'll add them to the pile.
The only additional one that we reference in the manual is:

* http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
- Discussion mailing list about OpenEmbedded.

I'm not sure we need reference it at all though, perhaps oe-core is
sufficient.
FYI, the reason I added oe-devel is because it's the list that is used to
discuss/submit patches for almost all OE community layers other than OE-Core
and the ones that are hosted on yoctoproject.org.
Fair enough.

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


Re: adding packages in my Yocto

David Stewart
 

Good advice. A quick check of openembedded-core shows that gst-ffmpeg appears to be one of the packages available. Yes, definitely check the hob.

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Jeff Osier-Mixon
Sent: Tuesday, August 21, 2012 9:01 AM
To: aaryak gautam
Cc: Yocto Project
Subject: Re: [yocto] adding packages in my Yocto

Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to
conf/local.conf:

IMAGE_INSTALL_append += " package"

Use your own package name in place of package. Note the leading space
before the package name.
For more information, read this chapter in the Yocto Project
Development Manual
(http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-addpkg).

I also highly recommend trying out the Hob interface, as it makes the
whole system easier to understand. I like to make changes in the Hob
and then examine those changes in the resulting configuration files to
better understand the system at work.

Hope this helps!

On Tue, Aug 21, 2012 at 1:26 AM, aaryak gautam <aaryak.gautam@gmail.com>
wrote:
Hello

I am a hobbyist and quite new to both Linux and Yocto.
I had already compiled my Yocto kernel for I.MX23 successfully.
But I want to add few packages.
Like if i want to have ffmpeg in my yocto,how should I add it?
I have gone through the documentation,but could not understand.

can you help me out?
I am using Bitbake core-image-minimal , not sato.


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


--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: adding packages in my Yocto

Robert P. J. Day
 

On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:

Hi - please take a look at the FAQ here: https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to
conf/local.conf:

IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.

rday

--

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

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


Re: adding packages in my Yocto

Jeff Osier-Mixon <jefro@...>
 

Hi - please take a look at the FAQ here: https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to
conf/local.conf:

IMAGE_INSTALL_append += " package"

Use your own package name in place of package. Note the leading space
before the package name.
For more information, read this chapter in the Yocto Project
Development Manual
(http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-addpkg).

I also highly recommend trying out the Hob interface, as it makes the
whole system easier to understand. I like to make changes in the Hob
and then examine those changes in the resulting configuration files to
better understand the system at work.

Hope this helps!

On Tue, Aug 21, 2012 at 1:26 AM, aaryak gautam <aaryak.gautam@gmail.com> wrote:
Hello

I am a hobbyist and quite new to both Linux and Yocto.
I had already compiled my Yocto kernel for I.MX23 successfully.
But I want to add few packages.
Like if i want to have ffmpeg in my yocto,how should I add it?
I have gone through the documentation,but could not understand.

can you help me out?
I am using Bitbake core-image-minimal , not sato.


Thank You.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org


Re: How does bitbake work

David Stewart
 

I like the chapter Beth Flanagan wrote recently about the architecture of the Yocto Project. Check it out at the following link, and I think you might learn a lot.  I do suspect that what’s happening for you is that certain native tools like quilt need to be built first so that other parts of the build will run. (Quilt is used to manage the patches that applied in the build process).

 

Dave

 

http://www.aosabook.org/en/yocto.html

 

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Liu
Sent: Tuesday, August 21, 2012 1:11 AM
To: yocto
Subject: [yocto] How does bitbake work

 

Hi all,

    In order to learn to use poky,I am wondering how bitbake works with so many recipes. When I bitbake <target>, I want to know how bitbake collect the providers of <target> . Then bitbake will prepare the runqueue tasks to build the <target>.So I need to know which tasks to assign to build the <target>.And bitbake run these tasks in what order.In other words according to the characteristics of what to decided to implement which task first and then next.

     I am very eager to know the answers.

     Thanks ,

------ Yu Liu

     Following is the some output of bitbake busybox and in this example I want to know why first do the task of (quilt-native_0.51.bb, do_fetch)  :

 

Parsing recipes...done.
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1106 targets, 34 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION        = "1.15.2"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "qemuarm"
DISTRO            = "poky"
DISTRO_VERSION    = "1.2.1"
TUNE_FEATURES     = "armv5 dsp thumb arm926ejs"
TARGET_FPU        = "soft"
meta             
meta-yocto        = "<unknown>:<unknown>"

NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++ (external-csl-toolchain, gcc-cross)
NOTE: consider defining a PREFERRED_PROVIDER entry to match virtual/arm-none-linux-gnueabi-g++
NOTE: multiple providers are available for runtime linux-libc-headers-dev (linux-libc-headers, linux-libc-headers-yocto, linux-libc-headers-yocto-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match linux-libc-headers-dev
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 706 (ID: 18, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb, do_fetch)
NOTE: Running task 2 of 706 (ID: 228, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_20111111.bb, do_fetch)
NOTE: Running task 3 of 706 (ID: 189, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb, do_fetch)
NOTE: Running task 4 of 706 (ID: 515, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, do_fetch)
NOTE: package gnu-config-native-20111111-r1: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Started
NOTE: package quilt-native-0.51-r1: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_fetch: Started
NOTE: package gnu-config-native-20111111-r1: task do_fetch: Succeeded
NOTE: Running task 5 of 706 (ID: 224, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_20111111.bb, do_unpack)
NOTE: package gnu-config-native-20111111-r1: task do_unpack: Started
NOTE: package gnu-config-native-20111111-r1: task do_unpack: Succeeded
NOTE: Running task 6 of 706 (ID: 202, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb, do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Succeeded
NOTE: Running task 7 of 706 (ID: 511, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, do_unpack)
NOTE: package m4-native-1.4.16-r2: task do_unpack: Started
NOTE: package m4-native-1.4.16-r2: task do_unpack: Succeeded
NOTE: Running task 8 of 706 (ID: 215, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb, do_fetch)
NOTE: package autoconf-native-2.68-r7: task do_fetch: Succeeded
NOTE: Running task 9 of 706 (ID: 185, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb, do_unpack)
NOTE: package libtool-native-2.4.2-r2.0: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Succeeded
NOTE: Running task 10 of 706 (ID: 254, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb, do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Succeeded
NOTE: Running task 11 of 706 (ID: 198, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb, do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Started
NOTE: package automake-native-1.11.2-r3: task do_unpack: Started
NOTE: package automake-native-1.11.2-r3: task do_unpack: Succeeded
NOTE: Running task 12 of 706 (ID: 450, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb, do_fetch)
NOTE: package pkgconfig-native-0.25-r3: task do_fetch: Started
WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.6.tar.bz2
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Succeeded
NOTE: Running task 13 of 706 (ID: 250, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb, do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_unpack: Started
NOTE: package pkgconfig-native-0.25-r3: task do_fetch: Succeeded
NOTE: Running task 14 of 706 (ID: 446, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb, do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_unpack: Succeeded
NOTE: Running task 15 of 706 (ID: 241, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/gettext/gettext-minimal-native_0.18.1.1.bb, do_fetch)
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_fetch: Started
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_fetch: Succeeded
NOTE: Running task 16 of 706 (ID: 237, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/gettext/gettext-minimal-native_0.18.1.1.bb, do_unpack)
NOTE: package pkgconfig-native-0.25-r3: task do_unpack: Started
NOTE: package pkgconfig-native-0.25-r3: task do_unpack: Succeeded
NOTE: Running task 17 of 706 (ID: 463, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/ncurses/ncurses_5.9.bb, do_fetch)
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_unpack: Started
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_unpack: Succeeded
NOTE: Running task 18 of 706 (ID: 528, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-connectivity/openssl/ocf-linux_20100325.bb, do_fetch)
NOTE: package ncurses-native-5.9-r9.1: task do_fetch: Started
NOTE: package ocf-linux-native-20100325-r3.0: task do_fetch: Started
NOTE: package libtool-native-2.4.2-r2.0: task do_fetch: Succeeded
NOTE: Running task 19 of 706 (ID: 211, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb, do_unpack)
NOTE: package libtool-native-2.4.2-r2.0: task do_unpack: Started
NOTE: package libtool-native-2.4.2-r2.0: task do_unpack: Succeeded
NOTE: Running task 20 of 706 (ID: 280, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb, do_fetch)
NOTE: package openssl-native-1.0.0i-r0.2: task do_fetch: Started
NOTE: package ncurses-native-5.9-r9.1: task do_fetch: Succeeded
NOTE: Running task 21 of 706 (ID: 459, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/ncurses/ncurses_5.9.bb, do_unpack)
NOTE: package ncurses-native-5.9-r9.1: task do_unpack: Started
NOTE: package ncurses-native-5.9-r9.1: task do_unpack: Succeeded
NOTE: Running task 22 of 706 (ID: 176, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-support/sqlite/sqlite3_3.7.10.bb, do_fetch)
NOTE: package sqlite3-native-3.7.10-r2: task do_fetch: Started
WARNING: Failed to fetch URL http://download.savannah.gnu.org/releases/quilt/quilt-0.51.tar.gz
NOTE: package openssl-native-1.0.0i-r0.2: task do_fetch: Succeeded
NOTE: Running task 23 of 706 (ID: 276, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb, do_unpack)
NOTE: package openssl-native-1.0.0i-r0.2: task do_unpack: Started
NOTE: package quilt-native-0.51-r1: task do_fetch: Succeeded
NOTE: Running task 24 of 706 (ID: 14, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb, do_unpack)
NOTE: package openssl-native-1.0.0i-r0.2: task do_unpack: Succeeded
NOTE: Running task 25 of 706 (ID: 541, virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-extended/pigz/pigz_2.2.4.bb, do_fetch)
NOTE: package quilt-native-0.51-r1: task do_unpack: Started
NOTE: package quilt-native-0.51-r1: task do_unpack: Succeeded
NOTE: Running task 26 of 706 (ID: 15, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb, do_patch)
NOTE: package pigz-native-2.2.4-r2: task do_fetch: Started
NOTE: package quilt-native-0.51-r1: task do_patch: Started
NOTE: package quilt-native-0.51-r1: task do_patch: Succeeded
NOTE: Running task 27 of 706 (ID: 20, /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb, do_configure)
NOTE: package quilt-native-0.51-r1: task do_configure: Started


Request for photos

David Stewart
 

All – I’m prepping to give a talk at LinuxCon next week on an update to the Yocto Project, and I would like to create a slide which shows a bunch of devices which are based on YP.

 

Can you please send me a quick note with anything you know about to include here? Particularly nice if you have a photo or logo for the thing.

 

Thanks!!

 

Dave


Re: [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

David Nyström <david.nystrom@...>
 

On 08/20/2012 09:50 PM, McClintock Matthew-B29882 wrote:
Adding David back...

-M

On Mon, Aug 20, 2012 at 2:42 PM, Matthew McClintock <msm@freescale.com> wrote:
On Mon, Aug 20, 2012 at 2:27 PM, Khem Raj <raj.khem@gmail.com> wrote:
I just checked and we do have a few obscure bits in our kernel tree's
header files. Nothing that 99.9% would use but it seems reasonable to
include these...
Do you want applications for sdk host to be built using these obscure bits ?
if yes I would like to know why?

since then you are creating a scenariou where nativesdk is dependent on target
kernel and we need to fix it so that nativesdk can be common again.

if patches you are carrying are good for nativesdk headers can they be made
available for other kernels like linux-yocto e.g. ?

right now if we do this we are pretty much saying fsl machine layer can really
not mix with other BSPs. Many people use yocto commonly on more than one kind
of CPU and this does not scale.
Hmm I think I was just confused. We don't need any modifications for
the headers for nativesdk foo (that is the x86 tools in
meta-toolchain).

So, I think everything is OK as is.. if you look at meta-toolchain you
will see it includes our kernel's headers for cross compiling.

-M
Oh, sorry for the misunderstanding

I was under the impression that linux-libc-headers-nativesdk was installed under
/opt/poky/1.2/sysroots/<target-sysroot>/..., which it obviously is not.

Br,
David


Re: Classes

David Stewart
 

Seth – it sounds like you need something different than an overview class. I think you might want to have one of the consultants who are familiar with building projects using the Yocto Project work for you for a couple of days to help you sort these things out, for a fee. I’m sure one of them on this mailing list would be willing to offer their help. (Guys – you know who you are…)

 

Dave

 

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Seth Bollinger
Sent: Monday, August 20, 2012 7:14 PM
To: yocto@...
Subject: [yocto] Classes

 

Hello,

 

Will anyone recommend some classes regarding yocto and open embedded?  It would be nice to get up to speed quickly and into the nitty gritty instead of an overview.

 

Something covering the following items would be nice:

 

1.  How should projects be laid out?  Distro, image, task, BSP, what things should go where?

2.  How should subprojects inherit from superprojects?  If you need to create many subplatforms from a base platform, what's the best way to go about this?

3.  How should classes such as distutils be created to be inherited by other recipes (ruby modules that require a C extension to be compiled would be one example).

4.  How should hardware specific software be handled?

 

I fear that (as a newb) I will design a layout that will be sub-optimal, but we'll discover that after we have 25 platforms that will need major refactoring.  :)

 

Thanks,

 

Seth

 


Re: Toolchain rework, call for testing

Martin Jansa
 

On Thu, Aug 16, 2012 at 09:47:37PM -0700, Khem Raj wrote:
Hi All

Recently glibc build has been simplified upstream. It has dropped the
dependency on libgcc_s and libgcc_eh for building glibc itself.
This means that we can simplify our toolchain bootstrap a bit by
dropping 1 of the 3 cross gcc build stages. We do not need
gcc-cross-intermediate
anymore. This should bring some build time reduction and simplify the
bootstrap. I have a series of patches which I have tested
by building core-image-minimal and meta-toolchain for all supported
qemu architectures and also uclibc/eglibc both
but it needs a lot more testing therefore I am calling out wider
audience for help in testing it out.

The branch is

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/toolchain-rework
eglibc fails to build in incremental build

| arm-oe-linux-gnueabi-gcc -march=armv4t -marm -mthumb-interwork -mtune=arm920t --sysroot=/OE/shr-core/tmp-eglibc/sysroots/om-gta02-tcbootstrap -nostdlib -nostartfiles -r -o /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.os \
| -Wl,-d -Wl,--whole-archive /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.a -o /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.os
| arm-oe-linux-gnueabi-gcc -march=armv4t -marm -mthumb-interwork -mtune=arm920t --sysroot=/OE/shr-core/tmp-eglibc/sysroots/om-gta02-tcbootstrap -nostdlib -nostartfiles -r -o /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.map.o '-Wl,-(' /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/dl-allobjs.os /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.mapT
| /OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/armv4t-oe-linux-gnueabi.gcc-cross-initial/gcc/arm-oe-linux-gnueabi/4.7.2/ld: cannot find -lgcc
| collect2: error: ld returned 1 exit status
| make[2]: *** [/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.map] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/eglibc-2_16/libc/elf'
| make[1]: *** [elf/subdir_lib] Error 2
| make[1]: Leaving directory `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/eglibc-2_16/libc'

Maybe it's because
http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not OEBasicHash here).

Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com


[PATCH] [Fixed]Yocto-BSP Main Page - time consuming processes block the UI

Ioana Grigoropol <ioanax.grigoropol@...>
 

- problems on the main page of yocto-bsp wizard :
- getting the available kernel architectures is invoked from the UI
-> similar to the properties page, when loading the
architectures a new thread is created in the background and a
progress monitor dialog is shown.
- getting qemu kernel architectures is invoked from the UI
-> as above.
- creation of properties file is done with each change in any of
the controls
-> this action should only be done once, and the most
convenient place would be when flipping to next page. Unfortunately, the
method that checks if we can flip to the next page is called at each
change on the controls, in so re-writing the file with each keystroke.
The creation of this file was moved on the YoctoBSP Wizard, when
clicking on finish.

In order to reuse the code that sends a process in the background
and shows the progress from the properties page, we use a
generic class BSPThread that runs a command from the shell in the
background and collects the output & error, and a BSPProgressDialog to
show. Each command will customize the processing of its output by
subclassing BSPThread. the progress of the background thread.


Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@intel.com>
---
.../sdk/remotetools/wizards/bsp/BSPAction.java | 32 ++
.../remotetools/wizards/bsp/BSPProgressDialog.java | 44 +++
.../sdk/remotetools/wizards/bsp/BSPThread.java | 92 ++++++
.../wizards/bsp/ErrorCollectorThread.java | 19 ++
.../remotetools/wizards/bsp/KernelArchGetter.java | 23 ++
.../wizards/bsp/KernelBranchesGetter.java | 28 ++
.../sdk/remotetools/wizards/bsp/MainPage.java | 296 +++++++----------
.../wizards/bsp/OutputCollectorThread.java | 19 ++
.../remotetools/wizards/bsp/PropertiesPage.java | 335 +++++++-------------
.../remotetools/wizards/bsp/QemuArchGetter.java | 27 ++
.../remotetools/wizards/bsp/YoctoBSPWizard.java | 99 +++---
11 files changed, 579 insertions(+), 435 deletions(-)
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPThread.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/ErrorCollectorThread.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelArchGetter.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelBranchesGetter.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/OutputCollectorThread.java
create mode 100644 plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/QemuArchGetter.java

diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
new file mode 100644
index 0000000..171f181
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
@@ -0,0 +1,32 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * Stores a list of items from the output of a background thread and the error message if something went wrong
+ * @author ioana.grigoropol
+ *
+ */
+public class BSPAction {
+ private String[] items;
+ private String message;
+
+ BSPAction(String[] items, String message){
+ this.setItems(items);
+ this.setMessage(message);
+ }
+
+ public String[] getItems() {
+ return items;
+ }
+
+ public void setItems(String[] items) {
+ this.items = items;
+ }
+
+ public String getMessage() {
+ return message;
+ }
+
+ public void setMessage(String message) {
+ this.message = message;
+ }
+}
\ No newline at end of file
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
new file mode 100644
index 0000000..5cf713d
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
@@ -0,0 +1,44 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.jface.dialogs.ProgressMonitorDialog;
+import org.eclipse.jface.operation.IRunnableWithProgress;
+import org.eclipse.swt.widgets.Shell;
+
+/**
+ * Creates a progress monitor dialog that will run in the background a BSPThread and display a custom message
+ * @author ioana.grigoropol
+ *
+ */
+public class BSPProgressDialog extends ProgressMonitorDialog{
+ String displayMessage;
+ BSPThread getterThread;
+ Shell shell;
+
+
+ public BSPProgressDialog(Shell parent, BSPThread getterThread, String displayMessage) {
+ super(parent);
+ this.shell = parent;
+ this.getterThread = getterThread;
+ this.displayMessage = displayMessage;
+ }
+
+ public void run(){
+ try {
+ super.run(true, true, new IRunnableWithProgress(){
+ @Override
+ public void run(IProgressMonitor monitor) {
+ monitor.beginTask(displayMessage + " ...", 100);
+ getterThread.run();
+ monitor.done();
+ }
+ });
+ } catch (Exception e) {
+ getterThread.getBspAction().setMessage(e.getMessage());
+ }
+ }
+
+ public BSPAction getBspAction() {
+ return getterThread.getBspAction();
+ }
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPThread.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPThread.java
new file mode 100644
index 0000000..e347bf1
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPThread.java
@@ -0,0 +1,92 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+import java.io.BufferedReader;
+import java.io.InputStreamReader;
+import java.util.ArrayList;
+
+/**
+ * Receives a command to be run on a separate thread in the background
+ * It contains an BSPAction object that will collect the output & error
+ * Output lines are processed and collected into the items of BSPAction
+ * @author ioana.grigoropol
+ *
+ */
+public abstract class BSPThread implements Runnable {
+ public static final String SUCCESS = "success";
+ public static final String ERROR = "error";
+
+ private BSPAction bspAction;
+ private String command;
+
+ /**
+ * Receives the command to be run in the background
+ * @param command
+ */
+ public BSPThread(String command) {
+ this.command = command;
+ this.bspAction = new BSPAction(null, null);
+ }
+
+ @Override
+ public void run() {
+ ArrayList<String> values = new ArrayList<String>();
+
+ try {
+ ProcessBuilder builder = new ProcessBuilder(new String[] {"sh", "-c", command});
+ // redirect error stream to collect both output & error
+ builder.redirectErrorStream(true);
+ Process process = builder.start();
+ BufferedReader br = new BufferedReader(new InputStreamReader(process.getInputStream()));
+ String line = null;
+ String errorMessage = "";
+ while ( (line = br.readLine()) != null) {
+ String[] result = processLine(line);
+ String status = result[0];
+ String value = result[1];
+ if (status.equals(ERROR) && !value.isEmpty()) {
+ errorMessage += value;
+ continue;
+ }
+ if (!value.isEmpty())
+ values.add(value);
+ }
+ int exitVal = process.waitFor();
+
+ // if the background process did not exit with 0 code, we should set the status accordingly
+ if (exitVal != 0) {
+ bspAction.setMessage(errorMessage);
+ bspAction.setItems(null);
+ }
+ } catch (Exception e) {
+ bspAction.setMessage(e.getMessage());
+ bspAction.setItems(null);
+ }
+ if (!values.isEmpty()) {
+ bspAction.setMessage(null);
+ bspAction.setItems(values.toArray(new String[values.size()]));
+ }
+ }
+
+ /**
+ * Each command ran in the background will have a different output and a different way of processing it
+ * @param line
+ * @return
+ */
+ protected abstract String[] processLine(String line);
+
+ public BSPAction getBspAction() {
+ return bspAction;
+ }
+
+ public void setBspAction(BSPAction bspAction) {
+ this.bspAction = bspAction;
+ }
+
+ public String getCommand() {
+ return command;
+ }
+
+ public void setCommand(String command) {
+ this.command = command;
+ }
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/ErrorCollectorThread.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/ErrorCollectorThread.java
new file mode 100644
index 0000000..d39ac28
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/ErrorCollectorThread.java
@@ -0,0 +1,19 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * BSPThread that ignores the output of the process and returns an error if the process exits with non zero code
+ * @author ioana.grigoropol
+ *
+ */
+public class ErrorCollectorThread extends BSPThread{
+
+ public ErrorCollectorThread(String command) {
+ super(command);
+ }
+
+ @Override
+ protected String[] processLine(String line) {
+ return null;
+ }
+
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelArchGetter.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelArchGetter.java
new file mode 100644
index 0000000..833057a
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelArchGetter.java
@@ -0,0 +1,23 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * BSPThread that processes the output of "yocto-bsp list karch"
+ * @author ioana.grigoropol
+ *
+ */
+public class KernelArchGetter extends BSPThread{
+
+ public KernelArchGetter(String command) {
+ super(command);
+ }
+
+ @Override
+ protected String[] processLine(String line) {
+ if (line.contains(":"))
+ return new String[]{SUCCESS, ""};
+ line = line.replaceAll("^\\s+", "");
+ line = line.replaceAll("\\s+$", "");
+ return new String[]{SUCCESS, line};
+ }
+
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelBranchesGetter.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelBranchesGetter.java
new file mode 100644
index 0000000..4caea2c
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelBranchesGetter.java
@@ -0,0 +1,28 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * BSPThread that processes the output lines from running command "yocto-bsp list" for the selected kernel
+ * @author ioana.grigoropol
+ *
+ */
+public class KernelBranchesGetter extends BSPThread {
+
+ public KernelBranchesGetter(String command) {
+ super(command);
+ }
+
+ @Override
+ protected String[] processLine(String line) {
+ // [TODO : Ioana]: find a better way to identify error lines
+ if (!line.startsWith("["))
+ return new String[]{ERROR, line + "\n"};
+
+ String[] items = line.split(",");
+
+ String value = items[0];
+ value = value.replace("[\"", "");
+ value = value.replaceAll("\"$", "");
+ return new String[]{SUCCESS, value};
+ }
+
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index fea1c76..606555d 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
@@ -14,7 +14,6 @@ import java.io.BufferedReader;
import java.io.File;
import java.io.InputStream;
import java.io.InputStreamReader;
-import java.util.ArrayList;

import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
@@ -33,16 +32,15 @@ import org.eclipse.swt.widgets.Combo;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Control;
import org.eclipse.swt.widgets.DirectoryDialog;
-import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Text;
import org.eclipse.swt.widgets.Widget;
import org.yocto.sdk.remotetools.YoctoBspElement;

/**
- *
+ *
* Setting up the parameters for creating the new Yocto BSP
- *
+ *
* @author jzhang
*/
public class MainPage extends WizardPage {
@@ -50,9 +48,6 @@ public class MainPage extends WizardPage {
private static final String KARCH_CMD = "yocto-bsp list karch";
private static final String QARCH_CMD = "yocto-bsp list qemu property qemuarch";
private static final String BSP_SCRIPT = "yocto-bsp";
- private static final String PROPERTIES_CMD_PREFIX = "yocto-bsp list ";
- private static final String PROPERTIES_CMD_SURFIX = " properties -o ";
- private static final String PROPERTIES_FILE = "/tmp/properties.json";

private Button btnMetadataLoc;
private Text textMetadataLoc;
@@ -87,6 +82,7 @@ public class MainPage extends WizardPage {
this.bspElem = element;
}

+ @Override
public void createControl(Composite parent) {
setErrorMessage(null);
Composite composite = new Composite(parent, SWT.NONE);
@@ -95,7 +91,7 @@ public class MainPage extends WizardPage {
composite.setLayout(layout);

gd.horizontalSpan = 2;
- composite.setLayoutData(gd);
+ composite.setLayoutData(gd);

labelMetadata = new Label(composite, SWT.NONE);
labelMetadata.setText("Meta_data location*: ");
@@ -105,6 +101,7 @@ public class MainPage extends WizardPage {
textMetadataLoc = (Text)addTextControl(textContainer, "");
textMetadataLoc.setEnabled(false);
textMetadataLoc.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
@@ -133,6 +130,7 @@ public class MainPage extends WizardPage {

textBspName = (Text)addTextControl(textContainer, "");
textBspName.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
@@ -147,24 +145,26 @@ public class MainPage extends WizardPage {

textBspOutputLoc = (Text)addTextControl(textContainer, "");
textBspOutputLoc.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
});
setBtnBspOutLoc(addFileSelectButton(textContainer, textBspOutputLoc));

- labelKArch= new Label(composite, SWT.NONE);
+ labelKArch = new Label(composite, SWT.NONE);
labelKArch.setText("kernel Architecture*: ");

textContainer = new Composite(composite, SWT.NONE);
textContainer.setLayout(new GridLayout(2, false));
textContainer.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false));

- comboKArch= new Combo(textContainer, SWT.READ_ONLY);
+ comboKArch = new Combo(textContainer, SWT.READ_ONLY);
comboKArch.setLayout(new GridLayout(2, false));
comboKArch.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, false));
comboKArch.setEnabled(false);
comboKArch.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
@@ -183,6 +183,7 @@ public class MainPage extends WizardPage {
comboQArch.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, false));
comboQArch.setEnabled(false);
comboQArch.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
@@ -200,7 +201,7 @@ public class MainPage extends WizardPage {
text.setText(value);
text.setSize(10, 150);

- return (Control)text;
+ return text;
}

private Button addFileSelectButton(final Composite parent, final Text text) {
@@ -216,74 +217,74 @@ public class MainPage extends WizardPage {
}
});
return button;
- }
+ }

private void controlChanged(Widget widget) {
- Status status = new Status(IStatus.OK, "not_used", 0, "", null);
- setErrorMessage(null);
- String metadataLoc = textMetadataLoc.getText();
-
- if (widget == textMetadataLoc) {
- resetKarchCombo();
- if (metadataLoc.length() == 0) {
- status = new Status(IStatus.ERROR, "not_used", 0, "Meta data location can't be empty!", null);
- } else {
- File meta_data = new File(metadataLoc);
- if (!meta_data.exists() || !meta_data.isDirectory()) {
- status = new Status(IStatus.ERROR, "not_used", 0,
- "Invalid meta data location: Make sure it exists and is a directory!", null);
- } else {
- File bspScript = new File(metadataLoc + "/scripts/" + BSP_SCRIPT);
- if (!bspScript.exists() || !bspScript.canExecute())
- status = new Status(IStatus.ERROR, "not_used", 0,
- "Make sure yocto-bsp exists under \"" + metadataLoc + "/scripts\" and is executable!", null);
- else {
- kernelArchesHandler();
- }
- }
- }
- } else if (widget == comboKArch) {
- String selection = comboKArch.getText();
- if (!bspElem.getKarch().contentEquals(selection))
- bspElem = new YoctoBspElement();
- if (selection.matches("qemu")) {
- labelQArch.setEnabled(true);
- comboQArch.setEnabled(true);
- } else {
- labelQArch.setEnabled(false);
- comboQArch.setEnabled(false);
- }
- }
-
- String buildDir = textBuildLoc.getText();
- String outputDir = textBspOutputLoc.getText();
- String bspName = textBspName.getText();
-
- if (!outputDir.isEmpty()){
- if (outputDir.matches(buildDir)) {
- status = new Status(IStatus.ERROR, "not_used", 0,
- "You've set BSP output directory the same as build directory, please leave output directory empty for this scenario!", null);
- } else {
- File outputDirectory = new File(outputDir);
- if (outputDirectory.exists()){
+ Status status = new Status(IStatus.OK, "not_used", 0, "", null);
+ setErrorMessage(null);
+ String metadataLoc = textMetadataLoc.getText();
+
+ if (widget == textMetadataLoc) {
+ resetKarchCombo();
+ if (metadataLoc.length() == 0) {
+ status = new Status(IStatus.ERROR, "not_used", 0, "Meta data location can't be empty!", null);
+ } else {
+ File meta_data = new File(metadataLoc);
+ if (!meta_data.exists() || !meta_data.isDirectory()) {
status = new Status(IStatus.ERROR, "not_used", 0,
- "Your BSP output directory points to an exiting directory!", null);
- }
- }
- } else if (buildDir.startsWith(metadataLoc) && !bspName.isEmpty()) {
- String bspDirStr = metadataLoc + "/meta-" + bspName;
- File bspDir = new File(bspDirStr);
- if (bspDir.exists()) {
- status = new Status(IStatus.ERROR, "not_used", 0,
- "Your BSP with name: " + bspName + " already exist under directory: " + bspDirStr + ", please change your bsp name!", null);
- }
- }
-
- if (status.getSeverity() == IStatus.ERROR)
- setErrorMessage(status.getMessage());
-
- getWizard().getContainer().updateButtons();
- canFlipToNextPage();
+ "Invalid meta data location: Make sure it exists and is a directory!", null);
+ } else {
+ File bspScript = new File(metadataLoc + "/scripts/" + BSP_SCRIPT);
+ if (!bspScript.exists() || !bspScript.canExecute())
+ status = new Status(IStatus.ERROR, "not_used", 0,
+ "Make sure yocto-bsp exists under \"" + metadataLoc + "/scripts\" and is executable!", null);
+ else {
+ kernelArchesHandler();
+ }
+ }
+ }
+ } else if (widget == comboKArch) {
+ String selection = comboKArch.getText();
+ if (!bspElem.getKarch().contentEquals(selection))
+ bspElem = new YoctoBspElement();
+ if (selection.matches("qemu")) {
+ labelQArch.setEnabled(true);
+ comboQArch.setEnabled(true);
+ } else {
+ labelQArch.setEnabled(false);
+ comboQArch.setEnabled(false);
+ }
+ }
+
+ String buildDir = textBuildLoc.getText();
+ String outputDir = textBspOutputLoc.getText();
+ String bspName = textBspName.getText();
+
+ if (!outputDir.isEmpty()){
+ if (outputDir.matches(buildDir)) {
+ status = new Status(IStatus.ERROR, "not_used", 0,
+ "You've set BSP output directory the same as build directory, please leave output directory empty for this scenario!", null);
+ } else {
+ File outputDirectory = new File(outputDir);
+ if (outputDirectory.exists()){
+ status = new Status(IStatus.ERROR, "not_used", 0,
+ "Your BSP output directory points to an exiting directory!", null);
+ }
+ }
+ } else if (buildDir.startsWith(metadataLoc) && !bspName.isEmpty()) {
+ String bspDirStr = metadataLoc + "/meta-" + bspName;
+ File bspDir = new File(bspDirStr);
+ if (bspDir.exists()) {
+ status = new Status(IStatus.ERROR, "not_used", 0,
+ "Your BSP with name: " + bspName + " already exist under directory: " + bspDirStr + ", please change your bsp name!", null);
+ }
+ }
+
+ if (status.getSeverity() == IStatus.ERROR)
+ setErrorMessage(status.getMessage());
+
+ getWizard().getContainer().updateButtons();
+ canFlipToNextPage();
}

private Status checkBuildDir() {
@@ -292,18 +293,18 @@ public class MainPage extends WizardPage {
String buildLoc = textBuildLoc.getText();

if (buildLoc.isEmpty()) {
- buildLoc = metadataLoc + "/build";
- return createBuildDir(buildLoc);
+ buildLoc = metadataLoc + "/build";
+ return createBuildDir(buildLoc);
} else {
- File buildLocDir = new File(buildLoc);
- if (!buildLocDir.exists()) {
- return createBuildDir(buildLoc);
- } else if (buildLocDir.isDirectory()) {
+ File buildLocDir = new File(buildLoc);
+ if (!buildLocDir.exists()) {
+ return createBuildDir(buildLoc);
+ } else if (buildLocDir.isDirectory()) {
return createBuildDir(buildLoc);
- } else {
- return new Status(IStatus.ERROR, "not_used", 0, "Invalid build location: Make sure the build location is a directory!", null);
- }
- }
+ } else {
+ return new Status(IStatus.ERROR, "not_used", 0, "Invalid build location: Make sure the build location is a directory!", null);
+ }
+ }
}

private Status createBuildDir(String buildLoc) {
@@ -337,10 +338,6 @@ public class MainPage extends WizardPage {
return this.bspElem;
}

- public void handleEvent(Event event) {
- canFlipToNextPage();
- getWizard().getContainer().updateButtons();
- }

private void resetKarchCombo() {
comboKArch.deselectAll();
@@ -351,24 +348,26 @@ public class MainPage extends WizardPage {
}

private void kernelArchesHandler() {
- ArrayList<String> karches = getKArches();
- if (!karches.isEmpty()) {
- String[] kitems = new String[karches.size()];
- kitems = karches.toArray(kitems);
- comboKArch.setItems(kitems);
+ BSPAction kArchesAction = getKArches();
+ if (kArchesAction.getMessage() == null && kArchesAction.getItems().length != 0) {
+ comboKArch.setItems(kArchesAction.getItems());
comboKArch.setEnabled(true);
+ } else if (kArchesAction.getMessage() != null){
+ setErrorMessage(kArchesAction.getMessage());
+ return;
}
- ArrayList<String> qarches = getQArches();
- if (!qarches.isEmpty()) {
- String[] qitems = new String[qarches.size()];
- qitems = qarches.toArray(qitems);
- comboQArch.setItems(qitems);
- }
+ BSPAction qArchesAction = getQArches();
+ if (qArchesAction.getMessage() == null && qArchesAction.getItems().length != 0) {
+ comboQArch.setItems(qArchesAction.getItems());
+ } else if (qArchesAction.getMessage() != null)
+ setErrorMessage(qArchesAction.getMessage());
+
}

+ @Override
public boolean canFlipToNextPage(){
String err = getErrorMessage();
- if (err != null)
+ if (err != null)
return false;
else if (!validatePage())
return false;
@@ -406,87 +405,30 @@ public class MainPage extends WizardPage {
bspElem.setMetadataLoc(metadataLoc);
bspElem.setKarch(karch);
bspElem.setQarch(qarch);
- bspElem.setValidPropertiesFile(createPropertiesFile());
-
- return true;
- }

+// boolean validPropertiesFile = true;
+// BSPAction action = createPropertiesFile();
+// if (action.getMessage() != null) {
+// validPropertiesFile = false;
+// setErrorMessage(action.getMessage());
+// }
+// bspElem.setValidPropertiesFile(validPropertiesFile);

- private boolean createPropertiesFile() {
- String create_properties_cmd = bspElem.getMetadataLoc() + "/scripts/" +
- PROPERTIES_CMD_PREFIX + bspElem.getKarch() +
- PROPERTIES_CMD_SURFIX + PROPERTIES_FILE;
- try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(create_properties_cmd);
- int exitVal = proc.waitFor();
- if (exitVal != 0)
- return false;
- return true;
- } catch (Throwable t) {
- t.printStackTrace();
- return false;
- }
+ return true;
}

- private ArrayList<String> getKArches() {
- ArrayList<String> karches = new ArrayList<String>();
-
- String get_karch_cmd = textMetadataLoc.getText() + "/scripts/" + KARCH_CMD;
- try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(get_karch_cmd);
- InputStream stdin = proc.getInputStream();
- InputStreamReader isr = new InputStreamReader(stdin);
- BufferedReader br = new BufferedReader(isr);
- String line = null;
-
- while ( (line = br.readLine()) != null) {
- if (line.contains(":"))
- continue;
- line = line.replaceAll("^\\s+", "");
- line = line.replaceAll("\\s+$", "");
- karches.add(line);
- }
-
- proc.waitFor();
-
- } catch (Throwable t) {
- t.printStackTrace();
- }
-
- return karches;
+ private BSPAction getKArches() {
+ String getKArchCmd = textMetadataLoc.getText() + "/scripts/" + KARCH_CMD;
+ BSPProgressDialog progressDialog = new BSPProgressDialog(getShell(), new KernelArchGetter(getKArchCmd), "Loading kernel architectures ");
+ progressDialog.run();
+ return progressDialog.getBspAction();
}

- private ArrayList<String> getQArches() {
- ArrayList<String> qarches = new ArrayList<String>();
-
- String get_qarch_cmd = textMetadataLoc.getText() + "/scripts/" + QARCH_CMD;
- try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(get_qarch_cmd);
- InputStream stdin = proc.getInputStream();
- InputStreamReader isr = new InputStreamReader(stdin);
- BufferedReader br = new BufferedReader(isr);
- String line = null;
-
- while ( (line = br.readLine()) != null) {
- if (!line.startsWith("["))
- continue;
- String[] values = line.split(",");
-
- String value = values[0];
- value = value.replace("[\"", "");
- value = value.replaceAll("\"$", "");
- qarches.add(value);
- }
- proc.waitFor();
-
- } catch (Throwable t) {
- t.printStackTrace();
- }
-
- return qarches;
+ private BSPAction getQArches() {
+ String getQArchCmd = textMetadataLoc.getText() + "/scripts/" + QARCH_CMD;
+ BSPProgressDialog progressDialog = new BSPProgressDialog(getShell(), new QemuArchGetter(getQArchCmd), "Loading Qemu architectures ");
+ progressDialog.run();
+ return progressDialog.getBspAction();
}

public Button getBtnMetadataLoc() {
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/OutputCollectorThread.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/OutputCollectorThread.java
new file mode 100644
index 0000000..df5fba5
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/OutputCollectorThread.java
@@ -0,0 +1,19 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * BSPThread that returns all the output lines of the process execution
+ * @author ioana.grigoropol
+ *
+ */
+public class OutputCollectorThread extends BSPThread{
+
+ public OutputCollectorThread(String command) {
+ super(command);
+ }
+
+ @Override
+ protected String[] processLine(String line) {
+ return new String[]{SUCCESS, line};
+ }
+
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java
index a2f6e26..14719d0 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/PropertiesPage.java
@@ -10,18 +10,12 @@
*******************************************************************************/
package org.yocto.sdk.remotetools.wizards.bsp;

-import java.io.BufferedReader;
-import java.io.InputStreamReader;
-import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashSet;
import java.util.Hashtable;
import java.util.Iterator;

-import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.jface.dialogs.MessageDialog;
-import org.eclipse.jface.dialogs.ProgressMonitorDialog;
-import org.eclipse.jface.operation.IRunnableWithProgress;
import org.eclipse.jface.wizard.WizardPage;
import org.eclipse.swt.SWT;
import org.eclipse.swt.custom.ScrolledComposite;
@@ -46,7 +40,7 @@ import org.yocto.sdk.remotetools.YoctoJSONHelper;
/**
*
* Setting up the parameters for creating the new Yocto Bitbake project
- *
+ *
* @author jzhang
*/
public class PropertiesPage extends WizardPage {
@@ -86,10 +80,10 @@ public class PropertiesPage extends WizardPage {
}

public void onEnterPage(YoctoBspElement element) {
- if (!element.getValidPropertiesFile()) {
- setErrorMessage("There's no valid properties file created, please choose \"Back\" to reselect kernel architecture!");
- return;
- }
+// if (!element.getValidPropertiesFile()) {
+// setErrorMessage("There's no valid properties file created, please choose \"Back\" to reselect kernel architecture!");
+// return;
+// }

if (this.bspElem == null || this.bspElem.getKarch().isEmpty() || !this.bspElem.getKarch().contentEquals(element.getKarch())) {
karch_changed = true;
@@ -115,20 +109,20 @@ public class PropertiesPage extends WizardPage {
smpButton.setText("SMP Support");
smpButton.setSelection(true);

- kbGroup= new Group(controlContainer, SWT.NONE);
- kbGroup.setLayout(new FillLayout(SWT.VERTICAL));
+ kbGroup= new Group(controlContainer, SWT.NONE);
+ kbGroup.setLayout(new FillLayout(SWT.VERTICAL));
kbGroup.setText("Kernel Branch Settings:");
newButton = new Button(kbGroup, SWT.RADIO);
newButton.setText("New");
newButton.setSelection(true);
-
+
existingButton = new Button(kbGroup, SWT.RADIO);
existingButton.setText("Existing");
existingButton.setSelection(false);
-
- kbCombo = new Combo(kbGroup, SWT.DROP_DOWN | SWT.READ_ONLY);
-
- }
+
+ kbCombo = new Combo(kbGroup, SWT.DROP_DOWN | SWT.READ_ONLY);
+
+ }
}
if (karch_changed) {
kbCombo.removeAll();
@@ -161,47 +155,47 @@ public class PropertiesPage extends WizardPage {
propertyControlMap = new Hashtable<YoctoBspPropertyElement, Control>();
Iterator<YoctoBspPropertyElement> it = properties.iterator();

- while (it.hasNext()) {
- // Get property
- YoctoBspPropertyElement propElem = (YoctoBspPropertyElement)it.next();
- String type = propElem.getType();
- String name = propElem.getName();
- if (type.contentEquals("edit")) {
- Composite textContainer = new Composite(propertyGroup, SWT.NONE);
-
- textContainer.setLayout(new FillLayout());
- new Label (textContainer, SWT.NONE).setText(name+":");
- Text text = new Text(textContainer, SWT.BORDER | SWT.SINGLE);
- propertyControlMap.put(propElem, (Control)text);
-
- } else if (type.contentEquals("boolean")) {
- Composite booleanContainer = new Composite(propertyGroup, SWT.NONE);
-
- booleanContainer.setLayout(new FillLayout(SWT.VERTICAL));
-
- String default_value = propElem.getDefaultValue();
- Button button = new Button(booleanContainer, SWT.CHECK);
- button.setText(name);
- if (default_value.equalsIgnoreCase("y")) {
- button.setSelection(true);
- } else
- button.setSelection(false);
- propertyControlMap.put(propElem, (Control)button);
-
- } else if (type.contentEquals("choicelist")) {
- Composite choiceContainer = new Composite(propertyGroup, SWT.NONE);
-
- choiceContainer.setLayout(new FillLayout());
-
- new Label (choiceContainer, SWT.NONE).setText(name+":");
- Combo combo = new Combo(choiceContainer, SWT.BORDER | SWT.READ_ONLY);
- combo.setLayout(new FillLayout());
-
- updateKernelValues(KERNEL_CHOICES, name);
-
- propertyControlMap.put(propElem, (Control)combo);
- }
- }
+ while (it.hasNext()) {
+ // Get property
+ YoctoBspPropertyElement propElem = it.next();
+ String type = propElem.getType();
+ String name = propElem.getName();
+ if (type.contentEquals("edit")) {
+ Composite textContainer = new Composite(propertyGroup, SWT.NONE);
+
+ textContainer.setLayout(new FillLayout());
+ new Label (textContainer, SWT.NONE).setText(name+":");
+ Text text = new Text(textContainer, SWT.BORDER | SWT.SINGLE);
+ propertyControlMap.put(propElem, text);
+
+ } else if (type.contentEquals("boolean")) {
+ Composite booleanContainer = new Composite(propertyGroup, SWT.NONE);
+
+ booleanContainer.setLayout(new FillLayout(SWT.VERTICAL));
+
+ String default_value = propElem.getDefaultValue();
+ Button button = new Button(booleanContainer, SWT.CHECK);
+ button.setText(name);
+ if (default_value.equalsIgnoreCase("y")) {
+ button.setSelection(true);
+ } else
+ button.setSelection(false);
+ propertyControlMap.put(propElem, button);
+
+ } else if (type.contentEquals("choicelist")) {
+ Composite choiceContainer = new Composite(propertyGroup, SWT.NONE);
+
+ choiceContainer.setLayout(new FillLayout());
+
+ new Label (choiceContainer, SWT.NONE).setText(name+":");
+ Combo combo = new Combo(choiceContainer, SWT.BORDER | SWT.READ_ONLY);
+ combo.setLayout(new FillLayout());
+
+ updateKernelValues(KERNEL_CHOICES, name);
+
+ propertyControlMap.put(propElem, combo);
+ }
+ }
}

}
@@ -216,31 +210,37 @@ public class PropertiesPage extends WizardPage {

this.composite.layout(true, true);
kcCombo.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
});


- newButton.addSelectionListener(new SelectionListener() {
- public void widgetDefaultSelected(SelectionEvent e) {}
-
- public void widgetSelected(SelectionEvent e) {
+ newButton.addSelectionListener(new SelectionListener() {
+ @Override
+ public void widgetDefaultSelected(SelectionEvent e) {}
+
+ @Override
+ public void widgetSelected(SelectionEvent e) {
controlChanged(e.widget);
}
});
-
-
- existingButton.addSelectionListener(new SelectionListener() {
- public void widgetDefaultSelected(SelectionEvent e) {}
-
- public void widgetSelected(SelectionEvent e) {
+
+
+ existingButton.addSelectionListener(new SelectionListener() {
+ @Override
+ public void widgetDefaultSelected(SelectionEvent e) {}
+
+ @Override
+ public void widgetSelected(SelectionEvent e) {
controlChanged(e.widget);
}
});
-
-
+
+
kbCombo.addModifyListener(new ModifyListener() {
+ @Override
public void modifyText(ModifyEvent e) {
controlChanged(e.widget);
}
@@ -250,6 +250,7 @@ public class PropertiesPage extends WizardPage {
}


+ @Override
public void createControl(Composite parent) {
this.composite = new Composite(parent, SWT.NONE);
GridData gd = new GridData(SWT.FILL, SWT.CENTER, true, false);
@@ -263,6 +264,7 @@ public class PropertiesPage extends WizardPage {
setControl(this.composite);
}

+ @Override
public boolean canFlipToNextPage() {
return false;
}
@@ -310,7 +312,7 @@ public class PropertiesPage extends WizardPage {

public boolean validatePage() {
if (kcCombo == null)
- return false;
+ return false;

if ((kcCombo != null) && (kbCombo != null)) {
String kcSelection = kcCombo.getText();
@@ -320,11 +322,11 @@ public class PropertiesPage extends WizardPage {
return false;
}
}
- if ((propertyControlMap != null)) {
+ if ((propertyControlMap != null)) {
if (!propertyControlMap.isEmpty()) {
Enumeration<YoctoBspPropertyElement> keys = propertyControlMap.keys();
while( keys.hasMoreElements() ) {
- YoctoBspPropertyElement key = (YoctoBspPropertyElement)keys.nextElement();
+ YoctoBspPropertyElement key = keys.nextElement();
Control control = propertyControlMap.get(key);
String type = key.getType();

@@ -361,162 +363,69 @@ public class PropertiesPage extends WizardPage {
private void updateProperties(YoctoBspPropertyElement element) {
Iterator<YoctoBspPropertyElement> it = properties.iterator();
while (it.hasNext()) {
- YoctoBspPropertyElement propElem = (YoctoBspPropertyElement)it.next();
+ YoctoBspPropertyElement propElem = it.next();
if (propElem.getName().contentEquals(element.getName())) {
- properties.remove((Object) propElem);
+ properties.remove(propElem);
properties.add(element);
break;
- } else
+ } else
continue;
}
- }
- private void controlChanged(Widget widget) {
- setErrorMessage(null);
-
- String kernel_choice = kcCombo.getText();
- if ((kernel_choice == null) || (kernel_choice.isEmpty())) {
- setErrorMessage("Please selecte kernel_choice!");
- return;
- }
- if (widget == kcCombo) {
- newButton.setSelection(true);
- existingButton.setSelection(false);
- kbCombo.removeAll();
-
- updateKernelValues(KERNEL_BRANCHES, "\\\"" + kernel_choice + "\\\"." + NEW_KBRANCH_NAME);
- } else if (widget == kbCombo) {
- setErrorMessage(null);
- } else if (widget == newButton) {
-
- boolean newBranch = newButton.getSelection();
-
- if (newBranch) {
- updateKernelValues(KERNEL_BRANCHES, "\"" + kernel_choice + "\"." + NEW_KBRANCH_NAME);
- } else {
- updateKernelValues(KERNEL_BRANCHES, "\"" + kernel_choice + "\"." + EXISTING_KBRANCH_NAME);
- }
- } else if (widget == existingButton) {
- boolean existingBranch = existingButton.getSelection();
-
- if (existingBranch) {
- updateKernelValues(KERNEL_BRANCHES, "\"" + kernel_choice + "\"." + EXISTING_KBRANCH_NAME);
- }
- }
- canFlipToNextPage();
- getWizard().getContainer().updateButtons();
}
+ private void controlChanged(Widget widget) {
+ setErrorMessage(null);

- private void updateKernelValues(final String value, String property) {
- final ValuesGetter runnable = new ValuesGetter(property);
-
- ProgressMonitorDialog dialog = new ProgressMonitorDialog(getShell());
- try {
- dialog.run(true, true, new IRunnableWithProgress(){
- public void run(IProgressMonitor monitor) {
- monitor.beginTask("Loading Kernel " + value + " ...", 100);
- runnable.run();
- monitor.done();
- }
- });
- } catch (Exception e) {
- runnable.getBspAction().setMessage(e.getMessage());
+ String kernel_choice = kcCombo.getText();
+ if ((kernel_choice == null) || (kernel_choice.isEmpty())) {
+ setErrorMessage("Please selecte kernel_choice!");
+ return;
}
+ if (widget == kcCombo) {
+ newButton.setSelection(true);
+ existingButton.setSelection(false);
+ kbCombo.removeAll();

- BSPAction action = runnable.getBspAction();
- if (action.getItems() != null) {
- if (value == KERNEL_CHOICES)
- kcCombo.setItems(action.getItems());
- else if (value == KERNEL_BRANCHES)
- kbCombo.setItems(action.getItems());
- } else if (action.getMessage() != null)
- MessageDialog.openError(getShell(), "Yocto-BSP", action.getMessage());
- }
-
- class ValuesGetter implements Runnable {
- private String property;
- private BSPAction bspAction;
-
- public ValuesGetter(String property) {
- this.property = property;
- this.bspAction = new BSPAction(null, null);
- }
+ updateKernelValues(KERNEL_BRANCHES, "\\\"" + kernel_choice + "\\\"." + NEW_KBRANCH_NAME);
+ } else if (widget == kbCombo) {
+ setErrorMessage(null);
+ } else if (widget == newButton) {

- public void run() {
- ArrayList<String> values = new ArrayList<String>();
-
- String build_dir = "";
- if ((bspElem.getBuildLoc() == null) || bspElem.getBuildLoc().isEmpty())
- build_dir = bspElem.getMetadataLoc()+"/build";
- else
- build_dir = bspElem.getBuildLoc();
-
- String values_cmd = "export BUILDDIR=" + build_dir + ";" + bspElem.getMetadataLoc() + "/scripts/" + VALUES_CMD_PREFIX + bspElem.getKarch() + VALUES_CMD_SURFIX + property;
- try {
- ProcessBuilder builder = new ProcessBuilder(new String[] {"sh", "-c", values_cmd});
- builder.redirectErrorStream(true);
- Process process = builder.start();
- BufferedReader br = new BufferedReader(new InputStreamReader(process.getInputStream()));
- String line = null;
- String error_message = "";
- while ( (line = br.readLine()) != null) {
- if (!line.startsWith("[")) {
- error_message += line + "\n";
- continue;
- }
- String[] items = line.split(",");
+ boolean newBranch = newButton.getSelection();

- String value = items[0];
- value = value.replace("[\"", "");
- value = value.replaceAll("\"$", "");
- values.add(value);
- }
- int exitVal = process.waitFor();
- if (exitVal != 0) {
- bspAction.setMessage(error_message);
- bspAction.setItems(null);
- }
- } catch (Exception e) {
- bspAction.setItems(null);
- bspAction.setMessage(e.getMessage());
- }
- if (!values.isEmpty()) {
- bspAction.setItems(values.toArray(new String[values.size()]));
- bspAction.setMessage(null);
+ if (newBranch) {
+ updateKernelValues(KERNEL_BRANCHES, "\"" + kernel_choice + "\"." + NEW_KBRANCH_NAME);
+ } else {
+ updateKernelValues(KERNEL_BRANCHES, "\"" + kernel_choice + "\"." + EXISTING_KBRANCH_NAME);
}
- }
-
- public BSPAction getBspAction() {
- return bspAction;
- }
+ } else if (widget == existingButton) {
+ boolean existingBranch = existingButton.getSelection();

- public void setBspAction(BSPAction bspAction) {
- this.bspAction = bspAction;
+ if (existingBranch) {
+ updateKernelValues(KERNEL_BRANCHES, "\"" + kernel_choice + "\"." + EXISTING_KBRANCH_NAME);
+ }
}
+ canFlipToNextPage();
+ getWizard().getContainer().updateButtons();
}

- class BSPAction {
- private String[] items;
- private String message;
-
- BSPAction(String[] items, String message){
- this.setItems(items);
- this.setMessage(message);
- }
-
- public String[] getItems() {
- return items;
- }
-
- public void setItems(String[] items) {
- this.items = items;
- }
+ private void updateKernelValues(final String value, String property) {
+ String build_dir = "";
+ if ((bspElem.getBuildLoc() == null) || bspElem.getBuildLoc().isEmpty())
+ build_dir = bspElem.getMetadataLoc()+"/build";
+ else
+ build_dir = bspElem.getBuildLoc();

- public String getMessage() {
- return message;
- }
+ String valuesCmd = "export BUILDDIR=" + build_dir + ";" + bspElem.getMetadataLoc() + "/scripts/" + VALUES_CMD_PREFIX + bspElem.getKarch() + VALUES_CMD_SURFIX + property;

- public void setMessage(String message) {
- this.message = message;
- }
+ BSPProgressDialog progressDialog = new BSPProgressDialog(getShell(), new KernelBranchesGetter(valuesCmd), "Loading Kernel " + value);
+ progressDialog.run();
+ BSPAction action = progressDialog.getBspAction();
+ if (action.getItems() != null) {
+ if (value == KERNEL_CHOICES)
+ kcCombo.setItems(action.getItems());
+ else if (value == KERNEL_BRANCHES)
+ kbCombo.setItems(action.getItems());
+ } else if (action.getMessage() != null)
+ MessageDialog.openError(getShell(), "Yocto-BSP", action.getMessage());
}
}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/QemuArchGetter.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/QemuArchGetter.java
new file mode 100644
index 0000000..e235695
--- /dev/null
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/QemuArchGetter.java
@@ -0,0 +1,27 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * BSPThread that processes the output of running "yocto-bsp list qemu property qemuarch"
+ * @author ioana.grigoropol
+ *
+ */
+public class QemuArchGetter extends BSPThread {
+
+ public QemuArchGetter(String command) {
+ super(command);
+ }
+
+ @Override
+ protected String[] processLine(String line) {
+ if (!line.startsWith("["))
+ return new String[]{ERROR, line + "\n"};
+
+ String[] values = line.split(",");
+
+ String value = values[0];
+ value = value.replace("[\"", "");
+ value = value.replaceAll("\"$", "");
+ return new String[]{SUCCESS, value};
+ }
+
+}
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/YoctoBSPWizard.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/YoctoBSPWizard.java
index 454a705..eecc200 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/YoctoBSPWizard.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/YoctoBSPWizard.java
@@ -10,9 +10,6 @@
*******************************************************************************/
package org.yocto.sdk.remotetools.wizards.bsp;

-import java.io.BufferedReader;
-import java.io.InputStream;
-import java.io.InputStreamReader;
import java.util.HashSet;

import org.eclipse.jface.dialogs.MessageDialog;
@@ -24,29 +21,32 @@ import org.yocto.sdk.remotetools.YoctoJSONHelper;

/**
* A wizard for creating Yocto BSP.
- *
+ *
* @author jzhang
- *
+ *
*/
public class YoctoBSPWizard extends Wizard {
private static final String CREATE_CMD = "/scripts/yocto-bsp create ";
private static final String PROPERTY_VALUE_FILE = "/tmp/propertyvalues.json";
-
+ private static final String PROPERTIES_CMD_PREFIX = "yocto-bsp list ";
+ private static final String PROPERTIES_CMD_SURFIX = " properties -o ";
+ private static final String PROPERTIES_FILE = "/tmp/properties.json";
+
private MainPage mainPage;
private PropertiesPage propertiesPage;
- private YoctoBspElement bspElem;
+ private final YoctoBspElement bspElem;

public YoctoBSPWizard() {
super();
bspElem = new YoctoBspElement();
}

- @Override
+ @Override
public IWizardPage getNextPage(IWizardPage page) {
propertiesPage.onEnterPage(mainPage.getBSPElement());
return propertiesPage;
}
-
+
@Override
public void addPages() {
mainPage = new MainPage(bspElem);
@@ -55,54 +55,63 @@ public class YoctoBSPWizard extends Wizard {
addPage(propertiesPage);
}

+ private BSPAction createPropertiesFile() {
+ String createPropertiesCmd = bspElem.getMetadataLoc() + "/scripts/" +
+ PROPERTIES_CMD_PREFIX + bspElem.getKarch() +
+ PROPERTIES_CMD_SURFIX + PROPERTIES_FILE;
+ BSPProgressDialog progressDialog = new BSPProgressDialog(getShell(), new ErrorCollectorThread(createPropertiesCmd), "Creating properties file ");
+ progressDialog.run();
+ return progressDialog.getBspAction();
+ }
+
+ private BSPAction createBSP(){
+ YoctoBspElement element = mainPage.getBSPElement();
+ String createBspCmd = element.getMetadataLoc() + CREATE_CMD +
+ element.getBspName() + " " + element.getKarch();
+
+ if (!element.getBspOutLoc().isEmpty())
+ createBspCmd = createBspCmd + " -o " + element.getBspOutLoc();
+ else
+ createBspCmd = createBspCmd + " -o " + element.getMetadataLoc() + "/meta-" + element.getBspName();
+ createBspCmd = createBspCmd + " -i " + PROPERTY_VALUE_FILE;
+
+ BSPProgressDialog progressDialog = new BSPProgressDialog(getShell(), new OutputCollectorThread(createBspCmd), "Creating BSP ");
+ progressDialog.run();
+ return progressDialog.getBspAction();
+ }
+
@Override
public boolean performFinish() {
if (propertiesPage.validatePage()) {
HashSet<YoctoBspPropertyElement> properties = propertiesPage.getProperties();
YoctoJSONHelper.createBspJSONFile(properties);
- YoctoBspElement element = mainPage.getBSPElement();
-
- String create_bsp_cmd = element.getMetadataLoc() + CREATE_CMD +
- element.getBspName() + " " + element.getKarch();
-
- if (!element.getBspOutLoc().isEmpty())
- create_bsp_cmd = create_bsp_cmd + " -o " + element.getBspOutLoc();
- else
- create_bsp_cmd = create_bsp_cmd + " -o " + element.getMetadataLoc() + "/meta-" + element.getBspName();
- create_bsp_cmd = create_bsp_cmd + " -i " + PROPERTY_VALUE_FILE;
-
- try {
- Runtime rt = Runtime.getRuntime();
- Process proc = rt.exec(create_bsp_cmd);
- InputStream stdin = proc.getInputStream();
- InputStreamReader isr = new InputStreamReader(stdin);
- BufferedReader br = new BufferedReader(isr);
- String line = null;
- String error_message = "";
-
- while ( (line = br.readLine()) != null) {
- error_message = error_message + line;
- }
-
- int exitVal = proc.waitFor();
- if (exitVal != 0) {
- MessageDialog.openError(getShell(),"Yocto-BSP", error_message);
- return false;
- } else {
- MessageDialog.openInformation(getShell(), "Yocto-BSP", error_message);
- return true;
- }
- } catch (Throwable t) {
- t.printStackTrace();
+
+
+ BSPAction createPropertiesAction = createPropertiesFile();
+ if (createPropertiesAction.getMessage() != null && !createPropertiesAction.getMessage().isEmpty()) {
+ MessageDialog.openError(getShell(),"Yocto-BSP", createPropertiesAction.getMessage());
return false;
}
+
+ BSPAction createBSPAction = createBSP();
+ if (createBSPAction.getMessage() != null && !createBSPAction.getMessage().isEmpty()) {
+ MessageDialog.openError(getShell(),"Yocto-BSP", createBSPAction.getMessage());
+ return false;
+ } else {
+ String message = "";
+ for (String item : createBSPAction.getItems())
+ message += item + "\n";
+ MessageDialog.openInformation(getShell(), "Yocto-BSP", message);
+ return true;
+ }
} else {
MessageDialog.openError(getShell(), "Yocto-BSP", "Property settings contains error!");
return false;
}
-
+
}
-
+
+ @Override
public boolean canFinish() {
return (mainPage.validatePage() && propertiesPage.validatePage());
}
--
1.7.9.5


[PATCH] meta-emenlow: unset preferred providers for virtual/libgles[12]

Ross Burton
 

The recent changes to enable GLES/EGL in mesa-dri have caused emenlow to fail:

ERROR: Trying to resolve runtime dependency libglu resulted in conflicting PREFERRED_PROVIDER entries being found.
The providers found were: ['/srv/home/pokybuild/yocto-autobuilder/yocto-slave/emenlow/build/yocto/meta-intel/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb', '/srv/home/pokybuild/yocto-autobuilder/yocto-slave/emenlow/build/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb']
The PREFERRED_PROVIDER entries resulting in this conflict were: ['PREFERRED_PROVIDER_mesa-dri = xpsb-glx', 'PREFERRED_PROVIDER_virtual/libgles1 = mesa-dri']

Because emenlow's xpsb-glx contains mesa, it needs to entirely replace
mesa-dri. We'd normally set virtual/libgles1 and virtual/libgles2 to xpsb-glx
but these drivers don't build the GLES libraries so that would be a lie.

So, unset the preferred provider entries so that bitbake doesn't look at
mesa-dri at all.
---
meta-emenlow/conf/machine/emenlow.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf
index afb3866..65dcd5a 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -13,6 +13,8 @@ PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
PREFERRED_PROVIDER_virtual/libx11 = "libx11-trim"
PREFERRED_PROVIDER_virtual/libgl = "xpsb-glx"
+PREFERRED_PROVIDER_virtual/libgles1 = ""
+PREFERRED_PROVIDER_virtual/libgles2 = ""
PREFERRED_PROVIDER_virtual/xserver = "xserver-psb"
PREFERRED_PROVIDER_virtual/xserver-xf86 = "xserver-psb"
PREFERRED_PROVIDER_mesa-dri = "xpsb-glx"
--
1.7.10


Re: Raspberry Pi do_fetch failure

Jack Mitchell <ml@...>
 

On 20/08/12 18:23, Andrei Gherzan wrote:
It seems like even if i got no feedback from github, this issue is not reproducible anymore. Fetch is working as it should now. Could you please confirm?

Si it could have been a temporary bug or this was solved meanwhile.

ag




On Mon, Aug 13, 2012 at 9:58 PM, Andrei Gherzan <andrei@gherzan.ro <mailto:andrei@gherzan.ro>> wrote:


On Mon, Aug 13, 2012 at 7:38 PM, Chris Tapp
<opensource@keylevel.com <mailto:opensource@keylevel.com>> wrote:

On 13 Aug 2012, at 15:00, Jack Mitchell wrote:

> On 13/08/12 14:51, Andrei Gherzan wrote:
>>
>> On Mon, Aug 13, 2012 at 4:34 PM, Jack Mitchell
<ml@communistcode.co.uk <mailto:ml@communistcode.co.uk>
<mailto:ml@communistcode.co.uk
<mailto:ml@communistcode.co.uk>>> wrote:
>>
>> Good afternoon everyone,
>>
>> I am trying (yet again) to get yocto to build for the
Raspberry Pi
>> and I am falling at the do_fetch hurdle on the RasPi kernel.
>>
>> ERROR: Fetcher failure: Fetch command export
HOME="/home/jack";
>> export SSH_AGENT_PID="1350"; export
>> SSH_AUTH_SOCK="/home/jack/.cache/keyring-fjEm9a/ssh"; export
>>
GIT_CONFIG="/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/etc/gitconfig";
>> export
>>
PATH="/home/jack/Projects/poky-rasp/scripts:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/bin/armv6-vfp-poky-linux-gnueabi:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi/usr/bin/crossscripts:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/sbin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/bin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/sbin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux//bin:/home/jack/Projects/poky-rasp/scripts:/home/jack/Projects/poky-rasp/bitbake/bin/:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl";
>> git clone --bare --mirror
>> git://github.com/raspberrypi/linux.git
<http://github.com/raspberrypi/linux.git>
>> <http://github.com/raspberrypi/linux.git>
>>
>>
>> Does this work in a shell? Just try to clone it on your
computer.
>>
>> ag
>
> Yes, cloning it now without issues - it took a while to get
going and someone has suggested that it might be timing out
within bitbake...


I've had similar issues in the past that seemed to be caused
by Github. If I ran a manual fetch I could see errors relating
to compressed folders (I think - was a while back) that
couldn't be found. It sorted itself after a day or so.

I sent an email to github. Will keep you posted.

ag

Working fine for me now.

--

Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk

--


Re: RFC: OE-Core task rework

Paul Eggleton
 

On Tuesday 21 August 2012 09:49:37 Paul Eggleton wrote:
The main concern with LSB is that we have something called task-basic,
which seems to be intended for LSB but does not state as much, and I know
at least one person has tried to use it and then been a little puzzled as
to why rpm has been pulled in when ipk packaging has been selected. Just
naming some of these tasks more appropriately would help avoid such
situations. In the specific case of task-basic there may be a case for
creating a similar but not LSB-focused task that pulls in real shell
utilities in preference to the light versions provided by busybox.
Ugh, sorry. I meant task-core-basic here - not to be confused with task-basic
in meta-oe [1].

Cheers,
Paul

[1] http://www.openembedded.org/wiki/Meta-oe_tasks

--

Paul Eggleton
Intel Open Source Technology Centre