[yocto] [Package Report System]Manual check recipes name list
This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason cups 1.6.1 1.6.0 287 day Saul Wold s...@linux.intel.co...No data libpng12 1.2.50 N/A 41434 d No Maintainer info No data minicom 2.6.2 2.6.2 42 days Cristian Iorga cristian.iorg...No data Manual Check Count: 3 Manual Need Check Count: 3 Any problem, please contact Saul Wold s...@linux.intel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Package Report System]Upgrade recipes name list
This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-xxx in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-xxx = Not upgrade to 2.0 because the new version is unstable You can check the detail information at http://packages.yoctoproject.org/upgradepkgname PackageName Version UpVersion MaintainerNoUpgradeReason lsb 4.1 1.4 Yi Zhao yi.z...@windriver.com ccache3.1.8 3.1.9 Wenzong Fan wenzong@windriver.com gettext 0.18.20.18.2.1 Wenzong Fan wenzong@windriver.com systemtap-uprobes 2.1+gitAUTOINC+addec81 2.2.1+gitAUTOINC+b1c0ba9 Tom Zanussi tom.zanu...@intel.com swabber-native0.0+gitAUTOINC+a079239 0.0+gitAUTOINC+2d1fe36Saul Wold s...@linux.intel.com libusb-compat 0.1.4 0.1.5 Saul Wold s...@linux.intel.com lsbinitscripts9.46 9.47 Saul Wold s...@linux.intel.com acl 2.2.512.2.52 Saul Wold s...@linux.intel.com mkelfimage1.0.0+svn6637 5914 Saul Wold s...@linux.intel.com libidn1.26 1.27 Saul Wold s...@linux.intel.com nspr 4.9.6 4.10 Saul Wold s...@linux.intel.com kconfig-frontends 3.9.0 3.9.0.0 Saul Wold s...@linux.intel.com glib-networking 2.36.22.37.2 Saul Wold s...@linux.intel.com docbook-sgml-dtd-4.1-native 1.0 41 Saul Wold s...@linux.intel.com docbook-sgml-dtd-3.1-native 1.0 31 Saul Wold s...@linux.intel.com createrepo0.4.110.9.9 Saul Wold s...@linux.intel.com Versions after 0.9.* use YUM,... guilt-native 0.33 0.35 Saul Wold s...@linux.intel.com gtk-doc-stub 0.0+gitAUTOINC+3dfd0a0 0.0+gitAUTOINC+3dfd0a0Saul Wold s...@linux.intel.com help2man-native 1.41.21.43.2 Saul Wold s...@linux.intel.com vte 0.28.20.34.6 Saul Wold s...@linux.intel.com libxkbcommon 0.3.0 0.3.1 Saul Wold s...@linux.intel.com sysstat 10.1.510.1.6 Saul Wold s...@linux.intel.com cracklib 2.8.222.9.0 Saul Wold s...@linux.intel.com oprofileui-server 0.0+gitAUTOINC+f168b8b 0.0+gitAUTOINC+f168b8bSaul Wold s...@linux.intel.com texinfo 4.13a 5.1 Saul Wold s...@linux.intel.com Checking script parses direct... build-appliance-image 8.0 9.0.0 Saul Wold s...@linux.intel.com socat 1.7.2.1 1.7.2.2 Saul Wold s...@linux.intel.com http://www.dest-unreach.org/socat/download/socat-1.7.2.1.tar.bz2;name=src sato-screenshot 0.1+gitAUTOINC+c792e4e 0.1+gitAUTOINC+c792e4eSaul Wold s...@linux.intel.com docbook-sgml-dtd-4.5-native 1.0 4.5 Saul Wold s...@linux.intel.com attr 2.4.462.4.47
Re: [yocto] Distributing Compilation of Yocto
On Monday 10 June 2013 20:16:22 Khem Raj wrote: On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas g...@mlbassoc.com wrote: Looks interesting and I think I'd like to try it myself. However, that page has a reference to http://bugs.openembedded.org/attachment.cgi?id=1032action=view which seems to be down at the moment (tested from both sides of the pond) OE bugzilla has been decommissioned long ago. In that case the Using IceCC page on the OE wiki [1] should not be linking to it. Can someone who has actually used IceCC in conjunction with OE (or has contact with someone who has) please update the page? Martin? Thanks, Paul [1] http://www.openembedded.org/wiki/Using_IceCC -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Distributing Compilation of Yocto
On Tue, Jun 11, 2013 at 09:20:05AM +0100, Paul Eggleton wrote: On Monday 10 June 2013 20:16:22 Khem Raj wrote: On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas g...@mlbassoc.com wrote: Looks interesting and I think I'd like to try it myself. However, that page has a reference to http://bugs.openembedded.org/attachment.cgi?id=1032action=view which seems to be down at the moment (tested from both sides of the pond) OE bugzilla has been decommissioned long ago. In that case the Using IceCC page on the OE wiki [1] should not be linking to it. Can someone who has actually used IceCC in conjunction with OE (or has contact with someone who has) please update the page? Martin? We're not using create-icecc-env.sh script, I've updated the page how to use icecc service in ubuntu and removed old link. Thanks, Paul [1] http://www.openembedded.org/wiki/Using_IceCC -- Paul Eggleton Intel Open Source Technology Centre -- 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] Distributing Compilation of Yocto
On 2013-06-11 10:07, Martin Jansa wrote: On Tue, Jun 11, 2013 at 09:20:05AM +0100, Paul Eggleton wrote: On Monday 10 June 2013 20:16:22 Khem Raj wrote: On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas g...@mlbassoc.com wrote: Looks interesting and I think I'd like to try it myself. However, that page has a reference to http://bugs.openembedded.org/attachment.cgi?id=1032action=view which seems to be down at the moment (tested from both sides of the pond) OE bugzilla has been decommissioned long ago. In that case the Using IceCC page on the OE wiki [1] should not be linking to it. Can someone who has actually used IceCC in conjunction with OE (or has contact with someone who has) please update the page? Martin? We're not using create-icecc-env.sh script, I've updated the page how to use icecc service in ubuntu and removed old link. I'm confused (sorry) - there are still references to that script on the Wiki page. If you're not using the create-icecc-env.sh, how do you set it up and what does ICECC_ENV_EXEC point to? Also I assume based on the current page that your patch to icecc.bbclass is not yet merged? Thanks Thanks, Paul [1] http://www.openembedded.org/wiki/Using_IceCC -- Paul Eggleton Intel Open Source Technology Centre -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Distributing Compilation of Yocto
On Tue, Jun 11, 2013 at 10:26:47AM +0100, Gary Thomas wrote:
On 2013-06-11 10:07, Martin Jansa wrote:
On Tue, Jun 11, 2013 at 09:20:05AM +0100, Paul Eggleton wrote:
On Monday 10 June 2013 20:16:22 Khem Raj wrote:
On Fri, Jun 7, 2013 at 4:11 AM, Gary Thomas g...@mlbassoc.com wrote:
Looks interesting and I think I'd like to try it myself. However, that
page has a reference to
http://bugs.openembedded.org/attachment.cgi?id=1032action=view
which seems to be down at the moment (tested from both sides of the pond)
OE bugzilla has been decommissioned long ago.
In that case the Using IceCC page on the OE wiki [1] should not be
linking
to it. Can someone who has actually used IceCC in conjunction with OE (or
has
contact with someone who has) please update the page? Martin?
We're not using create-icecc-env.sh script, I've updated the page how to
use icecc service in ubuntu and removed old link.
I'm confused (sorry) - there are still references to that script on the Wiki
page.
If you're not using the create-icecc-env.sh, how do you set it up and what
does
ICECC_ENV_EXEC point to?
icecc.bbclass:
ICECC_ENV_EXEC ?= ${STAGING_BINDIR_NATIVE}/icecc-create-env
Also I assume based on the current page that your patch to icecc.bbclass is
not
yet merged?
Thanks, I've removed reference to that patch which is now merged.
--
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] Can Yocto run on host with other CPU types
On 7 June 2013 11:45, Luo Zhenhua-B19537 b19...@freescale.com wrote: [Luo Zhenhua-B19537] Does it make sense to log defects in YP bugzilla if issue is found on host with those CPU types? We don't claim to only support x86 hosts, so yes. BTW, is there a limitation for maximum parallel number of Yocto build? I don't think the number can be arbitrary. Bitbake threads or make tasks? I'm not sure on the former, but for the latter the range is effectively infinite - if make can spawn 2000 sub-makes it will (depending on the makefile). This is effectively a fork bomb so I don't recommend it though ;) Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFC PATCH v2 00/50] Refactor and merge windows-build to master
This is only the cover letter for the entire patch series. Changed since v1: - implemented FIXME tasks in BBSession. The following changes since commit 57c5d62fab9bc1024a3cf1f3f840f7f3bcfd3167: Fix Thread Access exception for systemtap Dialogs (2013-05-31 15:07:01 +0300) are available in the git repository at: git://git.yoctoproject.org/poky-contrib igrigorx/common-remote-refactor http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=igrigorx/common-remote-refactor Ioana Grigoropol (50): Rename RSEHelper to RemoteHelper to match usages in org.yocto.bc.ui.plugin Add ProcessStreamBuffer utility class Move ICommandResponseHandler to org.yocto.remote.utils Add YoctoCommand utility class Add CommandResponseHandler implementation of ICommandResponseHandler Add ConsoleRunnable utility class Add ConsoleHelper utility class Add OutputProcessor utility class Add CommandOutputProcessor utilty class Refactor RemoteHelper class Remove ICommandResponseHandler from plugin and use org.yocto.remote.utils implementation Remove unused Bitbake Actions Remove storing of init script location Remove unused method loadInit in Activator Remove unused getInitScript from ProjectInfoHelper Use URI for storing project locations Redirect bitbake environment parsing to file parse Use YoctoHostFile for storing OEFile(s) Remove unused checkReadOnlyParent method of OEFile Fix full path of OEFile Fix NullPointerException when detecting changed files Fix Hob launching on Linux host Enable editsave of remote files Fix variables hoover Fix ShellSession execute Remove shell type from ShellSession constructor Use / as separator instead of OS separator Remove unsed methods inner classes from ShellSession Save active connection for Bitbake recipe Initialize and store the connection on Recipe Wizard Store connection for recipe in Recipe Wizard Page Refactor Wizard Page fields to have consistent names Refactor populate method name Break handlePopulate into remote and local functions Use uri instead of string to determine location of recipe determine archive type Store metadata location as URI instead of String Refactor Recipe Wizard Page to use Remote target Api Run all Recipe task in wizard container Enable Populate button when src URI changes Store reference to OptionsPage in InstallWizard Collect Bitbake error lines Refactor Bitbake wizard to use RemoteHelper API Retrieve console from RemoteHelper instead of recreating it Remove LongRunningTask,ICalculatePercentage from InstallWizard Create separated class for ConsoleWriter Remove unused ConsoleWriter Add implicit constructror for OEFileSystemContributor Refactor and clean-up of OptionsPage fields Refactor OptionsPage to use Remote Location box validation Validate project name to check for invalid characters plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF | 11 +- plugins/org.yocto.bc.ui/plugin.xml | 55 -- .../src/org/yocto/bc/bitbake/BBRecipe.java | 26 +- .../src/org/yocto/bc/bitbake/BBSession.java| 117 +++-- .../org/yocto/bc/bitbake/ProjectInfoHelper.java| 58 +-- .../src/org/yocto/bc/bitbake/ShellSession.java | 164 +++--- .../org/yocto/bc/remote/utils/ConsoleWriter.java | 36 ++ .../bc/remote/utils/YoctoRunnableWithProgress.java | 211 .../src/org/yocto/bc/ui/Activator.java | 83 ++- .../ui/actions/AbstractBitbakeCommandAction.java | 199 .../bc/ui/actions/BitbakeBuildRecipeAction.java| 24 - .../bc/ui/actions/BitbakeCleanRecipeAction.java| 26 - .../yocto/bc/ui/actions/BitbakeImportAction.java | 106 .../bc/ui/actions/BitbakeRebuildRecipeAction.java | 29 -- .../bc/ui/actions/LaunchVariableWizardAction.java | 16 +- .../bc/ui/builder/BitbakeCommanderNature.java |2 +- .../bc/ui/editors/bitbake/BBVariableTextHover.java | 28 +- .../editors/bitbake/BitBakeDocumentProvider.java | 40 +- .../bc/ui/editors/bitbake/BitBakeFileEditor.java | 19 +- .../bitbake/BitBakeSourceViewerConfiguration.java | 18 +- .../src/org/yocto/bc/ui/filesystem/OEFile.java | 295 +++ .../org/yocto/bc/ui/filesystem/OEFileSystem.java | 37 +- .../bc/ui/filesystem/OEFileSystemContributor.java |3 + .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java |7 +- .../org/yocto/bc/ui/filesystem/YoctoLocation.java | 34 ++ .../src/org/yocto/bc/ui/model/ProjectInfo.java | 75 ++- .../src/org/yocto/bc/ui/model/YoctoHostFile.java | 306 .../yocto/bc/ui/views/RecipeContentProvider.java |2 +- .../bc/ui/wizards/BitbakeRecipeUIElement.java | 15 +- .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java | 41 +- .../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 528 +++- .../importProject/ImportYoctoProjectWizard.java|7 +- .../yocto/bc/ui/wizards/install/InstallWizard.java |
Re: [yocto] [Refactor RFC 9/9] Redirect bitbake environment parsing to file parse
Hi Jessica,
The first fixme message is just a left-over. We don't need to perform any
waiting actions since the command is ran synchronously.
As for the second fixme, its purpose was to perform some clean-up of the
environment file (bitbake.env), and thus will be replaced with a call to rm
-rf.
I have sent a pull request for this change, from poky-contrib, branch:
igrigorx/common-remote-refactor
Ioana
From: Zhang, Jessica
Sent: Friday, June 07, 2013 3:27 AM
To: Grigoropol, IoanaX; yocto@yoctoproject.org
Subject: RE: [yocto] [Refactor RFC 9/9] Redirect bitbake environment parsing to
file parse
Ioana,
There're couple fixme in wait for bitbake to finish and clean up the
environment file that seems not addressed. Also, please make sure the changed
files have valid license info.
Thanks,
Jessica
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Ioana Grigoropol
Sent: Tuesday, June 04, 2013 6:26 AM
To: yocto@yoctoproject.org
Subject: [yocto] [Refactor RFC 9/9] Redirect bitbake environment parsing to
file parse
- when running bitbake -e the output is sent to the console, poluting it
- instead, send the output to a file (bitbake.env) and parse the file
accordingly
- if an error has occured while running the commad, all the error lines are
collected and displayed on the console
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../src/org/yocto/bc/bitbake/BBRecipe.java |2 +-
.../src/org/yocto/bc/bitbake/BBSession.java| 49 +---
.../src/org/yocto/bc/bitbake/ShellSession.java | 14 +++---
3 files changed, 40 insertions(+), 25 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 1baf124..6168f8c 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
@@ -26,7 +26,7 @@ public class BBRecipe extends BBSession {
super(session.shell, session.pinfo.getOriginalURI());
this.session = session;
this.fileURI = filePath;
- this.parsingCmd = DISABLE_SANITY_CHECKS=1 bitbake -e -b +
filePath;
+ this.parsingCmd = DISABLE_SANITY_CHECKS=\1\ bitbake -e -b +
+filePath.getPath() ++ BB_ENV_FILE;
}
@Override
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 fcde557..9bc4dcc 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
@@ -15,6 +15,8 @@ import java.io.File;
import java.io.FileFilter;
import java.io.IOException;
import java.io.StringReader;
+import java.io.InputStream;
+import java.io.InputStreamReader;
import java.net.URI;
import java.util.ArrayList;
import java.util.Arrays;
@@ -33,9 +35,11 @@ import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IResource;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus;
+import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.core.runtime.Status; import
org.eclipse.jface.preference.JFacePreferences;
import org.eclipse.jface.resource.JFaceResources;
+import org.eclipse.rse.core.model.IHost;
import org.eclipse.ui.console.ConsolePlugin;
import org.eclipse.ui.console.IConsole; import
org.eclipse.ui.console.IConsoleManager;
@@ -45,6 +49,7 @@ import org.eclipse.ui.progress.WorkbenchJob;
import org.yocto.bc.ui.model.IModelElement;
import org.yocto.bc.ui.model.ProjectInfo;
+import org.yocto.remote.utils.RemoteHelper;
/**
* BBSession encapsulates a global bitbake configuration and is the primary
interface @@ -59,6 +64,7 @@ public class BBSession implements
IBBSessionListener, IModelElement, Map {
public static final int TYPE_STATEMENT = 3;
public static final int TYPE_FLAG = 4;
+ public static final String BB_ENV_FILE = bitbake.env;
public static final String BUILDDIR_INDICATORS [] = {
File.separatorChar + conf + File.separatorChar + local.conf,
File.separatorChar + conf + File.separatorChar +
bblayers.conf, @@ -69,19 +75,21 @@ public class BBSession implements
IBBSessionListener, IModelElement, Map {
protected Map?,? properties = null;
protected List URI depends = null;
protected boolean initialized = false;
+ protected boolean errorOccured = false;
protected MessageConsole sessionConsole;
private final ReentrantReadWriteLock rwlock = new
ReentrantReadWriteLock();
private final Lock rlock = rwlock.readLock();
private final Lock wlock = rwlock.writeLock();
protected String parsingCmd;
[yocto] [PATCH] dlt-daemon: Fix multiple issues with service files.
From: Noor noor_ah...@mentor.com
* The newly included patch, systemd_service_installation.patch, is required
because the cmake script in the dlt-daemon package tries to locate the
systemd units directory on the host. During cross compiling it should not
see paths on local machine and make decesion based on it. On ubuntu 10.04
/lib/systemd/system folder does not exist so cross-compiling dlt-deamon
results in no servie file image folder. So commented the if condition which
checks the existance of /lib/systemd/system.
* Created symlinks of dlt.service and dlt-system.servic in basic.target.wants
folder.
* Set PARALLEL_MAKE to as faced some issues when it was set.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
.../systemd_service_installation.patch | 24
recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb| 16 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git
a/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
b/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
new file mode 100644
index 000..8469a5e
--- /dev/null
+++
b/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
@@ -0,0 +1,24 @@
+--- git/systemd/CMakeLists_old.txt 2013-03-12 16:53:37.052664326 +0500
git/systemd/CMakeLists.txt 2013-03-12 16:53:57.052896347 +0500
+@@ -46,15 +46,15 @@ if(WITH_SYSTEMD)
+ message(STATUS DLT adaptor udp configuration:
APPID=${DLT_ADAPTOR_UDP_APPID} CTID=${DLT_ADAPTOR_UDP_CTID}
PORT=${DLT_ADAPTOR_UDP_PORT} )
+
+
+-if(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#if(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt.service DESTINATION
${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-system.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-receive.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-example-user.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-adaptor-udp.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ message(STATUS Unit files will be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install )
+-else(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+-message(STATUS Unit files will not be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install)
+-endif(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#else(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#message(STATUS Unit files will not be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install)
++#endif(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+
+-endif(WITH_SYSTEMD)
+\ No newline at end of file
++endif(WITH_SYSTEMD)
diff --git a/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
b/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
index 9cdbfc0..82b46eb 100644
--- a/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
+++ b/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
@@ -19,7 +19,9 @@ LICENSE = MPLv2
LIC_FILES_CHKSUM = file://LICENSE.txt;md5=99ba60c3fad7eaf8c56bca6dd75cba09 \
file://MPL.txt;md5=ccdb2761cef70c8b2612624c323f89dc
-SRC_URI = git://git.projects.genivi.org/${PN}.git;protocol=git;tag=v${PV}
+SRC_URI = git://git.projects.genivi.org/${PN}.git;protocol=git;tag=v${PV} \
+ file://systemd_service_installation.patch \
+
S = ${WORKDIR}/git
@@ -31,3 +33,15 @@ FILES_${PN}-systemd += ${systemd_unitdir}/system/
PACKAGES =+ ${PN}-systemd
EXTRA_OECMAKE = -DWITH_SYSTEMD=ON
+
+PARALLEL_MAKE =
+
+do_install_append() {
+# Remove User=genivi option from systemd service files, as we want this
to go to default setting
+sed -i '/User/d' ${D}/${systemd_unitdir}/system/*.service
+
+# Install the required systemd services links
+install -d ${D}${base_libdir}/systemd/system/basic.target.wants
+ln -sf ../dlt.service
${D}${base_libdir}/systemd/system/basic.target.wants/dlt.service
+ln -sf ../dlt-system.service
${D}${base_libdir}/systemd/system/basic.target.wants/dlt-system.service
+}
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] dlt-daemon: Fix multiple issues with service files.
Hi,
From: Noor noor_ah...@mentor.com
Did you file a bug with upstream
http://projects.genivi.org/diagnostic-log-trace/ and provided them with these
patches too? As I do not see them on the email distribution list. If so, can
you make a reference to the bugzilla id(s) of any bug(s) you filed against the
DLT daemon regarding these two issues in the commit message?
Thank you.
Best regards,
Holger
---
* The newly included patch, systemd_service_installation.patch, is required
because the cmake script in the dlt-daemon package tries to locate the
systemd units directory on the host. During cross compiling it should not
see paths on local machine and make decesion based on it. On ubuntu 10.04
/lib/systemd/system folder does not exist so cross-compiling dlt-deamon
results in no servie file image folder. So commented the if condition which
checks the existance of /lib/systemd/system.
* Created symlinks of dlt.service and dlt-system.servic in basic.target.wants
folder.
* Set PARALLEL_MAKE to as faced some issues when it was set.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
.../systemd_service_installation.patch | 24
recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb| 16 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git
a/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
b/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
new file mode 100644
index 000..8469a5e
--- /dev/null
+++
b/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
@@ -0,0 +1,24 @@
+--- git/systemd/CMakeLists_old.txt 2013-03-12 16:53:37.052664326 +0500
git/systemd/CMakeLists.txt 2013-03-12 16:53:57.052896347 +0500
+@@ -46,15 +46,15 @@ if(WITH_SYSTEMD)
+ message(STATUS DLT adaptor udp configuration:
APPID=${DLT_ADAPTOR_UDP_APPID} CTID=${DLT_ADAPTOR_UDP_CTID}
PORT=${DLT_ADAPTOR_UDP_PORT} )
+
+
+-if(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#if(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt.service DESTINATION
${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-system.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-receive.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-example-user.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-adaptor-udp.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ message(STATUS Unit files will be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install )
+-else(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+-message(STATUS Unit files will not be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install)
+-endif(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#else(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#message(STATUS Unit files will not be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install)
++#endif(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+
+-endif(WITH_SYSTEMD)
+\ No newline at end of file
++endif(WITH_SYSTEMD)
diff --git a/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
b/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
index 9cdbfc0..82b46eb 100644
--- a/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
+++ b/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
@@ -19,7 +19,9 @@ LICENSE = MPLv2
LIC_FILES_CHKSUM = file://LICENSE.txt;md5=99ba60c3fad7eaf8c56bca6dd75cba09 \
file://MPL.txt;md5=ccdb2761cef70c8b2612624c323f89dc
-SRC_URI = git://git.projects.genivi.org/${PN}.git;protocol=git;tag=v${PV}
+SRC_URI = git://git.projects.genivi.org/${PN}.git;protocol=git;tag=v${PV} \
+ file://systemd_service_installation.patch \
+
S = ${WORKDIR}/git
@@ -31,3 +33,15 @@ FILES_${PN}-systemd += ${systemd_unitdir}/system/
PACKAGES =+ ${PN}-systemd
EXTRA_OECMAKE = -DWITH_SYSTEMD=ON
+
+PARALLEL_MAKE =
+
+do_install_append() {
+# Remove User=genivi option from systemd service files, as we want this
to go to default setting
+sed -i '/User/d' ${D}/${systemd_unitdir}/system/*.service
+
+# Install the required systemd services links
+install -d ${D}${base_libdir}/systemd/system/basic.target.wants
+ln -sf ../dlt.service
${D}${base_libdir}/systemd/system/basic.target.wants/dlt.service
+ln -sf ../dlt-system.service
${D}${base_libdir}/systemd/system/basic.target.wants/dlt-system.service
+}
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to deal with non-standard license.
Hi everybody, I have written a recipe which I'd like to contribute for glmark2: https://launchpad.net/glmark2 The last thing that puzzles me before submitting it is that it's partly GPL3+, and partly under this license: https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI which is not in this list: https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group#Licenses Is there any way to deal with that license? What should I put in the LICENSE field in my recipe? Bests, Diego ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH V2] dlt-daemon: Fix multiple issues with service files.
From: Noor noor_ah...@mentor.com
* The newly included patch, systemd_service_installation.patch, is required
because the cmake script in the dlt-daemon package tries to locate the
systemd units directory on the host. During cross compiling it should not
see paths on local machine and make decesion based on it. On ubuntu 10.04
/lib/systemd/system folder does not exist so cross-compiling dlt-deamon
results in no servie file image folder. So commented the if condition which
checks the existance of /lib/systemd/system. Genivi issue link dealing with
this is http://bugs.genivi.org/show_bug.cgi?id=67.
* Created symlinks of dlt.service and dlt-system.servic in basic.target.wants
folder.
* Set PARALLEL_MAKE to as faced some issues when it was set.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
.../systemd_service_installation.patch | 24
recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb| 16 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git
a/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
b/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
new file mode 100644
index 000..8469a5e
--- /dev/null
+++
b/recipes-extended/dlt-daemon/dlt-daemon-2.9.0/systemd_service_installation.patch
@@ -0,0 +1,24 @@
+--- git/systemd/CMakeLists_old.txt 2013-03-12 16:53:37.052664326 +0500
git/systemd/CMakeLists.txt 2013-03-12 16:53:57.052896347 +0500
+@@ -46,15 +46,15 @@ if(WITH_SYSTEMD)
+ message(STATUS DLT adaptor udp configuration:
APPID=${DLT_ADAPTOR_UDP_APPID} CTID=${DLT_ADAPTOR_UDP_CTID}
PORT=${DLT_ADAPTOR_UDP_PORT} )
+
+
+-if(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#if(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt.service DESTINATION
${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-system.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-receive.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-example-user.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ install(FILES ${PROJECT_BINARY_DIR}/systemd/dlt-adaptor-udp.service
DESTINATION ${SYSTEMD_CONFIGURATIONS_FILES_DIR} )
+ message(STATUS Unit files will be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install )
+-else(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+-message(STATUS Unit files will not be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install)
+-endif(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#else(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
++#message(STATUS Unit files will not be installed to
${SYSTEMD_CONFIGURATIONS_FILES_DIR} after make install)
++#endif(EXISTS ${SYSTEMD_CONFIGURATIONS_FILES_DIR})
+
+-endif(WITH_SYSTEMD)
+\ No newline at end of file
++endif(WITH_SYSTEMD)
diff --git a/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
b/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
index 9cdbfc0..82b46eb 100644
--- a/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
+++ b/recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb
@@ -19,7 +19,9 @@ LICENSE = MPLv2
LIC_FILES_CHKSUM = file://LICENSE.txt;md5=99ba60c3fad7eaf8c56bca6dd75cba09 \
file://MPL.txt;md5=ccdb2761cef70c8b2612624c323f89dc
-SRC_URI = git://git.projects.genivi.org/${PN}.git;protocol=git;tag=v${PV}
+SRC_URI = git://git.projects.genivi.org/${PN}.git;protocol=git;tag=v${PV} \
+ file://systemd_service_installation.patch \
+
S = ${WORKDIR}/git
@@ -31,3 +33,15 @@ FILES_${PN}-systemd += ${systemd_unitdir}/system/
PACKAGES =+ ${PN}-systemd
EXTRA_OECMAKE = -DWITH_SYSTEMD=ON
+
+PARALLEL_MAKE =
+
+do_install_append() {
+# Remove User=genivi option from systemd service files, as we want this
to go to default setting
+sed -i '/User/d' ${D}/${systemd_unitdir}/system/*.service
+
+# Install the required systemd services links
+install -d ${D}${base_libdir}/systemd/system/basic.target.wants
+ln -sf ../dlt.service
${D}${base_libdir}/systemd/system/basic.target.wants/dlt.service
+ln -sf ../dlt-system.service
${D}${base_libdir}/systemd/system/basic.target.wants/dlt-system.service
+}
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] No crosscompiler in Toolchain
Gentlemen! We have a problem here... I compiled the toolchain using the command *bitbake core-image-skidata -c populate_sdk *and installed the toolchain but I have to tell you that I dont see any cross-compiler installed with the toolchain... Any guesses what could be the reason.. The image is customized x11 image... Greets, Satya ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Fix bug related to system tap window resize
- when ok is pressed, the system tap window is resized in stead of running the
script
- this is caused by the fact that the window is opened twice and only the
second call is taken into consideration
[Yocto #4598]
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
---
.../sdk/remotetools/actions/SystemtapHandler.java |1 -
1 file changed, 1 deletion(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
index 87094ee..9d27e5a 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/SystemtapHandler.java
@@ -33,7 +33,6 @@ public class SystemtapHandler extends AbstractHandler {
shell, Systemtap
);
- setting.open();
String metadata_location =
((SystemtapSettingDialog)setting).getMetadataLocation();
String remote_host =
((SystemtapSettingDialog)setting).getRemoteHost();
String user_id = ((SystemtapSettingDialog)setting).getUserID();
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Custom kernel in Yocto/dylan branch.
Hi!
I few years ago I used to work with OpenEmbedded (the classical
branch). The addition of new kernel recipes was easy for me,
nevertheless I'm unable to do similar things with the current
Yocto-dylan branch.
The current Yocto-dylan is based on Linux kernel 3.x branches, all the
documentation regarding add custom kernels or new kernel features are
based on those 3.x branches. However, I would like to use a 2.6.32
Linux kernel (it's a constraint for my project).
I'm using the following kernel recipe in my bsp:
linux/
linux-yocto-abacus/
defconfig
linux-yocto-abacus_2.6.32.bb
# linux-yocto-abacus_2.6.32.bb
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
INHIBIT_PACKAGE_DEBUG_SPLIT =3D 1
FILESEXTRAPATHS_prepend :=3D ${THISDIR}/${PN}:
SRC_URI_append =3D file://defconfig
PROVIDES =3D virtual/kernel
SRC_URI =3D git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g=
it;protocol=3Dgit;nocheckout=3D1
LINUX_VERSION =3D 2.6.32
LINUX_VERSION_EXTENSION =3D -abacus
# tag: v3.476e10d158efb6d4516018846f60c2ab5501900bc
# tag: v2.6.32 459b3d520991ec1b8e5ba68fbc4b206d602fee6e
SRCREV=3D459b3d520991ec1b8e5ba68fbc4b206d602fee6e
PR =3D r1
PV =3D ${LINUX_VERSION}+git${SRCPV}
COMPATIBLE_MACHINE =3D romley
end ###
When I build the kernel with:
# bitbake virtual/kernel
The kernel is downloaded from kernel.org, with the correct git tag
(v2.6.32) and is built with success. Nevertheless, the defconfig is
not properly added in the kernel configuration. If I run:
# bitbake virtual/kernel -c menuconfig
The ncurses menuconfig is not using the defconfig added by me.
The defconfig with all kernel configurations is a deprecated feature?
Which is the correct way to add a new kernel recipe?
Many thanks!
Javi Roman
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom kernel in Yocto/dylan branch.
On 13-06-11 10:18 AM, Javi Roman wrote:
Hi!
I few years ago I used to work with OpenEmbedded (the classical
branch). The addition of new kernel recipes was easy for me,
nevertheless I'm unable to do similar things with the current
Yocto-dylan branch.
The current Yocto-dylan is based on Linux kernel 3.x branches, all the
documentation regarding add custom kernels or new kernel features are
based on those 3.x branches. However, I would like to use a 2.6.32
Linux kernel (it's a constraint for my project).
I'm using the following kernel recipe in my bsp:
linux/
linux-yocto-abacus/
defconfig
linux-yocto-abacus_2.6.32.bb
# linux-yocto-abacus_2.6.32.bb
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
INHIBIT_PACKAGE_DEBUG_SPLIT =3D 1
FILESEXTRAPATHS_prepend :=3D ${THISDIR}/${PN}:
SRC_URI_append =3D file://defconfig
PROVIDES =3D virtual/kernel
SRC_URI =3D git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g=
it;protocol=3Dgit;nocheckout=3D1
LINUX_VERSION =3D 2.6.32
LINUX_VERSION_EXTENSION =3D -abacus
# tag: v3.476e10d158efb6d4516018846f60c2ab5501900bc
# tag: v2.6.32 459b3d520991ec1b8e5ba68fbc4b206d602fee6e
SRCREV=3D459b3d520991ec1b8e5ba68fbc4b206d602fee6e
PR =3D r1
PV =3D ${LINUX_VERSION}+git${SRCPV}
COMPATIBLE_MACHINE =3D romley
end ###
When I build the kernel with:
# bitbake virtual/kernel
The kernel is downloaded from kernel.org, with the correct git tag
(v2.6.32) and is built with success. Nevertheless, the defconfig is
not properly added in the kernel configuration. If I run:
# bitbake virtual/kernel -c menuconfig
The ncurses menuconfig is not using the defconfig added by me.
The defconfig with all kernel configurations is a deprecated feature?
Which is the correct way to add a new kernel recipe?
It definitely should still be working, we have plenty of defconfig
users (whether right or wong ;) and it is tested daily.
How did you specify your defconfig on the SRC_URI ?
Bruce
Many thanks!
Javi Roman
___
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] Custom kernel in Yocto/dylan branch.
With
SRC_URI_append = file://defconfig
Javi Roman
On Tue, Jun 11, 2013 at 4:23 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-06-11 10:18 AM, Javi Roman wrote:
Hi!
I few years ago I used to work with OpenEmbedded (the classical
branch). The addition of new kernel recipes was easy for me,
nevertheless I'm unable to do similar things with the current
Yocto-dylan branch.
The current Yocto-dylan is based on Linux kernel 3.x branches, all the
documentation regarding add custom kernels or new kernel features are
based on those 3.x branches. However, I would like to use a 2.6.32
Linux kernel (it's a constraint for my project).
I'm using the following kernel recipe in my bsp:
linux/
linux-yocto-abacus/
defconfig
linux-yocto-abacus_2.6.32.bb
# linux-yocto-abacus_2.6.32.bb
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
INHIBIT_PACKAGE_DEBUG_SPLIT =3D 1
FILESEXTRAPATHS_prepend :=3D ${THISDIR}/${PN}:
SRC_URI_append =3D file://defconfig
PROVIDES =3D virtual/kernel
SRC_URI =3D
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g=
it;protocol=3Dgit;nocheckout=3D1
LINUX_VERSION =3D 2.6.32
LINUX_VERSION_EXTENSION =3D -abacus
# tag: v3.476e10d158efb6d4516018846f60c2ab5501900bc
# tag: v2.6.32 459b3d520991ec1b8e5ba68fbc4b206d602fee6e
SRCREV=3D459b3d520991ec1b8e5ba68fbc4b206d602fee6e
PR =3D r1
PV =3D ${LINUX_VERSION}+git${SRCPV}
COMPATIBLE_MACHINE =3D romley
end ###
When I build the kernel with:
# bitbake virtual/kernel
The kernel is downloaded from kernel.org, with the correct git tag
(v2.6.32) and is built with success. Nevertheless, the defconfig is
not properly added in the kernel configuration. If I run:
# bitbake virtual/kernel -c menuconfig
The ncurses menuconfig is not using the defconfig added by me.
The defconfig with all kernel configurations is a deprecated feature?
Which is the correct way to add a new kernel recipe?
It definitely should still be working, we have plenty of defconfig
users (whether right or wong ;) and it is tested daily.
How did you specify your defconfig on the SRC_URI ?
Bruce
Many thanks!
Javi Roman
___
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] Custom kernel in Yocto/dylan branch.
On 13-06-11 10:47 AM, Javi Roman wrote:
With
SRC_URI_append = file://defconfig
Which is what I expected. And you say that it isn't being applied
at all ? Is that by inspecting the final contents of .config ?
Or something else ?
Since this is on the dylan branches, I know it has been tested
explicitly there.
I'll switch and do some of my own test builds.
Cheers,
Bruce
Javi Roman
On Tue, Jun 11, 2013 at 4:23 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-06-11 10:18 AM, Javi Roman wrote:
Hi!
I few years ago I used to work with OpenEmbedded (the classical
branch). The addition of new kernel recipes was easy for me,
nevertheless I'm unable to do similar things with the current
Yocto-dylan branch.
The current Yocto-dylan is based on Linux kernel 3.x branches, all the
documentation regarding add custom kernels or new kernel features are
based on those 3.x branches. However, I would like to use a 2.6.32
Linux kernel (it's a constraint for my project).
I'm using the following kernel recipe in my bsp:
linux/
linux-yocto-abacus/
defconfig
linux-yocto-abacus_2.6.32.bb
# linux-yocto-abacus_2.6.32.bb
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
INHIBIT_PACKAGE_DEBUG_SPLIT =3D 1
FILESEXTRAPATHS_prepend :=3D ${THISDIR}/${PN}:
SRC_URI_append =3D file://defconfig
PROVIDES =3D virtual/kernel
SRC_URI =3D
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g=
it;protocol=3Dgit;nocheckout=3D1
LINUX_VERSION =3D 2.6.32
LINUX_VERSION_EXTENSION =3D -abacus
# tag: v3.476e10d158efb6d4516018846f60c2ab5501900bc
# tag: v2.6.32 459b3d520991ec1b8e5ba68fbc4b206d602fee6e
SRCREV=3D459b3d520991ec1b8e5ba68fbc4b206d602fee6e
PR =3D r1
PV =3D ${LINUX_VERSION}+git${SRCPV}
COMPATIBLE_MACHINE =3D romley
end ###
When I build the kernel with:
# bitbake virtual/kernel
The kernel is downloaded from kernel.org, with the correct git tag
(v2.6.32) and is built with success. Nevertheless, the defconfig is
not properly added in the kernel configuration. If I run:
# bitbake virtual/kernel -c menuconfig
The ncurses menuconfig is not using the defconfig added by me.
The defconfig with all kernel configurations is a deprecated feature?
Which is the correct way to add a new kernel recipe?
It definitely should still be working, we have plenty of defconfig
users (whether right or wong ;) and it is tested daily.
How did you specify your defconfig on the SRC_URI ?
Bruce
Many thanks!
Javi Roman
___
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/3] [meta-ivi] portmap: Use systemd service type forking instead of oneshot
From: Muhammad Shakeel muhammad_shak...@mentor.com portmap is a resident program and we want to start it in background. With service type 'forking' systemd knows that the executable is a daemon. Although in this case 'oneshot' + 'RemainAfterExit=yes' works but it is intended for non-resident programs. Signed-off-by: Muhammad Shakeel muhammad_shak...@mentor.com --- .../portmap/portmap/portmap.service|4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes-connectivity/portmap/portmap/portmap.service b/recipes-connectivity/portmap/portmap/portmap.service index 7f9bc94..a76754f 100644 --- a/recipes-connectivity/portmap/portmap/portmap.service +++ b/recipes-connectivity/portmap/portmap/portmap.service @@ -3,9 +3,9 @@ Description=Portmap After=connman.service [Service] -Type=oneshot +Type=forking ExecStart=/sbin/portmap -l -RemainAfterExit=yes +PIDFile=/var/run/portmap.pid [Install] WantedBy=multi-user.target -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 3/3] [meta-ivi] portmap: By default do not bind to 127.0.0.1
From: Muhammad Shakeel muhammad_shak...@mentor.com -l prevents portmap from binding to other external networking interfaces i.e. ethernet Signed-off-by: Muhammad Shakeel muhammad_shak...@mentor.com --- .../portmap/portmap/portmap.service|2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-connectivity/portmap/portmap/portmap.service b/recipes-connectivity/portmap/portmap/portmap.service index a76754f..e14058d 100644 --- a/recipes-connectivity/portmap/portmap/portmap.service +++ b/recipes-connectivity/portmap/portmap/portmap.service @@ -4,7 +4,7 @@ After=connman.service [Service] Type=forking -ExecStart=/sbin/portmap -l +ExecStart=/sbin/portmap PIDFile=/var/run/portmap.pid [Install] -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/3] [meta-ivi] portmap: Write portmap.pid file at startup
From: Muhammad Shakeel muhammad_shak...@mentor.com
Portmap systemd service is expecting this file to be present and
without this patch portmap service will fail, with timeout status.
Signed-off-by: Muhammad Shakeel muhammad_shak...@mentor.com
---
.../portmap/portmap/pid_file_creation.patch| 162
recipes-connectivity/portmap/portmap_6.0.bbappend |3 +-
2 files changed, 164 insertions(+), 1 deletion(-)
diff --git a/recipes-connectivity/portmap/portmap/pid_file_creation.patch
b/recipes-connectivity/portmap/portmap/pid_file_creation.patch
new file mode 100644
index 000..ec99968
--- /dev/null
+++ b/recipes-connectivity/portmap/portmap/pid_file_creation.patch
@@ -0,0 +1,162 @@
+Create portmap.pid file at startup
+
+This patch has been taken from:
+http://debian.2.n7.nabble.com/Bug-448470-Portmap-does-not-start-if-a-random-user-has-a-process-named-portmap-td440179.html
+Witout this patch systemd service was failing to start because no pidfile
+was getting generated by portmap. This problem is solved by getting
+portmap to write a pidfile, making sure the correct process is checked by
+the start script instead of a random one with the portmap name.
+
+Upstream-Status: Pending
+
+Signed-off-by: Muhammad Shakeel muhammad_shak...@mentor.com
+===
+--- portmap-6.0.orig/portmap.c
portmap-6.0/portmap.c
+@@ -98,6 +98,8 @@
+
+ #include stdlib.h
+ #include pwd.h
++#include stdarg.h
++#include sys/stat.h
+
+ #ifndef LOG_PERROR
+ #define LOG_PERROR 0
+@@ -169,6 +171,126 @@
+int priv;
+ };
+
++#ifndef PIDFILE
++# define PIDFILE /var/run/portmap.pid
++#endif
++
++/*
++ * Copied from the atd source
++ */
++static int
++lock_fd(int fd)
++{
++struct flock lock;
++
++lock.l_type = F_WRLCK;
++lock.l_whence = SEEK_SET;
++lock.l_start = 0;
++lock.l_len = 0;
++
++return fcntl(fd, F_SETLK, lock);
++}
++
++void
++perr(const char *fmt,...)
++{
++char buf[1024];
++va_list args;
++
++va_start(args, fmt);
++vsnprintf(buf, sizeof(buf), fmt, args);
++va_end(args);
++
++if (debugging) {
++ perror(buf);
++} else
++ syslog(LOG_ERR, %s: %m, buf);
++
++exit(EXIT_FAILURE);
++}
++
++void
++pabort(const char *fmt,...)
++{
++char buf[1024];
++va_list args;
++
++va_start(args, fmt);
++vsnprintf(buf, sizeof(buf), fmt, args);
++va_end(args);
++
++if (debugging) {
++ fprintf(stderr, %s\n, buf);
++} else
++ syslog(LOG_ERR, %s, buf);
++
++exit(EXIT_FAILURE);
++}
++
++FILE *
++save_pidfile(void) {
++pid_t pid;
++int fd;
++FILE *fp;
++fd = open(PIDFILE, O_RDWR | O_CREAT | O_EXCL,
++ S_IWUSR | S_IRUSR | S_IRGRP | S_IROTH);
++
++if (fd == -1) {
++
++ if (errno != EEXIST)
++ perr(Cannot open PIDFILE);
++
++ if ((fd = open(PIDFILE, O_RDWR)) 0)
++ perr(Cannot open PIDFILE);
++
++ fp = fdopen(fd, rw);
++ if (fp == NULL) {
++ perr(Cannot open PIDFILE for reading);
++ }
++ pid = -1;
++ if ((fscanf(fp, %d, pid) != 1) || (pid == getpid())
++ || (lock_fd(fileno(fp)) == 0)) {
++ int rc;
++
++ syslog(LOG_NOTICE, Removing stale lockfile for pid %d, pid);
++
++ rc = unlink(PIDFILE);
++
++ if (rc == -1) {
++ perr(Cannot unlink PIDFILE);
++ }
++ } else {
++ pabort(Another atd already running with pid %d, pid);
++ }
++ fclose(fp);
++
++ unlink(PIDFILE);
++ fd = open(PIDFILE, O_RDWR | O_CREAT | O_EXCL,
++ S_IWUSR | S_IRUSR | S_IRGRP | S_IROTH);
++
++
++ if (fd == -1)
++ perr(Cannot open PIDFILE the second time round);
++
++}
++
++if (lock_fd(fd) == -1)
++ perr(Cannot lock PIDFILE);
++
++fp = fdopen(fd, w);
++if (fp == NULL)
++ perr(Special weirdness: fdopen failed);
++
++fprintf(fp, %d\n, getpid());
++
++/* We do NOT close fd, since we want to keep the lock. However, we don't
++ * want to keep the file descriptor in case of an exec().
++ */
++fflush(fp);
++fcntl(fd, F_SETFD, (long) 1);
++return fp;
++}
++
+ int
+ main(int argc, char **argv)
+ {
+@@ -252,6 +374,8 @@
+exit(1);
+}
+
++ save_pidfile();
++
+ #ifdef LOG_DAEMON
+openlog(portmap, LOG_PID|LOG_NDELAY | ( foreground ? LOG_PERROR : 0),
+FACILITY);
+
+
diff --git a/recipes-connectivity/portmap/portmap_6.0.bbappend
b/recipes-connectivity/portmap/portmap_6.0.bbappend
index 0432982..512b826 100644
--- a/recipes-connectivity/portmap/portmap_6.0.bbappend
+++ b/recipes-connectivity/portmap/portmap_6.0.bbappend
@@ -1,4 +1,4 @@
-PRINC := ${@int(PRINC) + 5}
+PRINC := ${@int(PRINC) + 6}
# Find local ${PN} directory
FILESEXTRAPATHS := ${THISDIR}/${PN}
@@ -12,6 +12,7 @@ FILES_${PN} =+ ${systemd_unitdir}/system/portmap.service
SRC_URI_append
Re: [yocto] Custom kernel in Yocto/dylan branch.
On Tuesday 11 June 2013 16:47:53 Javi Roman wrote: With SRC_URI_append = file://defconfig Does your actual recipe have a leading space in the value? _append won't add this for you so you have to do it explicitly. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FW: Yocto Project 1.5 M1 release readiness meeting
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Pacific Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Liu, Song:MAILTO:song@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=yocto@yoct oproject.org:MAILTO:yocto@yoctoproject.org DESCRIPTION;LANGUAGE=en-US:\nSubject: Yocto Project 1.5 M1 release readines s meeting\nWhen: Thursday\, June 13\, 2013 8:00 AM-8:30 AM (UTC-08:00) Pac ific Time (US Canada).\nWhere: 916-356-2663\, 8-356-2663\, Bridge: 3\, P asscode: 6514012\n\n\nhttps://wiki.yoctoproject.org/wiki/Yocto_Project_v1. 5_Status#Milestone_1https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5 _Status\n\n\nThursday\, June 13\, 2013\, 08:00 AM US Pacific Time\n916-35 6-2663\, 8-356-2663\, Bridge: 3\, Passcode: 6514012\n\n\n SUMMARY;LANGUAGE=en-US:FW: Yocto Project 1.5 M1 release readiness meeting DTSTART;TZID=Pacific Standard Time:20130613T08 DTEND;TZID=Pacific Standard Time:20130613T083000 UID:04008200E00074C5B7101A82E008205F4F168F66CE01000 01000EC17B4CF1612854EAB23DAB1A9E74CC8 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20130611T173512Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:1 LOCATION;LANGUAGE=en-US:916-356-2663\, 8-356-2663\, Bridge: 3\, Passcode: 6 514012 X-MICROSOFT-CDO-APPT-SEQUENCE:1 X-MICROSOFT-CDO-OWNERAPPTID:-1016371235 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT5M END:VALARM END:VEVENT END:VCALENDAR ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No crosscompiler in Toolchain
On Tue, Jun 11, 2013 at 5:59 AM, DAMARLA Satya Swaroop swaroop.dama...@gmail.com wrote: Gentlemen! We have a problem here... Not all here are gentlemen :) I compiled the toolchain using the command bitbake core-image-skidata -c populate_sdk and installed the toolchain but I have to tell you that I dont see any cross-compiler installed with the toolchain... Any guesses what could be the reason.. The image is customized x11 image... I'm not sure I understand. It looks like you are using Host A to build a toolchain and install it into an image (core-image-skidata) on Target A. Are you then expecting to use Target A as Host B to compile for Target B? Is it possible that the skidata image recipe does not contain the cross-compiler recipes? -- 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
[yocto] How to get mkfs.ext4 in rootfs package
Hi, I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image, in particular the '.ext3' rootfs image, and am obviously missing something fundamental. I'm using a custom image based on (copy/pasted from) 'kvm_image_minimal', and have added 'e2fsprogs' to the IMAGE_INSTALL string in the image descriptor file. I see that the library is compiling and the binary is in tmp/sysroots: ben@ubuntu-scw:/opt/scw-appscard-build$ ls tmp/sysroots/x86_64-linux/sbin/mkfs.* tmp/sysroots/x86_64-linux/sbin/mkfs.ext2 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4 tmp/sysroots/x86_64-linux/sbin/mkfs.minix tmp/sysroots/x86_64-linux/sbin/mkfs.ext3 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4dev but it's not making it to the rootfs images. I've tried to read the documentation but still am not quite sure about what defines the contents of the rootfs images. thanks, Ben ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No crosscompiler in Toolchain
First I am sorry about the Gentlemen Next time it would be Ladies Gentlemen... ;-) Let me explain the situation better ... *core-image-skidata* (arm) is customized image which I build and I want to build a toolchain for this image on my x86_64 with should consist of cross compiler (which I assume a toolchain should contain). The build for the toolchain went successfull but when I installed the toolchain on my system, I didnot find the crosscompiler installed... Hope you understood my problem.. Greets, Satya On Tue, Jun 11, 2013 at 7:48 PM, Jeff Osier-Mixon je...@jefro.net wrote: On Tue, Jun 11, 2013 at 5:59 AM, DAMARLA Satya Swaroop swaroop.dama...@gmail.com wrote: Gentlemen! We have a problem here... Not all here are gentlemen :) I compiled the toolchain using the command bitbake core-image-skidata -c populate_sdk and installed the toolchain but I have to tell you that I dont see any cross-compiler installed with the toolchain... Any guesses what could be the reason.. The image is customized x11 image... I'm not sure I understand. It looks like you are using Host A to build a toolchain and install it into an image (core-image-skidata) on Target A. Are you then expecting to use Target A as Host B to compile for Target B? Is it possible that the skidata image recipe does not contain the cross-compiler recipes? -- 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] No crosscompiler in Toolchain
Hi Satya, What is your cross compiler that you said it's not installed? For example, on my development host e.g. x86, after I install the toolchain, there's an environment-setup-*** file, inside it specifies what is your cross compiler, e.g. arm-poky-linux-gnueabi-gcc for my case, after I source the environment file, and do which arm-poky-linux-gnueabi-gcc, I can see it's under path_to_toolchain/sysroots/i686_pokysdk_linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc... so you're seeing things differently? Jessica From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of DAMARLA Satya Swaroop Sent: Tuesday, June 11, 2013 11:55 AM To: Jeff Osier-Mixon; yocto@yoctoproject.org Subject: Re: [yocto] No crosscompiler in Toolchain First I am sorry about the Gentlemen Next time it would be Ladies Gentlemen... ;-) Let me explain the situation better ... core-image-skidata (arm) is customized image which I build and I want to build a toolchain for this image on my x86_64 with should consist of cross compiler (which I assume a toolchain should contain). The build for the toolchain went successfull but when I installed the toolchain on my system, I didnot find the crosscompiler installed... Hope you understood my problem.. Greets, Satya On Tue, Jun 11, 2013 at 7:48 PM, Jeff Osier-Mixon je...@jefro.netmailto:je...@jefro.net wrote: On Tue, Jun 11, 2013 at 5:59 AM, DAMARLA Satya Swaroop swaroop.dama...@gmail.commailto:swaroop.dama...@gmail.com wrote: Gentlemen! We have a problem here... Not all here are gentlemen :) I compiled the toolchain using the command bitbake core-image-skidata -c populate_sdk and installed the toolchain but I have to tell you that I dont see any cross-compiler installed with the toolchain... Any guesses what could be the reason.. The image is customized x11 image... I'm not sure I understand. It looks like you are using Host A to build a toolchain and install it into an image (core-image-skidata) on Target A. Are you then expecting to use Target A as Host B to compile for Target B? Is it possible that the skidata image recipe does not contain the cross-compiler recipes? -- 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
[yocto] SOLVED: How to get mkfs.ext4 in rootfs package
Sorry for the spam. Still learning how this works… Turns out I needed 'e2fsprogs-mke2fs' regards, Ben On Jun 11, 2013, at 10:51 AM, Ben Warren ben.war...@spidercloud.com wrote: Hi, I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image, in particular the '.ext3' rootfs image, and am obviously missing something fundamental. I'm using a custom image based on (copy/pasted from) 'kvm_image_minimal', and have added 'e2fsprogs' to the IMAGE_INSTALL string in the image descriptor file. I see that the library is compiling and the binary is in tmp/sysroots: ben@ubuntu-scw:/opt/scw-appscard-build$ ls tmp/sysroots/x86_64-linux/sbin/mkfs.* tmp/sysroots/x86_64-linux/sbin/mkfs.ext2 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4 tmp/sysroots/x86_64-linux/sbin/mkfs.minix tmp/sysroots/x86_64-linux/sbin/mkfs.ext3 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4dev but it's not making it to the rootfs images. I've tried to read the documentation but still am not quite sure about what defines the contents of the rootfs images. thanks, Ben ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to deal with non-standard license.
On Tue, Jun 11, 2013 at 5:28 AM, Diego diego...@zoho.com wrote:
Hi everybody,
I have written a recipe which I'd like to contribute for glmark2:
https://launchpad.net/glmark2
The last thing that puzzles me before submitting it is that it's partly GPL3+,
and partly under this license:
https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI
which is not in this list:
https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group#Licenses
Is there any way to deal with that license? What should I put in the LICENSE
field in my recipe?
So, you will need to add a custom license or submit a patch OE-Core to
add that license. Where are you contributing this to?
If it's to a layer, you'll want to add the license to a custom license
path. You'll want that file to be unique and descriptive. Please make
sure the license filename has a version in the file name. eg SGI-1.
Within the layer you'll make a directory (in this example I use
custom-licenses), add the license text to a file named SGI-1, then add
this to your layer.conf:
LICENSE_PATH += ${LAYERDIR}/custom-licenses
SPDXLICENSEMAP[SGIv1] = SGI-1
That should get you what you want.
-b
Bests,
Diego
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to deal with non-standard license.
Hi Diego, On Tuesday 11 June 2013 14:28:09 Diego wrote: I have written a recipe which I'd like to contribute for glmark2: https://launchpad.net/glmark2 The last thing that puzzles me before submitting it is that it's partly GPL3+, and partly under this license: https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI which is not in this list: https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group#Lic enses Is there any way to deal with that license? What should I put in the LICENSE field in my recipe? Beth has covered the part about adding the license text, the only remaining piece is how you should set LICENSE within your recipe; assuming you would call this SGI license SGI-1 based on what you said above you would set LICENSE as follows: LICENSE = GPLv3+ SGI-1 ( means different licences apply to different parts of the software). Note also that the LIC_FILES_CHKSUM variable should be set to point to both COPYING and COPYING.SGI. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] 1.4.1 rc1 available for testing
All, we've begun a spin of 1.4.1. This is the first release candidate. Unfortunately, a minor issue has occurred with the eclipse-plugin, so that will have to be rebuilt once the build run ends (as we may have to bring the buildbot slave down to fix it) The artifacts should be available in a few hours. Please begin testing as they are available. Location: http://autobuilder.yoctoproject.org/pub/nightly/20130611-2 meta-fsl-armd31a4e85673874dbc6b42bb5d1e8496810c574cc meta-fsl-ppc51252492cdda18eb3838b1c3108217a59243ba2a meta-intel 048def7bae8e3e1a11c91f5071f99bdcf8e6dd16 meta-minnow 0d428f867ffdf83dd35803c7318180751ddb096f meta-qt34c27cce6688aa39852f3cba5e7b80ec279019605 poky73f103bf9b2cdf985464dc53bf4f1cfd71d4531f I'll have the eclipse-plugin hash when we build it out. -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Need clarification on some terms
I'm trying a second time to see if I can learn this system. Section 3.4 contains a short glossary which explains some things and seems to obscure others. So perhaps someone can clear up a few simple things. Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. Is that different from the toolchain that bitbake builds in the beginning, and then uses to build the image? If so, what is it? Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? It also says that each one is a native package. In my experience, a native toolchain has always meant a toolchain that produces code for the same machine that the toolchain runs on, while a cross toolchain produces code for a different machine. That's obviously not what native means in this context, so what does it mean? The documentation makes frequent references to the SDK without ever defining it. I know what it means generically, but what is it in the Yocto context? And why does the SDK involve yet another set of three toolchains? (Oh, and why is one of them called canadian?) -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No crosscompiler in Toolchain
Hi Jessica, By the sentence No crosscompiler for my target installed in my toolchain, I mean I don't find the binaries for crosscompiling which are usually present in the directory as shown below *damarla@linuxbuildsrv:~/yocto/myToolchain/sysroots/x86_64-pokysdk-linux/usr/bin$ ls* *aclocalautoreconfflash2raw.terrier opkg-key pseudolog qemu-mipsel qemu-system-mipsel raw2flash.terrier runqemu-ifup* *aclocal-1.12 autoscan gnu-configize perl qemu-arm qemu-mips.realqemu-system-ppc runqemu runqemu-internal* *autoconf autoupdateifnames perl5.14.3 qemu-gaqemu-nbd qemu-system-x86_64 runqemu-addptable2image tunctl* *autoheader dtc libtoolize perl.real qemu-i386 qemu-ppc qemu-x86_64 runqemu-export-rootfs update-alternatives* *autom4te flash2raw.akita m4 pkg-config qemu-img qemu-system-arm raw2flash.akita runqemu-extract-sdk x86_64-pokysdk-linux-libtool* *automake flash2raw.borzoi oe-find-native-sysroot pseudo qemu-ioqemu-system-i386 raw2flash.borzoirunqemu-gen-tapdevs* *automake-1.12 flash2raw.spitz opkg-cl pseudodb qemu-mips qemu-system-mips raw2flash.spitz runqemu-ifdown* I don't have a directory and the list is empty *damarla@linuxbuildsrv:~/yocto/myToolchain/sysroots/x86_64-pokysdk-linux/usr/bin$ ls -la| egrep '^d'* *drwxr-xr-x 2 damarla damarla4096 Jun 11 14:27 .* *drwxr-xr-x 7 damarla damarla4096 Jun 11 14:15 ..* * * I want to know what could be the potential issue that my toolchain has no crosscompiler for my target Greets, Satya On Tue, Jun 11, 2013 at 9:05 PM, Zhang, Jessica jessica.zh...@intel.comwrote: Hi Satya, ** ** What is your cross compiler that you said it’s not installed? For example, on my development host e.g. x86, after I install the toolchain, there’s an environment-setup-*** file, inside it specifies what is your cross compiler, e.g. arm-poky-linux-gnueabi-gcc for my case, after I source the environment file, and do which arm-poky-linux-gnueabi-gcc, I can see it’s under path_to_toolchain/sysroots/i686_pokysdk_linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc… so you’re seeing things differently? ** ** Jessica ** ** *From:* yocto-boun...@yoctoproject.org [mailto: yocto-boun...@yoctoproject.org] *On Behalf Of *DAMARLA Satya Swaroop *Sent:* Tuesday, June 11, 2013 11:55 AM *To:* Jeff Osier-Mixon; yocto@yoctoproject.org *Subject:* Re: [yocto] No crosscompiler in Toolchain ** ** First I am sorry about the Gentlemen Next time it would be Ladies Gentlemen... ;-) ** ** Let me explain the situation better ... *core-image-skidata* (arm) is customized image which I build and I want to build a toolchain for this image on my x86_64 with should consist of cross compiler (which I assume a toolchain should contain). The build for the toolchain went successfull but when I installed the toolchain on my system, I didnot find the crosscompiler installed... ** ** Hope you understood my problem.. ** ** Greets, Satya ** ** On Tue, Jun 11, 2013 at 7:48 PM, Jeff Osier-Mixon je...@jefro.net wrote: On Tue, Jun 11, 2013 at 5:59 AM, DAMARLA Satya Swaroop swaroop.dama...@gmail.com wrote: Gentlemen! We have a problem here... Not all here are gentlemen :) I compiled the toolchain using the command bitbake core-image-skidata -c populate_sdk and installed the toolchain but I have to tell you that I dont see any cross-compiler installed with the toolchain... Any guesses what could be the reason.. The image is customized x11 image... I'm not sure I understand. It looks like you are using Host A to build a toolchain and install it into an image (core-image-skidata) on Target A. Are you then expecting to use Target A as Host B to compile for Target B? Is it possible that the skidata image recipe does not contain the cross-compiler recipes? -- 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
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, June 11, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Attendees: Andrei, Darren, Cristian, Foo Chien, ScottR, Richard, TomZ, KevinS, DaveST, Jessica, Ross, Belen, Paul, LaurentiuP, Corneliu, Nitin, BruceA, SongL Agenda: * Opens collection - 5 min (Song) * Yocto 1.4.1 status (Paul) . RC1 build is done last night. One failure, parallel build/install with systemd. Still investigating, it's uncommon race condition. . QA can get started on this week. Paul's call when to pass the build to QA. * Yocto 1.5 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status . Bug fixing: open bugs: 299, fixed 33. . WRS QA report is out: 4566 routerstation pro issue. 3936/3937: beagleboard problems. . M1 report is coming out. Expect a release readiness meeting sometime this week. In the morning US time. . Second week of M2, if you have not done the planning for M2, please do so. . Patches came out last Friday. Bitbake shell scripts changes, build own version of tar/git packages. Reached a point where we require minimum version for python, tar, git etc. python 2.7.3 now. We can use tarballs for these packages on systems not meeting the requirement. Will use same mechanism to upgrade from 2.7.3 to python 3. which can get rid of messy compatibility code. . AB Plan: build master with installed tarballs. Take sanity test patches and run MUT sometime today. * SWAT team rotation: Cristian - Andrei Dinu * Opens - 10 min * Team Sharing - 20 min - Cristian: adding file browser in build appliance. Associating it with different type of files. File manager added, there's some progress with screen shots in bugzilla. 2370. - MichaelH: new security update on the website, some general improvements are in place. Working on bugzilla extensions for doc change process . New sdk generated on master, running python 2.6.6. Release timeline added to the graph, will have those on the charts this week. (Great work, Michael!). - Darren: minnow update. RC3 released for the BSP. Firmware release is RC4. working through production process. Hardware solid, firmware working. Watch the websites for the final launch day. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SOLVED: How to get mkfs.ext4 in rootfs package
Can you try with IMAGE_INSTALL_append = e2fsprogs and run once again bitbake core-image-minimal or whatever you are referring for your final target //Gaurang Shastri On Wed, Jun 12, 2013 at 1:06 AM, Ben Warren ben.war...@spidercloud.comwrote: Sorry for the spam. Still learning how this works… Turns out I needed 'e2fsprogs-mke2fs' regards, Ben On Jun 11, 2013, at 10:51 AM, Ben Warren ben.war...@spidercloud.com wrote: Hi, I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image, in particular the '.ext3' rootfs image, and am obviously missing something fundamental. I'm using a custom image based on (copy/pasted from) 'kvm_image_minimal', and have added 'e2fsprogs' to the IMAGE_INSTALL string in the image descriptor file. I see that the library is compiling and the binary is in tmp/sysroots: ben@ubuntu-scw:/opt/scw-appscard-build$ ls tmp/sysroots/x86_64-linux/sbin/mkfs.* tmp/sysroots/x86_64-linux/sbin/mkfs.ext2 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4 tmp/sysroots/x86_64-linux/sbin/mkfs.minix tmp/sysroots/x86_64-linux/sbin/mkfs.ext3 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4dev but it's not making it to the rootfs images. I've tried to read the documentation but still am not quite sure about what defines the contents of the rootfs images. thanks, Ben ___ 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] Need clarification on some terms
Paul, Thanks for pointing out these areas where it is confusing. Maybe someone on the team can add some comments about the gcc-* recipe stuff. I don't have that understanding but if I am giving more explanation I can update that entry. I believe the term Cross-Development Toolchain is the same that BitBake builds in the beginning. If not, please someone from the team add some clarification for me and I will update. I will look for the term SDK throughout and remedy that. In the beginning of the development of the docs we used the term SDK liberally. Then we decided to weed it out. Seems I need to completely finish that task. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Paul D. DeRocco Sent: Tuesday, June 11, 2013 9:07 PM To: yocto@yoctoproject.org Subject: [yocto] Need clarification on some terms I'm trying a second time to see if I can learn this system. Section 3.4 contains a short glossary which explains some things and seems to obscure others. So perhaps someone can clear up a few simple things. Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. Is that different from the toolchain that bitbake builds in the beginning, and then uses to build the image? If so, what is it? Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? It also says that each one is a native package. In my experience, a native toolchain has always meant a toolchain that produces code for the same machine that the toolchain runs on, while a cross toolchain produces code for a different machine. That's obviously not what native means in this context, so what does it mean? The documentation makes frequent references to the SDK without ever defining it. I know what it means generically, but what is it in the Yocto context? And why does the SDK involve yet another set of three toolchains? (Oh, and why is one of them called canadian?) -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ 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: [linux-yocto] [PATCH 00/70] New standard/lsi branch - linux-yocto_3.4
On 13-06-10 09:45 PM, Paul Butler wrote: Creating a new branch in linux-yocto_3.4 for tracking LSI BSP changes. Branched from standard/base at commit fff57da7886cf5e99c07adf6649610cb1cd89330 Multiple patches for the same driver have been squashed into one where possible. Tried to improve several commit messages. Hey Paul, Any chance we can get a changelog that shows the delta from the first revision ? Bruce Anders Berg (3): drivers/misc: initial MTC driver Corrected definition of __arch_iounmap. Added support for PCI MSI for AXM55xx. Benjamin Herrenschmidt (1): powerpc/mpic: Create a revmap with enough entries for IPIs and timers David Mercado (1): ACP34xx: Add support for Performance Monitor (PMU) Jiang Lu (25): arch/arm: Updating Kconfig and Makefile for axxia arch/arm/tools/mach-types: adding axxia in the mach-types ppc/47x: add cputable entries for ACP 34xx powerpc/47x: add acpx1 board support ACP34xx:Fix a few mismatch section warnings powerpc/acp34xx: add clk_get/_rate support for acp board LSI:ACP34xx:standardize debug macro lsi/ncr: add support to read/write access to configuration ring resources lsi/nand: add acp3400 nand flash controller support lsi/ubootenv: add read access to the uboot env lsi/nand: Use EP501G1_NAND_1BIT_ECC0_STATUS to check HW ECC drivers/dma: Add Common LSI-DMA driver for ACP34xx and AXM55xx. PowerPC: ACP34xx:Add app350 i2c controller driver SPI: pl022: Update driver to support of-platform drivers PowerPC: ACP34xx: Add SPI at25 eeprom support powerpc/4xx: add support for the PCIe controller on ACP34xx drivers/net: Added support for acp network driver net/acp: add the netpoll support for acp device LSI:NIC: Using default value when ubootenv driver not present powerpc/47x: Kernel support for KEXEC powerpc/44x: kexec for SMP 47x GPIO:pl061: Update driver to support of-platform drivers PowerPC:ACP34xx: Add support for pl061 gpio driver ACP34xx: Add device tree for ACP344x v2 board Acp34xx: disable device when enabled set to 0 in dts John Jacques (6): arm/boot: Boot loader emulation code for AXM5516. arm/boot: change target name arm/boot: Updates for Emulation Bringup. arm/boot: Fix the problem with device tree loading in emulation arm/boot: add earlyprintk in the bootargs arm/boot: Use supersections for the early page table in the armv7 case Kevin Hao (5): usb/ehci-ci13612: add support for ci13612 host controller ppc/476: workaround for erratum #40 on dd2 core powerpc/44x: allow the kernel to be run from a non-zero physical address powerpc/acpx1: add early debug support for acpx1 board powerpc/acpx1: make udbg do IO access in AS1 Michael Bringmann (2): arm/dts: add configurations for I2C busses mach-axxia/i2c: fix i2c platform data structure Paul Butler (17): drivers/leds: Added support for RBS leds drivers/hwmon: add support for Analog Devices ADT75 drivers/i2c/busses: adding ai2c driver fs/vmfs: adding arm vmfs file system arch/arm/boot/dts: adding new dts files arch/arm/boot/fmboot: adding support for Fast Models arch/arm/mach-axxia: adding mach-axxia support arch/arm/mm: proc-v7-2level.S and 3level - checking coherent walk bits include/linux/i2c-axxia.h: added missing file to fix build bug arm/asm/io.h: let ioremap() fall back to platform specific one drivers/tty: Add support for lsi acp serial driver and console drivers/crypto/amcc/crypto4xx_core.c: added include for linux/module.h LSI acp34xx: Major rework of lsi_acp_net.c Ethernet driver drivers/crypto/amcc: removed section mismatch warning powerpc: fix section mismatch warnings arm: adding defconfig files for LSI arm family powerpc: adding defconfig file for LSI acp344x (elpaso) board. SangeethaRao (4): arm/dts: updated for PCIe node name arm: PEI ports name change supported in AXM55xx from PEI2 to PEI1. arm: PCIe driver DTS changes powerpc: PPC476 LSI PCIe driver Suzuki Poulose (1): powerpc/47x: Enable CRASH_DUMP Wang Hui (2): drivers/i2c/ai2c: remove default y from Kconfig arm: fmboot: make the fmboot image Wei Yang (2): powerpc/44x: Fix/Initialize PID to kernel PID before the TLB search powerpc/prom: remove the illegal reversed memory region yhe (1): kexec/44x: avoid cpu spin code flushed by new kernel arch/arm/Kconfig | 23 + arch/arm/Makefile |3 +- arch/arm/boot/Makefile |3 + arch/arm/boot/compressed/head.S| 53 + arch/arm/boot/dts/axm-sim.dts | 403 +++ arch/arm/boot/dts/axm-ve-tc1.dts | 363 ++ arch/arm/boot/dts/axm-ve-tc2.dts | 174 + arch/arm/boot/dts/axm55xx.dts | 297 ++ arch/arm/boot/dts/axm55xxsim.dts | 407 +++
