Date   

Re: IMAGE_INSTALL_append workflow

Eren Türkay <eren@...>
 

On Mon, Nov 26, 2012 at 10:47:31AM -0500, Trevor Woerner wrote:
I'm kinda surprised nobody jumped in on this one; either my question
is so silly it isn't worth anyone's time, or I'm the only one who
wants to add packages to an image after a full build. I know my
question has nothing to do with trace-cmd specifically, adding any
package after a full build results in the same problem.
I don't think you are the first person who wants to add a package to image after
the image has been built :)

The obvious problem would have been leading spaces in IMAGE_INSTALL_append but
you explicitly stated its correct. Normally, the class that's responsible for
image creation (image.bbclass) depends on the packages defined in IMAGE_INSTALL
so that the packages are built before the image creation begins.

image.bbclass, line 9
---------------------
RDEPENDS += "${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL}
${ROOTFS_BOOTSTRAP_INSTALL}"

On irc (#oe), Eric Benard tried IMAGE_INSTALL_append = " trace-cmd" after a full
build and reported that it built fine. I'm CCing him.

I believe that it will be better to include your <image> file and the files that
you changed so that it will be easier to debug. Mentioning your layers,
configuration, version of Yocto you use will also be helpful.

Regards,
Eren

--
. 73! DE TA1AET
http://erenturkay.com/


Re: my wiki page for using OE and meta-ti layer to build for panda ES

Evade Flow <evadeflow@...>
 

Love it! Any chance you could add an 'Advanced' or 'Next Steps'
section that shows how to go beyond a minimal build? Like, how to get
a working Qt stack into a custom image on the PandaBoard?

On Wed, Nov 21, 2012 at 2:44 PM, Robert P. J. Day <rpjday@...> wrote:

not strictly related to yocto but i figured some folks might be
interested in a recipe for using OE and the meta-ti layer to build a
bootable system for a panda ES:

http://www.crashcourse.ca/wiki/index.php/OE-Core%2C_meta-ti_and_the_PandaBoard_ES

feedback welcome.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: IMAGE_INSTALL_append workflow

Trevor Woerner
 

I'm kinda surprised nobody jumped in on this one; either my question
is so silly it isn't worth anyone's time, or I'm the only one who
wants to add packages to an image after a full build. I know my
question has nothing to do with trace-cmd specifically, adding any
package after a full build results in the same problem.

It would certainly seem odd that the yocto workflow assumes you always
know 100% ahead of time which packages you want in your final image. I
know when I was playing around with Hob this wasn't an issue: I would
simply add the new packages and Hob would build them and add them to
the image.

From what I have seen from skimming the documentation, the
documentation talks at length about how to add a new package to the
configuration, but it doesn't say what commands to issue after
modifying the config files. Obviously running "bitbake <image>" alone
doesn't work.

On Fri, Nov 23, 2012 at 1:27 PM, Trevor Woerner <twoerner@...> wrote:
There have been many emails and lots of documentation describing how
to add a package to a build, and that's all great.

Today I was playing around with an image I had already built and
decided I wanted to add a new package to the mix: trace-cmd. I added "
trace-cmd" (with the required leading space) to IMAGE_INSTALL_append
and re-ran my "bitbake <image>" command.

It failed:

Unable to resolve package trace-cmd

If I perform:

$ bitbake trace-cmd

and then

$ bitbake <image>

it works fine. What am I missing?

As it turns out, if I knew before my first build that I wanted
trace-cmd, I could have just added it as described above and
everything would have worked as well.

Best regards,
Trevor


Re: Best way to support multiple versions of Poky?

Burton, Ross <ross.burton@...>
 

On 26 November 2012 13:55, Jerrod Peach <peachj@...> wrote:
build-bundle (git repo with our layers + tools)
|
+-- meta-ourstuff (git submodule, i.e. separate repo locked to a specific
version within build-bundle)
+-- poky (another submodule)
|
+-- poky BB files (i.e. within meta, meta-yocto, etc.)
Guacamayo does something similar, although meta-outstuff isn't a
submodule of build-bundle.

Being able to branch a "next" branch that switched the poky revision
to the danny RC instead of denzil was very convenient.

Ross


Re: Best way to support multiple versions of Poky?

Jerrod Peach <peachj@...>
 

On Thu, Nov 22, 2012 at 3:35 AM, Chris Tapp <opensource@...> wrote:
I'm just getting round to moving from 'denzil' to 'danny'. I've got a layer that makes some changes to a few recipes through bbappend files.

However, 'danny' has bumped a few of these to a new version (which is good) which means I now have bbappend files that get a 'there is no matching bb file' errors when I try to build. This is easy to fix (generally just rename the bbappend to match the new version), but I would like the layer to be able to work with older versions of Poky - mainly in case I need to make changes to an existing project that hasn't be verified under 'danny'.

What's the best way to do this? All I can think of is to have another set of layers to use when building against a specific poky version:

meta-mystuff
|
+--poky-versions
   |
   +--denzil-specific
   +--danny-specific
   +--etc

Is there a more elegant solution?

Chris Tapp

opensource@...
www.keylevel.com



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

I don't know what sort of version control (if any) you're using around "meta-mystuff", so what I'm about to suggest may not be directly applicable to you.  Also, note that we have not actually deployed the scheme we've developed at our company yet (so there may be some reason it doesn't work that we haven't thought of yet), but here's the directory/repo structure we think will work for our code:

build-bundle (git repo with our layers + tools)
|
+-- meta-ourstuff (git submodule, i.e. separate repo locked to a specific version within build-bundle)
+-- poky (another submodule)
   |
   +-- poky BB files (i.e. within meta, meta-yocto, etc.)

When we release code, we'll create a tag in build-bundle.  If the released code needs to diverge from the state of our master, we'll branch, then tag.  Either way, if you want to build old code, you check out the tag and build it.  That should "just work" because what we see as the tools (i.e. everything in the poky directory) are being version-controlled along-side everything we've added, including .bbappend files in our layers that modify .bb files in the poky layer.  Of course, if you need to modify an old release, you'd branch off the release you wanted to modify.  So, if "denzil" is the current version and you need to modify a release created with "danny", you simply branch from that release, and all your .bbappend files and tools will be correct for the "danny" version of the Yocto tools.


Re: [PATCH resend][opkg-utils] opkg.py/opkg-build: fix creation of tar archives

Burton, Ross <ross.burton@...>
 

On 26 November 2012 13:19, Burton, Ross <ross.burton@...> wrote:
On 10 November 2012 09:33, Tomas Frydrych <tf+lists.yocto@...> wrote:
Could this be also applied to the danny branch (and perhaps even denzil)?
This was present in the Danny release. For Denzil you'd have to ask Scott...
Apologies, I was grepping the wrong branch...

*Now* it's locally in danny-next.

Ross


Re: mail list for Xilinx Zynq platform?

Elvis Dowson
 

Hi Daniel,
As far as I know, there is no specific mailing list for the Xilinx Zynq platform. I use the Xilinx forums to get help at the moment.

I personally have used Philip's meta-zynq layer to build a working u-boot and linux kernel image using Yocto. It works really well.

Using the Zynq is a little bit different than a standard ARM SOC. If you've worked with the TI OMAP series, you would be familiar with the x-loader component, that runs before u-boot. Well, the only difference here is that you need to use the Xilinx SDK to create a zynq_fsbl (first stage boot loader) project, using the defaults.

Once you've got the zynq_fsbl, you have a couple of options

a. Create a bootable image

Use the SDK create boot image utility to create a bootable image
- zynq_fsbl
- u-boot.bin
- system.bit (hardware bitstream)

You would rename the resultant file as BOOT.bin.

After that, you can drop the linux kernel uImage onto an SD card and boot linux as normal.

b. Download to the target using xmd and a tcl script

Use the xapp792 design files, to see how to download the binaries to the Zynq board using a JTAG cable. The tcl file is located in xapp792/zc702_video_3x_pipeline/ready_for_download/xmd_top.tcl

The whole process takes a couple of days to get used to. Let me know if you get stuck somewhere.

Best regards,

Elvis DOwson

On Nov 26, 2012, at 12:45 PM, Daniel Martinez Ramos <daniel.martinez@...> wrote:

Hi all,

I've found a bsp layer in Xilinx here http://forums.xilinx.com/t5/Embedded-Linux/Yocto-BSP-for-ZC-702/td-p/246932, which is pretty interesting.

Is any mail list under Yocto for the Xilinx Zinq platform?

Best regards,

Daniel Martinez



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


Re: [PATCH resend][opkg-utils] opkg.py/opkg-build: fix creation of tar archives

Burton, Ross <ross.burton@...>
 

On 10 November 2012 09:33, Tomas Frydrych <tf+lists.yocto@...> wrote:
Could this be also applied to the danny branch (and perhaps even denzil)?
This was present in the Danny release. For Denzil you'd have to ask Scott...

Ross


[PATCH 3/3] Validate Recipe autopopulated fields

Ioana Grigoropol <ioanax.grigoropol@...>
 

- validate that generated md5sums and sha256 sums are valid before populating the fields
- clear all previous commands output (like after source & bitbake -e) in order to limit output parsing

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../org/yocto/bc/remote/utils/RemoteHelper.java | 3 --
.../remote/utils/YoctoHostShellProcessAdapter.java | 8 ++++--
.../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 29 ++++++++++----------
3 files changed, 19 insertions(+), 21 deletions(-)

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 430dc6d..9c88ee7 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
@@ -301,8 +301,6 @@ public class RemoteHelper {
}

public static void runBatchRemote(IHost connection, List<YoctoCommand> cmds, IProgressMonitor monitor, boolean waitForOutput) throws CoreException {
- connection.getHostName();
- connection.getDefaultUserId();
try {
String remoteCommand = "";
for (YoctoCommand cmd : cmds) {
@@ -364,5 +362,4 @@ public class RemoteHelper {
}
return false;
}
-
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
index a772dc4..b75401c 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
@@ -11,7 +11,6 @@ import org.eclipse.rse.services.shells.IHostOutput;
import org.eclipse.rse.services.shells.IHostShell;
import org.eclipse.rse.services.shells.IHostShellChangeEvent;
import org.eclipse.rse.services.shells.IHostShellOutputReader;
-import org.eclipse.swt.widgets.Display;

public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
private ProcessStreamBuffer processStreamBuffer;
@@ -75,7 +74,6 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{

private void reportProgress(String info) {

-
if(calculator == null) {
updateMonitor(1);
} else {
@@ -125,7 +123,6 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
this.commandResponseHandler.response(value, false);
}
}
-
AbstractHostShellOutputReader absReader = (AbstractHostShellOutputReader)reader;
isAlive = absReader.isAlive();
isFinished = absReader.isFinished();
@@ -145,4 +142,9 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
public void setAlive(boolean isAlive) {
this.isAlive = isAlive;
}
+
+ public void clearProcessBuffer() {
+ this.processStreamBuffer.outputLines.clear();
+ this.processStreamBuffer.errorLines.clear();
+ }
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
index f45158f..eac1211 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
@@ -18,6 +18,7 @@ import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Set;
+import java.util.regex.Pattern;

import org.eclipse.core.resources.IContainer;
import org.eclipse.core.resources.IProject;
@@ -95,6 +96,8 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {
private static final String CONFIGURE_IN = "configure.in";
private static final String CONFIGURE_AC = "configure.ac";
private static final String AUTOTOOLS = "autotools";
+ private static final String md5Pattern = "^[0-9a-e]{32}$";
+ protected static final String sha256Pattern = "^[0-9a-e]{64}$";

public NewBitBakeFileRecipeWizardPage(ISelection selection, IHost connection) {
super("wizardPage");
@@ -302,14 +305,6 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {
} catch (Exception e) {
e.printStackTrace();
}
-// populateRecipeName(srcURI);
-// populateSrcUriChecksum(srcURI, monitor);
-//
-// URI extractDir = extractPackage(srcURI, monitor);
-// populateLicenseFileChecksum(extractDir, monitor);
-// updateSrcUri(createMirrorLookupTable(monitor), srcURI);
-// populateInheritance(extractDir, monitor);
-
} else {
String packageName = getSrcFileName(false).replace("-", "_");
fileText.setText(packageName + BB_RECIPE_EXT);
@@ -318,10 +313,7 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {
}
} catch (URISyntaxException e) {
e.printStackTrace();
- } /*catch (MalformedURLException e) {
- e.printStackTrace();
- }*/
-
+ }
}

private void handleLocalPopulate(URI srcURI, IProgressMonitor monitor) {
@@ -330,6 +322,7 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {
}

private void handleRemotePopulate(URI srcURI, IProgressMonitor monitor) throws Exception {
+ RemoteHelper.clearProcessBuffer(connection);
populateRecipeName(srcURI);
List<YoctoCommand> commands = new ArrayList<YoctoCommand>();

@@ -363,9 +356,12 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {
updateSrcUri(createMirrorLookupTable(monitor), srcURI);
populateInheritance(extractDir, monitor);

- md5sumText.setText(retrieveSum(md5YCmd));
- sha256sumText.setText(retrieveSum(sha256YCmd));
- checksumText.setText(RemoteHelper.createNewURI(extractDir, COPYING_FILE).toString() + ";md5=" + retrieveSum(licenseChecksumCmd));
+ String md5Val = retrieveSum(md5YCmd);
+ md5sumText.setText(Pattern.matches(md5Pattern, md5Val) ? md5Val : "");
+ String sha256Val = retrieveSum(sha256YCmd);
+ sha256sumText.setText(Pattern.matches(sha256Pattern, sha256Val) ? sha256Val : "");
+ String checkSumVal = retrieveSum(licenseChecksumCmd);
+ checksumText.setText(RemoteHelper.createNewURI(extractDir, COPYING_FILE).toString() + ";md5=" + (Pattern.matches(md5Pattern, checkSumVal) ? checkSumVal : ""));
}

private String retrieveSum(YoctoCommand cmd) {
@@ -409,6 +405,9 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {

private void populateInheritance(URI extractDir, IProgressMonitor monitor) {
IHostFile[] hostFiles = RemoteHelper.getRemoteDirContent(connection, metaDirLoc.getPath(), "", IFileService.FILE_TYPE_FILES, monitor);
+ if (hostFiles == null)
+ return;
+
for (IHostFile file: hostFiles) {
String fileName = file.getName();
if (fileName.equalsIgnoreCase(CMAKE_LIST)){
--
1.7.9.5


[PATCH 2/3] Fix Bitbake commander project wizard

Ioana Grigoropol <ioanax.grigoropol@...>
 

- do not run git task in a loop
- wait for the command to finish - use ModalContext.allowReadAndDispatch(false) - (needs some fixes for upstream RSE API - TBA)

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../yocto/bc/ui/wizards/install/InstallWizard.java | 27 ++++++++++----------
1 file changed, 14 insertions(+), 13 deletions(-)

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 dd2074c..d780cbf 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/InstallWizard.java
@@ -9,6 +9,7 @@ import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
import org.eclipse.jface.operation.IRunnableWithProgress;
+import org.eclipse.jface.operation.ModalContext;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.jface.wizard.WizardPage;
import org.eclipse.ptp.remote.core.IRemoteConnection;
@@ -114,12 +115,12 @@ public class InstallWizard extends FiniteStateWizard implements IWorkbenchWizard

if (((Boolean)options.get(GIT_CLONE)).booleanValue()) {
String[] cmd = {"/usr/bin/git clone --progress", "git://git.yoctoproject.org/poky.git", uri.getPath()};
+// String[] cmd = {"md5sum /home/builder/socks-gw"};
LongtimeRunningTask runningTask = new LongtimeRunningTask("Checking out Yocto git repository", cmd,
((IRemoteConnection)model.get(InstallWizard.SELECTED_CONNECTION)),
((IRemoteServices)model.get(InstallWizard.SELECTED_REMOTE_SERVICE)));
+ ModalContext.setAllowReadAndDispatch(false);
this.getContainer().run(false, false, runningTask);
-// while (!runningTask.isFinished)
-// Thread.sleep(2);
}

CommandResponseHandler cmdHandler = RemoteHelper.getCommandHandler(RemoteHelper.getRemoteConnectionByName(((IRemoteConnection)model.get(InstallWizard.SELECTED_CONNECTION)).getName()));
@@ -183,7 +184,7 @@ public class InstallWizard extends FiniteStateWizard implements IWorkbenchWizard

synchronized public void run(IProgressMonitor monitor)
throws InvocationTargetException, InterruptedException {
- boolean cancel = false;
+// boolean cancel = false;
try {
monitor.beginTask(taskName, TOTALWORKLOAD);

@@ -203,17 +204,17 @@ public class InstallWizard extends FiniteStateWizard implements IWorkbenchWizard
for (int i = 1; i < cmdArray.length; i++)
args += cmdArray[i] + " ";
try {
- while (!cancel) {
- if(monitor.isCanceled()) {
- cancel=true;
- throw new InterruptedException("User Cancelled");
- }
- boolean hasErrors = RemoteHelper.runCommandRemote(RemoteHelper.getRemoteConnectionByName(connection.getName()), new YoctoCommand(cmdArray[0], "", args), monitor);
- if (hasErrors)
- break;
+// while (!cancel) {
+// if(monitor.isCanceled()) {
+// cancel=true;
+// throw new InterruptedException("User Cancelled");
+// }
+ RemoteHelper.runCommandRemote(RemoteHelper.getRemoteConnectionByName(connection.getName()), new YoctoCommand(cmdArray[0], "", args), monitor);
+// if (hasErrors)
+// break;

- Thread.sleep(5000);
- }
+// Thread.sleep(5000);
+// }
} catch (Exception e) {
e.printStackTrace();
} finally {
--
1.7.9.5


[PATCH 1/3] Initialize bitbake session & environment parse variables

Ioana Grigoropol <ioanax.grigoropol@...>
 

- source oe-init-env for the connection shell
- parse environment variables

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../src/org/yocto/bc/bitbake/BBSession.java | 13 +++--
.../src/org/yocto/bc/bitbake/ShellSession.java | 53 ++++++++------------
2 files changed, 26 insertions(+), 40 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 e182d05..5f919c3 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
@@ -329,18 +329,17 @@ public class BBSession implements IBBSessionListener, IModelElement, Map {
}
}

- protected int checkExecuteError(String result, int code) {
+ protected void checkExecuteError(String result, boolean hasErrors) {
URI recipeURI = getDefaultDepends();
String text = "Parsing " + ((recipeURI != null) ? ("recipe " + recipeURI) : "base configurations");
- if (code != 0) {
+ if (hasErrors) {
text = text + " ERROR!\n" + result;
}else {
text = text + " SUCCESS.\n";
}
if(!silent) {
- displayInConsole(text, code, false);
+ displayInConsole(text, -1, false);
}
- return code;
}

protected void displayInConsole(final String result, final int code, boolean clear) {
@@ -377,9 +376,9 @@ public class BBSession implements IBBSessionListener, IModelElement, Map {
}
try {
if(!initialized) { //recheck
- int [] codes = {-1};
- String result = shell.execute(parsingCmd, codes);
- if(checkExecuteError(result, codes[0]) == 0) {
+ boolean hasErrors = false;
+ String result = shell.execute(parsingCmd, hasErrors);
+ if(!hasErrors) {
properties = parseBBEnvironment(result);
} else {
properties = parseBBEnvironment("");
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 a7ed3d6..a8c46dd 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
@@ -20,6 +20,7 @@ import java.io.Writer;

import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.NullProgressMonitor;
+import org.eclipse.rse.core.model.IHost;
import org.eclipse.rse.services.files.IHostFile;
import org.yocto.bc.remote.utils.RemoteHelper;
import org.yocto.bc.remote.utils.YoctoCommand;
@@ -92,43 +93,29 @@ public class ShellSession {
}

private void initializeShell(IProgressMonitor monitor) throws IOException {
-// try {
-// RemoteHelper.runCommandRemote(RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName()), new YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""), monitor);
-// } catch (CoreException e) {
-// e.printStackTrace();
-// }
-
-// process = Runtime.getRuntime().exec(shellPath);
-// pos = process.getOutputStream();
-//
-// if (root != null) {
-// out.write(execute("cd " + root.getAbsolutePath()));
-// }
-//
-// if (initCmd != null) {
-// out.write(execute("source " + initCmd));
-// }
+ try {
+ IHost connection = RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
+ RemoteHelper.runCommandRemote(connection, new YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""), monitor);
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
}

synchronized
public String execute(String command) throws IOException {
- return execute(command, (int [])null);
+ return execute(command, false);
}

synchronized
- public String execute(String command, int[] retCode) throws IOException {
- //FIXME : parse output
-// try {
-// RemoteHelper.runCommandRemote(RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName()), new YoctoCommand(command, root.getAbsolutePath(), ""), new NullProgressMonitor());
-// } catch (Exception e) {
-// e.printStackTrace();
-// }
-//
-// String errorMessage = null;
-// interrupt = false;
-// out.write(command);
-// out.write(LT);
-//
+ public String execute(String command, boolean hasErrors) throws IOException {
+ try {
+ IHost connection = RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
+ hasErrors = RemoteHelper.runCommandRemote(connection, new YoctoCommand(command, root.getAbsolutePath(), ""), new NullProgressMonitor());
+ return RemoteHelper.getProcessBuffer(connection).getMergedOutputLines();
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ return null;
// sendToProcessAndTerminate(command);
//
// if (process.getErrorStream().available() > 0) {
@@ -143,7 +130,7 @@ public class ShellSession {
// BufferedReader br = new BufferedReader(new InputStreamReader(process
// .getInputStream()));
//
- StringBuffer sb = new StringBuffer();
+// StringBuffer sb = new StringBuffer();
// String line = null;

// while (((line = br.readLine()) != null) && !line.endsWith(TERMINATOR) && !interrupt) {
@@ -169,8 +156,8 @@ public class ShellSession {
// if (errorMessage != null) {
// throw new IOException(errorMessage);
// }
-
- return sb.toString();
+//
+// return sb.toString();
}

synchronized
--
1.7.9.5


mail list for Xilinx Zynq platform?

Daniel Martinez Ramos <daniel.martinez@...>
 

Hi all,

I've found a bsp layer in Xilinx here http://forums.xilinx.com/t5/Embedded-Linux/Yocto-BSP-for-ZC-702/td-p/246932, which is pretty interesting.

Is any mail list under Yocto for the Xilinx Zinq platform?

Best regards,

Daniel Martinez


How to handle src.rpm packages

Christian Ege <chege@...>
 

Hello,

I am interested in how to handle source code inside of a src.rpm package. There had been a patch from Mark Hatle which handles the rpm packages inside the fetcher2. In his patch he suggests to handle Patches inside the rpm in the following way:


file://${WORKDIR}/mypatch.patch

When I tried this inside the SRC_URI declaration I always get en error like this:

NOTE: Running task 439 of 669 (ID: 4, /home/chris/src/poky-denzil/meta-stlinux/recipes-core/stslave/stslave_0.7.bb, do_fetch)
NOTE: package stslave-0.7-r1: task do_fetch: Started
ERROR: Function failed: Fetcher failure for URL: 'file:///home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/temp/log.do_fetch.25817
Log data follows:
| DEBUG: Trying PREMIRRORS
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['bzr', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['cvs', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['git', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['hg', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['osc', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['p4', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['svk', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', '/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', '', '', {}] comparing ['svn', '.*', '/.*', '', '', {}] to ['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: Trying Upstream
| ERROR: Function failed: Fetcher failure for URL: 'file:///home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz'. Unable to fetch URL from any source.

Yes of course I can just let fetcher2 extract all the files an afterwards apply the patches by hand. But I think there should be a more generic way to handle this. I hope I can get some hints how to solve this.




with kind regards,

Christian


[Package Report System]Upgrade recipes name list

Yocto Project Package Report System <package-reporting@...>
 

This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected.
Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version is unstable"
You can check the detail information at http://packages.yoctoproject.org/upgradepkgname


PackageName Version UpVersion Maintainer NoUpgradeReason
Upgradable Count: 0
Upgrade Total Count: 0
The based commit merge time is:
Tue Nov 20 13:06:48 2012 -0800
The based commit is:
commit 9cb9eadb844a4e05551b2c5811908c848cd50e59
Author: Ross Burton <ross.burton@...>
Date: Tue Nov 20 18:18:11 2012 +0000
Any problem, please contact Saul Wold <sgw@...>


[Package Report System]Manual check recipes name list

Yocto Project Package Report System <package-reporting@...>
 

This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check.
You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo


PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason
Manual Check Count: 0
Manual Need Check Count: 0
Any problem, please contact Saul Wold <sgw@...>


does meta-intel/meta-tlk layer require a README.sources file?

Robert P. J. Day
 

more annoying pedantry, but from what i read in the current yocto
BSP manual, a BSP layer *requires* a README.sources file, but there is
no such file in the meta-intel/meta-tlk layer, although i can
appreciate that that layer isn't *really* a BSP definition. or is it?

can someone clarify this? is there a clear explanation as to what
is required for a simple *layer* and what is required for an actual
BSP definition?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: inconsistent pages out there for setting up your yocto dev host

Wolfgang Denk <wd@...>
 

Dear Paul,

In message <3038126.PEqOPPdATB@helios> you wrote:

if you're on an allegedly supported distro, and you do an upgrade,
it's entirely possible that one of those bits of software gets
upgraded in a way that breaks OE/yocto, and by using ASSUME_PROVIDED,
you'll automatically start using that newer utility. or is the list
of supported distros specifically only those installed out of the box
and never updated? if that's the case, then, yes, i agree with your
position.
That's why we test specific versions of distributions, and with the Poky distro
config we warn the user if the distro/distro version is untested. It's rare
that you get that kind of breakage between major versions; if there were then
other applications are likely to be affected so it would be considered a
regression in that distro.
But of course there have always been, and will always be, such
regressions. Just look at Fedora 17 (one of the supported versions of
distributions), if one of the updates pulls in git version 1.7.11.7
and suddenly all git downloads using HTTP protocol will fail for you
(due to bug 865692, see https://bugzilla.redhat.com/show_bug.cgi?id=865692)

Actually it may make a lot of sense for certain configurations to
bootstrap more tools from a known version of the sources.

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: wd@...
Beware of the Turing Tar-pit in which everything is possible but
nothing of interest is easy.


IMAGE_INSTALL_append workflow

Trevor Woerner
 

There have been many emails and lots of documentation describing how
to add a package to a build, and that's all great.

Today I was playing around with an image I had already built and
decided I wanted to add a new package to the mix: trace-cmd. I added "
trace-cmd" (with the required leading space) to IMAGE_INSTALL_append
and re-ran my "bitbake <image>" command.

It failed:

Unable to resolve package trace-cmd

If I perform:

$ bitbake trace-cmd

and then

$ bitbake <image>

it works fine. What am I missing?

As it turns out, if I knew before my first build that I wanted
trace-cmd, I could have just added it as described above and
everything would have worked as well.

Best regards,
Trevor


Re: inconsistent pages out there for setting up your yocto dev host

Robert P. J. Day
 

On Fri, 23 Nov 2012, Paul Eggleton wrote:

Well, we don't test with any other value of ASSUME_PROVIDED. If you
add tools to ASSUME_PROVIDED that we would have otherwise built so
that the host tools are used, we haven't tested the build with those
host tools. Equally if you remove items from the default value of
ASSUME_PROVIDED, we don't necessarily fully test the system with
native tools that we don't normally build (although that's less
likely to be an issue than the other case).

I'm not saying you can't change the value of ASSUME_PROVIDED - just
that if you do and the build breaks, you get to keep both pieces :)
completely understood. for the sake of classroom work, i'm going to
experiment with adding extra entries to speed things up, and watch if
anything breaks. my first choice would be to add subversion to
ASSUME_PROVIDED -- that seems fairly safe, any moderately current
version of subversion should work.

thanks.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: inconsistent pages out there for setting up your yocto dev host

Paul Eggleton
 

On Friday 23 November 2012 09:31:39 Robert P. J. Day wrote:
On Thu, 22 Nov 2012, Paul Eggleton wrote:
On Thursday 22 November 2012 06:54:33 Robert P. J. Day wrote:
first, is ASSUME_PROVIDED technically completely superfluous?

it's clearly meant to speed up processing, but could one (if one
wanted) unset it and have the processing still work (albeit more
slowly, of course)?
If you like building things that you don't have to, sure, but I
wouldn't equate that to it being superfluous. Note that if you do
change this variable you are deviating from what has been tested, so
you do so at your own risk.
wait, this point interests me so indulge me for a minute.
obviously, there is a minimum collection of software one must install
before starting to use OE/yocto -- at the very least, say, the
fetching software -- so there will always be a page instructing a
developer to install that minimum.

afterwards, you can use ASSUME_PROVIDED to take advantage of that
software, correct? and that will certainly speed things up. but in
what way does that represent a "tested" configuration?
Well, we don't test with any other value of ASSUME_PROVIDED. If you add tools
to ASSUME_PROVIDED that we would have otherwise built so that the host tools
are used, we haven't tested the build with those host tools. Equally if you
remove items from the default value of ASSUME_PROVIDED, we don't necessarily
fully test the system with native tools that we don't normally build (although
that's less likely to be an issue than the other case).

I'm not saying you can't change the value of ASSUME_PROVIDED - just that if
you do and the build breaks, you get to keep both pieces :)

if you're on an allegedly supported distro, and you do an upgrade,
it's entirely possible that one of those bits of software gets
upgraded in a way that breaks OE/yocto, and by using ASSUME_PROVIDED,
you'll automatically start using that newer utility. or is the list
of supported distros specifically only those installed out of the box
and never updated? if that's the case, then, yes, i agree with your
position.
That's why we test specific versions of distributions, and with the Poky distro
config we warn the user if the distro/distro version is untested. It's rare
that you get that kind of breakage between major versions; if there were then
other applications are likely to be affected so it would be considered a
regression in that distro.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre