[yocto] [eclipse-poky][PATCH] plugin/sdk.ide: Pre-populate project specific profile form

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

On initial setup the profile form is populated with the values from
the previously selected target profile. This allows the user to
quickly make project specific adaptions of an existing profile.

Signed-off-by: Timo Mueller 
---
 .../sdk/ide/preferences/YoctoSDKProjectPropertyPage.java   | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
index 9f99caf..408ce76 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
@@ -31,14 +31,15 @@ import org.osgi.service.prefs.BackingStoreException;
 import org.yocto.sdk.ide.YoctoProfileElement;
 import org.yocto.sdk.ide.YoctoProfileSetting;
 import org.yocto.sdk.ide.YoctoProjectSpecificSetting;
+import org.yocto.sdk.ide.YoctoSDKChecker;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
 import org.yocto.sdk.ide.YoctoSDKMessages;
-import org.yocto.sdk.ide.utils.YoctoSDKUtils;
-import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
 import org.yocto.sdk.ide.YoctoSDKPlugin;
 import org.yocto.sdk.ide.YoctoUIElement;
 import org.yocto.sdk.ide.YoctoUISetting;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
 
 public class YoctoSDKProjectPropertyPage extends PropertyPage implements
IWorkbenchPropertyPage {
@@ -288,6 +289,15 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
public void switchToProjectSpecificProfile()
{
YoctoUIElement profileElement = 
getElemFromProjectPreferences(getProject());
+   SDKCheckResults result = 
YoctoSDKChecker.checkYoctoSDK(profileElement);
+
+   if ((result != SDKCheckResults.SDK_PASS)) {
+   /* Project specific profile has not yet been defined,
+* leave settings from previously selected profile
+*/
+   return;
+   }
+
yoctoUISetting.setCurrentInput(profileElement);
}
 
-- 
1.8.1.4

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


Re: [yocto] [PATCH][eclipse-poky] plugin/sdk.ide: Pre-populate project specific profile form

2013-06-25 Thread Timo Müller

Hi Jessica,

Zhang, Jessica wrote, On 25.06.2013 23:52:

Hi Timo,

How am I supposed to apply this patch? I tried to apply it against

master first, then the patch2 of your v3 patch series won't apply. If I
apply your v3 patch series first, then this patch won't apply after that...


I've messed up with the prefix, that's why it didn't apply. Sorry about 
that. I'll resend the patch that will apply to the master.




Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Timo Mueller
Sent: Tuesday, June 25, 2013 8:33 AM
To: yocto@yoctoproject.org
Cc: Timo Mueller
Subject: [yocto] [PATCH][eclipse-poky] plugin/sdk.ide: Pre-populate project 
specific profile form

From: Timo Mueller 

On initial setup the profile form is populated with the values from the 
previously selected target profile. This allows the user to quickly make 
project specific adaptions of an existing profile.

If a project specific profile is already defined the form will show the values 
from this configuration.

Signed-off-by: Timo Mueller 
---
  .../sdk/ide/preferences/YoctoSDKProjectPropertyPage.java   | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
index 9f99caf..408ce76 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoS
+++ DKProjectPropertyPage.java
@@ -31,14 +31,15 @@ import org.osgi.service.prefs.BackingStoreException;
  import org.yocto.sdk.ide.YoctoProfileElement;
  import org.yocto.sdk.ide.YoctoProfileSetting;
  import org.yocto.sdk.ide.YoctoProjectSpecificSetting;
+import org.yocto.sdk.ide.YoctoSDKChecker;
  import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
  import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
  import org.yocto.sdk.ide.YoctoSDKMessages;
-import org.yocto.sdk.ide.utils.YoctoSDKUtils;
-import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
  import org.yocto.sdk.ide.YoctoSDKPlugin;  import 
org.yocto.sdk.ide.YoctoUIElement;  import org.yocto.sdk.ide.YoctoUISetting;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;

  public class YoctoSDKProjectPropertyPage extends PropertyPage implements
 IWorkbenchPropertyPage {
@@ -288,6 +289,15 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
 public void switchToProjectSpecificProfile()
 {
 YoctoUIElement profileElement = 
getElemFromProjectPreferences(getProject());
+   SDKCheckResults result =
+YoctoSDKChecker.checkYoctoSDK(profileElement);
+
+   if ((result != SDKCheckResults.SDK_PASS)) {
+   /* Project specific profile has not yet been defined,
+* leave settings from previously selected profile
+*/
+   return;
+   }
+
 yoctoUISetting.setCurrentInput(profileElement);
 }

--
1.8.1.4

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



If this is merged, the "Add target profile quick switch" patch series 
has to be adapted slightly. I'll send a rework of the series in that case.


Best regards,
Timo
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [yocto-docs][PATCH] dev-manual: referencing bugzilla issues

2013-06-25 Thread Rifenbark, Scott M
Trevor, 

I use to have [YOCTO #] in the manual just as you do here.  I was told 
by Saul though that I was not to use the brackets in the commit description.  
That is when I took them out of the manual.  Maybe Saul can add more to this 
explanation.

Thanks,
Scott

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Trevor Woerner
>Sent: Tuesday, June 25, 2013 7:38 PM
>To: yocto@yoctoproject.org
>Cc: patc...@linaro.org
>Subject: [yocto] [yocto-docs][PATCH] dev-manual: referencing bugzilla
>issues
>
>Based on observations from the various mailing lists, it is obvious that
>bugzilla issues are almost always referenced using square brackets.
>
>Signed-off-by: Trevor Woerner 
>---
> documentation/dev-manual/dev-manual-newbie.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/documentation/dev-manual/dev-manual-newbie.xml
>b/documentation/dev-manual/dev-manual-newbie.xml
>index 0c849f5..55e0c58 100644
>--- a/documentation/dev-manual/dev-manual-newbie.xml
>+++ b/documentation/dev-manual/dev-manual-newbie.xml
>@@ -1405,7 +1405,7 @@
> references - any commit that addresses a specific bug
>should include the
> bug ID in the description (typically at the beginning)
>as follows:
> 
>- Fixes YOCTO #
>+ [YOCTO #]
>
>  
> 
>--
>1.8.3.rc1.44.gb387c77
>
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [yocto-docs][PATCH] dev-manual: referencing bugzilla issues

2013-06-25 Thread Trevor Woerner
Based on observations from the various mailing lists, it is obvious that
bugzilla issues are almost always referenced using square brackets.

Signed-off-by: Trevor Woerner 
---
 documentation/dev-manual/dev-manual-newbie.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/dev-manual-newbie.xml 
b/documentation/dev-manual/dev-manual-newbie.xml
index 0c849f5..55e0c58 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -1405,7 +1405,7 @@
 references - any commit that addresses a specific bug should 
include the
 bug ID in the description (typically at the beginning) as 
follows:
 
- Fixes YOCTO #
+ [YOCTO #]
 
  
 
-- 
1.8.3.rc1.44.gb387c77

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


[yocto] Weekly build now available

2013-06-25 Thread Flanagan, Elizabeth
The weekly build is now available:
http://autobuilder.yoctoproject.org/pub/nightly/20130625-2

eclipse-poky60e99763dc9b77307d46eae4f43343948fa49757
meta-fsl-arm3b4c20c4f683b721994ea2e4e364c38601cd3c6b
meta-fsl-ppcd75b5c38492f5fa821b5b2cca89217bef6868420
meta-intel  f6dbf42654aeec5f36dddedda6433a87e01ae726
meta-minnow 286a72ba3f5e29432be1dd77127de5bdc2d988c3
meta-qt34c27cce6688aa39852f3cba5e7b80ec279019605
poky8e9501ffa8726d69412d669580d787ffedb88d34

-- 
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [PATCHv3 0/8][eclipse-poky] Add target profile quick switch

2013-06-25 Thread Zhang, Jessica
Hi Timo,

Now it look much better and also with these patch set, I don't see the multiple 
selection of radio buttons, so I don't think we need the last patch of the 
series which enable the debugging.

The only thing that's not clear to me is, after define the project specific 
settings which is different from profiles. From the menu bar, the project menu, 
when I toggled between profile and project specific setting, by checking into 
the project property window, I can see the correct setting is showing.  But if 
I stayed inside the project property window, if I uncheck my project specific 
setting box, click on ok.  Then I reopen my project property window, recheck 
project specific setting box, I noticed that instead of restoring my project 
specific settings, it copied the prior profile setting.  Which is different 
behavior than other cases that it always able to restore the defined project 
specific settings once I defined it.  So is this a bug or intentional behavior?

Except for this case, everything else looks great to me.

Cheers,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Timo Mueller
Sent: Tuesday, June 25, 2013 8:34 AM
To: yocto@yoctoproject.org
Cc: Timo Mueller
Subject: [yocto] [PATCHv3 0/8][eclipse-poky] Add target profile quick switch

From: Timo Mueller 

Hi,

in conclusion to the previous discussion, we've agreed that the quick switch 
menu will enable the user to select only configured profiles.
An unconfigured project specific profile will be shown as a greyed out option 
in the menu.

There also has been a bug where the projects specific settings and one profile 
could be marked as selected at the same time. I could only reproduce by naming 
the target profile "project-specific" which collides with the radioParamter 
used for the menu. This case is resolved in this patch set. I've additionally 
merged the two places where the state of the menu was set so have one 
consistent place.

In any case, I've added one patch marked as TESTING to enable tracing in the 
relevant components. In case the problem prevails, please enable the tracing 
for th org.yocto.sdk.ide plugin and send me the output.

Changes in v3:
- Only grey out project specific profile if not configured.
- Fix Bug where multiple menu item could be selected at the same time

Changes in v2:
Handle error when project specific profile is not configure more gracefully. 
Instead of showing an error message the button is now greyed out.

Patches 01..07 contain the implementation with the greyed out menu button.

After playing around with the two options discussed in the first patch series, 
I started to prefer inserting a different button in the menu allowing the user 
to quickly navigate to the project preferences instead of just greying it out. 
I've added this in the last patch of the series, so you can compare yourself.

>From original cover letter

if a user wants to change the used target profile of a project he currently has 
to open the project preferences. This can be tedious if he has to switch the 
profile often.

This is a small addition which allows the user to quickly switch the used 
target profile of a project. Instead of having to open the project preferences 
the user can select the project in the navigator and then choose the desired 
target profile from a drop-down menu in the toolbar or from the project menu.


01: Small i18n fix
02..04: Refactoring the project specific utils
05..06: Introduce the target profile toolbar switch
07: Adds the target profile switch to the project menu
08: TESTING: Enalbe tracing to pin down the multi-select problem

Best regards,
Timo

Timo Mueller (8):
  plugins/sdk.ide: Use an internationalized dialog title
  plugins/sdk.ide: Extract project specific util methods
  plugins/sdk.ide: Move project specific util methods
  plugins/sdk.ide: Remove project context from method names
  plugins/sdk.ide: Add command to switch the target profile
  plugins/sdk.ide: Add profile switch menu to the toolbar
  plugins/sdk.ide: Add profile switch menu to the project menu
  TESTING: add tracing for radio menu

 plugins/org.yocto.sdk.ide/.options |   2 +
 .../OSGI-INF/l10n/bundle.properties|   4 +
 plugins/org.yocto.sdk.ide/plugin.xml   | 100 -
 .../sdk/ide/ProjectSpecificContributionItem.java   |  69 ++
 .../sdk/ide/TargetProfileContributionItem.java | 139 
 .../org/yocto/sdk/ide/YoctoSDKMessages.properties  |   4 +
 .../src/org/yocto/sdk/ide/YoctoUISetting.java  |   3 +-
 .../sdk/ide/actions/ProfileSwitchHandler.java  | 134 
 .../natures/YoctoSDKAutotoolsProjectNature.java|   3 +-
 .../ide/preferences/YoctoSDKPreferencePage.java|  11 +-
 .../preferences/YoctoSDKProjectPropertyPage.java   | 130 ++-
 .../sdk/ide/utils/ProjectPreferenceUtils.java  | 240 +
 .../src/org/yocto/sdk/ide/utils/Y

Re: [yocto] [meta-intel][PATCH] lms8: handle different host setups

2013-06-25 Thread Tom Zanussi
On Tue, 2013-06-25 at 17:45 +0100, Ross Burton wrote:
> The configure script looks at the *host* environment to decide where to 
> install
> the init script, so it's location at packaging time can change.
> 
> Signed-off-by: Ross Burton 

Pulled into meta-intel/master.

Thanks,

Tom

> ---
>  common/recipes-bsp/amt/lms8_8.0.0-7.bb |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/common/recipes-bsp/amt/lms8_8.0.0-7.bb 
> b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> index fbb4e45..65c413a 100644
> --- a/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> +++ b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> @@ -26,7 +26,13 @@ INITSCRIPT_PARAMS = "defaults"
>  do_install_append () {
>   mv ${D}/${sbindir}/lms ${D}/${sbindir}/lms8
>   install -d ${D}${sysconfdir}/init.d
> - mv ${D}${sysconfdir}/rc.d/init.d/lms 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
> + # The configure script looks at the host to decide where to put init
> + # scripts, so move it at the same time as renaming it.
> + if test -f ${D}${sysconfdir}/rc.d/init.d/lms ; then
> + mv ${D}${sysconfdir}/rc.d/init.d/lms 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
> + else
> + mv ${D}${sysconfdir}/init.d/lms 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
> + fi
>   sed -i 's/^NAME=lms/NAME=lms8/' 
> ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
>   rmdir ${D}${datadir} || :
>  }


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


Re: [yocto] [meta-intel][PATCH] meta-nuc: don't install lms8 as NUC doesn't support AMT

2013-06-25 Thread Tom Zanussi
On Tue, 2013-06-25 at 17:47 +0100, Ross Burton wrote:
> The NUC doesn't support Active Management Technology, so don't install lms8 as
> part of the machine recommendations.
> 
> Signed-off-by: Ross Burton 

Pulled into meta-intel/master.

Thanks,

Tom

> ---
>  meta-nuc/conf/machine/nuc.conf |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-nuc/conf/machine/nuc.conf b/meta-nuc/conf/machine/nuc.conf
> index 1404f72..f6ae404 100644
> --- a/meta-nuc/conf/machine/nuc.conf
> +++ b/meta-nuc/conf/machine/nuc.conf
> @@ -19,7 +19,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
> ${XSERVER_IA32_I965} \
> "
>  
> -MACHINE_EXTRA_RRECOMMENDS += "lms8 linux-firmware-iwlwifi-6000g2b-6"
> +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2b-6"
>  
>  # disable the serial port configuration
>  SERIAL_CONSOLE = ""


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


Re: [yocto] [meta-intel][PATCH] intel-gpu-tools: add new package

2013-06-25 Thread Tom Zanussi
On Tue, 2013-06-25 at 17:43 +0100, Ross Burton wrote:
> This package contains numerous useful tools for working with Intel GPUs.  Add 
> a
> patch to install intel_panel_fitter as it's genuinely useful and not just a
> debugging tool.
> 
> Signed-off-by: Ross Burton 

Nice addition.

Pulled into meta-intel/master.

Thanks,

Tom

> ---
>  .../intel-gpu-tools/files/install-fitter.patch |   26 
> 
>  .../intel-gpu-tools/intel-gpu-tools_1.3.bb |   15 +++
>  2 files changed, 41 insertions(+)
>  create mode 100644 
> common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
>  create mode 100644 
> common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
> 
> diff --git 
> a/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch 
> b/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
> new file mode 100644
> index 000..2a344c5
> --- /dev/null
> +++ b/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
> @@ -0,0 +1,26 @@
> +The panel_fitter is genuinely useful but not installed, so install it.
> +
> +Upstream-Status: Inappropriate
> +Signed-off-by: Ross Burton 
> +
> +Index: tools/Makefile.am
> +===
> +--- a/tools.orig/Makefile.am 2012-08-21 08:30:29.0 +0100
>  b/tools/Makefile.am  2013-06-25 16:52:34.220504579 +0100
> +@@ -17,13 +17,13 @@
> + intel_forcewaked\
> + intel_dpio_read \
> + intel_dpio_write\
> +-intel_l3_parity
> ++intel_l3_parity \
> ++intel_panel_fitter
> + 
> + noinst_PROGRAMS =   \
> + intel_dump_decode   \
> + intel_infoframes\
> +-intel_lid   \
> +-intel_panel_fitter
> ++intel_lid
> + 
> + dist_bin_SCRIPTS = intel_gpu_abrt
> + 
> diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb 
> b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
> new file mode 100644
> index 000..893c418
> --- /dev/null
> +++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
> @@ -0,0 +1,15 @@
> +require ${COREBASE}/meta/recipes-graphics/xorg-app/xorg-app-common.inc
> +
> +SUMMARY = "Intel GPU tools"
> +DESCRIPTION = "Variety of small tools for testing intel graphics."
> +
> +SRC_URI += "file://install-fitter.patch"
> +
> +SRC_URI[md5sum] = "67facd6241e26e2c68614728e3a932e9"
> +SRC_URI[sha256sum] = 
> "51d22fdb3d415a1b3b7d0a172c1bb24dec6f16116e80a9ce49873f44527f20a0"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=0918806acfedc3e8c0488f2dd61616dd"
> +
> +DEPENDS += "libdrm libpciaccess cairo udev glib-2.0"
> +
> +EXTRA_OECONF = "--disable-nouveau --disable-shader-debugger"


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


Re: [yocto] [PATCH][eclipse-poky] plugin/sdk.ide: Pre-populate project specific profile form

2013-06-25 Thread Zhang, Jessica
Hi Timo,

How am I supposed to apply this patch?  I tried to apply it against master 
first, then the patch2 of your v3 patch series won't apply.  If I apply your v3 
patch series first, then this patch won't apply after that...

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Timo Mueller
Sent: Tuesday, June 25, 2013 8:33 AM
To: yocto@yoctoproject.org
Cc: Timo Mueller
Subject: [yocto] [PATCH][eclipse-poky] plugin/sdk.ide: Pre-populate project 
specific profile form

From: Timo Mueller 

On initial setup the profile form is populated with the values from the 
previously selected target profile. This allows the user to quickly make 
project specific adaptions of an existing profile.

If a project specific profile is already defined the form will show the values 
from this configuration.

Signed-off-by: Timo Mueller 
---
 .../sdk/ide/preferences/YoctoSDKProjectPropertyPage.java   | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
index 9f99caf..408ce76 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoS
+++ DKProjectPropertyPage.java
@@ -31,14 +31,15 @@ import org.osgi.service.prefs.BackingStoreException;
 import org.yocto.sdk.ide.YoctoProfileElement;
 import org.yocto.sdk.ide.YoctoProfileSetting;
 import org.yocto.sdk.ide.YoctoProjectSpecificSetting;
+import org.yocto.sdk.ide.YoctoSDKChecker;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
 import org.yocto.sdk.ide.YoctoSDKMessages;
-import org.yocto.sdk.ide.utils.YoctoSDKUtils;
-import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
 import org.yocto.sdk.ide.YoctoSDKPlugin;  import 
org.yocto.sdk.ide.YoctoUIElement;  import org.yocto.sdk.ide.YoctoUISetting;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;

 public class YoctoSDKProjectPropertyPage extends PropertyPage implements
IWorkbenchPropertyPage {
@@ -288,6 +289,15 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
public void switchToProjectSpecificProfile()
{
YoctoUIElement profileElement = 
getElemFromProjectPreferences(getProject());
+   SDKCheckResults result =
+YoctoSDKChecker.checkYoctoSDK(profileElement);
+
+   if ((result != SDKCheckResults.SDK_PASS)) {
+   /* Project specific profile has not yet been defined,
+* leave settings from previously selected profile
+*/
+   return;
+   }
+
yoctoUISetting.setCurrentInput(profileElement);
}

--
1.8.1.4

___
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] variable override question

2013-06-25 Thread Marc Ferland
Bruce Ashfield  writes:

> On 13-06-25 03:59 PM, Marc Ferland wrote:
>> Hi,
>>
>> I have a linux-yocto_3.4.bbappend file in which I try to override the
>> KERNEL_FEATURES variable. I want it to be empty (I don't want the
>> netfilter stuff that's there by default).
>>
>> So I've tried (in my bbappend):
>>
>> KERNEL_FEATURES = ""
>>
>> but somehow the netfilter.scc file still gets merged in.
>>
>> What am I doing wrong?
>
> Nothing. It's an artifact of the _appends that are present
> in the linux-yocto recipe bbappends. You can clear it, but they'll
> still append.
>
> Those config fragments weren't optional when the recipes were
> created, we've since evolved to the point where they are.
>
> I squeezed in a change to linux-yocto_3.8 before the yocto 1.4
> cutoff, and have changed linux-yocto_3.4 to match, and strangely,
> was about to send a consolidated pull request that contains the
> change.
>
> You can either locally make the same change, and clear:
>
>  KERNEL_EXTRA_FEATURES
>
> or wait for my latest update.
>
Nice, exactly what I was looking for!

Thanks,

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


Re: [yocto] variable override question

2013-06-25 Thread Bruce Ashfield

On 13-06-25 03:59 PM, Marc Ferland wrote:

Hi,

I have a linux-yocto_3.4.bbappend file in which I try to override the
KERNEL_FEATURES variable. I want it to be empty (I don't want the
netfilter stuff that's there by default).

So I've tried (in my bbappend):

KERNEL_FEATURES = ""

but somehow the netfilter.scc file still gets merged in.

What am I doing wrong?


Nothing. It's an artifact of the _appends that are present
in the linux-yocto recipe bbappends. You can clear it, but they'll
still append.

Those config fragments weren't optional when the recipes were
created, we've since evolved to the point where they are.

I squeezed in a change to linux-yocto_3.8 before the yocto 1.4
cutoff, and have changed linux-yocto_3.4 to match, and strangely,
was about to send a consolidated pull request that contains the
change.

You can either locally make the same change, and clear:

 KERNEL_EXTRA_FEATURES

or wait for my latest update.

Cheers,

Bruce



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



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


[yocto] variable override question

2013-06-25 Thread Marc Ferland
Hi,

I have a linux-yocto_3.4.bbappend file in which I try to override the
KERNEL_FEATURES variable. I want it to be empty (I don't want the
netfilter stuff that's there by default).

So I've tried (in my bbappend):

KERNEL_FEATURES = ""

but somehow the netfilter.scc file still gets merged in.

What am I doing wrong?

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


Re: [yocto] Fwd: Yocto Layers not getting recognized by bitbake

2013-06-25 Thread Saul Wold

On 06/25/2013 12:04 PM, varun bhatnagar wrote:

Thanks a ton for the reply Paul :)
But how to clone the meta-openembedded repository. I am not very clear
on the suggestion given by you.  :(
Can you please provide some steps on how to do this (cloning
open-embedded repository).


Paul is suggesting that you use the git tools to clone the repo.

you can get man pages for git, but the summary is:

git clone git://git.openembedded.org/meta-openembedded

in the poky directory, this will bring everything you need.

Sau!


//
Varun


On Tue, Jun 25, 2013 at 4:16 PM, Paul Eggleton
mailto:paul.eggle...@linux.intel.com>>
wrote:

On Sunday 23 June 2013 00:34:17 varun bhatnagar wrote:
 > I am trying to compile my code using yocto. For that I have
created two
 > layers: "meta-networking" and "meta-oe". I have added these
dependencies in
 > bblayer.conf too. But these are not getting build. Can anyone
please tell
 > me what should I do to make this work.
 >
 > //
 > Varun
 >
 > --
 > From: *Gary Thomas* mailto:g...@mlbassoc.com>>
 > Date: Mon, Jun 17, 2013 at 11:03 PM
 > To: yocto@yoctoproject.org 
 >
 >
 > More details are needed to be able to help.
 >
 > What do you mean "not getting built"?  Do you mean that if you
 > try to build recipe XYZ which is in one of those layers that it's
 > not being built?  Or perhaps you mean something else?
 >
 > What do you mean "created two layers: ..."?  Did you just extract
 > these from meta-openembedded?  or something else?
 >
 > > I am building one of my application using yocto by giving
bitbake -k
 > > core-image-minimal command but I am facing some errors as this
application
 > > requires two libraries
 > > *1) net-snmp*
 > > *2) fuse*
 > > *
 > >
 > > *
 > > I have one link where in they are asking to add these two
libraries in the
 > > form of layers and then execute bitbake -k core-image-minimal
command.
 > >
 > > I am pasting one screenshot below:
 > >
 > > As you can I have added two layers meta-networking (contains
net-snmp) and
 > > meta-oe(contains fuse). After this I added these layers in
 > > *build/conf/bblayer.conf.*
 > > *
 > > *
 > > *
 > >
 > > *
 > > After this I again executed bitbake -k core-image-minimal
command but I
 > > faced the same error as before... :(
 > > Is there anyway that these layers get recognized? Do I need to
execute
 > > some other command?
 >
 > Obviously, this is a recipe that you made.
 >
 > Does it show these dependencies?  e.g. a line like this in your
recipe file:
 > DEPENDS = "net-snmp fuse"
 > (or whatever the *packages* that you need are)
 >
 > Bitbake can't read your mind; it will only build the recipes you
ask and the
 > dependencies which are explicitly specified in that build chain.
 >
 > If you still have trouble, try sending your recipe (.bb file and
all other
 > components you might have), bblayers.conf, etc to the list
because we're not
 > mind readers either :-)
 >
 > > On Tue, Jun 18, 2013 at 2:32 AM, Sudhangathan B S
 > > mailto:sudhangat...@gmail.com>
 > > sudhangat...@gmail.com **>> wrote:
 > > Can you please paste your command and it's output here..!
If you don't
 > >
 > > mind..!! Or explain with equivalent clarity. It
 > >
 > > l will good if you can also put in your directory structure.
 > >
 > > --**---
 > > Sudhangathan BS
 > > Ph:(+91) 9731-905-205
 > > --**---
 > >
 > >
 > > On Mon, Jun 17, 2013 at 11:33 PM, varun bhatnagar <
 > >
 > > varun292...@gmail.com 
>**> wrote:
 > > Actually the package which I am building is having some
 > >
 > > dependencies on some libraries. So I provided those libraries
with the
 > > help of creating layers. I did not extract those from
meta-openembedded,
 > > instead, I manually created two layers and added them in
bblayer.conf file.

Rather than creating these layers from scratch (which I think is the
most
likely source of the problem) I'd suggest starting by cloning the
original
meta-openembedded repository and building your recipe with the
meta-networking
and meta-oe layers enabled in your bblayers.conf file.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre




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


___
yo

Re: [yocto] Fwd: Yocto Layers not getting recognized by bitbake

2013-06-25 Thread varun bhatnagar
Thanks a ton for the reply Paul :)
But how to clone the meta-openembedded repository. I am not very clear on
the suggestion given by you.  :(
Can you please provide some steps on how to do this (cloning open-embedded
repository).

//
Varun


On Tue, Jun 25, 2013 at 4:16 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Sunday 23 June 2013 00:34:17 varun bhatnagar wrote:
> > I am trying to compile my code using yocto. For that I have created two
> > layers: "meta-networking" and "meta-oe". I have added these dependencies
> in
> > bblayer.conf too. But these are not getting build. Can anyone please tell
> > me what should I do to make this work.
> >
> > //
> > Varun
> >
> > --
> > From: *Gary Thomas* 
> > Date: Mon, Jun 17, 2013 at 11:03 PM
> > To: yocto@yoctoproject.org
> >
> >
> > More details are needed to be able to help.
> >
> > What do you mean "not getting built"?  Do you mean that if you
> > try to build recipe XYZ which is in one of those layers that it's
> > not being built?  Or perhaps you mean something else?
> >
> > What do you mean "created two layers: ..."?  Did you just extract
> > these from meta-openembedded?  or something else?
> >
> > > I am building one of my application using yocto by giving bitbake -k
> > > core-image-minimal command but I am facing some errors as this
> application
> > > requires two libraries
> > > *1) net-snmp*
> > > *2) fuse*
> > > *
> > >
> > > *
> > > I have one link where in they are asking to add these two libraries in
> the
> > > form of layers and then execute bitbake -k core-image-minimal command.
> > >
> > > I am pasting one screenshot below:
> > >
> > > As you can I have added two layers meta-networking (contains net-snmp)
> and
> > > meta-oe(contains fuse). After this I added these layers in
> > > *build/conf/bblayer.conf.*
> > > *
> > > *
> > > *
> > >
> > > *
> > > After this I again executed bitbake -k core-image-minimal command but I
> > > faced the same error as before... :(
> > > Is there anyway that these layers get recognized? Do I need to execute
> > > some other command?
> >
> > Obviously, this is a recipe that you made.
> >
> > Does it show these dependencies?  e.g. a line like this in your recipe
> file:
> > DEPENDS = "net-snmp fuse"
> > (or whatever the *packages* that you need are)
> >
> > Bitbake can't read your mind; it will only build the recipes you ask and
> the
> > dependencies which are explicitly specified in that build chain.
> >
> > If you still have trouble, try sending your recipe (.bb file and all
> other
> > components you might have), bblayers.conf, etc to the list because we're
> not
> > mind readers either :-)
> >
> > > On Tue, Jun 18, 2013 at 2:32 AM, Sudhangathan B S
> > > 
> > > sudhangat...@gmail.com**>> wrote:
> > > Can you please paste your command and it's output here..! If you
> don't
> > >
> > > mind..!! Or explain with equivalent clarity. It
> > >
> > > l will good if you can also put in your directory structure.
> > >
> > > --**---
> > > Sudhangathan BS
> > > Ph:(+91) 9731-905-205
> > > --**---
> > >
> > >
> > > On Mon, Jun 17, 2013 at 11:33 PM, varun bhatnagar <
> > >
> > > varun292...@gmail.com **> wrote:
> > > Actually the package which I am building is having some
> > >
> > > dependencies on some libraries. So I provided those libraries with the
> > > help of creating layers. I did not extract those from
> meta-openembedded,
> > > instead, I manually created two layers and added them in bblayer.conf
> file.
>
> Rather than creating these layers from scratch (which I think is the most
> likely source of the problem) I'd suggest starting by cloning the original
> meta-openembedded repository and building your recipe with the
> meta-networking
> and meta-oe layers enabled in your bblayers.conf file.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Layer input

2013-06-25 Thread Jerrod Peach
Scott,

   - Distro Layer
   - I'm unclear on what  is.  Is that supposed to be ?
   ?  It probably shouldn't just be , should it?
   - Software Layer
  - Should COPYING.MIT just be COPYING to be more generically
  applicable?
  - conf/.conf should be just layer.conf, right?
   - BSP Layer
  - COPYING.MIT file again.
  - machine/.conf should probably be machine/.conf.
   You can probably drop the non-asterisk version, since an
asterisk implies,
  "There might be more stuff, there might not."
  - recipes-bsp/formfactor shouldn't also have another formfactor
  directory, should it?  Or is the "files" directory in 1.4 replaced with
  another formfactor-named directory?  Also,  should be
 again.
  - What's everything from recipes-core down?  I can buy recipes-kernel
  being in a bsp, but are any other directories really necessary?

Kind regards,

Jerrod


On Tue, Jun 25, 2013 at 8:35 AM, Rifenbark, Scott M <
scott.m.rifenb...@intel.com> wrote:

> Hi,
>
> This next illustration attempting to dive deeper in the YP Development
> Process takes the remaining left-side input from that figure in the Quick
> Start (metadata, Machine, and Policy).  Note that when the original figure
> was created that appears in the QS, the layer stuff had not yet been
> established.  This figure I am attaching is rough.  I am unsure as to the
> contents of these layers.  Right now it is detailed but with generic names.
>  The idea is that individual layers are preferred to do things such as
> provide software, configure policy, and configure machines.  I am including
> some notes at the bottom of the figure that would not be part of the figure
> but might help to get across what I am trying to accomplish here.
>
> Any suggestions and feedback is really appreciated.
>
> Thanks,
> Scott
>
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
>
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-intel][PATCH] meta-nuc: don't install lms8 as NUC doesn't support AMT

2013-06-25 Thread Ross Burton
The NUC doesn't support Active Management Technology, so don't install lms8 as
part of the machine recommendations.

Signed-off-by: Ross Burton 
---
 meta-nuc/conf/machine/nuc.conf |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-nuc/conf/machine/nuc.conf b/meta-nuc/conf/machine/nuc.conf
index 1404f72..f6ae404 100644
--- a/meta-nuc/conf/machine/nuc.conf
+++ b/meta-nuc/conf/machine/nuc.conf
@@ -19,7 +19,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
"
 
-MACHINE_EXTRA_RRECOMMENDS += "lms8 linux-firmware-iwlwifi-6000g2b-6"
+MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2b-6"
 
 # disable the serial port configuration
 SERIAL_CONSOLE = ""
-- 
1.7.10.4

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


[yocto] [meta-intel][PATCH] lms8: handle different host setups

2013-06-25 Thread Ross Burton
The configure script looks at the *host* environment to decide where to install
the init script, so it's location at packaging time can change.

Signed-off-by: Ross Burton 
---
 common/recipes-bsp/amt/lms8_8.0.0-7.bb |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/common/recipes-bsp/amt/lms8_8.0.0-7.bb 
b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
index fbb4e45..65c413a 100644
--- a/common/recipes-bsp/amt/lms8_8.0.0-7.bb
+++ b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
@@ -26,7 +26,13 @@ INITSCRIPT_PARAMS = "defaults"
 do_install_append () {
mv ${D}/${sbindir}/lms ${D}/${sbindir}/lms8
install -d ${D}${sysconfdir}/init.d
-   mv ${D}${sysconfdir}/rc.d/init.d/lms 
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
+   # The configure script looks at the host to decide where to put init
+   # scripts, so move it at the same time as renaming it.
+   if test -f ${D}${sysconfdir}/rc.d/init.d/lms ; then
+   mv ${D}${sysconfdir}/rc.d/init.d/lms 
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
+   else
+   mv ${D}${sysconfdir}/init.d/lms 
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
+   fi
sed -i 's/^NAME=lms/NAME=lms8/' 
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
rmdir ${D}${datadir} || :
 }
-- 
1.7.10.4

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


[yocto] [meta-intel][PATCH] intel-gpu-tools: add new package

2013-06-25 Thread Ross Burton
This package contains numerous useful tools for working with Intel GPUs.  Add a
patch to install intel_panel_fitter as it's genuinely useful and not just a
debugging tool.

Signed-off-by: Ross Burton 
---
 .../intel-gpu-tools/files/install-fitter.patch |   26 
 .../intel-gpu-tools/intel-gpu-tools_1.3.bb |   15 +++
 2 files changed, 41 insertions(+)
 create mode 100644 
common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
 create mode 100644 
common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb

diff --git a/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch 
b/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
new file mode 100644
index 000..2a344c5
--- /dev/null
+++ b/common/recipes-graphics/intel-gpu-tools/files/install-fitter.patch
@@ -0,0 +1,26 @@
+The panel_fitter is genuinely useful but not installed, so install it.
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton 
+
+Index: tools/Makefile.am
+===
+--- a/tools.orig/Makefile.am   2012-08-21 08:30:29.0 +0100
 b/tools/Makefile.am2013-06-25 16:52:34.220504579 +0100
+@@ -17,13 +17,13 @@
+   intel_forcewaked\
+   intel_dpio_read \
+   intel_dpio_write\
+-  intel_l3_parity
++  intel_l3_parity \
++  intel_panel_fitter
+ 
+ noinst_PROGRAMS = \
+   intel_dump_decode   \
+   intel_infoframes\
+-  intel_lid   \
+-  intel_panel_fitter
++  intel_lid
+ 
+ dist_bin_SCRIPTS = intel_gpu_abrt
+ 
diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb 
b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
new file mode 100644
index 000..893c418
--- /dev/null
+++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.3.bb
@@ -0,0 +1,15 @@
+require ${COREBASE}/meta/recipes-graphics/xorg-app/xorg-app-common.inc
+
+SUMMARY = "Intel GPU tools"
+DESCRIPTION = "Variety of small tools for testing intel graphics."
+
+SRC_URI += "file://install-fitter.patch"
+
+SRC_URI[md5sum] = "67facd6241e26e2c68614728e3a932e9"
+SRC_URI[sha256sum] = 
"51d22fdb3d415a1b3b7d0a172c1bb24dec6f16116e80a9ce49873f44527f20a0"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=0918806acfedc3e8c0488f2dd61616dd"
+
+DEPENDS += "libdrm libpciaccess cairo udev glib-2.0"
+
+EXTRA_OECONF = "--disable-nouveau --disable-shader-debugger"
-- 
1.7.10.4

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


Re: [yocto] The simplest possible recipe

2013-06-25 Thread Sean Liming
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Paul D. DeRocco
> Sent: Monday, June 24, 2013 5:18 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] The simplest possible recipe
> 
> That would be to copy a single file, provided in the files subdirectory of
the
> recipe, into a particular place in the target tree. Is there any bbclass
that
> automates this? Or do I just write a recipe with a do_install function
that
> executes the "install" command?
> 
> My only guide is 5.3.1 in the Development Manual, which performs a simple
> compilation, but I'm very hazy about how recipes are interpreted, so I'd
like it
> if someone can tell me if I've gotten the following stuff right or not.
> 
> SRC_URI tells bitbake what files must be gotten from somewhere and copied
> somewhere else in order to carry out the build process. And according to
the
> Ref Manual, the "file://" prefix tells it to fetch a local file by
searching some
> directories including the "files" subdirectory next to the .bb file.
> And apparently, there is a "subdir" option (whose syntax is unexplained)
> which may be used to tell bitbake to put it somewhere specific relative to
> ${WORKDIR}.
> 
> Is the default value of the "subdir" option the S variable? Is that the
purpose
> of S, to tell bitbake where to put things that it fetches? The Ref Manual
says
> that S defaults to ${WORKDIR}/${PN}/${PV}, but then the sample compile
> recipe sets S to ${WORKDIR}. Is that what one does when one doesn't need
> to have a bunch of versioned subdirectories under ${WORKDIR}? (I'm not
> sure why one would ever want that, or why that would be the default.)
> 
> So if I want to install a file somewhere, do I even need a do_install
task, or
> can I just set S equal to the desired target location, like
"${etcdir}/foo" and be
> done with it? Or is that a no-no, and should I always use do_install?
> 
> --
> 
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


>From my book, I demonstrated two ways to create a receipt with and without
Autotools. Without Autotools:

DESCRIPTION = "Hello World C file recipe"
SECTION = "base"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
file://${WORKDIR}/COPYRIGHT;md5=349c872e0066155e1818b786938876a4"
PR = "r0"

SRC_URI = "file://helloyp.c \
  file://COPYRIGHT \ "

do_compile () {
 ${CC} ${WORKDIR}/helloyp.c -o ${WORKDIR}/helloyp
}

do_install () {

   install -d ${D}${bindir}
   install -m 0755 ${WORKDIR}/helloyp ${D}${bindir}/
}


The following is the recipe is with autotools:


DESCRIPTION = "Hello World Application with Autotools"
SECTION = "examples"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://${WORKDIR}/COPYING;md5=92bf9743cf0f1e6d9306478e118e432f"

PR = "r0"

SRC_URI = "file:///home/sean/workspace/helloyp-${PV}.tar.gz"
inherit autotools gettext

SRC_URI[md5sum] = "934bd36a4a3b1e7912fdff3ae764c7b6"
SRC_URI[sha256sum] =
"09810190e0cf9ebf141ad780b994fce8198098fbeca418ec51df59eb51747182"


The application was placed in the /usr/bin folder. From there it could be
moved or link to someplace else.


Regards,

Sean Liming
Owner

Tel: 714-970-7523 / Cell: 858-774-3176


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


[yocto] [PATCHv3 3/8] plugins/sdk.ide: Move project specific util methods

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

Move project specific methods to the new util class to allow public
usage of theses methods.

Signed-off-by: Timo Mueller 
---
 .../preferences/YoctoSDKProjectPropertyPage.java   | 121 ++---
 .../sdk/ide/utils/ProjectPreferenceUtils.java  | 102 +
 2 files changed, 109 insertions(+), 114 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
index f075c5b..1f82fe1 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
@@ -13,12 +13,8 @@
 package org.yocto.sdk.ide.preferences;
 
 import org.eclipse.core.resources.IProject;
-import org.eclipse.core.resources.ProjectScope;
 import org.eclipse.core.runtime.IAdaptable;
-import org.eclipse.core.runtime.preferences.IEclipsePreferences;
-import org.eclipse.core.runtime.preferences.IScopeContext;
 import org.eclipse.jface.dialogs.Dialog;
-import org.eclipse.jface.preference.IPreferenceStore;
 import org.eclipse.swt.SWT;
 import org.eclipse.swt.layout.GridLayout;
 import org.eclipse.swt.widgets.Composite;
@@ -27,19 +23,17 @@ import org.eclipse.swt.widgets.Event;
 import org.eclipse.swt.widgets.Listener;
 import org.eclipse.ui.IWorkbenchPropertyPage;
 import org.eclipse.ui.dialogs.PropertyPage;
-import org.osgi.service.prefs.BackingStoreException;
 import org.yocto.sdk.ide.YoctoProfileElement;
 import org.yocto.sdk.ide.YoctoProfileSetting;
 import org.yocto.sdk.ide.YoctoProjectSpecificSetting;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
 import org.yocto.sdk.ide.YoctoSDKMessages;
-import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
-import org.yocto.sdk.ide.utils.YoctoSDKUtils;
-import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
 import org.yocto.sdk.ide.YoctoSDKPlugin;
 import org.yocto.sdk.ide.YoctoUIElement;
 import org.yocto.sdk.ide.YoctoUISetting;
+import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
 
 public class YoctoSDKProjectPropertyPage extends PropertyPage implements
IWorkbenchPropertyPage {
@@ -79,10 +73,10 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
 
yoctoProfileSetting = new YoctoProfileSetting(
new 
YoctoProfileElement(globalProfileElement.getProfilesAsString(), 
selectedProfile), this, false);
-   boolean useProjectSpecificSetting = 
getUseProjectSpecificOptionFromProjectPreferences(project);
+   boolean useProjectSpecificSetting = 
ProjectPreferenceUtils.getUseProjectSpecificOptionFromProjectPreferences(project);
 
if (useProjectSpecificSetting) {
-   yoctoUISetting = new 
YoctoUISetting(getElemFromProjectPreferences(project));
+   yoctoUISetting = new 
YoctoUISetting(ProjectPreferenceUtils.getElemFromProjectPreferences(project));
} else {
yoctoUISetting = new 
YoctoUISetting(YoctoSDKUtils.getElemFromStore(YoctoSDKPlugin.getProfilePreferenceStore(selectedProfile)));
}
@@ -160,11 +154,11 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
return false;
}
 
-   
saveUseProjectSpecificOptionToProjectPreferences(project, true);
+   
ProjectPreferenceUtils.saveUseProjectSpecificOptionToProjectPreferences(project,
 true);

ProjectPreferenceUtils.saveProfilesToProjectPreferences(yoctoProfileSetting.getCurrentInput(),
 project);
-   
saveElemToProjectPreferences(yoctoUISetting.getCurrentInput(), project);
+   
ProjectPreferenceUtils.saveElemToProjectPreferences(yoctoUISetting.getCurrentInput(),
 project);
} else {
-   
saveUseProjectSpecificOptionToProjectPreferences(project, false);
+   
ProjectPreferenceUtils.saveUseProjectSpecificOptionToProjectPreferences(project,
 false);

ProjectPreferenceUtils.saveProfilesToProjectPreferences(yoctoProfileSetting.getCurrentInput(),
 project);
}
 
@@ -173,107 +167,6 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
return super.performOk();
}
 
