date:20130607

Re: [yocto] Application Development

2013-06-07 Thread DAMARLA Satya Swaroop

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 all installed packages
# (useful if you want to develop against libs in the
image)


Greets,
Satya


On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop <
swaroop.dama...@gmail.com> wrote:

> Hi Jessica & Philip,
>
> I have an issue... This is such a long error ... I even did a fresh build
> by deleting the "tmp" directory. The image build went very well but the
> toolchain is always giving me a error...
>
> *| Selecting previously unselected package xz-dev.*
> *| Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...*
> *| The following package disappeared from your system as*
> *| all files have been overwritten by other packages:*
> *|   avahi*
> *| log_check: Using
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
> as logfile*
> *| Logfile is clean*
> *| Installing NATIVESDK packages*
> *| Ign file: ./ InRelease*
> *| Ign file: ./ InRelease*
> *| Ign file: ./ Release.gpg*
> *| Ign file: ./ Release.gpg*
> *| Get:1 file: ./ Release [24 B]*
> *| Get:2 file: ./ Release [11 B]*
> *| Ign file: ./ Translation-en*
> *| Ign file: ./ Translation-en*
> *| Reading package lists...*
> *| W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__*
> *| W: You may want to run apt-get update to correct these problems*
> *| Reading package lists...*
> *| Building dependency tree...*
> *| Reading state information...*
> *| Some packages could not be installed. This may mean that you have*
> *| requested an impossible situation or if you are using the unstable*
> *| distribution that some required packages have not yet been created*
> *| or been moved out of Incoming.*
> *| The following information may help to resolve the situation:*
> *| *
> *| The following packages have unmet dependencies:*
> *|  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but
> it is not installable*
> *|Depends: gcc-cross-canadian-arm but
> it is not installable*
> *|Depends: meta-environment-arm but
> it is not installable*
> *|Depends:
> binutils-cross-canadian-arm but it is not installable*
> *| W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__*
> *| W: You may want to run apt-get update to correct these problems*
> *| E: Unable to correct problems, you have held broken packages.*
> *| DEBUG: Python function do_populate_sdk finished*
> *| ERROR: Function failed: populate_sdk_image (see
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
> for further information)*
> *ERROR: Task 10 (/home/damarla/yocto/poky/meta/recipes-graphics/images/
> core-image-skidata.bb, do_populate_sdk) failed with exit code '1'*
> *NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to
> be rerun and 1 failed.*
> *
> *
> *Summary: 1 task failed:*
> *  /home/damarla/yocto/poky/meta/recipes-graphics/images/
> core-image-skidata.bb, do_populate_sdk*
> *Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> *
>
> I am not able to install those packages as they say there are no
> installation candidate for them...
>
>
> On Thu, Jun 6, 2013 at 6:52 AM, Zhang, Jessica wrote:
>
>>  Hi Satya,
>>
>> ** **
>>
>> Use bitbake image-name –c populate_sdk, this allows you to create a
>> toolchain with sysroot that match your target image that allows you to
>> develop app against…
>>
>> ** **
>>
>> Cheers,
>>
>> Jessica
>>
>> ** **
>>
>> *From:* yocto-boun...@yoctoproject.org [mailto:
>> yocto-boun...@yoctoproject.org] *On Behalf Of *Satya Swaroop Damarla
>> *Sent:* Wednesday, June 05, 2013 6:05 AM
>> *To:* yocto@yoctoproject.org
>> *Subject:* [yocto] Application Development
>>
>> ** **
>>
>> Hi Guys,
>>
>> ** **
>>
>> I have an issue... I created a custom image based on NVIDIA Tegra2 with a
>> custom kernel. I installed  packages specific Tegra board and application
>> specific. Now we want to send the baord and the new linux image for
>> application development... 
>>
>> ** **
>>
>> As I went through ADT manual, I only found qemu based toolchains but I
>> want to create toolchain based on my rootfs and kernel... so that the
>> development team can develop a voip application for the board... I am kind
>> of stuck how to proceed in this issue...
>>
>> ** **
>>
>> I really need a small way out and hopefully I will catch things
>> automatically..
>>
>> ** **
>>
>> Cheers,
>>
>> Satya
>>
>
>
__

[yocto] staging of native header file to non-native package

2013-06-07 Thread Hans Beckérus

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 not
configure/compile anything but only installs the header file? But that
seems ugly :( Must be some more clever way if solving this?

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

Re: [yocto] Distributing Compilation of Yocto

2013-06-07 Thread Paul Eggleton

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 dedicated to building Yocto, but I can only use one if I can't
> get this setup.  I would really appreciate any help and/or pointers anyone
> can give on this.

If you haven't already seen this, you might find it interesting:

http://www.openembedded.org/wiki/Using_IceCC

I've not tried it myself but I know a couple of people have used it 
successfully recently.

Cheers,
Paul

-- 

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

Re: [yocto] Can Yocto run on host with other CPU types

2013-06-07 Thread Richard Purdie

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 others aren't
tested afaik.

Cheers,

Richard

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

Re: [yocto] Can Yocto run on host with other CPU types

2013-06-07 Thread Luo Zhenhua-B19537

> -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, Powerpc, etc?
> 
> You mean as the system to run the builds on? 
[Luo Zhenhua-B19537] Yes

> In theory that would be possible although most people tend to use x86 and the 
> others aren't
> tested afaik.
[Luo Zhenhua-B19537] Does it make sense to log defects in YP bugzilla if issue 
is found on host with those CPU types?

BTW, is there a limitation for maximum parallel number of Yocto build? I don't 
think the number can be arbitrary. 


Best Regards,

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

Re: [yocto] Distributing Compilation of Yocto

2013-06-07 Thread Gary Thomas


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 each have two Xeon quadcore
processors dedicated to building Yocto, but I can only use one if I can't
get this setup.  I would really appreciate any help and/or pointers anyone
can give on this.


If you haven't already seen this, you might find it interesting:

http://www.openembedded.org/wiki/Using_IceCC

I've not tried it myself but I know a couple of people have used it
successfully recently.


Looks interesting and I think I'd like to try it myself.  However, that page
has a reference to 
http://bugs.openembedded.org/attachment.cgi?id=1032&action=view
which seems to be down at the moment (tested from both sides of the pond)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [Refactor RFC 5/9] Remove storing of init script location

2013-06-07 Thread Grigoropol, IoanaX

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 
at this point need to be fixed due to the changes I have introduced, otherwise 
they will not compile.

Thanks,
Ioana

From: Zhang, Jessica
Sent: Friday, June 07, 2013 3:02 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [Refactor RFC 5/9] Remove storing of init script location

Why we want to remove this project info file, since it's not used now but it 
stated it's used for future.

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Tuesday, June 04, 2013 6:26 AM
To: yocto@yoctoproject.org
Subject: [yocto] [Refactor RFC 5/9] Remove storing of init script location

- when create a new bitbake commander project and when initializing the 
configuration - the location of the init bitbake script is stored in a file 
called .eclipse-data
- the information stored here is never used

Signed-off-by: Ioana Grigoropol 
---
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   23 
 .../BBConfigurationInitializeOperation.java|1 -
 .../newproject/CreateBBCProjectOperation.java  |6 -
 3 files changed, 30 deletions(-)

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ProjectInfoHelper.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ProjectInfoHelper.java
index 25dac97..b8d4b29 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ProjectInfoHelper.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ProjectInfoHelper.java
@@ -79,27 +79,4 @@ public class ProjectInfoHelper {

return null;
}
-
-   /**
-* This method will store the path to the bitbake init script for future
-* reference.
-*
-* @param path
-* @param projInfo
-* @throws IOException
-*/
-   public static void store(String path, ProjectInfo projInfo) throws 
IOException {
-   writeToFile(path, projInfo.getInitScriptPath());
-   }
-
-   private static void writeToFile(String path, String init) throws 
IOException {
-   File outFile = new File(path, ".eclipse-data");
-   FileOutputStream fos = new FileOutputStream(outFile);
-
-   fos.write(init.getBytes());
-
-   fos.flush();
-   fos.close();
-   }
-
 }
diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/BBConfigurationInitializeOperation.java
 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/BBConfigurationInitializeOperation.java
index 4f15107..64c3e6e 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/BBConfigurationInitializeOperation.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/BBConfigurationInitializeOperation.java
@@ -39,7 +39,6 @@ public class BBConfigurationInitializeOperation implements 
IRunnableWithProgress
public void run(IProgressMonitor monitor) throws 
InvocationTargetException, InterruptedException {
BBSession session;
try {
-   ProjectInfoHelper.store(pinfo.getRootPath(), pinfo);
session = Activator.getBBSession(pinfo.getRootPath(), 
writer);
session.initialize();

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/CreateBBCProjectOperation.java
 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/CreateBBCProjectOperation.java
index dc0153b..1d54ea3 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/CreateBBCProjectOperation.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/newproject/CreateBBCProjectOperation.java
@@ -85,12 +85,6 @@ public class CreateBBCProjectOperation extends 
WorkspaceModifyOperation {

IProject proj = wsroot.getProject(projInfo.getProjectName());
proj.create(desc, monitor);
-   try {
-   
ProjectInfoHelper.store(proj.getLocationURI().getPath(), projInfo);
-   } catch (IOException e) {
-   throw new InvocationTargetException(e);
-   }
-
proj.open(monitor);

addNatures(proj, monitor);
--
1.7.9.5

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

Re: [yocto] [Refactor RFC 4/9] Remove unused Bitbake Actions

2013-06-07 Thread Grigoropol, IoanaX

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] Remove unused Bitbake Actions

We can't remove them, since we should support build a specific recipe as from 
the command line.

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Tuesday, June 04, 2013 6:26 AM
To: yocto@yoctoproject.org
Subject: [yocto] [Refactor RFC 4/9] Remove unused Bitbake Actions

- none of the Bitbake action classes that inherit from 
AbstractBitbakeCommandAction is used -> clean-up classes & plugin.xml

Signed-off-by: Ioana Grigoropol 
---
 plugins/org.yocto.bc.ui/plugin.xml |   55 --
 .../ui/actions/AbstractBitbakeCommandAction.java   |  198 
 .../bc/ui/actions/BitbakeBuildRecipeAction.java|   24 ---
 .../bc/ui/actions/BitbakeCleanRecipeAction.java|   26 ---
 .../yocto/bc/ui/actions/BitbakeImportAction.java   |  106 ---
 .../bc/ui/actions/BitbakeRebuildRecipeAction.java  |   29 ---
 6 files changed, 438 deletions(-)
 delete mode 100644 
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/actions/AbstractBitbakeCommandAction.java
 delete mode 100644 
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/actions/BitbakeBuildRecipeAction.java
 delete mode 100644 
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/actions/BitbakeCleanRecipeAction.java
 delete mode 100644 
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/actions/BitbakeImportAction.java
 delete mode 100644 
plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/actions/BitbakeRebuildRecipeAction.java

diff --git a/plugins/org.yocto.bc.ui/plugin.xml 
b/plugins/org.yocto.bc.ui/plugin.xml
index cb0561c..2e1421f 100644
--- a/plugins/org.yocto.bc.ui/plugin.xml
+++ b/plugins/org.yocto.bc.ui/plugin.xml
@@ -39,61 +39,6 @@
 commandId="org.yocto.bc.ui.command.launchHob">
   

-   

   http://www.eclipse.org/legal/epl-v10.html
- *
- * Contributors:
- * Ken Gilmer - initial API and implementation
- 
***/
-package org.yocto.bc.ui.actions;
-
-import java.io.IOException;
-
-import org.eclipse.core.resources.IFile; -import 
org.eclipse.core.resources.IProject;
-import org.eclipse.core.runtime.CoreException;
-import org.eclipse.core.runtime.IProgressMonitor;
-import org.eclipse.core.runtime.IStatus; -import 
org.eclipse.core.runtime.Status; -import org.eclipse.core.runtime.jobs.Job;
-import org.eclipse.jface.action.IAction; -import 
org.eclipse.jface.preference.JFacePreferences;
-import org.eclipse.jface.resource.JFaceResources;
-import org.eclipse.jface.viewers.ISelection;
-import org.eclipse.jface.viewers.IStructuredSelection;
-import org.eclipse.swt.graphics.Color;
-import org.eclipse.ui.IWorkbenchWindow; -import 
org.eclipse.ui.IWorkbenchWindowActionDelegate;
-import org.eclipse.ui.console.MessageConsole;
-import org.eclipse.ui.console.MessageConsoleStream;
-import org.yocto.bc.bitbake.BBLanguageHelper;
-import org.yocto.bc.bitbake.BBSession;
-import org.yocto.bc.ui.Activator;
-import org.yocto.bc.ui.builder.BitbakeCommanderNature;
-import org.yocto.remote.utils.ICommandResponseHandler;
-
-public abstract class AbstractBitbakeCommandAction implements 
IWorkbenchWindowActionDelegate {
-
-   private class CommandJob extends Job {
-
-   public CommandJob() {
-   super(getJobTitle());
-   }
-
-   @Override
-   protected IStatus run(IProgressMonitor monitor) {
-   String cmds[] = getCommands();
-   return execCommands(cmds, monitor);
-   }
-
-   }
-   protected IAction action;
-   protected IFile recipe;
-   protected BBSession bbs;
-
-   private Color commandColor, responseColor, errorColor;
-   private boolean errorOccurred = false;
-
-   public AbstractBitbakeCommandAction() {
-   commandColor = 
JFaceResources.getColorRegistry().get(JFacePreferences.ACTIVE_HYPERLINK_COLOR);
-   responseColor = 
JFaceResources.getColorRegistry().get(JFacePreferences.HYPERLINK_COLOR);
-   errorColor = 
JFaceResources.getColorRegistry().get(JFacePreferences.ERROR_COLOR);
-   }
-
-   private void checkEnabled(IFile file) {
-   try {
-   if (file.getFileExtension() == null || 
!file.getFileExtension().equals(BBLanguageHelper.BITBAKE_RECIPE_FILE_EXTENSION))
 {
-   action.setEnabled(false);
-   return;
-   }
-
-   IProject project = file.getProject();
-   if 
(!(project.hasNature(BitbakeCommanderNature.NATURE_ID)))

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus

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 for debugging/profiling)
> #  "dev-pkgs"   - add -dev packages for all installed packages
> # (useful if you want to develop against libs in the
> image)
>
>
> Greets,
> Satya
>
I actually tried the 'bitbake  -c populate-sdk but it fails :(
Any clues to what make things go wrong this time? Nothing provides
meta-environment-arm??

Hans

| Note: adding Smart channel x86_64_nativesdk (25)
|
|
| Note: adding Smart channel all (10)
|
|
| Note: configuring RPM cross-install scriptlet_wrapper
|
| Updating cache...
 [100%]
|
| Saving cache...
|
| Note: adding Smart RPM DB channel
|
| Note: to be installed:  nativesdk-packagegroup-sdk-host@all
packagegroup-cross-canadian-arm@all
| Loading cache...
| Updating cache...
 [100%]
|
| Computing transaction...error: Can't install
packagegroup-cross-canadian-arm-1.0-r0@all: no package provides
meta-environment-arm
|
| Saving cache...
|
| DEBUG: Python function do_populate_sdk finished




>
> On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
>  wrote:
>>
>> Hi Jessica & Philip,
>>
>> I have an issue... This is such a long error ... I even did a fresh build
>> by deleting the "tmp" directory. The image build went very well but the
>> toolchain is always giving me a error...
>>
>> | Selecting previously unselected package xz-dev.
>> | Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
>> | The following package disappeared from your system as
>> | all files have been overwritten by other packages:
>> |   avahi
>> | log_check: Using
>> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
>> as logfile
>> | Logfile is clean
>> | Installing NATIVESDK packages
>> | Ign file: ./ InRelease
>> | Ign file: ./ InRelease
>> | Ign file: ./ Release.gpg
>> | Ign file: ./ Release.gpg
>> | Get:1 file: ./ Release [24 B]
>> | Get:2 file: ./ Release [11 B]
>> | Ign file: ./ Translation-en
>> | Ign file: ./ Translation-en
>> | Reading package lists...
>> | W: Ignoring Provides line with DepCompareOp for package
>> nativesdk-pkgconfig__pkg-config__
>> | W: You may want to run apt-get update to correct these problems
>> | Reading package lists...
>> | Building dependency tree...
>> | Reading state information...
>> | Some packages could not be installed. This may mean that you have
>> | requested an impossible situation or if you are using the unstable
>> | distribution that some required packages have not yet been created
>> | or been moved out of Incoming.
>> | The following information may help to resolve the situation:
>> |
>> | The following packages have unmet dependencies:
>> |  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but
>> it is not installable
>> |Depends: gcc-cross-canadian-arm but
>> it is not installable
>> |Depends: meta-environment-arm but it
>> is not installable
>> |Depends: binutils-cross-canadian-arm
>> but it is not installable
>> | W: Ignoring Provides line with DepCompareOp for package
>> nativesdk-pkgconfig__pkg-config__
>> | W: You may want to run apt-get update to correct these problems
>> | E: Unable to correct problems, you have held broken packages.
>> | DEBUG: Python function do_populate_sdk finished
>> | ERROR: Function failed: populate_sdk_image (see
>> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
>> for further information)
>> ERROR: Task 10
>> (/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
>> do_populate_sdk) failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>
>> /home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
>> do_populate_sdk
>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>>
>> I am not able to install those packages as they say there are no
>> installation candidate for them...
>>
>>
>> On Thu, Jun 6, 2013 at 6:52 AM, Zhang, Jessica 
>> wrote:
>>>
>>> Hi Satya,
>>>
>>>
>>>
>>> Use bitbake image-name –c populate_sdk, this allows you to create a
>>> toolchain with sysroot that match your target image that allows you to
>>> develop app against…
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Jessica
>>>
>>>
>>>
>>> From: yocto-boun...@yoctoproject.org
>>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Satya Swaroop Damarla
>>> Sent: Wednesday, Jun

Re: [yocto] Application Development

2013-06-07 Thread Gary Thomas


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
# (adds symbol information for debugging/profiling)
#  "dev-pkgs"   - add -dev packages for all installed packages
# (useful if you want to develop against libs in the
image)


Greets,
Satya


I actually tried the 'bitbake  -c populate-sdk but it fails :(
Any clues to what make things go wrong this time? Nothing provides
meta-environment-arm??


Do you have "tools-sdk" set in your IMAGE_FEATURES?



Hans

| Note: adding Smart channel x86_64_nativesdk (25)
|
|
| Note: adding Smart channel all (10)
|
|
| Note: configuring RPM cross-install scriptlet_wrapper
|
| Updating cache...
 [100%]
|
| Saving cache...
|
| Note: adding Smart RPM DB channel
|
| Note: to be installed:  nativesdk-packagegroup-sdk-host@all
packagegroup-cross-canadian-arm@all
| Loading cache...
| Updating cache...
 [100%]
|
| Computing transaction...error: Can't install
packagegroup-cross-canadian-arm-1.0-r0@all: no package provides
meta-environment-arm
|
| Saving cache...
|
| DEBUG: Python function do_populate_sdk finished






On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
 wrote:


Hi Jessica & Philip,

I have an issue... This is such a long error ... I even did a fresh build
by deleting the "tmp" directory. The image build went very well but the
toolchain is always giving me a error...

| Selecting previously unselected package xz-dev.
| Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
| The following package disappeared from your system as
| all files have been overwritten by other packages:
|   avahi
| log_check: Using
/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
as logfile
| Logfile is clean
| Installing NATIVESDK packages
| Ign file: ./ InRelease
| Ign file: ./ InRelease
| Ign file: ./ Release.gpg
| Ign file: ./ Release.gpg
| Get:1 file: ./ Release [24 B]
| Get:2 file: ./ Release [11 B]
| Ign file: ./ Translation-en
| Ign file: ./ Translation-en
| Reading package lists...
| W: Ignoring Provides line with DepCompareOp for package
nativesdk-pkgconfig__pkg-config__
| W: You may want to run apt-get update to correct these problems
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
|
| The following packages have unmet dependencies:
|  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but
it is not installable
|Depends: gcc-cross-canadian-arm but
it is not installable
|Depends: meta-environment-arm but it
is not installable
|Depends: binutils-cross-canadian-arm
but it is not installable
| W: Ignoring Provides line with DepCompareOp for package
nativesdk-pkgconfig__pkg-config__
| W: You may want to run apt-get update to correct these problems
| E: Unable to correct problems, you have held broken packages.
| DEBUG: Python function do_populate_sdk finished
| ERROR: Function failed: populate_sdk_image (see
/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
for further information)
ERROR: Task 10
(/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
do_populate_sdk) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
do_populate_sdk
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

I am not able to install those packages as they say there are no
installation candidate for them...


On Thu, Jun 6, 2013 at 6:52 AM, Zhang, Jessica 
wrote:


Hi Satya,



Use bitbake image-name –c populate_sdk, this allows you to create a
toolchain with sysroot that match your target image that allows you to
develop app against…



Cheers,

Jessica



From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Satya Swaroop Damarla
Sent: Wednesday, June 05, 2013 6:05 AM
To: yocto@yoctoproject.org
Subject: [yocto] Application Development



Hi Guys,



I have an issue... I created a custom image based on NVIDIA Tegra2 with a
custom kernel. I installe

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus

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
>>>
>>>   "dbg-pkgs"   - add -dbg packages for all installed packages
>>> # (adds symbol information for debugging/profiling)
>>> #  "dev-pkgs"   - add -dev packages for all installed packages
>>> # (useful if you want to develop against libs in the
>>> image)
>>>
>>>
>>> Greets,
>>> Satya
>>>
>> I actually tried the 'bitbake  -c populate-sdk but it fails :(
>> Any clues to what make things go wrong this time? Nothing provides
>> meta-environment-arm??
>
>
> Do you have "tools-sdk" set in your IMAGE_FEATURES?
>
Actually no. I did not find a reference of it in the ADT documentation
so I did not know it was required.
It will try again.

>>
>> | Note: adding Smart channel x86_64_nativesdk (25)
>> |
>> |
>> | Note: adding Smart channel all (10)
>> |
>> |
>> | Note: configuring RPM cross-install scriptlet_wrapper
>> |
>> | Updating cache...
>>  [100%]
>> |
>> | Saving cache...
>> |
>> | Note: adding Smart RPM DB channel
>> |
>> | Note: to be installed:  nativesdk-packagegroup-sdk-host@all
>> packagegroup-cross-canadian-arm@all
>> | Loading cache...
>> | Updating cache...
>>  [100%]
>> |
>> | Computing transaction...error: Can't install
>> packagegroup-cross-canadian-arm-1.0-r0@all: no package provides
>> meta-environment-arm
>> |
>> | Saving cache...
>> |
>> | DEBUG: Python function do_populate_sdk finished
>>
>>
>>
>>
>>>
>>> On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
>>>  wrote:

 Hi Jessica & Philip,

 I have an issue... This is such a long error ... I even did a fresh
 build
 by deleting the "tmp" directory. The image build went very well but the
 toolchain is always giving me a error...

 | Selecting previously unselected package xz-dev.
 | Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
 | The following package disappeared from your system as
 | all files have been overwritten by other packages:
 |   avahi
 | log_check: Using

 /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
 as logfile
 | Logfile is clean
 | Installing NATIVESDK packages
 | Ign file: ./ InRelease
 | Ign file: ./ InRelease
 | Ign file: ./ Release.gpg
 | Ign file: ./ Release.gpg
 | Get:1 file: ./ Release [24 B]
 | Get:2 file: ./ Release [11 B]
 | Ign file: ./ Translation-en
 | Ign file: ./ Translation-en
 | Reading package lists...
 | W: Ignoring Provides line with DepCompareOp for package
 nativesdk-pkgconfig__pkg-config__
 | W: You may want to run apt-get update to correct these problems
 | Reading package lists...
 | Building dependency tree...
 | Reading state information...
 | Some packages could not be installed. This may mean that you have
 | requested an impossible situation or if you are using the unstable
 | distribution that some required packages have not yet been created
 | or been moved out of Incoming.
 | The following information may help to resolve the situation:
 |
 | The following packages have unmet dependencies:
 |  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but
 it is not installable
 |Depends: gcc-cross-canadian-arm but
 it is not installable
 |Depends: meta-environment-arm but
 it
 is not installable
 |Depends:
 binutils-cross-canadian-arm
 but it is not installable
 | W: Ignoring Provides line with DepCompareOp for package
 nativesdk-pkgconfig__pkg-config__
 | W: You may want to run apt-get update to correct these problems
 | E: Unable to correct problems, you have held broken packages.
 | DEBUG: Python function do_populate_sdk finished
 | ERROR: Function failed: populate_sdk_image (see

 /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
 for further information)
 ERROR: Task 10

 (/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
 do_populate_sdk) failed with exit code '1'
 NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to
 be
 rerun and 1 failed.

 Summary: 1 task failed:

 /home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
 do_populate_sdk
 Summary: There was 1 ERROR message shown,

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus

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 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 all installed packages
 # (useful if you want to develop against libs in the
 image)


 Greets,
 Satya

