Re: [yocto] Installing the SDKs made with meta-mingw

2016-03-18 Thread Matt Hoosier 
On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson 
wrote:

> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
> wrote:
>
>> I've successfully built a Canadian-cross SDK using the meta-mingw layer.
>> Very nice!
>>
>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE}
>> is set to a MinGW host, though, the resulting SDK is not encapsulated into
>> the self-extracting tarball and the corresponding relocation logic (
>> relocate_sdk.py and so forth) is omitted.
>>
>> Any suggestions on how to do the last-mile work to use the SDK on
>> Windows? Or perhaps nothing is needed at all, except adjusting the prefixes
>> built into environment-setup-? Although that would be nice, I
>> think at least some installation-time adjustment is necessary though; when
>> I do:
>>
>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>
>> , the following happens during linking:
>>
>> ld.exe: cannot find /lib/libc.so.6 inside
>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>
>
As it turns out, the immediate error here was simply that libc.so.6 did not
exist, so ld.exe was telling the truth in this case. The symbolic links
stored in the SDK tarball that would have created libc.so.6 aren't
meaningful on Windows, so tar just ignores them when unpacking. Presumably
some fancier handling of the tarball unpacking to simulate symlinks by
making copies of the pointed-to file would cure this.


>
> Mark Hatle's branch switches to batch files for environment setup and
> whatnot. I don't know if it addresses the reloc issue or not, but it's a
> substantial improvement over master. See
> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>

Thanks, I'll try that.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Not able to disable introspection in gstreamer

2016-03-18 Thread Burton, Ross 
On 16 March 2016 at 14:54, Ashish Shrivastava 
wrote:

> Now gstreamer is throwing error for introspection.
>
>
> I am trying to disable it but with no success.
>

Can you include the full log of what errors you see?

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

Re: [yocto] Possible introspection failure in master

2016-03-18 Thread alexander . kanavin 
> The gstreamer _git recipes have not been updated to include the
> gobject introspection patches which were applied to the 1.6.3 recipes.

Yeah, I forgot about the git recipes, as they're totally hidden from
default builds. I'll get them fixed.

> Try disabling gobject introspection via DISTRO or MACHINE features, ie:
>
>   MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> gobject-introspection-data"

That is not going to help, I'm afraid. The recipes need further custom
fixing even when introspection is disabled.

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

Re: [yocto] Installing the SDKs made with meta-mingw

2016-03-18 Thread Christopher Larson 
On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
wrote:

> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
> wrote:
>
>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson >> > wrote:
>>>
 On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
 wrote:

> I've successfully built a Canadian-cross SDK using the meta-mingw
> layer. Very nice!
>
> Because the layer lobotomizes the SDK_PACKAGING_FUNC when
> ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not
> encapsulated into the self-extracting tarball and the corresponding
> relocation logic (relocate_sdk.py and so forth) is omitted.
>
> Any suggestions on how to do the last-mile work to use the SDK on
> Windows? Or perhaps nothing is needed at all, except adjusting the 
> prefixes
> built into environment-setup-? Although that would be nice, I
> think at least some installation-time adjustment is necessary though; when
> I do:
>
> arm-poky-linux-gnueabi-gcc -o foo foo.c
> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>
> , the following happens during linking:
>
> ld.exe: cannot find /lib/libc.so.6 inside
> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>

>>> As it turns out, the immediate error here was simply that libc.so.6 did
>>> not exist, so ld.exe was telling the truth in this case. The symbolic links
>>> stored in the SDK tarball that would have created libc.so.6 aren't
>>> meaningful on Windows, so tar just ignores them when unpacking. Presumably
>>> some fancier handling of the tarball unpacking to simulate symlinks by
>>> making copies of the pointed-to file would cure this.
>>>
>>>

 Mark Hatle's branch switches to batch files for environment setup and
 whatnot. I don't know if it addresses the reloc issue or not, but it's a
 substantial improvement over master. See
 https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw

>>>
>>> Thanks, I'll try that.
>>>
>>
>> Mark Hatle's branch does work much more nicely for that. There's still
>> the problem of what to do with the symlink from the SDK tarballs. Are there
>> any regular users of these mingw SDKs out there who know the right
>> expectation on how to extract them?
>>
>
> tar has an option to resolve symlinks to the files, I'd expect you could
> just add that to the variable for the tar options for the sdk, and it'd
> just duplicate the symlinks. You'll have extra files, so it'd be larger,
> but at least it'd be functional.
>

Erm, I meant duplicate the files, not the symlinks :) The symlinks would be
resolved to files. Clearly I haven't had enough caffeine yet today.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Compiling raspberry2 with eglinfo-x11

2016-03-18 Thread David Weisgerber 
Hi,
I have problems compiling eglinfo-x11 (as well as Qt 5 from meta-qt5) with egl.
I have setup poky, meta-raspberrypi (and meta-qt5) from git and I am on branch 
master.
My target is to get a distribution with working (hw acceleratetd) Qt5 with QML 
GUI. I have 
already spent some days on getting qteverywheredemo running but I did not 
succeed yet.
As a first test I wanted to get eglinfo-x11 running but it gives the following 
error when 
compiling:
[11/11] cxxprogram: build/release/src/json_writer.cpp.1.o 
build/release/src/log.cpp.1.o build/
release/src/main.cpp.1.o build/release/src/process_egl.cpp.1.o 
build/release/src/scopes.cpp.
1.o build/release/src/text_writer.cpp.1.o build/release/src/json-sax/json.c.1.o 
b

 
It links to libEGL and libGLESv2. nm says that this symbols should be in 
libGLESv2 but it just 
does not catch them up somehow?
 
My image is configured as follows:
include recipes-core/images/rpi-hwup-image.bb
 
GPU_MEM = "64"
 
LICENSE_FLAGS_WHITELIST = "commercial"
 
 
 
PACKAGECONFIG_append_pn-qtbase = "gles2"
 
SPLASH = "psplash-custopi"
 
ENABLE_SPI_BUS = "1"
 
IMAGE_FEATURES += "ssh-server-openssh splash x11-sato"
IMAGE_INSTALL_append = "qtbase qtbase-fonts custorouter custopi-gui 
packagegroup-core-
full-cmdline bluez5 wireless-tools wpa-supplicant qt5everywheredemo fontconfig 
freetype 
packagegroup-core-x11-base packagegroup-core-x11-sato eglinfo-x11"
 
IMAGE_LINGUAS ?= "de-de es-es fr-fr en-gb"
 
Thanks for help! 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

2016-03-18 Thread Christopher Larson 
On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier  wrote:

> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
> wrote:
>
>>
>>
>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson 
>> wrote:
>>
>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
>>> wrote:
>>>
 I've successfully built a Canadian-cross SDK using the meta-mingw
 layer. Very nice!

 Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE}
 is set to a MinGW host, though, the resulting SDK is not encapsulated into
 the self-extracting tarball and the corresponding relocation logic (
 relocate_sdk.py and so forth) is omitted.

 Any suggestions on how to do the last-mile work to use the SDK on
 Windows? Or perhaps nothing is needed at all, except adjusting the prefixes
 built into environment-setup-? Although that would be nice, I
 think at least some installation-time adjustment is necessary though; when
 I do:

 arm-poky-linux-gnueabi-gcc -o foo foo.c
 --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi

 , the following happens during linking:

 ld.exe: cannot find /lib/libc.so.6 inside
 d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi

>>>
>> As it turns out, the immediate error here was simply that libc.so.6 did
>> not exist, so ld.exe was telling the truth in this case. The symbolic links
>> stored in the SDK tarball that would have created libc.so.6 aren't
>> meaningful on Windows, so tar just ignores them when unpacking. Presumably
>> some fancier handling of the tarball unpacking to simulate symlinks by
>> making copies of the pointed-to file would cure this.
>>
>>
>>>
>>> Mark Hatle's branch switches to batch files for environment setup and
>>> whatnot. I don't know if it addresses the reloc issue or not, but it's a
>>> substantial improvement over master. See
>>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>>
>>
>> Thanks, I'll try that.
>>
>
> Mark Hatle's branch does work much more nicely for that. There's still the
> problem of what to do with the symlink from the SDK tarballs. Are there any
> regular users of these mingw SDKs out there who know the right expectation
> on how to extract them?
>

tar has an option to resolve symlinks to the files, I'd expect you could
just add that to the variable for the tar options for the sdk, and it'd
just duplicate the symlinks. You'll have extra files, so it'd be larger,
but at least it'd be functional.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] hddimg vs hdddirect?

2016-03-18 Thread Gary Thomas 

On 03/16/2016 08:40 PM, K Richard Pixley wrote:

What's the intended difference between hddimg and hdddirect?

I'm confused about the intent here. The data flow in previous releases,
even jethro, seems to be somewhat confused/broken so looking at the
source code isn't really helping here.

Is one intended to be a simple syslinux bootable image while the other
is a "live" image with multiple boot choices?

In master... How does one go about requesting either a vmdk of a live
image or a directly bootable vmdk?


I'm not sure the difference between the .hddimg and .hdddirect.
I tried converting a .hddimg to .vdi or .vmdk using the VBoxManage
tool, but that didn't come up - there was a message about (paraphrased)
"waiting for removable media to become ready"  and the boot just hung up

However, I do know that .vmdk will boot easily with VirtualBox
Just add this to your local.conf
  IMAGE_FSTYPES += " vmdk"

Note: as mentioned in the documentation, you must use += as
IMAGE_FSTYPES_append will not do.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Installing the SDKs made with meta-mingw

2016-03-18 Thread Matt Hoosier 
On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
wrote:

>
>
> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson 
> wrote:
>
>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
>> wrote:
>>
>>> I've successfully built a Canadian-cross SDK using the meta-mingw layer.
>>> Very nice!
>>>
>>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when ${SDKMACHINE}
>>> is set to a MinGW host, though, the resulting SDK is not encapsulated into
>>> the self-extracting tarball and the corresponding relocation logic (
>>> relocate_sdk.py and so forth) is omitted.
>>>
>>> Any suggestions on how to do the last-mile work to use the SDK on
>>> Windows? Or perhaps nothing is needed at all, except adjusting the prefixes
>>> built into environment-setup-? Although that would be nice, I
>>> think at least some installation-time adjustment is necessary though; when
>>> I do:
>>>
>>> arm-poky-linux-gnueabi-gcc -o foo foo.c
>>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>
>>> , the following happens during linking:
>>>
>>> ld.exe: cannot find /lib/libc.so.6 inside
>>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi
>>>
>>
> As it turns out, the immediate error here was simply that libc.so.6 did
> not exist, so ld.exe was telling the truth in this case. The symbolic links
> stored in the SDK tarball that would have created libc.so.6 aren't
> meaningful on Windows, so tar just ignores them when unpacking. Presumably
> some fancier handling of the tarball unpacking to simulate symlinks by
> making copies of the pointed-to file would cure this.
>
>
>>
>> Mark Hatle's branch switches to batch files for environment setup and
>> whatnot. I don't know if it addresses the reloc issue or not, but it's a
>> substantial improvement over master. See
>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw
>>
>
> Thanks, I'll try that.
>

Mark Hatle's branch does work much more nicely for that. There's still the
problem of what to do with the symlink from the SDK tarballs. Are there any
regular users of these mingw SDKs out there who know the right expectation
on how to extract them?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Conditional compile for package in layer.conf for Qemu

2016-03-18 Thread Burton, Ross 
On 18 March 2016 at 17:32, Mark T  wrote:

> Thanks, that  " IMAGE_INSTALL_append_intel-corei7-64 = "package_b" "  worked
> a treat.
>
> If I want to exclude a recipe from a layer for qemu builds  - is there a
> similar method for that ?
>

You can use _remove_qemuall for that.

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

Re: [yocto] Compiling raspberry2 with eglinfo-x11

2016-03-18 Thread SIVA SUBRAMANIAN.P 
What is your preferred GLES provider set to, userland or mesa?

On Wed, Mar 16, 2016 at 8:51 PM, David Weisgerber
 wrote:
