[yocto] what's the best distro to pick for adding packages to yocto
Hullo I'm trying to add a package to yocto (an AMQP implementation). There are various packaged versions, so I started with the one that I'm most familiar (RH). However, it's pretty clear that yocto's not based on that as the initscripts are totally different and missing the framework (there isn't even a /etc/rc.d/init.d, although it looks like there used to be). What's the best starting point for picking a prepackaged version for a distro? debian? suse? thanks Tim ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v6] [399231] Fix race conditions when reading using LocalShellOutputReader(s)
When running a remote command with a Local connection from a Linux host a new
LocalHostShell is created.
At this time, a new LocalHostThread is launched, along side with two
LocalShellOutputReaders (output and error). The constructors for the
OutputReaders will receive a reference to the reader created by the
LocalHostThread.
When calling runCommandRemote, the newly created IHostShell is returned, making
it possible to create an adapter(IHostShellProcessAdapter) that will then be
used to read all available output from the readers.
When the LocalShellThread finishes running its run() method, it will perform a
cleanup causing both readers (output and error) to be closed.
If at this point, there are any readers, or handlers to the readers that are
still trying to read data (read using handlers readers), an error will be
thrown saying that the the pipe to the stream is closed ("Ensure open stream"/
"Pipe closed" errors).
After inspecting the internalReadLine, it seems that it expects a null
reference of the reader in order to consider that the reading is done.
In order to ensure that this will happen once the LocalShellThread closes the
stream(s), we will make sure that the reference to the readers is set to null,
and that LocalShellOutputReader(s) use the same reference of the reader as the
LocalShellThread. For this to happen, a reference of the thread must be kept in
the reader, in order to retrieve the correct reference of the underlying reader.
Since there can still be race conditions in this solution, all operations that
involve the reference to now the only reader, must be performed under mutual
exclusion using a shared lock between the LocalShellOutputReader and
LocalShellThread.
[update] : there is no need to protect internalReadLine with locks as long as
we do it when reading.
Signed-off-by: Ioana Grigoropol
---
.../dstore/shells/DStoreShellOutputReader.java | 12
.../services/local/shells/LocalHostShell.java |5 ++--
.../local/shells/LocalShellOutputReader.java | 29 +---
.../services/local/shells/LocalShellThread.java| 18
.../.settings/.api_filters | 22 +++
.../shells/TerminalServiceShellOutputReader.java | 14 ++
.../services/shells/IHostShellOutputReader.java| 13 -
7 files changed, 100 insertions(+), 13 deletions(-)
diff --git
a/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
b/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
index 84c9bb9..35dbea4 100644
---
a/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
+++
b/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
@@ -13,10 +13,13 @@
*
* Contributors:
* David McKnight (IBM) - [286671] return null when status is null
+ * Ioana Grigoropol (Intel) - [399231] Race conditions occur when trying to
read from local processes using LocalShellOutputReader
***/
package org.eclipse.rse.internal.services.dstore.shells;
+import java.io.BufferedReader;
+import java.util.concurrent.locks.Lock;
import org.eclipse.dstore.core.model.DataElement;
import org.eclipse.dstore.extra.DomainEvent;
import org.eclipse.dstore.extra.IDomainListener;
@@ -168,6 +171,15 @@ public class DStoreShellOutputReader extends
AbstractHostShellOutputReader imple
notifyResponse();
}
+ public BufferedReader getReader() {
+ // TODO Auto-generated method stub
+ return null;
+ }
+
+ public Lock getReaderLock() {
+ return null;
+ }
+
/*
private void handleInput()
{
diff --git
a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
index 250a904..213bf2e 100644
---
a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
+++
b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
@@ -13,6 +13,7 @@
*
* Contributors:
* Martin Oberhuber (Wind River) - [161838] local shell reports isActive()
wrong
+ * Ioana Grigoropol (Intel) - [399231] Race conditions occur when trying to
read from local processes using LocalShellOutputReader
***/
package org.eclipse.rse.internal.services.local.shells;
@@ -37,8 +38,8 @@ public class LocalHostShell extends Ab
Re: [yocto] what's the best distro to pick for adding packages to yocto
On 31 January 2013 11:16, Tim Coote wrote: > Hullo > I'm trying to add a package to yocto (an AMQP implementation). There are > various packaged versions, so I started with the one that I'm most familiar > (RH). However, it's pretty clear that yocto's not based on that as the > initscripts are totally different and missing the framework (there isn't even > a /etc/rc.d/init.d, although it looks like there used to be). > > What's the best starting point for picking a prepackaged version for a > distro? debian? suse? Historically Debian is fairly close, but these days that isn't really true. It's probably best to look at an existing init script to see *what* needs to be done, and then copy the style of existing scripts in Yocto for *how* to do it. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] menuconfig fails using SSTATE_MIRRORS and SOURCE_MIRROR_URL
To explain my environment: I am building images for the machine "imx6qsabrelite" in the "meta-fsl-arm" BSP layer using Poky 1.3 (danny). The kernel recipe is linux-imx which is fetched from Freescale's git repository. On host machine A, I build an image and copy all the sstate cache and download files into a different directory. I've setup this directory as a Samba share so it can be accessed via the local network. On host machine B, I have local.conf set to use the shared sstate cache and source download mirror (SSTATE_MIRRORS and SOURCE_MIRROR_URL ). They are both utilized without any problems when I build an image. However, when I "bitbake -c menuconfig virtual/kernel", I get the following error in the kconfig terminal: scripts/kconfig/mconf Kconfig Error opening terminal: xterm. make[1]: *** [menuconfig] Error 1 make: *** [menuconfig] Error 2 Command failed. Press any key to continue... The same "bitbake -c menuconfig virtual/kernel" on host machine A works. It also works on host machine B when I disable using the shared sstate cache and source download mirror. Is anyone aware of such issues? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] lmsensors-apps builds, but not in final image?
I'm hoping someone can quickly spot my mistake. I'm attempting to use this recipe: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-extended/lm_sensors/lmsensors-apps_3.3.2.bb with my meta-intel/crownbay build under denzil 7.0.1. I put the recipe in my layer, and added "lmsensors-apps" to my IMAGE_INSTALL_append in my layer's layer.conf. The software builds, and I can see the files in tmp/work/crownbay-poky-linux/lmsensors-apps-3.3.2-r2. But it doesn't make it into tmp/work/core-image-minimal-1.0-r0/rootfs or the .hddimage file. Help, please? John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] lmsensors-apps builds, but not in final image?
r10kindsofpeople writes: > I'm hoping someone can quickly spot my mistake. I'm attempting to use > this recipe: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-extended/lm_ > sensors/lmsensors-apps_3.3.2.bb > > with my meta-intel/crownbay build under denzil 7.0.1. > > I put the recipe in my layer, and added "lmsensors-apps" to my > IMAGE_INSTALL_append in my layer's layer.conf. > > The software builds, and I can see the files in > tmp/work/crownbay-poky-linux/lmsensors-apps-3.3.2-r2. > > But it doesn't make it into tmp/work/core-image-minimal-1.0-r0/rootfs > or the .hddimage file. > You have to use one of the packages specified in the recipe. Like 'libsensors' or 'lmsensors-sensors'. lmsensors-apps is empty. Marc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC v2 00/18][eclipse-poky] Storing yocto settings as target profiles
Hi Timo, I'm having a hard time figuring out the sequence of this patch series. You have 01/18-09/18, then 10/17 is obsolete, then you have things like 12/18 and 12/17 and some have XX/18 and some have XX/17. Can you do some cleanup and resend? Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Timo Mueller Sent: Wednesday, January 30, 2013 5:56 AM To: yocto@yoctoproject.org Cc: Timo Mueller Subject: [yocto] [RFC v2 00/18][eclipse-poky] Storing yocto settings as target profiles From: Timo Mueller Hi, thanks for the feedback, I did some changes to the patch series accordingly. First of all I've fixed the issues with the patches (duplicate method, missing fix for NewYoctoCProjectTemplate.java). I also changed the functionality of the "new" button according to Jessica's feedback. The logic is changed to a "Save as ..." approach. If the button is clicked the current values of the form are checked. If these are valid, the user can enter a name to store them as a new profile. The last patch moves the "Save as ..." button to the bottom of the preference page alongside with the "perform defaults" and the "apply" button. I created this patch as a proof of concept because I thought it would be a good idea to move it. I used the contributeButtons hook of the preference page to achieve this, but this only allows adding the "Save as ..." button left to the "perform defaults" button. So the order of the buttons is a bit confusing. I further checked several other preference pages of eclipse and it seems like none of them is using this hook to add new buttons. Instead all have a new button next to the comboboxes (e.g. Formatter for CDT and JDT). So I would plead against moving it to the bottom to have a more consistent and less confusing ui. >From the original cover letter: currently the yocto settings can be changed globally through eclipse's preferences or locally in the project properties. But the standard configuration stored in the global preferences sometimes changes, e.g. if a new version of the toolchain or the sysroot is released. If you change the global settings to the updated toolchain or sysroot your old working configuration is gone. If you want to reuse this configuration at a later point in time you have to (remember and) re-enter everthing. This patch set introduces the possiblity to store a configuration under a unique name, a so called target profile, and be able to select the default target profile that is used for new projects. Building upon this change the target profiles could later also be used in the project settings and be able to quickly build and debug your software for different hard- and software combinations. Best regards, Timo Atanas Gegov (4): plugins/sdk.ide: Extract labels to private members plugins/sdk.ide: Add method to enable and disable form plugins/sdk.ide: Set value of target array on input change plugins/sdk.ide: Create UI element for managing target profiles. Timo Mueller (14): plugins/sdk.ide: Removed unused message plugins/sdk.ide: Changed method signature to be more consistent plugins/sdk.ide: Modified preferences storage to support profiles. plugins/sdk.ide: Set profile on selection change plugins/sdk.ide: Add method to allow storing the current settings plugins/sdk.ide: Add UI method to create a new profile plugins/sdk.ide: Add UI method to delete a profile plugins/sdk.ide: Add UI method to rename a profile plugins/sdk.ide: Add method to change values of the preference page plugins/sdk.ide: Add method to rename a profile and its preference store plugins/sdk.ide: Add method to delete a profile plugins/sdk.ide: Use profiles for the preference page plugins/sdk.ide: Added profile UI to the preference page plugins/sdk.ide: Moved save as button to bottom of preference page .../src/org/yocto/sdk/ide/YoctoProfileElement.java | 104 ++ .../src/org/yocto/sdk/ide/YoctoProfileSetting.java | 211 + .../org/yocto/sdk/ide/YoctoSDKMessages.properties | 19 +- .../src/org/yocto/sdk/ide/YoctoSDKPlugin.java | 9 + .../org/yocto/sdk/ide/YoctoSDKProjectNature.java | 10 +- .../src/org/yocto/sdk/ide/YoctoSDKUtils.java | 62 -- .../src/org/yocto/sdk/ide/YoctoUISetting.java | 60 +- .../sdk/ide/preferences/PreferenceConstants.java | 5 + .../sdk/ide/preferences/PreferenceInitializer.java | 22 ++- .../ide/preferences/ProfileNameInputValidator.java | 63 ++ .../ide/preferences/YoctoSDKPreferencePage.java| 133 ++--- .../preferences/YoctoSDKProjectPropertyPage.java | 6 +- .../sdk/ide/wizard/NewYoctoCProjectTemplate.java | 7 +- 13 files changed, 646 insertions(+), 65 deletions(-) create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/YoctoProfileElement.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/Yoct
Re: [yocto] lmsensors-apps builds, but not in final image?
Thanks, Marc, that's got me moving forward. However, it may not be
strictly true that lmsensors-apps is empty or at least has no effect. So
far, I'm up to "lmsensors lmsensors-scripts lmsensors-apps" with the last
being needed {sufficient?} to get strict.pm, needed to do "sensors-detect".
Now I'm off to find module cpuid. Thanks again,
John
On Thu, Jan 31, 2013 at 2:20 PM, Marc Ferland wrote:
> r10kindsofpeople writes:
>
> > I'm hoping someone can quickly spot my mistake. I'm attempting to use
> > this recipe:
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-extended/lm_
> > sensors/lmsensors-apps_3.3.2.bb
> >
> > with my meta-intel/crownbay build under denzil 7.0.1.
> >
> > I put the recipe in my layer, and added "lmsensors-apps" to my
> > IMAGE_INSTALL_append in my layer's layer.conf.
> >
> > The software builds, and I can see the files in
> > tmp/work/crownbay-poky-linux/lmsensors-apps-3.3.2-r2.
> >
> > But it doesn't make it into tmp/work/core-image-minimal-1.0-r0/rootfs
> > or the .hddimage file.
> >
>
> You have to use one of the packages specified in the recipe. Like
> 'libsensors' or 'lmsensors-sensors'. lmsensors-apps is empty.
>
> Marc
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] lmsensors-apps builds, but not in final image?
r10kindsofpeople writes:
> Thanks, Marc, that's got me moving forward. However, it may not be
> strictly true that lmsensors-apps is empty or at least has no effect.
> So far, I'm up to "lmsensors lmsensors-scripts lmsensors-apps" with
> the last being needed {sufficient?} to get strict.pm, needed to do
> "sensors-detect".
>
You could also use the new lmsensors recipe which I updated from the old
one (the one you're using atm).
It's available here:
https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-support/lm_sensors/lmsensors_3.3.2.bb
Marc
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] 1.4_M3.rc2 ready for QA
The 1.4_M3.rc2 is available at: http://autobuilder.yoctoproject.org/pub/nightly/20130131-4/ Built from: poky: 3ae1a4ba972cfc17ff3f2fda632da8ecc3414885 eclipse-poky: 65f1b736b719ad5284281ccd88a33a5a92724da2 meta-qt3: 06e2fe600de962cdba53c23de1207501439a9c9f Please begin testing against this RC. Please note that tag and branch names for this milestone will be named as if it was M3. Branches have already been created since some commits needed to be cherry-picked for the build. I will tag, sign and release the milestone if/when given the all clear. -- Michael Halstead Yocto Project / Sys Admin smime.p7s Description: S/MIME Cryptographic Signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC v4 00/13][eclipse-poky] Integrate yocto documentation into eclipse
Hi Timo, Thanks for the patch and everything looks good. So question to you and Scott, what's the plan from the doc site that we need to coordinate to have this merged into master. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Timo Mueller Sent: Wednesday, January 30, 2013 6:01 AM To: yocto@yoctoproject.org Cc: Timo Mueller Subject: [yocto] [RFC v4 00/13][eclipse-poky] Integrate yocto documentation into eclipse From: Timo Mueller Hi, the last proposal integrated the yocto documentation into the existing doc plugin of the yocto ADT feature. As Jessica pointed out is does not make sense to bundle all parts of the yocto documentation with the ADT feature. As some parts of the documentation could also be helpful with the BitBake Commander feature, we agreed to encapsulate the yocto documentation into its own feature. 01..02: Fixing typos in build and site scripts 03..12: Adding the yocto documentation as a new feature 13: Temporary patch to use timo branch of docs project - DO NOT MERGE >From the last propsal: One major change in this patch series is that I extended the plugin build system to integrate the generation into the build process. Thus keeping the eclipse help and the official documentation in sync is now automated. the documentation of the yocto project can currently be viewed online or as a separate pdf. When using the eclipse ide to develop software on base of a yocto sysroot and toolchain it would be convenient to access the relevant parts of the documentation from within the ide. I have intergrated this documentation in the ide and it can now be accessed through the eclipse help center (Help -> Help Contents). Best regards Timo Timo Mueller (13): features/sdk.site: Fixed typo in category name Fixed typo in version variable name plugins/sdk.ide.doc.user: Add empty eclipse help plugins/sdk.ide.doc.user: Add about.html to prepare addition of yocto documentation features/org.yocto.doc: Add new feature containing yocto project documentation features/doc.headless.build: Added headless build for yocto.doc feature features/sdk.site: Added yocto.doc feature to update site scripts/build.sh: Added yocto.doc feature to build scripts/generate-doc.sh: Add script to handle eclipse help generation plugins/sdk.ide.doc.user: Add yocto documentation to the table of contents scripts/generate-doc.sh: Copy generated eclipse help into the user.doc plugin scripts/build.sh: Add documentation generation to the default build (TEMPORARY): Use origin/timo branch of yocto docs project .../org.yocto.bc.headless.build/customTargets.xml | 4 +- features/org.yocto.doc.headless.build/.project | 11 + .../org.yocto.doc.headless.build/build.properties | 262 + .../org.yocto.doc.headless.build/customTargets.xml | 212 + features/org.yocto.doc/.project| 17 ++ features/org.yocto.doc/build.properties| 3 + features/org.yocto.doc/feature.properties | 163 + features/org.yocto.doc/feature.xml | 35 +++ features/org.yocto.doc/license.html| 107 + .../org.yocto.sdk.headless.build/customTargets.xml | 4 +- features/org.yocto.sdk.site/category.xml | 10 +- features/org.yocto.sdk.site/site.xml | 10 +- plugins/org.yocto.doc.user/.classpath | 6 + plugins/org.yocto.doc.user/.project| 28 +++ plugins/org.yocto.doc.user/META-INF/MANIFEST.MF| 8 + .../OSGI-INF/l10n/bundle.properties| 3 + plugins/org.yocto.doc.user/about.html.in | 166 + plugins/org.yocto.doc.user/build.properties| 9 + plugins/org.yocto.doc.user/html/book.css | 1 + plugins/org.yocto.doc.user/plugin.xml | 35 +++ plugins/org.yocto.doc.user/toc.xml | 21 ++ scripts/build.sh | 18 +- scripts/generate-doc.sh| 91 +++ 23 files changed, 1212 insertions(+), 12 deletions(-) create mode 100644 features/org.yocto.doc.headless.build/.project create mode 100644 features/org.yocto.doc.headless.build/build.properties create mode 100644 features/org.yocto.doc.headless.build/customTargets.xml create mode 100644 features/org.yocto.doc/.project create mode 100644 features/org.yocto.doc/build.properties create mode 100644 features/org.yocto.doc/feature.properties create mode 100644 features/org.yocto.doc/feature.xml create mode 100644 features/org.yocto.doc/license.html create mode 100644 plugins/org.yocto.doc.user/.classpath create mode 100644 plugins/org.yocto.doc.user/.project create mode 100644 plugins/org.yocto.doc.user/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.doc.user/OSGI-INF/l10n/bundle.properties create mode 100644 plugins/org
Re: [yocto] Build external module against Yocto kernel
On 13-01-23 10:17 AM, Patrick Turley wrote: On Jan 23, 2013, at 7:48 AM, Bruce Ashfield wrote: On 13-01-23 12:34 AM, Patrick Turley wrote: On Jan 22, 2013, at 11:17 PM, Bruce Ashfield wrote: On 13-01-23 12:14 AM, Patrick Turley wrote: On Jan 22, 2013, at 10:43 PM, Bruce Ashfield wrote: On 13-01-22 9:26 PM, Patrick Turley wrote: Argh. I'll have to just run the commands myself and stop spamming the list with ideas :) It's just a matter of making lkc accept the defaults (i.e. you could also use allyesconfig, or allnoconfig) or even better not trigger that config check at all. You're very kind to have spent so much time on my problem already. I look forward to hearing back. I'm not sure if you are still interested in this topic, but I took a few minutes to look into this more today .. just to understand exactly what is happening. It is what was discussed on the thread already, when you invoke make scripts, there is an explicit dependency on auto.conf and that is what triggers the make oldconfig if the .config is newer than it is. Technically we are safe from this, assuming that the .config and captured auto.conf match, and that auto.conf is in the SDK. The other way that oldconfig is triggered in my experience (and testing today) is what we mentioned before. If your .config was generated with ARCH= (even ARCH=i386 the default) and you then execute 'make scripts', you'll trigger the oldconfig. So to avoid it, you should execute your make scripts with ARCH= on the command line. As for saving ARCH in the .config, it has been considered in the past, but never implemented. Other elements such as CROSS_COMPILE are now saved, but not ARCH= since it isn't directly used in the .config, it's a Makefile construct. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
