date:20130115

[yocto] [PATCH v2 0/5][eclipse-poky][branch:windows-build]Multiple fixes

2013-01-15 Thread Ioana Grigoropol

- applies onto commit 27bb1f9e45f0a9408453f9e7e70cc333b97afe

Ioana Grigoropol (5):
  Fix variables hoover & remote file system detection
  Allow '-' in project names
  Reinstate OEFileSystem, OEFile and Ignored Paths for Linux
  Disable "Finish" when project location is invalid
  Send output from bitbake environment parsing in the background

 plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF   |2 +-
 plugins/org.yocto.bc.ui/plugin.xml |3 +-
 .../src/org/yocto/bc/bitbake/BBSession.java|   91 -
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   24 ++--
 .../src/org/yocto/bc/bitbake/ShellSession.java |   14 +-
 .../org/yocto/bc/remote/utils/RemoteHelper.java|   10 +-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |   25 ++--
 .../remote/utils/YoctoHostShellProcessAdapter.java |   14 +-
 .../src/org/yocto/bc/ui/Activator.java |   45 --
 .../org/yocto/bc/ui/BCResourceChangeListener.java  |1 -
 .../bc/ui/editors/bitbake/BBVariableTextHover.java |   12 +-
 .../src/org/yocto/bc/ui/filesystem/OEFile.java |  143 ++--
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   52 ---
 .../bc/ui/filesystem/OEFileSystemContributor.java  |7 +-
 .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java   |   31 -
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   21 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |  110 ---
 .../yocto/bc/ui/wizards/FiniteStateWizardPage.java |   54 
 .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java  |   58 
 .../ui/wizards/NewBitBakeFileRecipeWizardPage.java |5 +-
 .../yocto/bc/ui/wizards/install/InstallWizard.java |   63 +
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |   11 +-
 .../BBConfigurationInitializeOperation.java|2 +
 .../newproject/CreateBBCProjectOperation.java  |   23 ++--
 24 files changed, 494 insertions(+), 327 deletions(-)

-- 
1.7.9.5

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

[yocto] [PATCH v2 1/5] Fix variables hoover & remote file system detection

2013-01-15 Thread Ioana Grigoropol

- initialize bitbake session for recipe:
- when starting a new project, the session environment variables are 
obtained by calling "bitbake -e"
- when a new recipe is created and edited, the session variables should 
be updated with the values obtained from "bitbake -e -b package" => overwrite 
the session with the new one
- if we try to retrive a "remote" file (local file system, remote host) using 
RSE protocol before the system is initialized, null will be returned causing 
every remote operation to fail:
- add exception handling
- make sure that the "remote" FileSystem gets initialized, as well as 
the project connection

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/BBSession.java|4 
 .../src/org/yocto/bc/bitbake/ShellSession.java |   13 -
 .../org/yocto/bc/remote/utils/RemoteHelper.java|7 ++-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |8 +---
 .../bc/ui/editors/bitbake/BBVariableTextHover.java |   12 +---
 5 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 3aa4efe..66a6083 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -746,4 +746,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
wlock.unlock();
}
}
+
+   public Map getProperties() {
+   return (Map) properties;
+   }
 }
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 c127c25..38e2557 100644
--- 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
@@ -86,8 +86,12 @@ public class ShellSession {
 
private void initializeShell(IProgressMonitor monitor) throws 
IOException {
try {
-   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""));
-   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand(exportCmd, root.getAbsolutePath(), ""));
+   if (root != null) {
+   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""));
+   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand(exportCmd, root.getAbsolutePath(), ""));
+   } else {
+   throw new Exception("Root file not found!");
+   }
} catch (Exception e) {
e.printStackTrace();
}
@@ -103,9 +107,8 @@ public class ShellSession {
 
try {
if (projectInfo.getConnection() != null) {
-   IHost connection = 
RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
-   hasErrors = 
RemoteHelper.runCommandRemote(connection, new YoctoCommand(command, 
root.getAbsolutePath() + "/build/", ""));
-   return 
RemoteHelper.getProcessBuffer(connection).getMergedOutputLines();
+   hasErrors = 
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand(command, root.getAbsolutePath() + "/build/", ""));
+   return 
RemoteHelper.getProcessBuffer(projectInfo.getConnection()).getMergedOutputLines();
}
return null;
} catch (Exception e) {
diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
index c230fd6..e511e06 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
@@ -99,7 +99,11 @@ public class RemoteHelper {
if (host == null) {
// this is a local connection
ISystemRegistry sr = 
RSECorePlugin.getTheSystemRegistry();
-   return sr.getLocalHost();
+   IHost local = null;
+   while (local == null) {
+   local = sr.getLocalHost();
+   }
+   return local;
}
ISystemRegistry sr = RSECorePlugin.getTheSystemRegistry();
IHost[] connections = sr.getHosts();
@@ -237,6 +241,7 @@ public class RemoteHelper

[yocto] [PATCH v2 2/5] Allow '-' in project names

2013-01-15 Thread Ioana Grigoropol

Signed-off-by: Ioana Grigoropol 
---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index 72aeec2..97d1ad0 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
@@ -313,7 +313,7 @@ public class OptionsPage extends FiniteStateWizardPage {
if (!Character.isJavaIdentifierStart(chars[0]))
return false;
for (int i = 1; i < chars.length; i++)
-   if (!Character.isJavaIdentifierPart(chars[i]))
+   if (!Character.isJavaIdentifierPart(chars[i]) && 
chars[i] != '-')
return false;
return true;
}
-- 
1.7.9.5

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

[yocto] [PATCH v2 1/3] Reinstate OEFileSystem, OEFile and Ignored Paths for Linux

2013-01-15 Thread Ioana Grigoropol

- OEFileSystem and OEFile were dropped due to the use of hardcoded scheme 
"oefs://" that stopped remote connection from working. There is a need to have 
a custom file system in order to skip indexing large directories (such as 
build, tmp) and ignore some paths--was not tested under Windows

Signed-off-by: Ioana Grigoropol 
---
 plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF   |2 +-
 plugins/org.yocto.bc.ui/plugin.xml |3 +-
 .../src/org/yocto/bc/bitbake/BBSession.java|   62 ++---
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   24 ++--
 .../src/org/yocto/bc/ui/Activator.java |   45 --
 .../org/yocto/bc/ui/BCResourceChangeListener.java  |1 -
 .../src/org/yocto/bc/ui/filesystem/OEFile.java |  143 ++--
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   50 +--
 .../bc/ui/filesystem/OEFileSystemContributor.java  |7 +-
 .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java   |   31 -
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   21 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |  110 ---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |2 +-
 .../newproject/CreateBBCProjectOperation.java  |   23 ++--
 14 files changed, 318 insertions(+), 206 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF 
b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
index 9e8c523..1f0e63e 100644
--- a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Bundle-Name
 Bundle-SymbolicName: org.yocto.bc.ui;singleton:=true
-Bundle-Version: 1.4.0.qualifier
+Bundle-Version: 1.2.0.qualifier
 Bundle-Activator: org.yocto.bc.ui.Activator
 Bundle-Vendor: %Bundle-Vendor
 Require-Bundle: org.eclipse.ui,
diff --git a/plugins/org.yocto.bc.ui/plugin.xml 
b/plugins/org.yocto.bc.ui/plugin.xml
index cb0561c..6ba9b5f 100644
--- a/plugins/org.yocto.bc.ui/plugin.xml
+++ b/plugins/org.yocto.bc.ui/plugin.xml
@@ -180,8 +180,7 @@


-  
+  
  
  
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 66a6083..037d8aa 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -48,7 +48,7 @@ import org.yocto.bc.ui.model.ProjectInfo;
 /**
  * BBSession encapsulates a global bitbake configuration and is the primary 
interface
  * for actions against a BitBake installation.
- * 
+ *
  * @author kgilmer
  *
  */
@@ -57,10 +57,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public static final int TYPE_UNKNOWN = 2;
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
-   
+
+   public static final String CONF_DIR = "/conf";
public static final String BUILDDIR_INDICATORS [] = {
-   "/conf/local.conf",
-   "/conf/bblayers.conf",
+   "/local.conf",
+   "/bblayers.conf",
};
 
protected final ProjectInfo pinfo;
@@ -74,7 +75,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
private final Lock wlock = rwlock.writeLock();
protected String parsingCmd;
private boolean silent = false;
-   
+
public BBSession(ShellSession ssession, URI projectRoot) throws 
IOException {
shell = ssession;
this.pinfo = new ProjectInfo();
@@ -87,7 +88,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
this(ssession, projectRoot);
this.silent = silent;
}
-   
+
private Collection adapttoIPath(List asList, IProject project) {
 
List pathList = new ArrayList();
@@ -102,7 +103,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return pathList;
}
-   
+
private String appendAll(String[] elems, int st) {
StringBuffer sb = new StringBuffer();
 
@@ -112,7 +113,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return sb.toString();
}
-   
+
private int charCount(String trimmed, char c) {
int i = 0;
int p = 0;
@@ -124,11 +125,13 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return i;
}
-   
+
+   @Override
public void clear() {
throw new RuntimeException("BB configuration is read-only.");
}
 
+   @Override
public boolean containsKey(Object arg0) {
try {
checkValidAndLock(true);
@@ -141,6 +144,7 @@ public class BBSession implements IB

[yocto] [PATCH v2 2/3] Disable "Finish" when project location is invalid

2013-01-15 Thread Ioana Grigoropol

- when Bitbake project location is invalid, an error should be displayed and 
"finish" button disabled

Signed-off-by: Ioana Grigoropol 
---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index a103d2b..7a705aa 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
@@ -88,8 +88,13 @@ public class OptionsPage extends FiniteStateWizardPage {
@Override
public void reportError(String errorMessage, boolean 
infoOnly) {
setMessage(errorMessage);
-   validatePage();
-   updateModel();
+   if (validatePage()) {
+   updateModel();
+   setPageComplete(true);
+   return;
+   }
+
+   setPageComplete(false);
}
};
 
@@ -181,7 +186,6 @@ public class OptionsPage extends FiniteStateWizardPage {
setErrorMessage("A project with the 
name " + projName + " already exists");
return false;
}
-   //FIXME : do not throw exception when illegal 
characters show in URI ->show error on page
URI location = new URI("file:" + URI_SEPARATOR 
+ URI_SEPARATOR + convertToRealPath(projectLoc) + URI_SEPARATOR + 
txtProjectName.getText());
 
IStatus status = 
ResourcesPlugin.getWorkspace().validateProjectLocationURI(proj, location);
-- 
1.7.9.5

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

[yocto] [PATCH v2 3/5] Reinstate OEFileSystem, OEFile and Ignored Paths for Linux

2013-01-15 Thread Ioana Grigoropol

- OEFileSystem and OEFile were dropped due to the use of hardcoded scheme 
"oefs://" that stopped remote connection from working. There is a need to have 
a custom file system in order to skip indexing large directories (such as 
build, tmp) and ignore some paths--was not tested under Windows

Signed-off-by: Ioana Grigoropol 
---
 plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF   |2 +-
 plugins/org.yocto.bc.ui/plugin.xml |3 +-
 .../src/org/yocto/bc/bitbake/BBSession.java|   62 ++---
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   24 ++--
 .../src/org/yocto/bc/ui/Activator.java |   45 --
 .../org/yocto/bc/ui/BCResourceChangeListener.java  |1 -
 .../src/org/yocto/bc/ui/filesystem/OEFile.java |  143 ++--
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   50 +--
 .../bc/ui/filesystem/OEFileSystemContributor.java  |7 +-
 .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java   |   31 -
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   21 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |  110 ---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |2 +-
 .../newproject/CreateBBCProjectOperation.java  |   23 ++--
 14 files changed, 318 insertions(+), 206 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF 
b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
index 9e8c523..1f0e63e 100644
--- a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Bundle-Name
 Bundle-SymbolicName: org.yocto.bc.ui;singleton:=true
-Bundle-Version: 1.4.0.qualifier
+Bundle-Version: 1.2.0.qualifier
 Bundle-Activator: org.yocto.bc.ui.Activator
 Bundle-Vendor: %Bundle-Vendor
 Require-Bundle: org.eclipse.ui,
diff --git a/plugins/org.yocto.bc.ui/plugin.xml 
b/plugins/org.yocto.bc.ui/plugin.xml
index cb0561c..6ba9b5f 100644
--- a/plugins/org.yocto.bc.ui/plugin.xml
+++ b/plugins/org.yocto.bc.ui/plugin.xml
@@ -180,8 +180,7 @@


-  
+  
  
  
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 66a6083..037d8aa 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -48,7 +48,7 @@ import org.yocto.bc.ui.model.ProjectInfo;
 /**
  * BBSession encapsulates a global bitbake configuration and is the primary 
interface
  * for actions against a BitBake installation.
- * 
+ *
  * @author kgilmer
  *
  */
@@ -57,10 +57,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public static final int TYPE_UNKNOWN = 2;
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
-   
+
+   public static final String CONF_DIR = "/conf";
public static final String BUILDDIR_INDICATORS [] = {
-   "/conf/local.conf",
-   "/conf/bblayers.conf",
+   "/local.conf",
+   "/bblayers.conf",
};
 
protected final ProjectInfo pinfo;
@@ -74,7 +75,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
private final Lock wlock = rwlock.writeLock();
protected String parsingCmd;
private boolean silent = false;
-   
+
public BBSession(ShellSession ssession, URI projectRoot) throws 
IOException {
shell = ssession;
this.pinfo = new ProjectInfo();
@@ -87,7 +88,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
this(ssession, projectRoot);
this.silent = silent;
}
-   
+
private Collection adapttoIPath(List asList, IProject project) {
 
List pathList = new ArrayList();
@@ -102,7 +103,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return pathList;
}
-   
+
private String appendAll(String[] elems, int st) {
StringBuffer sb = new StringBuffer();
 
@@ -112,7 +113,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return sb.toString();
}
-   
+
private int charCount(String trimmed, char c) {
int i = 0;
int p = 0;
@@ -124,11 +125,13 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return i;
}
-   
+
+   @Override
public void clear() {
throw new RuntimeException("BB configuration is read-only.");
}
 
+   @Override
public boolean containsKey(Object arg0) {
try {
checkValidAndLock(true);
@@ -141,6 +144,7 @@ public class BBSession implements IB

[yocto] [PATCH v2 3/3] Send output from bitbake environment parsing in the background

2013-01-15 Thread Ioana Grigoropol

- after creating the project, the wizard should not block waiting for the 
environment to be populated and instead should be ran in the background

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/BBSession.java|   27 +
 .../src/org/yocto/bc/bitbake/ShellSession.java |3 +-
 .../org/yocto/bc/remote/utils/RemoteHelper.java|3 +-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |   23 +++
 .../remote/utils/YoctoHostShellProcessAdapter.java |   14 -
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   14 ++---
 .../yocto/bc/ui/wizards/FiniteStateWizardPage.java |   54 +
 .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java  |   58 +-
 .../ui/wizards/NewBitBakeFileRecipeWizardPage.java |5 +-
 .../yocto/bc/ui/wizards/install/InstallWizard.java |   63 +---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |1 +
 .../BBConfigurationInitializeOperation.java|2 +
 12 files changed, 149 insertions(+), 118 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 037d8aa..9adeb3f 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -13,8 +13,8 @@ package org.yocto.bc.bitbake;
 import java.io.BufferedReader;
 import java.io.File;
 import java.io.FileFilter;
+import java.io.FileReader;
 import java.io.IOException;
-import java.io.StringReader;
 import java.net.URI;
 import java.util.ArrayList;
 import java.util.Arrays;
@@ -58,6 +58,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
 
+   public static final String BB_ENV_FILE = "bitbake.env";
+
public static final String CONF_DIR = "/conf";
public static final String BUILDDIR_INDICATORS [] = {
"/local.conf",
@@ -81,7 +83,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
this.pinfo = new ProjectInfo();
pinfo.setLocation(projectRoot);

pinfo.setInitScriptPath(ProjectInfoHelper.getInitScriptPath(projectRoot));
-   this.parsingCmd = "DISABLE_SANITY_CHECKS=\"1\" bitbake -e";
+   this.parsingCmd = "sh -c 'DISABLE_SANITY_CHECKS=\"1\" bitbake 
-e >& " + BB_ENV_FILE + "  '" ;
}
 
public BBSession(ShellSession ssession, URI projectRoot, boolean 
silent) throws IOException {
@@ -387,11 +389,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
if(!initialized) { //recheck
boolean hasErrors = false;
String result = 
shell.execute(parsingCmd, hasErrors);
-   if(!hasErrors) {
-   properties = 
parseBBEnvironment(result);
-   } else {
-   properties = 
parseBBEnvironment("");
-   }
+
+   //FIXME : wait for bitbake to finish
+
+   properties = parseBBEnvironment(result);
+
initialized = true;
}
} finally {
@@ -450,10 +452,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
}
}
 
-   protected void parse(String content, Map outMap) throws Exception {
-   if (content == null)
-   return;
-   BufferedReader reader = new BufferedReader(new 
StringReader(content));
+   protected void parse(String bbOutfilePath, Map outMap) throws Exception 
{
+   BufferedReader reader = new BufferedReader(new 
FileReader(bbOutfilePath + BB_ENV_FILE));
String line;
boolean inLine = false;
StringBuffer sb = null;
@@ -520,11 +520,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
return null;
}
 
-   protected Map parseBBEnvironment(String bbOut) throws Exception {
+   protected Map parseBBEnvironment(String bbOutFilePath) throws Exception 
{
Map env = new Hashtable();
this.depends = new ArrayList();
 
-   parse(bbOut, env);
+   parse(bbOutFilePath, env);
 
String included = (String) env.get("BBINCLUDED");
if(getDefaultDepends() != null) {
@@ -768,4 +768,5 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public Map getProperties() {
return (Map) prop

[yocto] [PATCH v2 4/5] Disable "Finish" when project location is invalid

2013-01-15 Thread Ioana Grigoropol

- when Bitbake project location is invalid, an error should be displayed and 
"finish" button disabled

Signed-off-by: Ioana Grigoropol 
---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index a103d2b..7a705aa 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
@@ -88,8 +88,13 @@ public class OptionsPage extends FiniteStateWizardPage {
@Override
public void reportError(String errorMessage, boolean 
infoOnly) {
setMessage(errorMessage);
-   validatePage();
-   updateModel();
+   if (validatePage()) {
+   updateModel();
+   setPageComplete(true);
+   return;
+   }
+
+   setPageComplete(false);
}
};
 
@@ -181,7 +186,6 @@ public class OptionsPage extends FiniteStateWizardPage {
setErrorMessage("A project with the 
name " + projName + " already exists");
return false;
}
-   //FIXME : do not throw exception when illegal 
characters show in URI ->show error on page
URI location = new URI("file:" + URI_SEPARATOR 
+ URI_SEPARATOR + convertToRealPath(projectLoc) + URI_SEPARATOR + 
txtProjectName.getText());
 
IStatus status = 
ResourcesPlugin.getWorkspace().validateProjectLocationURI(proj, location);
-- 
1.7.9.5

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

[yocto] [PATCH v2 5/5] Send output from bitbake environment parsing in the background

2013-01-15 Thread Ioana Grigoropol

- after creating the project, the wizard should not block waiting for the 
environment to be populated and instead should be ran in the background

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/BBSession.java|   27 +
 .../src/org/yocto/bc/bitbake/ShellSession.java |3 +-
 .../org/yocto/bc/remote/utils/RemoteHelper.java|3 +-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |   23 +++
 .../remote/utils/YoctoHostShellProcessAdapter.java |   14 -
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   14 ++---
 .../yocto/bc/ui/wizards/FiniteStateWizardPage.java |   54 +
 .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java  |   58 +-
 .../ui/wizards/NewBitBakeFileRecipeWizardPage.java |5 +-
 .../yocto/bc/ui/wizards/install/InstallWizard.java |   63 +---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |1 +
 .../BBConfigurationInitializeOperation.java|2 +
 12 files changed, 149 insertions(+), 118 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 037d8aa..9adeb3f 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -13,8 +13,8 @@ package org.yocto.bc.bitbake;
 import java.io.BufferedReader;
 import java.io.File;
 import java.io.FileFilter;
+import java.io.FileReader;
 import java.io.IOException;
-import java.io.StringReader;
 import java.net.URI;
 import java.util.ArrayList;
 import java.util.Arrays;
@@ -58,6 +58,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
 
+   public static final String BB_ENV_FILE = "bitbake.env";
+
public static final String CONF_DIR = "/conf";
public static final String BUILDDIR_INDICATORS [] = {
"/local.conf",
@@ -81,7 +83,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
this.pinfo = new ProjectInfo();
pinfo.setLocation(projectRoot);

pinfo.setInitScriptPath(ProjectInfoHelper.getInitScriptPath(projectRoot));
-   this.parsingCmd = "DISABLE_SANITY_CHECKS=\"1\" bitbake -e";
+   this.parsingCmd = "sh -c 'DISABLE_SANITY_CHECKS=\"1\" bitbake 
-e >& " + BB_ENV_FILE + "  '" ;
}
 
public BBSession(ShellSession ssession, URI projectRoot, boolean 
silent) throws IOException {
@@ -387,11 +389,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
if(!initialized) { //recheck
boolean hasErrors = false;
String result = 
shell.execute(parsingCmd, hasErrors);
-   if(!hasErrors) {
-   properties = 
parseBBEnvironment(result);
-   } else {
-   properties = 
parseBBEnvironment("");
-   }
+
+   //FIXME : wait for bitbake to finish
+
+   properties = parseBBEnvironment(result);
+
initialized = true;
}
} finally {
@@ -450,10 +452,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
}
}
 
-   protected void parse(String content, Map outMap) throws Exception {
-   if (content == null)
-   return;
-   BufferedReader reader = new BufferedReader(new 
StringReader(content));
+   protected void parse(String bbOutfilePath, Map outMap) throws Exception 
{
+   BufferedReader reader = new BufferedReader(new 
FileReader(bbOutfilePath + BB_ENV_FILE));
String line;
boolean inLine = false;
StringBuffer sb = null;
@@ -520,11 +520,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
return null;
}
 
-   protected Map parseBBEnvironment(String bbOut) throws Exception {
+   protected Map parseBBEnvironment(String bbOutFilePath) throws Exception 
{
Map env = new Hashtable();
this.depends = new ArrayList();
 
-   parse(bbOut, env);
+   parse(bbOutFilePath, env);
 
String included = (String) env.get("BBINCLUDED");
if(getDefaultDepends() != null) {
@@ -768,4 +768,5 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public Map getProperties() {
return (Map) prop

[yocto] [PATCH v3 0/5][eclipse-poky][branch:windows-build]Multiple fixes

2013-01-15 Thread Ioana Grigoropol

- applies onto commit  5a27bb1f9e45f0a9408453f9e7e70cc333b97afe (windows-build 
HEAD)

Ioana Grigoropol (5):
  Fix variables hoover & remote file system detection
  Allow '-' in project names
  Reinstate OEFileSystem, OEFile and Ignored Paths for Linux
  Disable "Finish" when project location is invalid
  Send output from bitbake environment parsing in the background

 plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF   |2 +-
 plugins/org.yocto.bc.ui/plugin.xml |3 +-
 .../src/org/yocto/bc/bitbake/BBSession.java|   91 -
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   24 ++--
 .../src/org/yocto/bc/bitbake/ShellSession.java |   14 +-
 .../org/yocto/bc/remote/utils/RemoteHelper.java|   10 +-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |   25 ++--
 .../remote/utils/YoctoHostShellProcessAdapter.java |   14 +-
 .../src/org/yocto/bc/ui/Activator.java |   45 --
 .../org/yocto/bc/ui/BCResourceChangeListener.java  |1 -
 .../bc/ui/editors/bitbake/BBVariableTextHover.java |   12 +-
 .../src/org/yocto/bc/ui/filesystem/OEFile.java |  143 ++--
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   52 ---
 .../bc/ui/filesystem/OEFileSystemContributor.java  |7 +-
 .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java   |   31 -
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   21 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |  110 ---
 .../yocto/bc/ui/wizards/FiniteStateWizardPage.java |   54 
 .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java  |   58 
 .../ui/wizards/NewBitBakeFileRecipeWizardPage.java |5 +-
 .../yocto/bc/ui/wizards/install/InstallWizard.java |   63 +
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |   11 +-
 .../BBConfigurationInitializeOperation.java|2 +
 .../newproject/CreateBBCProjectOperation.java  |   23 ++--
 24 files changed, 494 insertions(+), 327 deletions(-)

-- 
1.7.9.5

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

[yocto] [PATCH v3 1/5] Fix variables hoover & remote file system detection

2013-01-15 Thread Ioana Grigoropol

- initialize bitbake session for recipe:
- when starting a new project, the session environment variables are 
obtained by calling "bitbake -e"
- when a new recipe is created and edited, the session variables should 
be updated with the values obtained from "bitbake -e -b package" => overwrite 
the session with the new one
- if we try to retrive a "remote" file (local file system, remote host) using 
RSE protocol before the system is initialized, null will be returned causing 
every remote operation to fail:
- add exception handling
- make sure that the "remote" FileSystem gets initialized, as well as 
the project connection

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/BBSession.java|4 
 .../src/org/yocto/bc/bitbake/ShellSession.java |   13 -
 .../org/yocto/bc/remote/utils/RemoteHelper.java|7 ++-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |8 +---
 .../bc/ui/editors/bitbake/BBVariableTextHover.java |   12 +---
 5 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 3aa4efe..66a6083 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -746,4 +746,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
wlock.unlock();
}
}
+
+   public Map getProperties() {
+   return (Map) properties;
+   }
 }
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 c127c25..38e2557 100644
--- 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
@@ -86,8 +86,12 @@ public class ShellSession {
 
private void initializeShell(IProgressMonitor monitor) throws 
IOException {
try {
-   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""));
-   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand(exportCmd, root.getAbsolutePath(), ""));
+   if (root != null) {
+   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""));
+   
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand(exportCmd, root.getAbsolutePath(), ""));
+   } else {
+   throw new Exception("Root file not found!");
+   }
} catch (Exception e) {
e.printStackTrace();
}
@@ -103,9 +107,8 @@ public class ShellSession {
 
try {
if (projectInfo.getConnection() != null) {
-   IHost connection = 
RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
-   hasErrors = 
RemoteHelper.runCommandRemote(connection, new YoctoCommand(command, 
root.getAbsolutePath() + "/build/", ""));
-   return 
RemoteHelper.getProcessBuffer(connection).getMergedOutputLines();
+   hasErrors = 
RemoteHelper.runCommandRemote(projectInfo.getConnection(), new 
YoctoCommand(command, root.getAbsolutePath() + "/build/", ""));
+   return 
RemoteHelper.getProcessBuffer(projectInfo.getConnection()).getMergedOutputLines();
}
return null;
} catch (Exception e) {
diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
index c230fd6..e511e06 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
@@ -99,7 +99,11 @@ public class RemoteHelper {
if (host == null) {
// this is a local connection
ISystemRegistry sr = 
RSECorePlugin.getTheSystemRegistry();
-   return sr.getLocalHost();
+   IHost local = null;
+   while (local == null) {
+   local = sr.getLocalHost();
+   }
+   return local;
}
ISystemRegistry sr = RSECorePlugin.getTheSystemRegistry();
IHost[] connections = sr.getHosts();
@@ -237,6 +241,7 @@ public class RemoteHelper

[yocto] [PATCH v3 2/5] Allow '-' in project names

2013-01-15 Thread Ioana Grigoropol

Signed-off-by: Ioana Grigoropol 
---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index 72aeec2..97d1ad0 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
@@ -313,7 +313,7 @@ public class OptionsPage extends FiniteStateWizardPage {
if (!Character.isJavaIdentifierStart(chars[0]))
return false;
for (int i = 1; i < chars.length; i++)
-   if (!Character.isJavaIdentifierPart(chars[i]))
+   if (!Character.isJavaIdentifierPart(chars[i]) && 
chars[i] != '-')
return false;
return true;
}
-- 
1.7.9.5

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

[yocto] [PATCH v3 4/5] Disable "Finish" when project location is invalid

2013-01-15 Thread Ioana Grigoropol

- when Bitbake project location is invalid, an error should be displayed and 
"finish" button disabled

Signed-off-by: Ioana Grigoropol 
---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index a103d2b..7a705aa 100644
--- 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
@@ -88,8 +88,13 @@ public class OptionsPage extends FiniteStateWizardPage {
@Override
public void reportError(String errorMessage, boolean 
infoOnly) {
setMessage(errorMessage);
-   validatePage();
-   updateModel();
+   if (validatePage()) {
+   updateModel();
+   setPageComplete(true);
+   return;
+   }
+
+   setPageComplete(false);
}
};
 
@@ -181,7 +186,6 @@ public class OptionsPage extends FiniteStateWizardPage {
setErrorMessage("A project with the 
name " + projName + " already exists");
return false;
}
-   //FIXME : do not throw exception when illegal 
characters show in URI ->show error on page
URI location = new URI("file:" + URI_SEPARATOR 
+ URI_SEPARATOR + convertToRealPath(projectLoc) + URI_SEPARATOR + 
txtProjectName.getText());
 
IStatus status = 
ResourcesPlugin.getWorkspace().validateProjectLocationURI(proj, location);
-- 
1.7.9.5

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

[yocto] [PATCH v3 3/5] Reinstate OEFileSystem, OEFile and Ignored Paths for Linux

2013-01-15 Thread Ioana Grigoropol

- OEFileSystem and OEFile were dropped due to the use of hardcoded scheme 
"oefs://" that stopped remote connection from working. There is a need to have 
a custom file system in order to skip indexing large directories (such as 
build, tmp) and ignore some paths--was not tested under Windows

Signed-off-by: Ioana Grigoropol 
---
 plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF   |2 +-
 plugins/org.yocto.bc.ui/plugin.xml |3 +-
 .../src/org/yocto/bc/bitbake/BBSession.java|   62 ++---
 .../org/yocto/bc/bitbake/ProjectInfoHelper.java|   24 ++--
 .../src/org/yocto/bc/ui/Activator.java |   45 --
 .../org/yocto/bc/ui/BCResourceChangeListener.java  |1 -
 .../src/org/yocto/bc/ui/filesystem/OEFile.java |  143 ++--
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   50 +--
 .../bc/ui/filesystem/OEFileSystemContributor.java  |7 +-
 .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java   |   31 -
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   21 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |  110 ---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |2 +-
 .../newproject/CreateBBCProjectOperation.java  |   23 ++--
 14 files changed, 318 insertions(+), 206 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF 
b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
index 9e8c523..1f0e63e 100644
--- a/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Bundle-Name
 Bundle-SymbolicName: org.yocto.bc.ui;singleton:=true
-Bundle-Version: 1.4.0.qualifier
+Bundle-Version: 1.2.0.qualifier
 Bundle-Activator: org.yocto.bc.ui.Activator
 Bundle-Vendor: %Bundle-Vendor
 Require-Bundle: org.eclipse.ui,
diff --git a/plugins/org.yocto.bc.ui/plugin.xml 
b/plugins/org.yocto.bc.ui/plugin.xml
index cb0561c..6ba9b5f 100644
--- a/plugins/org.yocto.bc.ui/plugin.xml
+++ b/plugins/org.yocto.bc.ui/plugin.xml
@@ -180,8 +180,7 @@


-  
+  
  
  
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 66a6083..037d8aa 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -48,7 +48,7 @@ import org.yocto.bc.ui.model.ProjectInfo;
 /**
  * BBSession encapsulates a global bitbake configuration and is the primary 
interface
  * for actions against a BitBake installation.
- * 
+ *
  * @author kgilmer
  *
  */
@@ -57,10 +57,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public static final int TYPE_UNKNOWN = 2;
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
-   
+
+   public static final String CONF_DIR = "/conf";
public static final String BUILDDIR_INDICATORS [] = {
-   "/conf/local.conf",
-   "/conf/bblayers.conf",
+   "/local.conf",
+   "/bblayers.conf",
};
 
protected final ProjectInfo pinfo;
@@ -74,7 +75,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
private final Lock wlock = rwlock.writeLock();
protected String parsingCmd;
private boolean silent = false;
-   
+
public BBSession(ShellSession ssession, URI projectRoot) throws 
IOException {
shell = ssession;
this.pinfo = new ProjectInfo();
@@ -87,7 +88,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
this(ssession, projectRoot);
this.silent = silent;
}
-   
+
private Collection adapttoIPath(List asList, IProject project) {
 
List pathList = new ArrayList();
@@ -102,7 +103,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return pathList;
}
-   
+
private String appendAll(String[] elems, int st) {
StringBuffer sb = new StringBuffer();
 
@@ -112,7 +113,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return sb.toString();
}
-   
+
private int charCount(String trimmed, char c) {
int i = 0;
int p = 0;
@@ -124,11 +125,13 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
 
return i;
}
-   
+
+   @Override
public void clear() {
throw new RuntimeException("BB configuration is read-only.");
}
 
+   @Override
public boolean containsKey(Object arg0) {
try {
checkValidAndLock(true);
@@ -141,6 +144,7 @@ public class BBSession implements IB

[yocto] [PATCH v3 5/5] Send output from bitbake environment parsing in the background

2013-01-15 Thread Ioana Grigoropol

- after creating the project, the wizard should not block waiting for the 
environment to be populated and instead should be ran in the background

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/BBSession.java|   27 +
 .../src/org/yocto/bc/bitbake/ShellSession.java |3 +-
 .../org/yocto/bc/remote/utils/RemoteHelper.java|3 +-
 .../org/yocto/bc/remote/utils/RemoteMachine.java   |   23 +++
 .../remote/utils/YoctoHostShellProcessAdapter.java |   14 -
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   14 ++---
 .../yocto/bc/ui/wizards/FiniteStateWizardPage.java |   54 +
 .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java  |   58 +-
 .../ui/wizards/NewBitBakeFileRecipeWizardPage.java |5 +-
 .../yocto/bc/ui/wizards/install/InstallWizard.java |   63 +---
 .../yocto/bc/ui/wizards/install/OptionsPage.java   |1 +
 .../BBConfigurationInitializeOperation.java|2 +
 12 files changed, 149 insertions(+), 118 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index 037d8aa..9adeb3f 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -13,8 +13,8 @@ package org.yocto.bc.bitbake;
 import java.io.BufferedReader;
 import java.io.File;
 import java.io.FileFilter;
+import java.io.FileReader;
 import java.io.IOException;
-import java.io.StringReader;
 import java.net.URI;
 import java.util.ArrayList;
 import java.util.Arrays;
@@ -58,6 +58,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
 
+   public static final String BB_ENV_FILE = "bitbake.env";
+
public static final String CONF_DIR = "/conf";
public static final String BUILDDIR_INDICATORS [] = {
"/local.conf",
@@ -81,7 +83,7 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
this.pinfo = new ProjectInfo();
pinfo.setLocation(projectRoot);

pinfo.setInitScriptPath(ProjectInfoHelper.getInitScriptPath(projectRoot));
-   this.parsingCmd = "DISABLE_SANITY_CHECKS=\"1\" bitbake -e";
+   this.parsingCmd = "sh -c 'DISABLE_SANITY_CHECKS=\"1\" bitbake 
-e >& " + BB_ENV_FILE + "  '" ;
}
 
public BBSession(ShellSession ssession, URI projectRoot, boolean 
silent) throws IOException {
@@ -387,11 +389,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
if(!initialized) { //recheck
boolean hasErrors = false;
String result = 
shell.execute(parsingCmd, hasErrors);
-   if(!hasErrors) {
-   properties = 
parseBBEnvironment(result);
-   } else {
-   properties = 
parseBBEnvironment("");
-   }
+
+   //FIXME : wait for bitbake to finish
+
+   properties = parseBBEnvironment(result);
+
initialized = true;
}
} finally {
@@ -450,10 +452,8 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
}
}
 
-   protected void parse(String content, Map outMap) throws Exception {
-   if (content == null)
-   return;
-   BufferedReader reader = new BufferedReader(new 
StringReader(content));
+   protected void parse(String bbOutfilePath, Map outMap) throws Exception 
{
+   BufferedReader reader = new BufferedReader(new 
FileReader(bbOutfilePath + BB_ENV_FILE));
String line;
boolean inLine = false;
StringBuffer sb = null;
@@ -520,11 +520,11 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
return null;
}
 
-   protected Map parseBBEnvironment(String bbOut) throws Exception {
+   protected Map parseBBEnvironment(String bbOutFilePath) throws Exception 
{
Map env = new Hashtable();
this.depends = new ArrayList();
 
-   parse(bbOut, env);
+   parse(bbOutFilePath, env);
 
String included = (String) env.get("BBINCLUDED");
if(getDefaultDepends() != null) {
@@ -768,4 +768,5 @@ public class BBSession implements IBBSessionListener, 
IModelElement, Map {
public Map getProperties() {
return (Map) prop

[yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Patrick Turley

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Here's an interesting line from the environment setup script:

export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

All these linker options are preceded by "-Wl", which indicates the SDK is
*expecting* them to be given to gcc and then passed on to ld.

If you look at the help for the ld command line, all these options are
available, but with the "-Wl," omitted. In fact, if you use these options
exactly as shown here, ld will complain that they aren't recognized and fail.

So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of
course, the C compiler driver can link and produce executables, and that
muddies the issue somewhat.

Here's an example where this is causing me real problems…

I'm building an external module against the kernel produced by Yocto. Here's an
extract from my output:

make -C
/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git
M=`pwd` ARCH=arm
CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
\
EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
.
.
.
LD [M]
/home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
unrecognized option '-Wl,-O1'

As you can see here, the kernel Make files are interpreting LDFLAGS as
something that *can* be given directly to ld, so they fail.

My questions are:

1) Has anyone else run into this before?

2) If so, how did you resolve it?

3) Since the Yocto kernel build is *not* failing, I infer that it is *not*
using the ld options the SDK gives me. So, the Yocto kernel build has its own
pathway through which it computes its value for LDFLAGS. Why would Yocto use
its own SDK in a way that no user is expected to?

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

[yocto] [PATCH] [Bug #3963][eclipse-poky][branch:denzil]

2013-01-15 Thread Ioana Grigoropol

- source oe-init-build-env each time a command is ran using yocto-bsp tool

Signed-off-by: Ioana Grigoropol 
---
 .../sdk/remotetools/wizards/bsp/MainPage.java  |   86 ++--
 .../remotetools/wizards/bsp/PropertiesPage.java|   16 ++--
 2 files changed, 89 insertions(+), 13 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index aa1c124..f7dea27 100644
--- 
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++ 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
@@ -56,6 +56,7 @@ public class MainPage extends WizardPage {
private static final String PROPERTIES_CMD_PREFIX = "yocto-bsp list ";
private static final String PROPERTIES_CMD_SURFIX = " properties -o ";
private static final String PROPERTIES_FILE = "/tmp/properties.json";
+   static final String INIT_FILE = "/oe-init-build-env";
 
private Button btnMetadataLoc;
private Button btnBspOutLoc;
@@ -287,8 +288,18 @@ public class MainPage extends WizardPage {
}

bspElem.setBspName(bspname);
+// if (!textBspOutLoc.getText().isEmpty())
+// bspElem.setBspOutLoc(textBspOutLoc.getText());
if (!textBspOutLoc.getText().isEmpty())
bspElem.setBspOutLoc(textBspOutLoc.getText());
+   else
+   bspElem.setBspOutLoc("");
+   if (!textBspOutLoc.getText().isEmpty())
+   bspElem.setBuildLoc(textBspOutLoc.getText());
+   else {
+   bspElem.setBuildLoc(metadata_loc + "/build");
+   checkBuildDir();
+   }
bspElem.setMetadataLoc(metadata_loc);
bspElem.setKarch(karch);
bspElem.setQarch(qarch);
@@ -296,6 +307,53 @@ public class MainPage extends WizardPage {

return true;
}
+   private Status createBuildDir(String buildLoc) {
+   String metadataDir = textMetadataLoc.getText();
+
+   // if we do  not change the directory to metadata location the 
script will be looked into the directory indicated by user.dir system property
+   // system.property usually points to the location from where 
eclipse was started
+   String createBuildDirCmd = "cd " + metadataDir + ";source " + 
metadataDir + INIT_FILE + " " + buildLoc;
+
+   try {
+   ProcessBuilder builder = new ProcessBuilder(new 
String[] {"sh", "-c", createBuildDirCmd});
+   Process proc = builder.start();
+   InputStream errorStream = proc.getErrorStream();
+   InputStreamReader isr = new 
InputStreamReader(errorStream);
+   BufferedReader br = new BufferedReader(isr);
+   String line = null;
+   String status = "";
+   while ( (line = br.readLine()) != null) {
+   status += line;
+   }
+
+   if (proc.waitFor() != 0)
+   return new Status(IStatus.ERROR, "not_used", 0, 
status, null);;
+   return new Status(IStatus.OK, "not_used", 0, "", null);
+   } catch (Exception e) {
+   return  new Status(IStatus.ERROR, "not_used", 0, 
e.getMessage(), null);
+   }
+   }
+   private Status checkBuildDir() {
+
+   String metadataLoc = textMetadataLoc.getText();
+
+   String buildLoc = metadataLoc + "/build";
+   return createBuildDir(buildLoc);
+   }
+   private String getBuildDir() {
+
+   String metadataLoc = textMetadataLoc.getText();
+   String buildLoc = textBspOutLoc.getText();
+
+   if (buildLoc.isEmpty()) {
+   buildLoc = metadataLoc + "/build";
+   } 
+   File buildLocDir = new File(buildLoc);
+   if (!buildLocDir.exists()) {
+   createBuildDir(buildLoc);
+   }
+   return buildLoc;
+   }

private boolean createPropertiesFile() {
String create_properties_cmd = bspElem.getMetadataLoc() + 
"/scripts/" + 
@@ -319,14 +377,22 @@ public class MainPage extends WizardPage {
}
return true;
}
-   
+   private String getSourceCmd(){
+   String metadataLoc = textMetadataLoc.getText();
+   return "source " + metadataLoc + INIT_FILE + " " + 
getBuildDir() +" > temps; rm -rf temps;";
+   }
private ArrayList getKArches() {

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Brian Lloyd

Try this in work documentation and let us know how it helps or if there
is something missing that would help more:
http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules

I just did the exact same thing and was happy to discover there is
support in yocto for doing just this.

Brian

On Mon, 2013-01-14 at 23:27 +, Patrick Turley wrote:

> I have to build a module from a third-party that has nothing to do with Yocto.
> 
> I want to build this module against the kernel Yocto is giving me.
> 
> The Make file for this module has a build command like this:
> 
> make -C $(LINUX_DIR) M=`pwd` $(ENV) \
> EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules
> 
> Obviously, this command needs to connect with either the Linux source tree or 
> something like a "kernel-headers" package.
> 
> I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. 
> Unfortunately, I don't see a "kernel-header" equivalent in there.
> 
> This leads me to imagine I must point this command at some sub-tree within 
> the Yocto output (probably under tmp/sysroots). And, if I want that tree 
> available elsewhere, I have to package it up into a tarball and transport it.
> 
> Usually, Yocto is way ahead of me on these sorts of things, and there's 
> already a graceful way to deal with this -- I just haven't figure it out yet.
> 
> What am I missing?
> 
> ___
> 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] Build external module against Yocto kernel

2013-01-15 Thread Brian Lloyd

Or better yet, now that it is past initial, use
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.
  :)
It worked fine for 1.2 (denzil) for me, though it is written for a later
one.

Brian

On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:

> Try this in work documentation and let us know how it helps or if
> there is something missing that would help more:
> http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
> 
> I just did the exact same thing and was happy to discover there is
> support in yocto for doing just this.
> 
> Brian
> 
> On Mon, 2013-01-14 at 23:27 +, Patrick Turley wrote: 
> 
> > I have to build a module from a third-party that has nothing to do with 
> > Yocto.
> > 
> > I want to build this module against the kernel Yocto is giving me.
> > 
> > The Make file for this module has a build command like this:
> > 
> > make -C $(LINUX_DIR) M=`pwd` $(ENV) \
> > EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules
> > 
> > Obviously, this command needs to connect with either the Linux source tree 
> > or something like a "kernel-headers" package.
> > 
> > I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. 
> > Unfortunately, I don't see a "kernel-header" equivalent in there.
> > 
> > This leads me to imagine I must point this command at some sub-tree within 
> > the Yocto output (probably under tmp/sysroots). And, if I want that tree 
> > available elsewhere, I have to package it up into a tarball and transport 
> > it.
> > 
> > Usually, Yocto is way ahead of me on these sorts of things, and there's 
> > already a graceful way to deal with this -- I just haven't figure it out 
> > yet.
> > 
> > What am I missing?
> > 
> > ___
> > 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Eric Bénard

Hi Patrick,

Le Tue, 15 Jan 2013 16:52:14 +,
Patrick Turley  a écrit :
> 1) Has anyone else run into this before?
> 
> 2) If so, how did you resolve it?
> 
> 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* 
> using the ld options the SDK gives me. So, the Yocto kernel build has its own 
> pathway through which it computes its value for LDFLAGS. Why would Yocto use 
> its own SDK in a way that no user is expected to?
> 
to build a kernel using the SDK (so outside Yocto) you need to unset
LDFLAGS like :
LDFLAGS="" CROSS_COMPILE=arm-oe-linux-gnueabi- ARCH=arm make

When building the kernel inside oe-core that's done in
kernel.bbclass :
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE

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

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Brian Lloyd

The kernel is a special case, where the SDK is really designed for
developing user applications (which the kernel is not).

I found it pretty easy to create a kernel-module-MYMODULE.bbclass file
and build the kernel and module in the OE/Poky build system directly,
and then have it included in the image made for the device.

See
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
 for details.

Brian

On Tue, 2013-01-15 at 16:52 +, Patrick Turley wrote:

> I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. 
> Here's an interesting line from the environment setup script:
> 
>   export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
> 
> All these linker options are preceded by "-Wl", which indicates the SDK is 
> *expecting* them to be given to gcc and then passed on to ld.
> 
> If you look at the help for the ld command line, all these options are 
> available, but with the "-Wl," omitted. In fact, if you use these options 
> exactly as shown here, ld will complain that they aren't recognized and fail.
> 
> So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of 
> course, the C compiler driver can link and produce executables, and that 
> muddies the issue somewhat.
> 
> Here's an example where this is causing me real problems…
> 
> I'm building an external module against the kernel produced by Yocto. Here's 
> an extract from my output:
> 
> 
> make -C 
> /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git
>  M=`pwd` ARCH=arm 
> CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
>  \
> EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
> .
> .
> .
>   LD [M]  
> /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
> /opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld:
>  unrecognized option '-Wl,-O1'
> 
> 
> As you can see here, the kernel Make files are interpreting LDFLAGS as 
> something that *can* be given directly to ld, so they fail.
> 
> 
> My questions are:
> 
> 1) Has anyone else run into this before?
> 
> 2) If so, how did you resolve it?
> 
> 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* 
> using the ld options the SDK gives me. So, the Yocto kernel build has its own 
> pathway through which it computes its value for LDFLAGS. Why would Yocto use 
> its own SDK in a way that no user is expected to?
> 
> ___
> 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] Build external module against Yocto kernel

2013-01-15 Thread Patrick Turley

Thank you for directing me toward that documentation. As it happens, I have
already read that, and it doesn't apply.

The section you mentioned begins with this text:

While it is always preferable to work with sources integrated into the Linux
kernel sources, if you need an external kernel module, the hello-mod.bb recipe
is available as a template from which you can create your own out-of-tree Linux
kernel module recipe.

The approach here is to create a recipe that will build a module outside the
kernel tree, but still within the Yocto system.

That isn't what I'm doing.

I have source code for a kernel module that is entirely outside Yocto. I'm
*not* going to write a recipe for this module and integrate it into a Yocto
layer.

Here's a link to instructions on how I would do this in Ubuntu:

http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html

As you can see, Ubuntu (and, of course, other major distributions) have
"kernel-headers" packages that carry all the artifacts one needs to build a
module "after the fact."

Does Yocto have a mechanism for packaging up the necessary artifacts and making
them available *outside* the Yocto build system and long *after* the Yocto
build is finished? Does Yocto recognize the necessity of this? The best I've
been able to do is point my module build process at something like this:

LINUX_DIR=/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

This works but it's messy, unreliable and inconvenient.

So, my question remains: Does Yocto have a graceful way of dealing with this
situation, perhaps like Ubuntu and friends?

On Jan 15, 2013, at 11:09 AM, Brian Lloyd
mailto:bll...@familyhonor.net>> wrote:

Or better yet, now that it is past initial, use
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.

:)
It worked fine for 1.2 (denzil) for me, though it is written for a later one.

Brian

On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:
Try this in work documentation and let us know how it helps or if there is
something missing that would help more:
http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules

I just did the exact same thing and was happy to discover there is support in
yocto for doing just this.

Brian

On Mon, 2013-01-14 at 23:27 +, Patrick Turley wrote:

I have to build a module from a third-party that has nothing to do with Yocto.

I want to build this module against the kernel Yocto is giving me.

The Make file for this module has a build command like this:

make -C $(LINUX_DIR) M=`pwd` $(ENV) \
EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules

Obviously, this command needs to connect with either the Linux source tree or
something like a "kernel-headers" package.

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Unfortunately, I don't see a "kernel-header" equivalent in there.

This leads me to imagine I must point this command at some sub-tree within the
Yocto output (probably under tmp/sysroots). And, if I want that tree available
elsewhere, I have to package it up into a tarball and transport it.

Usually, Yocto is way ahead of me on these sorts of things, and there's already
a graceful way to deal with this -- I just haven't figure it out yet.

What am I missing?

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

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Patrick Turley

On Jan 15, 2013, at 11:38 AM, Brian Lloyd
mailto:bll...@familyhonor.net>>
wrote:

The kernel is a special case, where the SDK is really designed for developing
user applications (which the kernel is not).

Yes, it's clear to me that, in this one respect, the SDK is unsuitable for
building kernels or kernel modules.

My point is that this is a problem, and it might be reasonable to fix it.

I found it pretty easy to create a kernel-module-MYMODULE.bbclass file and
build the kernel and module in the OE/Poky build system directly, and then have
it included in the image made for the device.

See
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
for details.

Thanks for pointing me at that. As it happens, I can't use that method because
I'm not going to create a recipe.

Brian

On Tue, 2013-01-15 at 16:52 +, Patrick Turley wrote:

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Here's an interesting line from the environment setup script:

export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

All these linker options are preceded by "-Wl", which indicates the SDK is
*expecting* them to be given to gcc and then passed on to ld.

So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of
course, the C compiler driver can link and produce executables, and that
muddies the issue somewhat.

Here's an example where this is causing me real problems…

I'm building an external module against the kernel produced by Yocto. Here's an
extract from my output:

As you can see here, the kernel Make files are interpreting LDFLAGS as
something that *can* be given directly to ld, so they fail.

My questions are:

1) Has anyone else run into this before?

2) If so, how did you resolve it?

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

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Bruce Ashfield

On 13-01-15 12:54 PM, Patrick Turley wrote:

Thank you for directing me toward that documentation. As it happens, I
have already read that, and it doesn't apply.

The section you mentioned begins with this text:

While it is always preferable to work with sources integrated into
the Linux kernel sources, if you need an external kernel module, the
|hello-mod.bb| recipe is available as a template from which you can
create your own out-of-tree Linux kernel module recipe.

The approach here is to create a recipe that will build a module outside
the kernel tree, but still within the Yocto system.

That isn't what I'm doing.

I have source code for a kernel module that is entirely outside Yocto.
I'm *not* going to write a recipe for this module and integrate it
into a Yocto layer.

Here's a link to instructions on how I would do this in Ubuntu:

http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html

As you can see, Ubuntu (and, of course, other major distributions) have
"kernel-headers" packages that carry all the artifacts one needs to
build a module "after the fact."

Does Yocto have a mechanism for packaging up the necessary artifacts and
making them available *outside* the Yocto build system and long *after*
the Yocto build is finished? Does Yocto recognize the necessity of
this? The best I've been able to do is point my module build process at
something like this:

LINUX_DIR=/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

This works but it's messy, unreliable and inconvenient.

So, my question remains: Does Yocto have a graceful way of dealing with
this situation, perhaps like Ubuntu and friends?

There are ways to do this, your requirement is the same as the on-target
module building requirement. Have enough of the kernel source packaged
to build modules on the target, after it has booted.

The trick is packaging things properly to not get binary/target elements
in the SDK/native packages, and to package just enough for the build. But
the issues have been explored and there was a plan. I know that Darren
(cc'd) has looked into this more than I have recently.

I can't locate the bugzilla entries on this at the moment, but I recall
that some parts were still missing, but may be addressed in yocto 1.4,
when I find the bug numbers, I'll have a better idea.

Cheers,

Bruce

On Jan 15, 2013, at 11:09 AM, Brian Lloyd mailto:bll...@familyhonor.net>> wrote:

Or better yet, now that it is past initial, use
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules.

:)
It worked fine for 1.2 (denzil) for me, though it is written for a
later one.

Brian

On Tue, 2013-01-15 at 11:07 -0600, Brian Lloyd wrote:

Try this in work documentation and let us know how it helps or if
there is something missing that would help more:
http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules

I just did the exact same thing and was happy to discover there is
support in yocto for doing just this.

Brian

On Mon, 2013-01-14 at 23:27 +, Patrick Turley wrote:

I have to build a module from a third-party that has nothing to do with Yocto.

I want to build this module against the kernel Yocto is giving me.

The Make file for this module has a build command like this:

make -C $(LINUX_DIR) M=`pwd` $(ENV) \
EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules

Obviously, this command needs to connect with either the Linux source tree or something
like a "kernel-headers" package.

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Unfortunately, I don't see a "kernel-header" equivalent in there.

Usually, Yocto is way ahead of me on these sorts of things, and there's already
a graceful way to deal with this -- I just haven't figure it out yet.

What am I missing?

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

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Bruce Ashfield

On 13-01-15 12:59 PM, Patrick Turley wrote:

On Jan 15, 2013, at 11:38 AM, Brian Lloyd mailto:bll...@familyhonor.net>>
wrote:

The kernel is a special case, where the SDK is really designed for
developing user applications (which the kernel is not).

Yes, it's clear to me that, in this one respect, the SDK is unsuitable
for building kernels or kernel modules.

My point is that this is a problem, and it might be reasonable to fix it.

You probably want Jessica or Richard to comment on the architecture /
design of the SDK with respect to kernel elements. The only packaging
for out of tree / non build system builds that I know I've ever looked
into are on target, or staging directory builds of modules.

I found it pretty easy to create a kernel-module-MYMODULE.bbclass file
and build the kernel and module in the OE/Poky build system directly,
and then have it included in the image made for the device.

See
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
for details.

Thanks for pointing me at that. As it happens, I can't use that method
because I'm not going to create a recipe.

Everyone/Everything has their reasons for the different workflow(s).
(I maintain the ability to build all the boards covered in linux-yocto
without the need for any build system at all, as an example). And all
workflows are definitely valid, but it is expected that the primary
workflow for anything oe/bitbake based would be centered around recipes.

Cheers,

Bruce

Brian

On Tue, 2013-01-15 at 16:52 +, Patrick Turley wrote:

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it.
Here's an interesting line from the environment setup script:

export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

All these linker options are preceded by "-Wl", which indicates the SDK is
*expecting* them to be given to gcc and then passed on to ld.

If you look at the help for the ld command line, all these options are available, but
with the "-Wl," omitted. In fact, if you use these options exactly as shown
here, ld will complain that they aren't recognized and fail.

So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of
course, the C compiler driver can link and produce executables, and that
muddies the issue somewhat.

Here's an example where this is causing me real problems…

I'm building an external module against the kernel produced by Yocto. Here's an
extract from my output:

As you can see here, the kernel Make files are interpreting LDFLAGS as
something that *can* be given directly to ld, so they fail.

My questions are:

1) Has anyone else run into this before?

2) If so, how did you resolve it?

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

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Eric Bénard

Le Tue, 15 Jan 2013 17:59:10 +,
Patrick Turley  a écrit :
> Yes, it's clear to me that, in this one respect, the SDK is unsuitable for 
> building kernels or kernel modules.
> 
> My point is that this is a problem, and it might be reasonable to fix it.
> 
set LDFLAGS="" and you can build kernel and/or modules with the SDK.

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

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Patrick Turley

On Jan 15, 2013, at 12:00 PM, Bruce Ashfield 
 wrote:

> On 13-01-15 12:54 PM, Patrick Turley wrote:
>> Thank you for directing me toward that documentation. As it happens, I
>> have already read that, and it doesn't apply.
> 
> There are ways to do this, your requirement is the same as the on-target
> module building requirement. Have enough of the kernel source packaged
> to build modules on the target, after it has booted.

Well, I still want to cross-compile them, but I see your point.

> The trick is packaging things properly to not get binary/target elements
> in the SDK/native packages, and to package just enough for the build. But
> the issues have been explored and there was a plan. I know that Darren
> (cc'd) has looked into this more than I have recently.
> 
> I can't locate the bugzilla entries on this at the moment, but I recall
> that some parts were still missing, but may be addressed in yocto 1.4,
> when I find the bug numbers, I'll have a better idea.

As I expected, someone else has already thought about this. This isn't the most 
common approach so it makes sense that it's been a lower priority. The good 
news for me is that I know I'm not missing something, so I can stop looking for 
it.

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

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Bruce Ashfield


On 13-01-15 01:26 PM, Patrick Turley wrote:

On Jan 15, 2013, at 12:00 PM, Bruce Ashfield 
  wrote:


On 13-01-15 12:54 PM, Patrick Turley wrote:

Thank you for directing me toward that documentation. As it happens, I
have already read that, and it doesn't apply.


There are ways to do this, your requirement is the same as the on-target
module building requirement. Have enough of the kernel source packaged
to build modules on the target, after it has booted.


Well, I still want to cross-compile them, but I see your point.


The trick is packaging things properly to not get binary/target elements
in the SDK/native packages, and to package just enough for the build. But
the issues have been explored and there was a plan. I know that Darren
(cc'd) has looked into this more than I have recently.

I can't locate the bugzilla entries on this at the moment, but I recall
that some parts were still missing, but may be addressed in yocto 1.4,
when I find the bug numbers, I'll have a better idea.


As I expected, someone else has already thought about this. This isn't the most 
common approach so it makes sense that it's been a lower priority. The good 
news for me is that I know I'm not missing something, so I can stop looking for 
it.


I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)

Cheers,

Bruce






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

Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

2013-01-15 Thread Autif Khan

On Thu, Jan 3, 2013 at 10:45 AM, Alex J Lennon
 wrote:
> On 03/01/2013 15:24, Autif Khan wrote:
>> On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
>>  wrote:
>>> On 02/01/2013 20:27, Autif Khan wrote:
 On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan  wrote:
> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>  wrote:
>> Hi all, Autif,
>>
>> I've been working to support .NET development on Linux
>> over the past few days.
>>
>> There is a Visual Studio plugin, MonoTools for Visual Studio
>> which provides support for local and remote debugging of
>> .NET applications with Mono.
>>
>> This requires a remote stub to be running on the target
>> platform, monotools-server.
>>
>> I've created a recipe to build monotools-server, which in
>> turn required me to pull in Openembedded Legacy recipes
>> for mono-xsp and gtk-sharp.
>>
>> As it stands I'm now able to build an X enabled image for
>> the Raspberry Pi and remote-debug some simple Windows
>> Forms .NET applications within the Visual Studio IDE.
>>
>> Recipes are hosted here in 'recipes-mono'
>>
>> g...@git.assembla.com:ciseco-eve.meta-eve.git

 I could not "git clone" the repo.
>>>
>>> Apologies. I should have given you the public r/o link.
>>>
>>> Originally I was trying to avoid modifying meta-mono, adding .bbappends
>>> into my own meta-eve layer instead, but since my last post to you I
>>> found I couldn't build against the current HEAD of Yocto due to some odd
>>> file location issues which I couldn't overlay. (i.e. it didn't seem to
>>> be able to pick up the patches where you had them - although was fine
>>> with an older commit of the Yocto core).
>>>
>>> As a result I've moved the original meta-mono patches that weren't being
>>> picked up by bitbake and merged my additions into a fork of meta-mono
>>> which is here:
>>>
>>> git://git.assembla.com/ciseco-eve.meta-mono.git
>>
>> Got it.
>>
>> I scanned thru the code and saw what you did to re-organize the
>> directory structure.
>>
>> When I get back, I will see if I can build libGDI+ and mono with
>> denzil (I am stuck with denzil for reasons beyond my control, or until
>> I find a show stopping bug in denzil for our project - unlikely)
>>
>> Meanwhile, I have no questions about changes for gk-sharp, mono,
>> mono-xsp and monotools-server.
>>
>
> Good oh.
>
>> Presumably, you will take care of the "TODO: This needs fixing
>> properly and needs to be revisited" in mono_.bb - I
>> definitely do not want unstripped binaries on my distribution -
>> presumably, this was needed for some debugging and is not meant to be
>> checked into production.
>
> Ah yes. I'd forgotten about that. I shall habe to revisit why that was
> erroring.
>
>> I could not understand the purpose of
>> libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
>> could you please help me understand what prompted these seemingly non
>> trivial changes.
>>
>
> Yes there seems to be a problem building libGDI against libpng15. It
> seems a known issue:
>
> https://github.com/mono/libgdiplus/pull/4
>
>> Everything else looks good.
>>
>
> Good oh
>
>>> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
>>> Can I issue a "pull request" to you or some such?
>>
>> Yes, a pull request should work.
>>
 Presumably, you want to release the recipes with the MIT and/or GPLv2 
 licenses.

 If the license is different for monotools-server or mono-xsp or
 gtk-sharp, you will likely have to submit a patch for README file too.
 Even otherwise, section 4 in README needs to be updated. If you have
 any tasks left - please add them to section 10.

>>>
>>> Will double check this. I am waiting for feedback from the
>>> monotools-server people on their license as there's nothing explicit in
>>> their source.
>>
>> Will wait for that. Might affect the README
>>
>
> I'll give them another nudge once I've worked our what's going on with
> the stripping, commit to my fork and then try to work out how to send
> you a pull req.
>
 The guidelines for the Yocto project are very similar to other FOSS
 projects including the Linux kernel. They are outlined here:

 https://wiki.yoctoproject.org/wiki/Contribution_Guidelines

 I used the following as a guide when I have submitted my patches in
 the past. This is for the Linux kernel, adapt as appropriate for
 meta-mono.

 http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/

 Please submit separate patches for each of the recipes (presumably
 there are no changes to the mono/libGDI+ recipes)

 Please add me to the "To:" recipient (I filter a lot of PATCH related
 traffic) - this should allow the emails to be caught by the filter
 instead of archiving.

 In case I do not respond within 72 hours, please email me with a
 gentle remin

Re: [yocto] Build external module against Yocto kernel

2013-01-15 Thread Zhang, Jessica

Hi Patrick,

According to bug 1614, the kernel dev packages should be included in sdk 
images.  Please generate your toolchain using "bitbake core-image-sato-sdk -c 
populate_sdk" which will make the toolchain target sysroot matching your 
image's sysroot (this is a new feature of 1.3) as long as your image is a sdk 
image.  If you still run into issue(missing kernel headers, etc.), then that's 
a bug of the 1614 patch that we need to reopen it.

For your LDFLAGS question in another email thread, the yocto SDK is mainly 
produced for application developer, but seems we are hearing more usage request 
for it to support kernel module build as well.  As Eric pointed, can you just 
set LDFLAGS="" and we'll add that instruction to developer's manual?

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Bruce Ashfield
Sent: Tuesday, January 15, 2013 10:38 AM
To: Patrick Turley
Cc: yocto@yoctoproject.org; Darren Hart; Brian Lloyd
Subject: Re: [yocto] Build external module against Yocto kernel

On 13-01-15 01:26 PM, Patrick Turley wrote:
> On Jan 15, 2013, at 12:00 PM, Bruce Ashfield 
>   wrote:
>
>> On 13-01-15 12:54 PM, Patrick Turley wrote:
>>> Thank you for directing me toward that documentation. As it happens,
>>> I have already read that, and it doesn't apply.
>>
>> There are ways to do this, your requirement is the same as the
>> on-target module building requirement. Have enough of the kernel
>> source packaged to build modules on the target, after it has booted.
>
> Well, I still want to cross-compile them, but I see your point.
>
>> The trick is packaging things properly to not get binary/target
>> elements in the SDK/native packages, and to package just enough for
>> the build. But the issues have been explored and there was a plan. I
>> know that Darren
>> (cc'd) has looked into this more than I have recently.
>>
>> I can't locate the bugzilla entries on this at the moment, but I
>> recall that some parts were still missing, but may be addressed in
>> yocto 1.4, when I find the bug numbers, I'll have a better idea.
>
> As I expected, someone else has already thought about this. This isn't the 
> most common approach so it makes sense that it's been a lower priority. The 
> good news for me is that I know I'm not missing something, so I can stop 
> looking for it.

I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the right parts 
of the kernel tree in SDK packages, since they include dev packages, and with 
what is currently in kernel-dev .. it should be enough to build against in the 
SDK (perhaps with just the LDFLAGS tweaks mentioned in the other thread). The 
sources should be part of the sysroot, and hence available when that is 
packaged for use outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that 
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something else is 
different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100% familiar 
with the SDK, but perhaps Jessica or others can chime in if I've led you astray 
:)

Cheers,

Bruce

>

___
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] Minutes: Yocto Project Technical Team Meeting - Tuesday, January 15, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

2013-01-15 Thread Liu, Song

Attendees:
Ciby (Mentor), Jessica, Sean, MarkH, ChrisL, ChrisK, ScottG, TomZ, KevinS, 
ScottR, BruceA, Corneliu, Saul, Nitin, JeffP, DaveST, BjörnS, Song
 
Agenda:
 
-- Thanks to Saul for covering me while I was on vacation.
 
* Opens collection - 5 min (Song)
* Yocto Project 1.2.2 status - 10 min (Scott/AlexG)
  - ScottG:has gone through full pass QA testing. All the issues can be release 
noted. No blockers.
  - Song: listed all the know issues in the IRC channel. No Special concerns 
from the audience.
  - Saul: More patches from Koen (4), what can we do? Sean/Saul: Suggest to 
make them available, get them to the tip of the denzil branches. But Moving 
forward with the plan. Wrapping up 1.2.2. 
  - Song: QA complete, no concerns or blockers. Move ahead with 1.2.2 release. 
Song will send CCB email asking for approval.
 
* Yocto Project 1.3.1 status - 10 min :
  - Saul: patches are integrated. Ready for QA test. 
  - Song: QA will be done after 1.4 M2/M3 release. If anyone would like to 
suggest more patches, please let Ross (ross.bur...@intel.com) know.
  - 
* Yocto 1.4 status - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Overview 
 
  - Bug fixing: resolved 51 last week. Thanks to Otavio Salvador (4) from the 
community (Ossystems.com.br), ScottG (11). Good work and thank you all.
  - Feature development (M2/3 cutoff is this coming Sunday): 
. SMART updater/Mark: code is there and working, a couple of bugs, a couple 
of performance issues related to incremental install and complimentary install. 
Opening bugs to track them in Bugzilla. Other than those. Everything is working.
.systemd/Saul: patches pending, reworked a little bit. There are still some 
issues. Trying to get this done by the end of this week.
.wayland/Saul: 3 patches pending, dependency issues. Saul will touch base 
with Ross to get the status, hope to resolve this feature by the end of this 
week.
. LTSI (Bruce): still underway, pending. Cannot be done for M3.
. Song: QA is working on the test plan for the above features. Please 
expect working with QA. 
. Mater status/Saul: RP pulled in last set of consolidated patches. Hoping 
to have a weekly build, and then full QA. Build will be available sometime 
tomorrow (RO/PRC time).
 
* SWAT team rotation: Radu Moisan -> Constantin Musca 
 
* Opens - 10 min 
 - ChrisK: Design firm Tobias & Tobias are helping with the design of a web UI 
for analysing builds and images. They are looking for people willing to test & 
give feedback on an early-stage design prototype. Interviews will be conducted 
via phone or Skype and take about 30 minutes. 
. If you can participate, please email: chris.kamin...@tobias.tv
  - Bjorn: x-test and x-ptest. have been working on the ptest framework. A week 
ago, it was merged. But a different approache has been merged. It's better if 
we could have only one way.  
. Saul: this is an oversight. ptest should be the way. Will contact Kai 
Kang to sort this out.
. Bjorn has a wiki page for this framework: 
https://wiki.yoctoproject.org/wiki/Ptest
 
* Team Sharing - 20 min
 - ScottR: url: 
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html. People can go 
here to see the kernel development manual. Also sent an email to the yp mailing 
list. 
 - Corneliu: tesopia is in its final version. Is a new testcase management 
platform we are going to use from now on. Feel free to ask me if there is any 
questions: 
https://wiki.yoctoproject.org/wiki/Testopia. Will be adding SMART testcases 
today. Remove zypper testcases. All existing testcases are there.
- Michael: reinstall OS on AB 3/7/9. new OSes and better support. HW error 
happening and been corrected. Added webhob mailing list. Working on testopia 
integration. Had some slight changes and extra testing. Corneliu working with 
me. This week will continue. YP dev day assistant. More information and 
organization on the web site BSP page. 
  - Sean/ScottG/Saul: Yocto Dev day: small budget issue, plan still in the 
work. Will go ahead with the dev day, but likely no hands-on lab, will have 
small focus group discussions. Build system will be setup on individual laptop, 
etc.





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

[yocto] WebHob feedback on early design prototype

2013-01-15 Thread Liu, Song

Hi all,

This came up in today's technical team meeting (please see minutes). Design 
firm Tobias & Tobias are helping with the design of a web UI for analysing 
builds and images. They are looking for people willing to test & give feedback 
on an early-stage design prototype. Interviews will be conducted via phone or 
Skype and take about 30 minutes.

If you can participate, please email: 
chris.kamin...@tobias.tv. It will be very 
helpful to the project and most importantly to get your requirement/suggestion 
into the system earlier.

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

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, January 15, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

2013-01-15 Thread Liu, Song

Attendees:
Ciby (Mentor), Jessica, Sean, MarkH, ChrisL, ChrisK, ScottG, TomZ, KevinS, 
ScottR, BruceA, Corneliu, Saul, Nitin, JeffP, DaveST, BjörnS, Song
 
Agenda:
 
-- Thanks to Saul for covering me while I was on vacation.
 
* Opens collection - 5 min (Song)
* Yocto Project 1.2.2 status - 10 min (Scott/AlexG)
  - ScottG:has gone through full pass QA testing. All the issues can be release 
noted. No blockers.
  - Song: listed all the know issues in the IRC channel. No Special concerns 
from the audience.
  - Saul: More patches from Koen (4), what can we do? Sean/Saul: Suggest to 
make them available, get them to the tip of the denzil branches. But Moving 
forward with the plan. Wrapping up 1.2.2. 
  - Song: QA complete, no concerns or blockers. Move ahead with 1.2.2 release. 
Song will send CCB email asking for approval.
 
* Yocto Project 1.3.1 status - 10 min :
  - Saul: patches are integrated. Ready for QA test. 
  - Song: QA will be done after 1.4 M2/M3 release. If anyone would like to 
suggest more patches, please let Ross (ross.bur...@intel.com) know.
  - 
* Yocto 1.4 status - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Overview 
 
  - Bug fixing: resolved 51 last week. Thanks to Otavio Salvador (4) from the 
community (Ossystems.com.br), ScottG (11). Good work and thank you all.
  - Feature development (M2/3 cutoff is this coming Sunday): 
. SMART updater/Mark: code is there and working, a couple of bugs, a couple 
of performance issues related to incremental install and complimentary install. 
Opening bugs to track them in Bugzilla. Other than those. Everything is working.
.systemd/Saul: patches pending, reworked a little bit. There are still some 
issues. Trying to get this done by the end of this week.
.wayland/Saul: 3 patches pending, dependency issues. Saul will touch base 
with Ross to get the status, hope to resolve this feature by the end of this 
week.
. LTSI (Bruce): still underway, pending. Cannot be done for M3.
. Song: QA is working on the test plan for the above features. Please 
expect working with QA. 
. Mater status/Saul: RP pulled in last set of consolidated patches. Hoping 
to have a weekly build, and then full QA. Build will be available sometime 
tomorrow (RO/PRC time).
 
* SWAT team rotation: Radu Moisan -> Constantin Musca 
 
* Opens - 10 min 
 - ChrisK: Design firm Tobias & Tobias are helping with the design of a web UI 
for analysing builds and images. They are looking for people willing to test & 
give feedback on an early-stage design prototype. Interviews will be conducted 
via phone or Skype and take about 30 minutes. 
. If you can participate, please email: chris.kamin...@tobias.tv
  - Bjorn: x-test and x-ptest. have been working on the ptest framework. A week 
ago, it was merged. But a different approache has been merged. It's better if 
we could have only one way.  
. Saul: this is an oversight. ptest should be the way. Will contact Kai 
Kang to sort this out.
. Bjorn has a wiki page for this framework: 
https://wiki.yoctoproject.org/wiki/Ptest
 
* Team Sharing - 20 min
 - ScottR: url: 
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html. People can go 
here to see the kernel development manual. Also sent an email to the yp mailing 
list. 
 - Corneliu: tesopia is in its final version. Is a new testcase management 
platform we are going to use from now on. Feel free to ask me if there is any 
questions: 
https://wiki.yoctoproject.org/wiki/Testopia. Will be adding SMART testcases 
today. Remove zypper testcases. All existing testcases are there.
- Michael: reinstall OS on AB 3/7/9. new OSes and better support. HW error 
happening and been corrected. Added webhob mailing list. Working on testopia 
integration. Had some slight changes and extra testing. Corneliu working with 
me. This week will continue. YP dev day assistant. More information and 
organization on the web site BSP page. 
  - Sean/ScottG/Saul: Yocto Dev day: small budget issue, plan still in the 
work. Will go ahead with the dev day, but likely no hands-on lab, will have 
small focus group discussions. Build system will be setup on individual laptop, 
etc.





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

[yocto] Busybox still old version: Still looking for a clear understanding of an old mystery.

2013-01-15 Thread Brian Smucker


Hello All,

I'm a relative newbie to yocto/oe, but have got a ways down the road to 
understanding, but the gaps in my understanding cause me great grief at 
times.


I think this probably is a simple question, but somehow I'm doing 
something wrong.


I recompile busybox with a new config: bitbake -c menuconfig busybox
I make busybox: bitbake busybox
bitbake gets compiled.

Then I do a bitbake core-image-minimal.  It does the do_rootfs action 
and makes a new image.

But the busybox is not the newly-compiled one, it is old.
I expect the new version.
Maybe my expectations are wrong.  But I've struggled with this and 
similar scenarios time and time again, sometimes hitting on a 
combination of things that work or by selectively deleting a directory 
or so or by bitbake -c cleansstate -f on one target or another.


But it's always been kind of a mystery to me how to recompile a 
particular target, which then succeeds, and subsequently make sure that 
target is included in the image target (core-image-minimal). I've 
succeeded in a hit-or-miss way at times, but I would love to know a 
clear series of steps that will work definitively.


I know I can delete the entire tmp directory, but that seems far too 
extreme, not to mention slow to recover from.


Can someone help me?

I'm using Danny.

Thanks,
Brian






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

[yocto] Details on automated Yocto validation?

2013-01-15 Thread Sandino Flores Moreno

Hello.
I'm familiar to bitbake and poky, but I'm new to Yocto.

Where may I find details about Yocto Validation?
Especially in what regards to automated tests.

I came up with this topic because we are using it to build a custom linux
distribution, rpm based, and now it is required to implement a proper
validation to ensure there are no regressions, that packages are sane, etc.

As it normally happens, there may be an effort that someone else started
already.

So far I have only found:
https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule

But it's, as the name states, it is very general.
Something more specific would be useful.

Thanks in advance for any info.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gcov on target

2013-01-15 Thread Robert Berger

Hi,

After compiling with:

GCOV_PROFILE := y

I get:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format
unknown relocation: 38

Is this a known issue, or am I doing something stupid?

Regards,

Robert



..."In the beginning, there was software. And it wasn't good."

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


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

Re: [yocto] Busybox still old version: Still looking for a clear understanding of an old mystery.

2013-01-15 Thread Rudolf Streif

Brian,

What are you exactly referring to as "new version"? The package version
that bitbake builds is defined by the recipe, through the version
designation in the recipe's file name or through explicitly setting PV.

I think what you are trying to do is to modify the busybox configuration
and then recompile and package. Bitbake will not automatically recompile
after menuconfig. Menuconfig does not invslidate the shared state cache.
Try this:

bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox

BR,
Rudi
On Jan 15, 2013 1:27 PM, "Brian Smucker"  wrote:

> Hello All,
>
> I'm a relative newbie to yocto/oe, but have got a ways down the road to
> understanding, but the gaps in my understanding cause me great grief at
> times.
>
> I think this probably is a simple question, but somehow I'm doing
> something wrong.
>
> I recompile busybox with a new config: bitbake -c menuconfig busybox
> I make busybox: bitbake busybox
> bitbake gets compiled.
>
> Then I do a bitbake core-image-minimal.  It does the do_rootfs action and
> makes a new image.
> But the busybox is not the newly-compiled one, it is old.
> I expect the new version.
> Maybe my expectations are wrong.  But I've struggled with this and similar
> scenarios time and time again, sometimes hitting on a combination of things
> that work or by selectively deleting a directory or so or by bitbake -c
> cleansstate -f on one target or another.
>
> But it's always been kind of a mystery to me how to recompile a particular
> target, which then succeeds, and subsequently make sure that target is
> included in the image target (core-image-minimal). I've succeeded in a
> hit-or-miss way at times, but I would love to know a clear series of steps
> that will work definitively.
>
> I know I can delete the entire tmp directory, but that seems far too
> extreme, not to mention slow to recover from.
>
> Can someone help me?
>
> I'm using Danny.
>
> Thanks,
> Brian
>
>
>
>
>
>
> __**_
> 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] gcov on target

2013-01-15 Thread Robert Berger

Hi,

After compiling with:

GCOV_PROFILE := y

I get:

insmod debugfs.ko
Error: could not insert module debugfs.ko: Invalid module format
unknown relocation: 38

Is this a known issue, or am I doing something stupid?

Regards,

Robert



..."In the beginning, there was software. And it wasn't good."

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


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

Re: [yocto] [PATCH] [Bug #3963][eclipse-poky][branch:denzil]

2013-01-15 Thread Zhang, Jessica

Merged to eclipse-poky denzil.

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ioana Grigoropol
Sent: Tuesday, January 15, 2013 8:40 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH] [Bug #3963][eclipse-poky][branch:denzil]

- source oe-init-build-env each time a command is ran using yocto-bsp tool

Signed-off-by: Ioana Grigoropol 
---
 .../sdk/remotetools/wizards/bsp/MainPage.java  |   86 ++--
 .../remotetools/wizards/bsp/PropertiesPage.java|   16 ++--
 2 files changed, 89 insertions(+), 13 deletions(-)

diff --git 
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index aa1c124..f7dea27 100644
--- 
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wi
+++ zards/bsp/MainPage.java
@@ -56,6 +56,7 @@ public class MainPage extends WizardPage {
private static final String PROPERTIES_CMD_PREFIX = "yocto-bsp list ";
private static final String PROPERTIES_CMD_SURFIX = " properties -o ";
private static final String PROPERTIES_FILE = "/tmp/properties.json";
+   static final String INIT_FILE = "/oe-init-build-env";

private Button btnMetadataLoc;
private Button btnBspOutLoc;
@@ -287,8 +288,18 @@ public class MainPage extends WizardPage {
}

bspElem.setBspName(bspname);
+// if (!textBspOutLoc.getText().isEmpty())
+// bspElem.setBspOutLoc(textBspOutLoc.getText());
if (!textBspOutLoc.getText().isEmpty())
bspElem.setBspOutLoc(textBspOutLoc.getText());
+   else
+   bspElem.setBspOutLoc("");
+   if (!textBspOutLoc.getText().isEmpty())
+   bspElem.setBuildLoc(textBspOutLoc.getText());
+   else {
+   bspElem.setBuildLoc(metadata_loc + "/build");
+   checkBuildDir();
+   }
bspElem.setMetadataLoc(metadata_loc);
bspElem.setKarch(karch);
bspElem.setQarch(qarch);
@@ -296,6 +307,53 @@ public class MainPage extends WizardPage {

return true;
}
+   private Status createBuildDir(String buildLoc) {
+   String metadataDir = textMetadataLoc.getText();
+
+   // if we do  not change the directory to metadata location the 
script will be looked into the directory indicated by user.dir system property
+   // system.property usually points to the location from where 
eclipse was started
+   String createBuildDirCmd = "cd " + metadataDir + ";source " +
+metadataDir + INIT_FILE + " " + buildLoc;
+
+   try {
+   ProcessBuilder builder = new ProcessBuilder(new 
String[] {"sh", "-c", createBuildDirCmd});
+   Process proc = builder.start();
+   InputStream errorStream = proc.getErrorStream();
+   InputStreamReader isr = new 
InputStreamReader(errorStream);
+   BufferedReader br = new BufferedReader(isr);
+   String line = null;
+   String status = "";
+   while ( (line = br.readLine()) != null) {
+   status += line;
+   }
+
+   if (proc.waitFor() != 0)
+   return new Status(IStatus.ERROR, "not_used", 0, 
status, null);;
+   return new Status(IStatus.OK, "not_used", 0, "", null);
+   } catch (Exception e) {
+   return  new Status(IStatus.ERROR, "not_used", 0, 
e.getMessage(), null);
+   }
+   }
+   private Status checkBuildDir() {
+
+   String metadataLoc = textMetadataLoc.getText();
+
+   String buildLoc = metadataLoc + "/build";
+   return createBuildDir(buildLoc);
+   }
+   private String getBuildDir() {
+
+   String metadataLoc = textMetadataLoc.getText();
+   String buildLoc = textBspOutLoc.getText();
+
+   if (buildLoc.isEmpty()) {
+   buildLoc = metadataLoc + "/build";
+   }
+   File buildLocDir = new File(buildLoc);
+   if (!buildLocDir.exists()) {
+   createBuildDir(buildLoc);
+   }
+   return buildLoc;
+   }

private boolean createPropertiesFile() {
String create_properties_cmd = bspElem.getMetadataLoc() + 
"/scripts/" + @@ -319,14 +377,22 @@ public class MainPage extends WizardPage {
}
return true;
}
-
+

Re: [yocto] Busybox still old version: Still looking for a clear understanding of an old mystery.

2013-01-15 Thread Brian Smucker


Hi Rudolf,

On 1/15/2013 3:28 PM, Rudolf Streif wrote:


Brian,

What are you exactly referring to as "new version"? The package 
version that bitbake builds is defined by the recipe, through the 
version designation in the recipe's file name or through explicitly 
setting PV.


I think what you are trying to do is to modify the busybox 
configuration and then recompile and package. Bitbake will not 
automatically recompile after menuconfig. Menuconfig does not 
invslidate the shared state cache. Try this:


bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox


So I have done the above.  That is not the question.  Busybox compiles 
fine and the new unstripped busybox is in the 
.../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/


My question is that after compiling busybox, I do

bitbake -c cleansstate core-image-minimal
bitbake core-image-minimal

expecting that the core image generated will contain the new busybox.  
It does not, it contains a busybox copy that was compiled days ago, not 
the custom one I just compiled.


Why is this?  How can I force the bitbake to include the newly-compiled 
busybox into my minimal image?


Thanks,

Brian

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

[yocto] Weekly build availability.

2013-01-15 Thread Flanagan, Elizabeth

The weekly build is available at:

http://autobuilder.yoctoproject.org/pub/nightly/20130115-2

Known issues:

- The eclipse plugin needs to be built alone and moved manually. I'm
doing this right now. This is due to moving the eclipse builder to a
slightly overloaded machine. I'll be moving it back once I have idle
time on the infrastructure.
- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.
- nightly-fsl-arm core-image-x11 failed. Multiple providers for
virtual/libgl and compile issues for beecrypt and avahi
- nightly-ppc failed on oprofile


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

Re: [yocto] Weekly build availability.

2013-01-15 Thread Saul Wold



QA Teams:

Please do FULL Pass testing on this as a PRE-M3 Full Pass so we have 
some idea of what's going on.


Git Rev: 9eb88ceb39b7d0b8ddc6487e61ce8edadef10ec4

On 01/15/2013 05:09 PM, Flanagan, Elizabeth wrote:

The weekly build is available at:

http://autobuilder.yoctoproject.org/pub/nightly/20130115-2

Known issues:

- The eclipse plugin needs to be built alone and moved manually. I'm
doing this right now. This is due to moving the eclipse builder to a
slightly overloaded machine. I'll be moving it back once I have idle
time on the infrastructure.
- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.
- nightly-fsl-arm core-image-x11 failed. Multiple providers for
virtual/libgl and compile issues for beecrypt and avahi



- nightly-ppc failed on oprofile


This is a known issue and there is a patch on stage/master_under_test 
for this



-b
___
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] Weekly build availability.

2013-01-15 Thread McClintock Matthew-B29882

On Tue, Jan 15, 2013 at 7:09 PM, Flanagan, Elizabeth
 wrote:
> - p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
> warnings about missing patches.

I've got a master-next branch I'm testing now and should be on master
soon. I'm also debugging the oprofile issues from nightly-ppc as well.

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

Re: [yocto] Weekly build availability.

2013-01-15 Thread Saul Wold


On 01/15/2013 08:37 PM, McClintock Matthew-B29882 wrote:

On Tue, Jan 15, 2013 at 7:09 PM, Flanagan, Elizabeth
 wrote:

- p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
warnings about missing patches.


I've got a master-next branch I'm testing now and should be on master
soon. I'm also debugging the oprofile issues from nightly-ppc as well.

There is a patch from Bogdan for this one, see "oprofile: set correct 
kernel path", there is clearly more work needed here, but that will get 
us past this failure until we get the libpfm recipe in, which looks like 
it will be required also.


Sau!


-M



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

Re: [yocto] Weekly build availability.

2013-01-15 Thread McClintock Matthew-B29882

On Tue, Jan 15, 2013 at 10:44 PM, Saul Wold  wrote:
> On 01/15/2013 08:37 PM, McClintock Matthew-B29882 wrote:
>>
>> On Tue, Jan 15, 2013 at 7:09 PM, Flanagan, Elizabeth
>>  wrote:
>>>
>>> - p1022ds failed due to a libxml2_2.8.0 failure. it is also throwing
>>> warnings about missing patches.
>>
>>
>> I've got a master-next branch I'm testing now and should be on master
>> soon. I'm also debugging the oprofile issues from nightly-ppc as well.
>>
> There is a patch from Bogdan for this one, see "oprofile: set correct kernel
> path", there is clearly more work needed here, but that will get us past
> this failure until we get the libpfm recipe in, which looks like it will be
> required also.

I made a recipe for libpfm3 and libpfm4 so let me submit those before
anyone else spends time on it.

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

Re: [yocto] SDK environment LDFLAGS problem?

2013-01-15 Thread Wolfgang Denk

Dear Bruce,

In message <50f59a91.5080...@windriver.com> you wrote:
>
> > Yes, it's clear to me that, in this one respect, the SDK is unsuitable
> > for building kernels or kernel modules.
> >
> > My point is that this is a problem, and it might be reasonable to fix it.

This is indeed a problem, and not only with the kernel, but also for
example with U-Boot - fortunately there are not that many software
packages that need to tweak with linker scripts etc. so they need to
call the linker directly.

> You probably want Jessica or Richard to comment on the architecture /
> design of the SDK with respect to kernel elements. The only packaging
> for out of tree / non build system builds that I know I've ever looked
> into are on target, or staging directory builds of modules.
...

> Everyone/Everything has their reasons for the different workflow(s).
> (I maintain the ability to build all the boards covered in linux-yocto
> without the need for any build system at all, as an example). And all
> workflows are definitely valid, but it is expected that the primary
> workflow for anything oe/bitbake based would be centered around recipes.

I found it difficult to find any formal definition of what LDFLAGS is
supposed to be.  The most authoritative appears to be the definition
as given by the make(1) documentation - as this is where LDFLAGS
actually gets used:

`LDFLAGS'
 Extra flags to give to compilers when they are supposed
 to invoke the linker, `ld'.

Note the phrase "flags to give to compilers", i. e. this clearly
states that the linking is supposed to be done by running the compiler
frontend, and not the linker directly.

So even though we feel the recent version breaks old habits, it seems
that simply our old habits were based on incorrect assumptions.

I see no reason to fix the current settings, but perhaps it would be
helpful to clearly document this behaviour and recommend a workaround.

At least this was what we did for our Yocto based ELDK [1].

[1] 
http://www.denx.de/wiki/view/ELDK-5/FrequentlyAskedQuestionsAndAnswers#Compiling_U_Boot_or_Linux_fails

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
   - Terry Pratchett, _Going_Postal_
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

46 matches

Mail list logo