Date   

Re: IMAGE_INSTALL_append workflow

Robert P. J. Day
 

On Tue, 27 Nov 2012, Trevor Woerner wrote:

On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day
<rpjday@...> wrote:
and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.
Thank you for your testing and observations.

But I'd like to point out that in my tests, all the relevant files
have already been fetched. My DL_DIR already contains everything to
do with bash, trace-cmd, and various others that I have been
testing. The errors I am getting are not fetching-related errors,
but are errors because do_rootfs can't find any packages (since
packages relating to the recently-appended recipes have not been
built).

Somewhere in the guts of bitbake a modified IMAGE_INSTALL_append
variable is not being noticed; packages aren't being created (as
I've noticed) and sources aren't being downloaded (as you have just
noticed). But somehow do_rootfs is noticing the change and
complaining it can't find the necessary packages.
ah, quite so ... but it's still useful to note that the problem
extends even to the act of fetching. weird.

rday

--

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

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


Re: IMAGE_INSTALL_append workflow

Eric Bénard <eric@...>
 

Le Tue, 27 Nov 2012 12:24:06 -0500 (EST),
"Robert P. J. Day" <rpjday@...> a écrit :
and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.
It's not fetched because the build system fails to see the new package
as a dependencie of the image so that's not a fetching issue but a
more global one.

Eric


Re: IMAGE_INSTALL_append workflow

Trevor Woerner
 

On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day
<rpjday@...> wrote:
and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.

Thank you for your testing and observations.

But I'd like to point out that in my tests, all the relevant files
have already been fetched. My DL_DIR already contains everything to do
with bash, trace-cmd, and various others that I have been testing. The
errors I am getting are not fetching-related errors, but are errors
because do_rootfs can't find any packages (since packages relating to
the recently-appended recipes have not been built).

Somewhere in the guts of bitbake a modified IMAGE_INSTALL_append
variable is not being noticed; packages aren't being created (as I've
noticed) and sources aren't being downloaded (as you have just
noticed). But somehow do_rootfs is noticing the change and complaining
it can't find the necessary packages.


Re: [oe] patchwork support for meta-freescale

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Nov 27, 2012 at 5:21 AM, Otavio Salvador
<otavio@...> wrote:
On Fri, Nov 23, 2012 at 5:13 PM, Otavio Salvador
<otavio@...> wrote:
Hi,

Could patchwork support be added to meta-freescale? It'd allow for
easy handle of patches.
Ping?
These are hosted on different organizations... I don't see any repos
from git.yoctoproject.org on http://patches.openembedded.org/.
Although it would be nice to have.

-M


Re: IMAGE_INSTALL_append workflow

Robert P. J. Day
 

On Tue, 27 Nov 2012, Eren Türkay wrote:

On Tue, Nov 27, 2012 at 08:40:26AM -0500, Trevor Woerner wrote:
Thank you, Eric, for the confirmation.

Just to clarify for anyone following along: the problem isn't with
bash or trace-cmd themselves. If I perform the same steps but use
'bash' first, then 'trace-cmd', adding 'bash' succeeds but later
adding 'trace-cmd' causes 'trace-cmd' to fail in the same way
'bash' did when it was added second.
Since it's confirmed from different people, I think it would be
better to report it using bugzilla. I guess that it's not an
intended behaviour/feature of bitbake. Please inform the bug number
so that anyone who is interested can follow.
here's a test i made based on nothing but fetching. using oe-core,
i selected qemuarm, added this line at the bottom of my local.conf:

IMAGE_INSTALL_append = " sysfsutils strace"

and ran

$ bitbake -c fetchall core-image-minimal

when that was done, i checked my downloads directory for the results
of fetching (and patching) those two packages:

$ ls strace*
strace-4.7.tar.xz strace-4.7.tar.xz.done
$ ls sysfs*
sysfs.sh.done sysfsutils-2.1.0.tar.gz
sysfsutils-2.0.0-class-dup.patch.done sysfsutils-2.1.0.tar.gz.done
$

