**** BEGIN LOGGING AT Fri Aug 02 02:59:59 2013 Aug 02 04:18:14 any body know how to use gcc and other libs which are installed in system? how to setup this? Aug 02 04:18:31 i need to build some module for my system it self.. so i don;t want to build gcc and all stufff again in oe-core Aug 02 04:18:37 any clue on this? Aug 02 05:39:28 hii all Aug 02 05:39:42 i need some urgent help in oe-core !! Aug 02 07:34:45 morning #oe Aug 02 07:38:28 Johny_: oe will use the system compilers to build cross compilers. if you have your own cross compiler then lookup external-toolchain in the docs Aug 02 07:40:03 rburton: gm there Aug 02 07:41:20 ant_work: morning :) Aug 02 07:41:27 is UK so hot that you guys are working overnight? Aug 02 07:43:13 ha Aug 02 07:43:17 it was pretty damn hot yesterday Aug 02 07:43:36 But it already rained this morning and cooled down Aug 02 07:43:41 but i'm actually just letting my machine download stuff whilst i wrestle the kids into cleaning their teeth and getting dressed Aug 02 07:43:49 but yeah, yesterday was a nice summer day Aug 02 07:43:56 yeah just started raining here Aug 02 07:44:05 stefan_schmidt_w: hottest day of the year no less Aug 02 07:44:32 rburton: That why I spent my time after work on a lake doing some wakeboarding :) Aug 02 07:44:50 Nice and refreshing to fall into the water from time to time Aug 02 07:44:50 good plan Aug 02 07:45:06 i'm doing that c25k running plan, glad yesterday wasn't a run day! Aug 02 07:46:35 hm, thunder. so much for a light shower Aug 02 07:47:06 :/ Aug 02 07:47:16 Here it was only 5 minutes of rain Aug 02 07:50:53 morning all Aug 02 07:54:38 rburton: bluelightning: other 45 + 24 patches... he he RP did know the patchstorm was coming Aug 02 07:55:18 :) Aug 02 07:55:27 maybe i'll have another coffee before reviewing this time Aug 02 07:55:38 if you have time pls check also the 51 dma patches in LAKML Aug 02 07:55:43 :p Aug 02 07:56:23 ant_work: that number is about normal ;-) Aug 02 07:56:44 uh oh..I summoned him Aug 02 07:57:21 quick hide! Aug 02 07:57:46 rp: you've been warned about appearing on OE channels before! Aug 02 07:58:40 rburton: I'm not really here... Aug 02 08:00:32 morning all Aug 02 08:02:54 hi Paul Aug 02 08:03:51 ok, now...call of duty for rburton and bluelightning on #yocto. We have a special guest! Aug 02 08:07:37 hii Aug 02 08:07:52 can we use system libraries to build the modules? Aug 02 08:08:04 i mean i'm building my modules for my system it self Aug 02 08:08:54 hi ant_work , hi bluelightning , hi all Aug 02 08:09:23 external tollchain i don;t want to use .. i have installed gcc in my system i need to use it Aug 02 08:10:43 Johny_: certainly; if your recipe is named xyz-native and does "inherit native" or it's called xyz and you add "native" to BBCLASSEXTEND in the recipe, then you can "bitbake xyz-native" and it will build the recipe for the build host Aug 02 08:11:15 ant_work: haha Aug 02 08:12:13 actually my doubt is. when u build any module first it wil build toolchain right? i mean gcc cross initla etc... Aug 02 08:12:38 ok i wil put this in otherway Aug 02 08:13:32 i have some xyz module which needs libGL.so which is in system prefix /usr/lib , as of now i'm using mesa module(which produces this libGL.so) Aug 02 08:13:45 but i don't need to build mesa. i need to take it form libGL.so Aug 02 08:13:55 whihc is in my system Aug 02 08:14:27 if i don't build mesa then it i wil give error while compilation.. unable to find -lGL Aug 02 08:15:08 not only one module i have set of modules which are installed in my machine. i want to use those libraries to build my xyz module Aug 02 08:15:31 i don't know whether i'm perfectly communicating my problem!!!! Aug 02 08:16:01 Johny_: ah, so set the virtual/libgl provider to the recipe that contains your libGL Aug 02 08:16:08 (assuming it also contains the headers and so on) Aug 02 08:16:25 mesa is the default provider, but if you have an alternative then you set that Aug 02 08:16:54 @rburton i don;t want to build any module that produces libGL.so, i need to use the one which is in my system Aug 02 08:16:58 that is my problem!! Aug 02 08:17:45 i was succesfull in using mesa and able to launch my image.. but i need in different way as it is very slow in rendering graphics Aug 02 08:17:45 Johny_: so you're building a "native" package and not a target one? Aug 02 08:18:27 sounds like you'll need to make a recipe for your libGL so it can actaully get installed into the image Aug 02 08:18:50 libGL should not install in the image Aug 02 08:19:05 but othermodules whihc uses that has to link to libGL Aug 02 08:19:27 example qtbase needs ligGL.so when building platofrm plugins Aug 02 08:19:54 so i should use libGL which is in the system.. (i should not build any modules like mesa who give libGL) Aug 02 08:20:03 Johny_: You have to use the headers in sysroot and not the ones on host Aug 02 08:21:08 my doubt is in oe-core we have external tollchain concept, or otherwise it will build compiler before building any thing right? i need OE not to build compilar but i need to make it to use compiler form my host Aug 02 08:21:16 all gcc , libc everything Aug 02 08:21:47 Johny_: I don't understand : are you cross-compiling or not? Aug 02 08:22:27 hmm no i 'm building for the same system that is building it Aug 02 08:22:42 why OE/Yocto then ? Aug 02 08:23:40 hahha good question.. but my project is should be able to build for many targets aswell as for developemtn pupose we are building for same machin Aug 02 08:23:44 Johny_: oe enforces a cross compilation split for all systems on the principle that it produces reliable builds without any host contamination. if you're trying to work around that, maybe you shouldn't use yocto. Aug 02 08:24:13 Johny_: so you'll need to package the libgl properly at some point when host!=target anyway Aug 02 08:24:28 so other targets like for arm, i have done.. and for my host machin also i have built but it is very slow as it is doing softrendering for graphics not hardware rendering Aug 02 08:25:06 rburton, libGL for different targets athere with me. like ready made Aug 02 08:25:45 my doubt is how to setup OE-core to use the compiler which is installed in my system to build my modules Aug 02 08:26:09 i guess you could use the external toolchain system to point at your host compiler Aug 02 08:26:16 but, meh. Aug 02 08:26:29 rburton exaxtly but i don;t knwo how to do!!!! Aug 02 08:26:39 special-casing a particular architecture like that is likely to bite you in the future. Aug 02 08:27:08 Johny_: me neither, sorry. compiling gcc generally only happens once. :) Aug 02 08:27:32 hmm i don;t use my output binarys outside i mean they wil reside in the same system that build them so no problem i guess :-) Aug 02 08:27:58 it is for internal use. to avoid harware costs.. like it works as simulator Aug 02 08:28:15 Johny_: have you already compiled the module with make on your host? does it link well? Aug 02 08:30:00 is it a kernel video driver like Nvidia / ATI ? Aug 02 08:30:21 ant_work no Aug 02 08:30:54 my issue is if i'm able to use some of the system libraries like libGL.so then i can use GPU for my graphics Aug 02 08:30:54 ok, so it's only user space Aug 02 08:31:41 but since oe- can't take any of hte system libraries i'm building module called Mesa to get libGL. so in this way if i launch my image it wil use CPU not GPU for my graphics.. Aug 02 08:31:51 so my oe-build is very slow Aug 02 08:32:37 mesa is the default provider, but if you have an alternative then you set that Aug 02 08:33:19 alternate is to use System library libGL.so is there in my system Aug 02 08:34:02 even if i build any module that gives me libGL, it wil become soft rendering . means CPU wil renderm y graphics.. not GPU Aug 02 08:34:38 using mesa provided libGL i'm succesfull in launching my image but GUI is very slow Aug 02 08:35:36 see http://www.mesa3d.org/faq.html Aug 02 08:36:16 ant_work thank for the link... Aug 02 08:36:44 but my question is not related to mesa.. as i don;t want to build that Aug 02 08:36:58 i need OE core setup to use my system library libGL Aug 02 08:42:14 lured Aug 02 08:42:45 rburton: bluelightning: ^ Aug 02 08:42:51 ant_work: oh man Aug 02 08:43:01 * rburton restrains himself Aug 02 08:43:10 is like fishing salmons Aug 02 08:43:17 ? Aug 02 08:43:27 sry, was OT Aug 02 08:43:55 Johny_: pls tell us CPU and GPU of your host Aug 02 08:44:10 Johny_: the OE model is that nothing from the host is used apart from when building native packages, but you can't make a "native" image. so you're going to be abusing oe to make it work, there's no variable you can just set. Aug 02 08:44:55 rburton!! exaclty.. so do u suggest not to use OE for my case Aug 02 08:46:01 Johny_: i suggest that you let oe build the right GL library for your target Aug 02 08:48:06 rburton i built right library using mesa and is working but the problem is it is very slow as it is doing soft rendering.. i mean using my cpu to render.. Aug 02 08:48:30 if i can use libGL.so which is in my system then i can link to some openGL libraries and can use GPU Aug 02 08:49:13 Johny_: maybe you forgot to install the GPU drivers Aug 02 08:49:57 hey my ubuntu version is running on it :-) Aug 02 08:50:25 well if the GL is doing software rendering it can't find the right drivers Aug 02 08:51:32 when i;m launching my image i'm making one shell and chanign root to my rootfs. Aug 02 08:51:59 so when anything acces /use/lib it is not exactly my host path... it is rootfs/usr/lib Aug 02 08:52:03 so you probably didn't put the GPU drivers in the rootfs Aug 02 08:53:23 hmm GPU driver can i build in oec-core? Aug 02 08:53:26 i'm not sure.. Aug 02 08:54:15 mesa builds them Aug 02 08:55:01 it's really recommended to just let oe build the right GL driver, then you get what you're expecting :) Aug 02 08:58:27 Johny_: can you tell us GPU name or is it a secret? Aug 02 08:59:00 (I guess host is some x86 flavor) Aug 02 09:00:55 yes Aug 02 09:01:01 x86_64 Aug 02 09:01:03 64 bit Aug 02 09:01:44 is there a video card by chance? Aug 02 09:03:10 i don;t knw much about graphics Aug 02 09:03:16 but ATI some thing is there Aug 02 09:04:00 Johny_: yeah, you'll need to know more than that Aug 02 09:04:22 :P Aug 02 09:05:03 but my doubt is not exaclty regarding graphics..!! how to set OE to take some of the system libraries too while building Aug 02 09:05:21 mainly compiler and these graphics realted libraried Aug 02 09:07:20 glxinfo | grep "glx" this command i have executed Aug 02 09:07:21 server glx vendor string: SGI server glx version string: 1.2 server glx extensions: client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: Aug 02 09:07:28 that was output Aug 02 09:07:56 dri it can support radeon i guess Aug 02 09:11:26 Johny_: we don't do that kind of thing, and for a good reason - we want builds to be independent of the build host, so if you build on one host and then another with different hardware, different installed packages or even a different distro, nothing in the output changes Aug 02 09:13:21 Johny_: what you can do with OE is to create some image for x86-64 specifying the right PREFERRED_PROVIDER_virtual/libgl Aug 02 09:13:29 then you could run that on qemu Aug 02 09:13:41 no need to hack on your host Aug 02 09:14:33 qemu also does software rendering!!!! and is slow.. i have qqmu build also for my project :-( Aug 02 09:15:02 now i want to do simulator setup so that i can use GL from my system that is the intenssion Aug 02 09:15:05 ok, then run the x86-image on your host Aug 02 09:15:13 normal build setup was ther.. now changin to OE-core Aug 02 09:15:56 ohhh i can't flash directly !!! some simulatoion need to be done. i can't replace my OS ubuntu.. with this image Aug 02 09:16:57 if rootfs is generated frm oOE-core then it does not have any relationg with system libs right..? that is why some necessary modules i'm building .. like libxcb, mesa etc Aug 02 09:19:15 Hey, I submitted a patch against libc-package.bbclass and until it's merged, I'd like to override the bbclass. in the manual, it's suggested that we can override some of the default behavior of the bbclass. Any pointer or examples? Aug 02 09:23:42 fabo: for this kind of thing I'd suggest just maintaining a branch with your fix in it Aug 02 09:24:14 fabo: there are other options but for this case, this patch will likely be accepted upstream without any issues Aug 02 09:24:44 bluelightning: fair enough. thanks. Aug 02 09:26:50 Johny_: if you package and build the right GL drivers for your hardware into the image, they'll maybe work in a chroot Aug 02 09:27:06 Johny_: taking "stuff" from the host for use in an image isn't something we support or even make easy Aug 02 09:27:14 Hi, am I right to assume that I can only have an RDEPENDS on a package if the recipe that provides that package has been built due to a DEPENDS, as otherwise bitbake won't know how to satisfy the RDEPENDS, as it doesn't know about the resulting package name(s)? Aug 02 09:31:16 @rburton ok... i got your point. but are you sure that if GPU drivers are there in the image, then it wil do hardware rendering? Aug 02 09:32:46 in my system it is using ATI, it can support radeon drivers. i'm going to build this now. and test. but i'm not sure i wil be succesfull !!! Aug 02 09:33:01 Thanks for the Support and your precious time.. :-) Aug 02 09:33:04 Johny_: depends on what your code is doing. you won't be able to just start another X, obviously. Aug 02 09:33:07 thanks for All Aug 02 09:33:25 yes true :-) Aug 02 09:34:16 Earlier i have tried this approach but it becaome little messy .. i got error like Unable to create Shader program.. some thing Aug 02 09:34:48 it was from QT as i'm using libqxcb platform plugin to run applications Aug 02 09:38:35 andre_d: if the RDEPENDS is set within the recipe (or in anonymous python if it needs to be a bit more dynamic) then bitbake will figure out what it needs to build first automatically Aug 02 09:40:20 andre_d: any later than that though e.g. dynamically at packaging time, then you should be adding explicit DEPENDS to cover the dependencies Aug 02 09:51:44 bluelightning: thanks. for the first case, I have noticed it indeed works even if I have RDEPENDS_${PN}= in my recipe, but it doesn't seem to if I have RDEPENDS_-some-package-name=, I still had to add a DEPENDS=. I am trying to figure out why this difference. Aug 02 09:52:32 andre_d: the latter is still within the recipe in which the package is produced, right? Aug 02 09:53:07 it's a kernel module, so there is no explicit PACKAGES= statement or so Aug 02 09:53:55 and no, it's in a different recipe Aug 02 09:57:11 module.bbclass adds lots of packages automatically, based on the names of the .ko. So I guess for the case where the .ko name doesn't correspond to ${PN}, this is too late (as 'some-package-name' is not explicitly mentioned in PACKAGES) Aug 02 09:59:48 why do you fix "bashism" in the scripts? Aug 02 10:00:19 Is this a case for 'any later than that'? Aug 02 10:00:23 I'm not experienced in shell programming but I always thought that the correct way for "if" statement is "if [ "$SOME" == "foo" ];" Aug 02 10:00:43 now Qi Chen provided patch for "if [ "$SOME" = "foo" ];" Aug 02 10:00:46 eren: == is bash-specific Aug 02 10:00:53 posix says = Aug 02 10:00:57 hm Aug 02 10:00:59 eren: that's a bashism - https://wiki.ubuntu.com/DashAsBinSh Aug 02 10:01:01 and "source" as well? Aug 02 10:01:04 yep Aug 02 10:01:08 and putting function before functions Aug 02 10:01:11 posix sh is *mental* Aug 02 10:01:50 okkie, thanks! Aug 02 10:03:02 I guess we need a decent guide on shell programming Aug 02 10:03:31 the trick is not accidently using the bash manual as a sh reference Aug 02 10:03:45 the posix reference is online and easily searchable Aug 02 10:04:09 there's only a few gotchas that people don't know, == source and function are the common ones Aug 02 10:07:33 the guide in ubuntu wiki seems to be ok for the most cases Aug 02 10:45:52 andre_d: sorry, got distracted Aug 02 10:46:43 andre_d: you can't modify the variable values in one recipe from another Aug 02 10:47:21 eren: if the script says #!/bin/sh and then proceeds to use stuff that's specific to bash, that's wrong and breaks on other shells Aug 02 10:47:48 eren: if it uses #!/bin/bash, no problems (assuming you never need to run it on a system that doesn't have bash e.g. a minimal target) Aug 02 11:07:28 Hi. With task-base.bb on denzil, if I want to remove wifi/bt/3g support do I need to modify through an append RDEPENDS_task-base or do I look to make a change else where? Aug 02 11:10:17 OWayne: those items are added dynamically based on DISTRO_FEATURES and MACHINE_FEATURES, so if your platform doesn't have those I'd suggest removing the corresponding features from one or the other variable Aug 02 11:16:20 bluelightning: and the distro config that is used is based off layer priority? Aug 02 11:17:07 OWayne: no, the distro is specified in the DISTRO variable which you normally set in local.conf, and that points to a file in conf/distro/ in any of the layers you have enabled Aug 02 11:17:45 so DISTRO = "mydistro" would be selecting conf/distro/mydistro.conf Aug 02 11:18:04 ah found it Aug 02 11:18:06 and in that file typically you would specify a value for DISTRO_FEATURES Aug 02 11:18:15 assuming you didn't want to take the default Aug 02 11:18:39 OWayne: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution Aug 02 11:18:47 brb Aug 02 11:30:08 bluelightning: got distracted myself, too. I think I was unclear - I am not trying to modify another recipe's variables. I have a recipe: kernel-module-stmfb.bb. Building this results in multiple packages due to multiple .ko and module.bbclass' handling of these, e.g. kernel-module-stmfb, kernel-module-othername, kernel-module-yetanothername. There is no PACKAGES= line in the recipe (because module.bbclass does the packaging for us). I also have RDEPENDS_kerne Aug 02 11:30:08 l-module-othername='i2c-tools' in that recipe. bitbake is failing to create the final image because it can't satisfy the dependency of i2c-tools. Is that expected because it's too late? Aug 02 11:30:22 Ah I see, so for quick tweaks for the purpose of testing I could append my local.conf Aug 02 11:31:04 I'll look to create distro config afterwards. Aug 02 11:46:06 bluelightning: ah, thank you Aug 02 12:25:30 andre_d: no that sounds like it should be working Aug 02 12:25:53 andre_d: assuming you haven't got a typo in the package name in RDEPENDS_packagename Aug 02 12:29:36 hm, OK. No typo though - just adding i2c-tools to DEPENDS fixes the build, and the package (and image) are generated ok. Aug 02 12:32:33 andre_d: hmm, so thinking about it, it's possible that the reason it doesn't work automatically in this example is because the list of PACKAGES isn't defined when the recipe is parsed, that only happens later Aug 02 12:33:01 andre_d: so bitbake has no direct way of looking up the additional RDEPENDS you've added Aug 02 12:33:23 although I can think of a way it could work, perhaps Aug 02 12:36:32 andre_d: for now the workaround should suffice though Aug 02 12:36:53 bluelightning: ok. That would explain why RDEPENDS_${PN}='i2c-tools' works on the other hand. bitbake now knows the during parsing what it needs to know Aug 02 12:37:26 right Aug 02 12:44:48 hi there Aug 02 12:49:13 win2mac: hi Aug 02 12:50:40 i need to use fpga with cyclone iv to program old parallel flash chip with coreboot firmware .. anyone tried that? Aug 02 12:57:50 win2mac: ah, is this a question about the OpenEmbedded project or about embedded development in general? Aug 02 13:01:16 actually that firmware is not for embedded system. i just want to use fpga as programmer because i already have one Aug 02 13:03:09 win2mac: ah ok, so it's not related to OpenEmbedded Aug 02 13:03:26 win2mac: I'd suggest asking in #coreboot perhaps Aug 02 13:03:33 i did Aug 02 13:04:33 they told me they have no experience with fpgas Aug 02 13:06:59 i know there is CFI interface on FPGA Aug 02 20:17:41 Question for the OE experts. I have kernel-modules as an extra image in my local.conf. When I run it, on the do_rootfs step, I get the following error "* satisfy_dependencies_for: Cannot satisfy the following dependencies for kernel-modules:" Aug 02 20:18:34 Then it lists several modules (such as kernel-module-krng, kernel-module-tunnel4, kernel-module-remoteproc). In fact, the modules listed are all the modules in tmp-eglibc/deploy/images/modules-zc706.tgz **** ENDING LOGGING AT Sat Aug 03 03:00:00 2013