**** BEGIN LOGGING AT Mon Jul 02 02:59:58 2012 Jul 02 07:13:28 i've got /usr/bin/ld: this linker was not configured to use sysroots" Jul 02 07:13:59 I compiled bash-3.1 using meta-toolchain sdk. Jul 02 07:14:45 HOST_CC=gcc passes --sysroot to it's ld, but the ld(host ld) can't accept the option. Jul 02 07:15:24 any idea? Jul 02 07:50:10 bash-3.1/builtins/Makefile.in sets LDFLAGS_FOR_BUILD to LDFLAGS, that was problem, Jul 02 08:15:21 morning all Jul 02 08:30:26 hi Jul 02 08:31:08 bluelightning: can I somehow set in local.conf which UI I want to be used by default? Jul 02 08:31:21 hi hrw Jul 02 08:31:28 as knotty2 is more useful then default one Jul 02 08:31:51 hmm, not sure Jul 02 09:11:22 hello Jul 02 09:12:27 I've been to do a pull request: Jul 02 09:12:27 From: Khem Raj Jul 02 09:12:27 To: openembedded-devel@lists.openembedded.org Jul 02 09:12:27 Date: Sun, 01 Jul 2012 12:04:04 -0700 Jul 02 09:12:30 Subject: Re: [oe] [oe-classic][PATCH 0/1] psplash: convert from svn.o-hand.com to git.yoctoproject.org Jul 02 09:12:34 Jul 02 09:12:37 Apelete Jul 02 09:12:40 Jul 02 09:12:43 Thanks for all your patches. Could you rebase all your patches against Jul 02 09:12:46 2011.03 branch and send a pull request for that maintenance branch since Jul 02 09:12:48 it will be of interest to that branch Jul 02 09:12:52 Jul 02 09:12:58 I'm new to oe and the ml, and not sure how that works Jul 02 09:13:56 checkout 2011.03 branch, apply your changes on top of it (you can merge and rebase your current branch), then push it e.g. to github Jul 02 09:13:57 do I need to have my own branch somewhere on the web for someone to pull from it ? (since I don't have commit access to git.openembedded.org) Jul 02 09:14:24 then create pull request (you can use create-pull-request script from oe-core) and send it to ML Jul 02 09:16:05 ok. so I basically need to have my own repo somewhere, right ? Jul 02 09:25:16 yes Jul 02 09:31:09 thanks for the answers JaMa. I will setup a mirror of oe-classic with the 2011.03 branch and send a pull request to the ml once I have rebased my patches. Jul 02 09:32:09 it's already mirrored on github.. Jul 02 09:32:28 so you can just use "fork" feature there, without the need to upload whole repo (much faster) Jul 02 09:36:28 ok, will look into that Jul 02 09:36:42 hi Jul 02 09:46:28 Hi @hilips Jul 02 09:51:50 I am facing problem " libstdc++6 (>= 4.3.3) * libgcc1 (>= 4.3.3) * libgcc1 (>= 4.3.3) *" while building image with OpenEmbedded using external toolchain on arm board Please help me to sovle this issue ... Jul 02 10:07:31 Does anyone face following issue while building image with external toolchain => "libstdc++6 (>= 4.3.3) * libgcc1 (>= 4.3.3) * libgcc1 (>= 4.3.3) *" Jul 02 10:07:52 Please help me on the same Jul 02 10:41:58 morning all Jul 02 11:13:11 Someone please help:: Jul 02 11:13:31 issue while building image with external toolchain => "libstdc++6 (>= 4.3.3) * libgcc1 (>= 4.3.3) * libgcc1 (>= 4.3.3) *" Jul 02 11:44:22 i have set: IMAGE_LINGUAS = "" Jul 02 11:44:22 GLIBC_GENERATE_LOCALES = "" Jul 02 11:44:22 LIMIT_BUILT_LOCALES = "POSIX" Jul 02 11:44:22 ENABLE_BINARY_LOCALE_GENERATION = "0" Jul 02 11:44:41 why are locales still generated ? I want to turn them off Jul 02 13:24:10 JaMa, problems with opkg.py -- has a reference to subprocess.check_output() which fails with python 2.6. Jul 02 13:24:45 I noticed you've been active on opkg lately, so I thought I'd mention that. Jul 02 13:25:12 (I'd submit a patch but my python foo is far too weak to know how to fix that call; I just reverted back to an older version of opkg) Jul 02 13:29:24 in opkg-utils? Jul 02 13:29:32 yes Jul 02 13:29:59 it was fixed in opkg-make-index http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/commit/?id=423ecd36b4782327c16f516885d1248249c7724a Jul 02 13:30:22 There's another one -- in opkg-utils/opkg.py Jul 02 13:30:23 so similar fix is probably needed for opkg.py, but my python foo is 2.7 :) Jul 02 13:30:29 Ah. Jul 02 13:31:09 please send patch to yocto ML Jul 02 13:31:35 I was goign to copy the other fix, but I noticed the output was required from the sub-process. I guess I'll have to go read up on how python handles sub-processes in order to fix it. it'll be a while... Jul 02 13:55:51 is there any documentation about how to deal with kernel config in current OE? Jul 02 13:56:46 as I have problem with understanding: http://pastebin.com/viSp2hnr Jul 02 13:58:30 there's the yocto kernel documentation which may explain that stuff in more detail, but I haven't really looked at it closely myself Jul 02 13:58:52 thx Jul 02 15:41:12 Do not use Bitbake as root. Jul 02 15:41:17 heh, forgot ;D Jul 02 15:42:06 have a nice rest of day Jul 02 15:42:55 * kergoth chuckles Jul 02 15:54:13 bluelightning: with qt4-x11-free build I got some programs e,g. moc which are built for host and runtrip fails on them have you seen such a problem before ? Jul 02 15:54:56 khem: no, I haven't... Jul 02 15:55:39 hmm ok this is qt 4.7 btw Jul 02 16:37:02 ah I see it now Jul 02 19:59:12 Could someone help me with adding package to oe-core? I've made receipe and it can be build, but when i try ti add it to image (for example core-image-minimal), it fails to build image ( * opkg_install_cmd: Cannot install package mypackage). Jul 02 20:02:27 as i understand, opkg-cl fails to find my package for some reason. opkg-cl looks for packages in build/tmp-eglibc/work/qemux86-oe-linux/micro-base-image-1.0-r0/rootfs//var/lib/opkg/info, but in this dir, there is no files related to my packege Jul 02 20:15:47 Hello, does anyone know of any work done to build OpenEmbedded (Angstrom) behind HTTP proxies that block git? Trying to get proxy the git:// protocol isn't working Jul 02 20:16:24 I've had to try to find http-cloneable git repo's and add ;protocol=http to the end... Is there a better way? Jul 02 20:36:41 I see that OE has its own Python installation in tmp/sysroots/i6860linux. How do I add Python libraries (for building) to that installation? Jul 02 21:08:26 evening all Jul 02 21:17:31 hi pb_ Jul 02 21:19:59 hi bluelightning Jul 02 21:44:48 pingswept, you mean more than just DEPEND+=pyfoo ? Jul 02 21:45:36 mr_science: Maybe not? That would result in pyfoo appearing in /tmp/sysroots/i686-linux/usr/lib/python2.6/ ? Jul 02 21:45:58 i guess i'm not sure... Jul 02 21:46:14 I think you might be right. Jul 02 21:46:35 i would hope a python dep that lives in site-packages would get the same place in the sysroot Jul 02 21:46:39 RDEPENDS would put it on the target. Jul 02 21:47:11 But I'm trying to get it installed for use during the build process. Jul 02 21:47:16 l Jul 02 21:47:24 pingswept: DEPENDS will do that Jul 02 21:48:17 How does bitbake know how to install Python libraries without a script? Or maybe it can't? Jul 02 21:48:39 i.e. I use DEPENDS, but need a .bb for the library? Jul 02 21:51:29 pingswept: python recipes install their libs into the appropriate place in the sysroot. add a dep on the recipe that provides the module you need. done. Jul 02 21:52:36 kergoth: the sysroot is available at build time *and* gets pulled into the rootfs? Jul 02 21:52:48 ? Jul 02 21:52:54 no, you're confused Jul 02 21:52:59 Agreed. Jul 02 21:53:10 Let me try to be more clear. Jul 02 21:53:11 if A depends on B, B's populate_sysroot will be run before A's configure/compile Jul 02 21:53:14 so it can build Jul 02 21:53:23 OK. Jul 02 21:53:30 for packaging, A will emit an ipk, oe will automatically see that it used the module from B, and add a runtime dependency on it Jul 02 21:53:36 thereby ensuring that adding A to a rootfs gets you B as well. Jul 02 21:53:45 this is how it always works, not just for python Jul 02 21:54:21 2 parts still confuse me there. Jul 02 21:55:39 1. In your example, B is used to compile A, right? If B is running on x86, won't it fail on a non-x86 target? Jul 02 21:56:04 eh? Jul 02 21:56:11 i think you're confused about how python modules are built and used Jul 02 21:56:23 if they dont' have C extnesions, there's no "compile" at all, it's irrelevent Jul 02 21:56:31 and either way, building it doesn't involve *running* it Jul 02 21:56:38 Agreed. Jul 02 21:56:45 if you want a module that you need to import and run at build time, then make a -native version of the recipe Jul 02 21:56:53 like you'd do with anything else, python or otherwise Jul 02 21:57:01 Ah, OK, that makes sense. Jul 02 21:57:39 The -native recipes are used on the host at build time. I think that's exactly what I need. Jul 02 21:58:07 thats what native means in this context, indeed Jul 02 21:58:55 For most Python, I could just copy the same code to the target and be fine, but in this case the Python code in question (numpy) has C extensions that will break on the target if compiled for the host. Jul 02 22:00:34 yeah, that's why in general we retain the native vs target in the recipes, even if technically it doesn't affect the output in some cases Jul 02 22:00:40 easier that way Jul 02 22:00:40 heh Jul 02 22:01:20 OK, I think I get it now. Thanks for the explanation. Does there exist a good native recipe to model mine after? Jul 02 22:02:05 just create a non-native recipe obeying typical conventions and add BBCLASSEXTEND = "native" Jul 02 22:02:22 it'll automatically create a native version by parsing it and then parsing the native class Jul 02 22:02:28 there are plenty of examples of this Jul 02 22:02:33 grep around Jul 02 22:02:44 Excellent. I'll grep for BBCLASSEXTEND . . . Thanks. Jul 02 22:02:56 np **** ENDING LOGGING AT Tue Jul 03 02:59:57 2012