date:20170615

Re: [yocto] FriendlyArm Mini6410 ?

2017-06-15 Thread Riko Ho


Hi Everyone,

Is it possible that I only change the kernel config to support this CPU

S3C6410 ? or I'm gonna need something else ?

bitbake linux-yocto -c menuconfig ?

It's ARM1176JZF-S based CPU

Thanks


On 15/06/17 14:05, Belisko Marek wrote:

Hi Riko,

On Thu, Jun 15, 2017 at 7:53 AM, Riko Ho  wrote:

Hello Everyone,

I want to use Yocto for my FriendlyArm Mini6410,
Where should I begin to start ?

Please read following thread:
https://lists.yoctoproject.org/pipermail/yocto/2014-June/020009.html

Thanks
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

BR,

marek



--
*

/***/
Sent by Ubuntu LTS 16.04,
谢谢,
Regards,
Riko Ho
/***/

*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] documentation: updates to static library support in SDK

2017-06-15 Thread Maxin B. John

Hi Andre,

On Wed, Jun 14, 2017 at 10:57:41AM -0700, Andre McCurdy wrote:
> On Wed, Jun 14, 2017 at 5:12 AM, Maxin B. John  wrote:
> > For development purposes, static libraries need to be
> > present only in the SDK. We do not need those static
> > libraries in the image for most scenarios. So, replace
> > IMAGE_INSTALL with TOOLCHAIN_TARGET_TASK in the documentation.
> >
> > Suggested-by: Anders Darander 
> > Signed-off-by: Maxin B. John 
> > ---
> >  documentation/adt-manual/adt-prepare.xml | 8 
> >  documentation/sdk-manual/sdk-appendix-obtain.xml | 8 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/documentation/adt-manual/adt-prepare.xml 
> > b/documentation/adt-manual/adt-prepare.xml
> > index 65df1d0..7587305 100644
> > --- a/documentation/adt-manual/adt-prepare.xml
> > +++ b/documentation/adt-manual/adt-prepare.xml
> > @@ -684,16 +684,16 @@
> >  
> >  By default, this toolchain does not build static binaries.
> >  If you want to use the toolchain to build these types of 
> > libraries,
> > -you need to be sure your image has the appropriate static
> > +you need to be sure your SDK has the appropriate static
> >  development libraries.
> >  Use the
> > - > url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'>IMAGE_INSTALL
> > + > url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'>TOOLCHAIN_TARGET_TASK
> >  variable inside your local.conf file to
> > -install the appropriate library packages.
> > +include the appropriate library packages in SDK.
> >  Following is an example using glibc static
> >  development libraries:
> >  
> > - IMAGE_INSTALL_append = " glibc-staticdev"
> > + TOOLCHAIN_TARGET_TASK_append = " glibc-staticdev"
> 
> That should perhaps be "libc-staticdev" so the same instructions work
> for musl (although it looks like currently musl doesn't rprovide
> libc-staticdev so that would need to be fixed too).

I agree with your suggestion that examples in documentation shouldn't be
specific for a particular libc implementation.

Filed a bug for musl libc-staticdev support:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11669

> >  
> >  
> >  
> > diff --git a/documentation/sdk-manual/sdk-appendix-obtain.xml 
> > b/documentation/sdk-manual/sdk-appendix-obtain.xml
> > index 3156f77..86e0eff 100644
> > --- a/documentation/sdk-manual/sdk-appendix-obtain.xml
> > +++ b/documentation/sdk-manual/sdk-appendix-obtain.xml
> > @@ -96,16 +96,16 @@
> >  
> >  By default, this toolchain does not build static 
> > binaries.
> >  If you want to use the toolchain to build these types 
> > of
> > -libraries, you need to be sure your image has the
> > +libraries, you need to be sure your SDK has the
> >  appropriate static development libraries.
> >  Use the
> > - > url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'>IMAGE_INSTALL
> > + > url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'>TOOLCHAIN_TARGET_TASK
> >  variable inside your local.conf 
> > file
> > -to install the appropriate library packages.
> > +to install the appropriate library packages in SDK.
> >  Following is an example using 
> > glibc
> >  static development libraries:
> >  
> > - IMAGE_INSTALL_append = " glibc-staticdev"
> > + TOOLCHAIN_TARGET_TASK_append = " glibc-staticdev"
> >  
> >  

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] documentation: updates to static library support in SDK

2017-06-15 Thread Maxin B. John

Hi Scott,

On Wed, Jun 14, 2017 at 11:29:15AM -0700, Scott Rifenbark wrote:
>Maxin,
>
>Can you send out a new patch with the correction?
>

Sure, will send an updated patch soon.

>Scott
>>
>>On Wed, Jun 14, 2017 at 10:57 AM, Andre McCurdy  wrote:
>>
>>>On Wed, Jun 14, 2017 at 5:12 AM, Maxin B. John  
>>> wrote:
>>> For development purposes, static libraries need to be


Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] useradd and one sysroot per recipe in pyro

2017-06-15 Thread Maxin B. John

Hi Christian,

On Wed, Jun 14, 2017 at 04:13:04PM +, Andersen, Christian wrote:
> Hi Maxin,
> 
> > Here, could you try to build again with an additional DEPENDENCY on shadow-
> > native:
> > ie: instead of
> > >DEPENDS = "puck-base"
> > DEPENDS = "puck-base shadow-native"
> > 
> > To be sure, please cleansstate the puck-base and test before build.
> 
> Thanks! I tried as you suggested (cleansstate and then build) and with 
> shadow-native it is working now.

Good to hear that !

> Do I have to add shadow-native in all these recipes or is it a bug / 
> regression in pyro?

It is one of those "known" limitations which fell through the cracks.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8078

Thanks for bringing this up. We need to address this for pyro/master.

> Regards,
> Christian

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] devshell not working for Qt or Boundary Devices based yocto

2017-06-15 Thread Paul Eggleton

On Thursday, 15 June 2017 5:12:19 AM CEST Gary Thomas wrote:
> On 2017-06-15 01:58, Jimi Damon wrote:
> > I'm trying out two different yocto distributions and in each one the
> > devshell doens't work. Instead it just gets to the 
> > Summary line and returns to my normal shell ( bash ) .
> 
> What are you expecting to happen?  'devshell' is just that - a shell
> environment (e.g. bash) where you are set up to "develop" (tinker, explore,
> etc) the given recipe.

I think Jimi is saying that it doesn't appear to be launching a separate 
terminal / shell. Right?

Assuming that's what's happening, the devshell code is supposed to print out 
an error when it can't launch a suitable terminal, but if the terminal isn't 
doing what it should then that might leave you in this situation. Does 
log.do_devshell for the recipe indicate anything?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Failed to build gdb

2017-06-15 Thread Lm Chew

Hi,


I am running on the latest poky branch, targeting raspberry pi.


I have added the following line to the local.config to remove any package with 
license newer than GPLv2, with exception the gdb for development purpose:

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 AGPL-3.0"
INCOMPATIBLE_LICENSE_pn-gdb = ""


When i run the following command to build gdb I get the error shown below.

$ bitbake gdb


How can i resolve this issue?


Best Regards,

Chew


ERROR: gdb-7.12.1-r0 do_compile: oe_runmake failed
ERROR: gdb-7.12.1-r0 do_compile: Function failed: do_compile (log file is 
located at 
/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/temp/log.do_compile.11637)
ERROR: Logfile of failure stored in: 
/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/temp/log.do_compile.11637
Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8 SUBDIRS=intl mmalloc libiberty opcodes bfd sim gdb etc utils
| make[1]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi'
| make[1]: Nothing to be done for 'all-target'.
| make[2]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/intl'
| make[2]: Nothing to be done for 'all'.
| make[2]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/intl'
| make[2]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/libiberty'
| make[2]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/etc'
| make[2]: Nothing to be done for 'all'.
| make[2]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/etc'
| make[2]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/readline'
| make[2]: Nothing to be done for 'all'.
| make[2]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/readline'
| make[3]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/libiberty/testsuite'
| make[3]: Nothing to be done for 'all'.
| make[3]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/libiberty/testsuite'
| make[2]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/libiberty'
| make[2]: Entering directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/zlib'
| true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc " "CFLAGS=-O2 -pipe -g 
-feliminate-unused-debug-types 
-fdebug-prefix-map=/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0=/usr/src/debug/gdb/7.12.1-r0
 
-fdebug-prefix-map=/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/recipe-sysroot-native=
 
-fdebug-prefix-map=/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/recipe-sysroot=
 " "CXXFLAGS=-O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0=/usr/src/debug/gdb/7.12.1-r0
 
-fdebug-prefix-map=/media/chewlm86/ext_data_drive/yocto-celebes-c4

[yocto] NFS filesystem rights

2017-06-15 Thread Andrea Di Chiara


Hi,
with a filesystem generated with a recent Yocto version (Morty or Pyro)
I obtain the following error using it as a NFS filesystem

mount: only root can mount proc on /proc
mount: only root can use "--types" option (effective UID is 1000)

what could be the problem? I have never faced this error with previous
version of Yocto (Dizzy), how can I generate an image as root user?
thank you
best regards
Andrea


Software Department
softw...@teseo.com

-
TESEO spavia Agnelli, 49  63900 FERMO (FM) ITALY
Tel. +39 0734 628818   --Fax. +39 0734 628816

Disclaimer: This electronic mail transmission may contain legally privileged 
and/or confidential information. Do not read this if you are not the person(s) 
named. Any use, distribution, copying or disclosure by any other person is 
strictly prohibited. If you receive this transmission by mistake destroy the 
original transmission and its attachments without reading or saving in any 
manner.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH v2] documentation: updates to static library support in SDK

2017-06-15 Thread Maxin B. John

For development purposes, static libraries need to be
present only in the SDK. We do not need those static
libraries in the image for most scenarios. So, replace
IMAGE_INSTALL with TOOLCHAIN_TARGET_TASK in the documentation.

Suggested-by: Anders Darander 
Signed-off-by: Maxin B. John 
---
 documentation/adt-manual/adt-prepare.xml | 8 
 documentation/sdk-manual/sdk-appendix-obtain.xml | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/documentation/adt-manual/adt-prepare.xml 
b/documentation/adt-manual/adt-prepare.xml
index 65df1d0..29d41c5 100644
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -684,16 +684,16 @@
 
 By default, this toolchain does not build static binaries.
 If you want to use the toolchain to build these types of libraries,
-you need to be sure your image has the appropriate static
+you need to be sure your SDK has the appropriate static
 development libraries.
 Use the
-IMAGE_INSTALL
+TOOLCHAIN_TARGET_TASK
 variable inside your local.conf file to
-install the appropriate library packages.
+include the appropriate library packages in SDK.
 Following is an example using glibc static
 development libraries:
 
- IMAGE_INSTALL_append = " glibc-staticdev"
+ TOOLCHAIN_TARGET_TASK_append = " libc-staticdev"
 
 
 
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.xml 
b/documentation/sdk-manual/sdk-appendix-obtain.xml
index 3156f77..99ea49d 100644
--- a/documentation/sdk-manual/sdk-appendix-obtain.xml
+++ b/documentation/sdk-manual/sdk-appendix-obtain.xml
@@ -96,16 +96,16 @@
 
 By default, this toolchain does not build static binaries.
 If you want to use the toolchain to build these types of
-libraries, you need to be sure your image has the
+libraries, you need to be sure your SDK has the
 appropriate static development libraries.
 Use the
-IMAGE_INSTALL
+TOOLCHAIN_TARGET_TASK
 variable inside your local.conf file
-to install the appropriate library packages.
+to install the appropriate library packages in SDK.
 Following is an example using glibc
 static development libraries:
 
- IMAGE_INSTALL_append = " glibc-staticdev"
+ TOOLCHAIN_TARGET_TASK_append = " libc-staticdev"
 
 
 
-- 
2.4.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] samba create user with password

2017-06-15 Thread idealsim

I have made some progress but still have an issue. First to create an user  
we need expect. I add it to my local.conf. Under the script that work  
(tested on the card) :


 #!/usr/bin/expect -f
 spawn echo script for create samba user
 spawn smbpasswd -a sambaUser
 expect "New SMB password:"
 send "myPassword\n"
 expect "Retype new SMB password:"
 send "myPassword\n"
 interact
 spawn echo end of script
Then i have modified my recipe to add this script and launch it at first  
boot :


FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

# Add custom smb.conf file to samba recipe
SRC_URI += "file://22-samba-conf.patch \
file://createUserSamba.sh \
  "

do_install_append () {
install -m 0755 ${WORKDIR}/createUserSamba.sh ${D}${sysconfdir}/samba
}

pkg_postinst_samba () {
/etc/samba/createUserSamba.sh
}

But this don't work ! Do you have some advices to resolve this please ?

regards

Mickael.

Le Mon, 12 Jun 2017 21:30:55 +0200, idealsim  a  
écrit:




Hi, i'm trying to configure a samba server from yocto for my card. I  
have a working server (add samba in local.conf), but i would like to add  
the user >with password to samba at yocto build step. For this i add  
this recipe (samba_%.bbappend)

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

# Replace default smb.conf file to /etc/samba with my custom
SRC_URI += "file://22-samba-conf.patch"

pkg_postinst_${PN} () {
   smbpasswd -a sambaUser -s
   echo Password
   echo Password
   echo
}


For that i use pkg_postinst () but i don't know if i use it correctly  
(for the moment this won't work) ! At first boot time i need to execute  
#smbpasswd in >shell to activate the user in Samba. If someone can help  
to configure it in yocto recipe ?


regards

Mickael




--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-chip][PATCH] chip: Make sure to append to MACHINE_EXTRA_RRECOMMENDS rather than overwriting

2017-06-15 Thread Andrei Gherzan

On Mon, Jun 12, 2017 at 12:56 PM,  wrote:

> From: Drew Moseley 
>
> Signed-off-by: Drew Moseley 
> ---
>  conf/machine/chip.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Looks good. Merged to master. Thanks.

--
Andrei Gherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [layerindex-web][PATCH v2] layerindex/views: support querying by layer name

2017-06-15 Thread Jose Lamego

ping

On 05/31/2017 03:47 PM, Jose Lamego wrote:
> This change supports querying recipes that belong to a specific layer
> by using the prefix "layer:" + the desired layer name, for example:
> "layer: openembedded-core" and this string can be used by itself or
> combined with other supported options.
> 
> A descriptive error message is displayed when the query string has an
> unexpected formatting or a non-valid layer name is searched.
> 
> [YOCTO #6618]
> 
> Signed-off-by: Jose Lamego 
> ---
>  layerindex/views.py | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/layerindex/views.py b/layerindex/views.py
> index 65a536a..3eac3ac 100644
> --- a/layerindex/views.py
> +++ b/layerindex/views.py
> @@ -390,13 +390,28 @@ class RecipeSearchView(ListView):
>  for item in query_items:
>  if item.startswith('inherits:'):
>  inherits.append(item.split(':')[1])
> +# support searches by layer name
> +elif item.startswith('layer:'):
> +query_layername = item.split(':')[1].strip().lower()
> +if not query_layername:
> +messages.add_message(self.request, messages.ERROR, 'The \
> +layer name is expected to follow the \"layer:\" prefix without any spaces.')
> +query_layer = LayerBranch.objects.filter(
> +layer__name=query_layername)
> +if query_layer:
> +init_qs = init_qs.filter(
> +layerbranch__layer__id=query_layer[0].id)
> +else:
> +messages.add_message(self.request, messages.ERROR,
> + 'No layer \"%s\" was found.'
> + % query_layername)
>  else:
>  query_terms.append(item)
>  if inherits:
>  # FIXME This is a bit ugly, perhaps we should consider having 
> this as a one-many relationship instead
>  for inherit in inherits:
>  init_qs = init_qs.filter(Q(inherits=inherit) | 
> Q(inherits__startswith=inherit + ' ') | Q(inherits__endswith=' ' + inherit) | 
> Q(inherits__contains=' %s ' % inherit))
> -query_string = ' '.join(query_terms)
> +query_string = ' '.join(query_terms)
>  
>  if query_string.strip():
>  order_by = ('pn', 'layerbranch__layer')
> 

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Build my Yocto edison image

2017-06-15 Thread Franck Furic

Hi,

I have bought an Intel Edison board and I would like build my image including 
Qt Framework (meta-qt5).

In the past, (2 years ago) I have success to compile C++ program using Qt by 
build my image with meta-qt5 I think it was 1.6.x version of yocto project.

Now, it's impossible for me to build an image including qt on yocto. I have 
tried many thinks in different ways but nothing at the end.

Some people help me to do this here https://communities.intel.com/thread/115234.

I have tried on dizzy branch and morty branch but i have always errors.

Someone can help me tell me the correct procedure to build an image containing 
meta-qt5 on any version of yocto.

I need to develop some code with Qt Framework.


[Description : FranckFuric]

[Description : Facebook]  
[Description : youtube-logo]  
Site web : www.madelin-sa.com  |  E-boutique : 
www.storemadelin-sa.com
__
Ce message contient des informations confidentielles ou appartenant à la 
société MADELIN SA et est établi à l'attention  exclusive de ses destinataires.
Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) 
de ce message, ou des informations qu'il contient, doit être préalablement 
autorisée.
Si vous n'êtes pas destinataire de ce message, merci de le détruire 
immédiatement et d'avertir l'expéditeur de l'erreur de distribution et de la 
destruction du message

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [layerindex-web][PATCH v2] layerindex/views: support querying by layer name

2017-06-15 Thread Paul Eggleton

Hi Jose,

Sorry for the delay. The patch looks good except it displays two errors if 
there's no layer after the layer: prefix. I've fixed that myself and merged to 
layerindex-web master.

Thanks,
Paul

On Thursday, 15 June 2017 3:19:48 PM CEST Jose Lamego wrote:
> ping
> 
> On 05/31/2017 03:47 PM, Jose Lamego wrote:
> > This change supports querying recipes that belong to a specific layer
> > by using the prefix "layer:" + the desired layer name, for example:
> > "layer: openembedded-core" and this string can be used by itself or
> > combined with other supported options.
> > 
> > A descriptive error message is displayed when the query string has an
> > unexpected formatting or a non-valid layer name is searched.
> > 
> > [YOCTO #6618]
> > 
> > Signed-off-by: Jose Lamego 
> > ---
> >  layerindex/views.py | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/layerindex/views.py b/layerindex/views.py
> > index 65a536a..3eac3ac 100644
> > --- a/layerindex/views.py
> > +++ b/layerindex/views.py
> > @@ -390,13 +390,28 @@ class RecipeSearchView(ListView):
> >  for item in query_items:
> >  if item.startswith('inherits:'):
> >  inherits.append(item.split(':')[1])
> > +# support searches by layer name
> > +elif item.startswith('layer:'):
> > +query_layername = item.split(':')[1].strip().lower()
> > +if not query_layername:
> > +messages.add_message(self.request, messages.ERROR, 
'The \
> > +layer name is expected to follow the \"layer:\" prefix without any 
spaces.')
> > +query_layer = LayerBranch.objects.filter(
> > +layer__name=query_layername)
> > +if query_layer:
> > +init_qs = init_qs.filter(
> > +layerbranch__layer__id=query_layer[0].id)
> > +else:
> > +messages.add_message(self.request, messages.ERROR,
> > + 'No layer \"%s\" was found.'
> > + % query_layername)
> >  else:
> >  query_terms.append(item)
> >  if inherits:
> >  # FIXME This is a bit ugly, perhaps we should consider having 
this as a one-many relationship instead
> >  for inherit in inherits:
> >  init_qs = init_qs.filter(Q(inherits=inherit) | 
Q(inherits__startswith=inherit + ' ') | Q(inherits__endswith=' ' + inherit) | 
Q(inherits__contains=' %s ' % inherit))
> > -query_string = ' '.join(query_terms)
> > +query_string = ' '.join(query_terms)
> >  
> >  if query_string.strip():
> >  order_by = ('pn', 'layerbranch__layer')
> > 
> 
> 


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Failed to build gdb

2017-06-15 Thread Gary Thomas

loc2c.o compile-c-support.o inflow.oinit.o \
|   -lreadline ../opcodes/libopcodes.a ../bfd/libbfd.a -L./../zlib -lz  ../libiberty/libiberty.a 
../libdecnumber/libdecnumber.a-ldl -ldl -lncurses -lm -ldl -lexpat../libiberty/libiberty.a 
  build-gnulib/import/libgnu.a  -ldl -Wl,--dynamic-list=../../gdb-7.12.1/gdb/proc-service.list

| completer.o: In function `gdb_display_match_list_1':
| /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined reference to 
`_rl_completion_prefix_display_length'

| /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined 
reference to `rl_sort_completion_matches'
| collect2: error: ld returned 1 exit status
| Makefile:1418: recipe for target 'gdb' failed
| make[2]: *** [gdb] Error 1
| make[2]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/gdb'

| Makefile:8827: recipe for target 'all-gdb' failed
| make[1]: *** [all-gdb] Error 2
| make[1]: Leaving directory 
'/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi'

| Makefile:850: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at 
/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/temp/log.do_compile.11637)
ERROR: Task 
(/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/meta/recipes-devtools/gdb/gdb_7.12.1.bb:do_compile) 
failed with exit code '1'

NOTE: Tasks Summary: Attempted 933 tasks of which 932 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
   
/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/meta/recipes-devtools/gdb/gdb_7.12.1.bb:do_compile
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


I had no problem building with this configuration (up to date master):

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-my-distro-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "my-distro"
DISTRO_VERSION= "2.3+snapshot-20170615"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"
TARGET_FPU= "hard"
meta  = "master:b1d5267f0e31605b346af40778da0ac1ff298b78"
meta-raspberrypi  = "master:081405feaa544b5b5c55a3ac72e629f3f3869a26"

What's your configuration?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Failed to build gdb

2017-06-15 Thread Jussi Kukkonen

On 15 June 2017 at 10:19, Lm Chew  wrote:

> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
> reference to `_rl_completion_prefix_display_length'
> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
> reference to `rl_sort_completion_matches'
> | collect2: error: ld returned 1 exit status
>

Making an educated guess here: Because of the INCOMPATIBLE_LICENSE setting
you end up with an ancient version of readline that doesn't actually
provide the API that gdb needs. You may have to allow GPLv3+ for readline
as well.

Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cgl][PATCH] racoon2: add new recipe

2017-06-15 Thread Adrian Dudau

On fre, 2017-06-09 at 14:17 +0800, yi.z...@windriver.com wrote:
> From: Yi Zhao 
> 
> The Racoon2 project is a joint effort which provides an
> implementation
> of key management system for IPsec. It supports IKEv1, IKEv2, and
> KINK
> protocols.
> 
> Signed-off-by: Yi Zhao 
> ---
>  .../recipes-cgl/racoon2/racoon2/iked.service   |  14 +
>  .../racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch  |  32 +++
>  .../racoon2/racoon2/racoon2-DESTDIR.patch  | 202
> +++
>  .../racoon2/racoon2-Remove-INSTALL_OPTS.patch  |  87 +++
>  .../racoon2/racoon2-configure-autoheader.patch |  60 +
>  .../racoon2/racoon2/racoon2-configure-memcmp.patch |  32 +++
>  ...oon2-configure.in-remove-redundant-macros.patch | 199
> +++
>  .../racoon2-correct-openssl-include-path.patch |  70 +
>  .../racoon2/racoon2-disable-hard-limit-timer.patch |  80 ++
>  .../racoon2/racoon2-fix-configure-error.patch  |  50 
>  .../racoon2/racoon2-fix-hardcoded-sysconfdir.patch | 281
> +
>  .../racoon2/racoon2-fix-rekeying-reply.patch   |  28 ++
>  .../racoon2-fix-sadb_msg_seq-collision.patch   |  41 +++
>  ...oon2-fix-target-perl-path-to-generate-RPM.patch |  86 +++
>  .../racoon2/racoon2-fwrite-return-value.patch  |  34 +++
>  .../racoon2/racoon2/racoon2-iked-initscript.patch  |  34 +++
>  .../racoon2/racoon2-iked-needs-libcrypto.patch |  34 +++
>  .../racoon2/racoon2/racoon2-kinkd-initscript.patch |  34 +++
>  .../racoon2/racoon2-reenable-the-ipv6-check.patch  |  65 +
>  .../racoon2-remove-deprecated-do-clause.patch  |  19 ++
>  .../racoon2-removed-conflicting-prototypes.patch   |  51 
>  .../racoon2/racoon2/racoon2-spmd-initscript.patch  |  33 +++
>  .../recipes-cgl/racoon2/racoon2/spmd.service   |  12 +
>  .../racoon2/racoon2/volatiles.99_racoon2   |   1 +
>  .../recipes-cgl/racoon2/racoon2_20100526a.bb   | 104 
>  25 files changed, 1683 insertions(+)
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/iked.service
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-DESTDIR.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-Remove-INSTALL_OPTS.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-configure-autoheader.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-configure-memcmp.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-configure.in-remove-redundant-
> macros.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-correct-openssl-include-path.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-disable-hard-limit-timer.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-fix-configure-error.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-fix-hardcoded-sysconfdir.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-fix-rekeying-reply.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-fix-sadb_msg_seq-collision.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-fix-target-perl-path-to-generate-
> RPM.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-fwrite-return-value.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-iked-initscript.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-iked-needs-libcrypto.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-kinkd-initscript.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-reenable-the-ipv6-check.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-remove-deprecated-do-clause.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-removed-conflicting-prototypes.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/racoon2-spmd-initscript.patch
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/spmd.service
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2/volatiles.99_racoon2
>  create mode 100644 meta-cgl-common/recipes-
> cgl/racoon2/racoon2_20100526a.bb


./racoon2-iked-initscript.patch
./racoon2-kinkd-initscript.patch
./racoon2-spmd-initscript.patch

These patches are missing the Upstream-Status tag. Also, it might be
useful to include some comments on what some of these patches do and
why they're needed, for future recipe updates.

Otherwise the recipe looks good and builds fine.

Adrian

> 
> diff --git a/meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service 
> b/meta-cgl-commo

Re: [yocto] Failed to build gdb

2017-06-15 Thread Andre McCurdy

On Thu, Jun 15, 2017 at 8:13 AM, Jussi Kukkonen
 wrote:
> On 15 June 2017 at 10:19, Lm Chew  wrote:
>>
>> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
>> reference to `_rl_completion_prefix_display_length'
>>
>> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
>> reference to `rl_sort_completion_matches'
>> | collect2: error: ld returned 1 exit status
>
> Making an educated guess here: Because of the INCOMPATIBLE_LICENSE setting
> you end up with an ancient version of readline that doesn't actually provide
> the API that gdb needs. You may have to allow GPLv3+ for readline as well.

Or use gdb's bundled version of readline, which avoids needing to
whitelist additional packages. Try adding this to local.conf:

  PACKAGECONFIG_remove_pn-gdb = "readline"

> ___
> 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] Is linux-yocto-rt kernel compatible with x32 tune?

2017-06-15 Thread Andre McCurdy

On Wed, Jun 14, 2017 at 11:13 PM, Bruce Ashfield
 wrote:
> On Thu, Jun 15, 2017 at 4:11 AM, Paul D. DeRocco 
> wrote:
>>
>> I've been fighting with this off and on for a week. If I build
>> core-image-minimal for a generic86-64 machine, I can get it to use the x32
>> ABI, or I can switch to the linux-yocto-rt 4.8 kernel, but I can't do
>> both.
>>
>> If I do both, it builds with no complaint other than a lot of bit size
>> errors in grub-efi do_package_qa (which don't seem to matter with the
>> standard kernel). Most binaries, including loadable kernel modules, are
>> properly built as ELF architecture i386:x64-32, but the kernel itself is
>> built as i386:x86-64. The result is an immediate kernel panic trying to
>> run init, because the kernel doesn't know how to load it.

Isn't the point of x32 that the kernel should be full 64bit (and so
able to directly address all memory) and only user space should be
restricted to 32bit pointers?

If so, then the kernel ELF architecture x86-64 seems correct. If that
kernel can't run x32 user space binaries then maybe the kernel config
option to enable support for x32 user space is somehow missing?

>>
>> I understand that not all packages have been updated to work with x32, but
>> the RT kernel? Is this a combination that is known not to work? If it is
>> expected to work, am I the first person to try to boot it on actual
>> hardware? I'd like to know either that this simply won't work, so I can
>> stop wasting time on it, or get some help diagnosing the problem and
>> fixing it. I'm stumped.
>
>
> I can't think of a reason off the top of my head that would prevent this
> from working at the kernel level.
>
> But can you confirm that a non-rt build for the same board works with
> x32 ? It could just be a kernel configuration issue if it does work with
> non-rt, since the -rt variant may not have a BSP entry point defined.
>
> Bruce
>
>>
>>
>> --
>>
>> Ciao,   Paul D. DeRocco
>> Paulmailto:pdero...@ix.netcom.com
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end"
>
> --
> ___
> 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] Failed to build gdb

2017-06-15 Thread Lm Chew

Hi Jussi,


Thanks! That does the trick.


Best Regards,

Chew


From: Jussi Kukkonen 
Sent: Thursday, 15 June, 2017 11:13:20 PM
To: Lm Chew
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Failed to build gdb

On 15 June 2017 at 10:19, Lm Chew 
mailto:lm.c...@free2move.se>> wrote:

| /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined 
reference to `_rl_completion_prefix_display_length'

| /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined 
reference to `rl_sort_completion_matches'
| collect2: error: ld returned 1 exit status

Making an educated guess here: Because of the INCOMPATIBLE_LICENSE setting you 
end up with an ancient version of readline that doesn't actually provide the 
API that gdb needs. You may have to allow GPLv3+ for readline as well.

Jussi

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using A Proprietary Closed License Inside A Layer & Its Recipes

2017-06-15 Thread Thomas A. F. Thorne MEng AUS MIET

Good afternoon,

I am putting together a meta-company-name layer to hold some internal
code.  This will contain a few BSPs for our units, some internally
developed applications and a few config file patches.  I am having
trouble getting recipes to be related to the proprietary license.  

I have added "LICENSE" file to the root of the layer.  I have also added
a "licenses" directory that contains a single "companyname" file that
has our standard copyright boiler plate in it.  In the layer.conf file I
have added
LICENSE_PATH += "${LAYERDIR}/licenses"

When inside a recipe.bb file set:
LICENSE = "companyname"
LIC_FILES_CHKSUM = "file://companyname;md5=260e42b87d2e3235853331775b597ad3"

I get set of errors from bitbake:
NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: recipe-0.1-r0 do_configure: QA Issue: recipe: LIC_FILES_CHKSUM
points to an invalid file:
/home/thomasthorne/work/yocto/build-lib/tmp/work/all-poky-linux/recipe/0.1-r0/companyname
[license-checksum]
ERROR: recipe-0.1-r0 do_configure: Fatal QA errors found, failing task.
ERROR: recipe-0.1-r0 do_configure: Function failed: do_qa_configure
ERROR: Logfile of failure stored in:
/home/thomasthorne/work/yocto/build/tmp/work/all-poky-linux/recipe/0.1-r0/temp/log.do_configure.13583
ERROR: Task 487
(/home/thomasthorne/work/yocto/meta-companyname/recipes-companyname/recipe/recipe_0.1.bb,
do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1557 tasks of which 1556 didn't need to
be rerun and 1 failed.

Should I be including a copy of the license in each recipe separately
instead and then using LIC_FILES_CHKSUM =
"file://companyname;md5=260e42b87d2e3235853331775b597ad3" (or pointing
at a header with the beginline=5; endline=10 syntax)? 

Is it only possible to use the special
LICENSE = "CLOSED"
license for licenses not already placed in the main license directory? 

Any help or pointers would be very gratefully received.  I have been
having a confusing couple of hours with this so far. 

Regards,

-- 
Thomas Thorne  Software Engineer  Net2Edge Limited




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using A Proprietary Closed License Inside A Layer & Its Recipes

2017-06-15 Thread Burton, Ross

On 15 June 2017 at 15:52, Thomas A. F. Thorne MEng AUS MIET <
thomas.tho...@net2edge.com> wrote:

> Is it only possible to use the special
> LICENSE = "CLOSED"
> license for licenses not already placed in the main license directory?
>

Yes, there's special-case logic for 'CLOSED'.  Can you not just use that
for your internal pieces?  It's special-cased in a few places.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Failed to build gdb

2017-06-15 Thread Lm Chew

mds.o mi-cmd-catch.o
> mi-cmd-env.o mi-cmd-var.o mi-cmd-break.o mi-cmd-stack.o mi-cmd-file.o 
> mi-cmd-disas.o mi-symbol-cmds.o mi-cmd-target.o
> mi-cmd-info.o mi-interp.o mi-main.o mi-parse.o mi-getopt.o python.o guile.o 
> elfread.o stap-probe.o dtrace-probe.o
> posix-hdep.o posix-strerror.o c-exp.o cp-name-parser.o ada-exp.o jv-exp.o 
> d-exp.o f-exp.o go-exp.o m2-exp.o p-exp.o
> rust-exp.o version.o annotate.o addrmap.o auto-load.o auxv.o agent.o 
> bfd-target.o blockframe.o breakpoint.o
> break-catch-sig.o break-catch-throw.o break-catch-syscall.o findvar.o 
> regcache.o cleanups.o charset.o continuations.o
> corelow.o disasm.o dummy-frame.o dfp.o source.o value.o eval.o valops.o 
> valarith.o valprint.o printcmd.o block.o
> symtab.o psymtab.o symfile.o symfile-debug.o symmisc.o linespec.o 
> dictionary.o namespace.o location.o infcall.o infcmd.o
> infrun.o expprint.o environ.o stack.o tid-parse.o thread.o thread-fsm.o 
> exceptions.o extension.o filesystem.o
> filestuff.o inf-child.o interps.o minidebug.o main.o macrotab.o macrocmd.o 
> macroexp.o macroscope.o mi-common.o
> event-loop.o event-top.o inf-loop.o completer.o gdbarch.o arch-utils.o 
> gdbtypes.o gdb_bfd.o gdb_obstack.o osabi.o
> copying.o memattr.o mem-break.o target.o target-dcache.o parse.o language.o 
> build-id.o buildsym.o findcmd.o std-regs.o
> signals-state-save-restore.o signals.o exec.o reverse.o bcache.o objfiles.o 
> observer.o minsyms.o maint.o demangle.o
> dbxread.o coffread.o coff-pe-read.o dwarf2read.o mipsread.o stabsread.o 
> corefile.o dwarf2expr.o dwarf2loc.o
> dwarf2-frame.o dwarf2-frame-tailcall.o ada-lang.o c-lang.o d-lang.o f-lang.o 
> objc-lang.o ada-tasks.o ada-varobj.o
> c-varobj.o ui-out.o cli-out.o varobj.o vec.o go-lang.o go-valprint.o 
> go-typeprint.o jv-lang.o jv-valprint.o
> jv-typeprint.o jv-varobj.o m2-lang.o opencl-lang.o p-lang.o p-typeprint.o 
> p-valprint.o selftest.o sentinel-frame.o
> complaints.o typeprint.o ada-typeprint.o c-typeprint.o f-typeprint.o 
> m2-typeprint.o ada-valprint.o c-valprint.o
> cp-valprint.o d-valprint.o f-valprint.o m2-valprint.o ser-event.o serial.o 
> mdebugread.o top.o utils.o ui-file.o
> user-regs.o frame.o frame-unwind.o doublest.o frame-base.o inline-frame.o 
> gnu-v2-abi.o gnu-v3-abi.o cp-abi.o
> cp-support.o cp-namespace.o d-namespace.o reggroups.o rust-lang.o 
> trad-frame.o tramp-frame.o solib.o solib-target.o
> prologue-value.o memory-map.o memrange.o xml-support.o xml-syscall.o 
> xml-utils.o target-descriptions.o target-memory.o
> xml-tdesc.o xml-builtin.o inferior.o osdata.o gdb_usleep.o record.o 
> record-full.o gcore.o gdb_vecs.o jit.o progspace.o
> skip.o probe.o common-utils.o buffer.o ptid.o gdb-dlfcn.o common-agent.o 
> format.o registry.o btrace.o record-btrace.o
> waitstatus.o print-utils.o rsp-low.o errors.o common-debug.o debug.o 
> common-exceptions.o btrace-common.o fileio.o
> common-regcache.o compile.o compile-c-symbols.o compile-c-types.o 
> compile-object-load.o compile-object-run.o
> compile-loc2c.o compile-c-support.o inflow.oinit.o \
> |   -lreadline ../opcodes/libopcodes.a ../bfd/libbfd.a -L./../zlib -lz  
> ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a-ldl -ldl -lncurses -lm -ldl -lexpat
> ../libiberty/libiberty.a
>   build-gnulib/import/libgnu.a  -ldl 
> -Wl,--dynamic-list=../../gdb-7.12.1/gdb/proc-service.list
> | completer.o: In function `gdb_display_match_list_1':
> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined 
> reference to
> `_rl_completion_prefix_display_length'
> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined 
> reference to `rl_sort_completion_matches'
> | collect2: error: ld returned 1 exit status
> | Makefile:1418: recipe for target 'gdb' failed
> | make[2]: *** [gdb] Error 1
> | make[2]: Leaving directory
> '/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi/gdb'
> | Makefile:8827: recipe for target 'all-gdb' failed
> | make[1]: *** [all-gdb] Error 2
> | make[1]: Leaving directory
> '/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/build-arm-poky-linux-gnueabi'
> | Makefile:850: recipe for target 'all' failed
> | make: *** [all] Error 2
> | ERROR: Function failed: do_compile (log file is located at
> /media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/build-cm1-c4/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/gdb/7.12.1-r0/temp/log.do_compile.11637)
> ERROR: Task
> (/media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/meta/recipes-devtools/gdb/gdb_7.12.1.bb:do_compile)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 933 tasks of which 932 didn't need to be rerun 
> and 1 failed.
>
> Summary: 1 task failed:
>
> /media/chewlm86/ext_data_drive/yocto-celebes-c4/test/yocto-celebes-c4/meta/recipes-devtools/gdb/gdb_7.12.1.bb:do_compile
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

I had no problem building with this configuration (up to date master):

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-my-distro-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "my-distro"
DISTRO_VERSION= "2.3+snapshot-20170615"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"
TARGET_FPU= "hard"
meta  = "master:b1d5267f0e31605b346af40778da0ac1ff298b78"
meta-raspberrypi  = "master:081405feaa544b5b5c55a3ac72e629f3f3869a26"

What's your configuration?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
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] devshell not working for Qt or Boundary Devices based yocto

2017-06-15 Thread Jimi Damon


Hi,

I am not getting a separate terminal or even a different shell ( I would 
assume that Control-D or exit would get me back to the original shell ). 
Note that *bitbake -c pydevshell * also fails in that no 
python shell is started.



In fact, I've deduced that something is set in my Environment in my Bash 
shell that is causing this corruption.



For example, I created a brand new user called "testperson" with shell 
Zsh ( different than my bash )



Using the exact same poky distribution that was setup as follows


git clone git://git.yoctoproject.org/poky.git

cd poky

git clone git://git.yoctoproject.org/meta-raspberrypi

MACHINE=raspberrypi3 . ./oe-init-build-env mybuild

bitbake  -c devshell gettext


, this part worked for the testuser with zsh .


However, with my bash environment I get  :


bitbake -D -c devshell gettext


...

DEBUG: Inheriting /media/build/poky/meta/classes/autotools.bbclass 
(from /media/build/poky/meta/recipes-core/gettext/gettext_0.19.8.1.bb:29)
DEBUG: Inheriting /media/build/poky/meta/classes/siteinfo.bbclass 
(from /media/build/poky/meta/classes/autotools.bbclass:24)
DEBUG: Inheriting /media/build/poky/meta/classes/siteconfig.bbclass 
(from /media/build/poky/meta/classes/autotools.bbclass:251)
DEBUG: Inheriting /media/build/poky/meta/classes/texinfo.bbclass (from 
/media/build/poky/meta/recipes-core/gettext/gettext_0.19.8.1.bb:29)
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 
'common']
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 
'common']
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 
'common']

DEBUG: Executing task do_devshell
DEBUG: gettext-0.19.8.1-r0 do_devshell: Attempting to spawn terminal 
"xterm"

DEBUG: Teardown for bitbake-worker



The teardown comes immediately after the "Attemping to spawn terminal..."


Compared to


...
DEBUG: Inheriting /media/build/poky/meta/classes/siteconfig.bbclass 
(from /media/build/poky/meta/classes/autotools.bbclass:251)
DEBUG: Inheriting /media/build/poky/meta/classes/texinfo.bbclass (from 
/media/build/poky/meta/recipes-core/gettext/gettext_0.19.8.1.bb:29)
DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 
'common-linux', 'common-glibc', 'i586-linux', 'common']
DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 
'common-linux', 'common-glibc', 'i586-linux', 'common']
DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 
'common-linux', 'common-glibc', 'i586-linux', 'common']

DEBUG: Executing task do_devshell
DEBUG: gettext-0.19.8.1-r0 do_devshell: Attempting to spawn terminal 
"xterm"
Currently  1 running tasks (281 of 281)  99% 
|# 
|


in the testuser.


On a side note, how can I produce more debugging output besides "-D" for 
the bitbake so that I can find out more about

where the do_devshell task is failing ?

Thanks,

-Jimi



On 06/15/2017 01:47 AM, Paul Eggleton wrote:

On Thursday, 15 June 2017 5:12:19 AM CEST Gary Thomas wrote:

On 2017-06-15 01:58, Jimi Damon wrote:

I'm trying out two different yocto distributions and in each one the
devshell doens't work. Instead it just gets to the
Summary line and returns to my normal shell ( bash ) .

What are you expecting to happen?  'devshell' is just that - a shell
environment (e.g. bash) where you are set up to "develop" (tinker, explore,
etc) the given recipe.

I think Jimi is saying that it doesn't appear to be launching a separate
terminal / shell. Right?

Assuming that's what's happening, the devshell code is supposed to print out
an error when it can't launch a suitable terminal, but if the terminal isn't
doing what it should then that might leave you in this situation. Does
log.do_devshell for the recipe indicate anything?

Cheers,
Paul



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Meta-web-kiosk Layer

2017-06-15 Thread Riko Ho


Hello Everyone,

I tried doing bitbake core-image-web-kiosk and got some errors, does 
anyone know how to fix it ? thanks,


Loading cache: 100% 
|#| 
Time: 0:00:00

Loaded 1310 entries from dependency cache.
ERROR: ExpansionError during parsing 
/home/bianchi77/poky/meta-web-kiosk/recipes-browser/vala/vala_0.16.0.bb 
| ETA:  --:--:--

Traceback (most recent call last):
  File "/home/bianchi77/poky/bitbake/lib/bb/data_smart.py", line 412, 
in 
DataSmart.expandWithRefs(s='http://ftp.gnome.org/pub/GNOME/sources/${BPN}/${SHRT_VER}/${BP}.tar.xz 
http://ftp.gnome.org/pub/GNOME/sources/vala/0.36/vala-0.36.0.tar.xz', 
varname='SRC_URI'):

 try:
>s = __expand_var_regexp__.sub(varparse.var_sub, s)
 try:
  File "/home/bianchi77/poky/bitbake/lib/bb/data_smart.py", line 111, 
in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(46, 57), 
match='${SHRT_VER}'>):

 else:
>var = self.d.getVarFlag(key, "_content")
 self.references.add(key)
  File "/home/bianchi77/poky/bitbake/lib/bb/data_smart.py", line 794, 
in DataSmart.getVarFlag(var='SHRT_VER', flag='_content', expand=True, 
noweakdefault=False, parsing=False):

 cachename = var + "[" + flag + "]"
>value = self.expand(value, cachename)

  File "/home/bianchi77/poky/bitbake/lib/bb/data_smart.py", line 436, 
in 
DataSmart.expand(s="${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]}", 
varname='SHRT_VER'):

 def expand(self, s, varname = None):
>return self.expandWithRefs(s, varname).value

  File "/home/bianchi77/poky/bitbake/lib/bb/data_smart.py", line 426, 
in 
DataSmart.expandWithRefs(s="${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]}", 
varname='SHRT_VER'):

 except Exception as exc:
>raise ExpansionError(varname, s, exc) from exc

bb.data_smart.ExpansionError: Failure expanding variable SHRT_VER, 
expression was 
${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]} 
which triggered exception AttributeError: module 'bb.data' has no 
attribute 'getVar'



Summary: There was 1 ERROR message shown, returning a non-zero exit code.

--
*

/***/
Sent by Ubuntu LTS 16.04,
谢谢,
Regards,
Riko Ho
/***/

*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] devshell not working for Qt or Boundary Devices based yocto

2017-06-15 Thread Jimi Damon


Hi,

I created a yocto group and user for performing these builds.

The yocto user has the basic Ubuntu default account ( comes from a 
simple useradd ... )



I verified that this user is able to perform the exact same bitbake -c 
devshell gettext that fails for other username ( same exact location on 
the filesystem after a sudo chgrp -R yocto $directory && sudo chmod -R 
g+rw  $directory ).


I'm guessing something is going wrong with the fakeroot command as I'm 
now seeing the terminal show up for just a second and then close when I 
try running this devshell as my original username.


I'm not sure which setting in my bash shell is causing this error so I'm 
all ears for any suggestions.



-Jimi

On 06/15/2017 01:47 AM, Paul Eggleton wrote:

On Thursday, 15 June 2017 5:12:19 AM CEST Gary Thomas wrote:

On 2017-06-15 01:58, Jimi Damon wrote:

I'm trying out two different yocto distributions and in each one the
devshell doens't work. Instead it just gets to the
Summary line and returns to my normal shell ( bash ) .

What are you expecting to happen?  'devshell' is just that - a shell
environment (e.g. bash) where you are set up to "develop" (tinker, explore,
etc) the given recipe.

I think Jimi is saying that it doesn't appear to be launching a separate
terminal / shell. Right?

Assuming that's what's happening, the devshell code is supposed to print out
an error when it can't launch a suitable terminal, but if the terminal isn't
doing what it should then that might leave you in this situation. Does
log.do_devshell for the recipe indicate anything?

Cheers,
Paul



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is linux-yocto-rt kernel compatible with x32 tune?

2017-06-15 Thread Paul D. DeRocco

> From: Andre McCurdy [mailto:armccu...@gmail.com] 
> 
> Isn't the point of x32 that the kernel should be full 64bit (and so
> able to directly address all memory) and only user space should be
> restricted to 32bit pointers?
> 
> If so, then the kernel ELF architecture x86-64 seems correct. If that
> kernel can't run x32 user space binaries then maybe the kernel config
> option to enable support for x32 user space is somehow missing?

You're probably right, although I never saw any docs that spelled that out. 
That would explain why there are libx32 directories. I was hoping that x32 just 
meant that everything was compiled with a single architecture, just like a 
32-bit processor, just using 64-bit mode for the larger register set, and 
32-bit pointers everywhere. No need for any multi-arch logic. That would seem 
to be desirable for a modest sized embedded system. But if it still produces a 
64-bit kernel, I can live with that, as long as I can get it to work.

> From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] 
> 
> I can't think of a reason off the top of my head that would 
> prevent this from working at the kernel level.
> 
> But can you confirm that a non-rt build for the same board works with
> x32 ? It could just be a kernel configuration issue if it 
> does work with
> non-rt, since the -rt variant may not have a BSP entry point defined.

I did more thorough testing, doing six core-image-minimal builds: 32, 32rt, 64, 
64rt, 64x32, and 64x32rt. All the non-rt ones and the 64rt one work. The 32rt 
and 64x32rt both panic loading init.

I'm not sure if I'm specifying the rt kernel properly. My 32-bit local.conf 
includes

  MACHINE = "genericx86"
  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
  PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"

and my 64-bit x32 local.conf includes

  MACHINE = "genericx86-64"
  DEFAULTTUNE = "core2-64-x32"
  baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
 or 'INVALID'), True) or 'lib'}"
  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
  PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"

I have a tiny layer that just includes a linux-yocto-rt_4.8.bbappend:

  COMPATIBLE_MACHINE = "genericx86|genericx86-64"
  KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", \
  "mx32", " cfg/x32.scc", "" ,d)}"

and a non-rt one just specifying COMPATIBLE_MACHINE. I copied that last line 
from the linux-yocto_4.8.bb file, because it's not in the rt recipe. The .scc 
file pulls in a .cfg file which turns on CONFIG_X86_X32 and CONFIG_COMPAT. 

Yet the problem isn't with x32, it's that it can't run 32-bit binaries, even in 
a plain 32-bit kernel. So what am I leaving out, in my effort to specify the rt 
kernel?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cgl][PATCH] racoon2: add new recipe

2017-06-15 Thread Yi Zhao




在 2017年06月15日 23:37, Adrian Dudau 写道:

On fre, 2017-06-09 at 14:17 +0800, yi.z...@windriver.com wrote:

From: Yi Zhao 

The Racoon2 project is a joint effort which provides an
implementation
of key management system for IPsec. It supports IKEv1, IKEv2, and
KINK
protocols.

Signed-off-by: Yi Zhao 
---
  .../recipes-cgl/racoon2/racoon2/iked.service   |  14 +
  .../racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch  |  32 +++
  .../racoon2/racoon2/racoon2-DESTDIR.patch  | 202
+++
  .../racoon2/racoon2-Remove-INSTALL_OPTS.patch  |  87 +++
  .../racoon2/racoon2-configure-autoheader.patch |  60 +
  .../racoon2/racoon2/racoon2-configure-memcmp.patch |  32 +++
  ...oon2-configure.in-remove-redundant-macros.patch | 199
+++
  .../racoon2-correct-openssl-include-path.patch |  70 +
  .../racoon2/racoon2-disable-hard-limit-timer.patch |  80 ++
  .../racoon2/racoon2-fix-configure-error.patch  |  50 
  .../racoon2/racoon2-fix-hardcoded-sysconfdir.patch | 281
+
  .../racoon2/racoon2-fix-rekeying-reply.patch   |  28 ++
  .../racoon2-fix-sadb_msg_seq-collision.patch   |  41 +++
  ...oon2-fix-target-perl-path-to-generate-RPM.patch |  86 +++
  .../racoon2/racoon2-fwrite-return-value.patch  |  34 +++
  .../racoon2/racoon2/racoon2-iked-initscript.patch  |  34 +++
  .../racoon2/racoon2-iked-needs-libcrypto.patch |  34 +++
  .../racoon2/racoon2/racoon2-kinkd-initscript.patch |  34 +++
  .../racoon2/racoon2-reenable-the-ipv6-check.patch  |  65 +
  .../racoon2-remove-deprecated-do-clause.patch  |  19 ++
  .../racoon2-removed-conflicting-prototypes.patch   |  51 
  .../racoon2/racoon2/racoon2-spmd-initscript.patch  |  33 +++
  .../recipes-cgl/racoon2/racoon2/spmd.service   |  12 +
  .../racoon2/racoon2/volatiles.99_racoon2   |   1 +
  .../recipes-cgl/racoon2/racoon2_20100526a.bb   | 104 
  25 files changed, 1683 insertions(+)
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/iked.service
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-DESTDIR.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-Remove-INSTALL_OPTS.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-configure-autoheader.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-configure-memcmp.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-configure.in-remove-redundant-
macros.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-correct-openssl-include-path.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-disable-hard-limit-timer.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-fix-configure-error.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-fix-hardcoded-sysconfdir.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-fix-rekeying-reply.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-fix-sadb_msg_seq-collision.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-fix-target-perl-path-to-generate-
RPM.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-fwrite-return-value.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-iked-initscript.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-iked-needs-libcrypto.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-kinkd-initscript.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-reenable-the-ipv6-check.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-remove-deprecated-do-clause.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-removed-conflicting-prototypes.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/racoon2-spmd-initscript.patch
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/spmd.service
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2/volatiles.99_racoon2
  create mode 100644 meta-cgl-common/recipes-
cgl/racoon2/racoon2_20100526a.bb


./racoon2-iked-initscript.patch
./racoon2-kinkd-initscript.patch
./racoon2-spmd-initscript.patch

These patches are missing the Upstream-Status tag. Also, it might be
useful to include some comments on what some of these patches do and
why they're needed, for future recipe updates.

Otherwise the recipe looks good and builds fine.

Adrian


Thanks. I will send V2

Yi




diff --git a/meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service
b/meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service
new file mode 100644

[yocto] About the sstate cache

2017-06-15 Thread 刘松

Hi,


I am working on the project based on the yocto build system, and want to 
improve the build performance.


There are many packages downloaded from external and won't be changed nearly in 
the whole project lifecycle. But if doing a clean build these packages will be 
rebuilt again, I don't know the sstate cache will be used to cache them or not ?


Also does sstate cache only cache the file level or package level ? if only in 
file level the package making is still not avoided, right ?


Is there document about the details of the sstate cache ?


Any information will be very appreciated.


Thanks,

Song
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Image type on bitbake ?

2017-06-15 Thread Riko Ho


Hi Everyone,

What parameter do I add to bitbake for getting *.hddimg or *.wic image ?

for example bitbake -??? core-image-sato
Thanks
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sqlite in yocto1.8-fido

2017-06-15 Thread Khem Raj

On 6/14/17 11:05 PM, balaj...@easyarm.com wrote:
> 
> Dear sir
> 
>  I enabled sqlite in qtbase-native ,but iam not able to get sqlite
> related libraries.


how did you enabled it ?

> 
>  Any suggestion would be appreciable.
> 
> 
> Thanks
> Balaji
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Failed to build gdb

2017-06-15 Thread Lm Chew

Thanks, this way works too.

/Chew


From: Andre McCurdy 
Sent: Friday, 16 June, 2017 1:49:36 AM
To: Jussi Kukkonen
Cc: Lm Chew; yocto@yoctoproject.org
Subject: Re: [yocto] Failed to build gdb

On Thu, Jun 15, 2017 at 8:13 AM, Jussi Kukkonen
 wrote:
> On 15 June 2017 at 10:19, Lm Chew  wrote:
>>
>> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
>> reference to `_rl_completion_prefix_display_length'
>>
>> | /usr/src/debug/gdb/7.12.1-r0/gdb-7.12.1/gdb/completer.c:1862: undefined
>> reference to `rl_sort_completion_matches'
>> | collect2: error: ld returned 1 exit status
>
> Making an educated guess here: Because of the INCOMPATIBLE_LICENSE setting
> you end up with an ancient version of readline that doesn't actually provide
> the API that gdb needs. You may have to allow GPLv3+ for readline as well.

Or use gdb's bundled version of readline, which avoids needing to
whitelist additional packages. Try adding this to local.conf:

  PACKAGECONFIG_remove_pn-gdb = "readline"

> ___
> 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] Build my Yocto edison image

2017-06-15 Thread Khem Raj

On 6/15/17 6:30 AM, Franck Furic wrote:
> Hi,
> 
>  
> 
> I have bought an Intel Edison board and I would like build my image
> including Qt Framework (meta-qt5).
> 
>  
> 
> In the past, (2 years ago) I have success to compile C++ program using
> Qt by build my image with meta-qt5 I think it was 1.6.x version of yocto
> project.
> 
>  
> 
> Now, it’s impossible for me to build an image including qt on yocto. I
> have tried many thinks in different ways but nothing at the end.
> 
>  
> 
> Some people help me to do this here
> https://communities.intel.com/thread/115234.
> 
>  
> 
> I have tried on dizzy branch and morty branch but i have always errors.
> 
>  
> 
> Someone can help me tell me the correct procedure to build an image
> containing meta-qt5 on any version of yocto.
> 
>  
> 
> I need to develop some code with Qt Framework.

you can add the needed bits to image yourself. Like

IMAGE_INSTALL_append = "\
qtbase \
qtbase-tools \
qtbase-fonts \
qtbase-plugins \
qtwebkit \
qtwayland \
qtwayland-plugins \
cinematicexperience \
"

in local.conf



> 
>  
> 
>  
> 
> Description : FranckFuric
> 
>  
> 
> Description : Facebook  
> Description : youtube-logo
> Site web :
> www.madelin-sa.com   |  E-boutique :
> www.storemadelin-sa.com 
> 
> __
> 
> Ce message contient des informations confidentielles ou appartenant à la
> société MADELIN SA et est établi à l'attention  exclusive de ses
> destinataires.
> 
> Toute divulgation, utilisation, diffusion ou reproduction (totale ou
> partielle) de ce message, ou des informations qu'il contient, doit être
> préalablement autorisée.
> 
> Si vous n'êtes pas destinataire de ce message, merci de le détruire
> immédiatement et d'avertir l'expéditeur de l'erreur de distribution et
> de la destruction du message
> 
>  
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH V2] racoon2: add new recipe

2017-06-15 Thread yi.zhao

From: Yi Zhao 

The Racoon2 project is a joint effort which provides an implementation
of key management system for IPsec. It supports IKEv1, IKEv2, and KINK
protocols.

Signed-off-by: Yi Zhao 
---
 .../recipes-cgl/racoon2/racoon2/iked.service   |  14 +
 .../racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch  |  32 +++
 .../racoon2/racoon2/racoon2-DESTDIR.patch  | 202 +++
 .../racoon2/racoon2-Remove-INSTALL_OPTS.patch  |  87 +++
 .../racoon2/racoon2-configure-autoheader.patch |  60 +
 .../racoon2/racoon2/racoon2-configure-memcmp.patch |  32 +++
 ...oon2-configure.in-remove-redundant-macros.patch | 199 +++
 .../racoon2-correct-openssl-include-path.patch |  70 +
 .../racoon2/racoon2-disable-hard-limit-timer.patch |  80 ++
 .../racoon2/racoon2-fix-configure-error.patch  |  50 
 .../racoon2/racoon2-fix-hardcoded-sysconfdir.patch | 281 +
 .../racoon2/racoon2-fix-rekeying-reply.patch   |  28 ++
 .../racoon2-fix-sadb_msg_seq-collision.patch   |  41 +++
 ...oon2-fix-target-perl-path-to-generate-RPM.patch |  86 +++
 .../racoon2/racoon2-fwrite-return-value.patch  |  34 +++
 .../racoon2/racoon2/racoon2-iked-initscript.patch  |  40 +++
 .../racoon2/racoon2-iked-needs-libcrypto.patch |  34 +++
 .../racoon2/racoon2/racoon2-kinkd-initscript.patch |  40 +++
 .../racoon2/racoon2-reenable-the-ipv6-check.patch  |  65 +
 .../racoon2-remove-deprecated-do-clause.patch  |  19 ++
 .../racoon2-removed-conflicting-prototypes.patch   |  51 
 .../racoon2/racoon2/racoon2-spmd-initscript.patch  |  39 +++
 .../recipes-cgl/racoon2/racoon2/spmd.service   |  12 +
 .../racoon2/racoon2/volatiles.99_racoon2   |   1 +
 .../recipes-cgl/racoon2/racoon2_20100526a.bb   | 104 
 25 files changed, 1701 insertions(+)
 create mode 100644 meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-DESTDIR.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-Remove-INSTALL_OPTS.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-configure-autoheader.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-configure-memcmp.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-configure.in-remove-redundant-macros.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-correct-openssl-include-path.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-disable-hard-limit-timer.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-fix-configure-error.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-fix-hardcoded-sysconfdir.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-fix-rekeying-reply.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-fix-sadb_msg_seq-collision.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-fix-target-perl-path-to-generate-RPM.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-fwrite-return-value.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-iked-initscript.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-iked-needs-libcrypto.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-kinkd-initscript.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-reenable-the-ipv6-check.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-remove-deprecated-do-clause.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-removed-conflicting-prototypes.patch
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-spmd-initscript.patch
 create mode 100644 meta-cgl-common/recipes-cgl/racoon2/racoon2/spmd.service
 create mode 100644 
meta-cgl-common/recipes-cgl/racoon2/racoon2/volatiles.99_racoon2
 create mode 100644 meta-cgl-common/recipes-cgl/racoon2/racoon2_20100526a.bb

diff --git a/meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service 
b/meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service
new file mode 100644
index 000..3ec4f96
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/racoon2/racoon2/iked.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=daemon for the Internet Key Exchange
+After=syslog.target network.target spmd.service
+Requires=spmd.service
+
+[Service]
+Type=forking
+PIDFile=/var/run/iked.pid
+ExecStart=@SBINDIR@/iked
+ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
+SuccessExitStatus=1
+
+[Install]
+WantedBy=multi-user.target
diff --git 
a/meta-cgl-common/recipes-cgl/racoon2/racoon2/racoon2-Add-Value-to-HAVE_NSSWITCH_CONF.patch

Re: [yocto] FriendlyArm Mini6410 ?

Re: [yocto] [PATCH] documentation: updates to static library support in SDK

Re: [yocto] [PATCH] documentation: updates to static library support in SDK

Re: [yocto] useradd and one sysroot per recipe in pyro

Re: [yocto] devshell not working for Qt or Boundary Devices based yocto

[yocto] Failed to build gdb

[yocto] NFS filesystem rights

[yocto] [PATCH v2] documentation: updates to static library support in SDK

Re: [yocto] samba create user with password

Re: [yocto] [meta-chip][PATCH] chip: Make sure to append to MACHINE_EXTRA_RRECOMMENDS rather than overwriting

Re: [yocto] [layerindex-web][PATCH v2] layerindex/views: support querying by layer name

[yocto] Build my Yocto edison image

Re: [yocto] [layerindex-web][PATCH v2] layerindex/views: support querying by layer name

Re: [yocto] Failed to build gdb

Re: [yocto] Failed to build gdb

Re: [yocto] [meta-cgl][PATCH] racoon2: add new recipe

Re: [yocto] Failed to build gdb

Re: [yocto] Is linux-yocto-rt kernel compatible with x32 tune?

Re: [yocto] Failed to build gdb

[yocto] Using A Proprietary Closed License Inside A Layer & Its Recipes

Re: [yocto] Using A Proprietary Closed License Inside A Layer & Its Recipes

Re: [yocto] Failed to build gdb

Re: [yocto] devshell not working for Qt or Boundary Devices based yocto

[yocto] Meta-web-kiosk Layer

Re: [yocto] devshell not working for Qt or Boundary Devices based yocto

Re: [yocto] Is linux-yocto-rt kernel compatible with x32 tune?

Re: [yocto] [meta-cgl][PATCH] racoon2: add new recipe

[yocto] About the sstate cache

[yocto] Image type on bitbake ?

Re: [yocto] sqlite in yocto1.8-fido

Re: [yocto] Failed to build gdb

Re: [yocto] Build my Yocto edison image

[yocto] [meta-cgl][PATCH V2] racoon2: add new recipe

33 matches

Site Navigation

Mail list logo

Footer information