so that seemed to work fine. so i started over with a clean build
and did it in two stages. first, i reduced the line to:

IMAGE_INSTALL_append = " sysfsutils"

ran the same "fetchall" operation again, and verified that that
content had been fetched:

$ ls sysfs*
sysfs.sh.done sysfsutils-2.1.0.tar.gz
sysfsutils-2.0.0-class-dup.patch.done sysfsutils-2.1.0.tar.gz.done
$

i then *changed* the line in local.conf to:

IMAGE_INSTALL_append = " strace sysfsutils"

and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.

rday

--

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

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


Re: Need for offline binary configuration

Venkata ramana gollamudi <ramana.gollamudi@...>
 

Looking for comments. Thanks
________________________________________
From: Bruce Ashfield [bruce.ashfield@...]
Sent: Thursday, November 22, 2012 12:59 AM
To: Venkata ramana gollamudi
Cc: yocto@...; Sanil kumar; Hatle, Mark; 'dvhart@...'
Subject: Re: [yocto] Need for offline binary configuration

On 12-11-21 11:29 AM, Venkata ramana gollamudi wrote:
Reply inline

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@...]
Sent: Tuesday, November 20, 2012 8:53 PM
To: Venkata ramana gollamudi
Cc: yocto@...; Sanil kumar; Hatle, Mark
Subject: Re: [yocto] Need for offline binary configuration

On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:
Poky allows to build custom Linux for you, but we have cases where
the post build customization is required, like user-addition, network
configuration, service control. Even selecting the required packages
can be a post build activity.

The current model requires the image to be rebuilt to support these
configuration.
Offline Configuration tool (OCT), which allows a binary image
customization before making a final target image. This case will be
more evident in larger companies, where platform teams, product teams ,
application teams are distributed and Linux build from source will be
owned and lab tested by a single team, like platform team. Other teams
just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated
from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages
into final target image.
b) Provision to select external binary packages like ADT compiled
applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model,
following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and
Hob can work on this package pool to select packages, configure and
generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without
build options but only with binary package selection. Configuration GUI
needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and
overall organization as they will be intended for different users.

Is there some overlap between this point and the other ongoing
discussions
about image construction, deployment and package management ?

i.e. this thread:

[OE-core] RFC: OE-Core image creation and deployment

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-
July/026938.html

These may already be coordinated, but I do see some common threads and
it would be nice to make sure everything will work together and that we
aren't duplicating effort!

Cheers,

Bruce
Bruce, Thanks for the information. After your reply, I have gone through the discussions and agree that binary pool is in similar lines. Great to see that the realization happening in yocto1.4.
Understood that package-feed can be used to generate the target image.

Is there any RFC/mail/wiki available explaining how the configuration(like fstype) during image generation will be realized?
Not that I know of. It is still under design last I heard, but MarkH is the
person to provide the details. He's out of the office at the moment, but
I'm sure that when he is back he can provide plenty of information.


I am looking for post build configuration tool, which allows the product team users also to configure users, network, services etc .
Agreed. I see this as something to start with, since it doesn't overlap
with the other efforts (that I know of), and when I first read your
email I thought it was the main focus. When you continued into image
creation and package selection, that's when I noted the overlap.

Image type, file system and Partition configuration can be one of them.
I expect the product team users who configures image and generates target image, will have a little or no knowledge of bitbake, also needs easy installation and less dependencies.

Can look in this context, how HOB will fit into this scenario or needs a new tool.
Keeping the number of tools low is a good thing, so hopefully it can fit
within the existing options.



2) Binary package pool can be a minimal/partial sstate-cache, as
complete sstate-cache is quite big and not required for product teams
as they are not expected to build but just need to select and
configure.
I think it is sufficient to keep the minimal binaries from
sstate-cache which are required to execute image.bbclass, do_rootfs
task to generate image.
Point 2, No longer applicable as package-feed is a binary pool.