>>> I actually tried the 'bitbake  -c populate-sdk but it fails :(
>>> Any clues to what make things go wrong this time? Nothing provides
>>> meta-environment-arm??
>>
>>
>> Do you have "tools-sdk" set in your IMAGE_FEATURES?
>>
> Actually no. I did not find a reference of it in the ADT documentation
> so I did not know it was required.
> It will try again.
>
>
Wh. tools-sdk seems to drag in a complete X11 environment! I do
not want that :(
Is there some more lean approach to this I can take? ;)

>>>
>>> | Note: adding Smart channel x86_64_nativesdk (25)
>>> |
>>> |
>>> | Note: adding Smart channel all (10)
>>> |
>>> |
>>> | Note: configuring RPM cross-install scriptlet_wrapper
>>> |
>>> | Updating cache...
>>>  [100%]
>>> |
>>> | Saving cache...
>>> |
>>> | Note: adding Smart RPM DB channel
>>> |
>>> | Note: to be installed:  nativesdk-packagegroup-sdk-host@all
>>> packagegroup-cross-canadian-arm@all
>>> | Loading cache...
>>> | Updating cache...
>>>  [100%]
>>> |
>>> | Computing transaction...error: Can't install
>>> packagegroup-cross-canadian-arm-1.0-r0@all: no package provides
>>> meta-environment-arm
>>> |
>>> | Saving cache...
>>> |
>>> | DEBUG: Python function do_populate_sdk finished
>>>
>>>
>>>
>>>

 On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
  wrote:
