Re: [yocto] Installing the SDKs made with meta-mingw
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
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
> 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
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
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
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?
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
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
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
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 custopi-gui > packagegroup-core-fu
Re: [yocto] Re: Re: Qt5.6 new modules
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 = "71a323e1f12df8d213a4052621027e223eb5a343" The config
Re: [yocto] Conditional compile for package in layer.conf for Qemu
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
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