3) Along with specific configuration UI implementation, a generic
configuration model similar to kernel kconfig and menuconfig can be
considered, in cases where more detailed offline configurations is
required like detailed security configuration.
Point 3, still can be thought about.
There have been other menuconfig efforts in the past (that I've heard
about, but not had direct involvement), so doing some research in this
area would be appropriate as well.

cheers,

Bruce



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


Re: IMAGE_INSTALL_append workflow

Eren Türkay <eren@...>
 

On Tue, Nov 27, 2012 at 08:40:26AM -0500, Trevor Woerner wrote:
Thank you, Eric, for the confirmation.

Just to clarify for anyone following along: the problem isn't with
bash or trace-cmd themselves. If I perform the same steps but use
'bash' first, then 'trace-cmd', adding 'bash' succeeds but later
adding 'trace-cmd' causes 'trace-cmd' to fail in the same way 'bash'
did when it was added second.
Since it's confirmed from different people, I think it would be better to report
it using bugzilla. I guess that it's not an intended behaviour/feature of
bitbake. Please inform the bug number so that anyone who is interested can
follow.

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


Re: Preempt-rt kernel build for beagleboard

Bruce Ashfield <bruce.ashfield@...>
 

On 12-11-27 05:23 AM, Yu Pan wrote:
I started looking at Yocto 2 weeks back. Despite the complexity in
kernel building, I found it quite hard to locate information on
preempt-rt build. I was trying to build linux-yocto-rt for beagleboard
from "danny" and the linux-yocto-3.4 kernel, and it seems to be working.
I'd like to share how one can do that in this thread.

Since the kernel does not include an official preempt-rt branch for
beagleboard yet, I choose to directly use the standard/preempt-rt/base
branch. I guess this should work for the preempt-rt kernel, from the
fact that the standard kernel (non preempt-rt) used for beagleboard from
the standard/beagleboard branch is basically identical to that from the
standard/base branch.
Correct. If you don't have any board specific patches, working with
an existing branch in the tree is fine.


Here is what I did.
1. Under poky/meta-yocto-bsp/recipes-kernel/linux, I added a
linux-yocto-rt_3.4.bbappend recipe containing the following lines. The
SRCREV value used is the same as the one in the base
linux-yocto-rt_3.4.bb <http://linux-yocto-rt_3.4.bb> under
poky/meta/recipes/kernel.

KBRANCH_beagleboard = "standard/preempt-rt/base"
SRCREV_machine_beagleboard ?= "5705c8037d2c47938034ead87c70ae3ebef552f7"
COMPATIBLE_MACHINE_beagleboard = "beagleboard"
Also note that the yocto-bsp tool allows the extension of an existing
BSP or kernel to a new board. It should provide some of what you
did via editing the files, I added TomZ in case I've misspoken about
what the tools do in this area.

But what you have above is correct.


2. Modified the PREFERRED_PROVIDER_virtual/kernel variable in
poky/meta-yocto-bsp/conf/machine/beagleboard.conf to "linux-yocto-rt".

3. "bitbake linux-yocto-rt -c menuconfig" to set the Preemption Model to
"Fully Preemptible Kernel (RT)".
You shouldn't have needed to do this part, since the board already has
a preempt-rt BSP description:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.4/tree/meta/cfg/kernel-cache/bsp/beagleboard/beagleboard-preempt-rt.scc?h=meta

And when you build the linux-yocto-rt kernel with that board, that
description should be found, and it enables all the base options already.

If you look in your build, what does the file 'linux/meta/top_tgt'
contain ?

Cheers,

Bruce


4. "bitbake linux-yocto-rt"

5. "bitbake core-image-rt" which includes some realtime test programs on
top of core-image-minimal.

I did some cyclictest on beagleboard using the generated kernel and
image with "/usr/bin/cyclictest -p95 -m". The results did show huge
improvement on max latency especially under load.

Hope it helps.

Cheers
Pan Yu


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


[PATCH 4/4] Do not rely on AbstractHostShellOutputReader for waiting for command outputs

Ioana Grigoropol <ioanax.grigoropol@...>
 

- AbstractHostShellReader is designed such that it will block in a read from the pipeline when the command is finished its execution, therefore we should not wait for this variable to be set because it will eventually block.
Instead we will acquire a semaphore each time we run a command and wait for the first prompt line that comes after it, in order to parse the output.

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../org/yocto/bc/remote/utils/RemoteHelper.java | 21 ++++--
.../remote/utils/YoctoHostShellProcessAdapter.java | 68 +++++++++++++++++++-
2 files changed, 80 insertions(+), 9 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 9c88ee7..e017d2a 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
@@ -290,13 +290,15 @@ public class RemoteHelper {
hostShellProcessAdapter.setMonitor(monitor);
getHostShell(connection).writeToShell(remoteCommand);

- try {
- while (!hostShellProcessAdapter.isFinished() && hostShellProcessAdapter.isAlive()) {
- Thread.sleep(2);
- }
- } catch (Exception e) {
- e.printStackTrace();
- }
+// try {
+// while (!hostShellProcessAdapter.isFinished() && hostShellProcessAdapter.isAlive()) {
+// Thread.sleep(2);
+// }
+//// System.out.println(">>>>>>>>>>>>>>>>>>>>finished command " + remoteCommand);
+// } catch (Exception e) {
+// e.printStackTrace();
+// }
+//
return hostShellProcessAdapter.hasErrors();
}

@@ -362,4 +364,9 @@ public class RemoteHelper {
}
return false;
}
+
+ public static void clearProcessBuffer(IHost connection) {
+ getHostShellProcessAdapter(connection).clearProcessBuffer();
+ }
+
}
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 b75401c..79a62e0 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
@@ -1,6 +1,7 @@
package org.yocto.bc.remote.utils;

import java.io.IOException;
+import java.util.concurrent.Semaphore;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

@@ -13,6 +14,10 @@ import org.eclipse.rse.services.shells.IHostShellChangeEvent;
import org.eclipse.rse.services.shells.IHostShellOutputReader;

public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
+ private String commandPrompt = null;
+ private static final String ROOT = "root";
+ private static final String PROMPT_USER_CH = "$";
+ private static final String PROMPT_ROOT_CH = "#";
private ProcessStreamBuffer processStreamBuffer;
private CommandResponseHandler commandResponseHandler;
private boolean isFinished;
@@ -20,7 +25,34 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
private int reportedWorkload;
private IProgressMonitor monitor;
private boolean isAlive;
+
+ private String lastCommand;
+ private boolean waitForOutput;
+ private String endChar = null;
+
+ private Semaphore sem;

+ public String getLastCommand() {
+ return lastCommand;
+ }
+
+ public synchronized void setLastCommand(String lastCommand) {
+// if (waitForOutput) {
+ try {
+ // there are still some processes that might take a long time and if we do not wait for them,
+ // then the semaphore will not be released, because an interrupted exception will occur
+ Thread.sleep(2000);
+ System.out.println(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>semaphore aquire");
+ sem.acquire();
+ this.lastCommand = lastCommand.trim();
+ System.out.println(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>last command set " + lastCommand);
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+// }
+ }
+
+
public IProgressMonitor getMonitor() {
return monitor;
}
@@ -50,6 +82,9 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
this.processStreamBuffer = processStreamBuffer;
this.commandResponseHandler = commandResponseHandler;
this.calculator = new GitCalculatePercentage();
+ this.sem = new Semaphore(1);
+ this.lastCommand = "";
+
}

private void updateMonitor(final int work){
@@ -106,6 +141,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
if (value.isEmpty()) {
continue;
}
+ setCommandPrompt(value);
System.out.println(value);
this.processStreamBuffer.addErrorLine(value);
this.commandResponseHandler.response(value, false);
@@ -116,18 +152,38 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
if (value.isEmpty()) {
continue;
}
-
+ setCommandPrompt(value);
+ if (value.startsWith(commandPrompt) && value.endsWith(endChar) &&
+ !value.endsWith(lastCommand) && processStreamBuffer.getLastOutputLineContaining(lastCommand) != null /*&& waitForOutput*/) {
+ System.out.println(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Sem release");
+ sem.release();
+ }
+
reportProgress(value);
System.out.println(value);
this.processStreamBuffer.addOutputLine(value);
this.commandResponseHandler.response(value, false);
}
}
+
AbstractHostShellOutputReader absReader = (AbstractHostShellOutputReader)reader;
isAlive = absReader.isAlive();
isFinished = absReader.isFinished();
}
-
+ private void setCommandPrompt(String value) {
+ if (commandPrompt == null) {
+ if (value.startsWith(ROOT) && value.indexOf(PROMPT_ROOT_CH) != -1) {
+ int end = value.indexOf(PROMPT_ROOT_CH);
+ commandPrompt = value.substring(0, end);
+ endChar = PROMPT_ROOT_CH;
+ } else if (value.indexOf(PROMPT_USER_CH) != -1) {
+ int end = value.indexOf(PROMPT_USER_CH);
+ commandPrompt = value.substring(0, end);
+ endChar = PROMPT_USER_CH;
+ }
+
+ }
+ }
public boolean isFinished() {
return isFinished;
}
@@ -143,6 +199,14 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter{
this.isAlive = isAlive;
}

+ public boolean isWaitForOutput() {
+ return waitForOutput;
+ }
+
+ public void setWaitForOutput(boolean waitForOutput) {
+ this.waitForOutput = waitForOutput;
+ }
+
public void clearProcessBuffer() {
this.processStreamBuffer.outputLines.clear();
this.processStreamBuffer.errorLines.clear();
--
1.7.9.5


[PATCH 3/4] Fix bitbake session by disabling sanity checks

Ioana Grigoropol <ioanax.grigoropol@...>
 

- when creating a shell session for Bitbake, we cannot run "bitbake -e -b recipe.bb" just by setting DISABLE_SANITY_CHECKS=1; we must first append DISABLE_SANITY_CHECKS to BB_ENV_EXTRAWHITE

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../src/org/yocto/bc/bitbake/BBRecipe.java | 10 +++++-----
.../src/org/yocto/bc/bitbake/ShellSession.java | 16 +++++++++-------
2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
index 7682aee..6a33ade 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBRecipe.java
@@ -20,24 +20,24 @@ import java.net.URI;
*/
public class BBRecipe extends BBSession {
private final BBSession session;
- private final URI filePath;
+ private final URI fileURI;

public BBRecipe(BBSession session, URI filePath) throws IOException {
super(session.shell, session.pinfo.getURI());
this.session = session;
- this.filePath = filePath;
- this.parsingCmd = "DISABLE_SANITY_CHECKS=1 bitbake -e -b " + filePath;
+ this.fileURI = filePath;
+ this.parsingCmd = "DISABLE_SANITY_CHECKS=\"1\" bitbake -e -b " + filePath.getPath();
}

@Override
public void initialize() throws Exception {
if (this.size() == 0) {
- System.out.println("Failed to parse " + filePath);
+ System.out.println("Failed to parse " + fileURI);
//throw new IOException("Failed to parse " + filePath);
}
}

protected URI getDefaultDepends() {
- return this.filePath;
+ return this.fileURI;
}
}
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 a8c46dd..edff746 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
@@ -46,6 +46,7 @@ public class ShellSession {
*/
public static final String TERMINATOR = "#234o987dsfkcqiuwey18837032843259d";
public static final String LT = System.getProperty("line.separator");
+ public static final String exportCmd = "export BB_ENV_EXTRAWHITE=\"DISABLE_SANITY_CHECKS $BB_ENV_EXTRAWHITE\"";

public static String getFilePath(String file) throws IOException {
File f = new File(file);
@@ -69,7 +70,7 @@ public class ShellSession {

private OutputStream pos = null;
//private File initFile = null;
- private String shellPath = null;
+// private String shellPath = null;
private final String initCmd;
private final IHostFile root;
// private final Writer out;
@@ -84,10 +85,10 @@ public class ShellSession {
// } else {
// this.out = out;
// }
- if (shellType == SHELL_TYPE_SH) {
- shellPath = "/bin/sh";
- }
- shellPath = "/bin/bash";
+// if (shellType == SHELL_TYPE_SH) {
+// shellPath = "/bin/sh";
+// }
+// shellPath = "/bin/bash";

initializeShell(new NullProgressMonitor());
}
@@ -95,7 +96,8 @@ public class ShellSession {
private void initializeShell(IProgressMonitor monitor) throws IOException {
try {
IHost connection = RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
- RemoteHelper.runCommandRemote(connection, new YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""), monitor);
+ RemoteHelper.runCommandRemote(connection, new YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""), monitor);
+ RemoteHelper.runCommandRemote(connection, new YoctoCommand(exportCmd, root.getAbsolutePath(), ""), monitor);
} catch (Exception e) {
e.printStackTrace();
}
@@ -110,7 +112,7 @@ public class ShellSession {
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());
+ hasErrors = RemoteHelper.runCommandRemote(connection, new YoctoCommand(command, root.getAbsolutePath() + "/build/", ""), new NullProgressMonitor());
return RemoteHelper.getProcessBuffer(connection).getMergedOutputLines();
} catch (Exception e) {
e.printStackTrace();
--
1.7.9.5


[PATCH 2/4] Fix md5sum & sha256sum pattern checks

Ioana Grigoropol <ioanax.grigoropol@...>
 

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

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 eac1211..f1d90c9 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
@@ -96,8 +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}$";
+ private static final String md5Pattern = "^[0-9a-f]{32}$";
+ protected static final String sha256Pattern = "^[0-9a-f]{64}$";

public NewBitBakeFileRecipeWizardPage(ISelection selection, IHost connection) {
super("wizardPage");
@@ -323,6 +323,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>();

--
1.7.9.5


[PATCH 1/4] Fix remote deletion of files

Ioana Grigoropol <ioanax.grigoropol@...>
 

- when deleting a file from a remote directory use the URI and not the location of the file which is null

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../src/org/yocto/bc/bitbake/BBSession.java | 6 +++---
1 file changed, 3 insertions(+), 3 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 5f919c3..c5354a4 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
@@ -80,7 +80,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 = "DISABLE_SANITY_CHECKS=\"1\" bitbake -e";
}

public BBSession(ShellSession ssession, URI projectRoot, boolean silent) throws IOException {
@@ -376,7 +376,7 @@ public class BBSession implements IBBSessionListener, IModelElement, Map {
}
try {
if(!initialized) { //recheck
- boolean hasErrors = false;
+ boolean hasErrors = false;
String result = shell.execute(parsingCmd, hasErrors);
if(!hasErrors) {
properties = parseBBEnvironment(result);
@@ -725,7 +725,7 @@ public class BBSession implements IBBSessionListener, IModelElement, Map {
try {
if (initialized && (removed != null || changed != null)) {
for(int i=0;removed != null && i<removed.length;i++) {
- if (this.depends.contains(removed[i].getLocation().toString())) {
+ if (this.depends.contains(removed[i].getLocationURI())) {
initialized = false;
return;
}
--
1.7.9.5


Re: Forcing native binaries to build as 32-bit on a 64-bit host OS?

Paul Eggleton
 

On Tuesday 20 November 2012 14:27:30 Jerrod Peach wrote:
My company has traditionally built all their code on 32-bit systems for
32-bit target architectures. We're now trying to move our build hosts to
64-bit OSes, but that's presenting us with a bit of a problem: some
non-trivial number of native packages don't want to properly build 64-bit
binaries. Rather than fix all those issues right now, we'd like to build
everything as a 32-bit binary on a 64-bit OS. The problem is, I'm not sure
how I'd go about forcing that to happen. Is there some simple mechanism I
can use to force all native packages to build as 32-bit on a 64-bit system?
Sorry for the delay in replying. I've not had to do this myself but I suspect
something like this might do it:

BUILD_ARCH = "i686"

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: IMAGE_INSTALL_append workflow

Eric Bénard <eric@...>
 

Le Tue, 27 Nov 2012 14:00:34 +0000,
Jonas Jonsson L <jonas.l.jonsson@...> a écrit :

I can also confirm this.

A package (I've tried with diffutils & bash) must be built separately before it's added to an image via IMAGE_INSTALL_append.
that seems to work the first time you add something using
IMAGE_INSTALL_append.
Then it fails when you add packages later (bitbake wants to install
the package in the image but doesn't trigger the build of the package
before).

Eric


Re: IMAGE_INSTALL_append workflow

Jonas Jonsson L <jonas.l.jonsson@...>
 

I can also confirm this.

A package (I've tried with diffutils & bash) must be built separately before it's added to an image via IMAGE_INSTALL_append.

/Jonas - fetched poky today

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Trevor Woerner
Sent: den 27 november 2012 03:21
To: Eren Türkay
Cc: yocto@...
Subject: Re: [yocto] IMAGE_INSTALL_append workflow

On Mon, Nov 26, 2012 at 6:52 PM, Trevor Woerner <twoerner@...> wrote:
I haven't yet figured out if the "PREFERRED_PROVIDER_virtual/kernel =
"linux-yocto-rt"" line might be the culprit.
No, it is not related, this problem doesn't need any fancy configuration features. This problem is reproducible with just the plain qemux86 machine and the core-image-minimal image.
Also, before my latest tests I pulled
the latest git repo.

To reproduce this problem:

- use the latest git repositories
- run "source poky/oe-init-build-env qemux86"
- make no modifications to conf/bblayers.conf
- make no changes to conf/local.conf
- run "bitbake core-image-minimal"

After that completes successfully add the following line to your
conf/local.conf:

IMAGE_INSTALL_append = " trace-cmd"

- re-run the build "bitbake core-image-minimal"

This should complete successfully. When it does, modify the last line of conf/local.conf to be:

IMAGE_INSTALL_append = " trace-cmd bash"

- try re-running the build now "bitbake core-image-minimal". It fails for me as I have detailed in my previous emails.

If I manually do:

$ bitbake bash
$ bitbake core-image-minimal

everything succeeds and my image contains 'bash'. But something tells me there's a bug in there somewhere.
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: IMAGE_INSTALL_append workflow

Trevor Woerner
 

On Tue, Nov 27, 2012 at 5:39 AM, Eric Bénard <eric@...> wrote:
I confirm the problem when following this procedure step by step.

Thank you, Eric, for the confirmation.

Just to clarify for anyone following along: the problem isn't with
bash or trace-cmd themselves. If I perform the same steps but use
'bash' first, then 'trace-cmd', adding 'bash' succeeds but later
adding 'trace-cmd' causes 'trace-cmd' to fail in the same way 'bash'
did when it was added second.


Re: IMAGE_INSTALL_append workflow

Eric Bénard <eric@...>
 

Hi Trevor,

Le Mon, 26 Nov 2012 21:20:30 -0500,
Trevor Woerner <twoerner@...> a écrit :

On Mon, Nov 26, 2012 at 6:52 PM, Trevor Woerner <twoerner@...> wrote:
I haven't yet figured out if the "PREFERRED_PROVIDER_virtual/kernel =
"linux-yocto-rt"" line might be the culprit.
No, it is not related, this problem doesn't need any fancy
configuration features. This problem is reproducible
with just the plain qemux86 machine and the core-image-minimal image.
Also, before my latest tests I pulled
the latest git repo.

To reproduce this problem:

- use the latest git repositories
- run "source poky/oe-init-build-env qemux86"
- make no modifications to conf/bblayers.conf
- make no changes to conf/local.conf
- run "bitbake core-image-minimal"

After that completes successfully add the following line to your
conf/local.conf:

IMAGE_INSTALL_append = " trace-cmd"

- re-run the build "bitbake core-image-minimal"

This should complete successfully. When it does, modify the last line
of conf/local.conf to be:

IMAGE_INSTALL_append = " trace-cmd bash"

- try re-running the build now "bitbake core-image-minimal". It fails
for me as I have detailed in my previous emails.

If I manually do:

$ bitbake bash
$ bitbake core-image-minimal

everything succeeds and my image contains 'bash'. But something tells
me there's a bug in there somewhere.
I confirm the problem when following this procedure step by step.

with bitbake -e we see that bash is in RDEPENDS and in IMAGE_INSTALL
with bitbake -g we see that bash is not present in any of the
*depends.dot files

Eric


Preempt-rt kernel build for beagleboard

Yu Pan <panyu2000@...>
 

I started looking at Yocto 2 weeks back. Despite the complexity in kernel building, I found it quite hard to locate information on preempt-rt build. I was trying to build linux-yocto-rt for beagleboard from "danny" and the linux-yocto-3.4 kernel, and it seems to be working. I'd like to share how one can do that in this thread.

Since the kernel does not include an official preempt-rt branch for beagleboard yet, I choose to directly use the standard/preempt-rt/base branch. I guess this should work for the preempt-rt kernel, from the fact that the standard kernel (non preempt-rt) used for beagleboard from the standard/beagleboard branch is basically identical to that from the standard/base branch.

Here is what I did.
1. Under poky/meta-yocto-bsp/recipes-kernel/linux, I added a linux-yocto-rt_3.4.bbappend recipe containing the following lines. The SRCREV value used is the same as the one in the base linux-yocto-rt_3.4.bb under poky/meta/recipes/kernel.

  KBRANCH_beagleboard = "standard/preempt-rt/base" 
  SRCREV_machine_beagleboard ?= "5705c8037d2c47938034ead87c70ae3ebef552f7" 
  COMPATIBLE_MACHINE_beagleboard = "beagleboard"

2. Modified the PREFERRED_PROVIDER_virtual/kernel variable in poky/meta-yocto-bsp/conf/machine/beagleboard.conf to "linux-yocto-rt".

3. "bitbake linux-yocto-rt -c menuconfig" to set the Preemption Model to "Fully Preemptible Kernel (RT)".

4. "bitbake linux-yocto-rt"

5. "bitbake core-image-rt" which includes some realtime test programs on top of core-image-minimal.

I did some cyclictest on beagleboard using the generated kernel and image with "/usr/bin/cyclictest -p95 -m". The results did show huge improvement on max latency especially under load.

Hope it helps.

Cheers
Pan Yu


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

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

On 26 November 2012 20:44, Tom Zanussi <tom.zanussi@...> wrote:
The meta-tlk layer isn't a BSP layer - it's a layer used to add the
'time limited kernel' feature to images built from a meta-intel BSP
layer and distributed with that layer e.g. in the downloadable tarballs
available on the Yocto downloads page.

It's a meta-intel-only layer and has no meaning unless coupled with a
meta-intel BSP layer, which does always includes a README.sources of its
own, and so doesn't itself need one.
It's probably worth adding basically this as the README so that anyone
who comes across it knows what it is.

Ross


Re: Best way to support multiple versions of Poky?

Anders Darander
 

* Burton, Ross <ross.burton@...> [121126 14:58]:

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.
At ChargeStorm we're using a similar scheme to Guacamayo, i.e. we have
our repo with our recipes, bsp's, distro config etc. in our own
meta-*-directories. And the we have oe-core, meta-oe, and/or poky and
whatever layers we're using as submodules.

Being able to branch a "next" branch that switched the poky revision
to the danny RC instead of denzil was very convenient.
Indeed, and also to be able to create a next branch halfway between
denzil and danny, to be able to port / adapt some recipe that required
bigger changes at about the same time those occured in poky-master (or
oe-core master).

Thus, I'm pretty satisfied with our structure for the moment, though
everything can be improved.

Cheers,
Anders

--
Anders Darander
ChargeStorm AB / eStorm AB