-   private void saveUseProjectSpecificOptionToProjectPreferences(IProject 
project, boolean useProjectSpecificSetting) {
-   IScopeContext projectScope = new ProjectScope(project);
-   IEclipsePreferences projectNode = 
projectScope.getNode(YoctoSDKUtilsConstants.PROJECT_SCOPE);
-   if (

[yocto] [PATCHv3 8/8] TESTING: add tracing for radio menu

2013-06-25 Thread Timo Mueller
From: Timo Mueller 


Signed-off-by: Timo Mueller 
---
 plugins/org.yocto.sdk.ide/.options|  2 ++
 .../org/yocto/sdk/ide/TargetProfileContributionItem.java  | 15 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 plugins/org.yocto.sdk.ide/.options

diff --git a/plugins/org.yocto.sdk.ide/.options 
b/plugins/org.yocto.sdk.ide/.options
new file mode 100644
index 000..30ba9c2
--- /dev/null
+++ b/plugins/org.yocto.sdk.ide/.options
@@ -0,0 +1,2 @@
+org.yocto.sdk.ide/debug=false
+org.yocto.sdk.ide/debug/profileMenu=true
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/TargetProfileContributionItem.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/TargetProfileContributionItem.java
index 95d8229..755005d 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/TargetProfileContributionItem.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/TargetProfileContributionItem.java
@@ -21,6 +21,7 @@ import org.eclipse.core.commands.ExecutionException;
 import org.eclipse.core.resources.IProject;
 import org.eclipse.core.resources.IResource;
 import org.eclipse.core.runtime.IAdaptable;
+import org.eclipse.core.runtime.Platform;
 import org.eclipse.jface.action.IContributionItem;
 import org.eclipse.jface.viewers.ISelection;
 import org.eclipse.jface.viewers.ITreeSelection;
@@ -38,6 +39,9 @@ import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
 import org.yocto.sdk.ide.utils.YoctoSDKUtils;
 
 public class TargetProfileContributionItem extends CompoundContributionItem 
implements IWorkbenchContribution {
+   private static final boolean DEBUG = 
YoctoSDKPlugin.getDefault().isDebugging() &&
+   
"true".equalsIgnoreCase(Platform.getDebugOption("org.yocto.sdk.ide/debug/profileMenu"));
+
private IServiceLocator serviceLocator;
 
public TargetProfileContributionItem() {}
@@ -114,13 +118,22 @@ public class TargetProfileContributionItem extends 
CompoundContributionItem impl
try {
if 
(ProjectPreferenceUtils.getUseProjectSpecificOption(project)) {
HandlerUtil.updateRadioState(command, 
ProfileSwitchHandler.PROJECT_SPECIFIC_PARAMETER);
+
+   if (DEBUG)
+   System.out.println("Enabling project 
specific menu item");
+
return;
}
 
String selectedProfile = 
ProjectPreferenceUtils.getProfiles(project).getSelectedProfile();
HandlerUtil.updateRadioState(command, selectedProfile);
+   if (DEBUG)
+   System.out.println("Enabling menu item of 
profile: " + selectedProfile);
} catch (ExecutionException e) {
-   // ignore
+   if (DEBUG) {
+   System.out.println("An error occurred when 
trying to enable a menu item");
+   e.printStackTrace();
+   }
}
}
 }
-- 
1.8.1.4

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


[yocto] [PATCHv3 7/8] plugins/sdk.ide: Add profile switch menu to the project menu

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

If a project with a yocto nature is selected, the project menu will
show a target profile menu which allows the user to switch the used
target profile of the project.

Signed-off-by: Timo Mueller 
---
 plugins/org.yocto.sdk.ide/plugin.xml | 25 +
 1 file changed, 25 insertions(+)

diff --git a/plugins/org.yocto.sdk.ide/plugin.xml 
b/plugins/org.yocto.sdk.ide/plugin.xml
index aaa0a35..c082c3a 100644
--- a/plugins/org.yocto.sdk.ide/plugin.xml
+++ b/plugins/org.yocto.sdk.ide/plugin.xml
@@ -251,6 +251,15 @@
  point="org.eclipse.ui.menus">
   
+ 
+ 
+  
+  
  
@@ -284,6 +293,22 @@
   
   
+ 
+ 
+ 
+ 
+ 
+ 
+  
+  
  https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCHv3 2/8] plugins/sdk.ide: Extract project specific util methods

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

Project specific util methods are moved to a separate util class. This
way the general util class will get more concise and other project
specific methods can be move to this new util class later.

Signed-off-by: Timo Mueller 
---
 .../natures/YoctoSDKAutotoolsProjectNature.java|   3 +-
 .../ide/preferences/YoctoSDKPreferencePage.java|  11 +-
 .../preferences/YoctoSDKProjectPropertyPage.java   |  13 +-
 .../sdk/ide/utils/ProjectPreferenceUtils.java  | 138 +
 .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 118 --
 .../ide/wizard/NewYoctoProjectTemplateProcess.java |   3 +-
 6 files changed, 155 insertions(+), 131 deletions(-)
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/ProjectPreferenceUtils.java

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKAutotoolsProjectNature.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKAutotoolsProjectNature.java
index fb53c53..ce80d77 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKAutotoolsProjectNature.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKAutotoolsProjectNature.java
@@ -18,6 +18,7 @@ import 
org.eclipse.cdt.managedbuilder.core.ManagedBuildManager;
 import org.eclipse.core.resources.IProject;
 import org.yocto.sdk.ide.YoctoSDKPlugin;
 import org.yocto.sdk.ide.YoctoUIElement;
+import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
 import org.yocto.sdk.ide.utils.YoctoSDKUtils;
 
 public class YoctoSDKAutotoolsProjectNature extends YoctoSDKProjectNature {
@@ -35,7 +36,7 @@ public class YoctoSDKAutotoolsProjectNature extends 
YoctoSDKProjectNature {
public static void configureAutotoolsOptions(IProject project) {
IManagedBuildInfo info = 
ManagedBuildManager.getBuildInfo(project);
IConfiguration icfg = info.getDefaultConfiguration();
-   YoctoUIElement elem = 
YoctoSDKUtils.getElemFromProjectEnv(project);
+   YoctoUIElement elem = 
ProjectPreferenceUtils.getElemFromProjectEnv(project);
String sysroot_str = elem.getStrSysrootLoc();
String id = icfg.getId();
String CFLAGS_str = YoctoSDKUtils.getEnvValue(project, 
"CFLAGS");
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
index 211c4f9..e8123e2 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
@@ -34,6 +34,7 @@ import org.yocto.sdk.ide.YoctoProfileSetting;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
 import org.yocto.sdk.ide.natures.YoctoSDKProjectNature;
+import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
 import org.yocto.sdk.ide.utils.YoctoSDKUtils;
 import org.yocto.sdk.ide.YoctoSDKMessages;
 import org.yocto.sdk.ide.YoctoSDKPlugin;
@@ -240,10 +241,10 @@ public class YoctoSDKPreferencePage extends 
PreferencePage implements IWorkbench
 
for (IProject project : yoctoProjects)
{
-   
YoctoSDKUtils.saveProfilesToProjectPreferences(profileElement, project);
+   
ProjectPreferenceUtils.saveProfilesToProjectPreferences(profileElement, 
project);
YoctoUIElement elem = YoctoSDKUtils.getElemFromStore(


YoctoSDKPlugin.getProfilePreferenceStore(PreferenceConstants.STANDARD_PROFILE_NAME));
-   YoctoSDKUtils.saveElemToProjectEnv(elem, project);
+   ProjectPreferenceUtils.saveElemToProjectEnv(elem, 
project);
}
}
 
@@ -254,14 +255,14 @@ public class YoctoSDKPreferencePage extends 
PreferencePage implements IWorkbench
 
for (IProject project : yoctoProjects)
{
-   
YoctoSDKUtils.saveProfilesToProjectPreferences(profileElement, project);
+   
ProjectPreferenceUtils.saveProfilesToProjectPreferences(profileElement, 
project);
}
}
 
private void updateProjects(HashSet yoctoProjects, 
YoctoUIElement elem) {
for (IProject project : yoctoProjects)
{
-   YoctoSDKUtils.saveElemToProjectEnv(elem, project);
+   ProjectPreferenceUtils.saveElemToProjectEnv(elem, 
project);
}
}
 
@@ -295,7 +296,7 @@ public class YoctoSDKPreferencePage extends PreferencePage 
implements IWorkbench
 
private boolean projectUsesProfile(IProject project, String profile)
{
-   YoctoProfileElement profileEleme

[yocto] [PATCHv3 6/8] plugins/sdk.ide: Add profile switch menu to the toolbar

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

If a project with a yocto nature is selected, the toolbar will show a
target profile menu which allows the user to switch the used target
profile of the project.

The content of this menu is dynamically created using the list of
globally defined target profiles. Additionally it will also contain
the project specific profile.

If the project specific profile is not yet defined for the selected
project, the button will be greyed out.

Signed-off-by: Timo Mueller 
---
 .../OSGI-INF/l10n/bundle.properties|   1 +
 plugins/org.yocto.sdk.ide/plugin.xml   |  57 +-
 .../sdk/ide/ProjectSpecificContributionItem.java   |  69 +++
 .../sdk/ide/TargetProfileContributionItem.java | 126 +
 .../org/yocto/sdk/ide/YoctoSDKMessages.properties  |   1 +
 .../sdk/ide/actions/ProfileSwitchHandler.java  |  26 -
 6 files changed, 278 insertions(+), 2 deletions(-)
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/ProjectSpecificContributionItem.java
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/TargetProfileContributionItem.java

diff --git a/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties 
b/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
index 1191af6..2031154 100644
--- a/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
@@ -7,6 +7,7 @@ command.name = ReconfigureYoctoProject
 command.label.0 = Change Yocto Project Settings
 command.mnemonic = C
 command.targetProfileSwitch.name = Change Target Profile
+command.targetProfileSwitch.label = Target Profiles
 command.targetProfileSwitch.description = Changes the target profile of a 
selected project
 command.targetProfileSwitch.parameter.name = Selected Target Profile
 projectType.name.0 = Yocto Project ADT Autotools Project
diff --git a/plugins/org.yocto.sdk.ide/plugin.xml 
b/plugins/org.yocto.sdk.ide/plugin.xml
index 62f1297..aaa0a35 100644
--- a/plugins/org.yocto.sdk.ide/plugin.xml
+++ b/plugins/org.yocto.sdk.ide/plugin.xml
@@ -81,6 +81,10 @@
 id="org.yocto.sdk.ide.command.reconfigYocto"
 name="%command.name">
   
+  
+  


@@ -243,5 +247,56 @@
  
   

-
+   
+  
+ 
+
+   
+  
+ 
+ 
+ 
+
+   
+   
+
+ 
+  
+   
+
+ 
+  
+  
+ 
+ 
+ 
+ 
+ 
+ 
+  
+   
 
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/ProjectSpecificContributionItem.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/ProjectSpecificContributionItem.java
new file mode 100644
index 000..c29d278
--- /dev/null
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/ProjectSpecificContributionItem.java
@@ -0,0 +1,69 @@
+/***
+ * Copyright (c) 2013 BMW Car IT GmbH.
+ * 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:
+ * BMW Car IT - initial implementation
+ 
***/
+
+package org.yocto.sdk.ide;
+
+import java.util.ArrayList;
+
+import org.eclipse.core.resources.IProject;
+import org.eclipse.jface.action.IContributionItem;
+import org.eclipse.ui.menus.CommandContributionItem;
+import org.eclipse.ui.menus.CommandContributionItemParameter;
+import org.eclipse.ui.services.IServiceLocator;
+import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
+import org.yocto.sdk.ide.actions.ProfileSwitchHandler;
+import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
+
+public class ProjectSpecificContributionItem extends 
TargetProfileContributionItem {
+   private static final String PROJECT_SPECIFIC_PROFILE =
+   "Preferences.Profile.ProjectSpecific.Profile.Label"; 
//$NON-NLS-N$
+   private static final String DISABLED_COMMAND_ID = 
"org.yocto.sdk.ide.command.disabled"; //$NON-NLS-N$
+
+   private IServiceLocator serviceLocator;
+
+   public ProjectSpecificContributionItem() {}
+
+   public ProjectSpecificContributionItem(String id) {
+   super(id);
+   }
+
+   @Override
+   protected IContributionItem[] getContributionItems() {
+   ArrayList items = new 
ArrayList();
+
+   IProject project = getSelectedProject(serviceLocator);
+   YoctoUIElement yoctoUIElement = 
ProjectPreferenceUtils.getElem(project

[yocto] [PATCHv3 5/8] plugins/sdk.ide: Add command to switch the target profile

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

The command can be used in a radio group to switch the target profile
of a selected project.

Radio items should call this command handing over the name of the
target profile as the command's parameter.

Signed-off-by: Timo Mueller 
---
 .../OSGI-INF/l10n/bundle.properties|   3 +
 plugins/org.yocto.sdk.ide/plugin.xml   |  18 
 .../org/yocto/sdk/ide/YoctoSDKMessages.properties  |   3 +
 .../sdk/ide/actions/ProfileSwitchHandler.java  | 110 +
 4 files changed, 134 insertions(+)
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/ProfileSwitchHandler.java

diff --git a/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties 
b/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
index 48eb653..1191af6 100644
--- a/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
@@ -6,6 +6,9 @@ extension.name.2 = YoctoSDKCMakeNature
 command.name = ReconfigureYoctoProject
 command.label.0 = Change Yocto Project Settings
 command.mnemonic = C
+command.targetProfileSwitch.name = Change Target Profile
+command.targetProfileSwitch.description = Changes the target profile of a 
selected project
+command.targetProfileSwitch.parameter.name = Selected Target Profile
 projectType.name.0 = Yocto Project ADT Autotools Project
 projectProperties.label.0 = Yocto Project Settings
 Bundle-Vendor = yoctoproject.org
diff --git a/plugins/org.yocto.sdk.ide/plugin.xml 
b/plugins/org.yocto.sdk.ide/plugin.xml
index 7ea55c7..62f1297 100644
--- a/plugins/org.yocto.sdk.ide/plugin.xml
+++ b/plugins/org.yocto.sdk.ide/plugin.xml
@@ -225,5 +225,23 @@
  
   

+   
+  
+ 
+ 
+ 
+ 
+  
+   
 
 
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties
index 4ff1574..a953d6f 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoSDKMessages.properties
@@ -89,6 +89,9 @@ Preferences.Profile.Standard.Modification.Message = Standard 
cross development p
 Preferences.Profile.ProjectSpecific.Title = Use project specific settings
 Preferences.Profile.ProjectSpecific.Group.Title = Project specific settings:
 
+Preferences.Profile.ProjectSpecific.Error.Title = Could not change to project 
specific target profile
+Preferences.Profile.ProjectSpecific.Error.Message = The project specific 
target profile is not defined for the project "{0}".\nYou can define it in the 
project's property page.
+
 Console.SDK.Name = Yocto Project Console
 
 LaunchConfig.Type.Name = 
org.eclipse.ui.externaltools.ProgramLaunchConfigurationType
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/ProfileSwitchHandler.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/ProfileSwitchHandler.java
new file mode 100644
index 000..e12597e
--- /dev/null
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/ProfileSwitchHandler.java
@@ -0,0 +1,110 @@
+/***
+ * Copyright (c) 2013 BMW Car IT GmbH.
+ * 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:
+ * BMW Car IT - initial implementation
+ 
***/
+package org.yocto.sdk.ide.actions;
+
+import org.eclipse.cdt.core.model.ICElement;
+import org.eclipse.cdt.core.model.ICProject;
+import org.eclipse.core.commands.AbstractHandler;
+import org.eclipse.core.commands.ExecutionEvent;
+import org.eclipse.core.commands.ExecutionException;
+import org.eclipse.core.resources.IProject;
+import org.eclipse.core.resources.IResource;
+import org.eclipse.core.runtime.IAdaptable;
+import org.eclipse.core.runtime.Status;
+import org.eclipse.jface.dialogs.ErrorDialog;
+import org.eclipse.jface.preference.IPreferenceStore;
+import org.eclipse.jface.viewers.ISelection;
+import org.eclipse.jface.viewers.ITreeSelection;
+import org.eclipse.swt.widgets.Display;
+import org.eclipse.ui.handlers.HandlerUtil;
+import org.eclipse.ui.handlers.RadioState;
+import org.yocto.sdk.ide.YoctoProfileElement;
+import org.yocto.sdk.ide.YoctoSDKChecker;
+import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
+import org.yocto.sdk.ide.YoctoSDKMessages;
+import org.yocto.sdk.ide.YoctoSDKPlugin;
+import org.yocto.sdk.ide.YoctoUIElement;
+import org.yocto.sdk.ide.utils.ProjectPreferenceUtils;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+
+public class ProfileSwitchHandler extends AbstractHandler {
+   private static final String PROJECT_SPECIFIC_ERRO

[yocto] [PATCHv3 0/8][eclipse-poky] Add target profile quick switch

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

Hi,

in conclusion to the previous discussion, we've agreed that the quick
switch menu will enable the user to select only configured profiles.
An unconfigured project specific profile will be shown as a greyed out
option in the menu.

There also has been a bug where the projects specific settings and one
profile could be marked as selected at the same time. I could only
reproduce by naming the target profile "project-specific" which
collides with the radioParamter used for the menu. This case is
resolved in this patch set. I've additionally merged the two places
where the state of the menu was set so have one consistent place.

In any case, I've added one patch marked as TESTING to enable tracing
in the relevant components. In case the problem prevails, please
enable the tracing for th org.yocto.sdk.ide plugin and send me the
output.

Changes in v3:
- Only grey out project specific profile if not configured.
- Fix Bug where multiple menu item could be selected at the same time

Changes in v2:
Handle error when project specific profile is not configure more
gracefully. Instead of showing an error message the button is now
greyed out.

Patches 01..07 contain the implementation with the greyed out menu
button.

After playing around with the two options discussed in the first patch
series, I started to prefer inserting a different button in the menu
allowing the user to quickly navigate to the project preferences
instead of just greying it out. I've added this in the last patch of
the series, so you can compare yourself.

>From original cover letter

if a user wants to change the used target profile of a project he
currently has to open the project preferences. This can be tedious if
he has to switch the profile often.

This is a small addition which allows the user to quickly switch the
used target profile of a project. Instead of having to open the
project preferences the user can select the project in the navigator
and then choose the desired target profile from a drop-down menu in
the toolbar or from the project menu.


01: Small i18n fix
02..04: Refactoring the project specific utils
05..06: Introduce the target profile toolbar switch
07: Adds the target profile switch to the project menu
08: TESTING: Enalbe tracing to pin down the multi-select problem

Best regards,
Timo

Timo Mueller (8):
  plugins/sdk.ide: Use an internationalized dialog title
  plugins/sdk.ide: Extract project specific util methods
  plugins/sdk.ide: Move project specific util methods
  plugins/sdk.ide: Remove project context from method names
  plugins/sdk.ide: Add command to switch the target profile
  plugins/sdk.ide: Add profile switch menu to the toolbar
  plugins/sdk.ide: Add profile switch menu to the project menu
  TESTING: add tracing for radio menu

 plugins/org.yocto.sdk.ide/.options |   2 +
 .../OSGI-INF/l10n/bundle.properties|   4 +
 plugins/org.yocto.sdk.ide/plugin.xml   | 100 -
 .../sdk/ide/ProjectSpecificContributionItem.java   |  69 ++
 .../sdk/ide/TargetProfileContributionItem.java | 139 
 .../org/yocto/sdk/ide/YoctoSDKMessages.properties  |   4 +
 .../src/org/yocto/sdk/ide/YoctoUISetting.java  |   3 +-
 .../sdk/ide/actions/ProfileSwitchHandler.java  | 134 
 .../natures/YoctoSDKAutotoolsProjectNature.java|   3 +-
 .../ide/preferences/YoctoSDKPreferencePage.java|  11 +-
 .../preferences/YoctoSDKProjectPropertyPage.java   | 130 ++-
 .../sdk/ide/utils/ProjectPreferenceUtils.java  | 240 +
 .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java | 118 --
 .../ide/wizard/NewYoctoProjectTemplateProcess.java |   3 +-
 14 files changed, 714 insertions(+), 246 deletions(-)
 create mode 100644 plugins/org.yocto.sdk.ide/.options
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/ProjectSpecificContributionItem.java
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/TargetProfileContributionItem.java
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/ProfileSwitchHandler.java
 create mode 100644 
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/utils/ProjectPreferenceUtils.java

-- 
1.8.1.4

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


[yocto] [PATCHv3 4/8] plugins/sdk.ide: Remove project context from method names

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

Through the context of the ProjectPreferenceUtil class we can infer
that all methods act on project preferences. Having this context
information duplicated in the method name is not needed anymore and
can be removed to get a cleaner API.

Signed-off-by: Timo Mueller 
---
 .../sdk/ide/preferences/YoctoSDKPreferencePage.java  |  6 +++---
 .../sdk/ide/preferences/YoctoSDKProjectPropertyPage.java | 16 
 .../org/yocto/sdk/ide/utils/ProjectPreferenceUtils.java  | 12 ++--
 .../sdk/ide/wizard/NewYoctoProjectTemplateProcess.java   |  2 +-
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
index e8123e2..4e6ca2a 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKPreferencePage.java
@@ -241,7 +241,7 @@ public class YoctoSDKPreferencePage extends PreferencePage 
implements IWorkbench
 
for (IProject project : yoctoProjects)
{
-   
ProjectPreferenceUtils.saveProfilesToProjectPreferences(profileElement, 
project);
+   ProjectPreferenceUtils.saveProfiles(profileElement, 
project);
YoctoUIElement elem = YoctoSDKUtils.getElemFromStore(


YoctoSDKPlugin.getProfilePreferenceStore(PreferenceConstants.STANDARD_PROFILE_NAME));
ProjectPreferenceUtils.saveElemToProjectEnv(elem, 
project);
@@ -255,7 +255,7 @@ public class YoctoSDKPreferencePage extends PreferencePage 
implements IWorkbench
 
for (IProject project : yoctoProjects)
{
-   
ProjectPreferenceUtils.saveProfilesToProjectPreferences(profileElement, 
project);
+   ProjectPreferenceUtils.saveProfiles(profileElement, 
project);
}
}
 
@@ -296,7 +296,7 @@ public class YoctoSDKPreferencePage extends PreferencePage 
implements IWorkbench
 
private boolean projectUsesProfile(IProject project, String profile)
{
-   YoctoProfileElement profileElement = 
ProjectPreferenceUtils.getProfilesFromProjectPreferences(project);
+   YoctoProfileElement profileElement = 
ProjectPreferenceUtils.getProfiles(project);
 
if (!profileElement.getSelectedProfile().equals(profile)) {
return false;
diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
index 1f82fe1..f6026ee 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
@@ -64,7 +64,7 @@ public class YoctoSDKProjectPropertyPage extends PropertyPage 
implements
IProject project = getProject();
 
YoctoProfileElement globalProfileElement= 
YoctoSDKUtils.getProfilesFromDefaultStore();
-   YoctoProfileElement profileElement = 
ProjectPreferenceUtils.getProfilesFromProjectPreferences(project);
+   YoctoProfileElement profileElement = 
ProjectPreferenceUtils.getProfiles(project);
 
String selectedProfile = profileElement.getSelectedProfile();
if (!globalProfileElement.contains(selectedProfile)) {
@@ -73,10 +73,10 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
 
yoctoProfileSetting = new YoctoProfileSetting(
new 
YoctoProfileElement(globalProfileElement.getProfilesAsString(), 
selectedProfile), this, false);
-   boolean useProjectSpecificSetting = 
ProjectPreferenceUtils.getUseProjectSpecificOptionFromProjectPreferences(project);
+   boolean useProjectSpecificSetting = 
ProjectPreferenceUtils.getUseProjectSpecificOption(project);
 
if (useProjectSpecificSetting) {
-   yoctoUISetting = new 
YoctoUISetting(ProjectPreferenceUtils.getElemFromProjectPreferences(project));
+   yoctoUISetting = new 
YoctoUISetting(ProjectPreferenceUtils.getElem(project));
} else {
yoctoUISetting = new 
YoctoUISetting(YoctoSDKUtils.getElemFromStore(YoctoSDKPlugin.getProfilePreferenceStore(selectedProfile)));
}
@@ -154,12 +154,12 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
return false;
}
 
-   
ProjectPreferenceUtils.saveUseProjectSpeci

[yocto] [PATCHv3 1/8] plugins/sdk.ide: Use an internationalized dialog title

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

Signed-off-by: Timo Mueller 
---
 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoUISetting.java | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoUISetting.java 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoUISetting.java
index e5a7897..d192538 100644
--- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoUISetting.java
+++ b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoUISetting.java
@@ -42,7 +42,6 @@ import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
 import org.yocto.sdk.ide.preferences.PreferenceConstants;
 
 public class YoctoUISetting {
-
private static final String ENV_SCRIPT_FILE_PREFIX = 
"environment-setup-";
 
private SelectionListener fSelectionListener;
@@ -375,7 +374,7 @@ public class YoctoUISetting {
if ((result != SDKCheckResults.SDK_PASS) && showErrorDialog) {
Display display = Display.getCurrent();
ErrorDialog.openError(display.getActiveShell(),
-   "Yocto 
Project Configuration Error",
+   
YoctoSDKChecker.SDKCheckRequestFrom.Other.getErrorMessage(),

YoctoSDKChecker.getErrorMessage(result, from),
new 
Status(Status.ERROR, YoctoSDKPlugin.PLUGIN_ID, result.getMessage()));
 
-- 
1.8.1.4

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


[yocto] [PATCH][eclipse-poky] plugin/sdk.ide: Pre-populate project specific profile form

2013-06-25 Thread Timo Mueller
From: Timo Mueller 

On initial setup the profile form is populated with the values from
the previously selected target profile. This allows the user to
quickly make project specific adaptions of an existing profile.

If a project specific profile is already defined the form will show the
values from this configuration.

Signed-off-by: Timo Mueller 
---
 .../sdk/ide/preferences/YoctoSDKProjectPropertyPage.java   | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
index 9f99caf..408ce76 100644
--- 
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
+++ 
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java
@@ -31,14 +31,15 @@ import org.osgi.service.prefs.BackingStoreException;
 import org.yocto.sdk.ide.YoctoProfileElement;
 import org.yocto.sdk.ide.YoctoProfileSetting;
 import org.yocto.sdk.ide.YoctoProjectSpecificSetting;
+import org.yocto.sdk.ide.YoctoSDKChecker;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckRequestFrom;
 import org.yocto.sdk.ide.YoctoSDKChecker.SDKCheckResults;
 import org.yocto.sdk.ide.YoctoSDKMessages;
-import org.yocto.sdk.ide.utils.YoctoSDKUtils;
-import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
 import org.yocto.sdk.ide.YoctoSDKPlugin;
 import org.yocto.sdk.ide.YoctoUIElement;
 import org.yocto.sdk.ide.YoctoUISetting;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
+import org.yocto.sdk.ide.utils.YoctoSDKUtilsConstants;
 
 public class YoctoSDKProjectPropertyPage extends PropertyPage implements
IWorkbenchPropertyPage {
@@ -288,6 +289,15 @@ public class YoctoSDKProjectPropertyPage extends 
PropertyPage implements
public void switchToProjectSpecificProfile()
{
YoctoUIElement profileElement = 
getElemFromProjectPreferences(getProject());
+   SDKCheckResults result = 
YoctoSDKChecker.checkYoctoSDK(profileElement);
+
+   if ((result != SDKCheckResults.SDK_PASS)) {
+   /* Project specific profile has not yet been defined,
+* leave settings from previously selected profile
+*/
+   return;
+   }
+
yoctoUISetting.setCurrentInput(profileElement);
}
 
-- 
1.8.1.4

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


Re: [yocto] Installing .deb file in Build

2013-06-25 Thread Paul Eggleton
On Tuesday 25 June 2013 15:20:19 DAMARLA Satya Swaroop wrote:
> I am trying to install .deb file and the recipe is as follows... may I ask
> you what is the mistake that is not allowing it to build it into the
> rootfilesystem
> 
> *UMMARY = "Bootstrapper from Skidata"*
> *DESCRIPTION = "For the moment it just installs the .deb file"*
> *LICENSE = "CLOSED"*
> *
> *
> *SRC_URI[md5sum] = "7835334732d1704765e52168994b09a6"*
> *SRC_URI[sha256sum] =
> "11bda24a487da08ef6d3133cc0bf55862e6ae75891c7d08433341f2f3a0dc740"*
> *
> *
> *
> *
> *SRC_URI =
> "file:///home/damarla/openYocto/downloads/skidata-bootstraploader-1.0.0.14.d
> eb" *
> *
> *
> *inherit bin_package*
> *
> *
> *INITSCRIPT_PACKAGES = "${PN}-bsd"*
> *INITSCRIPT_NAME_${PN}-bsp = "bootstraploader"*
> *INITSCRIPT_PARAMS_${PN}-bsp = "defaults 90"*

You have a mismatch here, "bsp" in the last two lines and "bsd" everywhere 
else.

> *PACKAGES =+ "${PN} ${PN}-bsd"*
> *
> *
> *FILES_${PN}-bsd = "${sysconfdir}/init.d/bootstraploader"*
> *FILES_${PN} = "${D}/usr/skidata/bootstraploader/*.sh
> ${D}/usr/skidata/bootstraploader/*.pm"*

You should not include ${D} in FILES values. Because of the invalid path the 
desired files are not being picked up.

The reason you're likely getting an error at do_rootfs is that because of the 
above, the package is empty and therefore is not produced, thus it can't be 
found when it comes to installing it into the image.

Cheers,
Paul

-- 

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


Re: [yocto] FW: cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk

2013-06-25 Thread Thanassis Silis
Hi Jessica,
I have rebuilt an image with "IMAGE_INSTALL_append = " openssh" in my local.conf
which led to the generation of the image with openssh as expected.

However, the sftp-server executable was never included in the deployed image. I 
am wondering why this is.

searching for the executable gives enough results:

- there are .deb, .ipk, .rpm packages generated under 
/tmp/deploy/[deb|ipk|rpm] folders
- the executable has been installed in : 
/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/openssh/6.1p1-r0/sysroot-destdir/usr/lib/openssh/sftp-server

still it was never transfered to the image. so I wanted to do that manually 
following:
http://www.yoctoproject.org/docs/1.3.1/adt-manual/adt-manual.html#configuring-the-pms
 unfortunately, I am stuck at not finding a packaging suitable application 
(opkg-cl) in my sourced environment.

this is really a single executable file and I did just copy it manually to the 
target in the end (and debugging through openssh works fine too), but I would 
surely like to know if I have missed any steps and fail to use "smart" or 
"opkg-cl" in order to install packages in my image (or extracted image for that 
matter)

Thank you for your help.

From: djnass...@hotmail.com
To: yocto@yoctoproject.org
Date: Thu, 20 Jun 2013 17:48:58 +
Subject: [yocto] FW: cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk






From: djnass...@hotmail.com
To: jessica.zh...@intel.com
Subject: RE: [yocto] cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk
Date: Thu, 20 Jun 2013 17:48:14 +




Hi jessica,
I will try with SSH too,
but for now it seems there are some bugs with "packages_deb " being the primary 
packaging scheme.
so apart from adding 
IMAGE_INSTALL_append = " tcf-agent"

moving "packages_rpm" to be the primary scheme ended up succeeding in making an 
image that had tcf-agent included.

Thank you for your help.
I will post back when I generate an image with openssh (I have dropbear enabled 
ATM). 

From: jessica.zh...@intel.com
To: djnass...@hotmail.com; meta-freesc...@yoctoproject.org; 
yocto@yoctoproject.org
Subject: RE: [yocto] cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk
Date: Wed, 19 Jun 2013 16:25:03 +









Hi Thanassis,
 
I don’t know why tcf-agent  is not included in your sdk image.  But you also 
can use ssh to create a rse remote connection that allows you to do remote 
interaction.
  When you create remote connection, instead of choosing tcf, use ssh.  You’ll 
need openssh in your target image for this to work.
 
Cheers,
Jessica
 


From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Thanassis Silis

Sent: Tuesday, June 18, 2013 6:56 AM

To: meta-freesc...@yoctoproject.org; yocto@yoctoproject.org

Subject: [yocto] cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk


 

Hello everyone,

it seems tcf-agent is not provided. Not even in the -sdk image I created. And 
that is where my problems start:



using this in my local.conf: IMAGE_INSTALL_append = " tcf-agent"

I expected to be able to automate the process of generating the tcf-agent and 
deploying it in my image with command:
bitbake fsl-image-gui-sdk


this fails with:
| 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-core-x11-base : Depends: packagegroup-core-x11-utils but it is 
not going to be installed

| W: Ignoring Provides line with DepCompareOp for package 
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.

| ERROR: Function failed: do_rootfs (see 
/home/nass/yocto/build/tmp/work/imx6qsabrelite-poky-linux-gnueabi/fsl-image-gui-sdk/1.0-r0/temp/log.do_rootfs.26945
 for further information)

ERROR: Task 7 
(/home/nass/yocto/sources/meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb,
 do_rootfs) failed with exit code '1'

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

No currently running tasks (7417 of 7419)



Summary: 1 task failed:

  
/home/nass/yocto/sources/meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb,
 do_rootfs

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




I then went on to try and compile it manually:
bitbake fsl-image-gui-sdk -c compile tcf-agent

bitbake fsl-image-gui-sdk -c deploy


this fails with:
ERROR: Task do_deploy does not exist for target fsl-image-gui-sdk
Then I tried compiling it manually using this info

http://www.yoctoproject.org/docs/cur

Re: [yocto] Installing .deb file in Build

2013-06-25 Thread DAMARLA Satya Swaroop
Hi Guys,

I am trying to install .deb file and the recipe is as follows... may I ask
you what is the mistake that is not allowing it to build it into the
rootfilesystem

*UMMARY = "Bootstrapper from Skidata"*
*DESCRIPTION = "For the moment it just installs the .deb file"*
*LICENSE = "CLOSED"*
*
*
*SRC_URI[md5sum] = "7835334732d1704765e52168994b09a6"*
*SRC_URI[sha256sum] =
"11bda24a487da08ef6d3133cc0bf55862e6ae75891c7d08433341f2f3a0dc740"*
*
*
*
*
*SRC_URI =
"file:///home/damarla/openYocto/downloads/skidata-bootstraploader-1.0.0.14.deb"
*
*
*
*inherit bin_package*
*
*
*INITSCRIPT_PACKAGES = "${PN}-bsd"*
*INITSCRIPT_NAME_${PN}-bsp = "bootstraploader"*
*INITSCRIPT_PARAMS_${PN}-bsp = "defaults 90"*
*
*
*PACKAGES =+ "${PN} ${PN}-bsd"*
*
*
*FILES_${PN}-bsd = "${sysconfdir}/init.d/bootstraploader"*
*FILES_${PN} = "${D}/usr/skidata/bootstraploader/*.sh
${D}/usr/skidata/bootstraploader/*.pm"*

and the error I get is

*ERROR: Function failed: do_rootfs (log file is located at
/home/damarla/openYocto/poky/buildSmartCPU/tmp/work/smartcpu-untersberg-linux-gnueabi/rootfs-smartcpu/1.0-r0/temp/log.do_rootfs.30357)
*
*ERROR: Logfile of failure stored in:
/home/damarla/openYocto/poky/buildSmartCPU/tmp/work/smartcpu-untersberg-linux-gnueabi/rootfs-smartcpu/1.0-r0/temp/log.do_rootfs.30357
*
*Log data follows:*
*| DEBUG: Executing shell function do_rootfs*
*| dpkg-scanpackages: info: Wrote 33 entries to output Packages file.*
*| dpkg-scanpackages: info: Wrote 5352 entries to output Packages file.*
*| dpkg-scanpackages: info: Wrote 157 entries to output Packages file.*
*| dpkg-scanpackages: info: Wrote 33 entries to output Packages file.*
*| Ign file: ./ InRelease*
*| Ign file: ./ InRelease*
*| Ign file: ./ InRelease*
*| Ign file: ./ Release.gpg*
*| Ign file: ./ Release.gpg*
*| Ign file: ./ Release.gpg*
*| Get:1 file: ./ Release [16 B]*
*| Get:2 file: ./ Release [29 B]*
*| Get:3 file: ./ Release [11 B]*
*| Ign file: ./ Translation-en*
*| Ign file: ./ Translation-en*
*| Ign file: ./ Translation-en*
*| Reading package lists...*
*| Reading package lists...*
*| Building dependency tree...*
*| Reading state information...*
*| The following extra packages will be installed:*
*|   eglibc-binary-localedata-en-us*
*| The following NEW packages will be installed:*
*|   eglibc-binary-localedata-en-us locale-base-en-us*
*| 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.*
*| Need to get 0 B/327 kB of archives.*
*| After this operation, 0 B of additional disk space will be used.*
*| WARNING: The following packages cannot be authenticated!*
*|   eglibc-binary-localedata-en-us locale-base-en-us*
*| Authentication warning overridden.*
*| dpkg: warning: overriding problem because --force enabled:*
*|  package architecture (armel) does not match system (amd64)*
*| Selecting previously unselected package eglibc-binary-localedata-en-us.*
*| (Reading database ... 0 files and directories currently installed.)*
*| Unpacking eglibc-binary-localedata-en-us (from
.../eglibc-binary-localedata-en-us_2.17-r0_armel.deb) ...*
*| dpkg: warning: overriding problem because --force enabled:*
*|  package architecture (armel) does not match system (amd64)*
*| Selecting previously unselected package locale-base-en-us.*
*| Unpacking locale-base-en-us (from
.../locale-base-en-us_2.17-r0_armel.deb) ...*
*| Reading package lists...*
*| Building dependency tree...*
*| Reading state information...*
*| The following extra packages will be installed:*
*|   eglibc-binary-localedata-en-gb*
*| The following NEW packages will be installed:*
*|   eglibc-binary-localedata-en-gb locale-base-en-gb*
*| 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.*
*| 2 not fully installed or removed.*
*| Need to get 0 B/327 kB of archives.*
*| After this operation, 0 B of additional disk space will be used.*
*| WARNING: The following packages cannot be authenticated!*
*|   eglibc-binary-localedata-en-gb locale-base-en-gb*
*| Authentication warning overridden.*
*| dpkg: warning: overriding problem because --force enabled:*
*|  package architecture (armel) does not match system (amd64)*
*| Selecting previously unselected package eglibc-binary-localedata-en-gb.*
*| (Reading database ... 18 files and directories currently installed.)*
*| Unpacking eglibc-binary-localedata-en-gb (from
.../eglibc-binary-localedata-en-gb_2.17-r0_armel.deb) ...*
*| dpkg: warning: overriding problem because --force enabled:*
*|  package architecture (armel) does not match system (amd64)*
*| Selecting previously unselected package locale-base-en-gb.*
*| Unpacking locale-base-en-gb (from
.../locale-base-en-gb_2.17-r0_armel.deb) ...*
*| Reading package lists...*
*| Building dependency tree...*
*| Reading state information...*
*| Package bootstrapper is not available, but is referred to by another
package.*
*| This may mean that the package is missing, has been obsoleted, or*
*| is only available from another source*
*| *
*| E: Package 'bootstrapper' has no installation candidate*
*| E: Unabl

Re: [yocto] Layer input

2013-06-25 Thread Rifenbark, Scott M
Thanks Bruce.  I will implement that.

>-Original Message-
>From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>Sent: Tuesday, June 25, 2013 5:42 AM
>To: Rifenbark, Scott M
>Cc: yocto@yoctoproject.org; Paul Eggleton
>Subject: Re: [yocto] Layer input
>
>On 13-06-25 08:35 AM, Rifenbark, Scott M wrote:
>> Hi,
>>
>> This next illustration attempting to dive deeper in the YP Development
>Process takes the remaining left-side input from that figure in the
>Quick Start (metadata, Machine, and Policy).  Note that when the
>original figure was created that appears in the QS, the layer stuff had
>not yet been established.  This figure I am attaching is rough.  I am
>unsure as to the contents of these layers.  Right now it is detailed but
>with generic names.  The idea is that individual layers are preferred to
>do things such as provide software, configure policy, and configure
>machines.  I am including some notes at the bottom of the figure that
>would not be part of the figure but might help to get across what I am
>trying to accomplish here.
>>
>> Any suggestions and feedback is really appreciated.
>
>I realize you are documenting the Yocto reference builds, so the
>explicit reference to linux-yocto*.bbappend makes sense (and I obviously
>like it), but a quick tweak might be to just use .bbappend or
>.bb (since not all BSP layers must bbappend a kernel, they may
>have something very custom) for the kernel recipe reference.
>
>You've already used that notation in the distro layer for the kernel-
>headers, so it logically flows.
>
>Cheers,
>
>Bruce
>
>>
>> Thanks,
>> Scott
>>
>> Scott Rifenbark
>> Intel Corporation
>> Yocto Project Documentation
>> 503.712.2702
>> 503.341.0418 (cell)
>>
>>
>>
>>
>> ___
>> 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] Layer input

2013-06-25 Thread Bruce Ashfield

On 13-06-25 08:35 AM, Rifenbark, Scott M wrote:

Hi,

This next illustration attempting to dive deeper in the YP Development Process 
takes the remaining left-side input from that figure in the Quick Start 
(metadata, Machine, and Policy).  Note that when the original figure was 
created that appears in the QS, the layer stuff had not yet been established.  
This figure I am attaching is rough.  I am unsure as to the contents of these 
layers.  Right now it is detailed but with generic names.  The idea is that 
individual layers are preferred to do things such as provide software, 
configure policy, and configure machines.  I am including some notes at the 
bottom of the figure that would not be part of the figure but might help to get 
across what I am trying to accomplish here.

Any suggestions and feedback is really appreciated.


I realize you are documenting the Yocto reference builds, so the
explicit reference to linux-yocto*.bbappend makes sense (and I obviously
like it), but a quick tweak might be to just use .bbappend or
.bb (since not all BSP layers must bbappend a kernel, they may
have something very custom) for the kernel recipe reference.

You've already used that notation in the distro layer for the kernel-
headers, so it logically flows.

Cheers,

Bruce



Thanks,
Scott

Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)




___
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] Fwd: Yocto Layers not getting recognized by bitbake

2013-06-25 Thread Paul Eggleton
On Sunday 23 June 2013 00:34:17 varun bhatnagar wrote:
> I am trying to compile my code using yocto. For that I have created two
> layers: "meta-networking" and "meta-oe". I have added these dependencies in
> bblayer.conf too. But these are not getting build. Can anyone please tell
> me what should I do to make this work.
> 
> //
> Varun
> 
> --
> From: *Gary Thomas* 
> Date: Mon, Jun 17, 2013 at 11:03 PM
> To: yocto@yoctoproject.org
> 
> 
> More details are needed to be able to help.
> 
> What do you mean "not getting built"?  Do you mean that if you
> try to build recipe XYZ which is in one of those layers that it's
> not being built?  Or perhaps you mean something else?
> 
> What do you mean "created two layers: ..."?  Did you just extract
> these from meta-openembedded?  or something else?
> 
> > I am building one of my application using yocto by giving bitbake -k
> > core-image-minimal command but I am facing some errors as this application
> > requires two libraries
> > *1) net-snmp*
> > *2) fuse*
> > *
> > 
> > *
> > I have one link where in they are asking to add these two libraries in the
> > form of layers and then execute bitbake -k core-image-minimal command.
> > 
> > I am pasting one screenshot below:
> > 
> > As you can I have added two layers meta-networking (contains net-snmp) and
> > meta-oe(contains fuse). After this I added these layers in
> > *build/conf/bblayer.conf.*
> > *
> > *
> > *
> > 
> > *
> > After this I again executed bitbake -k core-image-minimal command but I
> > faced the same error as before... :(
> > Is there anyway that these layers get recognized? Do I need to execute
> > some other command?
> 
> Obviously, this is a recipe that you made.
> 
> Does it show these dependencies?  e.g. a line like this in your recipe file:
> DEPENDS = "net-snmp fuse"
> (or whatever the *packages* that you need are)
> 
> Bitbake can't read your mind; it will only build the recipes you ask and the
> dependencies which are explicitly specified in that build chain.
> 
> If you still have trouble, try sending your recipe (.bb file and all other
> components you might have), bblayers.conf, etc to the list because we're not
> mind readers either :-)
> 
> > On Tue, Jun 18, 2013 at 2:32 AM, Sudhangathan B S
> >  
> > sudhangat...@gmail.com**>> wrote:
> > Can you please paste your command and it's output here..! If you don't
> > 
> > mind..!! Or explain with equivalent clarity. It
> > 
> > l will good if you can also put in your directory structure.
> > 
> > --**---
> > Sudhangathan BS
> > Ph:(+91) 9731-905-205
> > --**---
> > 
> > 
> > On Mon, Jun 17, 2013 at 11:33 PM, varun bhatnagar <
> > 
> > varun292...@gmail.com **> wrote:
> > Actually the package which I am building is having some
> > 
> > dependencies on some libraries. So I provided those libraries with the
> > help of creating layers. I did not extract those from meta-openembedded,
> > instead, I manually created two layers and added them in bblayer.conf file.

Rather than creating these layers from scratch (which I think is the most 
likely source of the problem) I'd suggest starting by cloning the original 
meta-openembedded repository and building your recipe with the meta-networking 
and meta-oe layers enabled in your bblayers.conf file.

Cheers,
Paul

-- 

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


Re: [yocto] The simplest possible recipe

2013-06-25 Thread Paul Eggleton
On Tuesday 25 June 2013 11:17:47 Paul Eggleton wrote:
> > then the sample compile recipe sets S to ${WORKDIR}. Is that what one does
> > when one doesn't need to have a bunch of versioned subdirectories under
> > ${WORKDIR}? (I'm not sure why one would ever want that, or why that would
> > be the default.)
> 
> If you know you're not going to unpack an archive into a subdirectory, and
> for the single C file you aren't, then S can be set to ${WORKDIR} because
> that's where the C file will be copied to.

Or I should say, not just a C file as in the example but any kind of file that 
isn't being unpacked.

-- 

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


Re: [yocto] The simplest possible recipe

2013-06-25 Thread Paul Eggleton
Hi Paul,

On Monday 24 June 2013 17:18:05 Paul D. DeRocco wrote:
> That would be to copy a single file, provided in the files subdirectory of
> the recipe, into a particular place in the target tree. Is there any bbclass
> that automates this? Or do I just write a recipe with a do_install function
> that executes the "install" command?

There's nothing that automates this, no. On the face of it it seems 
straightforward, but when installing you need to know what the permissions 
should be, you may wish to name the file differently than it is named in 
SRC_URI, etc. For the few cases were a recipe does need to do this it's easy 
enough to just get the recipe to do everything (which is not a lot).
 
> My only guide is 5.3.1 in the Development Manual, which performs a simple
> compilation, but I'm very hazy about how recipes are interpreted, so I'd
> like it if someone can tell me if I've gotten the following stuff right or
> not.
> 
> SRC_URI tells bitbake what files must be gotten from somewhere and copied
> somewhere else in order to carry out the build process. 

To the work directory (WORKDIR) yes.

> And according to the Ref Manual, the "file://" prefix tells it to fetch a
> local file by searching some directories including the "files" subdirectory
> next to the .bb file. 

It searches FILESPATH for local files, technically, which by default includes 
subdirectories named "files" and the bare name of the recipe (${BPN}) as well 
as the bare name with the version separated by a dash (${BP}). So for a recipe 
called example-software_2.5.bb it would search "files", "example-software", and 
"example-software-2.5".

> And apparently, there is a "subdir" option (whose syntax is unexplained)
> which may be used to tell bitbake to put it somewhere specific
> relative to ${WORKDIR}.
>
> Is the default value of the "subdir" option the S variable? 

No. By default subdir is empty - since the convention for tarballs in 
free/open source software is to have a subdirectory inside the tarball 
already, we don't need to extract the contents into one explicitly, we just 
extract it under the WORKDIR and the contents will already be under a 
subdirectory. The subdir parameter exists for those upstream tarballs where 
for whatever reason the creator of the tarball has not included a 
subdirectory, or has used a subdirectory which clashes with another 
subdirectory name within the workdir that we already use ("image", "packages", 
etc.) If you do set subdir you'll also need to set S to match it.

> Is that the purpose of S, to tell bitbake where to put things that it
> fetches? 

Rather, it tells the build system where to find the sources after they have 
been unpacked.

> The Ref Manual says that S defaults to ${WORKDIR}/${PN}/${PV}

${WORKDIR}/${BP} is the default (equivalent to ${WORKDIR}/${BPN}-${PV}). This 
is a common convention based on the naming of upstream tarballs, but is by no 
means always the right value, hence you'll see a lot of recipes set S to the 
correct value to point to whatever will be extracted from the upstream tarball 
fetched by that recipe.

> then the sample compile recipe sets S to ${WORKDIR}. Is that what one does
> when one doesn't need to have a bunch of versioned subdirectories under
> ${WORKDIR}? (I'm not sure why one would ever want that, or why that would be
> the default.)

If you know you're not going to unpack an archive into a subdirectory, and for 
the single C file you aren't, then S can be set to ${WORKDIR} because that's 
where the C file will be copied to.
 
> So if I want to install a file somewhere, do I even need a do_install task,
> or can I just set S equal to the desired target location, like
> "${etcdir}/foo" and be done with it? Or is that a no-no, and should I always
> use do_install?

You should always use do_install. You'll lose a bunch of flexibility trying to 
do it the other way and you may break some assumptions the system makes about 
what it can do with S, not to mention that the sstate code might break.

HTH.

Cheers,
Paul

-- 

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


Re: [yocto] Documenting YP Development Environment in more detail - user configuration

2013-06-25 Thread Burton, Ross
On 25 June 2013 01:39, Philip Balister  wrote:
> I totally agree we drifted way beyond the initial discussion of the
> figure. The key thought here is understanding how Poky differs from a
> typical use of oe-core + other layers.

Is there such a thing as a "typical" use of oe-core + layers?  Poky
uses a custom tool (combo-layer, in oe-core/scripts) to merge the
layers into a single repo.  You could also use git submodules to make
a single repo (such as Guacamayo), or git subtree merges, or use repo
(gumstix), or have a script that manages the fetching of multiple
layers (Angstrom).

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


Re: [yocto] [PATCH v2] Fix Eclipse workspace deadlock when restoring

2013-06-25 Thread Grigoropol, IoanaX
Hi Jessica,

This is the compromise we talked about. We cannot control the way Eclipse 
restores the workspace or the time when RSE API is initialized. That is why, we 
returned a Null store at first and created a hook for restoring the connection 
when the RSE API is up.
I am not sure that we can catch that error message(regarding the project 
description) since it is deep within the Eclipse core.
On the other hand, I am not sure I understand what you mean by telling the user 
to restore the remote connection. 
In the current implementation, we return a null file store, and when we get 
notified that the RSE API is up, we will automatically restore the Bitbake 
session, and the shell session.
The project remote connection will be restored in a lazy way, when it is 
accessed, since at this point we will have the sessions we need to do that.
What action should be performed upon catching that action, and telling the user 
to restore, besides waiting for the RSE API to be initialized and update the 
connection when we need it ?

Thanks,
Ioana

From: Zhang, Jessica
Sent: Friday, June 21, 2013 10:43 PM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Cc: Ioana Grigoropol
Subject: RE: [yocto] [PATCH v2] Fix Eclipse workspace deadlock when restoring

OK more info. It seems if the project is remote, first we'll get the project 
description failure since we haven't restored the remote connection, after we 
dismiss the error and double click on the project and restore the RSE 
connection, the project will be able to restore.  We should change the error 
message into warning and tell user to restore their RSE connection.

Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Friday, June 21, 2013 7:27 AM
To: yocto@yoctoproject.org
Cc: Ioana Grigoropol
Subject: [yocto] [PATCH v2] Fix Eclipse workspace deadlock when restoring

From: Ioana Grigoropol 

- when creating a new bitbake commander project, a bunch of information 
relevant for the project is set in the project information map
- when closing & restarting Eclipse, having a Bitbake commander project in the 
workspace an deadlock occurs due to the following:
- Eclipse Resources container tries to restore all projects that were 
previously in the workspace
- when trying to restore our BB project, we will try to determine what 
was the remote connection for that specific project, given its URI
- we can only determine the connection by calling RSE plugin & 
we must wait for it to be initialized
- the RSE plugin is initialized after the Resource container is 
finishes, and since this process is blocked waiting for a later one, a deadlock 
occurs

- in order to fix this problem, perform the following steps:
- when the Eclipse Resource container asks for the store of our project
- return a NullFileStore
- register as a listener of the RSEInitJob in order to get 
notified when the job is finished
- restore the project information when the RSE API is up by 
triggering the internal file system core manager
- restoring the information:
- for the local implementation:
- the connection of the project is missing -> retrive 
it by invoking RSE
- for the remote implementation:
- the only URI for the project is the oefs one
- we cannot change this uri to point to the real one 
since it will block the refresh on the project
- we cannot determine the real URI form the oefs one 
since we have no clue what is the host(ip)
   -> solution:
- when creating the BBC project
- save the information about the real URI of 
the project in the metadata of the workspace
- when restoring the project
- retrieve the information from the metadata 
location
- fixed also the Project Description of the Location to display the real URI of 
the files

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/ShellSession.java |2 +-
 .../src/org/yocto/bc/ui/Activator.java |4 +-
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   10 +--
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   11 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |   10 +++
 .../yocto/bc/ui/wizards/install/InstallWizard.java |1 +
 .../org.yocto.remote.utils/META-INF/MANIFEST.MF|6 +-
 .../src/org/yocto/remote/utils/RemoteHelper.java   |   79 
 8 files changed, 113 insertions(+), 10 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
index 11d677a..724b7d0 100

Re: [yocto] [RFC PATCH v2 upstream org.eclipse.tm] [411343]Provide access to readers in host shell

2013-06-25 Thread Grigoropol, IoanaX
Hi Jessica,

I have just tested with a clean master & my upstream patch. Everything compiles 
fine.
There are no changes made to IHostShell what so ever. In this patch, I only 
change AbstractHostShell and TerminalServiceHostShell.

Please make sure that your TM &Yocto plugin sources are up to date and 
refreshed in you workspace.

Thanks,
Ioana

From: Zhang, Jessica
Sent: Friday, June 21, 2013 8:42 PM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [RFC PATCH v2 upstream org.eclipse.tm] [411343]Provide 
access to readers in host shell

Hi Ioana,

Unfortunately we have to introduce the API getReader in IHostShell interface, 
otherwise, when I applied the patch to my clean upstream RSE master and open a 
project I'm getting:

An internal error occurred during "Open Project"
Unresolved compilation problems:
The method getReader(Boolean) is undefined for the type IHostShell

Please do some local verification when sending patches upstream.

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Friday, June 21, 2013 8:19 AM
To: yocto@yoctoproject.org
Subject: [yocto] [RFC PATCH v2 upstream org.eclipse.tm] [411343]Provide access 
to readers in host shell

- add a plain getter in the AbstractHostShell class:
- the compilation is not broken for subclasses of this class since it 
always returns null
- the targeted classes (local and remote) can implement the getter 
(local implementation is already there)
- the reader can be accessed and the output can be read in a 
synchronous way
- add implementation of getReader in TerminaServiceHostShell
- store the underlying reader as a field of this class & return it
Signed-off-by: Ioana Grigoropol 
---
 .../services/shells/TerminalServiceHostShell.java  |   20 
 .../rse/services/shells/AbstractHostShell.java |9 +++--
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git 
a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceHostShell.java
 
b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceHostShell.java
index 2a461ad..0775894 100644
--- 
a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceHostShell.java
+++ b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/
+++ services/shells/TerminalServiceHostShell.java
@@ -22,6 +22,7 @@
  * Anna Dushistova  (MontaVista) - [258720] SshHostShell fails to run command 
if initialWorkingDirectory supplied
  * Rob Stryker (JBoss) - [335059] TerminalServiceShellOutputReader logs error 
when hostShell.exit() is called
  * Martin Oberhuber (Wind River) - [356132] wait for initial output
+ * Ioana Grigoropol (Intel)  - [411343] Provide access to readers in host 
shell
  
***/

 package org.eclipse.rse.internal.services.shells;
@@ -47,7 +48,7 @@ public class TerminalServiceHostShell extends 
AbstractHostShell {
public static final String SHELL_INVOCATION = ">"; //$NON-NLS-1$

ITerminalShell fTerminalShell;
-
+   BufferedReader fBufReader;
private TerminalServiceShellOutputReader fStdoutHandler;

private TerminalServiceShellOutputReader fStderrHandler; @@ -60,21 
+61,21 @@ public class TerminalServiceHostShell extends AbstractHostShell {
try {
fTerminalShell = terminalShell;
String encoding = fTerminalShell.getDefaultEncoding();
-   BufferedReader bufReader;
+
if (encoding != null) {
-   bufReader = new BufferedReader(new 
InputStreamReader(fTerminalShell
+   fBufReader = new BufferedReader(new
+InputStreamReader(fTerminalShell
.getInputStream(), encoding));
} else {
-   bufReader = new BufferedReader(new 
InputStreamReader(fTerminalShell
+   fBufReader = new BufferedReader(new
+InputStreamReader(fTerminalShell

.getInputStream()));
}
//bug 356132: wait for initial output before sending 
any command
//FIXME this should likely move into the 
TerminalServiceShellWriterThread, so wait can be canceled
-   bufReader.mark(1);
-   bufReader.read();
-   bufReader.reset();
+   fBufReader.mark(1);
+   fBufReader.read();
+   fBufReader.reset();

-   fStdoutHandler = new 
TerminalServiceShel

Re: [yocto] [PATCH 1/1][eclipse-poky] systemtap: add button to browse to build folder

2013-06-25 Thread Adrian Dudau
Hi Jessica,

Can you please have a look at this patch? It's been pending for a while.

Thanks,
--Adrian


On Mon, 2013-06-17 at 14:37 +0200, Adrian Dudau wrote:
> [Yocto #4223]
> Signed-off-by: Adrian Dudau 
> ---
>  .../src/org/yocto/remote/utils/ShellSession.java   |4 ++-
>  .../src/org/yocto/sdk/remotetools/Messages.java|1 +
>  .../sdk/remotetools/actions/SystemtapHandler.java  |3 ++-
>  .../sdk/remotetools/actions/SystemtapModel.java|6 +++--
>  .../actions/SystemtapSettingDialog.java|   28 
> 
>  .../org/yocto/sdk/remotetools/messages.properties  |1 +
>  6 files changed, 39 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java 
> b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
> index 4ac8001..10cdf94 100644
> --- 
> a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
> +++ 
> b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
> @@ -46,6 +46,7 @@ public class ShellSession {
>   private String shellPath = null;
>   private final String initCmd;
>   private final File root;
> + private final File builddir;
>  
>   private OutputStreamWriter out;
>  
> @@ -70,6 +71,7 @@ public class ShellSession {
>  
>   public ShellSession(int shellType, File root, String initCmd, 
> OutputStream out) throws IOException {
>   this.root = root;
> + this.builddir = builddir;
>   this.initCmd  = initCmd;
>   if (out == null) {
>   this.out = new OutputStreamWriter(null);
> @@ -93,7 +95,7 @@ public class ShellSession {
>   }
>  
>   if (initCmd != null) {
> - execute("source " + initCmd);
> + execute("source " + initCmd + " " + 
> builddir.getAbsolutePath());
>   }
>   }
>  
> diff --git 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
>  
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
> index 66ba62b..cbf2b05 100644
> --- 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
> +++ 
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
> @@ -40,6 +40,7 @@ public class Messages extends NLS {
>   public static String TerminalViewer_text;
>   //public static String Systemtap_KO_Text;
>   public static String Metadata_Location;
> + public static String Builddir_Location;
>   public static String User_ID;
>   public static String Remote_Host;
>   public static String Systemtap_Script;
> diff --git 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
>  
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
> index 9d27e5a..9f45d05 100644
> --- 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
> +++ 
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
> @@ -34,6 +34,7 @@ public class SystemtapHandler extends AbstractHandler {
>   );
>   
>   String metadata_location = 
> ((SystemtapSettingDialog)setting).getMetadataLocation();
> + String builddir_location = 
> ((SystemtapSettingDialog)setting).getBuilddirLocation();
>   String remote_host = 
> ((SystemtapSettingDialog)setting).getRemoteHost();
>   String user_id = ((SystemtapSettingDialog)setting).getUserID();
>   String systemtap_script = 
> ((SystemtapSettingDialog)setting).getSystemtapScript();
> @@ -41,7 +42,7 @@ public class SystemtapHandler extends AbstractHandler {
>  
>   if(setting.open() == BaseSettingDialog.OK) {
>   IProgressService progressService = 
> PlatformUI.getWorkbench().getProgressService();
> - SystemtapModel op = new 
> SystemtapModel(metadata_location,remote_host, user_id, systemtap_script,
> + SystemtapModel op = new 
> SystemtapModel(metadata_location, builddir_location, remote_host, user_id, 
> systemtap_script,
>   
> systemtap_args,window.getShell().getDisplay());
>   try {
>   progressService.busyCursorWhile(op);
> diff --git 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
>  
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
> index f443e00..bb2fa2d 100644
> --- 
> a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
> +++ 
> b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
> @@ -29,6 +29,7 @@ public class S

Re: [yocto] Adding users and their rights

2013-06-25 Thread DAMARLA Satya Swaroop
Thank you Nicolas and Anders... This is what Iam actually looking for...

Cheers,
Satya


On Tue, Jun 25, 2013 at 8:58 AM, Anders Darander wrote:

> ,
>
> * DAMARLA Satya Swaroop  [130625 08:39]:
> > I would like to know if its possible to add users and theri rights at
> > the build
> > itself... I know tinylogin provides the adduser to the target but how
> > can I do
> > it at the build is the issue here..
>
> Sure, it's quite easy to do using the useradd class. See
>
> http://cgit.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
> for more info
>
> Cheers,
> Anders
>
> --
> Anders Darander
> ChargeStorm AB / eStorm AB
>
> ___
> 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] Documenting YP Development Environment in more detail

2013-06-25 Thread Nicolas Dechesne
On Tue, Jun 25, 2013 at 7:15 AM, Rudolf Streif
wrote:

>
>
>> An appendix on Android's "repo" tool might make for an excellent
>> addition; it seems some Yocto projects are showing lots of interest in
>> using it.
>>
>> The idea is to integrate/use it with YP? I know what repo does and that
> it is built on top of git but I have not looked behind the scenes to figure
> out how it does its job and how it can be used with something else like YP
> instead of with the Android repositories and review system.
>

not integrate with yocto directly. but use it to 'manage' the set of trees
that are required when using OE/Yocto. The gumstix guys are using it, see
[1], and we are moving toward it at linaro too, to manage our builds [2]

[1] https://github.com/gumstix/Gumstix-YoctoProject-Repo
[2] http://lists.linaro.org/pipermail/linaro-dev/2013-May/015998.html

then for organization that might need it, repo can be integrated with
gerrit too, but repo 'standalone' can still be used to manage set of trees.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto