Re: [yocto] the current yocto FAQ is pretty much valueless
Hi Koen, On 27/06/12 22:58, Koen Kooi wrote: > I have no problem with poky-the-distro, I have a problem with > poky-the-buildsystem. I warned mallum about this confusion years ago, > but you know how stubborn he can be :) The Yocto naming confusion is entirely of Yocto making, nothing at all to do with days of yore. There was never any confusion about what Poky was before Yocto, just unhappiness of some that Poky was not just a distro. :) Poky-the-buildsystem was simply necessary. OE-the-buildsystem is a wonderful, rich, community project, but one in a constant and unpredictable flux. This is great for tinkering, but PITA when trying to develop and long term maintain a product (much bigger problem than what sparked this thread for sure). In the absence of a clearly defined process for the OE-the-buildsystem Poky had to bring sanity to the buildsystem itself and could not be just a distro. It introduced QA, releases, it focused on facilitating customization and manageable upgrade paths (and even provided some documentation!). Yocto is based on Poky; if it was not, it would need to create something just like Poky (the alternative would be asserting complete control over OE as a whole, not good I think). OE has benefited from the Poky effort over the last seven years, and it is a better ecosystem for it. At the same time, the OE systemd situation (a major system level change without adequate consideration of the upgrade path) suggests to me that the need for a sanitized OE-derivative remains. I shut up now. Really. Maybe. :-) (Perhaps I should add that I am not formally affiliated with the Yocto project in any way, my opinions are really my own, not someone else's or driven by a policy, I have a long history with Poky, so I am definitely biased in a particular way, I work with Poky on daily basis, and I tinker with Poky after hours.) Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On Wednesday 27 June 2012 11:01:09 Khem Raj wrote: > On Wed, Jun 27, 2012 at 9:49 AM, Paul Eggleton > wrote: > > It's something I've been discussing with Joe MacDonald already. I think > > it's an either-or situation - the recipes will not need to be in both > > layers. People who want recipes from either or both layers should be able > > to include the layers as needed. > > from my experience of deploying layers for others. Its quite a talk > for folks to get it and on top if you have overlapping recipes they > are not making life any easier. if we start using this kind of method, it > sure will fume into chaos. I think layers should have some wholeness to them > but at the same time they should be leveraging other layers to get > functionality they need. I agree completely - my intention is not to have any overlapping recipes. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Web Hob - two additional design ideas
Thanks, Dave. Cheers Belen On 27/06/2012 20:17, "Stewart, David C" wrote: >Gang there are a couple of ideas for Web Hob that we have talked about. >I don't remember seeing them in the various movies and documents. So I'm >going to throw them out there to get your feedback and hopefully get them >in the design. > >* Visualizing the image > >One of the things which frustrates me about GUI tools which build Linux >images is that you usually get a long list of packages to choose from, >but no real guidance. I think there are a couple of interesting ways to >visualize what is in the image. > >One would be to add more visual information about what makes up the >image, maybe like a pie chart or linear chart which shows the breakdown >between kernel, libraries, commands; perhaps with some drill down into >these categories to show which libraries, for example. This could be >extremely useful for tuning a poky-tiny image for its footprint size. > >I find I'm also struggling with figuring out how to add a whole >subsystem, rather than picking out the packages. This goes beyond the >scroll list of packages to add higher-level groups of packages. This >might be already present in how we present Tasks to select, so it might >already be there. > >* Finalizing your device's source offer > >One of the things the Project has been praised on is our support for >building license compliant embedded distributions. This turns out to be >one of the biggest challenges when people use Linux for their embedded >devices - often the Linux gets shipped out on the embedded device, but >the sources are not made available as specified in the GPL. Through our >tracking and validating of source licenses in recipes, the logic in the >build system to restrict licenses used, and the source manifests >generated in the build, I think we have a world class solution. This >really needs to be supported well in Web Hob. > >So the requirement here is that when a build is completed, you not only >get access to the image (and kernel) but maybe also a tar file of the >sources and scripts used to build the image, for purposes of GPL license >compliance. > > - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include libstdc++ in an image?
On Tuesday 26 June 2012 19:22:20 maniacbug wrote: > Hi. I am using denzil, trying to build a core-image-minimal with > libstdc++ installed. I want to cross-develop in c++, and run the > resulting apps on the image. For now, I am using qemu-arm as the > machine. I've been able to build and run core-image-minimal out of the > box. build the cross tools, and build apps using the cross tools (and > even add ssh to the image). What I cannot figure out how to do is get > libstdc++ (and libgcc1 and libc6) onto the target machine. > > The task-core-standalone-sdk-target looks super promising, > seeming to contain the exact pieces I need. I thought I could add this > to the IMAGE_INSTALL line in core-image-minimal.bb, and have the libs > show up. This didn't happen, so clearly I have some more to learn about > poky. > > Can anyone advise the appropriate way to inject libsdtc++ (and its > dependencies) into a poky image? Please note that I do not need to > compile/link apps on the target, only run them. Adding libstdc++ to IMAGE_INSTALL should work - in fact I just tried it and it worked here (although I used the alternative of adding it to CORE_IMAGE_EXTRA_INSTALL in local.conf, but the result should be the same). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Looking for help in building a custom device tree based kernel
Aloha, I was wondering if someone could advise on how I would go about creating a custom device tree based kernel? I've created my meta-foo repo which includes my defconfig etc. The bit I'm stuck on is how I would create the steps that I would manually do, within Yocto. As in which files need what entries, below are the manual steps I would do: git clone git://kernel.repo.git git checkout branch I would then build a kernel zImage with: make ARCH=arm platform_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j5 zImage I then need to build and append the dtb: git clone git://dts.repo.git git checkout branch I would then copy the motherboard.dtsi and processor.dts into kernel.repo/arch/arm/boot/dts Then do: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- rtsm_ve-cortex_a15x2.dtb This creates a dtb entry in kernel.repo/arch/arm/boot To append the blob to the kernel I do: cat ./zImage ./rtsm_ve-cortex_a15x2.dtb | dd of=zimageProcessor.bin bs=4 conv=sync With the root tarballs I use manually I then have to create an initramfs enabled rootfs by doing: sudo sh -c 'find . | cpio --quiet -H newc -o | gzip -3 -n > ../filesystem.cpio.gz' Now I'm not sure whether the last step is required if I use Yocto or not, but I need to build the kernel with the dtb appended. Ant ideas? Many thanks, Andy ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem building custom tool-chain/SDK
Dear all,
I'm trying to integrate a custom tool-chain/SDK in yocto, following steps found
in http://docs.openembedded.org/usermanual/html/commonuse_qte_sdk.html
So I've written three recipes
meta-toolchain-MINE.bb
task-MINE-toolchain-host.bb
task-MINE-toolchain-target.bb
When building with command "bitbake meta-toolchain-MINE" I'm having the
following error
ERROR: Nothing PROVIDES 'virtual/i686-MINE-linux-gcc'
How can i solve this error ? I was not able to track the dependency chain
Thanks in advance.
---[meta-toolchain-MINE.bb]
require ../meta/recipes-core/meta/meta-toolchain.bb
DESCRIPTION = "Meta package for building a MINE toolchain"
LICENSE = "MIT"
PR = "r7"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
TOOLCHAIN_TARGET_TASK = "task-MINE-toolchain-target"
TOOLCHAIN_HOST_TASK = "task-MINE-toolchain-host"
TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-MINE-${DISTRO_VERSION}"
PROVIDES = "meta-toolchain-MINE"
TOOLCHAIN_NEED_CONFIGSITE_CACHE += "zlib"
SDK_SUFFIX = "toolchain-MINE"
---
---[task-MINE-toolchain-host.bb]-
require ../meta/recipes-core/tasks/task-sdk-host-nativesdk.bb
DESCRIPTION = "Host packages for MINE SDK"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
ALLOW_EMPTY = "1"
RDEPENDS_${PN} += " "
[task-MINE-toolchain-target.bb]-
DESCRIPTION = "Target package for MINE SDK"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
ALLOW_EMPTY = "1"
PR = "r0"
RDEPENDS_${PN} += "\
dbus-dev \
dbus-glib-dev \
gstreamer-dev \
bluez4-dev \
gconf-dev \
avahi-dev \
telepathy-glib-dev \
eds-dbus-dev \
libecal-dev \
libebook-dev \
libxi-dev \
libsqlite3-dev \
gssdp \
gupnp \
gupnp-av \
gupnp-tools \
gypsy \
libart-lgpl \
libgalago \
libtelepathy \
pulseaudio \
qt4-x11-free-dev \
"
---
---___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a summary of the proper use of all yocto-related mailing lists?
I do track the bitbake and oe-core mailing lists, but the Yocto Project does not host them. I can address this on the community page: http://www.yoctoproject.org/community/mailing-lists - that page should point to them. On Tue, Jun 19, 2012 at 9:26 AM, Tyler Jones wrote: > OE and bitbake are tools provided by Yocto Project in Poky. The mailing > lists are not provided or maintained by the Yocto Project thus them not > being on the Yocto Project's site. You could make a wiki > page, https://wiki.yoctoproject.org/wiki/Mailing_Lists, with the mailing > lists and their description, but I feel they do not belong on the Yocto > Project's site. > > -Tyler Jones > > > On 19 June 2012 01:44, Robert P. J. Day wrote: >> >> OE > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto and Qt embedded
Hi, This is my first post on this mailing list and I'm quite new to Yocto. I successfully built a distro using the latest release of hob, including Qt embedded (without X11). I wrote a Qt application and cross compiled for ARM on my host machine but when I deploy it on the device (a Freescale iMX53) I get and error because the application looks for libraries like libQtGui but on the distro all Qt libraries are named like libQtGuiE (ending with E which I suppose it stands for Embedded). Is the problem due to a wrong distro configuration or a compile problem? (I'm using a default ARM toolchain from Ubuntu repos) Thanks Giovanni -- Dott. Ing. Giovanni Foiani Cell:+39-349-3577515 Phone:+39-0532-97-4106 mail:giovanni.foi...@unife.it CenTec - Corso Guercino, 47 - 44042 Cento (FE) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Qt embedded
Dear Giovanni, In message you wrote: > > This is my first post on this mailing list and I'm quite new to Yocto. > I successfully built a distro using the latest release of hob, including Qt > embedded (without X11). > I wrote a Qt application and cross compiled for ARM on my host machine but > when I deploy it on the device (a Freescale iMX53) I get and error because > the application looks for libraries like libQtGui but on the distro all Qt > libraries are named like libQtGuiE (ending with E which I suppose it stands > for Embedded). These names are OK for the Qt Embedded libraries, and they should match what your cross development tools are using. Which tool chain did you use for compiling and linking your application - the one from meta-toolchain-qte ? When I build meta-toolchain-qte, this also includes, for example, .../sysroots/armv6-vfp-linux-gnueabi/usr/lib/libQtGuiE.so.4.8.2 so cross tool chain and native systems work together without problems. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's hard to make a program foolproof because fools are so ingenious. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto and Qt embedded
Hi Giovanni, You need to build a matching toolchain. Either from command line do "bitbake meta-toolchain-qte or through hob, under Settings, please make sure check "Build Toolchain". Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Wolfgang Denk Sent: Thursday, June 28, 2012 11:12 AM To: Giovanni Foiani Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto and Qt embedded Dear Giovanni, In message you wrote: > > This is my first post on this mailing list and I'm quite new to Yocto. > I successfully built a distro using the latest release of hob, > including Qt embedded (without X11). > I wrote a Qt application and cross compiled for ARM on my host machine > but when I deploy it on the device (a Freescale iMX53) I get and error > because the application looks for libraries like libQtGui but on the > distro all Qt libraries are named like libQtGuiE (ending with E which > I suppose it stands for Embedded). These names are OK for the Qt Embedded libraries, and they should match what your cross development tools are using. Which tool chain did you use for compiling and linking your application - the one from meta-toolchain-qte ? When I build meta-toolchain-qte, this also includes, for example, .../sysroots/armv6-vfp-linux-gnueabi/usr/lib/libQtGuiE.so.4.8.2 so cross tool chain and native systems work together without problems. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's hard to make a program foolproof because fools are so ingenious. ___ 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] How to include libstdc++ in an image?
>> Can anyone advise the appropriate way to inject libsdtc++ (and its >> dependencies) into a poky image? Please note that I do not need to >> compile/link apps on the target, only run them. > Adding libstdc++ to IMAGE_INSTALL should work - in fact I just tried it and > it > worked here (although I used the alternative of adding it to > CORE_IMAGE_EXTRA_INSTALL in local.conf, but the result should be the same). Thanks! Turns out this was user error. libstdc++/libgcc were in fact included in the image, so it is correct that task-core-standalone-sdk-target did the job. I just had to remove the -dev packages to avoid balooning my image, so now I have a minimal image with ssh and libstdc++ < 10M. Happiness. Also handy to know that it works to just add package recipes directly to IMAGE_INSTALL. Still learning bitbake, so it's not clear what goes there versus IMAGE_FEATURES, etc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Beagleboard BSP on BeagleBone?
Apologies if this is the wrong list, should it be on meta-ti? Does anyone here know if the yocto 'beagleboard' BSP works on the BeagleBone board? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Beagleboard BSP on BeagleBone?
On 28/06/2012 20:27, maniacbug wrote: Apologies if this is the wrong list, should it be on meta-ti? Does anyone here know if the yocto 'beagleboard' BSP works on the BeagleBone board? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto You should use the Beaglebone BSP by adding the meta-ti layer and following the instructions in the meta-ti readme. Regards, Jack. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] meta-cedartrail: add gstreamer-vaapi support
From: Rahul Saxena
enable gstreamer with vaapi based hardware acceleration
Signed-off-by: Rahul Saxena
---
meta-cedartrail/conf/machine/cedartrail.conf |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta-cedartrail/conf/machine/cedartrail.conf
b/meta-cedartrail/conf/machine/cedartrail.conf
index dbd7d95..4c676f4 100644
--- a/meta-cedartrail/conf/machine/cedartrail.conf
+++ b/meta-cedartrail/conf/machine/cedartrail.conf
@@ -7,8 +7,12 @@
require conf/machine/include/tune-atom.inc
require conf/machine/include/ia32-base.inc
+VA_FEATURES ?= "gst-va-intel va-intel"
+
MACHINE_FEATURES += "pcbios efi"
+MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
+
XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
cdv-pvr-driver \
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1][meta-intel] Cover letter for enabling gstreamer-vaapi in meta-cedartrail
From: Rahul Saxena Cover letter for enabling gstreamer with vaapi based hardware acceleration Please pull into master branch. Signed-off-by: Rahul Saxena -- The following changes since commit 8f4eb72ee349858cf9b768c97aca70d82319f978: meta-emenlow: prefer 1.10.2 cairo (2012-06-14 23:48:34 -0500) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib rsaxena-master http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena-master Rahul Saxena (1): meta-cedartrail: add gstreamer-vaapi support meta-cedartrail/conf/machine/cedartrail.conf |4 1 files changed, 4 insertions(+), 0 deletions(-) -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-xilinx] util-linux: rename file to util-linux_2.21.2.bbappend
* Rename util-linux bbaapend file to match recipe version provided in
poky/meta/recipes-core/util-linux
Signed-off-by: Elvis Dowson
---
recipes-core/util-linux/util-linux_2.21.1.bbappend |3 ---
recipes-core/util-linux/util-linux_2.21.2.bbappend |3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
delete mode 100644 recipes-core/util-linux/util-linux_2.21.1.bbappend
create mode 100644 recipes-core/util-linux/util-linux_2.21.2.bbappend
diff --git a/recipes-core/util-linux/util-linux_2.21.1.bbappend
b/recipes-core/util-linux/util-linux_2.21.1.bbappend
deleted file mode 100644
index 5199eb2..000
--- a/recipes-core/util-linux/util-linux_2.21.1.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
-# Disable microblaze ncurses support
-EXTRA_OECONF_microblaze += " --without-ncurses "
diff --git a/recipes-core/util-linux/util-linux_2.21.2.bbappend
b/recipes-core/util-linux/util-linux_2.21.2.bbappend
new file mode 100644
index 000..5199eb2
--- /dev/null
+++ b/recipes-core/util-linux/util-linux_2.21.2.bbappend
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS := "${THISDIR}/${PN}"
+# Disable microblaze ncurses support
+EXTRA_OECONF_microblaze += " --without-ncurses "
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