>
>
> Hi Jessica & Philip,
>
> I have an issue... This is such a long error ... I even did a fresh
> build
> by deleting the "tmp" directory. The image build went very well but the
> toolchain is always giving me a error...
>
> | Selecting previously unselected package xz-dev.
> | Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
> | The following package disappeared from your system as
> | all files have been overwritten by other packages:
> |   avahi
> | log_check: Using
>
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
> as logfile
> | Logfile is clean
> | Installing NATIVESDK packages
> | Ign file: ./ InRelease
> | Ign file: ./ InRelease
> | Ign file: ./ Release.gpg
> | Ign file: ./ Release.gpg
> | Get:1 file: ./ Release [24 B]
> | Get:2 file: ./ Release [11 B]
> | Ign file: ./ Translation-en
> | Ign file: ./ Translation-en
> | Reading package lists...
> | W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__
> | W: You may want to run apt-get update to correct these problems
> | Reading package lists...
> | Building dependency tree...
> | Reading state information...
> | Some packages could not be installed. This may mean that you have
> | requested an impossible situation or if you are using the unstable
> | distribution that some required packages have not yet been created
> | or been moved out of Incoming.
> | The following information may help to resolve the situation:
> |
> | The following packages have unmet dependencies:
> |  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but
> it is not installable
> |Depends: gcc-cross-canadian-arm but
> it is not installable
> |Depends: meta-environment-arm but
> it
> is not installable
> |Depends:
> binutils-cross-canadian-arm
> but it is not installable
> | W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__
> | W: You may want to run apt-get update to correct these problems
> | E: Unable to correct problems, you have held broken packages.
> | DEBUG: Python function do_populate_sdk finished
> | ERROR: Function failed: populate_sdk_image (see
>
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
> for further information)
> ERROR: Task 10
>
> (/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
> do_populate_

Re: [yocto] Application Development

2013-06-07 Thread Zhang, Jessica

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: [yocto] Application Development



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 all installed packages

# (useful if you want to develop against libs in the image)





Greets,

Satya



On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop 
mailto:swaroop.dama...@gmail.com>> wrote:

Hi Jessica & Philip,



I have an issue... This is such a long error ... I even did a fresh build by 
deleting the "tmp" directory. The image build went very well but the toolchain 
is always giving me a error...



| Selecting previously unselected package xz-dev.

| Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...

| The following package disappeared from your system as

| all files have been overwritten by other packages:

|   avahi

| log_check: Using 
/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
 as logfile

| Logfile is clean

| Installing NATIVESDK packages

| Ign file: ./ InRelease

| Ign file: ./ InRelease

| Ign file: ./ Release.gpg

| Ign file: ./ Release.gpg

| Get:1 file: ./ Release [24 B]

| Get:2 file: ./ Release [11 B]

| Ign file: ./ Translation-en

| Ign file: ./ Translation-en

| Reading package lists...

| W: Ignoring Provides line with DepCompareOp for package 
nativesdk-pkgconfig__pkg-config__

| W: You may want to run apt-get update to correct these problems

| Reading package lists...

| Building dependency tree...

| Reading state information...

| Some packages could not be installed. This may mean that you have

| requested an impossible situation or if you are using the unstable

| distribution that some required packages have not yet been created

| or been moved out of Incoming.

| The following information may help to resolve the situation:

|

| The following packages have unmet dependencies:

|  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but it is 
not installable

|Depends: gcc-cross-canadian-arm but it is 
not installable

|Depends: meta-environment-arm but it is 
not installable

|Depends: binutils-cross-canadian-arm but 
it is not installable

| W: Ignoring Provides line with DepCompareOp for package 
nativesdk-pkgconfig__pkg-config__

| W: You may want to run apt-get update to correct these problems

| E: Unable to correct problems, you have held broken packages.

| DEBUG: Python function do_populate_sdk finished

| ERROR: Function failed: populate_sdk_image (see 
/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
 for further information)

ERROR: Task 10 
(/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
 do_populate_sdk) failed with exit code '1'

NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to be rerun 
and 1 failed.



Summary: 1 task failed:

  
/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
 do_populate_sdk

Summary: There was 1 ERROR message shown, returning a non-zero exit code.



I am not able to install those packages as they say there are no installation 
candidate for them...



On Thu, Jun 6, 2013 at 6:52 AM, Zhang, Jessica 
mailto:jessica.zh...@intel.com>> wrote:

   Hi Satya,



   Use bitbake image-name -c populate_sdk, this allows you to create a 
toolchain with sysroot that match your target image that allows you to develop 
app against...



   Cheers,

   Jessica



   From: yocto-boun...@yoctoproject.org 
[mailto:yocto-boun...@yoctoproject.org] 
On Behalf Of Satya Swaroop Damarla
   Sent: Wednesday, June 05, 2013 6:05 AM
   To: yocto@yoctoproject.org
   Subject: [yocto] Application Development



   Hi Guys,



   I have an issue... I created a custom image based on NVIDIA Tegra2 with a 
custom kernel. I installed  packages specific Tegra board and application 
specific. Now we want to send the baord and the new linux image for application 
development...



   As I went through ADT manual, I only found qemu based toolchains but I want 
to create toolchain based on my rootfs and kernel... so that the development 
team can de

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus

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
device rootfs, or?

>
> 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: [yocto] Application Development
>
>
>
> 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 all installed packages
>
> # (useful if you want to develop against libs in the
> image)
>
>
>
>
>
> Greets,
>
> Satya
>
>
>
> On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
>  wrote:
>
> Hi Jessica & Philip,
>
>
>
> I have an issue... This is such a long error ... I even did a fresh build by
> deleting the "tmp" directory. The image build went very well but the
> toolchain is always giving me a error...
>
>
>
> | Selecting previously unselected package xz-dev.
>
> | Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
>
> | The following package disappeared from your system as
>
> | all files have been overwritten by other packages:
>
> |   avahi
>
> | log_check: Using
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
> as logfile
>
> | Logfile is clean
>
> | Installing NATIVESDK packages
>
> | Ign file: ./ InRelease
>
> | Ign file: ./ InRelease
>
> | Ign file: ./ Release.gpg
>
> | Ign file: ./ Release.gpg
>
> | Get:1 file: ./ Release [24 B]
>
> | Get:2 file: ./ Release [11 B]
>
> | Ign file: ./ Translation-en
>
> | Ign file: ./ Translation-en
>
> | Reading package lists...
>
> | W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__
>
> | W: You may want to run apt-get update to correct these problems
>
> | Reading package lists...
>
> | Building dependency tree...
>
> | Reading state information...
>
> | Some packages could not be installed. This may mean that you have
>
> | requested an impossible situation or if you are using the unstable
>
> | distribution that some required packages have not yet been created
>
> | or been moved out of Incoming.
>
> | The following information may help to resolve the situation:
>
> |
>
> | The following packages have unmet dependencies:
>
> |  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm but it
> is not installable
>
> |Depends: gcc-cross-canadian-arm but it
> is not installable
>
> |Depends: meta-environment-arm but it is
> not installable
>
> |Depends: binutils-cross-canadian-arm
> but it is not installable
>
> | W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__
>
> | W: You may want to run apt-get update to correct these problems
>
> | E: Unable to correct problems, you have held broken packages.
>
> | DEBUG: Python function do_populate_sdk finished
>
> | ERROR: Function failed: populate_sdk_image (see
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.4066
> for further information)
>
> ERROR: Task 10
> (/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
> do_populate_sdk) failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to be
> rerun and 1 failed.
>
>
>
> Summary: 1 task failed:
>
>
> /home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skidata.bb,
> do_populate_sdk
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
>
> I am not able to install those packages as they say there are no
> installation candidate for them...
>
>
>
> On Thu, Jun 6, 2013 at 6:52 AM, Zhang, Jessica 
> wrote:
>
> Hi Satya,
>
>
>
> Use bitbake image-name –c populate_sdk, this allows you to create a
> toolchain with sysroot that match your target image that allows you to
> develop app against…
>
>
>
> Cheers,
>
> Jessica
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Satya Swaroop Damarla
> Sent: Wednesday, June 05, 2013 6:05 AM
> To: yocto@yoctoproject.org
> Subject: [yocto] Application Development
>
>
>
> Hi Guys,
>
>
>
> I have an issue... I created a custom image based on NVIDIA Tegra2 with a
> custom kernel. I installed  packages specific Tegra board and application
> specific. Now we want to se

Re: [yocto] Application Development

2013-06-07 Thread Zhang, Jessica

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.  You said you 
were able to build the image, was the x11 packages there?  We're building a 
toolchain plus the sysroot that matching the rootfs of your target image here 
so it's not just the toolchain that is built.

-Original Message-
From: Hans Beckérus [mailto:hans.becke...@gmail.com]
Sent: Friday, June 07, 2013 7:09 AM
To: Zhang, Jessica
Cc: DAMARLA Satya Swaroop; yocto@yoctoproject.org
Subject: Re: [yocto] Application Development

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 device 
rootfs, or?

>
> 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: [yocto] Application Development
>
>
>
> 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 all installed packages
>
> # (useful if you want to develop against libs in the
> image)
>
>
>
>
>
> Greets,
>
> Satya
>
>
>
> On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
>  wrote:
>
> Hi Jessica & Philip,
>
>
>
> I have an issue... This is such a long error ... I even did a fresh
> build by deleting the "tmp" directory. The image build went very well
> but the toolchain is always giving me a error...
>
>
>
> | Selecting previously unselected package xz-dev.
>
> | Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
>
> | The following package disappeared from your system as
>
> | all files have been overwritten by other packages:
>
> |   avahi
>
> | log_check: Using
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-
> poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.
> 4066
> as logfile
>
> | Logfile is clean
>
> | Installing NATIVESDK packages
>
> | Ign file: ./ InRelease
>
> | Ign file: ./ InRelease
>
> | Ign file: ./ Release.gpg
>
> | Ign file: ./ Release.gpg
>
> | Get:1 file: ./ Release [24 B]
>
> | Get:2 file: ./ Release [11 B]
>
> | Ign file: ./ Translation-en
>
> | Ign file: ./ Translation-en
>
> | Reading package lists...
>
> | W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__
>
> | W: You may want to run apt-get update to correct these problems
>
> | Reading package lists...
>
> | Building dependency tree...
>
> | Reading state information...
>
> | Some packages could not be installed. This may mean that you have
>
> | requested an impossible situation or if you are using the unstable
>
> | distribution that some required packages have not yet been created
>
> | or been moved out of Incoming.
>
> | The following information may help to resolve the situation:
>
> |
>
> | The following packages have unmet dependencies:
>
> |  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm
> | but it
> is not installable
>
> |Depends: gcc-cross-canadian-arm
> | but it
> is not installable
>
> |Depends: meta-environment-arm but
> | it is
> not installable
>
> |Depends:
> | binutils-cross-canadian-arm
> but it is not installable
>
> | W: Ignoring Provides line with DepCompareOp for package
> nativesdk-pkgconfig__pkg-config__
>
> | W: You may want to run apt-get update to correct these problems
>
> | E: Unable to correct problems, you have held broken packages.
>
> | DEBUG: Python function do_populate_sdk finished
>
> | ERROR: Function failed: populate_sdk_image (see
> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-
> poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.
> 4066
> for further information)
>
> ERROR: Task 10
> (/home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skid
> ata.bb,
> do_populate_sdk) failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 5020 tasks of which 4939 didn't need to
> be rerun and 1 failed.
>
>
>
> Summary: 1 task failed:
>
>
> /home/damarla/yocto/poky/meta/recipes-graphics/images/core-image-skida
> ta.bb,
> do_populate_sdk
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
>
> I am not able to install those pack

