Re: [yocto] fatal: A branch named 'meta-orig' already exists.
On Wed, 1 Apr 2015, Bruce Ashfield wrote: ... snip ... I completely agree .. better to sort this out sooner rather than later, I'm just trying to narrow down on a configuration that allows me to see the problem and poke at the smouldering pile. If git is doing something different now, it won't be hard to fix, but hands on, versus code inspection, is the real trick here. for a quick test, i started a new project on my fedora rawhide system: * latest checkout of poky * core-image-minimal * qemuarm (as opposed to initial qemux86, just to be different) the initial fetch worked fine (taking advantage of numerous tarballs i've collected over the months): $ bitbake -c fetchall core-image-minimal then: $ bitbake linux-yocto which quickly produces the error at the bottom of this note as displayed by bb. i'm baffled ... does the kernel tree have some new, untracked garbage in it that is causing this? the native git is version 2.3.0. rday $ bb log linux-yocto validate_branches DEBUG: Executing shell function do_validate_branches NOTE: Setting branch meta to 9e70b482d3773abf92c9c5850e134cbca1d5651f error: The following untracked working tree files would be removed by checkout: .gitignore .mailmap COPYING CREDITS Documentation/00-INDEX Documentation/ABI/README Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads Documentation/ABI/obsolete/sysfs-bus-usb Documentation/ABI/obsolete/sysfs-class-rfkill Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra Documentation/ABI/removed/devfs Documentation/ABI/removed/dv1394 Documentation/ABI/removed/ip_queue Documentation/ABI/removed/net_dma Documentation/ABI/removed/o2cb Documentation/ABI/removed/raw1394 Documentation/ABI/removed/video1394 Documentation/ABI/stable/firewire-cdev Documentation/ABI/stable/o2cb Documentation/ABI/stable/syscalls Documentation/ABI/stable/sysfs-acpi-pmprofile Documentation/ABI/stable/sysfs-bus-firewire Documentation/ABI/stable/sysfs-bus-usb Documentation/ABI/stable/sysfs-bus-xen-backend Documentation/ABI/stable/sysfs-class-backlight Documentation/ABI/stable/sysfs-class-rfkill Documentation/ABI/stable/sysfs-class-tpm Documentation/ABI/stable/sysfs-class-ubi Documentation/ABI/stable/sysfs-class-udc Documentation/ABI/stable/sysfs-devices-node Documentation/ABI/stable/sysfs-devices-system-cpu Documentation/ABI/stable/sysfs-devices-system-xen_memory Documentation/ABI/stable/sysfs-driver-ib_srp Documentation/ABI/stable/sysfs-driver-qla2xxx Documentation/ABI/stable/sysfs-driver-usb-usbtmc Documentation/ABI/stable/sysfs-driver-w1_ds28e04 Documentation/ABI/stable/sysfs-firmware-efi-vars Documentation/ABI/stable/sysfs-firmware-opal-dump Documentation/ABI/stable/sysfs-firmware-opal-elog Documentation/ABI/stable/sysfs-module Documentation/ABI/stable/sysfs-transport-srp Documentation/ABI/stable/thermal-notification Documentation/ABI/stable/vdso Documentation/ABI/testing/configfs-spear-pcie-gadget Documentation/ABI/testing/configfs-usb-gadget Documentation/ABI/testing/configfs-usb-gadget-acm Documentation/ABI/testing/configfs-usb-gadget-ecm Documentation/ABI/testing/configfs-usb-gadget-eem Documentation/ABI/testing/configfs-usb-gadget-ffs Documentation/ABI/testing/configfs-usb-gadget-hid Documentation/ABI/testing/configfs-usb-gadget-loopback Documentation/ABI/testing/configfs-usb-gadget-mass-storage Documentation/ABI/testing/configfs-usb-gadget-midi Documentation/ABI/testing/configfs-usb-gadget-ncm Documentation/ABI/testing/configfs-usb-gadget-obex Documentation/ABI/testing/configfs-usb-gadget-phonet Documentation/ABI/testing/configfs-usb-gadget-rndis Documentation/ABI/testing/configfs-usb-gadget-serial Documentation/ABI/testing/configfs-usb-gadget-sourcesink Documentation/ABI/testing/configfs-usb-gadget-subset Documentation/ABI/testing/configfs-usb-gadget-uac1 Documentation/ABI/testing/configfs-usb-gadget-uac2 Documentation/ABI/testing/debugfs-driver-genwqe Documentation/ABI/testing/debugfs-ec Documentation/ABI/testing/debugfs-ideapad Documentation/ABI/testing/debugfs-olpc Documentation/ABI/testing/debugfs-pfo-nx-crypto Documentation/ABI/testing/debugfs-pktcdvd Documentation/ABI/testing/dev-kmsg Documentation/ABI/testing/evm Documentation/ABI/testing/ima_policy Documentation/ABI/testing/procfs-diskstats
Re: [yocto] Building crosswalk for armv7
Hi, I do not have too much info about this, but I hope you have already some fixes available from here for meta-crosswalk: https://github.com/crosswalk-project/meta-crosswalk/commit/362674ee6f838aafdaeae5b8bb035615330d243e //Gaurang Shastri On Thu, Apr 2, 2015 at 1:34 PM, Lev Lehn lev.l...@kardex.com wrote: I’m having troubles building the crosswalk-project OE meta-layer for an armv7 target. I followed the short instructions from here: https://www.yoctoproject.org/blogs/jefro/2014/crosswalk-now-available-yocto-project However I’m getting this error in do_compile step from the crosswalk recipe: | /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++ | /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++ So it seems to use -wrong linker -wrong path to libs Any ideas how I can fix this? Thanks in advance, *Lev* -- Kardex Software GmbH Sitz: Wörth a.R., Deutschland Amtsgericht Landau HRB 30060 UST-IDNR. DE 812560748 Geschäftsführer: Rolf Mössner, Jürgen Schnatterer -- ___ 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] Building crosswalk for armv7
I’m having troubles building the crosswalk-project OE meta-layer for an armv7 target. I followed the short instructions from here: https://www.yoctoproject.org/blogs/jefro/2014/crosswalk-now-available-yocto-project However I’m getting this error in do_compile step from the crosswalk recipe: | /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++ | /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++ So it seems to use -wrong linker -wrong path to libs Any ideas how I can fix this? Thanks in advance, Lev Kardex Software GmbH Sitz: Wörth a.R., Deutschland Amtsgericht Landau HRB 30060 UST-IDNR. DE 812560748 Geschäftsführer: Rolf Mössner, Jürgen Schnatterer -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find libraries when building software
__ From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf of Gary Thomas [g...@mlbassoc.com] Sent: Thursday, April 02, 2015 11:58 AM To: yocto@yoctoproject.org Subject: Re: [yocto] How to find libraries when building software On 2015-04-02 11:36, Andy Falanga (afalanga) wrote: HI, Thanks to Gary Thomas' response, I was able to get the python libraries from Boost built. Now, when I'm building my own library, which requires libboost_python, the configure script isn't able to find it. How do I work with these cross compilation environments? What I have is this. I added the line below to local.conf as Gary instructed. PACKAGECONFIG_pn-boost = python I then ran bitbake core-image-minimal This built both python and the full set of boost (include libboost_python). I see this in output_dir/sysroots/zc706-zynq7/usr/lib. (In case it's relevant, this environment was constructed using /opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.) I then use a script that a co-worker wrote (quite simple) which configures the paths accordingly to use the cross compiler toolset. My path is as follows: /home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games In my own library project, I run my configure script with this: ./configure --host=arm-poky-linux-gnueabi All is working quite well except that I run into this error: ... checking for Boost headers version = 1.47.0... yes checking for Boost's header version... 1_56 checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... gcc49 -gcc checking boost/system/error_code.hpp usability... yes checking boost/system/error_code.hpp presence... yes checking for boost/system/error_code.hpp... yes checking for the Boost system library... yes checking boost/filesystem/path.hpp usability... yes checking boost/filesystem/path.hpp presence... yes checking for boost/filesystem/path.hpp... yes checking for the Boost filesystem library... (cached) yes checking boost/python.hpp usability... no checking boost/python.hpp presence... no checking for boost/python.hpp... no configure: error: cannot find boost/python.hpp I can find this file in output_dir/sysroots/zx706-zinq7/usr/include/boost, why can't the configure script? What's wrong with how I've done things? Or, and probably much more beneficial, when I say, --host=arm-poky-linux-gnueabi what does that actually mean? Where are these things installed? Why is it saying that it cannot find the header when I can? The only rational explanation is that it's looking somewhere other than where I am. Thus, I don't understand as much as I should. What should I read in the manual? Another thing to look at is the 'config.log' in your build (for your library recipe). It should tell you more about why it can't find boost/python.hpp I want to ensure I've been clear enough. I fear I didn’t explain well how I'm trying to build my library. (It's a C++ library exposed in python.) I have a standard GNU configure script which I'm trying to use with the cross compiler that was built. I'm not using recipes in bitbake to make this library. Also, I have been reviewing the config.log file. It appears to me that the real problem is that the build cannot find python.h. This is rather strange because the file does exist and it's in .../sysroots/zc706-zynq7/usr/include/python2.7. I would have assumed that the automate macro AM_PATH_PYTHON. At any rate, this does seem to be the problem. Curiously, I haven't yet been able to workaround it by supplying a customized CPPFLAGS= argument. I've tried both CPPFLAGS= and BOOST_PYTHON_CPPFLAGS= to the same effect. Any pointers are most appreciated. Thanks, Andy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing custom python packages
Matthew, Please have a look at the python recipes in http://git.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python Creating your own similar recipe will allow you to add the python package to your built image, or load it an runtime as an rpm/ipk/deb. You could add this recipe to your own layer, if it is custom and not useful to the community. It is possible to run pip on the target (if you added pip to your image, e.g. IMAGE_INSTALL_append = python-pip is in your local.conf). Regards, --Tim On Thu, Apr 2, 2015 at 12:09 PM, Matthew Karas mkarasc...@gmail.com wrote: How do I install a custom python package in yocto? I've tried looking up google but nothing comes up. On my non-target machine I just do pip install package-folder. What do I put in my bb file? Many Thanks -- ___ 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] what is the proper way to build with fedora rawhide/gcc-5.0?
On Tue, 31 Mar 2015, Khem Raj wrote: On Mar 31, 2015, at 12:54 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: i asked about this a few weeks ago, finally getting back to it ... for better or worse, i'm running fedora rawhide, updated to the point where i have gcc-5.0.0: $ gcc --version gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ which causes a number of build issues trying to build for something as simple as qemux86. first, there is a linemarkers issue with gcc-5.0 that i got around by adding to local.conf: CPPFLAGS_append= -P” This should not be required. Can you post the failing package with error details it should be fixed. and there were two native build issues due to gcc-5.0 being far pickier with warnings that i sidestepped with the cheap hack: ASSUME_PROVIDED += elfutils-native ASSUME_PROVIDED += binutils-native” There is 2.25 update available on my contrib tree. http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master should help with binutils. i *think* i mentioned earlier that the first failing package build is ncurses-native: | In file included from /home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/curses.priv.h:283:0, | from ../ncurses/lib_gen.c:19: | _9187.c:835:15: error: expected ')' before 'int' | ../include/curses.h:1594:56: note: in definition of macro 'mouse_trafo' | #define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen) | ^ | gcc -DHAVE_CONFIG_H -I../ncurses -I/home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses -isystem/home/rpjday/oe/builds/qemux86/tmp/sysroots/x86_64-linux/usr/include -D_GNU_SOURCE -DNDEBUG -I. -I../include -I/home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/../include -I/home/rpjday/oe/builds/qemux86/tmp/sysroots/x86_64-linux/usr/include -isystem/home/rpjday/oe/builds/qemux86/tmp/sysroots/x86_64-linux/usr/include -D_GNU_SOURCE -O2 -pipe --param max-inline-insns-single=1200 -fPIC -c /home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/base/lib_isendwin.c -o ../obj_s/lib_isendwin.o | Makefile:1682: recipe for target '../obj_s/lib_gen.o' failed this appears to be related to the issues listed in this post describing a mass rebuild of fedora packages with gcc-5.0.0: https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html particularly this: Main offender this time is probably the gnu11 change that entails different inline semantics, enables some warnings by default, bumps the __STDC_VERSION__, and so on. Hopefully it won't take too long till these packages catch on. Many packages were not prepared for the new major version of GCC. There's also been quite a lot of churn because of the preprocessor now emitting linemarkers in the output when the -P option is not turned on. The C++ compiler now rejects some code that it used to accept. Furthermore, GCC 5 has a batch of new warnings, which, combined with -Werror, caused some additional failures. sure enough, down that page, ncurses and a bunch of other packages are identified as having the issue: these packages failed to build because of the changes in the preprocessor; gcc started to generate line directives to better detect whether a macro tokens come from a system header - see http://gcc.gnu.org/PR60723 The fix is to use the -P option if the code isn't prepared to deal with such directives. i see that your oe-contrib repo has a newer version of binutils, but not of ncurses, although your ncurses SRC_URI is different. anyway, this is just what i've tripped over lately on my rawhide system. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel Panic: /sbin/init not found
Hi Chan Kit, On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote: My Yocto build environment was working perfectly until last week when I got kernel panic caused by missing/sbin/init. When I examined the image, I found that /sbin/init is indeed absent from the root image. To troubleshoot the issue, I tried building a stock Yocto whose target platform is 64-bit machine using a freshly installed Ubuntu 14.04 from another build machine. Despite that, the kernel panic still occurs and that's the main reason I'm writing here; that is to see if anyone else has the same issue. I did not make any change or any customization to local.conf aside from setting MACHINE to 64 bit and adding the following lines which enable multilib: IMAGE_INSTALL = lib32-connman require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = x86 I would be more than happy to provide necessary diagnostic message shall you request so. Let me know if you guys are able to reproduce this issue. What version of the build system are you using? What exact image are you building? What image output type are you trying this with (ext3 / live / etc.)? What is your MACHINE value? Can you attach the manifest file for the image that is broken? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] python3-native problems
I've attempted through the icr channel to install python3 and pip such that
I can install packages and use the standard library.
It didn't look like the python 3 package group was setup. I attempted to
do what khem` suggested to get around the problem.
https://www.yoctoproject.org/irc/%23yocto.2015-04-01.log.html
mkaras: look into build tree of python3 and see what all ipk/rpms it
generated
and add them all to IMAGE_INSTALL
Doing that still produced errors. So I tried out getting pip and python 2
on my target and it worked on the first try.
Adding these to IMAGE_INSTALL - did exactly what I was looking for.
python \
python-pip \
On Wed, Apr 1, 2015 at 11:19 AM, Burton, Ross ross.bur...@intel.com wrote:
On 1 April 2015 at 15:29, Matthew Karas mkarasc...@gmail.com wrote:
DEPENDS = python3 python3-native python3-distribute
RDEPENDS_${PN} = python3 python3-native python3-distribute
RDEPENDS_${PN}-dev = bash python3 python3-native python3-distribute
python3-native is a form of Python 3 that is built and executed on your
build machine, so it makes no sense to have this as a runtime dependency.
The RDEPENDS should just be python3 python3-distribute.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fatal: A branch named 'meta-orig' already exists.
On Wed, 1 Apr 2015, Bruce Ashfield wrote: ... again, snip ... I completely agree .. better to sort this out sooner rather than later, I'm just trying to narrow down on a configuration that allows me to see the problem and poke at the smouldering pile. If git is doing something different now, it won't be hard to fix, but hands on, versus code inspection, is the real trick here. ok, now i'm confused about where i'm getting my kernel source from. with a fresh build for qemux86 and deliberately not using any of my local mirror content, i did: $ bitbake -c fetchall linux-yocto assuming the fetch would take a while due to, you know, git checkout. the first puzzler is that my downloads directory very quickly contained (among other things): -rw-rw-r--. 1 rpjday rpjday 81688872 Feb 8 22:20 linux-3.19.tar.xz should i have expected that? why do i suddenly have what looks like a stock linux-3.19 tarball when git should be used for this? and here's the salient bit from the fetch log file, clearly showing a sizable tarball being downloaded from downloads.yoctoproject.org: / START / DEBUG: For url git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/common-pc,meta;name=machine,meta returning http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz ... cut ... DEBUG: Fetching http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz using command '/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/rpjday/oe/builds/qemux86/downloads 'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz'' DEBUG: Fetcher accessed the network with the command /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/rpjday/oe/builds/qemux86/downloads 'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz' /// END /// that tarball is 927M as you can see here: http://downloads.yoctoproject.org/mirror/sources/ dated mar 24, so that's fairly new and makes me wonder if there's something weird/broken about it. waiting for wget to finish ... ok, done. now try to cuild: $ bitbake linux-yocto hmmm ... and it's already blown by the validate_branches task, so suddenly, no problem. weird. it is entirely possible that, because i was using a local mirror loaded with tarballs, an earlier kernel tarball was being picked up and wasn't compatible with later content. after dropping any reference to my local mirror, validate_branches appears to work. still curious as to the presence of the linux-3.19 xz tarball in my downloads directory. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?
On Tue, 31 Mar 2015, Khem Raj wrote: On Mar 31, 2015, at 12:54 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: i asked about this a few weeks ago, finally getting back to it ... for better or worse, i'm running fedora rawhide, updated to the point where i have gcc-5.0.0: $ gcc --version gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ which causes a number of build issues trying to build for something as simple as qemux86. first, there is a linemarkers issue with gcc-5.0 that i got around by adding to local.conf: CPPFLAGS_append= -P” This should not be required. Can you post the failing package with error details it should be fixed. FYI, your version of ncurses-5,9 with a more upstream SRC_URI appears to solve the problem with building ncurses-native. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto- now available.
A release candidate build for yocto- is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto- Please begin QA on this build as soon as possible. Build hash information: meta-intel : 53eea4f12311b4808b3af9695ac822eea1fc60c2 meta-fsl-arm : bfe01a0ebde407086f4a7710ea165c6beff310d7 meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568 meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 meta-fsl-ppc : 4c8cd553f9de56379e2b6502ceb996521e2d6a20 poky : 33558eacc8a2d3dce3396b9ab2fd0773ac5076bc This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder Email: elizabeth.flana...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Installing custom python packages
How do I install a custom python package in yocto? I've tried looking up google but nothing comes up. On my non-target machine I just do pip install package-folder. What do I put in my bb file? Many Thanks -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Devshell configuration
On 1 April 2015 at 08:59, PIEWALD Georg georg.piew...@frequentis.com wrote: Ideally I would imagine that I can somewhere configure the exact command that is called when I execute bitbake xxx –c devshell. If that's not possible, can I at least change some of the points mentioned above? For most things you said not currently, but classes/devshell.bbclass and classes/terminal.bbclass are where the logic lies, so patches are welcome. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?
On Tue, 31 Mar 2015, Khem Raj wrote: On Mar 31, 2015, at 12:54 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: i asked about this a few weeks ago, finally getting back to it ... for better or worse, i'm running fedora rawhide, updated to the point where i have gcc-5.0.0: $ gcc --version gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ which causes a number of build issues trying to build for something as simple as qemux86. first, there is a linemarkers issue with gcc-5.0 that i got around by adding to local.conf: CPPFLAGS_append= -P” This should not be required. Can you post the failing package with error details it should be fixed. and there were two native build issues due to gcc-5.0 being far pickier with warnings that i sidestepped with the cheap hack: ASSUME_PROVIDED += elfutils-native ASSUME_PROVIDED += binutils-native” There is 2.25 update available on my contrib tree. http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master should help with binutils. ok, i finally have a full build for qemux86/core-image-minimal. things i did: * wiped the old kernel tarball from my local source mirror -- not sure why that fixed the kernel issue but a fresh download seems to have done the trick. * removed the above CPPFLAGS_append line from local.conf * used khem's ncurses recipe * left the two ASSUME_PROVIDED lines where they were, out of sheer laziness since they seem to work. enough excitement for one day ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?
On Thu, Apr 2, 2015 at 6:12 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Tue, 31 Mar 2015, Khem Raj wrote: On Mar 31, 2015, at 12:54 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: i asked about this a few weeks ago, finally getting back to it ... for better or worse, i'm running fedora rawhide, updated to the point where i have gcc-5.0.0: $ gcc --version gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ which causes a number of build issues trying to build for something as simple as qemux86. first, there is a linemarkers issue with gcc-5.0 that i got around by adding to local.conf: CPPFLAGS_append= -P” This should not be required. Can you post the failing package with error details it should be fixed. and there were two native build issues due to gcc-5.0 being far pickier with warnings that i sidestepped with the cheap hack: ASSUME_PROVIDED += elfutils-native ASSUME_PROVIDED += binutils-native” There is 2.25 update available on my contrib tree. http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master should help with binutils. ok, i finally have a full build for qemux86/core-image-minimal. things i did: * wiped the old kernel tarball from my local source mirror -- not sure why that fixed the kernel issue but a fresh download seems to have done the trick. * removed the above CPPFLAGS_append line from local.conf * used khem's ncurses recipe * left the two ASSUME_PROVIDED lines where they were, out of sheer laziness since they seem to work. my branch will have more fixes for packages that are specifically originating from gcc5 work. Some has already been merged some more are to come enough excitement for one day ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto 1.8_M4.rc1 Full Pass test report.
Hello, Here is the Full pass test report for Yocto 1.8_M4.rc1. Below you can view the summary report. The full pass test report is available on the wiki: https://wiki.yoctoproject.org/wiki/WW13_-_2015-03-25_-_Full_Pass_1.8_M4.rc1 including the Distro test results and build performance test. Testing data Test type: Full Pass Release Test Branch: master Build name: 1.8_M4.rc1 poky commit: 8b3d3e7c957ad06c390886487f69aeb8e145da6a Autobuilder images repository: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.8_M4.rc1/ Distributions tested: Ubuntu 14.04 64bit, Fedora 21 64bit, Opensuse 13.2 64bit, CentOS 7 64 bit Test Run Summary Report Testing Summary Report Test RunTest Plan Environment Passed Other issuesFailed Failing bugsBlocked Blocking bugs Complete 3645https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3645 3646https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3646 ADT: master branch Fedora 21 i686 98.5% none1.5% 7536https://bugzilla.yoctoproject.org/show_bug.cgi?id=7536 7545https://bugzilla.yoctoproject.org/show_bug.cgi?id=7545 0.0%none 100.0% 3647https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3647 3648https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3648 ADT: master branch Ubuntu 14.04 x86_64 98.5% none1.5% 7536https://bugzilla.yoctoproject.org/show_bug.cgi?id=7536 7545https://bugzilla.yoctoproject.org/show_bug.cgi?id=7545 0.0%none 100.0% 3651https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3651 3652https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3652 BSP/QEMU: master branch Beaglebone Black98.7% none1.3% 7543https://bugzilla.yoctoproject.org/show_bug.cgi?id=75430.0%none 100.0% 3657https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3657 3658https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3658 BSP/QEMU: master branch EdgeRouter 100.0% none0.0%none0.0%none 100.0% 3632https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3632 3633https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3633 BSP/QEMU: master branch generic-x86 on AtomPC 98.8% none1.2% 7532https://bugzilla.yoctoproject.org/show_bug.cgi?id=75320.0%none 100.0% 3630https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3630 3631https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3631 BSP/QEMU: master branch genericx86-64 on Sugarbay 100.0% none0.0%none 0.0%none100.0% 3659https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3659 3660https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3660 BSP/QEMU: master branch MPC8315e-rdb100.0% none0.0%none0.0%none 100.0% 3653https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3653 3655https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3655 BSP/QEMU: master branch P1022ds 100.0% none0.0%none0.0%none100.0% 3634https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3634 3635https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3635 BSP/QEMU: master branch qemu-x86100.0% none0.0%none0.0%none 100.0% 3638https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3638 3639https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3639 BSP/QEMU: master branch qemuarm 100.0% none0.0%none0.0%none100.0% 3640https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3640 3641https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3641 BSP/QEMU: master branch qemumips100.0% none0.0%none0.0%none 100.0% 3642https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3642 3643https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3643 BSP/QEMU: master branch qemuppc 100.0% 7236https://bugzilla.yoctoproject.org/show_bug.cgi?id=72360.0%none 0.0%none100.0% 3636https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3636 3637https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3637 BSP/QEMU: master branch qemux86-64 100.0% none0.0%none0.0%none 100.0% 3625https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3625 Eclipse Plugin: master branch Fedora 21 x86_6433.3% 7530https://bugzilla.yoctoproject.org/show_bug.cgi?id=75303.0% 5163https://bugzilla.yoctoproject.org/show_bug.cgi?id=5163 7530https://bugzilla.yoctoproject.org/show_bug.cgi?id=7530 63.6% 7530https://bugzilla.yoctoproject.org/show_bug.cgi?id=7530100.0% 3649https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3649 3650https://bugzilla.yoctoproject.org/tr_show_run.cgi?run_id=3650 Meta-yocto: master branch Ubuntu 14.04 x86_64 100.0% 6156https://bugzilla.yoctoproject.org/show_bug.cgi?id=61560.0%none 0.0%none100.0%
[yocto] How to find libraries when building software
HI, Thanks to Gary Thomas' response, I was able to get the python libraries from Boost built. Now, when I'm building my own library, which requires libboost_python, the configure script isn't able to find it. How do I work with these cross compilation environments? What I have is this. I added the line below to local.conf as Gary instructed. PACKAGECONFIG_pn-boost = python I then ran bitbake core-image-minimal This built both python and the full set of boost (include libboost_python). I see this in output_dir/sysroots/zc706-zynq7/usr/lib. (In case it's relevant, this environment was constructed using /opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.) I then use a script that a co-worker wrote (quite simple) which configures the paths accordingly to use the cross compiler toolset. My path is as follows: /home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games In my own library project, I run my configure script with this: ./configure --host=arm-poky-linux-gnueabi All is working quite well except that I run into this error: ... checking for Boost headers version = 1.47.0... yes checking for Boost's header version... 1_56 checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... gcc49 -gcc checking boost/system/error_code.hpp usability... yes checking boost/system/error_code.hpp presence... yes checking for boost/system/error_code.hpp... yes checking for the Boost system library... yes checking boost/filesystem/path.hpp usability... yes checking boost/filesystem/path.hpp presence... yes checking for boost/filesystem/path.hpp... yes checking for the Boost filesystem library... (cached) yes checking boost/python.hpp usability... no checking boost/python.hpp presence... no checking for boost/python.hpp... no configure: error: cannot find boost/python.hpp I can find this file in output_dir/sysroots/zx706-zinq7/usr/include/boost, why can't the configure script? What's wrong with how I've done things? Or, and probably much more beneficial, when I say, --host=arm-poky-linux-gnueabi what does that actually mean? Where are these things installed? Why is it saying that it cannot find the header when I can? The only rational explanation is that it's looking somewhere other than where I am. Thus, I don't understand as much as I should. What should I read in the manual? Andy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find libraries when building software
On 2015-04-02 11:36, Andy Falanga (afalanga) wrote: HI, Thanks to Gary Thomas' response, I was able to get the python libraries from Boost built. Now, when I'm building my own library, which requires libboost_python, the configure script isn't able to find it. How do I work with these cross compilation environments? What I have is this. I added the line below to local.conf as Gary instructed. PACKAGECONFIG_pn-boost = python I then ran bitbake core-image-minimal This built both python and the full set of boost (include libboost_python). I see this in output_dir/sysroots/zc706-zynq7/usr/lib. (In case it's relevant, this environment was constructed using /opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.) I then use a script that a co-worker wrote (quite simple) which configures the paths accordingly to use the cross compiler toolset. My path is as follows: /home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games In my own library project, I run my configure script with this: ./configure --host=arm-poky-linux-gnueabi All is working quite well except that I run into this error: ... checking for Boost headers version = 1.47.0... yes checking for Boost's header version... 1_56 checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... gcc49 -gcc checking boost/system/error_code.hpp usability... yes checking boost/system/error_code.hpp presence... yes checking for boost/system/error_code.hpp... yes checking for the Boost system library... yes checking boost/filesystem/path.hpp usability... yes checking boost/filesystem/path.hpp presence... yes checking for boost/filesystem/path.hpp... yes checking for the Boost filesystem library... (cached) yes checking boost/python.hpp usability... no checking boost/python.hpp presence... no checking for boost/python.hpp... no configure: error: cannot find boost/python.hpp I can find this file in output_dir/sysroots/zx706-zinq7/usr/include/boost, why can't the configure script? What's wrong with how I've done things? Or, and probably much more beneficial, when I say, --host=arm-poky-linux-gnueabi what does that actually mean? Where are these things installed? Why is it saying that it cannot find the header when I can? The only rational explanation is that it's looking somewhere other than where I am. Thus, I don't understand as much as I should. What should I read in the manual? Library dependencies like this are handled by DEPENDS Does your recipe DEPENDS contain boost? e.g. DEPENDS = boost -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find libraries when building software
On 2015-04-02 11:36, Andy Falanga (afalanga) wrote: HI, Thanks to Gary Thomas' response, I was able to get the python libraries from Boost built. Now, when I'm building my own library, which requires libboost_python, the configure script isn't able to find it. How do I work with these cross compilation environments? What I have is this. I added the line below to local.conf as Gary instructed. PACKAGECONFIG_pn-boost = python I then ran bitbake core-image-minimal This built both python and the full set of boost (include libboost_python). I see this in output_dir/sysroots/zc706-zynq7/usr/lib. (In case it's relevant, this environment was constructed using /opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.) I then use a script that a co-worker wrote (quite simple) which configures the paths accordingly to use the cross compiler toolset. My path is as follows: /home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games In my own library project, I run my configure script with this: ./configure --host=arm-poky-linux-gnueabi All is working quite well except that I run into this error: ... checking for Boost headers version = 1.47.0... yes checking for Boost's header version... 1_56 checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... gcc49 -gcc checking boost/system/error_code.hpp usability... yes checking boost/system/error_code.hpp presence... yes checking for boost/system/error_code.hpp... yes checking for the Boost system library... yes checking boost/filesystem/path.hpp usability... yes checking boost/filesystem/path.hpp presence... yes checking for boost/filesystem/path.hpp... yes checking for the Boost filesystem library... (cached) yes checking boost/python.hpp usability... no checking boost/python.hpp presence... no checking for boost/python.hpp... no configure: error: cannot find boost/python.hpp I can find this file in output_dir/sysroots/zx706-zinq7/usr/include/boost, why can't the configure script? What's wrong with how I've done things? Or, and probably much more beneficial, when I say, --host=arm-poky-linux-gnueabi what does that actually mean? Where are these things installed? Why is it saying that it cannot find the header when I can? The only rational explanation is that it's looking somewhere other than where I am. Thus, I don't understand as much as I should. What should I read in the manual? Another thing to look at is the 'config.log' in your build (for your library recipe). It should tell you more about why it can't find boost/python.hpp -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
