[yocto] psplash_git.bb: Error when building with icecc
Hi all, i just found an error building core-image-basic with icecc
inherited:
NameError: global name 'set_icecc_env' is not defined
ERROR: The stack trace of python calls that resulted in this
exception/failure was:
ERROR: File do_compile, line 26, in module
ERROR:
ERROR: File do_compile, line 3, in do_compile
ERROR:
ERROR: The code that was being executed was:
ERROR: 0022:bb.build.exec_func(oe_runmake, d)
ERROR: 0023:shutil.copyfile(psplash, outputfile)
ERROR: 0024:
ERROR: 0025:
ERROR: *** 0026:do_compile(d)
ERROR: 0027:
ERROR: [From file: 'do_compile', lineno: 26, function: module]
ERROR: 0001:
ERROR: 0002:def do_compile(d):
ERROR: *** 0003:set_icecc_env
ERROR: 0004:import shutil, commands
ERROR: 0005:
ERROR: 0006:# Build a separate executable for each splash image
ERROR: 0007:convertscript = %s/make-image-header.sh %
d.getVar('S', True)
ERROR: [From file: 'do_compile', lineno: 3, function: do_compile]
ERROR: Function failed: do_compile
Seems that icecc compile_prepend (set_icecc_env shell function) gets prepended
into psplash compile that is written in python. How to deal with it, and
in general, is that possible to mix languages in prepend/append?
I'm using poky master and icecc is working great!
Cheers,
Francesco
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] psplash_git.bb: Error when building with icecc
On Thu, Apr 25, 2013 at 09:34:09AM +0200, Francesco Del Degan wrote:
Hi all, i just found an error building core-image-basic with icecc
inherited:
You can send patch extending blacklist defined in icecc.bbclass:
system_package_blacklist = [ uclibc, glibc, gcc, bind, u-boot,
dhcp-forwarder, enchant, connman, orbit2 ]
user_package_blacklist = (d.getVar('ICECC_USER_PACKAGE_BL') or ).split()
or add psplash to ICECC_USER_PACKAGE_BL
NameError: global name 'set_icecc_env' is not defined
ERROR: The stack trace of python calls that resulted in this
exception/failure was:
ERROR: File do_compile, line 26, in module
ERROR:
ERROR: File do_compile, line 3, in do_compile
ERROR:
ERROR: The code that was being executed was:
ERROR: 0022:bb.build.exec_func(oe_runmake, d)
ERROR: 0023:shutil.copyfile(psplash, outputfile)
ERROR: 0024:
ERROR: 0025:
ERROR: *** 0026:do_compile(d)
ERROR: 0027:
ERROR: [From file: 'do_compile', lineno: 26, function: module]
ERROR: 0001:
ERROR: 0002:def do_compile(d):
ERROR: *** 0003:set_icecc_env
ERROR: 0004:import shutil, commands
ERROR: 0005:
ERROR: 0006:# Build a separate executable for each splash image
ERROR: 0007:convertscript = %s/make-image-header.sh %
d.getVar('S', True)
ERROR: [From file: 'do_compile', lineno: 3, function: do_compile]
ERROR: Function failed: do_compile
Seems that icecc compile_prepend (set_icecc_env shell function) gets prepended
into psplash compile that is written in python. How to deal with it, and
in general, is that possible to mix languages in prepend/append?
I'm using poky master and icecc is working great!
Cheers,
Francesco
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [eclipse-poky][RFC 0/6] Introducing a YoctoSDKCMakeProjectNature
Hi Jessica,
thank you for the input, I will resend the patches.
Best regards,
Atanas
On Thu, Apr 25, 2013 at 6:27 AM, Zhang, Jessica jessica.zh...@intel.comwrote:
Hi Atanas,
** **
Please see my comments below…
** **
Thanks,
Jessica
** **
*From:* Atanas Gegov [mailto:atanas.gegov@gmail.com]
*Sent:* Wednesday, April 24, 2013 8:48 AM
*To:* Zhang, Jessica
*Cc:* yocto@yoctoproject.org
*Subject:* Re: [yocto] [eclipse-poky][RFC 0/6] Introducing a
YoctoSDKCMakeProjectNature
** **
Hi Jessica,
thank you for the comments!
** **
**1. **Yes, the idea is that at the end there are the current
category (Yocto Project ADT Autotools Project with some Autotools-based
project templates) and a new category Yocto Project ADT CMake Project
with e.g. its own Hello World C++ CMake Project. The latter category and
the templates will be implemented in the upcoming patch series.
Great that’s what I’d expected .
** **
**2. **Could you please give me a small example how it should look
like?Should the method addNatures receive a list of natures to add? What is
the case if more natures are added to a project (e.g. SDKNature +
AutotoolsNature + EmptyNature)? Or do you think of enum based on the
buildsystem natures only (Autotools vs. CMake) and not based on all 4
natures?
I took another look of the class, we should be able to even further
simplify the API of addNatures. We can make all the natures as instance
variables of the class. In process method we assign them values and
totally eliminate passing natures in addNatures API. So the code should
be(please ignore the incorrect capitalization due to auto correction):
** **
Public class NewYoctoProjectTemplateProcess extends ProcessRunner {
…
Private Boolean isEmptyProject;
Private Boolean isAutotoolsProject;
Private Boolean isCMakeProject;
…
Public void process(…) {
…
isEmptyProject = …
isAutotoolsProject = …
isCMakeProject = …
…
addNatures(project, false, monitor);
…
}
…
Private void addNatures(IProject project, Boolean
projectExists, IProgressMonitor monitor) {
…
}
** **
**3. **I just created an account in bugzilla.yoctoproject.org, so
you can assign me the CMake support entry.
Super. You’ll get your first assignment J
Thanks,
Atanas
** **
On Tue, Apr 23, 2013 at 8:50 PM, Zhang, Jessica jessica.zh...@intel.com
wrote:
Hi Atanas,
Overall, the patches look good. Couple comments:
1. So from the end user perspective, after the 2nd patch set, user will
see Yocto Project ADT CMake Project category when they want to create a
new project?
2. Can we change the API for addNatures by using an enum type for
projectNature instead of explicitly listing all of them out. This way is
easier for code maintenance and API usability.
3. Don't know whether you've created a bugzilla account at
bugzilla.yoctoproject.org or not, if not, please do, since I'd hope
you're able to help fixing certain bugs in this area down the road. Also,
from project planning process wise, we're right in the 1.5 planning, and
I'd like to create an entry in the bugzilla for extending eclipse for CMake
support and assign that to you, so it's easier to track what are the
community contribution to the project.
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:
yocto-boun...@yoctoproject.org] On Behalf Of Atanas Gegov
Sent: Monday, April 22, 2013 5:06 AM
To: yocto@yoctoproject.org
Subject: [yocto] [eclipse-poky][RFC 0/6] Introducing a
YoctoSDKCMakeProjectNature
From: Atanas Gegov atanas.ge...@bmw-carit.de
Hi,
This patch series introduces a YoctoSDKCMakeProjectNature as a new nature
for CMake-based Yocto Projects in the IDE. It requires the basic
YoctoSDKProjectNature and is an alternative to the
YoctoSDKAutotoolsProjectNature.
This does not affect the currently existing Autotools template projects.
Upcoming patch series will add the last missing parts for having CMake
projects in the IDE: a ManagedBuilder for CMake (CMake toolchain for
building in Eclipse) and some template projects. However, I already wanted
to post this series for a review and make sure that the concept is
acceptable, so that we can build on top of it.
Cheers, Atanas
P.S: This patch series apply on the current master plugins/sdk.ide:
Extracted error message to YoctoSDKMessages
(7142c5fc82a41a9d5f86c48b289db0ef44f5a897).
Atanas Gegov (6):
plugins/sdk.ide: Prepared templates for CMake nature
plugins/sdk.ide: Added a new YoctoSDKCMakeProjectNature
[yocto] Missing something in UAP for Overo-Fire
Hello, I have included this folder in my poky folder, but still i'm not getting the UAP drivers and firmware up and running. https://github.com/chrisw957/meta-gumstix/commit/d0dbc51e1643860f9066c5e817db023fb062362c I'm compiling for Gumstix overo fire on an x86 Ubuntu Studio machine. No files related to the UAP are getting included in the rootfs tar ball. I'm not able to find the uap8xxx.ko file in the final build. The contents of this folder are: /home/desen555/yocto/build/tmp/work/overo-poky-linux-gnueabi/linux-sakoman-3.5-r0/git/drivers/net/wireless/libertas_uap built-in.o Makefile uap_debug.c uap_drv.h uap_fw.h uap_headers.h uap_main.c uap_proc.c uap_sdio_mmc.c uap_sdio_mmc.h Looks like it is partially getting compiled but not the final .ko files. I'l be glad to reply with any other details. Regards, - Sudhangathan BS Ph:(+91) 9731-905-205 - ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] About running old kernels with Yoctoo 1.2 or 1.3
-Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: 24 April 2013 15:36 To: Diego Santa Cruz Cc: yocto@yoctoproject.org; Bruce Ashfield Subject: Re: [yocto] About running old kernels with Yoctoo 1.2 or 1.3 On Wednesday 24 April 2013 08:53:31 Bruce Ashfield wrote: Each Yocto release uses a sliding set of kernel's that have had at least some level of testing with the associated userspace of the release. 1.4 is: 3.2, 3.4 and 3.8 1.3 was: 3.4, 3.2 and 3.0 1.2 was: 3.2, 3.0 and 2.6.37 But obviously, the linux kernel has a very stable userspace ABI, so there shouldn't be any big compatibility issues with other kernel versions. It's just that we don't know for sure. It is true that each of these releases with have a linux-libc-headers that is newer than the 2.6.x kernel you are talking about, which could expose syscalls or other interfaces to userspace that aren't supported in your kernel, but this typically degrades gracefully and the issue detected when you try your applications. The usual problematic components are those that rely heavily upon the kernel e.g. udev and systemd. For such components you may find you need to downgrade or avoid them altogether; most of userspace should work just fine with an older kernel though. Many thanks for the valuable input. Is the traditional init system still supported, or is Yocto using systemd exclusively? Best, Diego -- Diego Santa Cruz, PhD Technology Architect _ SpinetiX S.A. Rue des Terreaux 17 1003, Lausanne, Switzerland T +41 21 341 15 50 F +41 21 311 19 56 diego.santac...@spinetix.com http://www.spinetix.com http://www.youtube.com/SpinetiXTeam _ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [eclipse-poky][RFCv2 0/7] Introducing a YoctoSDKCMakeProjectNature
From: Atanas Gegov atanas.ge...@bmw-carit.de Hi, This patch series introduces a YoctoSDKCMakeProjectNature as a new nature for CMake-based Yocto Projects in the IDE. It requires the basic YoctoSDKProjectNature and is an alternative to the YoctoSDKAutotoolsProjectNature. This does not affect the currently existing Autotools template projects. Upcoming patch series will add the last missing parts for having CMake projects in the IDE: a ManagedBuilder for CMake (CMake toolchain for building in Eclipse) and some template projects. Cheers, Atanas P.S: This patch series apply on the current master Display progress bar while running systemtap script (0006f3194e0050bb69887cece970df7a820b8c30). Atanas Gegov (7): plugins/sdk.ide: Prepared templates for CMake nature plugins/sdk.ide: Added a new YoctoSDKCMakeProjectNature plugins/sdk.ide: Enable the creation of CMake projects plugins/sdk.ide: Update CMake projects on Yocto settings change plugins/sdk.ide: Renamed template process plugins/sdk.ide: Fixed whitespace issues plugins/sdk.ide: Extracted member variables .../OSGI-INF/l10n/bundle.properties|1 + plugins/org.yocto.sdk.ide/plugin.xml | 25 +- .../ide/natures/YoctoSDKCMakeProjectNature.java| 92 +++ .../src/org/yocto/sdk/ide/utils/YoctoSDKUtils.java |7 +- .../sdk/ide/wizard/NewYoctoCProjectTemplate.java | 245 -- .../ide/wizard/NewYoctoProjectTemplateProcess.java | 267 .../EmptyCAutotoolsProject/template.xml|1 + .../EmptyCPPAutotoolsProject/template.xml |1 + .../HelloWorldCAutotoolsProject/template.xml |1 + .../HelloWorldCGTKAutotoolsProject/template.xml|1 + .../HelloWorldCPPAutotoolsProject/template.xml |1 + 11 files changed, 395 insertions(+), 247 deletions(-) create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoProjectTemplateProcess.java -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFCv2 1/7] plugins/sdk.ide: Prepared templates for CMake nature
From: Atanas Gegov atanas.ge...@bmw-carit.de
Added an extra variable to the templates and the
creating process to prepare them for the new CMake
nature.
---
plugins/org.yocto.sdk.ide/plugin.xml |4
.../sdk/ide/wizard/NewYoctoCProjectTemplate.java |2 ++
.../EmptyCAutotoolsProject/template.xml|1 +
.../EmptyCPPAutotoolsProject/template.xml |1 +
.../HelloWorldCAutotoolsProject/template.xml |1 +
.../HelloWorldCGTKAutotoolsProject/template.xml|1 +
.../HelloWorldCPPAutotoolsProject/template.xml |1 +
7 files changed, 11 insertions(+)
diff --git a/plugins/org.yocto.sdk.ide/plugin.xml
b/plugins/org.yocto.sdk.ide/plugin.xml
index 1b882a2..dd75532 100644
--- a/plugins/org.yocto.sdk.ide/plugin.xml
+++ b/plugins/org.yocto.sdk.ide/plugin.xml
@@ -162,6 +162,10 @@
external=true
name=isAutotoolsProject
/simple
+ simple
+ external=true
+ name=isCMakeProject
+ /simple
/processType
processType
name=NewYoctoAutotoolsProjectPostProcess
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
index a103ebe..705dc99 100644
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java
@@ -88,9 +88,11 @@ public class NewYoctoCProjectTemplate extends ProcessRunner {
String isCProjectValue = args[3].getSimpleValue();
String isEmptyProjetValue = args[4].getSimpleValue();
String isAutotoolsProjectValue = args[5].getSimpleValue();
+ String isCMakeProjectValue = args[6].getSimpleValue();
boolean isCProject =
Boolean.valueOf(isCProjectValue).booleanValue();
boolean isEmptyProject =
Boolean.valueOf(isEmptyProjetValue).booleanValue();
boolean isAutotoolsProject =
Boolean.valueOf(isAutotoolsProjectValue).booleanValue();
+ boolean isCMakeProject =
Boolean.valueOf(isCMakeProjectValue).booleanValue();
IProject project =
ResourcesPlugin.getWorkspace().getRoot().getProject(projectName);
try {
diff --git
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCAutotoolsProject/template.xml
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCAutotoolsProject/template.xml
index 028f33d..e1c1abc 100644
---
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCAutotoolsProject/template.xml
+++
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCAutotoolsProject/template.xml
@@ -11,6 +11,7 @@
simple name=isCProject value=true /
simple name=isEmptyProject value=true /
simple name=isAutotoolsProject value=true /
+ simple name=isCMakeProject value=false /
/process
/template
diff --git
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCPPAutotoolsProject/template.xml
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCPPAutotoolsProject/template.xml
index ae4173b..9f1d46b 100644
---
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCPPAutotoolsProject/template.xml
+++
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/EmptyCPPAutotoolsProject/template.xml
@@ -10,6 +10,7 @@
simple name=isCProject value=false /
simple name=isEmptyProject value=true /
simple name=isAutotoolsProject value=true /
+ simple name=isCMakeProject value=false /
/process
/template
diff --git
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCAutotoolsProject/template.xml
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCAutotoolsProject/template.xml
index 33bffd5..ca154ca 100644
---
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCAutotoolsProject/template.xml
+++
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCAutotoolsProject/template.xml
@@ -56,6 +56,7 @@
simple name=isCProject value=true /
simple name=isEmptyProject value=false /
simple name=isAutotoolsProject value=true /
+ simple name=isCMakeProject value=false /
/process
process type=org.eclipse.cdt.core.CreateSourceFolder
diff --git
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCGTKAutotoolsProject/template.xml
b/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCGTKAutotoolsProject/template.xml
index 8a4f43b..4234ff4 100644
---
a/plugins/org.yocto.sdk.ide/templates/projecttemplates/HelloWorldCGTKAutotoolsProject/template.xml
+++
[yocto] [RFCv2 2/7] plugins/sdk.ide: Added a new YoctoSDKCMakeProjectNature
From: Atanas Gegov atanas.ge...@bmw-carit.de
This nature is intended for Yocto projects that
use CMake as a build system. It requires the
YoctoSDKProjectNature and can be used by upcoming
CMake project templates. It excludes the
YoctoSDKAutotoolsProjectNature, e.g. their
relation in plugin.xml is declared as
one-of-nature.
---
.../OSGI-INF/l10n/bundle.properties|1 +
plugins/org.yocto.sdk.ide/plugin.xml | 19 +++
.../ide/natures/YoctoSDKCMakeProjectNature.java| 20
3 files changed, 40 insertions(+)
create mode 100644
plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
diff --git a/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
b/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
index 1a4e3c9..48eb653 100644
--- a/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
+++ b/plugins/org.yocto.sdk.ide/OSGI-INF/l10n/bundle.properties
@@ -2,6 +2,7 @@
page.name.0 = Yocto Project ADT
extension.name.0 = YoctoSDKNature
extension.name.1 = YoctoSDKAutotoolsNature
+extension.name.2 = YoctoSDKCMakeNature
command.name = ReconfigureYoctoProject
command.label.0 = Change Yocto Project Settings
command.mnemonic = C
diff --git a/plugins/org.yocto.sdk.ide/plugin.xml
b/plugins/org.yocto.sdk.ide/plugin.xml
index dd75532..2d6b941 100644
--- a/plugins/org.yocto.sdk.ide/plugin.xml
+++ b/plugins/org.yocto.sdk.ide/plugin.xml
@@ -40,11 +40,30 @@
class=org.yocto.sdk.ide.natures.YoctoSDKAutotoolsProjectNature
/run
/runtime
+ one-of-nature
+id=org.yocto.sdk.ide.buildsystemNaturesSet
+ /one-of-nature
builder
id=org.eclipse.cdt.autotools.core.genmakebuilderV2
/builder
/extension
extension
+ id=YoctoSDKCMakeNature
+ name=%extension.name.2
+ point=org.eclipse.core.resources.natures
+ requires-nature
+id=org.yocto.sdk.ide.YoctoSDKNature
+ /requires-nature
+ runtime
+ run
+ class=org.yocto.sdk.ide.natures.YoctoSDKCMakeProjectNature
+ /run
+ /runtime
+ one-of-nature
+id=org.yocto.sdk.ide.buildsystemNaturesSet
+ /one-of-nature
+ /extension
+ extension
id=YoctoSDKEmptyNature
point=org.eclipse.core.resources.natures
requires-nature
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
new file mode 100644
index 000..86a9d45
--- /dev/null
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
@@ -0,0 +1,20 @@
+/***
+ * Copyright (c) 2013 BMW Car IT GmbH.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * BMW Car IT - initial API and implementation
+
***/
+package org.yocto.sdk.ide.natures;
+
+import org.eclipse.core.resources.IProject;
+import org.eclipse.core.runtime.CoreException;
+import org.yocto.sdk.ide.YoctoSDKPlugin;
+
+public class YoctoSDKCMakeProjectNature extends YoctoSDKProjectNature {
+ public static final String YoctoSDK_CMAKE_NATURE_ID =
YoctoSDKPlugin.getUniqueIdentifier() + .YoctoSDKCMakeNature;
+
+}
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFCv2 3/7] plugins/sdk.ide: Enable the creation of CMake projects
From: Atanas Gegov atanas.ge...@bmw-carit.de
This enables creating projects with the introduced
CMake nature. What is still upcoming are the
template projects and a corresponfig CMake
ManagedBuilder (CMake build toolchain for
Eclipse).
---
.../ide/natures/YoctoSDKCMakeProjectNature.java| 72
.../sdk/ide/wizard/NewYoctoCProjectTemplate.java | 12 ++--
2 files changed, 80 insertions(+), 4 deletions(-)
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
index 86a9d45..b3d0f2c 100644
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/natures/YoctoSDKCMakeProjectNature.java
@@ -10,11 +10,83 @@
***/
package org.yocto.sdk.ide.natures;
+import org.eclipse.cdt.core.CCorePlugin;
+import org.eclipse.cdt.core.envvar.IContributedEnvironment;
+import org.eclipse.cdt.core.envvar.IEnvironmentVariable;
+import org.eclipse.cdt.core.envvar.IEnvironmentVariableManager;
+import org.eclipse.cdt.core.model.CoreModel;
+import org.eclipse.cdt.core.settings.model.ICConfigurationDescription;
+import org.eclipse.cdt.core.settings.model.ICProjectDescription;
import org.eclipse.core.resources.IProject;
import org.eclipse.core.runtime.CoreException;
import org.yocto.sdk.ide.YoctoSDKPlugin;
+import org.yocto.sdk.ide.utils.YoctoSDKUtils;
public class YoctoSDKCMakeProjectNature extends YoctoSDKProjectNature {
public static final String YoctoSDK_CMAKE_NATURE_ID =
YoctoSDKPlugin.getUniqueIdentifier() + .YoctoSDKCMakeNature;
+ // Considered poky's cmake.bbclass for this method
+ public static void extendProjectEnvironmentForCMake(IProject project) {
+ ICProjectDescription cpdesc =
CoreModel.getDefault().getProjectDescription(project, true);
+ ICConfigurationDescription ccdesc =
cpdesc.getActiveConfiguration();
+ IEnvironmentVariableManager manager =
CCorePlugin.getDefault().getBuildEnvironmentManager();
+ IContributedEnvironment env =
manager.getContributedEnvironment();
+ String delimiter = manager.getDefaultDelimiter();
+
+ env.addVariable(CCACHE, ,
IEnvironmentVariable.ENVVAR_REPLACE, delimiter, ccdesc);
+
+ env.addVariable(OECMAKE_SOURCEPATH, ..,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+
+ String oecmakeBuildPathString = ;
+ env.addVariable(OECMAKE_BUILDPATH, oecmakeBuildPathString,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+ env.addVariable(EXTRA_OEMAKE, -C + oecmakeBuildPathString,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+
+ String ccString = YoctoSDKUtils.getEnvValue(project, CC);
+
+ if (!ccString.equals() !ccString.equals( )) {
+ ccString.trim();
+ ccString = ccString.split( )[0];
+ }
+
+ env.addVariable(OECMAKE_C_COMPILER, ccString,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+ String cxxString = YoctoSDKUtils.getEnvValue(project, CXX);
+
+ if (!cxxString.equals() !cxxString.equals( )) {
+ cxxString.trim();
+ cxxString = cxxString.split( )[0];
+ }
+
+ env.addVariable(OECMAKE_CXX_COMPILER, cxxString,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+
+ String hostCCArchString = YoctoSDKUtils.getEnvValue(project,
HOST_CC_ARCH);
+ String toolchainOptionsString =
YoctoSDKUtils.getEnvValue(project, TOOLCHAIN_OPTIONS);
+ String cppFlagsString = YoctoSDKUtils.getEnvValue(project,
CPPFLAGS);
+ String cxxFlagsString = YoctoSDKUtils.getEnvValue(project,
CXXFLAGS);
+ String selectedOptimizationString =
YoctoSDKUtils.getEnvValue(project, SELECTED_OPTIMIZATION);
+ env.addVariable(OECMAKE_C_FLAGS, hostCCArchString + +
toolchainOptionsString + + cppFlagsString,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+ env.addVariable(OECMAKE_CXX_FLAGS, hostCCArchString + +
toolchainOptionsString + + cxxFlagsString
+ + -fpermissive,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
ccdesc);
+ env.addVariable(OECMAKE_C_FLAGS_RELEASE,
selectedOptimizationString + + cppFlagsString + -DNDEBUG,
+ IEnvironmentVariable.ENVVAR_REPLACE, delimiter,
[yocto] [RFCv2 5/7] plugins/sdk.ide: Renamed template process
From: Atanas Gegov atanas.ge...@bmw-carit.de The original name of the class had two drawbacks: firstly, it suggested that it applies only for C projects and secondly, it did not state that this is a process. --- plugins/org.yocto.sdk.ide/plugin.xml |2 +- .../sdk/ide/wizard/NewYoctoCProjectTemplate.java | 251 .../ide/wizard/NewYoctoProjectTemplateProcess.java | 251 3 files changed, 252 insertions(+), 252 deletions(-) delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoProjectTemplateProcess.java diff --git a/plugins/org.yocto.sdk.ide/plugin.xml b/plugins/org.yocto.sdk.ide/plugin.xml index 2d6b941..7ea55c7 100644 --- a/plugins/org.yocto.sdk.ide/plugin.xml +++ b/plugins/org.yocto.sdk.ide/plugin.xml @@ -156,7 +156,7 @@ point=org.eclipse.cdt.core.templateProcessTypes processType name=NewYoctoProject -processRunner=org.yocto.sdk.ide.wizard.NewYoctoCProjectTemplate + processRunner=org.yocto.sdk.ide.wizard.NewYoctoProjectTemplateProcess simple name=name /simple diff --git a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java deleted file mode 100644 index dc9bca5..000 --- a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoCProjectTemplate.java +++ /dev/null @@ -1,251 +0,0 @@ -/*** - * Copyright (c) 2010 Intel Corporation. - * All rights reserved. This program and the accompanying materials - * are made available under the terms of the Eclipse Public License v1.0 - * which accompanies this distribution, and is available at - * http://www.eclipse.org/legal/epl-v10.html - * - * Contributors: - * Intel - initial API and implementation - ***/ -package org.yocto.sdk.ide.wizard; - -import java.util.Arrays; -import java.util.LinkedHashMap; -import java.util.List; -import java.util.regex.Matcher; -import java.util.regex.Pattern; - -import org.eclipse.cdt.autotools.core.AutotoolsNewProjectNature; -import org.eclipse.cdt.core.CCorePlugin; -import org.eclipse.cdt.core.templateengine.TemplateCore; -import org.eclipse.cdt.core.templateengine.process.ProcessArgument; -import org.eclipse.cdt.core.templateengine.process.ProcessFailureException; -import org.eclipse.cdt.core.templateengine.process.ProcessRunner; -import org.eclipse.cdt.core.templateengine.process.processes.Messages; -import org.eclipse.cdt.internal.autotools.core.configure.AutotoolsConfigurationManager; -import org.eclipse.cdt.make.core.MakeCorePlugin; -import org.eclipse.cdt.make.core.scannerconfig.IDiscoveredPathManager; -import org.eclipse.cdt.make.core.scannerconfig.IDiscoveredPathManager.IDiscoveredPathInfo; -import org.eclipse.cdt.make.core.scannerconfig.IDiscoveredPathManager.IPerProjectDiscoveredPathInfo; -import org.eclipse.cdt.make.internal.core.scannerconfig.util.SymbolEntry; -import org.eclipse.cdt.managedbuilder.core.BuildException; -import org.eclipse.cdt.managedbuilder.core.IConfiguration; -import org.eclipse.cdt.managedbuilder.core.IManagedBuildInfo; -import org.eclipse.cdt.managedbuilder.core.IOption; -import org.eclipse.cdt.managedbuilder.core.ManagedBuildManager; -import org.eclipse.cdt.managedbuilder.templateengine.ProjectCreatedActions; -import org.eclipse.cdt.managedbuilder.ui.wizards.MBSCustomPageManager; -import org.eclipse.jface.wizard.IWizardPage; -import org.eclipse.cdt.ui.wizards.CDTMainWizardPage; -import org.eclipse.cdt.internal.ui.wizards.ICDTCommonProjectWizard; -import org.eclipse.core.resources.IProject; -import org.eclipse.core.resources.IWorkspace; -import org.eclipse.core.resources.IWorkspaceDescription; -import org.eclipse.core.resources.ResourcesPlugin; -import org.eclipse.core.runtime.CoreException; -import org.eclipse.core.runtime.IPath; -import org.eclipse.core.runtime.IProgressMonitor; -import org.eclipse.core.runtime.OperationCanceledException; -import org.eclipse.core.runtime.Path; -import org.eclipse.jface.preference.IPreferenceStore; -import org.yocto.sdk.ide.YoctoGeneralException; -import org.yocto.sdk.ide.YoctoProfileElement; -import org.yocto.sdk.ide.YoctoSDKChecker; -import org.yocto.sdk.ide.YoctoSDKMessages; -import org.yocto.sdk.ide.YoctoSDKPlugin; -import org.yocto.sdk.ide.YoctoUIElement; -import org.yocto.sdk.ide.natures.YoctoSDKAutotoolsProjectNature; -import org.yocto.sdk.ide.natures.YoctoSDKCMakeProjectNature; -import org.yocto.sdk.ide.natures.YoctoSDKEmptyProjectNature; -import org.yocto.sdk.ide.natures.YoctoSDKNatureUtils; -import org.yocto.sdk.ide.natures.YoctoSDKProjectNature; -import
[yocto] [RFCv2 7/7] plugins/sdk.ide: Extracted member variables
From: Atanas Gegov atanas.ge...@bmw-carit.de
Simplified the calling of the addNatures(...)
method. Variables describing the nature of the
project are not more local for the process(...)
method, but private object members.
---
.../ide/wizard/NewYoctoProjectTemplateProcess.java | 29 ++--
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoProjectTemplateProcess.java
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoProjectTemplateProcess.java
index 2ac52e5..9c6dca4 100644
---
a/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoProjectTemplateProcess.java
+++
b/plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/wizard/NewYoctoProjectTemplateProcess.java
@@ -70,8 +70,18 @@ public class NewYoctoProjectTemplateProcess extends
ProcessRunner {
protected ListCharacter illegalChars = Arrays.asList('$',
'','#','%','','\'','(',')','*', '+',
',','.','/',':',';','','=','','?','@','[','\\',']','^','`','{','|','}','~');
private static final String PROJECT_NAME_ERROR =
Wizard.SDK.Error.ProjectName;
+ private boolean isCProject;
+ private boolean isEmptyProject;
+ private boolean isAutotoolsProject;
+ private boolean isCMakeProject;
+
public NewYoctoProjectTemplateProcess() {
pca = new ProjectCreatedActions();
+
+ isCProject = false;
+ isEmptyProject = false;
+ isAutotoolsProject = false;
+ isCMakeProject = false;
}
private String printIllegalChars(){
@@ -81,6 +91,7 @@ public class NewYoctoProjectTemplateProcess extends
ProcessRunner {
print = print.substring(0, print.length() - 2);
return print;
}
+
public void process(TemplateCore template, ProcessArgument[] args,
String processId, IProgressMonitor monitor) throws ProcessFailureException {
String projectName = args[0].getSimpleValue();
@@ -90,10 +101,11 @@ public class NewYoctoProjectTemplateProcess extends
ProcessRunner {
String isEmptyProjetValue = args[4].getSimpleValue();
String isAutotoolsProjectValue = args[5].getSimpleValue();
String isCMakeProjectValue = args[6].getSimpleValue();
- boolean isCProject =
Boolean.valueOf(isCProjectValue).booleanValue();
- boolean isEmptyProject =
Boolean.valueOf(isEmptyProjetValue).booleanValue();
- boolean isAutotoolsProject =
Boolean.valueOf(isAutotoolsProjectValue).booleanValue();
- boolean isCMakeProject =
Boolean.valueOf(isCMakeProjectValue).booleanValue();
+
+ isCProject = Boolean.valueOf(isCProjectValue).booleanValue();
+ isEmptyProject =
Boolean.valueOf(isEmptyProjetValue).booleanValue();
+ isAutotoolsProject =
Boolean.valueOf(isAutotoolsProjectValue).booleanValue();
+ isCMakeProject =
Boolean.valueOf(isCMakeProjectValue).booleanValue();
IProject project =
ResourcesPlugin.getWorkspace().getRoot().getProject(projectName);
try {
@@ -132,7 +144,7 @@ public class NewYoctoProjectTemplateProcess extends
ProcessRunner {
pca.setArtifactExtension(artifactExtension);
info = pca.createProject(monitor,
CCorePlugin.DEFAULT_INDEXER, isCProject);
- addNatures(project, false, isEmptyProject,
isAutotoolsProject, isCMakeProject, monitor);
+ addNatures(project, false, monitor);
info.setValid(true);
ManagedBuildManager.saveBuildInfo(project,
true);
@@ -145,7 +157,7 @@ public class NewYoctoProjectTemplateProcess extends
ProcessRunner {
YoctoSDKChecker.checkIfGloballySelectedYoctoProfileIsValid();
- addNatures(project, true, isEmptyProject,
isAutotoolsProject, isCMakeProject, monitor);
+ addNatures(project, true, monitor);
//restoreAutoBuild(workspace);
IDiscoveredPathManager manager =
MakeCorePlugin.getDefault().getDiscoveryManager();
@@ -186,9 +198,8 @@ public class NewYoctoProjectTemplateProcess extends
ProcessRunner {
return matcher.find();
}
- private void addNatures(IProject project, boolean projectExists,
boolean isEmptyProject,
- boolean isAutotoolsProject, boolean isCMakeProject,
IProgressMonitor monitor)
- throws CoreException,
YoctoGeneralException {
+ private void addNatures(IProject project, boolean projectExists,
IProgressMonitor monitor)
+ throws CoreException, YoctoGeneralException {
Re: [yocto] [meta-raspberrypi][PATCH 1/2] sdcard_image-rpi.bbclass: Fix error in conditional test
On 25 April 2013 02:00, seth bollinger seth.b...@gmail.com wrote: When the shell tests for rootfs type I was seeing [[: not found. I use echo and egrep to test for the xz rootfs type to work around this error. '[[' should be a bash builtin. What host OS are you using for the build? Also what's the exact error message? I'm wondering if this is somehow being ran in a shell that isn't bash. With an unknown command 'abcd', bash gives me abcd: command not found and dash gives me dash: 1: abcd: not found. Using egrep for a test like this seems less readable to me. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] psplash_git.bb: Error when building with icecc
Martin Jansa martin.ja...@gmail.com
writes:
On Thu, Apr 25, 2013 at 09:34:09AM +0200, Francesco Del Degan wrote:
Hi all, i just found an error building core-image-basic with icecc
inherited:
You can send patch extending blacklist defined in icecc.bbclass:
system_package_blacklist = [ uclibc, glibc, gcc, bind, u-boot,
dhcp-forwarder, enchant, connman, orbit2 ]
user_package_blacklist = (d.getVar('ICECC_USER_PACKAGE_BL') or ).split()
or add psplash to ICECC_USER_PACKAGE_BL
This is not going to work, because set_icecc_env gets prepended anyhow,
so i just got the same error.
In fact, the icecc.bbclass declares:
do_compile_prepend() {
set_icecc_env
}
and only in set_icecc_env the blacklist controls is performed.
The problem seems to be that do_compile in psplash_git.bb is written in python:
python do_compile () {
import shutil, commands
}
so prepending just mixes the two languages.
Could be this the first case of mixing languages? Is bitbake able to
make some transformation when prepending/appending like that.
Also a some sort of conditional prepending based on languages could
works. What do you think?
NameError: global name 'set_icecc_env' is not defined
ERROR: The stack trace of python calls that resulted in this
exception/failure was:
ERROR: File do_compile, line 26, in module
ERROR:
ERROR: File do_compile, line 3, in do_compile
ERROR:
ERROR: The code that was being executed was:
ERROR: 0022:bb.build.exec_func(oe_runmake, d)
ERROR: 0023:shutil.copyfile(psplash, outputfile)
ERROR: 0024:
ERROR: 0025:
ERROR: *** 0026:do_compile(d)
ERROR: 0027:
ERROR: [From file: 'do_compile', lineno: 26, function: module]
ERROR: 0001:
ERROR: 0002:def do_compile(d):
ERROR: *** 0003:set_icecc_env
ERROR: 0004:import shutil, commands
ERROR: 0005:
ERROR: 0006:# Build a separate executable for each splash image
ERROR: 0007:convertscript = %s/make-image-header.sh %
d.getVar('S', True)
ERROR: [From file: 'do_compile', lineno: 3, function: do_compile]
ERROR: Function failed: do_compile
Seems that icecc compile_prepend (set_icecc_env shell function) gets
prepended
into psplash compile that is written in python. How to deal with it, and
in general, is that possible to mix languages in prepend/append?
I'm using poky master and icecc is working great!
Cheers,
Francesco
___
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] [meta-raspberrypi][PATCH 2/2] sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation.
On 25 April 2013 02:00, seth bollinger seth.b...@gmail.com wrote: start_cd.elf and fixup_cd.dat are required when running the system with a 16MB GPU memory configuration. This change copies all files contained in bcm2835-bootfiles instead of cherry picking. Signed-off-by: Seth Bollinger seth.b...@gmail.com Trying to apply this email I get: Applying: sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation. fatal: corrupt patch at line 14 Patch failed at 0001 sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation. Trying to apply the attached patch I get: Patch format detection failed. Are you using 'git send-email'? However, I can apply this after fixing the attached patch file by hand, giving it a test now. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/2] sdcard_image-rpi.bbclass: Fix error in conditional test
On 25 April 2013 13:51, Seth Bollinger seth.b...@gmail.com wrote: On Thu, Apr 25, 2013 at 7:38 AM, Paul Barker p...@paulbarker.me.uk wrote: '[[' should be a bash builtin. What host OS are you using for the build? I'm using debian. I'll check what the default shell is. You're right, it's probably dash. Try 'sudo dpkg-reconfigure dash'. However, should this fail silently then? In this instance I only saw the error with debug enabled. Otherwise it silently tried to dd a compressed image to the sd card. Of course this didn't run. :) I assume that 'if' tries to run the command, gets a non-zero return value as the command doesn't run and just interprets this as the command running but returning non-zero. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] About running old kernels with Yoctoo 1.2 or 1.3
Hi Diego, On 25 April 2013 13:27, Diego Santa Cruz diego.santac...@spinetix.com wrote: Many thanks for the valuable input. Is the traditional init system still supported, or is Yocto using systemd exclusively? With 1.4 (about to be released), systemd is an option but the default init is still sysvinit. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 2/2] sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation.
On 25 April 2013 13:57, Seth Bollinger seth.b...@gmail.com wrote: On Thu, Apr 25, 2013 at 7:51 AM, Paul Barker p...@paulbarker.me.uk wrote: Trying to apply this email I get: Applying: sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation. fatal: corrupt patch at line 14 Patch failed at 0001 sdcard_image-rpi.bbclass: Copy startup files required for 16MB GPU operation. Trying to apply the attached patch I get: Patch format detection failed. Are you using 'git send-email'? However, I can apply this after fixing the attached patch file by hand, giving it a test now. I run git format-patch and then copy the text into the email and attach the patch. I apologize for the trouble. Richard complained of whitespace problems in my last patches so I'm trying to alleviate this problem. :) I'll see if I can't get gmail set up on my vm so I can use git send-email. Seth Somehow a leading '' crept into the attached patch. Almost all mail clients ruin patches, maybe take a look at https://coderwall.com/p/dp-gka for using 'git send-email' with gmail. If you don't want to clog the list with attempts which might not work, send a few test patches to me and i'll let you know if they work. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Files and overrides
I'm trying to supply a target specific file for which there are already many alternatives. For whatever reason, the wrong file is always being chosen. Here are the details: I have a local layer (meta-imx6) which is used to override/overlay a BSP layer (meta-fsl-arm) which in turn is supplying some tuned files. In particular, the file 'xorg.conf' which appears in all of these places: ./meta-imx6/recipes-graphics/xorg-xserver/xserver-xf86-config/sabrelite/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemuarm/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemuppc/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86-64/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemush4/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips64/xorg.conf ./meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemux86/xorg.conf ./meta-fsl-arm/recipes-graphics/xorg-xserver/xserver-xf86-config/mx6/xorg.conf ./meta-fsl-arm/recipes-graphics/xorg-xserver/xserver-xf86-config/mx5/xorg.conf ./meta-fsl-arm/recipes-graphics/xorg-xserver/xserver-xf86-config/mxs/xorg.conf My meta-imx6 layer sets up the overrides to be: FILESOVERRIDES=imx6qsabrelite:arm:armv7a:mx6:mx6q:sabrelite:amltd OVERRIDES=imx6qsabrelite:arm:armv7a:mx6:mx6q:sabrelite:amltd where amltd is the name of my distribution and sabrelite is my machine name. The file that is actually chosen is .../mx6/xorg.conf, but I want it to be .../sabrelite/xorg.conf I have other files in the .../xserver-xf86-config/sabrelite directory being picked up (that's part of what this is about, adding such configury) but not xorg.conf How can I fix this? I tried moving/adding sabrelite to the front of the *OVERRIDES variables with no change. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Finding/Generating Rootfs Package List
Hi all, I generally like to keep a little manifest file with my rootfs images, containing a list of installed packages and their associated versions. On images where I keep package data around, I usually generate this via 'opkg list'. In my current situation, I have a small read-only image where I can't afford to ship pkg data, and wanted to gather this info on the host side of things. I assume this information is tracked somewhere in the poky build directory, but I'm having some trouble finding it. Could someone kindly point me towards this information or the documentation section(s) that I may have overlooked. Thank you! Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
Hi Jon, On 25 April 2013 15:10, Jon Szymaniak jon.szyman...@gmail.com wrote: In my current situation, I have a small read-only image where I can't afford to ship pkg data, and wanted to gather this info on the host side of things. I assume this information is tracked somewhere in the poky build directory, but I'm having some trouble finding it. Could someone kindly point me towards this information or the documentation section(s) that I may have overlooked. In tmp/work/[machine]/[image]/[version]/ you'll find installed-pkgs.txt and complementary-pkgs.txt, which should be exactly what you want. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
On Thu, Apr 25, 2013 at 10:10:31AM -0400, Jon Szymaniak wrote: Hi all, I generally like to keep a little manifest file with my rootfs images, containing a list of installed packages and their associated versions. On images where I keep package data around, I usually generate this via 'opkg list'. In my current situation, I have a small read-only image where I can't afford to ship pkg data, and wanted to gather this info on the host side of things. I assume this information is tracked somewhere in the poky build directory, but I'm having some trouble finding it. Could someone kindly point me towards this information or the documentation section(s) that I may have overlooked. buildhistory is what you're looking for -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
On 2013-04-25 08:25, Burton, Ross wrote: Hi Jon, On 25 April 2013 15:10, Jon Szymaniak jon.szyman...@gmail.com wrote: In my current situation, I have a small read-only image where I can't afford to ship pkg data, and wanted to gather this info on the host side of things. I assume this information is tracked somewhere in the poky build directory, but I'm having some trouble finding it. Could someone kindly point me towards this information or the documentation section(s) that I may have overlooked. In tmp/work/[machine]/[image]/[version]/ you'll find installed-pkgs.txt and complementary-pkgs.txt, which should be exactly what you want. True, but the installed-pkgs.txt file only contains the names, not the version information (at least with opkg). I suppose you could write a script to use this file as a starting point, then look through the packages, e.g. tmp/deploy/ipk/*, to find the actual version used. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
On 2013-04-25 08:49, Gary Thomas wrote:
On 2013-04-25 08:25, Burton, Ross wrote:
Hi Jon,
On 25 April 2013 15:10, Jon Szymaniak jon.szyman...@gmail.com wrote:
In my current situation, I have a small read-only image where I can't afford
to ship pkg data, and wanted to gather this info on the host side of things.
I assume this information is tracked somewhere in the poky build directory,
but I'm having some trouble finding it.
Could someone kindly point me towards this information or the documentation
section(s) that I may have overlooked.
In tmp/work/[machine]/[image]/[version]/ you'll find
installed-pkgs.txt and complementary-pkgs.txt, which should be exactly
what you want.
True, but the installed-pkgs.txt file only contains the names, not the
version information (at least with opkg). I suppose you could write a
script to use this file as a starting point, then look through the packages,
e.g. tmp/deploy/ipk/*, to find the actual version used.
These commands did the trick on my RaspberryPi (opkg) based image:
$ find tmp/deploy/ipk -type f | sed -e 's;tmp/deploy/ipk/.*/;;' | sort PKGS
$ awk '{print $1}'
tmp/work/rpi-amltd-linux-gnueabi/rpiface-controller/1.0-r0/installed_pkgs.txt |
sort | xargs -n1 -I \{} grep \{}_ PKGS | sort | uniq INSTALLED
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project 1.4 release readiness meeting - 4/25/2013
Attendees: MarkH (also represents KevinM), Saul, Corneliu, AlexG, Cristiana, AlexD, Laurentiu, Ionut, Jessica (also represents DaveST), Ross, BogdanM, Richard, Cristian, Song Notes: - We have all CCB members here or represented here. - Review release criteria: please see: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Milestone_6.2C_1.4_releasehttps://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status - There are some failures on AB due to racing issues. So we did not have a completely green build. But these are random issue (4358), should not block the release. - Postinstall issues found by the community lately. We will address them in 1.5, but they should not block the release. - 1.5 release criteria or QA test summary could include community feedback to reflect more of the community's opinion . Action item for Song: review 1.5 release criteria. - CentOS should be tested more. Many commercial vendors are using CentOS. Will consider this when we review the 1.5 release. * Decision: 1.4 release is a go. Thank you all, and congratulations to the team and everyone involved in this release! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project 1.4 release readiness meeting - 4/25/2013
Attendees: MarkH (also represents KevinM), Saul, Corneliu, AlexG, Cristiana, AlexD, Laurentiu, Ionut, Jessica (also represents DaveST), Ross, BogdanM, Richard, Cristian, Song Notes: - We have all CCB members here or represented here. - Review release criteria: please see: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Milestone_6.2C_1.4_releasehttps://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status - There are some failures on AB due to racing issues. So we did not have a completely green build. But these are random issue (4358), should not block the release. - Postinstall issues found by the community lately. We will address them in 1.5, but they should not block the release. - 1.5 release criteria or QA test summary could include community feedback to reflect more of the community's opinion . Action item for Song: review 1.5 release criteria. - CentOS should be tested more. Many commercial vendors are using CentOS. Will consider this when we review the 1.5 release. * Decision: 1.4 release is a go. Thank you all, and congratulations to the team and everyone involved in this release! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
Ross and Martin -- thanks for your quick responses.
I failed to mention that I wanted both the ${PV} and ${PR} for packages, so
unfortunately the *-pkgs.txt files won't suffice.
Is there a particular reason why these files don't contain this
information? I haven't looked into where these are generated, but would
including ${PV} and ${PR} in these be a welcome patch?
Looking at the buildhistory wiki page [1], I see this certainly provides
what I need, and a whole lot more.
[1] https://wiki.yoctoproject.org/wiki/Buildhistory
Thanks again,
Jon
On Thu, Apr 25, 2013 at 10:27 AM, Martin Jansa martin.ja...@gmail.comwrote:
On Thu, Apr 25, 2013 at 10:10:31AM -0400, Jon Szymaniak wrote:
Hi all,
I generally like to keep a little manifest file with my rootfs images,
containing a list of installed packages and their associated versions.
On
images where I keep package data around, I usually generate this via
'opkg
list'.
In my current situation, I have a small read-only image where I can't
afford to ship pkg data, and wanted to gather this info on the host side
of
things. I assume this information is tracked somewhere in the poky build
directory, but I'm having some trouble finding it.
Could someone kindly point me towards this information or the
documentation
section(s) that I may have overlooked.
buildhistory is what you're looking for
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
--
--
Jon Szymaniak jon.szymaniak+...@gmail.com
OpenPGP Key Hosted at the following keyservers:
http://keyserver.ubuntu.com/
http://pgp.mit.edu/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Compliance program questions
Hi there, I have a couple of questions regarding the compliance program. If there is a better place for asking such questions, please let me know. I have studied the Yocto compliance documentation, [1] on the website, and I have the following questions: - is there any 'practical' guide with do's and don'ts to help make a sucessful Yocto Project Compatible registration? - i understand that while the project should build with the OE core toolchain, it is not required to use the OE core toolchain 'by default', so we should be able to provide our own modified/customized toolchain in our layers, is my understanding correct? - it is recommended, but not mandatory not use the Yocto kernel, so we can use any mainline version in our BSP layers, right? - is it tolerated to change the versions of some components from OE-core or meta-oe? Not just add patches through .bbappend, but actually use an older or a more recent version of components, let's say Gstreamer for example? - can we included new recipes for software programs not already included in oe-core or meta-oe in our layers, or do we have to contribute them back into oe-core or meta-oe before registration? - the Yocto project compatible registration is made against a specific version of Yocto. What happens when a new Yocto version is released? Should we go through the registration process again? thanks a lot! nicolas [1] https://www.yoctoproject.org/ecosystem/yocto-project-compliance-program ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Compliance program questions
Hi Nicolas, thanks for asking these questions. We are in the process of revising the documentation and application forms for that program, so your questions come at a very good time. I have a few answers: On Thu, Apr 25, 2013 at 8:36 AM, Nicolas Dechesne nde...@gmail.com wrote: Hi there, I have a couple of questions regarding the compliance program. If there is a better place for asking such questions, please let me know. I have studied the Yocto compliance documentation, [1] on the website, and I have the following questions: - is there any 'practical' guide with do's and don'ts to help make a sucessful Yocto Project Compatible registration? We don't have a guide like this, but I can create one. I'm guessing you are looking for guidance on how to answer individual questions as well as how one answer affects the others, is that correct? - i understand that while the project should build with the OE core toolchain, it is not required to use the OE core toolchain 'by default', so we should be able to provide our own modified/customized toolchain in our layers, is my understanding correct? Yes - the project needs to be able to build with the standard toolchain, but you can provide your own as well. - it is recommended, but not mandatory not use the Yocto kernel, so we can use any mainline version in our BSP layers, right? I believe this is the case, but I'll need to research get back to you. - is it tolerated to change the versions of some components from OE-core or meta-oe? Not just add patches through .bbappend, but actually use an older or a more recent version of components, let's say Gstreamer for example? I don't think we require specific versions of any packages, but again I'll have to research first. - can we included new recipes for software programs not already included in oe-core or meta-oe in our layers, or do we have to contribute them back into oe-core or meta-oe before registration? Yes, you can include new recipes (and packages). - the Yocto project compatible registration is made against a specific version of Yocto. What happens when a new Yocto version is released? Should we go through the registration process again? That is a question we have discussed quite a lot. The plan of record is for YP Compatible products/projects to resubmit the form after testing with the new version. However, that does create a problem if someone has, for example, a dozen YP Compatible products. Plus, what happens with point releases? These issues are under discussion I'll report back as soon as I have clear answers. thanks a lot! Thank you for asking these questions! nicolas [1] https://www.yoctoproject.org/ecosystem/yocto-project-compliance-program ___ 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] Compliance program questions
Jeff, On Thu, Apr 25, 2013 at 7:52 PM, Jeff Osier-Mixon je...@jefro.net wrote: Hi Nicolas, thanks for asking these questions. We are in the process of revising the documentation and application forms for that program, so your questions come at a very good time. thanks a lot for your quick answer, and I am glad that it's right on time! I have a few answers: On Thu, Apr 25, 2013 at 8:36 AM, Nicolas Dechesne nde...@gmail.com wrote: Hi there, I have a couple of questions regarding the compliance program. If there is a better place for asking such questions, please let me know. I have studied the Yocto compliance documentation, [1] on the website, and I have the following questions: - is there any 'practical' guide with do's and don'ts to help make a sucessful Yocto Project Compatible registration? We don't have a guide like this, but I can create one. I'm guessing you are looking for guidance on how to answer individual questions as well as how one answer affects the others, is that correct? Yes my questions below are clearly good target for such a 'compliance' tutorial. - i understand that while the project should build with the OE core toolchain, it is not required to use the OE core toolchain 'by default', so we should be able to provide our own modified/customized toolchain in our layers, is my understanding correct? Yes - the project needs to be able to build with the standard toolchain, but you can provide your own as well. ok. - it is recommended, but not mandatory not use the Yocto kernel, so we can use any mainline version in our BSP layers, right? I believe this is the case, but I'll need to research get back to you. at least meta-arago seems to provide a couple of kernel, so i expect it should be ok, but worth checking. - is it tolerated to change the versions of some components from OE-core or meta-oe? Not just add patches through .bbappend, but actually use an older or a more recent version of components, let's say Gstreamer for example? I don't think we require specific versions of any packages, but again I'll have to research first. that question is currently the most important for me, so please let me know. again, just to avoid any confusion, we would need to downgrade several recipes to older versions. the idea would be to import such recipes from OE tree history if they ever existed, or create them from scratch, if needed. - can we included new recipes for software programs not already included in oe-core or meta-oe in our layers, or do we have to contribute them back into oe-core or meta-oe before registration? Yes, you can include new recipes (and packages). ok. - the Yocto project compatible registration is made against a specific version of Yocto. What happens when a new Yocto version is released? Should we go through the registration process again? That is a question we have discussed quite a lot. The plan of record is for YP Compatible products/projects to resubmit the form after testing with the new version. However, that does create a problem if someone has, for example, a dozen YP Compatible products. Plus, what happens with point releases? These issues are under discussion I'll report back as soon as I have clear answers. ok, thanks again. looking forward for your next set of answers. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding/Generating Rootfs Package List
You can use the license manifest to give you this information. See: build/tmp/deploy/licenses/image-machine-timedate/... There is a license.manifest and package.manifest. The license.manifest includes package version. --Mark On 4/25/13 9:10 AM, Jon Szymaniak wrote: Hi all, I generally like to keep a little manifest file with my rootfs images, containing a list of installed packages and their associated versions. On images where I keep package data around, I usually generate this via 'opkg list'. In my current situation, I have a small read-only image where I can't afford to ship pkg data, and wanted to gather this info on the host side of things. I assume this information is tracked somewhere in the poky build directory, but I'm having some trouble finding it. Could someone kindly point me towards this information or the documentation section(s) that I may have overlooked. Thank you! Jon ___ 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] working my way through the kernel hands-on labs finally
On Tue, Apr 9, 2013 at 6:11 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Tue, 2013-04-09 at 18:06 -0400, Trevor Woerner wrote: On Tue, Apr 9, 2013 at 5:46 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: ok, so what am i looking for? I couldn't get lab3 to work fully unless I switched from package_ipk to package_rpm. The module would get built and included in the image, but it wasn't being loaded automatically during boot. At the time I tried against the master HEAD and everything worked fine, so whatever it is I think I've found, it has been fixed (this is only a danny-8.0.1 problem). https://lists.yoctoproject.org/pipermail/yocto/2013-February/014424.html When I mentioned it, it didn't seem to make sense that the choice of packaging should affect something like this. But I tried it a couple times on my machine and could reproduce it. I don't think anyone else tried reproducing it. I believe I tried and couldn't reproduce it. But if someone does reproduce it, please file a bug detailing the *exact* steps needed to reproduce. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4423 This is still reproducible. This time I also gave it a try using a Fedora 18 (64) VM. Lab 3 does not work if you set PACKAGE_CLASSES to package_ipk. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding prebuilt binaries to /usr/bin on rootfs
On Apr 17, 2013, at 8:11 AM, Satya Swaroop Damarla swaroop.dama...@gmail.com
wrote:
Hi Burton,
Please have a look at the build error I had
WARNING: File '/usr/bin/sdusb-cmd' from skidata-tools was already stripped,
this will prevent future debugging!
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/packages-split/skidata-tools/usr/bin/devsrv'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/packages-split/skidata-tools/usr/bin/USBDownload'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/packages-split/skidata-tools/usr/bin/setty'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/packages-split/skidata-tools/usr/bin/TCPDownload'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/packages-split/skidata-tools/usr/bin/sdusb-cmd'
ERROR: QA Issue: No GNU_HASH in the elf binary:
'/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/packages-split/skidata-tools/usr/bin/i2c-test'
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/home/damarla/yocto/poky/buildSkidataHarmony/tmp/work/cortexa9-vfp-vfpv3d16-poky-linux-gnueabi/skidata-tools/1.0-r0/temp/log.do_package.31327
ERROR: Task 10
(/home/damarla/yocto/poky/meta/recipes-extended/skidata-tools/skidata-tools.bb,
do_package) failed with exit code '1'
This means linker flags are not proper. what happens if you add TARGET_CC_ARCH
+= ${LDFLAGS} to recipe
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