[yocto] gnuradio on beagleboard beagleone & pandaboard

2013-06-07 Thread Edward Vidal

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 beagleboard and meta-oe & meta-ti
for the beaglebone & pandaboard.
The disk space increased from 10% to 64% which I believe is due to
adding dbg-pkgs. On these systems and I noticed that the when logging
in they all came up in / not at /home/root.  I checked /etc/passwd
root:x:0:0:root:/home/root:/bin/sh.  This just occurred after a new
git clone of all meta-data.  Where do you find what caused these
difference in builds?
The build information for the beagleboard is below:
MACHINE=beagleboard bitbake core-image-sato-sdk-ex
boost qt-mobility-x11 gsl gnuplot gnuradio
378 additional pkgs for dbg-pkgs & gnuradio
beagleboard_pkglist060613 1964  RPMs beagleboard_pkglist060613 2342 RPMs
Filesystem 1K-blocksUsed Available Use% Mounted on
/dev/root7467728 4496112   2592276  64% /
devtmpfs  245656   4245652   1% /dev
tmpfs 40   040   0% /mnt/.psplash
tmpfs 245844 212245632   1% /var/volatile
tmpfs 245844   0245844   0% /media/ram
/dev/mmcblk0p1 510824524 46558   9% /media/mmcblk0p1
Linux beagleboard 3.4.36-yocto-standard #1 Thu Jun 6 06:21:51 MDT 2013
armv7l GNU/Linux
Build Configuration:
BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-18"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "beagleboard"
DISTRO= "poky"
DISTRO_VERSION= "1.4.1"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "dylan:b0a5694e3ef1980004a46522780d129bad110eac"
meta-oe   = "master:17ace92714bccf64d0d9fcefaabe3067f59fdf0a"
meta-yocto-bsp= "dylan:b0a5694e3ef1980004a46522780d129bad110eac"
When I execute "gnuradio-companion" I get the following:
** (process:898): WARNING **: Trying to register gtype
'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:898): WARNING **: Trying to register gtype
'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:898): WARNING **: Trying to register gtype
'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Traceback (most recent call last):
  File "/usr/bin/gnuradio-companion", line 67, in 
from gnuradio.grc.python.Platform import Platform
  File "/usr/lib/python2.7/site-packages/gnuradio/grc/python/Platform.py",
line 22, in 
from .. base.Platform import Platform as _Platform
  File "/usr/lib/python2.7/site-packages/gnuradio/grc/base/Platform.py",
line 26, in 
from Block import Block as _Block
  File "/usr/lib/python2.7/site-packages/gnuradio/grc/base/Block.py",
line 23, in 
from Cheetah.Template import Template
  File "/usr/lib/python2.7/site-packages/Cheetah/Template.py", line
21, in 

All help will be appreciated.

Thanks Ed Vidal If I provide please let me know.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus

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 
> packages?  I think x11 is brought in via some package dependency.  You said 
> you were able to build the image, was the x11 packages there?  We're building 
> a toolchain plus the sysroot that matching the rootfs of your target image 
> here so it's not just the toolchain that is built.
>

Hi Jessica.

I am building my own image recipe that basically does:

require recipes-core/images/core-image-minimal-mtdutils.bb
IMAGE_FEATURES += " ssh-server-dropbear \
  "

Its a console-only type of image for an embedded device with no
graphic support what so ever.
Building the the rootfs and booting it up on the device works fine.
I have had no X11 dependency until I added tools-sdk to IMAGE_FEATURES
as suggested.
What I am after is a command-line-only toolchain which will be using
the sysroot from my rootfs build.
Maybe I am asking for something that is not supported?

Hans


> -Original Message-
> From: Hans Beckérus [mailto:hans.becke...@gmail.com]
> Sent: Friday, June 07, 2013 7:09 AM
> To: Zhang, Jessica
> Cc: DAMARLA Satya Swaroop; yocto@yoctoproject.org
> Subject: Re: [yocto] Application Development
>
> 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 device 
> rootfs, or?
>
>>
>> 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: [yocto] Application Development
>>
>>
>>
>> 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 all installed packages
>>
>> # (useful if you want to develop against libs in the
>> image)
>>
>>
>>
>>
>>
>> Greets,
>>
>> Satya
>>
>>
>>
>> On Thu, Jun 6, 2013 at 1:07 PM, DAMARLA Satya Swaroop
>>  wrote:
>>
>> Hi Jessica & Philip,
>>
>>
>>
>> I have an issue... This is such a long error ... I even did a fresh
>> build by deleting the "tmp" directory. The image build went very well
>> but the toolchain is always giving me a error...
>>
>>
>>
>> | Selecting previously unselected package xz-dev.
>>
>> | Unpacking xz-dev (from .../xz-dev_5.1.2alpha-r0_armel.deb) ...
>>
>> | The following package disappeared from your system as
>>
>> | all files have been overwritten by other packages:
>>
>> |   avahi
>>
>> | log_check: Using
>> /home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/skidata_harmony-
>> poky-linux-gnueabi/core-image-skidata/1.0-r0/temp/log.do_populate_sdk.
>> 4066
>> as logfile
>>
>> | Logfile is clean
>>
>> | Installing NATIVESDK packages
>>
>> | Ign file: ./ InRelease
>>
>> | Ign file: ./ InRelease
>>
>> | Ign file: ./ Release.gpg
>>
>> | Ign file: ./ Release.gpg
>>
>> | Get:1 file: ./ Release [24 B]
>>
>> | Get:2 file: ./ Release [11 B]
>>
>> | Ign file: ./ Translation-en
>>
>> | Ign file: ./ Translation-en
>>
>> | Reading package lists...
>>
>> | W: Ignoring Provides line with DepCompareOp for package
>> nativesdk-pkgconfig__pkg-config__
>>
>> | W: You may want to run apt-get update to correct these problems
>>
>> | Reading package lists...
>>
>> | Building dependency tree...
>>
>> | Reading state information...
>>
>> | Some packages could not be installed. This may mean that you have
>>
>> | requested an impossible situation or if you are using the unstable
>>
>> | distribution that some required packages have not yet been created
>>
>> | or been moved out of Incoming.
>>
>> | The following information may help to resolve the situation:
>>
>> |
>>
>> | The following packages have unmet dependencies:
>>
>> |  packagegroup-cross-canadian-arm : Depends: gdb-cross-canadian-arm
>> | but it
>> is not installable
>>
>> |Depends: gcc-cross-canadian-arm
>> | but it
>> is not installable
>>
>> |Depends: meta-environment-arm but
>> | it is
>> not installable
>>
>> |Depends:
>> | binutils-cross-canadian-arm
>> but it is not installable
>>
>> | W: Ignoring Provides line with DepCompareOp for package
>> nativesdk-pkgconfig__pkg-config__
>>
>> | W: You may want to run apt-get update to correct these problems
>>
>> | E: Unable t

[yocto] [RFC Refactor[v2] 1/8] Move ICommandResponseHandler to org.yocto.remote.utils

2013-06-07 Thread Ioana Grigoropol

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/bc/bitbake/ICommandResponseHandler.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ICommandResponseHandler.java

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ICommandResponseHandler.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ICommandResponseHandler.java
deleted file mode 100644
index 4c44352..000
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ICommandResponseHandler.java
+++ /dev/null
@@ -1,15 +0,0 @@
-/*
- * Copyright (c) 2009 Ken Gilmer
- * All rights reserved. This program and the accompanying materials
- * are made available under the terms of the Eclipse Public License v1.0
- * which accompanies this distribution, and is available at
- * http://www.eclipse.org/legal/epl-v10.html
- *
- * Contributors:
- * Ken Gilmer - initial API and implementation
- 
***/
-package org.yocto.bc.bitbake;
-
-public interface ICommandResponseHandler {
-   public void response(String line, boolean isError);
-}
diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ICommandResponseHandler.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ICommandResponseHandler.java
new file mode 100644
index 000..f135dde
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ICommandResponseHandler.java
@@ -0,0 +1,15 @@
+/*
+ * Copyright (c) 2013 Ken Gilmer
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ken Gilmer - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+public interface ICommandResponseHandler {
+   public void response(String line, boolean isError);
+}
-- 
1.7.9.5

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

[yocto] [RFC Refactor[v2] 5/8] Add ConsoleHelper utility class

2013-06-07 Thread Ioana Grigoropol

- 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 insertions(+)
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleHelper.java

diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleHelper.java 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleHelper.java
new file mode 100644
index 000..9c5c244
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleHelper.java
@@ -0,0 +1,38 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+import org.eclipse.swt.widgets.Display;
+import org.eclipse.ui.console.ConsolePlugin;
+import org.eclipse.ui.console.IConsole;
+import org.eclipse.ui.console.IConsoleManager;
+import org.eclipse.ui.console.MessageConsole;
+
+public class ConsoleHelper {
+   public static final String YOCTO_CONSOLE = "Yocto Project Console";
+
+   public static MessageConsole findConsole(String name) {
+   ConsolePlugin plugin = ConsolePlugin.getDefault();
+   IConsoleManager conMan = plugin.getConsoleManager();
+   IConsole[] existing = conMan.getConsoles();
+   for (int i = 0; i < existing.length; i++)
+   if (name.equals(existing[i].getName()))
+   return (MessageConsole) existing[i];
+   // no console found, so create a new one
+   MessageConsole myConsole = new MessageConsole(name, null);
+   conMan.addConsoles(new IConsole[] { myConsole });
+   return myConsole;
+   }
+
+   public static void showConsole(MessageConsole console){
+   Display.getDefault().syncExec(new ConsoleRunnable(console));
+   }
+}
-- 
1.7.9.5

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

[yocto] [RFC Refactor[v2] 0/8] Split refactoring of RemoteHelper

2013-06-07 Thread Ioana Grigoropol

- 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 ConsoleHelper utility class
  Add OutputProcessor utility class
  Add CommandOutputProcessor utilty class
  Refactor RemoteHelper class

 .../yocto/bc/bitbake/ICommandResponseHandler.java  |   15 --
 .../org.yocto.remote.utils/META-INF/MANIFEST.MF|8 +-
 .../yocto/remote/utils/CommandOutputProcessor.java |   43 
 .../yocto/remote/utils/CommandResponseHandler.java |   44 
 .../org/yocto/remote/utils/CommandRunnable.java|   44 
 .../src/org/yocto/remote/utils/ConsoleHelper.java  |   38 +++
 .../org/yocto/remote/utils/ConsoleRunnable.java|   47 
 .../remote/utils/ICommandResponseHandler.java  |   15 ++
 .../org/yocto/remote/utils/OutputProcessor.java|  112 +
 .../src/org/yocto/remote/utils/RemoteHelper.java   |  255 
 .../src/org/yocto/remote/utils/RemoteMachine.java  |  202 
 .../src/org/yocto/remote/utils/YoctoCommand.java   |   63 +
 12 files changed, 822 insertions(+), 64 deletions(-)
 delete mode 100644 
plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ICommandResponseHandler.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandResponseHandler.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandRunnable.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleHelper.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleRunnable.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ICommandResponseHandler.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/OutputProcessor.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteMachine.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/YoctoCommand.java

-- 
1.7.9.5

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

[yocto] [RFC Refactor[v2] 3/8] Add CommandResponseHandler implementation of ICommandResponseHandler

2013-06-07 Thread Ioana Grigoropol

- 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 changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandResponseHandler.java

diff --git a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF 
b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
index c7b57fe..e31d557 100644
--- a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
@@ -23,5 +23,6 @@ Import-Package: org.eclipse.rse.core,
  org.eclipse.rse.subsystems.terminals.core.elements,
  org.eclipse.rse.ui,
  org.eclipse.tm.internal.terminal.control,
- org.eclipse.tm.internal.terminal.provisional.api
+ org.eclipse.tm.internal.terminal.provisional.api,
+ org.eclipse.ui.console
 Export-Package: org.yocto.remote.utils
diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandResponseHandler.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandResponseHandler.java
new file mode 100644
index 000..f02fbfa
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandResponseHandler.java
@@ -0,0 +1,44 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+import org.eclipse.ui.console.MessageConsole;
+import org.eclipse.ui.console.MessageConsoleStream;
+
+public class CommandResponseHandler implements ICommandResponseHandler {
+   private MessageConsoleStream consoleStream;
+   private Boolean errorOccured = false;
+
+   public CommandResponseHandler(MessageConsole console) {
+   try {
+   this.consoleStream = console.newMessageStream();
+   } catch (Exception e) {
+   e.printStackTrace();
+   }
+   }
+
+   public Boolean hasError() {
+   return errorOccured;
+   }
+
+   @Override
+   public void response(String line, boolean isError) {
+   try {
+   if (isError) {
+   errorOccured = true;
+   }
+   consoleStream.println(line);
+   } catch (Exception e) {
+   e.printStackTrace();
+   }
+   }
+
+}
\ No newline at end of file
-- 
1.7.9.5

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

[yocto] [RFC Refactor[v2] 6/8] Add OutputProcessor utility class

2013-06-07 Thread Ioana Grigoropol

- 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)
(using locks for local, and none for remote, as dictated by 
the upstream)
- call processing for each buffer (output and error) using 
processBuffer method
- the processing of each buffer is basically done in the 
same way & the difference stands:
- in the way we determine the end of the line
- in the processing of a single line
- in order to provide a fully customizable approach for 
processing the output
each of the methods that differ are left as abstract
- each line(output or error) is printed in the console and stored 
in the underlying ProcessStreamBuffer

Signed-off-by: Ioana Grigoropol 
---
 .../org.yocto.remote.utils/META-INF/MANIFEST.MF|2 +
 .../org/yocto/remote/utils/OutputProcessor.java|  112 
 .../src/org/yocto/remote/utils/RemoteHelper.java   |2 +
 3 files changed, 116 insertions(+)
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/OutputProcessor.java

diff --git a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF 
b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
index e31d557..408e33a 100644
--- a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
@@ -11,6 +11,8 @@ Bundle-RequiredExecutionEnvironment: JavaSE-1.6
 Import-Package: org.eclipse.rse.core,
  org.eclipse.rse.core.model,
  org.eclipse.rse.core.subsystems,
+ org.eclipse.rse.internal.services.local.shells,
+ org.eclipse.rse.internal.services.shells,
  org.eclipse.rse.internal.terminals.ui,
  org.eclipse.rse.internal.terminals.ui.views,
  org.eclipse.rse.services,
diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/OutputProcessor.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/OutputProcessor.java
new file mode 100644
index 000..401a782
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/OutputProcessor.java
@@ -0,0 +1,112 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.InputStreamReader;
+import java.util.concurrent.locks.Lock;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.rse.internal.services.local.shells.LocalHostShell;
+import org.eclipse.rse.internal.services.shells.TerminalServiceHostShell;
+import org.eclipse.rse.services.shells.HostShellProcessAdapter;
+import org.eclipse.rse.services.shells.IHostShell;
+
+public abstract class OutputProcessor{
+   private static final int ERROR_BUFFER = 1;
+   private static final int OUTPUT_BUFFER = 2;
+   protected String task;
+   protected ProcessStreamBuffer processBuffer;
+   protected IHostShell hostShell;
+   protected CommandResponseHandler cmdHandler;
+   protected IProgressMonitor monitor;
+
+   public OutputProcessor(IProgressMonitor monitor, IHostShell hostShell, 
CommandResponseHandler cmdHandler, String task){
+   this.monitor = monitor;
+   this.hostShell = hostShell;
+   this.processBuffer = new ProcessStreamBuffer(hostShell 
instanceof TerminalServiceHostShell);
+   this.cmdHandler = cmdHandler;
+   this.task = task;
+   }
+   public ProcessStreamBuffer processOutput() throws Exception{
+   if (hostShell == null)
+   throw new Exception("An error has occured while trying 
to run remote command!");
+   monitor.beginTask(this.task, RemoteHelper.TOTALWORKLOAD);
+   Lock lock = null;
+   if (hostShell instanceof LocalHostShell) {
+   lock = ((LocalHostShell)hostShell).getLock();
+   lock.lock();
+   }
+   BufferedReader inbr = null;
+   BufferedReader errbr = null;
+
+   if (hostShell instanceof LocalHostShell) {
+   inbr = ((LocalHostShell)hostShell).getReader(false);
+   errbr = ((LocalHostShell)hostShell).getReader(true);
+

[yocto] [RFC Refactor[v2] 8/8] Refactor RemoteHelper class

2013-06-07 Thread Ioana Grigoropol

- 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 variables in the remote env
- message console & command response handler to log the 
commands ran against the remote machine and their output
- the host connection use to connect to the remote machine
- the connected subsytem of the remote system and its file 
service(needed for any operations on the file system)
- all the information that is stored in the RemoteMachine makes it 
easier to map connections to remote machines

RemoteHelper:
- refactor helper to be used as a lazy singleton class-> all fields are 
initialized upon demand
- refactor helper to group all fields that are machine specific togheter:
- added map for storing connection->remote machine associations
- retrieve console for remote machine implementation instead of 
using a different one for each invocation
- retrieve command response handler for the remote machine 
instead of using one global one
- retrive file service for particular remote machine given the 
connection
- retrieve connected shell service for the remote machine given 
the connection
- refactor helper to be able to run commands on remote hosts in a synchronous 
way (wait for the command to finish, process output/error)
- run all commands using CommandRunnable wrapper(handleRunCommandRemote 
method)
- added methods for:
- creating a new URI given a parent URI
- retrieving remote input stream for a specific file
- checking if a file exists on the remote host
- retriving a remote IHostFile
- retrieve remote directory content
- retrieve connection for given URI

Signed-off-by: Ioana Grigoropol 
---
 .../org.yocto.remote.utils/META-INF/MANIFEST.MF|3 +
 .../org/yocto/remote/utils/CommandRunnable.java|   44 
 .../src/org/yocto/remote/utils/RemoteHelper.java   |  253 
 .../src/org/yocto/remote/utils/RemoteMachine.java  |  202 
 4 files changed, 454 insertions(+), 48 deletions(-)
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandRunnable.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteMachine.java

diff --git a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF 
b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
index 408e33a..06d14f8 100644
--- a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
@@ -16,10 +16,13 @@ Import-Package: org.eclipse.rse.core,
  org.eclipse.rse.internal.terminals.ui,
  org.eclipse.rse.internal.terminals.ui.views,
  org.eclipse.rse.services,
+ org.eclipse.rse.services.clientserver.messages,
  org.eclipse.rse.services.files,
  org.eclipse.rse.services.shells,
  org.eclipse.rse.services.terminals,
+ org.eclipse.rse.subsystems.files.core.model,
  org.eclipse.rse.subsystems.files.core.servicesubsystem,
+ org.eclipse.rse.subsystems.files.core.subsystems,
  org.eclipse.rse.subsystems.shells.core.subsystems.servicesubsystem,
  org.eclipse.rse.subsystems.terminals.core,
  org.eclipse.rse.subsystems.terminals.core.elements,
diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandRunnable.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandRunnable.java
new file mode 100644
index 000..8cbda18
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandRunnable.java
@@ -0,0 +1,44 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+import org.eclipse.core.runtime.CoreException;
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.rse.core.model.IHost;
+import org.eclipse.rse.services.shells.IHostShell;
+
+public class CommandRunnable implements Runnable{
+   private IHostShell hostShell;
+   private final IHost connection;
+   private final YoctoCommand cmd;
+   private final IProgressMonitor monitor;
+   private final CommandResponseHandler cmdHandler;
+
+   CommandRunnable(IHost connection, YoctoCommand cmd, IProgressMonitor 
monitor){
+   this.connection = co

[yocto] [RFC Refactor[v2] 2/8] Add YoctoCommand utility class

2013-06-07 Thread Ioana Grigoropol

- 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
- this class will simplify the process of running a remote command by wrapping 
all needed data into one object

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/remote/utils/YoctoCommand.java   |   63 
 1 file changed, 63 insertions(+)
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/YoctoCommand.java

diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/YoctoCommand.java 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/YoctoCommand.java
new file mode 100644
index 000..b37d526
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/YoctoCommand.java
@@ -0,0 +1,63 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+
+public class YoctoCommand {
+   private String command;
+   private String initialDirectory;
+   private String arguments;
+   private ProcessStreamBuffer processBuffer;
+
+   public YoctoCommand(String command, String initialDirectory, String 
arguments){
+   this.setCommand(command);
+   this.setInitialDirectory(initialDirectory);
+   this.setArguments(arguments);
+   this.setProcessBuffer(new ProcessStreamBuffer(false));
+   }
+
+   public String getCommand() {
+   return command;
+   }
+
+   public void setCommand(String command) {
+   this.command = command;
+   }
+
+   public String getInitialDirectory() {
+   return initialDirectory;
+   }
+
+   public void setInitialDirectory(String initialDirectory) {
+   this.initialDirectory = initialDirectory;
+   }
+
+   public String getArguments() {
+   return arguments;
+   }
+
+   public void setArguments(String arguments) {
+   this.arguments = arguments;
+   }
+
+   public ProcessStreamBuffer getProcessBuffer() {
+   return processBuffer;
+   }
+
+   public void setProcessBuffer(ProcessStreamBuffer processBuffer) {
+   this.processBuffer = processBuffer;
+   }
+
+   @Override
+   public String toString() {
+   return command + " " + arguments;
+   }
+}
-- 
1.7.9.5

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

[yocto] [RFC Refactor[v2] 4/8] Add ConsoleRunnable utility class

2013-06-07 Thread Ioana Grigoropol

- 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.remote.utils/src/org/yocto/remote/utils/ConsoleRunnable.java

diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleRunnable.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleRunnable.java
new file mode 100644
index 000..e5fe666
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleRunnable.java
@@ -0,0 +1,47 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+import org.eclipse.ui.IWorkbench;
+import org.eclipse.ui.IWorkbenchPage;
+import org.eclipse.ui.IWorkbenchWindow;
+import org.eclipse.ui.PlatformUI;
+import org.eclipse.ui.console.IConsoleConstants;
+import org.eclipse.ui.console.IConsoleView;
+import org.eclipse.ui.console.MessageConsole;
+
+public class ConsoleRunnable implements Runnable{
+   MessageConsole console;
+   ConsoleRunnable (MessageConsole console){
+   this.console = console;
+   }
+   @Override
+   public void run() {
+   IWorkbench wb = PlatformUI.getWorkbench();
+   if (wb == null)
+   return;
+   IWorkbenchWindow win = wb.getActiveWorkbenchWindow();
+   if (win == null)
+   return;
+   IWorkbenchPage page = win.getActivePage();
+   if (page == null)
+   return;
+   String id = IConsoleConstants.ID_CONSOLE_VIEW;
+   try {
+   IConsoleView view = (IConsoleView) page.showView(id);
+   if (view == null)
+   return;
+   view.display(console);
+   } catch (Exception e) {
+   e.printStackTrace();
+   }
+   }
+}
\ No newline at end of file
-- 
1.7.9.5

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

[yocto] [RFC Refactor[v2] 7/8] Add CommandOutputProcessor utilty class

2013-06-07 Thread Ioana Grigoropol

- 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(+)
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java

diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java
new file mode 100644
index 000..081e6d4
--- /dev/null
+++ 
b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java
@@ -0,0 +1,43 @@
+/***
+ * Copyright (c) 2013 Intel Corporation.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Ioana Grigoropol(Intel) - initial API and implementation
+ 
***/
+package org.yocto.remote.utils;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.rse.services.shells.IHostShell;
+
+public class CommandOutputProcessor extends OutputProcessor {
+
+   public CommandOutputProcessor(IProgressMonitor monitor,
+   IHostShell hostShell, CommandResponseHandler 
cmdHandler, String task) {
+   super(monitor, hostShell, cmdHandler, task);
+   }
+
+   @Override
+   protected boolean isErrChStop(char ch) {
+   return (ch == '\n');
+   }
+
+   @Override
+   protected boolean isOutChStop(char ch) {
+   return (ch == '\n');
+   }
+
+   @Override
+   protected void processOutputBufferLine(char ch, String str) {
+   processBuffer.addOutputLine(str);
+   }
+
+   @Override
+   protected void processErrorBufferLine(char ch, String str) {
+   processBuffer.addErrorLine(str);
+   }
+
+}
-- 
1.7.9.5

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

[yocto] [RFC PATCH 00/50] Refactor and merge windows-build to master

2013-06-07 Thread Ioana Grigoropol

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-contrib igrigorx/common-remote-refactor
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=igrigorx/common-remote-refactor

Ioana Grigoropol (50):
  Rename RSEHelper to RemoteHelper to match usages in
org.yocto.bc.ui.plugin
  Add ProcessStreamBuffer utility class
  Move ICommandResponseHandler to org.yocto.remote.utils
  Add YoctoCommand utility class
  Add CommandResponseHandler implementation of ICommandResponseHandler
  Add ConsoleRunnable utility class
  Add ConsoleHelper utility class
  Add OutputProcessor utility class
  Add CommandOutputProcessor utilty class
  Refactor RemoteHelper class
  Remove ICommandResponseHandler from plugin and use
org.yocto.remote.utils implementation
  Remove unused Bitbake Actions
  Remove storing of init script location
  Remove unused method loadInit in Activator
  Remove unused getInitScript from ProjectInfoHelper
  Use URI for storing project locations
  Redirect bitbake environment parsing to file & parse
  Use YoctoHostFile for storing OEFile(s)
  Remove unused checkReadOnlyParent method of OEFile
  Fix full path of OEFile
  Fix NullPointerException when detecting changed files
  Fix Hob launching on Linux host
  Enable edit&save of remote files
  Fix variables hoover
  Fix ShellSession execute
  Remove shell type from ShellSession constructor
  Use / as separator  instead of OS separator
  Remove unsed methods & inner classes from ShellSession
  Save active connection for Bitbake recipe
  Initialize and store the connection on Recipe Wizard
  Store connection for recipe in Recipe Wizard Page
  Refactor Wizard Page fields to have consistent names
  Refactor populate method name
  Break handlePopulate into remote and local functions
  Use uri instead of string to determine location of recipe & determine
