Date   

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

Grigoropol, IoanaX <ioanax.grigoropol@...>
 

Hi Jessica,

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

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

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

Jessica

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

From: Ioana Grigoropol <ioana.grigoropol@gmail.com>

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

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

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

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
index 11d677a..724b7d0 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
@@ -18,7 +18,7 @@ import java.io.InputStream; import java.io.InputStreamReader; import java.io.OutputStream; import java.io.Writer;
-
+
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.rse.core.model.IHost; diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
index 5c43ba8..f53592c 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
@@ -108,7 +108,7 @@ public class Activator extends AbstractUIPlugin {

BBSession bbs = (BBSession) bbSessionMap.get(projectRoot);

- if (bbs == null) {
+ if (bbs == null || bbs.getShell() == null) {
bbs = new BBSession(getShellSession(projectInfo, null, monitor), projectRoot);
bbSessionMap.put(projectRoot, bbs);
}
@@ -190,7 +190,7 @@ public class Activator extends AbstractUIPlugin {

ShellSession ss = (ShellSession) shellMap.get(absolutePath);

- if (ss == null) {
+ if (ss == null &&
+RemoteHelper.isInitialized(projInfo.getOriginalURI())) {
IHostFile remoteHostFile = RemoteHelper.getRemoteHostFile(projInfo.getConnection(), absolutePath.getPath(), monitor);
ss = new ShellSession(projInfo, remoteHostFile, ProjectInfoHelper.getInitScriptPath(absolutePath));
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/OEFileSystem.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/OEFileSystem.java
index 357edc1..b814c4c 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/OEFileSystem.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/OEFileSyste
+++ m.java
@@ -11,7 +11,6 @@
*******************************************************************************/
package org.yocto.bc.ui.filesystem;

-import java.io.File;
import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.util.ArrayList;
@@ -22,14 +21,16 @@ import java.util.Map; import org.eclipse.core.filesystem.IFileStore;
import org.eclipse.core.filesystem.IFileSystem;
import org.eclipse.core.filesystem.provider.FileSystem;
+import org.eclipse.core.internal.filesystem.NullFileStore;
+import org.eclipse.core.internal.resources.LocalMetaArea;
+import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.NullProgressMonitor;
+import org.eclipse.core.runtime.Path;
import org.eclipse.rse.services.clientserver.messages.SystemMessageException;
-
import org.yocto.bc.bitbake.BBSession;
import org.yocto.bc.ui.Activator;
import org.yocto.bc.ui.model.ProjectInfo;
-import org.yocto.bc.ui.model.YoctoHostFile;

/**
* A filesystem that ignores specific OE directories that contain derived information.
@@ -64,8 +65,7 @@ public class OEFileSystem extends FileSystem {
config = Activator.getBBSession(projInfo, new NullProgressMonitor());
config.initialize();
} catch (Exception e) {
- e.printStackTrace();
- return new OEIgnoreFile(new YoctoHostFile(projInfo, uri));
+ return new NullFileStore(new Path(uri.getPath()));
}

if (config.get("TMPDIR") == null || config.get("DL_DIR") == null || config.get("SSTATE_DIR")== null) { diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java

index 79e5f87..119782d 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java
@@ -61,6 +61,13 @@ public class ProjectInfo implements IModelElement {
public void setLocationURI(URI location) {
if (this.location == null)
this.location = new YoctoLocation();
+ if (location.getScheme().equalsIgnoreCase("oefs")) {
+ if (this.name == null) {
+ String path = location.getPath();
+ this.name = path.substring(path.lastIndexOf("/") + 1);
+ }
+ location = RemoteHelper.retrieveURIFromMetaArea(this.name);
+ }
this.location.setOriginalURI(location);
try {
this.location.setOEFSURI(new URI(ProjectInfoHelper.OEFS_SCHEME + location.getPath() )); @@ -79,7 +86,7 @@ public class ProjectInfo implements IModelElement {
}

public IHost getConnection() {
- if (connection == null) {
+ if (connection == null &&
+RemoteHelper.isInitialized(getOriginalURI())) {
connection = RemoteHelper.getRemoteConnectionForURI(location.getOriginalURI(), new NullProgressMonitor());
}
return connection;
@@ -99,6 +106,8 @@ public class ProjectInfo implements IModelElement {

public IFileService getFileService(IProgressMonitor monitor){
try {
+ if (!RemoteHelper.isInitialized(getOriginalURI()))
+ return null;
return RemoteHelper.getConnectedRemoteFileService(connection, monitor);
} catch (Exception e) {
e.printStackTrace();
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/YoctoHostFile.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/YoctoHostFile.java
index eaa26df..7113efb 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/YoctoHostFile.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/YoctoHostFile.ja
+++ va
@@ -313,4 +313,14 @@ public class YoctoHostFile implements IHostFile{
public void setFileService(IFileService fileService) {
this.fileService = fileService;
}
+
+ @Override
+ public String toString() {
+ URI uri = this.projectInfo.getOriginalURI();
+ try {
+ return new URI(uri.getScheme(), uri.getHost(), fileURI.getPath(), uri.getFragment()).toString();
+ } catch (URISyntaxException e) {
+ return fileURI.toString();
+ }
+ }
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/InstallWizard.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/InstallWizard.java
index 5df375e..f3ecfc4 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/InstallWizard.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/Instal
+++ lWizard.java
@@ -195,6 +195,7 @@ public class InstallWizard extends FiniteStateWizard implements
Activator.putProjInfo(pinfo.getOEFSURI(), pinfo);

container.run(false, false, new CreateBBCProjectOperation(pinfo));
+ RemoteHelper.storeURIInMetaArea(pinfo.getProjectName(), uri);
return true;
}
} catch (Exception e) {
diff --git a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
index 06d14f8..08a76cc 100644
--- a/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
+++ b/plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF
@@ -8,9 +8,13 @@ Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
-Import-Package: org.eclipse.rse.core,
+Import-Package: org.eclipse.core.internal.filesystem,
+ org.eclipse.core.internal.resources,
+ org.eclipse.core.resources,
+ org.eclipse.rse.core,
org.eclipse.rse.core.model,
org.eclipse.rse.core.subsystems,
+ org.eclipse.rse.internal.core,
org.eclipse.rse.internal.services.local.shells,
org.eclipse.rse.internal.services.shells,
org.eclipse.rse.internal.terminals.ui,
diff --git a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteHelper.java b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteHelper.java
index e9118d6..cd33d29 100644
--- a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteHelper.java
+++ b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/RemoteHe
+++ lper.java
@@ -13,19 +13,30 @@ package org.yocto.remote.utils;

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
+import java.io.BufferedReader;
import java.io.File;
+import java.io.FileNotFoundException;
import java.io.FileOutputStream;
+import java.io.FileReader;
+import java.io.IOException;
import java.io.InputStream;
+import java.io.PrintWriter;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
import java.util.Iterator;
+import java.util.List;
import java.util.Map;

+import org.eclipse.core.internal.filesystem.InternalFileSystemCore;
+import org.eclipse.core.internal.resources.LocalMetaArea;
+import org.eclipse.core.internal.resources.Workspace;
+import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.FileLocator;
+import org.eclipse.core.runtime.IPath;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus; import org.eclipse.core.runtime.MultiStatus;
@@ -34,12 +45,14 @@ import org.eclipse.core.runtime.Status; import org.eclipse.core.runtime.SubProgressMonitor;
import org.eclipse.osgi.util.NLS;
import org.eclipse.rse.core.IRSECoreStatusCodes;
+import org.eclipse.rse.core.IRSEInitListener;
import org.eclipse.rse.core.IRSESystemType;
import org.eclipse.rse.core.RSECorePlugin;
import org.eclipse.rse.core.model.IHost; import org.eclipse.rse.core.model.ISubSystemConfigurationCategories;
import org.eclipse.rse.core.model.ISystemRegistry;
import org.eclipse.rse.core.subsystems.ISubSystem;
+import org.eclipse.rse.internal.core.RSEInitJob;
import org.eclipse.rse.services.IService;
import org.eclipse.rse.services.clientserver.messages.SystemMessageException;
import org.eclipse.rse.services.files.IFileService;
@@ -62,6 +75,72 @@ public class RemoteHelper {
public static final int TOTALWORKLOAD = 100;
private static Map<IHost, RemoteMachine> machines;

+ public static IPath getWorkspaceMetaArea(){
+ Workspace workspace = (Workspace)ResourcesPlugin.getWorkspace();
+ LocalMetaArea metaDataArea = workspace.getMetaArea();
+ return metaDataArea.getLocation();
+ }
+
+ public static void storeURIInMetaArea(String projName, URI uri){
+ IPath path = getWorkspaceMetaArea();
+ String sep = File.separator;
+ File f = new File(path.toString() + sep + ".projects" + sep + projName + sep + ".originalURI");
+ PrintWriter writer;
+ try {
+ writer = new PrintWriter(f);
+ writer.println(uri.getScheme());
+ writer.println(uri.getHost());
+ writer.println(uri.getPath());
+ writer.println(uri.getFragment());
+ writer.close();
+ } catch (FileNotFoundException e) {
+ e.printStackTrace();
+ }
+ }
+
+ public static URI retrieveURIFromMetaArea(String projName){
+ IPath path = getWorkspaceMetaArea();
+ String sep = File.separator;
+ File f = new File(path.toString() + sep + ".projects" + sep + projName + sep + ".originalURI");
+ try {
+ BufferedReader buf = new BufferedReader(new FileReader(f));
+ String line = null;
+ List<String> elems = new ArrayList<String>();
+ while((line = buf.readLine()) != null){
+ if (line.equals("null"))
+ line = null;
+ elems.add(line);
+ }
+ buf.close();
+ if (elems.size() == 4){
+ URI uri = new URI(elems.get(0), elems.get(1), elems.get(2), elems.get(3));
+ return uri;
+ }
+ } catch (IOException e) {
+ e.printStackTrace();
+ } catch (URISyntaxException e) {
+ e.printStackTrace();
+ }
+ return null;
+ }
+
+ public static boolean isInitialized(final URI uri){
+ boolean init = RSECorePlugin.isInitComplete(RSECorePlugin.INIT_MODEL);
+ if (!init) {
+ RSEInitJob.getInstance().addInitListener(new IRSEInitListener() {
+ @Override
+ public void phaseComplete(int arg0) {
+ try {
+ InternalFileSystemCore.getInstance().getStore(uri);
+ } catch (CoreException e) {
+ e.printStackTrace();
+ }
+ }
+ });
+ }
+ return init;
+ }
+
public static IHost getRemoteConnectionByName(String remoteConnection) {
if (remoteConnection == null)
return null;
--
1.7.10.4

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


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

Grigoropol, IoanaX <ioanax.grigoropol@...>
 

Hi Jessica,

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

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

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

Hi Ioana,

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

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

Please do some local verification when sending patches upstream.

Thanks,
Jessica

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

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

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

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

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

private TerminalServiceShellOutputReader fStderrHandler; @@ -60,21 +61,21 @@ public class TerminalServiceHostShell extends AbstractHostShell {
try {
fTerminalShell = terminalShell;
String encoding = fTerminalShell.getDefaultEncoding();
- BufferedReader bufReader;
+
if (encoding != null) {
- bufReader = new BufferedReader(new InputStreamReader(fTerminalShell
+ fBufReader = new BufferedReader(new
+InputStreamReader(fTerminalShell
.getInputStream(), encoding));
} else {
- bufReader = new BufferedReader(new InputStreamReader(fTerminalShell
+ fBufReader = new BufferedReader(new
+InputStreamReader(fTerminalShell
.getInputStream()));
}
//bug 356132: wait for initial output before sending any command
//FIXME this should likely move into the TerminalServiceShellWriterThread, so wait can be canceled
- bufReader.mark(1);
- bufReader.read();
- bufReader.reset();
+ fBufReader.mark(1);
+ fBufReader.read();
+ fBufReader.reset();

- fStdoutHandler = new TerminalServiceShellOutputReader(this, bufReader, false);
+ fStdoutHandler = new TerminalServiceShellOutputReader(this,
+fBufReader, false);
fStderrHandler = new TerminalServiceShellOutputReader(this, null, true);
OutputStream outputStream = fTerminalShell.getOutputStream();
if (encoding != null) {
@@ -170,4 +171,7 @@ public class TerminalServiceHostShell extends AbstractHostShell {
return "echo $PWD'>'"; //$NON-NLS-1$
}

+ public BufferedReader getReader(boolean isErrorReader) {
+ return fBufReader;
+ }
}
diff --git a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/AbstractHostShell.java b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/AbstractHostShell.java
index 0ac8e3f..4d189b6 100644
--- a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/AbstractHostShell.java
+++ b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/
+++ shells/AbstractHostShell.java
@@ -11,11 +11,13 @@
* Emily Bruner, Mazen Faraj, Adrian Storisteanu, Li Ding, and Kent Hawley.
*
* Contributors:
- * {Name} (company) - description of contribution.
+ * Ioana Grigoropol (Intel) - [411343] Provide access to readers in host shell
********************************************************************************/

package org.eclipse.rse.services.shells;

+import java.io.BufferedReader;
+

public abstract class AbstractHostShell implements IHostShell { @@ -34,4 +36,7 @@ public abstract class AbstractHostShell implements IHostShell
}
}

-}
\ No newline at end of file
+ public BufferedReader getReader(boolean isErrorReader){
+ return null;
+ }
+}
--
1.7.10.4

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


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

Adrian Dudau
 

Hi Jessica,

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

Thanks,
--Adrian

On Mon, 2013-06-17 at 14:37 +0200, Adrian Dudau wrote:
[Yocto #4223]
Signed-off-by: Adrian Dudau <adrian.dudau@enea.com>
---
.../src/org/yocto/remote/utils/ShellSession.java | 4 ++-
.../src/org/yocto/sdk/remotetools/Messages.java | 1 +
.../sdk/remotetools/actions/SystemtapHandler.java | 3 ++-
.../sdk/remotetools/actions/SystemtapModel.java | 6 +++--
.../actions/SystemtapSettingDialog.java | 28 ++++++++++++++++++++
.../org/yocto/sdk/remotetools/messages.properties | 1 +
6 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
index 4ac8001..10cdf94 100644
--- a/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
+++ b/plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/ShellSession.java
@@ -46,6 +46,7 @@ public class ShellSession {
private String shellPath = null;
private final String initCmd;
private final File root;
+ private final File builddir;

private OutputStreamWriter out;

@@ -70,6 +71,7 @@ public class ShellSession {

public ShellSession(int shellType, File root, String initCmd, OutputStream out) throws IOException {
this.root = root;
+ this.builddir = builddir;
this.initCmd = initCmd;
if (out == null) {
this.out = new OutputStreamWriter(null);
@@ -93,7 +95,7 @@ public class ShellSession {
}

if (initCmd != null) {
- execute("source " + initCmd);
+ execute("source " + initCmd + " " + builddir.getAbsolutePath());
}
}

diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
index 66ba62b..cbf2b05 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/Messages.java
@@ -40,6 +40,7 @@ public class Messages extends NLS {
public static String TerminalViewer_text;
//public static String Systemtap_KO_Text;
public static String Metadata_Location;
+ public static String Builddir_Location;
public static String User_ID;
public static String Remote_Host;
public static String Systemtap_Script;
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
index 9d27e5a..9f45d05 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
@@ -34,6 +34,7 @@ public class SystemtapHandler extends AbstractHandler {
);

String metadata_location = ((SystemtapSettingDialog)setting).getMetadataLocation();
+ String builddir_location = ((SystemtapSettingDialog)setting).getBuilddirLocation();
String remote_host = ((SystemtapSettingDialog)setting).getRemoteHost();
String user_id = ((SystemtapSettingDialog)setting).getUserID();
String systemtap_script = ((SystemtapSettingDialog)setting).getSystemtapScript();
@@ -41,7 +42,7 @@ public class SystemtapHandler extends AbstractHandler {

if(setting.open() == BaseSettingDialog.OK) {
IProgressService progressService = PlatformUI.getWorkbench().getProgressService();
- SystemtapModel op = new SystemtapModel(metadata_location,remote_host, user_id, systemtap_script,
+ SystemtapModel op = new SystemtapModel(metadata_location, builddir_location, remote_host, user_id, systemtap_script,
systemtap_args,window.getShell().getDisplay());
try {
progressService.busyCursorWhile(op);
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
index f443e00..bb2fa2d 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapModel.java
@@ -29,6 +29,7 @@ public class SystemtapModel extends BaseModel {

protected MessageConsole sessionConsole;
private String metadata_location;
+ private String builddir_location;
private String remote_host;
private String user_id;
private String systemtap_script;
@@ -36,9 +37,10 @@ public class SystemtapModel extends BaseModel {

Display display;

- public SystemtapModel(String metadata_location, String remote_host, String user_id, String systemtap_script, String systemtap_args, Display display) {
+ public SystemtapModel(String metadata_location, String builddir_location, String remote_host, String user_id, String systemtap_script, String systemtap_args, Display display) {
super(null, TASK_NAME, "", "");
this.metadata_location = metadata_location;
+ this.builddir_location = builddir_location;
this.remote_host = remote_host;
this.user_id = user_id;
this.systemtap_script = systemtap_script;
@@ -70,7 +72,7 @@ public class SystemtapModel extends BaseModel {
throws InvocationTargetException, InterruptedException {
try {
ShellSession shell = new ShellSession(ShellSession.SHELL_TYPE_BASH,
- new File(this.metadata_location),
+ new File(this.metadata_location), new File(this.builddir_location),
DEFAULT_INIT_SCRIPT, sessionConsole.newOutputStream());
boolean acceptedKey = shell.ensureKnownHostKey(user_id, remote_host);
if (acceptedKey) {
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapSettingDialog.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapSettingDialog.java
index c447569..760715c 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapSettingDialog.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapSettingDialog.java
@@ -37,18 +37,21 @@ public class SystemtapSettingDialog extends Dialog {
static protected String TITLE="Systemtap Crosstap";
protected String title;
protected String metadata_location;
+ protected String builddir_location;
protected String systemtap_script;
protected String user_id;
protected String remote_host;
protected String systemtap_args;
protected boolean okPressed;
protected Button metadataLocationBtn;
+ protected Button builddirLocationBtn;
protected Button systemtapScriptBtn;
protected Text userIDText;
protected Text remoteHostText;
protected Text systemtapArgsText;
protected Text systemtapScriptText;
protected Text metadataLocationText;
+ protected Text builddirLocationText;

protected SystemtapSettingDialog(Shell parentShell, String title) {
super(parentShell);
@@ -75,6 +78,10 @@ public class SystemtapSettingDialog extends Dialog {
return metadata_location;
}

+ public String getBuilddirLocation() {
+ return builddir_location;
+ }
+
public String getRemoteHost() {
return remote_host;
}
@@ -119,6 +126,14 @@ public class SystemtapSettingDialog extends Dialog {
metadataLocationBtn = addDirSelectButton(textContainer, metadataLocationText);

label = new Label(projComp, SWT.NONE);
+ label.setText(Messages.Builddir_Location);
+ textContainer = new Composite(projComp, SWT.NONE);
+ textContainer.setLayout(new GridLayout(2, false));
+ textContainer.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, true, false));
+ builddirLocationText = (Text)addTextControl(textContainer, builddir_location);
+ builddirLocationBtn = addDirSelectButton(textContainer, builddirLocationText);
+
+ label = new Label(projComp, SWT.NONE);
label.setText(Messages.User_ID);
userIDText = new Text(projComp, SWT.SINGLE | SWT.BORDER);

@@ -219,6 +234,19 @@ public class SystemtapSettingDialog extends Dialog {
CommonHelper.showErrorDialog("SystemTap Error", null, "The specified metadata location is not a directory!");
return;
}
+ builddir_location = builddirLocationText.getText();
+ if ( (builddir_location == null) || builddir_location.isEmpty()) {
+ CommonHelper.showErrorDialog("SystemTap Error", null, "Please specify your builddir location!");
+ return;
+ }
+ File builddir_dir = new File(builddir_location);
+ if (!builddir_dir.exists()) {
+ CommonHelper.showErrorDialog("SystemTap Error", null, "The specified builddir location does not exist!");
+ }
+ if (!metadata_dir.isDirectory()) {
+ CommonHelper.showErrorDialog("SystemTap Error", null, "The specified builddir location is not a directory!");
+ return;
+ }
user_id = userIDText.getText();
if ( (user_id == null) || user_id.isEmpty()) {
CommonHelper.showErrorDialog("SystemTap Error", null, "Please specify remote user id!");
diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/messages.properties b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/messages.properties
index 7bbf987..2d6d8af 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/messages.properties
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/messages.properties
@@ -35,6 +35,7 @@ Powertop_ShowPid_Text=show pids in wakeups list
TerminalViewer_text=This view is dedicated to Yocto Remote tools. Please use the "Yocto Remote Tools" menu to open the view.
//Systemtap_KO_Text=Kernel Module:
Metadata_Location=Metadata Location:
+Builddir_Location=Build dir Location:
User_ID=User ID:
Remote_Host=Remote Host:
Systemtap_Script=Systemtap Script:


Re: Adding users and their rights

DAMARLA Satya Swaroop <satyaswaroop.damarla@...>
 

Thank you Nicolas and Anders... This is what Iam actually looking for...

Cheers,
Satya


On Tue, Jun 25, 2013 at 8:58 AM, Anders Darander <anders@...> wrote:
,

* DAMARLA Satya Swaroop <satyaswaroop.damarla@...> [130625 08:39]:
> I would like to know if its possible to add users and theri rights at
> the build
> itself... I know tinylogin provides the adduser to the target but how
> can I do
> it at the build is the issue here..

Sure, it's quite easy to do using the useradd class. See
http://cgit.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
for more info

Cheers,
Anders

--
Anders Darander
ChargeStorm AB / eStorm AB

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


Re: Documenting YP Development Environment in more detail

Nicolas Dechesne
 


On Tue, Jun 25, 2013 at 7:15 AM, Rudolf Streif <rstreif@...> wrote:
 
An appendix on Android's "repo" tool might make for an excellent
addition; it seems some Yocto projects are showing lots of interest in
using it.

The idea is to integrate/use it with YP? I know what repo does and that it is built on top of git but I have not looked behind the scenes to figure out how it does its job and how it can be used with something else like YP instead of with the Android repositories and review system. 

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


then for organization that might need it, repo can be integrated with gerrit too, but repo 'standalone' can still be used to manage set of trees.


Re: Adding users and their rights

Nicolas Dechesne
 


On Tue, Jun 25, 2013 at 8:38 AM, DAMARLA Satya Swaroop <satyaswaroop.damarla@...> wrote:
I would like to know if its possible to add users and theri rights at the build itself... I know tinylogin provides the adduser to the target but how can I do it at the build is the issue here..

Suggestions are deeply appreciated

not sure if i understand the question correctly, but isn't 'useradd' what you are looking for: 


cheers


Re: Adding users and their rights

Anders Darander
 

,

* DAMARLA Satya Swaroop <satyaswaroop.damarla@gmail.com> [130625 08:39]:
I would like to know if its possible to add users and theri rights at
the build
itself... I know tinylogin provides the adduser to the target but how
can I do
it at the build is the issue here..
Sure, it's quite easy to do using the useradd class. See
http://cgit.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
for more info

Cheers,
Anders

--
Anders Darander
ChargeStorm AB / eStorm AB


Adding users and their rights

DAMARLA Satya Swaroop <satyaswaroop.damarla@...>
 

Hi,

I would like to know if its possible to add users and theri rights at the build itself... I know tinylogin provides the adduser to the target but how can I do it at the build is the issue here..

Suggestions are deeply appreciated

Greets,
Satya


Re: Documenting YP Development Environment in more detail

Rudolf Streif <rstreif@...>
 

Hi Trevor,


On Mon, Jun 24, 2013 at 5:56 AM, Trevor Woerner <trevor.woerner@...> wrote:
Awesome! That's great news! I was hoping someone would "beat me to it"
:-) I look forward to reading it once it's done. Do you have a
publisher or an expected release date?

Yes, I do. Pearson and the release date is early next year (Embedded Linux Conference is my target).
 
An appendix on Android's "repo" tool might make for an excellent
addition; it seems some Yocto projects are showing lots of interest in
using it.

The idea is to integrate/use it with YP? I know what repo does and that it is built on top of git but I have not looked behind the scenes to figure out how it does its job and how it can be used with something else like YP instead of with the Android repositories and review system. 

Cheers,
Rudi 


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

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Everyone,

Thanks for the discussion on user configuration. It is good that ideas are being shared and more information is being revealed. I am attaching the next revision of the user configuration figure. I am moving on to the rest of the "left-side" of the inputs for the overall YP development figure that appears on the YP Quick Start. That will deal with metadata (.bb and patches), layers, machine configurations, and distro configurations (policy settings).

Feel free to comment on the user configuration stuff in this email.

Thanks,
Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Philip Balister
Sent: Monday, June 24, 2013 5:39 PM
To: Jeff Osier-Mixon
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 06/24/2013 02:37 PM, Jeff Osier-Mixon wrote:
On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister
<philip@balister.org> wrote:
Showing how Poky (the reference distribution) is built would be a
nice
way to introduce people to building their own custom distributions
using
OpenEmbedded.
Totally agree, but I would relegate that to a separate effort. The
main problem with diagrams like this is trying to squeeze in too much
information in order to preserve completeness, at the expense of
clarity. It would be more ideal to start with a very simple diagram,
then move on to other diagrams to zoom in on pertinent detail. It is a
delicate balancing act. In this case, I would say to put "how Poky is
built" into the 3rd or 4th diagram in a series.

I'm glad to see this conversation happening!
I totally agree we drifted way beyond the initial discussion of the
figure. The key thought here is understanding how Poky differs from a
typical use of oe-core + other layers.

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


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

Philip Balister
 

On 06/24/2013 02:37 PM, Jeff Osier-Mixon wrote:
On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister <philip@balister.org> wrote:
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.
Totally agree, but I would relegate that to a separate effort. The
main problem with diagrams like this is trying to squeeze in too much
information in order to preserve completeness, at the expense of
clarity. It would be more ideal to start with a very simple diagram,
then move on to other diagrams to zoom in on pertinent detail. It is a
delicate balancing act. In this case, I would say to put "how Poky is
built" into the 3rd or 4th diagram in a series.

I'm glad to see this conversation happening!
I totally agree we drifted way beyond the initial discussion of the
figure. The key thought here is understanding how Poky differs from a
typical use of oe-core + other layers.

Philip


The simplest possible recipe

Paul D. DeRocco
 

That would be to copy a single file, provided in the files subdirectory of
the recipe, into a particular place in the target tree. Is there any bbclass
that automates this? Or do I just write a recipe with a do_install function
that executes the "install" command?

My only guide is 5.3.1 in the Development Manual, which performs a simple
compilation, but I'm very hazy about how recipes are interpreted, so I'd
like it if someone can tell me if I've gotten the following stuff right or
not.

SRC_URI tells bitbake what files must be gotten from somewhere and copied
somewhere else in order to carry out the build process. And according to the
Ref Manual, the "file://" prefix tells it to fetch a local file by searching
some directories including the "files" subdirectory next to the .bb file.
And apparently, there is a "subdir" option (whose syntax is unexplained)
which may be used to tell bitbake to put it somewhere specific relative to
${WORKDIR}.

Is the default value of the "subdir" option the S variable? Is that the
purpose of S, to tell bitbake where to put things that it fetches? The Ref
Manual says that S defaults to ${WORKDIR}/${PN}/${PV}, but then the sample
compile recipe sets S to ${WORKDIR}. Is that what one does when one doesn't
need to have a bunch of versioned subdirectories under ${WORKDIR}? (I'm not
sure why one would ever want that, or why that would be the default.)

So if I want to install a file somewhere, do I even need a do_install task,
or can I just set S equal to the desired target location, like
"${etcdir}/foo" and be done with it? Or is that a no-no, and should I always
use do_install?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Re: Yocto Project bug trends for 2013 WW25

David Stewart
 

Thanks for sending these out! Nice to see it before the meeting tomorrow

On 6/24/13 11:37 AM, "Michael Halstead" <michael@yoctoproject.org> wrote:

The trend graphs for work week 25 are up at
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend with two new charts.
Versions of the weighted defect density trend-lines with Yocto Project
release dates and several additional controls have been added.

Screenshots of the graphs are attached for people who need a copy while
offline. These are large images and you may need to open them outside of
your e-mail client to see all the detail.

--
Michael Halstead
Yocto Project / System Administrator


Yocto Project bug trends for 2013 WW25

Michael Halstead
 

The trend graphs for work week 25 are up at
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend with two new charts.
Versions of the weighted defect density trend-lines with Yocto Project
release dates and several additional controls have been added.

Screenshots of the graphs are attached for people who need a copy while
offline. These are large images and you may need to open them outside of
your e-mail client to see all the detail.

--
Michael Halstead
Yocto Project / System Administrator


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

Jeff Osier-Mixon <jefro@...>
 

On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister <philip@balister.org> wrote:
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.
Totally agree, but I would relegate that to a separate effort. The
main problem with diagrams like this is trying to squeeze in too much
information in order to preserve completeness, at the expense of
clarity. It would be more ideal to start with a very simple diagram,
then move on to other diagrams to zoom in on pertinent detail. It is a
delicate balancing act. In this case, I would say to put "how Poky is
built" into the 3rd or 4th diagram in a series.

I'm glad to see this conversation happening!

--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org


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

Philip Balister
 

On 06/24/2013 12:59 PM, Burton, Ross wrote:
On 24 June 2013 17:55, Philip Balister <philip@balister.org> wrote:
Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.
Agreed - explaining clearly that Poky is mostly an aggregation of
existing repositories and not actually canonical upstream for anything
is probably a good move, as this is clearly misunderstood by many
people.
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.

Philip


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

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Ok - I was told there was just a single version of oe-init-build-env. So that must be not quite right. What I will likely do is in the supporting text for the figure get into some detail on just where these pieces are. That would be a good opportunity to maybe present some text around that.

-----Original Message-----
From: Philip Balister [mailto:philip@balister.org]
Sent: Monday, June 24, 2013 9:56 AM
To: Rifenbark, Scott M
Cc: Burton, Ross; Robert P. J. Day; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote:
My figure is for Yocto Project documentation so I am going to show
that oe-init-build-env gets information from meta-yocto. I understand
that OE-Core sample files are in "meta". There is a single oe-init-
build-env script and it looks in one of two places.

Actually, the script is in two places, the root level of a poky checkout
and in the oe-core directory.

Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.

Philip


Scott

-----Original Message-----
From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: Monday, June 24, 2013 7:57 AM
To: Robert P. J. Day
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 24 June 2013 15:47, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env
is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.
meta-yocto is what makes Poky Poky, otherwise it would be just oe-
core
+ bitbake. oe-init-build-env looks for sample files in
$TEMPLATECONF,
which is one of the things that get munged as
bitbake+oe-core+meta-yocto becomes poky.

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


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

Ross Burton
 

On 24 June 2013 17:55, Philip Balister <philip@balister.org> wrote:
Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.
Agreed - explaining clearly that Poky is mostly an aggregation of
existing repositories and not actually canonical upstream for anything
is probably a good move, as this is clearly misunderstood by many
people.

Ross


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

Philip Balister
 

On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote:
My figure is for Yocto Project documentation so I am going to show that oe-init-build-env gets information from meta-yocto. I understand that OE-Core sample files are in "meta". There is a single oe-init-build-env script and it looks in one of two places.
Actually, the script is in two places, the root level of a poky checkout
and in the oe-core directory.

Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.

Philip


Scott

-----Original Message-----
From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: Monday, June 24, 2013 7:57 AM
To: Robert P. J. Day
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 24 June 2013 15:47, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.
meta-yocto is what makes Poky Poky, otherwise it would be just oe-core
+ bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF,
which is one of the things that get munged as
bitbake+oe-core+meta-yocto becomes poky.

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


Re: linux-libc-header version mismatch?

Hans Beckérus <hans.beckerus@...>
 

On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker <paul@paulbarker.me.uk> wrote:
On 24 June 2013 17:19, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:

Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(
Summary: you can match them if you want, but we are testing across
several kernel versions and haven't found any issues (yet).
Just to point out - this is pretty common across linux distros as
well, otherwise all your software would have to be re-built every time
you updated the kernel.

--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk
Thanks Paul (and Bruce of course).
I now realize that this would break most systems after a major kernel upgrade ;)
From what I know/experienced so far is that the only thing that
usually breaks with a new major kernel version is our own kernel
drivers...

Hans


On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker <paul@paulbarker.me.uk> wrote:
On 24 June 2013 17:19, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:

Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(
Summary: you can match them if you want, but we are testing across
several kernel versions and haven't found any issues (yet).
Just to point out - this is pretty common across linux distros as
well, otherwise all your software would have to be re-built every time
you updated the kernel.

--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk