Re: [yocto] Best way to support multiple versions of Poky?
* Burton, Ross ross.bur...@intel.com [121126 14:58]: On 26 November 2012 13:55, Jerrod Peach pea...@lexmark.com 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Preempt-rt kernel build for beagleboard
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.bbunder 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
Hi Trevor, Le Mon, 26 Nov 2012 21:20:30 -0500, Trevor Woerner twoer...@gmail.com a écrit : On Mon, Nov 26, 2012 at 6:52 PM, Trevor Woerner twoer...@gmail.com 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
On Tue, Nov 27, 2012 at 5:39 AM, Eric Bénard e...@eukrea.com 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. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
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-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Trevor Woerner Sent: den 27 november 2012 03:21 To: Eren Türkay Cc: yocto@yoctoproject.org Subject: Re: [yocto] IMAGE_INSTALL_append workflow On Mon, Nov 26, 2012 at 6:52 PM, Trevor Woerner twoer...@gmail.com 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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
Le Tue, 27 Nov 2012 14:00:34 +, Jonas Jonsson L jonas.l.jons...@ericsson.com 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Forcing native binaries to build as 32-bit on a 64-bit host OS?
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Preempt-rt kernel build for beagleboard
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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/4] Fix remote deletion of files
- 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.grigoro...@intel.com
---
.../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
iremoved.length;i++) {
- if
(this.depends.contains(removed[i].getLocation().toString())) {
+ if
(this.depends.contains(removed[i].getLocationURI())) {
initialized = false;
return;
}
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 3/4] Fix bitbake session by disabling sanity checks
- 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.grigoro...@intel.com
---
.../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());
[yocto] [PATCH 4/4] Do not rely on AbstractHostShellOutputReader for waiting for command outputs
- 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.grigoro...@intel.com
---
.../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{
Re: [yocto] IMAGE_INSTALL_append workflow
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/ pgpIGycH7Ifpr.pgp Description: PGP signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need for offline binary configuration
Looking for comments. Thanks From: Bruce Ashfield [bruce.ashfi...@windriver.com] Sent: Thursday, November 22, 2012 12:59 AM To: Venkata ramana gollamudi Cc: yocto@yoctoproject.org; Sanil kumar; Hatle, Mark; 'dvh...@linux.intel.com' 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.ashfi...@windriver.com] Sent: Tuesday, November 20, 2012 8:53 PM To: Venkata ramana gollamudi Cc: yocto@yoctoproject.org; 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
Re: [yocto] IMAGE_INSTALL_append workflow
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] patchwork support for meta-freescale
On Tue, Nov 27, 2012 at 5:21 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Fri, Nov 23, 2012 at 5:13 PM, Otavio Salvador ota...@ossystems.com.br 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day rpj...@crashcourse.ca 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. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
Le Tue, 27 Nov 2012 12:24:06 -0500 (EST), Robert P. J. Day rpj...@crashcourse.ca 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
On Tue, 27 Nov 2012, Trevor Woerner wrote: On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day rpj...@crashcourse.ca 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Wiki Main page terrible sparse
Hi Jeff, Hi Maxin - it would be good to coordinate your effort with the rest of the community. Sure :) Can you let us know what you have in mind before starting? At first, I will try to address the suggestions of Alex along with other modifications based on our requirements. Also, please let me know if you have trouble with access. I don't see any account requests being held. I have checked the access rights and it works fine. Thanks! thanks Thanks and Regards, Maxin On Fri, Nov 23, 2012 at 6:16 AM, Maxin John maxin.j...@enea.com wrote: Hi Alex, Hello all, I can't help but notice that the main page of the Yocto Wiki looks somewhat underwhelming compared to the new site face. Can we please have a volunteer to update and beautify a bit the main page ? I am interested in this task. I have already sent a request for access to the Yocto Wiki. I'd think that we need to list current 1.4 pages, add/verify links to all main sections, and the Yocto logo, etc... We can discuss the list of activities in this mailing-list or in irc (nickname: maxin) Cheers, Alex Best Regards, Maxin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL_append workflow
On Tue, 27 Nov 2012, Trevor Woerner wrote: On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day rpj...@crashcourse.ca 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. for what it's worth, if you're building an image that's a variation of a core image, an alternate way of adding packages after the fact is: CORE_IMAGE_EXTRA_INSTALL = sysfsutils strace bash i just tested it and, when i added a new entry in that list, at least the fetching understood and fetched that new source and patched it. so it doesn't solve the original problem with IMAGE_INSTALL_append, but feel free to see if that variation works for you. again, it's only valid if you're building a core image or some variation thereof. 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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, November 27, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Attendees: Dave, MichaelH, Ciby, PaulE, ScottG, BjörnS, Ramana, KevinS, TomZ, Eren, AlexG, ALexD, Richard, BrianR,Jefro, LaurentiuP, Nitin, BruceA, RossB, ScottR, JeffP, MarkH, CristianI, DarrenH, DaveST, JessicaZ, Beth, Song, IoanaG. Agenda: * Opens collection - 5 min (Song) * Yocto 1.4 status - 20 min (Song/team) - This week will have RC1 for QA to run a full pass testing. - QA will send out report on the full pass testing on last weekly build. - M1 feature complete has come and gone. This week is the planning week for M2. Please schedule your features into M2 and make sure you understand the requirement and please consider holidays and your vacation. - Master status: Ross: a couple of problems, mostly green. Saul: connman issue. Mihai: looking at it. Seems to be autobuilder issue. Can fix it by increasing the timeout. * SWAT team rotation: Ross - LaurentiuP (Friday, RO national holiday, Beth will cover that day) * Opens - 10 min - Ramana: offline configuration tool. Have some ideas and thoughts, would like to hear more feedback on it. Especially from Mark. . Dave: It is a good idea. . RP: would like to do it in bitbake. Darren and Mark are working on similar things. . Mark: Initial idea is to use bitbake. Pass in packages, etc. without all recipe parsing, etc. . RP: The good place to discuss this is the mailing list. . Mark will respond this week. Darren will do so too. - Eren - location of the team. . Song: we have teams in US, UK, Romania, Canada, China. There are people here from Sweden, India, etc. We are across the globe. - Jefro: website and wiki. Thanks for everyone who provided feedback, new website was launched. We are going to setup engineering process for maintenance and production. Anyone interested to help, please let Jefro know. * Team Sharing - 20 min - Darren: have been working on ext for file generation code. Got a prototype for pre-populating files/directories, basic frameworks is there. Will have patches out soon. - RP: traveling, fixing bugs on autobuilder, sstates, etc. Been an interesting week, the autobuilder is mostly green now. - Cristian: trying to improve build appliance. Updated to a more recent version of poky repos. Network testing is fixed. Produced some build to test it. Tested in vmware player. Working on virualbox. - Radu: working system D. fixing some issues and failures on core-image-minimal. Will work on sato. Code is in contrib branch with my name and 'systemd', welcome comments and feedback. - LaurentiuP: working on package upgrades. Struggling with some relocation issues. It's fixed. Hopefully to move on to the next stage. - Iona: working on Eclipse for windows. Committed a few patches. A few other issues to be addressed, will send patches today. - MichaelH: Worked on bugzilla field description, newest version of Bugzilla has the feature. Making sure we have more hard drives. Holiday networking maintenance. Had 4 short network outages. Coming week, generation of the graphs RP asked. Recofnigration for testopia, etc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] Initialize bitbake session environment parse variables
Hi Ioana,
The patched won't apply and please rebase against eclipse-poky-windows and
resubmit.
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Ioana Grigoropol
Sent: Monday, November 26, 2012 2:05 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH 1/3] Initialize bitbake session environment parse
variables
- source oe-init-env for the connection shell
- parse environment variables
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../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
Re: [yocto] IMAGE_INSTALL_append workflow
This issue has been entered into the yocto bugzilla as: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3503 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Preempt-rt kernel build for beagleboard
Hi Bruce, Thanks for commenting :-) 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=metahttp://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 ? This was what puzzles me as well. I thought bitbake should pickup what is specified in beagleboard-preempt-rt.scc to produce the .config in the kernel build directory. But it did not, at least for the PREEMPT part. Below is the PREEMPT related configs in the .config without manually doing the menuconfig: # CONFIG_PREEMPT_RCU is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT__LL is not set # CONFIG_PREEMPT_RTB is not set # CONFIG_PREEMPT_RT_FULL is not set Follow your pointer, I checked linux/meta/top_tgt, it indeed points to meta/cfg/kernel-cache/bsp/beagleboard/beagleboard-preempt-rt.scc, which includes ktypes/preempt-rt (why not ktypes/preempt-rt.scc?). In ktypes/preempt-rt.cfg (included by ktypes/preempt-rt.scc), CONFIG_PREEMPT_RT_FULL=y is there. So why not this configuration fragment not picked up in the final .config? Cheers Pan Yu ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