archive type
  Store metadata location as URI instead of String
  Refactor Recipe Wizard Page to use Remote target Api
  Run all Recipe task in wizard container
  Enable Populate button when src URI changes
  Store reference to OptionsPage in InstallWizard
  Collect Bitbake error lines
  Refactor Bitbake wizard to use RemoteHelper API
  Retrieve console from RemoteHelper instead of recreating it
  Remove LongRunningTask,ICalculatePercentage from InstallWizard
  Create separated class for ConsoleWriter
  Remove unused ConsoleWriter
  Add implicit constructror for OEFileSystemContributor
  Refactor and clean-up of OptionsPage fields
  Refactor OptionsPage to use Remote Location box & validation
  Validate project name to check for invalid characters

 plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF   |   11 +-
 plugins/org.yocto.bc.ui/plugin.xml |   55 --
 .../src/org/yocto/bc/bitbake/BBRecipe.java |   26 +-
 .../src/org/yocto/bc/bitbake/BBSession.java|  117 +++--
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   58 +--
 .../src/org/yocto/bc/bitbake/ShellSession.java |  164 +++---
 .../org/yocto/bc/remote/utils/ConsoleWriter.java   |   36 ++
 .../bc/remote/utils/YoctoRunnableWithProgress.java |  211 
 .../src/org/yocto/bc/ui/Activator.java |   83 ++-
 .../ui/actions/AbstractBitbakeCommandAction.java   |  199 
 .../bc/ui/actions/BitbakeBuildRecipeAction.java|   24 -
 .../bc/ui/actions/BitbakeCleanRecipeAction.java|   26 -
 .../yocto/bc/ui/actions/BitbakeImportAction.java   |  106 
 .../bc/ui/actions/BitbakeRebuildRecipeAction.java  |   29 --
 .../bc/ui/actions/LaunchVariableWizardAction.java  |   16 +-
 .../bc/ui/builder/BitbakeCommanderNature.java  |2 +-
 .../bc/ui/editors/bitbake/BBVariableTextHover.java |   28 +-
 .../editors/bitbake/BitBakeDocumentProvider.java   |   40 +-
 .../bc/ui/editors/bitbake/BitBakeFileEditor.java   |   19 +-
 .../bitbake/BitBakeSourceViewerConfiguration.java  |   18 +-
 .../src/org/yocto/bc/ui/filesystem/OEFile.java |  295 +++
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   37 +-
 .../bc/ui/filesystem/OEFileSystemContributor.java  |3 +
 .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java   |7 +-
 .../org/yocto/bc/ui/filesystem/YoctoLocation.java  |   34 ++
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   75 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |  306 
 .../yocto/bc/ui/views/RecipeContentProvider.java   |2 +-
 .../bc/ui/wizards/BitbakeRecipeUIElement.java  |   15 +-
 .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java  |   41 +-
 .../ui/wizards/NewBitBakeFileRecipeWizardPage.java |  528 +++-
 .../importProject/ImportYoctoProjectWizard.java|7 +-
 .../yocto/bc/ui/wizards/install/InstallWizard.java |  347 +++--
 .../yocto/bc/ui/wizards/install/Op

Re: [yocto] [Refactor RFC 2/9] Add remote tools classes needed for bitbake remote capabilities

2013-06-07 Thread Grigoropol, IoanaX

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 can be 
found also on poky-contrib: igrigorx/common-remote-refactor.

Thanks,
Ioana 

From: Zhang, Jessica
Sent: Friday, June 07, 2013 2:53 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [Refactor RFC 2/9] Add remote tools classes needed for 
bitbake remote capabilities

Hi Ioana,

Please separate this into 2 patches, one is for adding those new util files and 
also please add License for them.  Then make the RemoteHelper.java into a 
separate patch.  Other comments are:

1.please add much more detailed information in your patch to explain why we 
need new util classes and why RemoteHelper.java need to be changed.
2. there're many new functions that using IHost variable and you don't need to 
check for IHost is null case?

Thanks
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Tuesday, June 04, 2013 6:26 AM
To: yocto@yoctoproject.org
Subject: [yocto] [Refactor RFC 2/9] Add remote tools classes needed for bitbake 
remote capabilities

Signed-off-by: Ioana Grigoropol 
---
 .../org.yocto.remote.utils/META-INF/MANIFEST.MF|8 +-
 .../yocto/remote/utils/CommandOutputProcessor.java |   33 +++
 .../yocto/remote/utils/CommandResponseHandler.java |   36 +++
 .../org/yocto/remote/utils/CommandRunnable.java|   34 +++
 .../src/org/yocto/remote/utils/ConsoleHelper.java  |   28 +++
 .../org/yocto/remote/utils/ConsoleRunnable.java|   37 +++
 .../remote/utils/ICommandResponseHandler.java  |   15 ++
 .../org/yocto/remote/utils/OutputProcessor.java|  102 
 .../yocto/remote/utils/ProcessStreamBuffer.java|   77 ++
 .../src/org/yocto/remote/utils/RemoteHelper.java   |  255 
 .../src/org/yocto/remote/utils/RemoteMachine.java  |  206 
 .../src/org/yocto/remote/utils/Session.java|  117 +
 .../src/org/yocto/remote/utils/YoctoCommand.java   |   53 
 13 files changed, 952 insertions(+), 49 deletions(-)  create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandResponseHandler.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandRunnable.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleHelper.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ConsoleRunnable.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ICommandResponseHandler.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/OutputProcessor.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ProcessStreamBuffer.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteMachine.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/Session.java
 create mode 100644 
plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/YoctoCommand.java

diff --git a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF 
b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
index c7b57fe..06d14f8 100644
--- a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
@@ -11,17 +11,23 @@ Bundle-RequiredExecutionEnvironment: JavaSE-1.6
 Import-Package: org.eclipse.rse.core,
  org.eclipse.rse.core.model,
  org.eclipse.rse.core.subsystems,
+ org.eclipse.rse.internal.services.local.shells,
+ org.eclipse.rse.internal.services.shells,
  org.eclipse.rse.internal.terminals.ui,
  org.eclipse.rse.internal.terminals.ui.views,
  org.eclipse.rse.services,
+ org.eclipse.rse.services.clientserver.messages,
  org.eclipse.rse.services.files,
  org.eclipse.rse.services.shells,
  org.eclipse.rse.services.terminals,
+ org.eclipse.rse.subsystems.files.core.model,
  org.eclipse.rse.subsystems.files.core.servicesubsystem,
+ org.eclipse.rse.subsystems.files.core.subsystems,
  org.eclipse.rse.subsystems.shells.core.subsystems.servicesubsystem,
  org.eclipse.rse.subsystems.terminals.core,
  org.eclipse.rse.subsystems.terminals.core.elements,
  org.eclipse.rse.ui,
  org.eclipse.tm.internal.terminal.control,
- org.eclipse.tm.internal.terminal.provisional.api
+ org.eclipse.tm.internal.terminal.provisional.api,
+ org.eclipse.ui.console
 Export-Package: org.yocto.remote.utils
diff --git 
a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/CommandOutputProcessor.java
 
b/plugins/org.yocto.remote.utils/src/org/yocto/rem

Re: [yocto] staging of native header file to non-native package

2013-06-07 Thread Hans Beckérus

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 RDEPENDS ${PN}-include
which will make sure it picks up the staged header file in the target
sysroot. No files will be written to the target rootfs since the .rpm
for ${PN}-include is empty.

But any suggestions to improve on this solution is more than welcome :)

On Fri, Jun 7, 2013 at 10:05 AM, Hans Beckérus  wrote:
> 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 not
> configure/compile anything but only installs the header file? But that
> seems ugly :( Must be some more clever way if solving this?
>
> Hans


On Fri, Jun 7, 2013 at 10:05 AM, Hans Beckérus  wrote:
> 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 not
> configure/compile anything but only installs the header file? But that
> seems ugly :( Must be some more clever way if solving this?
>
> Hans


On Fri, Jun 7, 2013 at 10:05 AM, Hans Beckérus  wrote:
> 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 not
> configure/compile anything but only installs the header file? But that
> seems ugly :( Must be some more clever way if solving this?
>
> Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Application Development

[yocto] staging of native header file to non-native package

Re: [yocto] Distributing Compilation of Yocto

Re: [yocto] Can Yocto run on host with other CPU types

Re: [yocto] Can Yocto run on host with other CPU types

Re: [yocto] Distributing Compilation of Yocto

Re: [yocto] [Refactor RFC 5/9] Remove storing of init script location

Re: [yocto] [Refactor RFC 4/9] Remove unused Bitbake Actions

Re: [yocto] Application Development

Re: [yocto] Application Development

Re: [yocto] Application Development

Re: [yocto] Application Development

Re: [yocto] Application Development

Re: [yocto] Application Development

Re: [yocto] Application Development

[yocto] gnuradio on beagleboard beagleone & pandaboard

Re: [yocto] Application Development

[yocto] [RFC Refactor[v2] 1/8] Move ICommandResponseHandler to org.yocto.remote.utils

[yocto] [RFC Refactor[v2] 5/8] Add ConsoleHelper utility class

[yocto] [RFC Refactor[v2] 0/8] Split refactoring of RemoteHelper

[yocto] [RFC Refactor[v2] 3/8] Add CommandResponseHandler implementation of ICommandResponseHandler

[yocto] [RFC Refactor[v2] 6/8] Add OutputProcessor utility class

[yocto] [RFC Refactor[v2] 8/8] Refactor RemoteHelper class

[yocto] [RFC Refactor[v2] 2/8] Add YoctoCommand utility class

[yocto] [RFC Refactor[v2] 4/8] Add ConsoleRunnable utility class

[yocto] [RFC Refactor[v2] 7/8] Add CommandOutputProcessor utilty class

[yocto] [RFC PATCH 00/50] Refactor and merge windows-build to master

Re: [yocto] [Refactor RFC 2/9] Add remote tools classes needed for bitbake remote capabilities

Re: [yocto] staging of native header file to non-native package

29 matches

Site Navigation

Mail list logo

Footer information