SHould we install development and debigging pacakages in the images when we
want to build a toolchain.. I mean this
"dbg-pkgs" - add -dbg packages for all installed packages
# (adds symbol information for debugging/profiling)
# "dev-pkgs" - add -dev packages for a
Hello. We have a native package that implements a header file that is
required also by another non-native package. What is the best approach
to handle such a situation?
I guess one option is to create two recipes for the package containing
the header filer; one native and a one non-native that does
Hi Mike,
On Thursday 06 June 2013 18:39:38 Mike Dean wrote:
> Can I distribute the compilation with Yocto? I found posts about using
> icecc to do so, and tried to set it up, but I haven't been able to get it
> to work correctly. I have two machines which each have two Xeon quadcore
> processors
On Thu, 2013-06-06 at 06:48 +, Luo Zhenhua-B19537 wrote:
> Except x86/x86-64 hosts, can Yocto support to run on hosts with other
> CPU arch, e.g. ARM, Powerpc, etc?
You mean as the system to run the builds on? In theory that would be
possible although most people tend to use x86 and the other
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Friday, June 07, 2013 5:50 PM
>
> On Thu, 2013-06-06 at 06:48 +, Luo Zhenhua-B19537 wrote:
> > Except x86/x86-64 hosts, can Yocto support to run on hosts with other
> > CPU arch, e.g. ARM,
On 2013-06-07 02:45, Paul Eggleton wrote:
Hi Mike,
On Thursday 06 June 2013 18:39:38 Mike Dean wrote:
Can I distribute the compilation with Yocto? I found posts about using
icecc to do so, and tried to set it up, but I haven't been able to get it
to work correctly. I have two machines which e
Hi Jessica,
The reason I have remove this is that we can always find it on git.
So if we at some point decide that we need to save the location of the init
script, we can just look in the git log, and add it again.
I do not see the point in keeping classes, methods that are not used, and which
Neither of the actions is actually defined in the plugin.xml. If we need to
support it, why aren't they enabled ?
From: Zhang, Jessica
Sent: Friday, June 07, 2013 2:57 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [Refactor RFC 4/9]
On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop
wrote:
> SHould we install development and debigging pacakages in the images when we
> want to build a toolchain.. I mean this
>
> "dbg-pkgs" - add -dbg packages for all installed packages
> # (adds symbol information
On 2013-06-07 07:10, Hans Beckérus wrote:
On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop
wrote:
SHould we install development and debigging pacakages in the images when we
want to build a toolchain.. I mean this
"dbg-pkgs" - add -dbg packages for all installed packages
#
On Fri, Jun 7, 2013 at 3:34 PM, Gary Thomas wrote:
> On 2013-06-07 07:10, Hans Beckérus wrote:
>>
>> On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop
>> wrote:
>>>
>>> SHould we install development and debigging pacakages in the images when
>>> we
>>> want to build a toolchain.. I mean this
On Fri, Jun 7, 2013 at 3:40 PM, Hans Beckérus wrote:
> On Fri, Jun 7, 2013 at 3:34 PM, Gary Thomas wrote:
>> On 2013-06-07 07:10, Hans Beckérus wrote:
>>>
>>> On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop
>>> wrote:
SHould we install development and debigging pacakages in the i
Yes, you need those packages in your sysroot for cross development.
Cheers,
Jessica
From: satyaswaroop.dama...@gmail.com [mailto:satyaswaroop.dama...@gmail.com] On
Behalf Of DAMARLA Satya Swaroop
Sent: Friday, June 07, 2013 12:10 AM
To: Zhang, Jessica; yocto@yoctoproject.org
Subject: Re: [y
On Fri, Jun 7, 2013 at 4:03 PM, Zhang, Jessica wrote:
> Yes, you need those packages in your sysroot for cross development.
>
>
Ok. But out of curiosity, why should I need X11 packages for a simple
command-line based toolchain?
I assume that none of these X11 packages gets copied to my target
devi
When you create your image, what profile did you use. Are you building one of
our existing images, e.g. core-image-minimal, etc. or it's a customized image
and if so, how did you customize your image, via layer or install extra
packages? I think x11 is brought in via some package dependency.
Hello all,
I built a core-image-sato with boost-1.53.0, qt-mobility-x11-1.2.0,
gsl-1.15, gnuplot-4.6.3, and gnuradio-3.6.4.1. This had the
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk dev-pkgs dbg-pkgs" set
for tools-sdk dev-pkgs dbg-pkgs in the local.conf.
This required adding meta-oe for the be
On Fri, Jun 7, 2013 at 4:21 PM, Zhang, Jessica wrote:
> When you create your image, what profile did you use. Are you building one
> of our existing images, e.g. core-image-minimal, etc. or it's a customized
> image and if so, how did you customize your image, via layer or install extra
> pack
Signed-off-by: Ioana Grigoropol
---
.../yocto/bc/bitbake/ICommandResponseHandler.java | 15 ---
.../remote/utils/ICommandResponseHandler.java | 15 +++
2 files changed, 15 insertions(+), 15 deletions(-)
delete mode 100644
plugins/org.yocto.bc.ui/src/org/yocto/b
- ConsoleHelper class is to be used in order to find a console by a specified
name and display it in the view (using ConsoleRunnble) on the GUI thread
Signed-off-by: Ioana Grigoropol
---
.../src/org/yocto/remote/utils/ConsoleHelper.java | 38
1 file changed, 38 insertion
- this set of patches replaces patch 2/9 from first batch of patches
Ioana Grigoropol (8):
Move ICommandResponseHandler to org.yocto.remote.utils
Add YoctoCommand utility class
Add CommandResponseHandler implementation of ICommandResponseHandler
Add ConsoleRunnable utility class
Add Cons
- plain implementation of ICommandResponseHandler interface that prints all
lines to the console stream
Signed-off-by: Ioana Grigoropol
---
.../org.yocto.remote.utils/META-INF/MANIFEST.MF|3 +-
.../yocto/remote/utils/CommandResponseHandler.java | 44
2 files chang
- OutputProcessor class is a stub class that will be used for processing the
output of a remote command
- the main method of this class is processOutput()
- in this method, we retrieve the bufferes needed for output and
error processing (from the host shell)
(u
- added utility class CommandRunnable that will be used for running a remote
command in a different thread & processing the output
- add RemoteMachine utility class
- RemoteMachine class holds all the information needed for a
remote/local machine
- environment map of all v
- YoctoCommand wraps all information needed for running a remote command
- the actual command string
- the command arguments
- the directory in which to run the remote command
- a ProcessStreamBuffer that will store the output of running this
particular command
- th
- Console Runnable implements Runnable and is charge to display the specified
console in the Console View
Signed-off-by: Ioana Grigoropol
---
.../org/yocto/remote/utils/ConsoleRunnable.java| 47
1 file changed, 47 insertions(+)
create mode 100644
plugins/org.yocto.r
- this is a simple implementation of the OutputProcessor abstract class
- splitting the error and output lines is done by '\n' character
Signed-off-by: Ioana Grigoropol
---
.../yocto/remote/utils/CommandOutputProcessor.java | 43
1 file changed, 43 insertions(+)
c
This is the cover letter only for the entire patch series.
The following changes since commit 57c5d62fab9bc1024a3cf1f3f840f7f3bcfd3167:
Fix Thread Access exception for systemtap Dialogs (2013-05-31 15:07:01 +0300)
are available in the git repository at:
git://git.yoctoproject.org/poky-cont
Hi Jessica,
I have sent you a set of 8 patches that replaces the second patch (2/9). I have
added the new classes incrementally and put the changes to the RemoteHelper
along with the classes that are strongly linked with it.
I have also sent a pull request for the whole set of patches(50). They
The simplest way I found to solve this was to add the following to my recipe
PACKAGES += " ${PN}-include"
${PN}-include_FILES = "foobar.h"
BBCLASSEXTEND =+ "native"
By doing this I could get away with one recipe for both {PN} and ${PN}-native.
And all the target package needs to do is to RDEPEN
29 matches
Mail list logo
