A couple of things:
1) If you're not already, use bitbake -e and not just bitbake -e
2) I'd also recommend not piping through grep - pipe through "less" instead
and search for the variable with / - this means you can see the history of how
the variable's value got set.
Cheers,
Paul
On Mon, 1
Hello Joshua!
Please also apply to the pre-sstate branch. There's a slight merge
conflict (previous line differs), but that's easy to resolve, so I am
not sending that as a separate patch.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an
Hi Mark,
Thanks a lot for your comments.
Is there plan to support non-MMU targets in Yocto?
Best Regards,
Zhenhua
> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: Friday, September 09, 2016 10:37 PM
> To: Zhenhua Luo ; 'yocto@yoctoproject.org'
>
>
Hi All,
I am trying to build one recipes on Yocto2.0 based environment.
However I am seeing following error.I wonder if this is a known problem.
It says error: '__uint128_t' does not name a type
/local/mnt/workspace/narasimha/AGL_NEW/poky/build/tmp-glibc/sysroots/usr/include/bits/mathcalls.h:24
OE-core commit 6d969bacc718e changed do_rootfs so that it creates
IMGDEPLOYDIR. That change broke the creation of additional swupd
images, because setting do_rootfs to empty caused the entire task to
be skipped, including the evaluation of the 'cleandirs' task
attribute.
It remains to be seen whet
On Mon, 2016-09-12 at 09:09 +0200, Patrick Ohly wrote:
> OE-core commit 6d969bacc718e changed do_rootfs so that it creates
> IMGDEPLOYDIR. That change broke the creation of additional swupd
> images, because setting do_rootfs to empty caused the entire task to
> be skipped, including the evaluation
Hi Ross,
Thanks for your reply,it's working for me ..:)
Regards
Bharath
On Fri, Sep 9, 2016 at 6:46 AM, Burton, Ross wrote:
> 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
Using `pidof Xvnc` isn't sufficient because on debian-based distros
the vncserver script will start Xtightvnc.
Instead switch back to using netstat for the VNC tcp socket to
detect a running vncserver.
[YOCTO #10257]
Signed-off-by: Joshua Lock
---
bin/checkvnc | 2 +-
1 file changed, 1 inserti
On 9/12/16 12:07 AM, Zhenhua Luo wrote:
> Hi Mark,
>
> Thanks a lot for your comments.
>
> Is there plan to support non-MMU targets in Yocto?
>
Not that I am aware of.
--Mark
> Best Regards,
>
> Zhenhua
>
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
On 09/09/2016 11:51 AM, Jeff Osier-Mixon wrote:
Hi all - we are in the planning stages for DevDay at ELCE right now,
particularly the advanced track. This track changes every session,
usually to cover the things we are working on hardest - for example,
in San Diego we covered CROPS, devtool, the
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
--
__
On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
> Following up as I've done more investigation and debugging this afternoon:
>
> I've been able to resolve my problem with the missing symbolic link to
> .so by explicitly including a runtime dependency
> (RDEPENDS_${PN}) to the -dev mo
Ronald,
If you don't make your driver GPL you can't access GPL symbols. This
*may* be the reason behind the "Unknown symbols"
Regards,
2016-09-12 13:02 GMT-03:00 Lennart Sorensen :
> On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
>> Following up as I've done more investigation and
On Mon, Sep 12, 2016 at 01:41:24PM -0300, Daniel. wrote:
> If you don't make your driver GPL you can't access GPL symbols. This
> *may* be the reason behind the "Unknown symbols"
> Regards,
Well at least for __stack_chk_fail the kernel has:
#ifdef CONFIG_CC_STACKPROTECTOR
/*
* Called when gcc's
I was able to resovle my problem (with a bit of help from Google and
Stack Overflow) by including a stub version of __stack_check_fail() in
my recepie.
It appears that the shared object libarary was not needed after all,
and was just a red herring in my invesgagation.
Thank you for your assistanc
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 currently get this:
/usr/local/jenkins/workspace/project-build-manual/Project/build-project/tmp/work/arm
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 currently get this:
>
> /usr/local/je
Thanks, I just found this post was addressed already ->
https://lists.yoctoproject.org/pipermail/poky/2015-August/010197.html
On Mon, Sep 12, 2016 at 1:16 PM, Burton, Ross wrote:
>
> On 12 September 2016 at 19:22, Matthew Stanger <
> matthew_stan...@trimble.com> wrote:
>
>> I'm using Yocto 1.7.1
On Mon, Sep 12, 2016 at 08:16:02PM +0100, Burton, Ross wrote:
> If those paths come from __FILE__ and so on, then currently no. It would
> be great if GCC could do this, but currently it can not.
__FILE__ contains whatever was passed to gcc, so if you ask it to do:
gcc file.c
then __FILE__ will
On Wed, Aug 17, 2016 at 6:58 AM, Khem Raj wrote:
> Fixes taskhash mismatch e.g.
>
> ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch
> 78b2e0830a66052318e5e7eba193 versus 4b9bbe5dba1b48cf5cb5ad365d991de9 for
> /a/builder/home/kraj/work/oe/openembedded-core/meta/recipes-
stamp files are not of much use and this patch fixes:
ERROR: kde-base-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch
3fad6675b6fcc6b048099609adf21967 versus f0665d2ea6d2db2359c456c60a33e52e for
/home/superandy/data/oe-core/sources/meta-misc/recipes-image/kde/kde-base-image.bb.do_image_rpi_sdi
oe-core's commit d54339d4b1a7e884de636f6325ca60409ebd95ff creates image in
IMGDEPLOYDIR and copies through sstate to DEPLOY_DIR_IMAGE. That causes
DEPLOY_DIR_IMAGE not valid when calling IMAGE_CMD. Therefore use
IMGDEPLOYDIR for sdcard creation too.
Signed-off-by: Andreas Müller
---
classes/sdca
Hello All,
I am getting an compilation error like below. Can you pls let me know how
to fix this one. Thanks in advance.
error: implicit declaration of function 'close'
[-Werror=implicit-function-declaration]
| close(fd);
Cheers,
Vijay
--
_
Hello All
We are including the meta-ivi layer in our custom distribution. There is a
package 'dlt-daemon' whose fetch URL got modified upstream in the recipe file
due to some corruption in the repositories. I want to modify this URL in the
corresponding bbappend file in my custom BSP layer. I t
What recipe? Ideally you want to fix the code and add the function
declaration.
Kind regards,
Rudolf J Streif
On Sep 12, 2016 6:26 PM, "Vijayakumar Badiger"
wrote:
> Hello All,
>
> I am getting an compilation error like below. Can you pls let me know how
> to fix this one. Thanks in advance.
>
The IMAGE_NAME variable already contains the date and time so it is
redundant to also include the date again with IMAGEDATESTAMP
when writing to image-version-info in the boot partition.
Signed-off-by: Jonathan Liu
---
classes/sdcard_image-rpi.bbclass | 8 ++--
1 file changed, 2 insertions(+
Hi Andreas,
On 13 September 2016 at 10:19, Andreas Müller
wrote:
> stamp files are not of much use and this patch fixes:
> ERROR: kde-base-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch
> 3fad6675b6fcc6b048099609adf21967 versus f0665d2ea6d2db2359c456c60a33e52e for
> /home/superandy/data/oe-
Hi Andreas/Khem,
On 13 September 2016 at 09:04, Andreas Müller
wrote:
> On Wed, Aug 17, 2016 at 6:58 AM, Khem Raj wrote:
>> Fixes taskhash mismatch e.g.
>>
>> ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch
>> 78b2e0830a66052318e5e7eba193 versus 4b9bbe5dba1b48cf5cb5ad
Smells like you didn't include a file.
man 2 close says:
#include
Frederick
From: yocto-boun...@yoctoproject.org on behalf
of Rudolf Streif
Sent: Monday, September 12, 2016 6:53 PM
To: Vijayakumar Badiger
Cc: Yocto Discussion Mailing List
Subject: Re: [yo
Dear all,
based on the material presented in GDP master, i successfully compiled it
and it is working. but when i try to extract sdk using this command
" bitbake genivi-dev-platform-sdk -c populate_sdk " i got the following
error:
"
ERROR: Taskhash mismatch 717dd6510c2db4bae5bb8bab51bd0c34 verses
On Tue, Sep 13, 2016 at 4:06 AM, Jonathan Liu wrote:
> The IMAGE_NAME variable already contains the date and time so it is
> redundant to also include the date again with IMAGEDATESTAMP
> when writing to image-version-info in the boot partition.
>
> Signed-off-by: Jonathan Liu
> ---
> classes/sd
31 matches
Mail list logo
