Re: [yocto] Core-Image-sato GUI

On 8 February 2017 at 10:43, Joseph Ngigi wrote: > My only concern is I'd like to include a login prompt once the GUI starts, > for security purposes. Which files should I use to do that? > meta-oe has some graphical login managers, such as lxdm or gdm. Ross --

Re: [yocto] genericx86 vs qemux86

On 4 February 2017 at 03:59, Takashi Matsuzawa wrote: > So, if virtualization platform provides what intel-core* builds expects, > then I will see a better performance with them, rather thatn qemu* builds. > Or qemu* builds provide particular features that suites well with

Re: [yocto] More new messages

On 25 January 2017 at 08:53, Gary Thomas wrote: > WARNING: libsndfile1-1.0.27-r0 do_package: Manifest > /build/p0382_2016-01-13/tmp/sstate-control/manifest-allarch-alsa-lib.populate_sysroot > not found? > FWIW I see these too, for intel-corei7-64. Note how its looking for

Re: [yocto] Section 5.10.6, current YP reference manual, "default working directory"

On 22 February 2017 at 11:58, Robert P. J. Day wrote: > so, *technically*, that claim in the ref manual is not wholly true; > there are still a small number of tasks that use that default > directory. is that a distinction worth making in the reference manual? > The point

Re: [yocto] Problem: Installation

On 20 February 2017 at 16:30, SatyaNarayana Sampangi wrote: > 14 SRC_URI = "file://hellosatya-1.0.tgz" > 15 > 16 S = "${WORKDIR}" > What files are in the tgz, and where do they expand to? The error says no such file or directory, so presumably it didn't unpack

Re: [yocto] Problem: Installation

On 20 February 2017 at 18:09, SatyaNarayana Sampangi wrote: > Problem Solved, I did not mention the path properly in the S variable, > > I changed, S = "${WORKDIR}/${PN}-${PV}", which works fine. > > Thanks to Ross, for triggering. > That's the default value, so you can

Re: [yocto] Python3 partial rootfs installation

On 24 February 2017 at 09:21, Maciej Borzęcki wrote: > > Is there any way to make a full standard python3 install? > > Installing python3-modules should cover most of your needs. > python3-modules will pull in the *entire* standard library. Ross --

Re: [yocto] Trying to build yocto-morty on ubuntu-16, machine reboots in the middle of the build

On 23 February 2017 at 13:24, William McKinney wrote: > I’m trying to build the yocto-morty release on an ubuntu 16.04.2 LTS box > with 16GB of memory and plenty of disk space. More than once the machine > appears to just reboot in the middle of the build. Has anyone else >

Re: [yocto] [PATCH 0/2] poky/yocto-bsps: introduce 4.9 as the default kernel

On 24 February 2017 at 19:42, Bruce Ashfield wrote: > Is there a bug or other issue lurking that I should look into ? > The autobuilder sanity tests were failing for every MIPS machine. I can run a rebuild now to verify it still happens. Ross --

Re: [yocto] task is executed even when sstate-cache md5 matches

On 22 February 2017 at 16:50, Pepe Perez wrote: > This is important for me because I'm working in a project in which > do_fetch should not be executed, but always resolved with the sstate > do_fetch can't be resolved by sstate. If fetch needs to execute, it will download it

Re: [yocto] gtest 1.8.0

On 12 February 2017 at 18:10, Suvi S wrote: > When I do populate_sdk from my custom image, it is not including as part > of sysroots or sdk does not have gtest, gmock libraries > Is gtest in the normal image that you are building a SDK for? Ross --

Re: [yocto] Out-of-tree module errors installing its udev rule

