Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On 2 February 2015 at 18:33, Khem Raj raj.k...@gmail.com wrote: Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have updated the contrib tree which fixes cross-localedef-native compile time issue. So you should be good to go now. Bad news, glibc is now failing: | x86_64-poky-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap dl-open.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes -fPIC -mno-sse -mno-mmx-I../include -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include -isystem /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include -D_LIBC_REENTRANT -include /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h -DMODULE_NAME=rtld -include ../include/libc-symbols.h -DPIC -DSHARED -o /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os -MD -MP -MF /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt -MT /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os | dl-caller.c:1:0: error: SSE instruction set disabled, using 387 arithmetics [-Werror] | /* Check whether caller comes from the right place. | ^ | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics [-Werror] | /* Load a shared object at runtime, relocate it, and run its initializer. | ^ | cc1: all warnings being treated as errors | cc1: all warnings being treated as errors Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unset task_name[noexec] in bbappend
If there any way in the bbappend file to override task_name[noexec] = 1 specified in the parent .bb file? I want to extend the package-index task, and need to fetch a couple of configuration files. The package-index.bb task contains do_fetch[noexec] = 1, so the fetch is not performed. -- Paul Stath Axxcelera Broadband Wireless -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake-whatchanged error
On 02/03/2015 02:40 AM, Paul Eggleton wrote: Hi Gary, On Monday 02 February 2015 09:33:30 Gary Thomas wrote: Every time I run the 'bitbake-whatchanged' script, I get an error like this: ERROR: Bitbake's cached basehash does not match the one we just generated (/home/local/poky-cutting-edge/meta-imx6/packages/images/imx6-demo-image.bb .do_rootfs)! ERROR: The mismatched hashes were e48dfde9772b0a567b5327087c9e2d44 and 3c3447f08ef4da61b814bff5fb909bff What causes this and should I be worried? Does it affect the actual results which are shown? I don't think you should necessarily be worried, but this is definitely a bug and we should fix it. It affects bitbake -S printdiff as well. If you have a chance it would be great if you could file a bug about it. Thanks, Paul I've sent a patch to OE-core mailing list to fix this problem. The title is: image.bbclass: don't let do_rootfs depend on BUILDNAME Regards, Chen Qi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] layer conf: update to include meta-networking
layer index updated. I will update README next. thanks, Armin On 02/02/2015 10:31 AM, Paul Eggleton wrote: On Monday 02 February 2015 10:24:21 akuster808 wrote: On 02/02/2015 08:31 AM, Paul Eggleton wrote: Can you please also update the OE layer index? Do I do that manually or is it picked up from the README? No, it needs to be done manually, I don't have anything to parse a README and extract dependencies at the moment. http://layers.openembedded.org/layerindex/branch/master/layer/meta-securit y/ I added meta-perl and meta-oe this morning based on the meta-security README - the latter isn't represented in your LAYERDEPENDS value though, so all three places ought to be made consistent with whatever the actual set of requirements is. (If people are starting to use LAYERDEPENDS a bit more it might make sense for us to add some code to the layer index update script to try to update its dependency list based upon LAYERDEPENDS and BBFILE_COLLECTIONS; up to now it hasn't seen a huge amount of use hence I hadn't done that.) Is the idea to include all layers required including the cascaded ones? i.e: meta-networking requires mete-python, should I include that one too? No, no need to do that - just the direct dependencies is enough. Cheers, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFC]provide native recipe for every package
Hi folks Would you tell me why can't we inherit native.bbclass in every recipes. IMO, it's better to provide native recipe for every package. Thanks, Bian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to use different busybox defconfig's in the initramfs and rootfs image
The only way I know is to make a new recipe, busybox-initramfs.bb, for example. Install busybox for image rootfs and busybox-initramfs for initramfs. Best Regards, Chen Qi On 02/02/2015 09:21 PM, erwin.rieger@rohde-schwarz.com wrote: Hello list, i have used Yocto to create a initramfs linux kernel and a corresponding rootfs for a embedded linux system. Things are working as expected, so far. Now i want to fine-tune my setup and want to use a different busybox configuration in the initramfs as the one in the rootfs image. For example, the initramfs busybox should contain support for switch-root and that is not needed in the rootfs. On the other hand, the rootfs should contain a full-fledged busybox (with inetd enabled, for example). So the question is: How can i build/install a package two times with differing configurations in one bitbake run?. How can this be done the Yocto-way without copying busybox.bb and hacking it the way i need it? I've tried various combinations, e.g. bb-appending busybox, inheriting from busybox and so on - but to no avail. Maybe someone have an idea on how to do that? PS: * The kernel recipe is derived (bbappend) from core-image-minimal-initramfs. * Rootfs recipe is derived from core-image-minimal.bb. -- Erwin Rieger -- -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Recipe reporting system] Upgradable recipe name list
This mail was sent out by Recipe reporting system. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-xxx in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-xxx = Not upgrade to 2.0 is unstable You can check the detail information at: http://packages.yoctoproject.org/upgradepkgname Package VersionUpstream version Maintainer NoUpgradeReason - --- -- gnome-icon-theme 2.31.0 3.7.4 Alejandro Hernandez waiting for the sato gtk3 port nfs-utils 1.3.1 1.3.2 Alejandro Hernandez midori0.5.8 0.5.9 Alejandro Hernandez screen4.0.3 4.2.1 Aníbal Limón jpeg 8d 9 Aníbal Limón webkit-gtk 1.8.3 doesn't wo... apt 0.9.9.41.0.9.6 Aníbal Limón nettle2.7.1 3.0 Armin Kuster 3.0.0 breaks gnutls, api ch... linux-libc-headers3.17.7 3.18.5Bruce Ashfield sysstat 11.0.2 11.1.2Chen Qi busybox 1.22.1 1.23.1Chen Qi console-tools 0.3.2 1999.03.02Chen Qi systemd 216+gitX 218+gitAUTOINC+55... Chen Qi dbus-test 1.8.10 1.9.6 Chong Lu dbus 1.8.10 1.9.6 Chong Lu D-BUS 1.9.x is the developm... bison 2.7.1 3.0.4 Chong Lu libatomics-ops7.27.4.0 Cristian Iorga pulseaudio5.05.99.3Cristian Iorga speex 1.2rc1 1.2rc2Cristian Iorga db6.0.30 6.1.19Cristian Iorga API compatibility issue libical 1.0.0 1.0.1 Cristian Iorga neon 0.30.0 0.30.1Cristian Iorga quota 4.01 4.02 Cristian Iorga harfbuzz 0.9.37 0.9.38Cristian Iorga bluez44.101 5.28 Cristian Iorga BlueZ 5.x is not backward-c... gst-plugin-bluetooth 4.101 5.28 Cristian Iorga bluez55.27 5.28 Cristian Iorga connman 1.26 1.28 Cristian Iorga iproute2 3.17.0 3.18.0Cristian Iorga neard 0.14 0.15 Cristian Iorga ofono 1.15 1.16 Cristian Iorga gst-fluendo-mp3 0.10.310.10.32 Cristian Iorga gst-fluendo-mpegd... 0.10.720.10.85 Cristian Iorga flac 1.3.0 1.3.1 Cristian Iorga hwlatdetect 0.89 0.90 Darren Hart rt-tests 0.89 0.90 Darren Hart linux-yocto-dev 3.17++gitX 3.17.6++5ff54d8fb... Darren Hart linux-yocto-rt3.14.24+gitX 3.14.29+gitAUTOIN... Darren Hart linux-yocto-tiny 3.17.6+gitX2012+gitAUTOINC+5... Darren Hart linux-yocto 3.14.24+gitX 3.14.29+gitAUTOIN... Darren Hart kernelshark 1.2+gitX 2.5.1+gitAUTOINC+... Darren Hart 0.2 is the latest version. trace-cmd 2.3.2+gitX 2.5.1+gitAUTOINC+... Darren Hart u-boot-fw-utils v2014.07+gitX v2015.01+gitAUTOI... Denys Dmytriyenko u-boot-mkimagev2014.07+gitX v2015.01+gitAUTOI... Denys Dmytriyenko u-bootv2014.07+gitX v2015.01+gitAUTOI... Denys Dmytriyenko qmmp 0.7.7 0.8.3 Hongxu Jia patch 2.7.1 2.7.4 Hongxu Jia perl 5.20.0 5.21.8Hongxu Jia createrepo0.4.11 0.10.3Hongxu Jia Versions after 0.9.* use YU... bash 4.34.3.30Hongxu Jia The latest version in yocto... groff 1.22.2 1.22.3Hongxu Jia 1.18.1.4 is latest GPLv2 Ve... man-pages 3.76 3.79 Hongxu Jia man 1.6g 2.5a6 Hongxu Jia pigz 2.3.1 2.3.3 Hongxu Jia socat 1.7.2.41.7.3.0 Hongxu Jia
[yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
Hi All I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 ( upcoming ) on a contrib branch ( top 2 patches) its has not got much testing besides x86 qemu thus far. http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade I would like to request some help in testing these out in your respective environments and please report any issues you see so we can start sorting them out at earlier and making its way into OE-Core. Thanks for your help -Khem -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] need help to add local kernel to yocto build
Hi, I am new to yocto and trying to create bsp for my wandboard-quad. As a starting point I have followed the http://wiki.wandboard.org/Getting_started_with_Yocto_on_Wandboard and finally gave the command bitbake core-image-minimal So far so good.., I can see the generated images at /fsl-community-bsp/build/tmp/deploy/images/myboard/ Now I don't want build yocto with my own kernel instead of downloading from repository. It was 3.0.35 base kernel with lot of modifications being done to it. I have been working to acheive this since last week and was no success to acheive this. I have read yocto user manual and other stuff and came to know that I need to set the SOURCE_MIRROR_URL in bit bake file. So I have tried to set the following in the bit bake file located at $ /fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/ linux-wandboard_3.0.35.bb SOURCE_MIRROR_URL ?= file://home/mykernel/ INHERIT += own-mirrors BB_GENERATE_MIRROR_TARBALLS = 1 BB_NO_NETWORK = 1 But it was not working. Some one must have already tried to acheive this. Please let me know like how do I set the path to my local kernel folder and with what name do I need to store it. Modifying linux-wandboard_3.0.35.bb is sufficient or do I need to modify any other files as well Regards, Pavan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to use different busybox defconfig's in the initramfs and rootfs image
Hello list, i have used Yocto to create a initramfs linux kernel and a corresponding rootfs for a embedded linux system. Things are working as expected, so far. Now i want to fine-tune my setup and want to use a different busybox configuration in the initramfs as the one in the rootfs image. For example, the initramfs busybox should contain support for switch-root and that is not needed in the rootfs. On the other hand, the rootfs should contain a full-fledged busybox (with inetd enabled, for example). So the question is: How can i build/install a package two times with differing configurations in one bitbake run?. How can this be done the Yocto-way without copying busybox.bb and hacking it the way i need it? I've tried various combinations, e.g. bb-appending busybox, inheriting from busybox and so on - but to no avail. Maybe someone have an idea on how to do that? PS: * The kernel recipe is derived (bbappend) from core-image-minimal-initramfs. * Rootfs recipe is derived from core-image-minimal.bb. -- Erwin Rieger -- -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Need help for custom recipe
Hi,
I am trying to write an custom recipe for one of the application. In the
do_install() I am using an external script for creating rpm of the application.
Below is the recipe file which I have written.
SUMMARY = Hello World
DESCRIPTION = A recipe for HelloWorld
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302file:///\\$%7bCOMMON_LICENSE_DIR%7d\MIT;md5=0835ade698e0bcf8506ecda2f7b4f302
# Upstream names releases after SVN revs
#SRCREV = 100
SRCREV = ${AUTOREV}
PV = r${SRCREV}
DEPENDS = boost util-linux curl
SRC_URI = file://helloworld.c
S = ${WORKDIR}
do_install () {
sh ${WORKDIR}/ build.sh
}
Now as this is a makefile based project. Now when I fire bitbake helloworld I
am able to build the RPM of the package using build.sh file.
But when I try to check these RPM under build_dir/tmp/deploy it is not found.
Any thoughts how to fix the same.
Thanks,
Abhinav
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Recipe reporting system] Upgradable recipe name list
This mail was sent out by Recipe reporting system. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-xxx in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-xxx = Not upgrade to 2.0 is unstable You can check the detail information at: http://packages.yoctoproject.org/upgradepkgname Package VersionUpstream version Maintainer NoUpgradeReason - --- -- gnome-icon-theme 2.31.0 3.7.4 Alejandro Hernandez waiting for the sato gtk3 port nfs-utils 1.3.1 1.3.2 Alejandro Hernandez midori0.5.8 0.5.9 Alejandro Hernandez screen4.0.3 4.2.1 Aníbal Limón jpeg 8d 9 Aníbal Limón webkit-gtk 1.8.3 doesn't wo... apt 0.9.9.41.0.9.6 Aníbal Limón dpkg 1.17.211.17.23 Aníbal Limón nettle2.7.1 3.0 Armin Kuster 3.0.0 breaks gnutls, api ch... linux-libc-headers3.17.7 3.18.5Bruce Ashfield sysstat 11.0.2 11.1.2Chen Qi resolvconf1.76 1.76.1Chen Qi busybox 1.22.1 1.23.1Chen Qi console-tools 0.3.2 1999.03.02Chen Qi systemd 216+gitX 218+gitAUTOINC+a3... Chen Qi dbus-test 1.8.10 1.9.6 Chong Lu dbus 1.8.10 1.9.6 Chong Lu D-BUS 1.9.x is the developm... bison 2.7.1 3.0.4 Chong Lu libatomics-ops7.27.4.0 Cristian Iorga pulseaudio5.05.99.3Cristian Iorga speex 1.2rc1 1.2rc2Cristian Iorga db6.0.30 6.1.19Cristian Iorga API compatibility issue libical 1.0.0 1.0.1 Cristian Iorga neon 0.30.0 0.30.1Cristian Iorga quota 4.01 4.02 Cristian Iorga harfbuzz 0.9.37 0.9.38Cristian Iorga bluez44.101 5.27 Cristian Iorga BlueZ 5.x is not backward-c... gst-plugin-bluetooth 4.101 5.27 Cristian Iorga connman 1.26 1.27 Cristian Iorga iproute2 3.17.0 3.18.0Cristian Iorga neard 0.14 0.15 Cristian Iorga ofono 1.15 1.16 Cristian Iorga gst-fluendo-mpegd... 0.10.720.10.85 Cristian Iorga flac 1.3.0 1.3.1 Cristian Iorga gst-fluendo-mp3 0.10.310.10.32 Cristian Iorga hwlatdetect 0.89 0.90 Darren Hart rt-tests 0.89 0.90 Darren Hart linux-yocto-dev 3.17++gitX 3.17.6++5ff54d8fb... Darren Hart linux-yocto-rt3.14.24+gitX 3.14.29+gitAUTOIN... Darren Hart linux-yocto-tiny 3.17.6+gitX2012+gitAUTOINC+5... Darren Hart linux-yocto 3.14.24+gitX 3.14.29+gitAUTOIN... Darren Hart kernelshark 1.2+gitX 2.5.1+gitAUTOINC+... Darren Hart 0.2 is the latest version. trace-cmd 2.3.2+gitX 2.5.1+gitAUTOINC+... Darren Hart u-boot-fw-utils v2014.07+gitX v2015.01+gitAUTOI... Denys Dmytriyenko u-boot-mkimagev2014.07+gitX v2015.01+gitAUTOI... Denys Dmytriyenko u-bootv2014.07+gitX v2015.01+gitAUTOI... Denys Dmytriyenko qmmp 0.7.7 0.8.3 Hongxu Jia patch 2.7.1 2.7.4 Hongxu Jia perl 5.20.0 5.21.8Hongxu Jia createrepo0.4.11 0.10.3Hongxu Jia Versions after 0.9.* use YU... bash 4.34.3.30Hongxu Jia The latest version in yocto... groff 1.22.2 1.22.3Hongxu Jia 1.18.1.4 is latest GPLv2 Ve... man-pages 3.76 3.78 Hongxu Jia man 1.6g 2.5a6 Hongxu Jia pigz 2.3.1 2.3.3 Hongxu Jia socat
Re: [yocto] need help to add local kernel to yocto build
try using SOURCE_MIRROR_URL ?= file:///home/mykernel/ - three '///' assuming that /home is in your root directoryLachlan - Original Message - From: Pavan Kumar B To: Cc: Sent:Sun, 1 Feb 2015 19:58:35 +0530 Subject:[yocto] need help to add local kernel to yocto build Hi, I am new to yocto and trying to create bsp for my wandboard-quad. As a starting point I have followed the http://wiki.wandboard.org/Getting_started_with_Yocto_on_Wandboard [1] and finally gave the command bitbake core-image-minimal So far so good.., I can see the generated images at /fsl-community-bsp/build/tmp/deploy/images// Now I don't want build yocto with my own kernel instead of downloading from repository. It was 3.0.35 base kernel with lot of modifications being done to it. I have been working to acheive this since last week and was no success to acheive this. I have read yocto user manual and other stuff and came to know that I need to set the SOURCE_MIRROR_URL in bit bake file. So I have tried to set the following in the bit bake file located at $ /fsl-community-bsp/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-wandboard_3.0.35.bb SOURCE_MIRROR_URL ?= file://home/mykernel/ INHERIT += own-mirrors BB_GENERATE_MIRROR_TARBALLS = 1 BB_NO_NETWORK = 1 But it was not working. Some one must have already tried to acheive this. Please let me know like how do I set the path to my local kernel folder and with what name do I need to store it. Modifying linux-wandboard_3.0.35.bb is sufficient or do I need to modify any other files as well Regards, Pavan Message sent via Adam Internet WebMail - http://www.adam.com.au/ Links: -- [1] http://wiki.wandboard.org/Getting_started_with_Yocto_on_Wandboard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Target SDK
Hi, How do I build a target SDK, so that I can develop on the target. My target machine is ARM. I am using poky-1.5. When I try to add the packagegroup-target-sdk I get an install error which says Nothing RPROVIDES perl-ptest, even though I have selected perl-ptest for the final image that has the sdk builtin. How do I resolve this problem? Kind regards Sirjee. Rooplall (Systems Engineer) Description: C:\Users\FDL\AppData\Roaming\Microsoft\Signatures\sirjee_files\Image001.jp g -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Checksum failure encountered Java
Hi Jim, On Sun, Feb 01, 2015 at 10:58:02AM -0500, Jim Abernathy wrote: after I posted this issues, I tried to click on the link at the Oracle site and there is something about accepting a License. I have the LICENSE_FLAGS_WHITELIST += oracle_java which worked on the NUC build. I'm guessing that's not the issue. Since Oracle download webpage has an accept license button, the downloading process is on a best effort basis one. If the download fails for a particular binary, please go to the oracle download webpage and download the tarball. Move that binary to the bitbake download location as mentioned in local.conf file and build again. Sorry for the trouble and I think, we should update the README to reflect this process (again). Please note that the arm binary is pre-built for vfp-hflt (hard-float) and it may have troubles with root-filesystem built with soft-float support. Jim A Best Regards, Maxin ━━━ From: jfaberna...@outlook.com To: yocto@yoctoproject.org Date: Sun, 1 Feb 2015 10:53:28 -0500 Subject: [yocto] Checksum failure encountered Java I tried to move a build from NUC to Pandaboard and the core-image-sato worked fine, well except the README.HARDWARE for arm didn't mention coping the uImage to /boot. Figured that out easy enough. But when I tried to add oracle-jse-jre that worked fine on NUC got the following errors: WARNING: Checksum failure encountered with download of http:// download.oracle.com/otn/java/ejre/7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz - will attempt other sources if available WARNING: Renaming /work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz to / work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz_bad-checksum_b72400960629e7403c4b579dada2a804 ERROR: Fetcher failure for URL: 'http://download.oracle.com/otn/java/ejre/ 7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz'. Checksum mismatch! File: '/work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz' has md5 checksum b72400960629e7403c4b579dada2a804 when b9b8f598b0a7f49e4d221f16ba25c6c0 was expected File: '/work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz' has sha256 checksum c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779 when ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = b72400960629e7403c4b579dada2a804 SRC_URI[sha256sum] = c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779 Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: Function failed: Fetcher failure for URL: 'http://download.oracle.com/ otn/java/ejre/7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /work/pandaboard/tmp/work/ cortexa9t2hf-vfp-neon-poky-linux-gnueabi/oracle-jse-jre/1.7.0-u60r0/temp/ log.do_fetch.31677 ERROR: Task 231 (/home/jim/poky/meta-oracle-java/recipes-devtools/oracle-java/ oracle-jse-jre_1.7.0.bb, do_fetch) failed with exit code '1' Should I just change the checksum locally or what??? Jim A -- ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross ross.bur...@intel.com wrote: cross-localdef-native: | In file included from glibc/locale/programs/locarchive.c:696:0: | glibc/locale/programs/../../intl/l10nflist.c: In function '_nl_normalize_codeset': | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary operator before token ( | glibc/locale/programs/../../intl/l10nflist.c:313:9: error: '_nl_C_locobj_ptr' undeclared (first use in this function) | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared identifier is reported only once for each function it appears in gcc would work with latest tree but I did not run into this error. So wait a while until I get to it. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can two build dir of different yocto version share the same download/ and sstate/ dir?
Hi Qiang, On Monday 02 February 2015 17:26:18 Qiang Yu wrote: I know two build dir of the same yocto version can share download/ and sstate/ dir to speed up build. But what if two build dir of different yocto version, like 1.6 and 1.7? Yes. However, you will probably find you won't get too much benefit from having 1.6 and 1.7 share SSTATEDIR since the signatures will be different for almost everything. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
Hi Khem, On 2 February 2015 at 10:02, Khem Raj raj.k...@gmail.com wrote: I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 ( upcoming ) on a contrib branch ( top 2 patches) its has not got much testing besides x86 qemu thus far. I'm seeing these failures when cherry-picking the top two commits to current poky/master. gcc-cross-initial: | /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c: In function 'void expand_builtin_init_dwarf_reg_sizes(tree)': | /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27: error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode' cross-localdef-native: | In file included from glibc/locale/programs/locarchive.c:696:0: | glibc/locale/programs/../../intl/l10nflist.c: In function '_nl_normalize_codeset': | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary operator before token ( | glibc/locale/programs/../../intl/l10nflist.c:313:9: error: '_nl_C_locobj_ptr' undeclared (first use in this function) | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared identifier is reported only once for each function it appears in Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
Hi Ross Please repull. I did not push from right machine first time. Now it should be good. Thanks for quick turnaround Thanks -Khem On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross ross.bur...@intel.com wrote: Hi Khem, On 2 February 2015 at 10:02, Khem Raj raj.k...@gmail.com wrote: I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 ( upcoming ) on a contrib branch ( top 2 patches) its has not got much testing besides x86 qemu thus far. I'm seeing these failures when cherry-picking the top two commits to current poky/master. gcc-cross-initial: | /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c: In function 'void expand_builtin_init_dwarf_reg_sizes(tree)': | /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27: error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode' cross-localdef-native: | In file included from glibc/locale/programs/locarchive.c:696:0: | glibc/locale/programs/../../intl/l10nflist.c: In function '_nl_normalize_codeset': | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary operator before token ( | glibc/locale/programs/../../intl/l10nflist.c:313:9: error: '_nl_C_locobj_ptr' undeclared (first use in this function) | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared identifier is reported only once for each function it appears in Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-qt5 problem in yocto 1.7
On 02/02/2015 04:27, peterengcomau...@adam.com.au wrote: Alex, I have completely separated daisy and dizzy. all of my daisy stuff goes into ~/poky-1.6 and I clone only daisy branches there such as poky, meta-openembedded, meta-qt5, etc. All of my dizzy stuff goes in ~/poky-1.7 so there is never a mix between them. For dizzy i originally cloned the dizzy meta-qt5 branch and got a lot of do_fetch failures for v5.3.2. I then cloned the master branch of meta-qt5 from an idea from Simon, but still get the same do_fetch failuers but now for v5.4.0. The files are there because I can manually download them, but I cant get the do_fetch to work inside bitbake. So I've successfully built up the latest now, which builds 5.4.0. This all seems to work OK, excepting that I need to modify the qtbase recipe as I mentioned to copy examples across to the image tree if I want qtbase-examples. Not sure why your do_fetch() step is failing with this... Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto-custom kernel build issue
Hi, I want to add my own BSP layer to yocto and also we use our inhouse customizied kernel. I add my BSP layer to yocto using yocto-bsp create command. I give the our curtomized kernel repositary path to the git path while creating the BSP. After successfully creating the BSP layer when I run the bitbake -k core-image-minimal I got the error as follows. Log data follows: | DEBUG: Executing shell function do_kernel_checkout | ERROR: S is not set to the linux source directory. Check | ERROR: the recipe and set S to the proper extracted subdirectory | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_kernel_checkout (log file is located at /home/testuser/poky/build/tmp/work/dhruwa-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798) could you please help for resolving this issue. Thanks and Regards, Raghavendra. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] README: update layer information
Signed-off-by: Armin Kuster akuster...@gmail.com --- README | 7 +++ 1 file changed, 7 insertions(+) diff --git a/README b/README index 71378d9..ef80f2b 100644 --- a/README +++ b/README @@ -24,6 +24,11 @@ This layer depends on: revision: HEAD prio: default + URI: git://git.openembedded.org/meta-openembedded/meta-networking + branch: master + revision: HEAD + prio: default + Adding the security layer to your build @@ -39,6 +44,8 @@ other layers needed. e.g.: /path/to/oe-core/meta \ /path/to/meta-openembedded/meta-oe \ /path/to/meta-openembedded/meta-perl \ +/path/to/meta-openembedded/meta-python \ +/path/to/meta-openembedded/meta-networking \ /path/to/layer/meta-security \ Contents and Help -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross ross.bur...@intel.com wrote: On 2 February 2015 at 18:33, Khem Raj raj.k...@gmail.com wrote: Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have updated the contrib tree which fixes cross-localedef-native compile time issue. So you should be good to go now. Bad news, glibc is now failing: | x86_64-poky-linux-gcc -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap dl-open.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes -fPIC -mno-sse -mno-mmx-I../include -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include -isystem /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include -D_LIBC_REENTRANT -include /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h -DMODULE_NAME=rtld -include ../include/libc-symbols.h -DPIC -DSHARED -o /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os -MD -MP -MF /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt -MT /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os | dl-caller.c:1:0: error: SSE instruction set disabled, using 387 arithmetics [-Werror] | /* Check whether caller comes from the right place. | ^ | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics [-Werror] | /* Load a shared object at runtime, relocate it, and run its initializer. | ^ | cc1: all warnings being treated as errors | cc1: all warnings being treated as errors The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS and for this particular file glibc says -mno-sse -mno-mmx so it defaults to x87 80bit arithmetics. May be we should get a bit milder with optimizations for this case when compiling glibc. Since glibc has its own notion about floating point. I think this issue was there even with older version of glibc for i7 but it was flagged as a warning, glibc 2.21 now uses -Werror by default. Can you confirm that via inspecting 2.20 glibc build logs for this machine ? I have pushed another patch to disable sse for replacing fpu. Please try it out and let me know if it fixed it. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [meta-raspberrypi][PATCH v2] qtbase: Add basic Qt5 building support
Andrei Gherzan writes:
Hello,
On Tue, Jan 27, 2015 at 02:26:55PM +0800, Yen-Chin Lee wrote:
To build raspberrypi with Qt5, we need to add extra QT_CONFIG_FLAGS to
indicate device config.
Signed-off-by: Yen-Chin Lee coldnew...@gmail.com
---
qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
diff --git a/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
b/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
new file mode 100644
index 000..384df9f
--- /dev/null
+++ b/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
@@ -0,0 +1,7 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+
+QT_CONFIG_FLAGS_append_raspberrypi = \
+-device linux-rasp-pi-g++ \
+-device-option CROSS_COMPILE=${TARGET_PREFIX} \
+-I${STAGING_DIR_TARGET}${includedir}/interface/vcos/pthreads \
+
--
1.9.3 (Apple Git-50)
--
___
Openembedded-devel mailing list
openembedded-de...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
First of all please send patches to meta-raspberrypi mailing list (yocto).
Use README for additional information.
For whatever reason I can't bake qtbase:
pulse/pulseaudio.h: No such file or directory
| #include pulse/pulseaudio.h
| ^
| compilation terminated.
| Makefile:206: recipe for target 'pulseaudio.o' failed
| make: *** [pulseaudio.o] Error 1
| PulseAudio disabled.
| PulseAudio support cannot be enabled due to functionality tests!
Any idea why? Didn't you encounter this issue?
Last time I build with qt5 is fine, I think it's due to meta-qt5
upstream recently add function to let user to select alsa/pulseaudio.
I'll re-test this and resend it.
--
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] COMPATIBLE_HOST
Hi Thomas, On 2 February 2015 at 15:17, Moore, Thomas (FtWorth) thomas.moo...@atk.com wrote: I have a binary recipe that is only compatible with x86 and x86_64 systems. I *think* specifying the COMPATIBLE_HOST in my recipe would be a good idea. However, I've been unable to find any documentation, or even a good description, of this variable. Can someone help me out here? The manual has a section in the glossary: http://www.yoctoproject.org/docs/1.7.1/mega-manual/mega-manual.html#var-COMPATIBLE_HOST And yes, this is the idiom. Lots of meta-intel for example uses COMPATIBLE_HOST = '(i.86|x86_64).*-linux'. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] COMPATIBLE_HOST
On 2015-02-02 08:28, Moore, Thomas (FtWorth) wrote: Gary, It seems like COMPATIBLE_MACHINE would have values such as genericx86, qemux86-64, or beaglebone. If that's true, I don't think I want to use COMPATIBLE_MACHINE as my recipes are only dependent on the architecture. You can also use architecture here - basically anything that is an override can be used. Similar to Ross' answer, I think this should work: COMPATIBLE_MACHINE = '(i.86|x86_64)' -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Gary Thomas Sent: Monday, February 02, 2015 9:23 AM To: yocto@yoctoproject.org Subject: Re: [yocto] COMPATIBLE_HOST On 2015-02-02 08:17, Moore, Thomas (FtWorth) wrote: I have a binary recipe that is only compatible with x86 and x86_64 systems. I *think* specifying the COMPATIBLE_HOST in my recipe would be a good idea. However, I've been unable to find any documentation, or even a good description, of this variable. Can someone help me out here? I think you really need to use COMPATIBLE_MACHINE instead. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] COMPATIBLE_HOST
Ross, Perfect. For whatever reason, the manual doesn’t come up when I google COMPATIBLE_HOST. Looks like I’ll need to bookmark the mega manual. Thanks, Thomas From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, February 02, 2015 9:21 AM To: Moore, Thomas (FtWorth) Cc: yocto@yoctoproject.org Subject: Re: [yocto] COMPATIBLE_HOST Hi Thomas, On 2 February 2015 at 15:17, Moore, Thomas (FtWorth) thomas.moo...@atk.commailto:thomas.moo...@atk.com wrote: I have a binary recipe that is only compatible with x86 and x86_64 systems. I *think* specifying the COMPATIBLE_HOST in my recipe would be a good idea. However, I've been unable to find any documentation, or even a good description, of this variable. Can someone help me out here? The manual has a section in the glossary: http://www.yoctoproject.org/docs/1.7.1/mega-manual/mega-manual.html#var-COMPATIBLE_HOST And yes, this is the idiom. Lots of meta-intel for example uses COMPATIBLE_HOST = '(i.86|x86_64).*-linux'. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] COMPATIBLE_HOST
On 2015-02-02 08:33, Richard Purdie wrote: On Mon, 2015-02-02 at 08:32 -0700, Gary Thomas wrote: On 2015-02-02 08:28, Moore, Thomas (FtWorth) wrote: Gary, It seems like COMPATIBLE_MACHINE would have values such as genericx86, qemux86-64, or beaglebone. If that's true, I don't think I want to use COMPATIBLE_MACHINE as my recipes are only dependent on the architecture. You can also use architecture here - basically anything that is an override can be used. Similar to Ross' answer, I think this should work: COMPATIBLE_MACHINE = '(i.86|x86_64)' No, that syntax is for COMPATIBLE_HOST... So how would one write this. We use similar syntax to specify architecture dependencies in some ARM recipes, e.g. COMPATIBLE_MACHINE = ls102xa where ls102xa is an architecture (SOC) override and this allows the recipe only for LS102x targets. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Checksum failure encountered Java
Date: Mon, 2 Feb 2015 11:07:05 +0100 From: maxin.j...@enea.com To: jfaberna...@outlook.com CC: yocto@yoctoproject.org Subject: Re: [yocto] Checksum failure encountered Java Hi Jim, On Sun, Feb 01, 2015 at 10:58:02AM -0500, Jim Abernathy wrote: after I posted this issues, I tried to click on the link at the Oracle site and there is something about accepting a License. I have the LICENSE_FLAGS_WHITELIST += oracle_java which worked on the NUC build. I'm guessing that's not the issue. Since Oracle download webpage has an accept license button, the downloading process is on a best effort basis one. If the download fails for a particular binary, please go to the oracle download webpage and download the tarball. Move that binary to the bitbake download location as mentioned in local.conf file and build again. Sorry for the trouble and I think, we should update the README to reflect this process (again). Please note that the arm binary is pre-built for vfp-hflt (hard-float) and it may have troubles with root-filesystem built with soft-float support. Jim A Best Regards, Maxin thanks, but here's a dumb question for you. Since I'm using a Pandaboard, is it hard-float or soft-float? And are you referring to the oracle binary or the BSP I'm using. Jim A ━━━ From: jfaberna...@outlook.com To: yocto@yoctoproject.org Date: Sun, 1 Feb 2015 10:53:28 -0500 Subject: [yocto] Checksum failure encountered Java I tried to move a build from NUC to Pandaboard and the core-image-sato worked fine, well except the README.HARDWARE for arm didn't mention coping the uImage to /boot. Figured that out easy enough. But when I tried to add oracle-jse-jre that worked fine on NUC got the following errors: WARNING: Checksum failure encountered with download of http:// download.oracle.com/otn/java/ejre/7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz - will attempt other sources if available WARNING: Renaming /work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz to / work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz_bad-checksum_b72400960629e7403c4b579dada2a804 ERROR: Fetcher failure for URL: 'http://download.oracle.com/otn/java/ejre/ 7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz'. Checksum mismatch! File: '/work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz' has md5 checksum b72400960629e7403c4b579dada2a804 when b9b8f598b0a7f49e4d221f16ba25c6c0 was expected File: '/work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz' has sha256 checksum c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779 when ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = b72400960629e7403c4b579dada2a804 SRC_URI[sha256sum] = c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779 Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: Function failed: Fetcher failure for URL: 'http://download.oracle.com/ otn/java/ejre/7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /work/pandaboard/tmp/work/ cortexa9t2hf-vfp-neon-poky-linux-gnueabi/oracle-jse-jre/1.7.0-u60r0/temp/ log.do_fetch.31677 ERROR: Task 231 (/home/jim/poky/meta-oracle-java/recipes-devtools/oracle-java/ oracle-jse-jre_1.7.0.bb, do_fetch) failed with exit code '1' Should I just change the checksum locally or what??? Jim A -- ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] COMPATIBLE_HOST
On 2015-02-02 08:17, Moore, Thomas (FtWorth) wrote: I have a binary recipe that is only compatible with x86 and x86_64 systems. I *think* specifying the COMPATIBLE_HOST in my recipe would be a good idea. However, I've been unable to find any documentation, or even a good description, of this variable. Can someone help me out here? I think you really need to use COMPATIBLE_MACHINE instead. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] COMPATIBLE_HOST
Gary, It seems like COMPATIBLE_MACHINE would have values such as genericx86, qemux86-64, or beaglebone. If that's true, I don't think I want to use COMPATIBLE_MACHINE as my recipes are only dependent on the architecture. Thanks, Thomas -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Gary Thomas Sent: Monday, February 02, 2015 9:23 AM To: yocto@yoctoproject.org Subject: Re: [yocto] COMPATIBLE_HOST On 2015-02-02 08:17, Moore, Thomas (FtWorth) wrote: I have a binary recipe that is only compatible with x86 and x86_64 systems. I *think* specifying the COMPATIBLE_HOST in my recipe would be a good idea. However, I've been unable to find any documentation, or even a good description, of this variable. Can someone help me out here? I think you really need to use COMPATIBLE_MACHINE instead. -- 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] COMPATIBLE_HOST
On Mon, 2015-02-02 at 08:32 -0700, Gary Thomas wrote: On 2015-02-02 08:28, Moore, Thomas (FtWorth) wrote: Gary, It seems like COMPATIBLE_MACHINE would have values such as genericx86, qemux86-64, or beaglebone. If that's true, I don't think I want to use COMPATIBLE_MACHINE as my recipes are only dependent on the architecture. You can also use architecture here - basically anything that is an override can be used. Similar to Ross' answer, I think this should work: COMPATIBLE_MACHINE = '(i.86|x86_64)' No, that syntax is for COMPATIBLE_HOST... Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] COMPATIBLE_HOST
I have a binary recipe that is only compatible with x86 and x86_64 systems. I *think* specifying the COMPATIBLE_HOST in my recipe would be a good idea. However, I've been unable to find any documentation, or even a good description, of this variable. Can someone help me out here? Thanks, Thomas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] layer conf: update to include meta-networking
suricata needs a package in meta-networking
Signed-off-by: Armin Kuster akuster...@gmail.com
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index c5a717b..650e6ed 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,4 +9,4 @@ BBFILE_COLLECTIONS += security
BBFILE_PATTERN_security = ^${LAYERDIR}/
BBFILE_PRIORITY_security = 6
-LAYERDEPENDS_security = openembedded-layer perl-layer
+LAYERDEPENDS_security = openembedded-layer perl-layer networking-layer
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
Khem, If I knew what testing' entailed I would through some time at this. - Armin On 02/02/2015 02:02 AM, Khem Raj wrote: Hi All I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 ( upcoming ) on a contrib branch ( top 2 patches) its has not got much testing besides x86 qemu thus far. http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade I would like to request some help in testing these out in your respective environments and please report any issues you see so we can start sorting them out at earlier and making its way into OE-Core. Thanks for your help -Khem -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need help for custom recipe
Hi Paul,
Actually we do have existing scripts which create RPM's for other platform i.e.
Linux. We would be cross compile the code and want to use the existing scripts
for doing it. As the existing RPM spec contain lot of logic for post install,
upgrade use case etc. So we can use the current infrastructure but it will be a
re-work for us.
So we were thinking to use it.
Thanks,
Abhinav
From: Paul Eggleton [paul.eggle...@linux.intel.com]
Sent: Monday, February 02, 2015 10:11 PM
To: Bipnesh, Abhinav (Abhinav)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Need help for custom recipe
Hi Abhinav,
On Monday 02 February 2015 14:04:49 Bipnesh, Abhinav wrote:
I am trying to write an custom recipe for one of the application. In the
do_install() I am using an external script for creating rpm of the
application. Below is the recipe file which I have written.
SUMMARY = Hello World
DESCRIPTION = A recipe for HelloWorld
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302file:
///\\$%7bCOMMON_LICENSE_DIR%7d\MIT;md5=0835ade698e0bcf8506ecda2f7b4f302
# Upstream names releases after SVN revs
#SRCREV = 100
SRCREV = ${AUTOREV}
PV = r${SRCREV}
DEPENDS = boost util-linux curl
SRC_URI = file://helloworld.c
S = ${WORKDIR}
do_install () {
sh ${WORKDIR}/ build.sh
}
Now as this is a makefile based project. Now when I fire bitbake helloworld
I am able to build the RPM of the package using build.sh file.
But when I try to check these RPM under build_dir/tmp/deploy it is not
found.
My first question is why do you need to create the RPMs in a custom manner like
this? By doing so you are bypassing quite a lot of well-tested logic that we
have written around packaging.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Checksum failure encountered Java
downloading the JRE file from the Oracle site to the working download directory solved my build problem. This image boots and now I'm testing java. So far so good. Since the Pandaboard uses an OMAP4430, I think it's hard-float. Jim A From: jfaberna...@outlook.com To: maxin.j...@enea.com Date: Mon, 2 Feb 2015 09:48:15 -0500 CC: yocto@yoctoproject.org Subject: Re: [yocto] Checksum failure encountered Java Date: Mon, 2 Feb 2015 11:07:05 +0100 From: maxin.j...@enea.com To: jfaberna...@outlook.com CC: yocto@yoctoproject.org Subject: Re: [yocto] Checksum failure encountered Java Hi Jim, On Sun, Feb 01, 2015 at 10:58:02AM -0500, Jim Abernathy wrote: after I posted this issues, I tried to click on the link at the Oracle site and there is something about accepting a License. I have the LICENSE_FLAGS_WHITELIST += oracle_java which worked on the NUC build. I'm guessing that's not the issue. Since Oracle download webpage has an accept license button, the downloading process is on a best effort basis one. If the download fails for a particular binary, please go to the oracle download webpage and download the tarball. Move that binary to the bitbake download location as mentioned in local.conf file and build again. Sorry for the trouble and I think, we should update the README to reflect this process (again). Please note that the arm binary is pre-built for vfp-hflt (hard-float) and it may have troubles with root-filesystem built with soft-float support. Jim A Best Regards, Maxin thanks, but here's a dumb question for you. Since I'm using a Pandaboard, is it hard-float or soft-float? And are you referring to the oracle binary or the BSP I'm using. Jim A ━━━ From: jfaberna...@outlook.com To: yocto@yoctoproject.org Date: Sun, 1 Feb 2015 10:53:28 -0500 Subject: [yocto] Checksum failure encountered Java I tried to move a build from NUC to Pandaboard and the core-image-sato worked fine, well except the README.HARDWARE for arm didn't mention coping the uImage to /boot. Figured that out easy enough. But when I tried to add oracle-jse-jre that worked fine on NUC got the following errors: WARNING: Checksum failure encountered with download of http:// download.oracle.com/otn/java/ejre/7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz - will attempt other sources if available WARNING: Renaming /work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz to / work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz_bad-checksum_b72400960629e7403c4b579dada2a804 ERROR: Fetcher failure for URL: 'http://download.oracle.com/otn/java/ejre/ 7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz'. Checksum mismatch! File: '/work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz' has md5 checksum b72400960629e7403c4b579dada2a804 when b9b8f598b0a7f49e4d221f16ba25c6c0 was expected File: '/work/downloads/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz' has sha256 checksum c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779 when ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = b72400960629e7403c4b579dada2a804 SRC_URI[sha256sum] = c4a64be693e0e27ca95ffe3036c56156e3d75e07f620fd913308eb03cdf86779 Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: Function failed: Fetcher failure for URL: 'http://download.oracle.com/ otn/java/ejre/7u60-b19/ ejre-7u60-fcs-b19-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /work/pandaboard/tmp/work/ cortexa9t2hf-vfp-neon-poky-linux-gnueabi/oracle-jse-jre/1.7.0-u60r0/temp/ log.do_fetch.31677 ERROR: Task 231 (/home/jim/poky/meta-oracle-java/recipes-devtools/oracle-java/ oracle-jse-jre_1.7.0.bb, do_fetch) failed with exit code '1' Should I just change the checksum locally or what??? Jim A -- ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake-whatchanged error
Every time I run the 'bitbake-whatchanged' script, I get an error like this: ERROR: Bitbake's cached basehash does not match the one we just generated (/home/local/poky-cutting-edge/meta-imx6/packages/images/imx6-demo-image.bb.do_rootfs)! ERROR: The mismatched hashes were e48dfde9772b0a567b5327087c9e2d44 and 3c3447f08ef4da61b814bff5fb909bff What causes this and should I be worried? Does it affect the actual results which are shown? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need help for custom recipe
Hi Abhinav,
On Monday 02 February 2015 14:04:49 Bipnesh, Abhinav wrote:
I am trying to write an custom recipe for one of the application. In the
do_install() I am using an external script for creating rpm of the
application. Below is the recipe file which I have written.
SUMMARY = Hello World
DESCRIPTION = A recipe for HelloWorld
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302file:
///\\$%7bCOMMON_LICENSE_DIR%7d\MIT;md5=0835ade698e0bcf8506ecda2f7b4f302
# Upstream names releases after SVN revs
#SRCREV = 100
SRCREV = ${AUTOREV}
PV = r${SRCREV}
DEPENDS = boost util-linux curl
SRC_URI = file://helloworld.c
S = ${WORKDIR}
do_install () {
sh ${WORKDIR}/ build.sh
}
Now as this is a makefile based project. Now when I fire bitbake helloworld
I am able to build the RPM of the package using build.sh file.
But when I try to check these RPM under build_dir/tmp/deploy it is not
found.
My first question is why do you need to create the RPMs in a custom manner like
this? By doing so you are bypassing quite a lot of well-tested logic that we
have written around packaging.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need help for custom recipe
On Monday 02 February 2015 16:46:37 Bipnesh, Abhinav wrote: Paul Eggleton wrote: On Monday 02 February 2015 14:04:49 Bipnesh, Abhinav wrote: I am trying to write an custom recipe for one of the application. In the do_install() I am using an external script for creating rpm of the application. My first question is why do you need to create the RPMs in a custom manner like this? By doing so you are bypassing quite a lot of well-tested logic that we have written around packaging. Actually we do have existing scripts which create RPM's for other platform i.e. Linux. We would be cross compile the code and want to use the existing scripts for doing it. As the existing RPM spec contain lot of logic for post install, upgrade use case etc. So we can use the current infrastructure but it will be a re-work for us. So we were thinking to use it. I'd have to say this is something we don't support. If you want to do this you would need to disable the current packaging tasks and stage the package files yourself, but that's going to take almost as much work as converting over your postinstall scripts to be specified within the recipe. You would also lose all of the package QA checks that we currently run. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] layer conf: update to include meta-networking
On Monday 02 February 2015 07:35:51 Armin Kuster wrote:
suricata needs a package in meta-networking
Signed-off-by: Armin Kuster akuster...@gmail.com
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index c5a717b..650e6ed 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,4 +9,4 @@ BBFILE_COLLECTIONS += security
BBFILE_PATTERN_security = ^${LAYERDIR}/
BBFILE_PRIORITY_security = 6
-LAYERDEPENDS_security = openembedded-layer perl-layer
+LAYERDEPENDS_security = openembedded-layer perl-layer networking-layer
Can you please also update the OE layer index?
http://layers.openembedded.org/layerindex/branch/master/layer/meta-security/
I added meta-perl and meta-oe this morning based on the meta-security README -
the latter isn't represented in your LAYERDEPENDS value though, so all three
places ought to be made consistent with whatever the actual set of
requirements is.
(If people are starting to use LAYERDEPENDS a bit more it might make sense for
us to add some code to the layer index update script to try to update its
dependency list based upon LAYERDEPENDS and BBFILE_COLLECTIONS; up to now it
hasn't seen a huge amount of use hence I hadn't done that.)
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] sstate management
I'm looking into using sstate more and in particular sharing it amongst a number of builds. I have a couple of questions which I didn't find much info about. * The sstate-cache for a given build/target seems to grow without bounds. I have one build which I've been reusing since last November has grown to 62GB. A very similar build which hasn't see quite so many 'bakes' is only 27GB. Is there some maintenance to be done on the sstate-cache? I'm thinking I want to set up a shared cache which might last for a long time and I would like to only keep the bits that are really needed. * The second operational question I have is if I have a shared sstate cache and I make some sort of build, what is the best way (if any) to share any newly created objects so that my other builds can make use of them? I've not actually tried to share any caches yet, so these questions are just based on my rough understanding of the use of sstate. Please feel free to correct me if I've got it [totally] wrong. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate management
On Mon, Feb 2, 2015 at 9:42 AM, Gary Thomas g...@mlbassoc.com wrote: * The sstate-cache for a given build/target seems to grow without bounds. I have one build which I've been reusing since last November has grown to 62GB. A very similar build which hasn't see quite so many 'bakes' is only 27GB. Is there some maintenance to be done on the sstate-cache? I'm thinking I want to set up a shared cache which might last for a long time and I would like to only keep the bits that are really needed. In the past i've either used sstate-cache-management.sh or ensured that SSTATE_DIR is on a mount with atime enabled and just periodically wiped anything that hasn't been accessed in over a week. * The second operational question I have is if I have a shared sstate cache and I make some sort of build, what is the best way (if any) to share any newly created objects so that my other builds can make use of them? I doubt there's a best on that. Personally I either use a shared filesystem path (e.g. nfs) or hook up rsync. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On Feb 2, 2015, at 9:50 AM, Burton, Ross ross.bur...@intel.com wrote: On 2 February 2015 at 17:40, Khem Raj raj.k...@gmail.com mailto:raj.k...@gmail.com wrote: Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std c99 and hence the problem. I have fix for that issue already locally. $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 This is the default gcc in current Debian stable. Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have updated the contrib tree which fixes cross-localedef-native compile time issue. So you should be good to go now. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] layer conf: update to include meta-networking
Paul,
Is the idea to include all layers required including the cascaded ones?
i.e: meta-networking requires mete-python, should I include that one too?
On 02/02/2015 08:31 AM, Paul Eggleton wrote:
On Monday 02 February 2015 07:35:51 Armin Kuster wrote:
suricata needs a package in meta-networking
Signed-off-by: Armin Kuster akuster...@gmail.com
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index c5a717b..650e6ed 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,4 +9,4 @@ BBFILE_COLLECTIONS += security
BBFILE_PATTERN_security = ^${LAYERDIR}/
BBFILE_PRIORITY_security = 6
-LAYERDEPENDS_security = openembedded-layer perl-layer
+LAYERDEPENDS_security = openembedded-layer perl-layer networking-layer
Can you please also update the OE layer index?
Do I do that manually or is it picked up from the README?
- armin
http://layers.openembedded.org/layerindex/branch/master/layer/meta-security/
I added meta-perl and meta-oe this morning based on the meta-security README -
the latter isn't represented in your LAYERDEPENDS value though, so all three
places ought to be made consistent with whatever the actual set of
requirements is.
(If people are starting to use LAYERDEPENDS a bit more it might make sense for
us to add some code to the layer index update script to try to update its
dependency list based upon LAYERDEPENDS and BBFILE_COLLECTIONS; up to now it
hasn't seen a huge amount of use hence I hadn't done that.)
Thanks,
Paul
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] layer conf: update to include meta-networking
On Monday 02 February 2015 10:24:21 akuster808 wrote: On 02/02/2015 08:31 AM, Paul Eggleton wrote: Can you please also update the OE layer index? Do I do that manually or is it picked up from the README? No, it needs to be done manually, I don't have anything to parse a README and extract dependencies at the moment. http://layers.openembedded.org/layerindex/branch/master/layer/meta-securit y/ I added meta-perl and meta-oe this morning based on the meta-security README - the latter isn't represented in your LAYERDEPENDS value though, so all three places ought to be made consistent with whatever the actual set of requirements is. (If people are starting to use LAYERDEPENDS a bit more it might make sense for us to add some code to the layer index update script to try to update its dependency list based upon LAYERDEPENDS and BBFILE_COLLECTIONS; up to now it hasn't seen a huge amount of use hence I hadn't done that.) Is the idea to include all layers required including the cascaded ones? i.e: meta-networking requires mete-python, should I include that one too? No, no need to do that - just the direct dependencies is enough. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake-whatchanged error
Hi Gary, On Monday 02 February 2015 09:33:30 Gary Thomas wrote: Every time I run the 'bitbake-whatchanged' script, I get an error like this: ERROR: Bitbake's cached basehash does not match the one we just generated (/home/local/poky-cutting-edge/meta-imx6/packages/images/imx6-demo-image.bb .do_rootfs)! ERROR: The mismatched hashes were e48dfde9772b0a567b5327087c9e2d44 and 3c3447f08ef4da61b814bff5fb909bff What causes this and should I be worried? Does it affect the actual results which are shown? I don't think you should necessarily be worried, but this is definitely a bug and we should fix it. It affects bitbake -S printdiff as well. If you have a chance it would be great if you could file a bug about it. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake-whatchanged error
On 2015-02-02 11:40, Paul Eggleton wrote: Hi Gary, On Monday 02 February 2015 09:33:30 Gary Thomas wrote: Every time I run the 'bitbake-whatchanged' script, I get an error like this: ERROR: Bitbake's cached basehash does not match the one we just generated (/home/local/poky-cutting-edge/meta-imx6/packages/images/imx6-demo-image.bb .do_rootfs)! ERROR: The mismatched hashes were e48dfde9772b0a567b5327087c9e2d44 and 3c3447f08ef4da61b814bff5fb909bff What causes this and should I be worried? Does it affect the actual results which are shown? I don't think you should necessarily be worried, but this is definitely a bug and we should fix it. It affects bitbake -S printdiff as well. If you have a chance it would be great if you could file a bug about it. Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7274 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On 2 February 2015 at 10:54, Khem Raj raj.k...@gmail.com wrote: On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross ross.bur...@intel.com wrote: cross-localdef-native: | In file included from glibc/locale/programs/locarchive.c:696:0: | glibc/locale/programs/../../intl/l10nflist.c: In function '_nl_normalize_codeset': | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary operator before token ( | glibc/locale/programs/../../intl/l10nflist.c:313:9: error: '_nl_C_locobj_ptr' undeclared (first use in this function) | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared identifier is reported only once for each function it appears in gcc would work with latest tree but I did not run into this error. So wait a while until I get to it. I can confirm that the current branch builds gcc (and everything else in a minimal image) apart from cross-localdef-native, with a long set of errors for me now: | In file included from glibc/locale/programs/locarchive.c:696:0: | glibc/locale/programs/../../intl/l10nflist.c: In function '_nl_normalize_codeset': | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary operator before token ( | glibc/locale/programs/../../intl/l10nflist.c:313:9: error: '_nl_C_locobj_ptr' undeclared (first use in this function) | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared identifier is reported only once for each function it appears in | glibc/locale/programs/locarchive.c: In function 'add_locales_to_archive': | glibc/locale/programs/locarchive.c:1517:7: warning: passing argument 1 of '__xpg_basename' discards 'const' qualifier from pointer target type [enabled by default] | In file included from /data/poky-master/tmp/work/x86_64-linux/cross-localedef-native/2.21-r0/git/localedef/include/string.h:4:0, | from glibc/locale/programs/locarchive.c:34: | /usr/include/libgen.h:35:14: note: expected 'char *' but argument is of type 'const char *' | glibc/locale/programs/ld-ctype.c: In function 'set_class_defaults': | glibc/locale/programs/ld-ctype.c:3012:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3012:7: note: use option -std=c99 or -std=gnu99 to compile your code | glibc/locale/programs/ld-ctype.c:3016:19: error: redefinition of 'cnt' | glibc/locale/programs/ld-ctype.c:3012:19: note: previous definition of 'cnt' was here | glibc/locale/programs/ld-ctype.c:3016:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3034:5: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3038:17: error: redefinition of 'cnt' | glibc/locale/programs/ld-ctype.c:3034:17: note: previous definition of 'cnt' was here | glibc/locale/programs/ld-ctype.c:3038:5: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3250:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3254:19: error: redefinition of 'cnt' | glibc/locale/programs/ld-ctype.c:3250:19: note: previous definition of 'cnt' was here | glibc/locale/programs/ld-ctype.c:3254:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3272:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3276:19: error: redefinition of 'cnt' | glibc/locale/programs/ld-ctype.c:3272:19: note: previous definition of 'cnt' was here | glibc/locale/programs/ld-ctype.c:3276:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3383:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3389:19: error: redefinition of 'cnt' | glibc/locale/programs/ld-ctype.c:3383:19: note: previous definition of 'cnt' was here | glibc/locale/programs/ld-ctype.c:3389:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:3401:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c: In function 'allocate_arrays': | glibc/locale/programs/ld-ctype.c:3887:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:4039:7: error: 'for' loop initial declarations are only allowed in C99 mode | glibc/locale/programs/ld-ctype.c:4062:19: error: redefinition of 'cnt' | glibc/locale/programs/ld-ctype.c:4039:19: note: previous definition of 'cnt' was here | glibc/locale/programs/ld-ctype.c:4062:7: error: 'for' loop initial declarations are only allowed in C99 mode | make: *** [locarchive.o] Error 1 Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate management
On 2 February 2015 at 16:48, Christopher Larson clar...@kergoth.com wrote: Is there some maintenance to be done on the sstate-cache? I'm thinking I want to set up a shared cache which might last for a long time and I would like to only keep the bits that are really needed. In the past i've either used sstate-cache-management.sh or ensured that SSTATE_DIR is on a mount with atime enabled and just periodically wiped anything that hasn't been accessed in over a week. Seconded on this - after doing lots of builds in the last few weeks involving five machines and new eglibc/gcc patches my sstate was 1.2TB. A quick find -atime -delete did the job. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On Feb 2, 2015, at 9:25 AM, Burton, Ross ross.bur...@intel.com wrote: On 2 February 2015 at 10:54, Khem Raj raj.k...@gmail.com mailto:raj.k...@gmail.com wrote: On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross ross.bur...@intel.com mailto:ross.bur...@intel.com wrote: cross-localdef-native: | In file included from glibc/locale/programs/locarchive.c:696:0: | glibc/locale/programs/../../intl/l10nflist.c: In function '_nl_normalize_codeset': | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary operator before token ( | glibc/locale/programs/../../intl/l10nflist.c:313:9: error: '_nl_C_locobj_ptr' undeclared (first use in this function) | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared identifier is reported only once for each function it appears in gcc would work with latest tree but I did not run into this error. So wait a while until I get to it. I can confirm that the current branch builds gcc (and everything else in a minimal image) apart from cross-localdef-native, with a long set of errors for me now: Thanks guys. Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std c99 and hence the problem. I have fix for that issue already locally. I could reproduce it once I passed -std=c89 in CFLAGS. but there is another issue where a new macro IS_IN(lib) is added in glibc 2.21 and is giving me a bit of heartache I will update the branch soon when I have fix for it and then send a notification. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Two Stage Package Recipe
I took a stab at this and found that the only way I could handle this is to split the package up. See interspersed with my original email. The short answer is that I had to split it into three package, each with its own recipe. (I may revisit this down the road using classes such as those that are used for having a single package build for target, build a '-native' for the build host and in some cases, for the SDK). -- Regards, Darcy Darcy Watkins :: Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [P4] dwatk...@sierrawireless.com :: www.sierrawireless.com :: www.inmotiontechnology.com On Sat, 2015-01-24 at 08:56 -0800, Darcy Watkins wrote: Hello, I have a package in my BSP layer, let’s just call it “my-platform”. At present, it builds libraries to implement a HW access API along with command line utilities useful for testing and diagnostics (and using the API from shell scripts). At present, it also uses the host-swig to generate interface libraries for python bindings and java bindings to access the HW API. This means that ‘my-platform’ has to depend both on ‘python’ and on ‘openjdk-7-jre’ to build. The issue that triggered the need is that openjdk-7-jre has been broken due to something that changed in QEMU so I want to be able to build the base package, then a package for the python bindings and then a package for the java bindings (that I can disable until I have the java build back up again). The objective is to have these handled using dependencies based on what images and/or distro layers call up. For example, my-image-full build everythings but my-image-nojava excludes the java components. What I would like to do is to have the default build to the recipe to build it all EXCEPT for the java bindings. So I would want to build all the usual libraries and utilities and have this NOT have dependency on ‘openjdk-7-jre’. I tried to place these into separate PACKAGEs (i.e. separate RPM outputs). That works great, however I was not able to have outside dependencies select these on individual basis. The build seems to be for all or none. It is like I need to be able to have do_compile, do_install etc. phases for multiple items inside the package, with each chain accessible for dependency rules. Then without having to treat it as a different package, I would like to be able to re-invoke the build to build the java bindings. This particular step will need to be dependent on ‘openjdk-7-jre’ without making earlier steps to be dependent on ‘openjdk-7-jre’. Had to make separate packages: my-platform - for base items python-my-platform - for python bindings to the libraries my-platform-java - for java bindings to the libraries The one-to-many relationship from source to generated outputs is handled by all three recipes retrieving common source. I envision that this should result in one RPM output with the first build products, and the second RPM output with the java bindings (addons). I had hoped that this could be handled using a single recipe based on one source retrieval and three generated outputs, but it appears I need to implement it as three recipes. In the end, I will want to be able to have a minimalistic image include and depend on ‘my-package’ without java bindings, and then have a full feature image that includes and depends on the java bindings. Although not as elegant as I hoped, I was able to get this to happen. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
Armin, On 2 February 2015 at 16:41, akuster akus...@mvista.com wrote: If I knew what testing' entailed I would through some time at this. Please build your stuff with this glibc/gcc and check it still works. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need help for custom recipe
Hi, Thanks for providing input. I would need to evaluate the modification required to override such thing. One quick query in the do_install() can we have the check as we do normally in the RPM spec file. I mean to say %file and some logic like if this exist then execute a particular block. A post and prerun section. As what I can understand is that do_install or internally do_package generate its own SPEC file and create RPM. Sorry for ask such thing as I am not able to find a document reference or an example which shows how we can achieve the same. Thanks, Abhinav From: Burton, Ross [ross.bur...@intel.com] Sent: Monday, February 02, 2015 10:44 PM To: Bipnesh, Abhinav (Abhinav) Cc: yocto@yoctoproject.org Subject: Re: [yocto] Need help for custom recipe On 2 February 2015 at 16:54, Paul Eggleton paul.eggle...@linux.intel.commailto:paul.eggle...@linux.intel.com wrote: I'd have to say this is something we don't support. If you want to do this you would need to disable the current packaging tasks and stage the package files yourself, but that's going to take almost as much work as converting over your postinstall scripts to be specified within the recipe. You would also lose all of the package QA checks that we currently run. If you *really* want to do this then you'll probably need a custom do_package to put the RPMs you've generated in the place that bitbake expects them, or maybe a custom do_deploy. At this point you're subverting the system so you'll have to look at the default tasks to work out how they operate and how to replace them. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate management
On Monday 02 February 2015 17:33:23 Burton, Ross wrote: On 2 February 2015 at 16:48, Christopher Larson clar...@kergoth.com wrote: Is there some maintenance to be done on the sstate-cache? I'm thinking I want to set up a shared cache which might last for a long time and I would like to only keep the bits that are really needed. In the past i've either used sstate-cache-management.sh or ensured that SSTATE_DIR is on a mount with atime enabled and just periodically wiped anything that hasn't been accessed in over a week. Seconded on this - after doing lots of builds in the last few weeks involving five machines and new eglibc/gcc patches my sstate was 1.2TB. A quick find -atime -delete did the job. I don't suppose I can talk one or more of you into writing up some documentation for this to add to the manual? (As usual, something raw in the form of a wiki page that Scott can then adapt would be ideal.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate management
You might want to quickly look through http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#shared-state-cache in the ref-manual before supplying raw documentation information. This section is our current discourse on sstate. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Paul Eggleton Sent: Monday, February 02, 2015 9:43 AM To: Burton, Ross; Christopher Larson; Gary Thomas Cc: yocto@yoctoproject.org Subject: Re: [yocto] sstate management On Monday 02 February 2015 17:33:23 Burton, Ross wrote: On 2 February 2015 at 16:48, Christopher Larson clar...@kergoth.com wrote: Is there some maintenance to be done on the sstate-cache? I'm thinking I want to set up a shared cache which might last for a long time and I would like to only keep the bits that are really needed. In the past i've either used sstate-cache-management.sh or ensured that SSTATE_DIR is on a mount with atime enabled and just periodically wiped anything that hasn't been accessed in over a week. Seconded on this - after doing lots of builds in the last few weeks involving five machines and new eglibc/gcc patches my sstate was 1.2TB. A quick find -atime -delete did the job. I don't suppose I can talk one or more of you into writing up some documentation for this to add to the manual? (As usual, something raw in the form of a wiki page that Scott can then adapt would be ideal.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ 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] Need help for custom recipe
On 2 February 2015 at 16:54, Paul Eggleton paul.eggle...@linux.intel.com wrote: I'd have to say this is something we don't support. If you want to do this you would need to disable the current packaging tasks and stage the package files yourself, but that's going to take almost as much work as converting over your postinstall scripts to be specified within the recipe. You would also lose all of the package QA checks that we currently run. If you *really* want to do this then you'll probably need a custom do_package to put the RPMs you've generated in the place that bitbake expects them, or maybe a custom do_deploy. At this point you're subverting the system so you'll have to look at the default tasks to work out how they operate and how to replace them. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-ti/pandaboard
I've noticed a few issues with the pandaboard image that builds. 1. core-image-sato does not have WiFi capability. I think it's missing firmware. 2. core-image-base is missing the linux-firmware. I added: IMAGE_INSTALL_append = linux-firmware. Now I have the necessary firmware to bring up the WiFi. 3. There is some delay cause in booting that affect the ability to have WiFi active after boot. I have to wait a few minutes until I see the error and recovery before doing the ifup wlan0. dmesg | grep wl12 gives me the following output: [0.396392] vwl1271: 1800 mV [ 67.167297] wl12xx: ERROR could not get nvs file ti-connectivity/wl1271-nvs.bin: -2 [ 67.181457] wl12xx: loaded (once I see the message above I can ifup wlan0 which produces this output below and WiFi now is working: [ 135.964355] wl12xx: firmware booted (Rev 6.3.5.0.98) [ 137.979522] wl12xx: Association completed. Jim A -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On Feb 2, 2015, at 9:26 AM, Burton, Ross ross.bur...@intel.com wrote: Armin, On 2 February 2015 at 16:41, akuster akus...@mvista.com mailto:akus...@mvista.com wrote: If I knew what testing' entailed I would through some time at this. Please build your stuff with this glibc/gcc and check it still works. anything helps. apply the patches and see if they apply and parse correctly with your layer combo then second step is compile and build images/sdks as Ross said. Third would be boot and runt the images and workloads which you normally do 4th would be run your tests 5th would be run gcc and glibc unit tests. and repeat same for as many architectures as possible. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade
On 2 February 2015 at 17:40, Khem Raj raj.k...@gmail.com wrote: Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std c99 and hence the problem. I have fix for that issue already locally. $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 This is the default gcc in current Debian stable. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for Yocto-1.8_M2.rc2 now available
Seems automagic email did not happen for the release candidate, I thought I marked it true. http://autobuilder.yoctoproject.org/pub/nightly/20150202-1 Please start testing this as RC2 Thanks -- Sau! Saul Wold Yocto Component Wrangler @ Intel Yocto Project / Poky Build System -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can two build dir of different yocto version share the same download/ and sstate/ dir?
Hi all, I know two build dir of the same yocto version can share download/ and sstate/ dir to speed up build. But what if two build dir of different yocto version, like 1.6 and 1.7? Regards, Qiang -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