> Hi,
>
> I have problems compiling eglinfo-x11 (as well as Qt 5 from meta-qt5) with
> egl.
>
> I have setup poky, meta-raspberrypi (and meta-qt5) from git and I am on
> branch master.
>
> My target is to get a distribution with working (hw acceleratetd) Qt5 with
> QML GUI. I have already spent some days on getting qteverywheredemo running
> but I did not succeed yet.
>
> As a first test I wanted to get eglinfo-x11 running but it gives the
> following error when compiling:
>
> [11/11] cxxprogram: build/release/src/json_writer.cpp.1.o
> build/release/src/log.cpp.1.o build/release/src/main.cpp.1.o
> build/release/src/process_egl.cpp.1.o build/release/src/scopes.cpp.1.o
> build/release/src/text_writer.cpp.1.o build/release/src/json-sax/json.c.1.o
> b
> uild/release/src/platform_x11_generic.cpp.1.o
> build/release/src/openvg_stats.cpp.1.o
> build/release/src/process_openvg.cpp.1.o -> build/release/eglinfo
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glDiscardFramebufferEXT'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glPointSizePointerOES'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_set_error_api'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_BindFramebuffer'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glintAttribPointer'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_state_free'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_FramebufferRenderbuffer'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_buffer_info_set'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_set_error'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_DeleteFramebuffers'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `gl11_client_state_init'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_GetFramebufferAttachmentParameteriv'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_IsRenderbuffer'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_GetRenderbufferParameteriv'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_DeleteRenderbuffers'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glBufferSubData'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_FramebufferTexture2D'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_BindRenderbuffer'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_GenerateMipmap'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_RenderbufferStorage'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_GenFramebuffers'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_GenRenderbuffers'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_CheckFramebufferStatus'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `gl20_client_state_init'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_buffer_info_get'
> /home/david/yocto/poky/build/tmp/sysroots/raspberrypi2/usr/lib/libEGL.so:
> undefined reference to `glxx_client_IsFramebuffer'
>
>
>
> It links to libEGL and libGLESv2. nm says that this symbols should be in
> libGLESv2 but it just does not catch them up somehow?
>
>
>
> My image is configured as follows:
>
> include recipes-core/images/rpi-hwup-image.bb
>
>
>
> GPU_MEM = "64"
>
>
>
> LICENSE_FLAGS_WHITELIST = "commercial"
>
>
>
>
>
>
>
> PACKAGECONFIG_append_pn-qtbase = "gles2"
>
>
>
> SPLASH = "psplash-custopi"
>
>
>
> ENABLE_SPI_BUS = "1"
>
>
>
> IMAGE_FEATURES += "ssh-server-openssh splash x11-sato"
>
> IMAGE_INSTALL_append = "qtbase qtbase-fonts custorouter

Re: [yocto] Re: Re: Qt5.6 new modules

2016-03-18 Thread idealsim 

Hi and thank you, now i know where to find SRCREV !
After adjust this variable and LICENSE.FDL the source is fetched. My bb :
/
//require qt5.inc//
//require qt5-git.inc//
//
//# There are no LGPLv3-only licensed files in this component.//
//# There are no GPLv2 licensed files in this component.//
//LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & 
The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"//

//LIC_FILES_CHKSUM = " \//
//file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \//
//file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \//
//file://LICENSE.FDL;md5=f70ee9a6c44ae8917586fea34dff0ab5 \//
//file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \//
//"//
//
//DEPENDS += "qtbase qtserialport"//
//
//SRCREV = "92c979c6652d55c30ab9118d45db74d8da96fc3b"/

When i launch bitbake qtserialbus, the process build without error, but 
it seems there is something missing because the compile step is very 
fast and my 
neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+92c979c665-r0/package/ 
folder is empty ! If i take the qtsensors folder, there are this folder 
(in package) :

usr/
include/
lib/
src/

I'm looking to meta-qt5 BSP to find where i can precise to build my new 
recipe but didn't find anything can help. Do you know how to proceed ?


regards,

Le 18/03/2016 08:16, Christian Ege a écrit :

Hi,

2016-03-17 17:16 GMT+01:00 idealsim :

Hi, i have started a build of the image this master Branch, like you said i
have an error on qtserialbus :

WARNING: Failed to fetch URL
git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git,
attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find revision
6a16281aceedb713676e16c3074e6f7ea1e70b79 in branch 5.6 even from upstream
ERROR: Function failed: Fetcher failure for URL:
'git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/media/modjo/data1TO/yocto/seco/udoo-community-bsp/neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+6a16281ace-r0/temp/log.do_fetch.5862
ERROR: Task 894
(/media/modjo/data1TO/yocto/seco/udoo-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtserialbus_git.bb,
do_fetch) failed with exit code '1'

This is my qtserialbus_git.bb :

require qt5.inc
require qt5-git.inc

# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & The-Qt-Company-Qt-LGPL-Exception-1.1
| LGPL-3.0)"
LIC_FILES_CHKSUM = " \
 file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
 file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
 file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
 file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"

DEPENDS += "qtbase qtserialport"

SRCREV = "6a16281aceedb713676e16c3074e6f7ea1e70b79"

The SRCREV is the git SHA1 of the repository qtserialbus. For the 5.6
Branch the latest one is:

SRCREV = "92c979c6652d55c30ab9118d45db74d8da96fc3b"


You can check the SHA1s here:
https://github.com/qtproject/qtserialbus/commits/5.6

The MD5 Sums will be complained during configure step and bitbake wil
tell you the right ones.
Please check if the Licences do match

Regards,
Christian


An idea is welcome !

Regards,

Mickaël



Le 16/03/2016 14:57, idealsim a écrit :

Thanks for the tip. I will try it out and let you know ...

Regards,

Mickaël

Le 16/03/2016 10:17, Christian Ege a écrit :

Hi,,

2016-03-16 9:04 GMT+01:00 idealsim :

Hi, we have build an image for udoo neo from meta-qt5 jansa/master-5.6 and
works fine (thanks to Christian Ege ). The problem is that I'm looking for
https://github.com/qtproject/qtquickcontrols2 and
https://github.com/qtproject/qtserialbus. My question is how we can add this
modules to our build ?  I add this to our local.conf :

  "qtquickcontrols2 \
   qtserialbus \
  "
But this modules don't have buildable providers ! If someone can help to
said me how to proceed ...

You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference

require qt5.inc
require qt5-git.inc
# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 &
The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"
LIC_FILES_CHKSUM = " \
file://LICENSE.LGPLv21;md5=58a180e1cf84c756c29f782b3a485c29 \
file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
file://LGPL_EXCEPTION.txt;md5=9625233da42f9e0ce9d63651a9d97654 \
file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"
DEPENDS += "qtbase"

SRCREV =

Re: [yocto] Conditional compile for package in layer.conf for Qemu

2016-03-18 Thread Mark T 
Ross,

Thanks, that  " IMAGE_INSTALL_append_intel-corei7-64 = "package_b" "  worked
a treat.

If I want to exclude a recipe from a layer for qemu builds  - is there a
similar method for that ?

Thanks,
Mark


On 17 March 2016 at 09:10, Andre McCurdy  wrote:

> On Wed, Mar 16, 2016 at 2:01 AM, Burton, Ross 
> wrote:
> >
> > On 16 March 2016 at 08:56, Mark T  wrote:
> >>
> >> I'd like to be able to do the following
> >>
> >> IMAGE_INSTALL_append += "package_a"
>
> It's not typical usage to combine += with _append, pick one or the other.
>
> Using _append is generally more reliable if you're not sure how the
> variable you're appending to was originally initialised, however with
> _append you need to manually include a leading space character, ie:
>
> IMAGE_INSTALL_append = " package_a"
>
> >> if ( not qemu )
> >> IMAGE_INSTALL_append += "package_b"
> >> endif
> >
> >
> > The neater way would be if you can easily identify what "not qemu" is,
> for
> > example:
> >
> > IMAGE_INSTALL_append_intel-corei7-64 = "package_b"
> >
> > Would install package_b only for intel-corei7-64 machines.
> >
> > If you want to support arbitrary machines but not qemu then something
> like
> > this might work:
> >
> > MOREDEPS = "package_b"
> > MOREDEPS_qemuall = ""
> > IMAGE_INSTALL_append = " ${MOREDEPS}"
> >
> > (qemuall is an override that is enabled by all qemu machines)
>
> Another alternative would be something like:
>
> IMAGE_INSTALL_remove_qemuall = "package_b"
>
> > Ross
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project booth at ELC - Call for demos

2016-03-18 Thread Barros Pena, Belen 
The Yocto Project will have a booth at the Embedded Linux Conference in
San Diego. If you have something you'd like to demo in the booth, please
reply to me off list providing the following information:

1. Person in charge of the demo (they must be at ELC)
2. Demo description

Thanks!

Belén

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