On 13 February 2017 at 16:14, Colin Helliwell < colin.helliw...@ln-systems.com> wrote: > > Also udev rules go into ${nonarch_base_libdir}. > > Oh ok, hadn't encounter that var. What's the reasoning? (i.e. where would > that be pointing in comparison to ${base_libdir} > udev rules are

Re: [yocto] Trimming images

On 9 February 2017 at 13:53, Gary Thomas wrote: > This used to work - what am I doing wrong now? > usbutils depends on hwdb as it's mostly useless without it. Maybe this is the cause? Ross -- ___ yocto mailing list

Re: [yocto] Trimming images

On 9 February 2017 at 14:33, Gary Thomas wrote: > usbutils depends on hwdb as it's mostly useless without it. Maybe this is >> the cause? >> > > I'm sure it is (and it's a recent change, 2017-02-02, while I was on > holiday) > > Is there some way to disable this, certainly in

Re: [yocto] Trimming images

On 9 February 2017 at 14:39, Gary Thomas wrote: > I can see in the usbutils recipe > RDEPENDS_${PN} = "udev-hwdb" > > If I have this, shouldn't that override it? or maybe it's because > the actual package is eudev-hwdb and not udev-hwdb? > BAD_RECOMMENDATIONS = "

Re: [yocto] Trimming images

On 9 February 2017 at 14:48, Gary Thomas wrote: > > Is it possible to make this "image" specific? I have some ramdisk > based images as well as full fledged "disk" images and I really only > care about the size issues for the ramdisk ones. Is there a way to > say "for my

Re: [yocto] x86 testing

On 18 January 2017 at 07:02, Gary Thomas wrote: > It used to be that I could run qemu and it would pop up a separate > window that emulated a display+keyboard+mouse. That doesn't seem > to be the same now, or at least I don't see how to make it work. > Advice on this would be

Re: [yocto] sstate-cache and native recipes

On 18 January 2017 at 09:13, Gary Thomas wrote: > * glib-2.0-native depends on ${DISTRO_FEATURES} > To me this seems silly as "native" should be "native" and > not depend on any distribution settings. Here's the code > that's causing it (in do_install) > > if [

Re: [yocto] sstate-cache and native recipes

On 18 January 2017 at 09:51, Gary Thomas wrote: > How would one change the recipe to reflect that? Is there an > override that effectively says "not -native"? > do_install_class-target. Ross -- ___ yocto mailing list

Re: [yocto] [PATCH 0/7] introduce rockchip offical linux support to meta-rockchip

(CCing the layer maintainers as listed in the README to ensure this gets noticed) On 19 January 2017 at 10:09, Jacob Chen wrote: > This series of patches add below features, will add more supports in the > future(medias, more chips). > > 1. rockchip 4.4 kernel > >

Re: [yocto] [PATCH 1/1] kernel-fitimage: Let U-Boot select ramdisk load/entry address

Hi Rick, Patches for oe-core should go to the openembedded-c...@lists.openembedded.org mailing list, yocto@ is for user support and smaller layers that don't need their own list. Can you resend it? On 19 January 2017 at 01:52, Rick Altherr wrote: > Change-Id:

Re: [yocto] Debugging question

On 16 January 2017 at 04:29, Gary Thomas wrote: > * Any ideas how upgrading the X server now calls into openssl? >I've bisected this error down to the change in the X server >recipe to v1.19 from v1.18.4 > $ grep ssl * xserver-xorg.inc:XORG_CRYPTO ??= "openssl"

Re: [yocto] Building on MacOS X

On 14 January 2017 at 19:45, Roger Smith wrote: > Is Building Yocto project on a POSIX system, a desire for the Yocto > project? It would allow support on all bsd UNIX’s including macOS > Making OE itself work isn't rocket science - fix a few Linuxisms in bitbake, port

Re: [yocto] Illegal Instruction Generate for Intel Atom

On 16 January 2017 at 14:47, Chris Trobridge wrote: > Managed to get the actual compiler lines and the initial args are "-m32 > -march=i586" but there is "-march=native" appended to the end of the line. > > Looks like asterisk itself is adding -march=native, so you'll

Re: [yocto] [PATCH] kernel-fit: Change FIT (kernel+initrd) symlinks to fitImage-*

On 11 January 2017 at 20:55, Rick Altherr wrote: > KERNEL_IMAGETYPE only provides the first image type specified in > KERNEL_IMAGETYPES which can provide surprising results. Since this > class is solely for FIT images, just hardcode the names to fitImage-*. > Nathan sent

Re: [yocto] How to run a runqemu with intel-corei7-64?

On 19 August 2016 at 02:50, Richard Zhang wrote: > After built an ‘intel-corei7-64’ image with Toaster, I try to run a > runqemu, it can’t run. > > ERROR: unable to classify arg [intel-corei7-64]. > > Does intel-corei7-64 could be run with runqemu? > > Currently, not out

Re: [yocto] [meta-qt4][PATCH 1/2] qt4-embedded.inc: provide PACKAGECONFIG for tslib

On 19 August 2016 at 09:42, Maxin B. John wrote: > (A quick grep in meta-qt4 for PACKAGECONFIG_CONFARGS returned zero results) > FWIW it's a relatively new feature: when PACKAGECONFIG is evaluated it writes the enabled/disabled values to PACKAGECONFIG_CONFARGS, which

Re: [yocto] [OE-core] Yocto Project Status WW09’17

On 28 February 2017 at 02:09, akuster808 wrote: > o rpm v4/dnf to replace rpm v5/smart? > > IMHO, we should include dnf in 2.3 so folks can start playing with it and > remove smart in 2.4. Not possible: dnf requires rpm4. In the current work there is no attempt at

Re: [yocto] yocto web-kiosk project matchbox-keyboard

On 2 September 2016 at 10:37, pirmin.weis...@t-online.de < pirmin.weis...@t-online.de> wrote: > One function is not working on the target system: The automatic popup of > the virtual keyboard when I select a text entry field (e.g. by touching it). > > Display and Touch are working fine, internet

Re: [yocto] building python-gst without x11

On 8 September 2016 at 15:36, nick83ola wrote: > it gives me an error because gtk+ requires it and python-pygst is a > dependance of python-gst > Looking at the pygtk configure you might be able to change the pygtk recipe to not pull in the gtk+ and so on dependencies if

Re: [yocto] [Yocot] : undefined reference to `__init_array_start' error.

This is because your distro has enabled the security options, but native-frameworks has bad link lines that work without security flags more via luck than anything else. You'll need to fix the linking order used to build libbinder. Ross On 9 September 2016 at 08:15, BHARATH RAJ

Re: [yocto] 'bb' utility fails on attempt to import 'commands' module

On 8 September 2016 at 23:06, Siegel, Jeffrey (Nokia - US) < jeffrey.sie...@nokia.com> wrote: > ‘bb’ Python source contains shebang path ‘/usr/bin/env python3’ , which > means it expects to be run by a Python 3.x interpreter. But then it imports > python code from bitbake/lib, and bitbake/Yocto

Re: [yocto] Subjects for YP Developer Day at ELCE

On 12 September 2016 at 15:48, William Mills wrote: > 5) Can Yocto [cross-]build snaps or flatpaks? > Just because it's interesting, note that the standard freedesktop.org flatpak runtime is in fact bootstrapped through a custom OE distro. Ross --

Re: [yocto] Fetcher failure

On 14 September 2016 at 13:42, Anicic Damir (PSI) wrote: > wget https://www.exampe.com/ > --2016-09-14 14:42:39-- https://www.exampe.com/ > Resolving www.exampe.com... 69.172.201.153 > Connecting to www.exampe.com|69.172.201.153|:443... connected. > Unable to establish SSL

Re: [yocto] Fetcher failure

On 14 September 2016 at 15:48, Anicic Damir (PSI) wrote: > it turns out that something HAS changed in my system/libraries (but not > Python itself), > influencing python urllib2 to fail, although wget, chrome, firefox, ... > worked > > Fortunately we have another python

Re: [yocto] Creating a core image with openCV

On 10 September 2016 at 10:35, Szymon Guza wrote: > i want to prepare a yocto distribution with openCV and C++ for Xilinx > zedboard. Do you have any tips for me how to do it? I wanted to take a one > of the core-images with user interfece and add some packages i need. >

Re: [yocto] Striping cross-compiled paths

On 12 September 2016 at 19:22, Matthew Stanger wrote: > I'm using Yocto 1.7.1 I'd like built programs to have the build path > striped down. The goal is if I'm looking at some programs log after cross > compiling I want this: > > src/program.c:388 > > where I

Re: [yocto] Fetcher failure

On 14 September 2016 at 08:52, Anicic Damir (PSI) wrote: > Fetcher failure for URL: 'https://www.example.com/'. URL > https://www.example.com/ doesn't work. Please ensure your network is > configured correctly. > This is the "is networking correctly configured" test,

Re: [yocto] How to extract an archive in a git repostry and copy it to a defined position in the rootfs?

On 13 September 2016 at 08:08, wrote: > > ??? do_fetch_append () { > ???extract ${S}/example.tar.gz > ??? } > ??? do_install () { > ???copy ${S}/ ${D}/opt/ > ??? } It's a tarball so use "tar" to extract, and you'll need to mkdir ${D}/opt before copying.

Re: [yocto] No /lib64 directory in yocto

On 14 September 2016 at 22:44, Nadikuda, Lavanya < lavanya.nadik...@us.fujitsu.com> wrote: > Could you please let me know what the resolution is for /lib64 directory > not found in yocto. > > If you're bothered by this, you can change your base_libdir to be /lib64 instead of /lib. Ross --

Re: [yocto] No /lib64 directory in yocto

On 15 September 2016 at 15:51, Nadikuda, Lavanya < lavanya.nadik...@us.fujitsu.com> wrote: > What if I want both the directories. > > So Set libdir to one, install a symlink for the other. Ross -- ___ yocto mailing list yocto@yoctoproject.org

Re: [yocto] How to compile and install a recipe natively

On 16 September 2016 at 06:49, Martin Bachmann wrote: > In my recipe I've added RDEPENDS += "opencv " and yocto installs the > libraries in the target rootfs. But now i'd like the libraries compiled > natively and installed to x86_x64-linux rootfs. This would allow me to >

Re: [yocto] missing glxext.h header file in core-image-x11 // toolchain SDK

On 29 September 2016 at 15:46, Karim ATIKI wrote: > I have generated a core-image-x11 image for a Toradex Colibri T20 board. > I aim to compile and execute our application that normally runs under X11 > + OpenGL. > What sort of GPU does this board have, and what GL

Re: [yocto] [meta-selinux][PATCH] libpcre_%.bbappend: add missing symlink libpcre.so.1

On 5 October 2016 at 13:58, Ioan-Adrian Ratiu wrote: > (the reason why the lib is moved in the first place is to avoid a QA issue > because there's a risk for /usr to be on another partition) > I'm not a meta-selinux maintainer but this is where I ask is there actually a

Re: [yocto] QA Host Contamination in autotools/pkconfig based recipe

On 16 September 2016 at 13:40, Chris Trobridge wrote: > The install line in the makefile is "cp -af $(APP_LIBXX_FILES) > $(DESTDIR)$(libdir)/", so I am at a bit of a loss as this should preserve > ownership. > It does - the build happens as you (uid 1000) so the file

Re: [yocto] How to generate a debug version of a single application and deploy it into the image?

On 17 August 2016 at 07:49, wrote: > In my case I have a software which do logging. The amount of the logs > depends on type of the build (Release skips all debug messages). Let's > assume that my recipe for the software(myApp) is called myApp.bb. It is > downloaded from

Re: [yocto] What is the common way to extend an package without bbappend?

On 28 September 2016 at 14:40, wrote: > When populate_sysroot is called in myweb.bb finishes with the error: > > myweb-1.0-r0 do_populate_sysroot: The recipe myweb is trying to install > files into a shared area when those files already exist. Those files and > their

Re: [yocto] What is the common way to extend an package without bbappend?

On 28 September 2016 at 14:50, wrote: > do_install () { > install -d ${D}/usr/share/apache2/htdocs/ > cp -r ${S}/myweb/* ${D}/usr/share/apache2/htdocs/ > } > FILES_${PN} += "/usr/share/apache2/htdocs/*" Just put the files somewhere else, like

Re: [yocto] Postinsts question

On 8 November 2016 at 23:23, Vuille, Martin (Martin) wrote: > Is there a way to fail the build for any postinsts that can’t > > be performed during the build and have to be deferred? > > Sadly not that I'm aware of currently. If you're using a sufficiently recent release (and

Re: [yocto] Help with out of (python) tree python modules in SDK

On 4 November 2016 at 18:55, Brad Bishop wrote: > I am on Krogoth. I have an autotools inheriting recipe. The configure > script runs a python script (in repo), that imports an out-of-python-distro > module. > > I can’t seem to wrap my head around the correct way

Re: [yocto] Postinsts question

On 8 November 2016 at 23:23, Vuille, Martin (Martin) wrote: > We are running with our rootfs mounted read-only. > > Consequently, any postinsts that get deferred to first boot fail. > > > > Is there a way to fail the build for any postinsts that can’t > > be performed during

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

Hi Scott, On 3 November 2016 at 20:21, Scott Rifenbark wrote: > See http://www.yoctoproject.org/docs/2.2/ref-manual/ref- > manual.html#detailed-supported-distros and let me know if this is okay. > If so, I will make sure the same commit is on my yocto-docs/morty branch. >

Re: [yocto] FW: cmake version 3.0.0 or greater

On 8 November 2016 at 04:52, Dinh Nguyen (dinhn) wrote: > Our SDK has the Yocto Project 1.7 Dizzy version and it supports cmake > 2.8.12 version as show below: > ./meta/recipes-devtools/cmake/cmake_2.8.12.2.bb > ./meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb > > We need

Re: [yocto] FW: cmake version 3.0.0 or greater

On 8 November 2016 at 12:23, Dinh Nguyen (dinhn) wrote: > Here is the error message when trying to build sdk-dslink-c within Yocto > Dizzy version. > > | + echo /media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/ > work/core2-64-poky-linux/sdk-dslink-c/1.1-r0 > | +

Re: [yocto] FW: cmake version 3.0.0 or greater

On 8 November 2016 at 12:43, Dinh Nguyen (dinhn) wrote: > Right, and I am trying to upgrade to 3x version. Would you please tell me > which cmake patch or recipe that I can use to upgrade to 3.x version for > Dizzy? > What you said: > I found

Re: [yocto] Yocto "Long Term Support"

On 7 November 2016 at 09:09, Burton, Ross <ross.bur...@intel.com> wrote: > Currently the Yocto Project commits to supporting the previous two > releases with security fixes. If you want a longer life-cycle than that > then it is recommended to approach one of the many OSVs wh

Re: [yocto] Yocto "Long Term Support"

On 6 November 2016 at 15:33, Vuille, Martin (Martin) wrote: > Has there ever been any discussion of making select releases > > “Long Term Support” releases, i.e., committing to support them > > for a number of years? > > > > Presumably that would entail having the resources to

Re: [yocto] libtomcrypt libtomfastmath recipe

Please considering posting these recipe into meta-oe or similar, tomcrypt etc comes up every few months. And posting a recipe to the list implies you want review, right? :) On 19 October 2016 at 10:12, Markus Volk wrote: > DESCRIPTION = "tomcrypt" > HOMEPAGE = "

Re: [yocto] Install mozroot-certdata package on a read only root file system

On 20 October 2016 at 07:59, Jussi Kukkonen wrote: > You'll have to extend the recipe to run mono inside a qemu, there are >> plenty of other recipes that demonstrate how to do this (fontcache and >> gio-module-cache classes come to mind, although they also use

Re: [yocto] Yocto recipe license

On 14 October 2016 at 06:23, Contrib Open Source < contrib.open.sou...@gmail.com> wrote: > Here "metadata" stands for "oe-core recipe", right ? > "metadata" includes all the recipes and classes in oe-core. > What if we extend (*.bbappend) a GPLv2 recipe: is it "contaminated" or not > ? >

Re: [yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()

On 20 October 2016 at 19:41, Dinh Nguyen (dinhn) wrote: > I am trying to build the luajit_2.0.3.bb recipe on our Yocto-1.7 base. > It failed to path the ppc-fixplt.patch. Hers is my build configuration. > Looking back in history it's possible that both your BSP and meta-oe are

Re: [yocto] confusion about DEPENDS vs RDEPENDS vs PROVIDES

On 20 October 2016 at 13:06, 윤영석 wrote: > Is there anyone who explain to me..? > > The documentation covers these: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PROVIDES http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-DEPENDS

Re: [yocto] Install mozroot-certdata package on a read only root file system

On 18 October 2016 at 23:26, Nick Wareing wrote: > However I'm running into an issue with a recipe in the meta-mono layer: > mozroot-certdata. I see the culprit is the pkg_postint script ( > http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/ >

Re: [yocto] populate_sdk_ext: Unable to locate package nativesdk-buildtools-perl-dummy

On 24 November 2016 at 07:50, Michel D'HOOGE wrote: > During the install, the error was: > ERROR: e2fsprogs-native-1.43-r1 do_populate_sysroot_setscene: > Error executing a python function in exec_python_func() autogenerated: > [...] > File:

Re: [yocto] Use recipes but not whole layer

On 23 November 2016 at 10:00, Oliver wrote: > When a layer is included in the build (conf/bblayers.conf), all the > bbappends and distro configurations, apply to the current build. Is there > something additional which the build is affected after a layer included? > As per the

Re: [yocto] Use recipes but not whole layer

On 24 November 2016 at 10:43, Oliver wrote: > In order to success in generate recipeA, I need to extend the boost to > expand some configuration parameters(log). > On the other side someone would like to use recipeB. He/She will > unwillingly inherit the boost modifications. >

Re: [yocto] What source is included in sstate hash, how to change?

On 28 November 2016 at 15:02, Vuille, Martin (Martin) wrote: > Or am I completely off-track? > > It will track the md5 of files mentioned in SRC_URI, but if a file is generated dynamically then bitbake may not be aware of it. Can you share a minimal example? Ross --

Re: [yocto] ERROR: glibc-locale-2.24-r0 do_package: QA Issue: glibc-locale: Files/directories were installed but not shipped in any package

On 24 November 2016 at 08:36, Andrew Stuart < andrew.stu...@supercoders.com.au> wrote: > I am doing bit "bitbake xen-guest-image-minimal” and getting the errors > seen below with locale. > Do you have anything non-standard in your local.conf, specifically controlling locales? Ross --

Re: [yocto] uninative vs. BB_NO_NETWORK

On 18 November 2016 at 14:58, Vuille, Martin (Martin) wrote: > Currently using Yocto 1.8, planning upgrade to 2.2 > > Per the Reference Manual, "The uninative class is now enabled by default > in Poky. [...] > With this class enabled, a tarball containing a pre-built C library

Re: [yocto] raspberry pi gtkmm_3.0.bb

SRC_URI = " http://ftp.gnome.org/pub/GNOME/sources/gtkmm/${PV}/gtkmm-${PV}.0.tar.bz2; S = "${WORKDIR}/${BPN}-${PV}.0" Just rename the recipe to gtkmm_3.0.0.bb, use ${BPN}-${PV}.tar.bz2, and delete the S assignment. That likely won't fix your problem but can't hurt. Setting PR=r0 isn't needed as

Re: [yocto] uninative workflow

On 18 November 2016 at 21:30, Trevor Woerner wrote: > To be honest, I'm not entirely sure what the uninative stuff is > (explanations > or pointers to explanations appreciated!) but I'm trying to figure out how > to > work with it. It's a prebuild glibc designed to remove

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

On 1 November 2016 at 15:19, Vuille, Martin (Martin) wrote: > Is that correct/intentional, or a documentation oversight? > > Ubuntu 16.04 is mentioned elsewhere in the docs. > > That's a mistake, I consider the whitelist assignment in poky.conf to be canonical and that

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

On 1 November 2016 at 17:05, Bas Mevissen wrote: > What are the criteria to call a distro supported? > The short version is that it's a distro that doesn't change too much, is still supported, and we have builders on autobuilder.yoctoproject.org running that distro. The

Re: [yocto] how to copy a tar file to Root file system

On 2 November 2016 at 20:00, wrote: > Thank you so much for your help. My .bb file now looks like as attached. > Did your tar file have .a and .so?? I am getting errors because of them. > Can I force the do_package_qa to skip? > > You might find this document

Re: [yocto] [sstate-cache] using sstate-cache in parallel builds

On 3 November 2016 at 09:57, Mike Looijmans wrote: > Would it be safe to store the sstate-cache for a bunch of builds into a > single directory, with builds running in parallel contributing to that? > > Each build would be using a different set of layers, different

Re: [yocto] How to add libudev.h

On 3 November 2016 at 12:55, idealsim wrote: > Thanks for your answer. > It seems that i didn't have DEPENDS = "udev". > How i can add it ? > - to my local.conf > or > - to myImage.bb > Regards, > If you want to do compiling inside the image, the

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

On 1 November 2016 at 22:20, Daniel. wrote: > Just as a note, I've been using archlinux for about a year and have never > faced "distro related problems", except when the gcc6 comes out. Anyway I'm > using daisy in my work. I think that making old releases supported by X >

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

On 2 November 2016 at 14:21, Daniel. wrote: > I'm planning to move to ubuntu 16.04 as I have in home, since I'm > something like tired of reading the words "not supported" .. but I have a > lot of work to do before I can format my machine there... So, it will be > arch :)

Re: [yocto] [sstate-cache] using sstate-cache in parallel builds

On 2 November 2016 at 13:36, Chris Z. wrote: > Is it secure to use in parallel sstate-cache for building images for > different target machines ? > Short answer: yes. The hashes will be different so there's no risk of conflicting files for the target, so it's only

Re: [yocto] Yocto recipe license

On 13 October 2016 at 09:49, Contrib Open Source < contrib.open.sou...@gmail.com> wrote: > it seems that license.manifest file describes application/lib/etc. > source code license, > but what about Yocto recipe license itself ? > So what is the license of a Yocto recipe ? > How to know it ? > If

Re: [yocto] Two pythons

On 12 October 2016 at 18:58, Michael Callahan wrote: > I just moved my project from Fido to Krogoth and now I have two > pythons (2.7 and 3). This bumps the size of my image by approximately > 25%. What would be the most reasonable way to get back to just one >

Re: [yocto] Building a package for target and native

On 8 December 2016 at 13:03, wrote: > I’m creating a recipe for a 3rd party package. > > Part of its install is to create the target’s config file by running > *itself* - obviously this doesn’t work as the target cpu is different to > the host. > > I should be

Re: [yocto] Qt make: g++: Command not found issue with SDK generated for soloX

As per the documentation, the compiler isn't just "gcc" but has the full platform triple in: http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#makefile-based-projects One you've sourced the setup script these are set as $CC and so on, so your makefile should be using $CC instead of

Re: [yocto] Qt make: g++: Command not found issue with SDK generated for soloX

On 9 December 2016 at 13:04, Alankar Dhobale < alankar.dhob...@renuelectronics.com> wrote: > But I think “make” is somehow calling g++ instead of calling > arm-poky-linux-gnueabi-g++. I am not sure about the generated sdk is > correct? > > I'd check the generated makefiles, or your qmake files.

Re: [yocto] meta-zephyr layer

On 12 December 2016 at 22:52, Bystricky, Juro wrote: > you need poky to build QEMUs and toolchains > You should just need *OpenEmbedded* to build the qemus and toolchains. Why does zephyr.conf include poky.conf? I'd say that any variables that are useful - such as

Re: [yocto] How to get headers installed at target side of SDK?

On 16 December 2016 at 02:54, Daniel. wrote: > Then I tried to append packagegroup-sdk-target adding foo-dev to it > but still I can't get the headers at the SDK. I'm building the SDK by > building meta-toolchain and installing by executing the script > generated at

Re: [yocto] Ignoring Fetch errors for optional source.

On 7 December 2016 at 13:00, Beth 'pidge' Flanagan wrote: > I've an odd use case that I wonder if anyone has a work around/way of > doing it. > > I've a client who has contractors who can't have access to a certain > segment of the code base. So for example, a recipe will

Re: [yocto] [matchbox-wm][PATCH 0/3] matchbox-window-manager fixes

On 7 December 2016 at 13:22, Jussi Kukkonen wrote: > One actual bug fix (YOCTO #10635) and a few build cleanups. > Looks good to me, push away. Ross -- ___ yocto mailing list yocto@yoctoproject.org

Re: [yocto] Package depending on ATLAS, BLAS, libmetis, liblapack

On 7 December 2016 at 11:57, david bensoussan wrote: > Those are tuning libraries which cannot be cross compiled > . > One solution that really isn't too difficult is to replace the places where it runs tests with simple

Re: [yocto] sstate pruning

On 12 January 2017 at 13:38, Gary Thomas wrote: > Any constructive ideas for cleaning out a ver long standing > sstate cache? I have one build tree that is now approaching > a year old (I do builds there all the time, sometimes many > times per day). The sstate-cache is

Re: [yocto] Building on MacOS X

On 12 January 2017 at 15:14, Roger Smith wrote: > Is there any documentation for running the Yocto build system on Mac OS X > or macOS as Apple now calls it? I am working with the Intel Aero board. > Before I go down the rabbit hole of fixing issues like this one (and I

Re: [yocto] Building on MacOS X

On 12 January 2017 at 15:39, Tim Orling wrote: > You can also build using Docker containers: > https://github.com/crops/docker-win-mac-docs/wiki > Yes, this is the link I was failing to find, thanks Tim. This is basically the official way of using OE on

Re: [yocto] Building on MacOS X

On 12 January 2017 at 17:41, Roger Smith wrote: > As I mentioned, I tried to simply source the oe-init-build-env, and got an > error that the readlink command that yocto is using is incompatible with > the bsd version of readlink built into os x. > Yes, we assume GNU

Re: [yocto] Building on MacOS X

On 12 January 2017 at 17:55, Maciej Borzęcki wrote: > IIRC docker on mac relies on docker-machine, which in turn spins up a > virtualbox VM. > That's the old Docker (Docker Toolbox), the new Docker (Docker for Mac) uses the built-in hypervisor so basically works

Re: [yocto] [oe] [Openembedded-architecture] OpenEmbedded Developers Meeting in Portland before ELC

On 12 January 2017 at 14:18, Hudson, Sean wrote: > It's a great point. I have volunteered Mentor's teleconference, but the > onsite pickup is always a challenge. Once we've finalized the location, > I'll focus on making sure that we have a high quality pickup(s) in

Re: [yocto] CommonAPI *.so bindings

On 30 November 2016 at 15:32, Suchy, Pawel wrote: > Questions: > 1. How to solve best this? > > 2. Is it a good Yocto practice to not allow to have symbolic links in > none-dev images? > > 3. Is there a way to have symbolic links to libs in */usr/lib *directory > in

Re: [yocto] Yocto doesn't recognize cross-compiled binaries inside SDK

On 2 December 2016 at 08:36, Kun Yi wrote: > Reading Yocto 2.1 reference it seems that I should be able to > cross-compile binaries for arm inside the SDK shell and run the > You can't run cross-compiled binaries inside the SDK unless you use qemu. Ross --

Re: [yocto] [meta-raspberrypi] X11 failure

On 5 December 2016 at 11:12, Gary Thomas wrote: > What do I need to do to get libGL v1 so X11 will work again? > That would be part of mesa-gl, but I'm surprised RPi X needs OpenGL (as that is pure software, not accelerated). Ross --

Re: [yocto] Yocto doesn't recognize cross-compiled binaries inside SDK

On 2 December 2016 at 18:36, Kun Yi wrote: > Thanks for the explanation Alex! Will give the alternative you suggested a > try. > As I understand I will need to instruct Yocto to fetch necessary > "native" toolchains and libs to compile the native variant recipe. > Doesn't that

Re: [yocto] morty populate_sdk_ext fails for recipes inherit bin_package

On 9 January 2017 at 15:51, wrote: > TOOLCHAIN_TARGET_TASK_append = "hals hals-doc" > _append doesn't insert whitespace, so you need to do it. Use TOOLCHAIN_TARGET_TASK_append = " hals hals-doc" in your image recipe instead of changing it globally. Ross --

<    4   5   6   7   8   9   10   11   12   13   >