**** BEGIN LOGGING AT Sat Jul 21 02:59:58 2012 Jul 21 13:21:07 hi, with BBCLASSEXTEND = "native" : is there a simple way to have a do_compile_prepend() which willonly be used for the target build and not the native one ? Jul 21 13:22:42 seems using virtclass-cross could solve this issue Jul 21 13:40:02 ericben,yess there is Jul 21 13:40:08 hi GNUtoo Jul 21 13:40:09 ericben, usually they use overrides Jul 21 13:40:18 virtclass-cross doens't work Jul 21 13:40:20 like virtclass native or something like that Jul 21 13:40:49 yes but in the present case I wan't to have a doc_compile_prepend *only* for crossc ompilation Jul 21 13:40:57 ok Jul 21 13:41:20 maybe _virtclass-native() { : } Jul 21 13:41:23 or for exemple to append something to SRC_URI only for cross compulation Jul 21 13:41:28 ok Jul 21 13:41:56 I'll look where the overrrides are but I think they are in distros Jul 21 13:42:07 and you use no distro if I remember well Jul 21 13:42:23 oe-core's defautl distro Jul 21 13:42:55 ok Jul 21 13:43:35 hmmm Jul 21 13:44:10 I'll grep Jul 21 13:46:13 I'll PM you btw Jul 21 13:48:07 openembedded-core/meta/classes/useradd.bbclass:USERADDSETSCENEDEPS_virtclass-cross = "" <- virtclass-cross seem valid tough Jul 21 14:40:30 ericben: with recent versions you can use _class-target Jul 21 14:49:44 bluelightning: hi. thanks, virtclass-cross is not working. I assume _class-target is not available on denzil ? Jul 21 14:50:07 hmm, let me check Jul 21 14:51:37 ericben: no, it seems not I'm afraid Jul 21 14:51:45 a quick grep confirm that Jul 21 14:52:09 the alternative way is to set a variable and then for virtclass_native override it to be "" Jul 21 14:52:16 er, virtclass-native Jul 21 14:52:37 bluelightning: does taht work for a do_compile_prepend ? Jul 21 14:52:55 or I can use the variable inside the do_compile_prepend in fact Jul 21 14:52:56 ah, no, it won't really :/ Jul 21 14:53:03 well yes you could do that :) Jul 21 14:53:13 a little bit hacky but functional Jul 21 15:01:46 bluelightning: thanks that works. still a few tests to run and I'll post an apache2 recipe for meta-oe :-) Jul 21 15:06:17 ericben: ah, I've already been working on that... Jul 21 15:06:35 ericben: I sent out an email a few weeks ago about creating a meta-webserver layer Jul 21 15:06:44 I have a working apache2 recipe already Jul 21 15:07:04 yes but I didn't saw any recipe ;-) I also have one working here (tested with php-cgi) Jul 21 15:07:14 as well as modphp Jul 21 15:07:23 your may be cleaner as I started from the oe-classic 's one Jul 21 15:07:38 so did I Jul 21 15:07:49 oh well I guess we can merge them at some point soon Jul 21 15:08:03 hopefully I can publish the meta-webserver layer next week Jul 21 15:08:14 ok, I'll post it and you will choose. Will meta-webserver be in meta-oe ? Jul 21 15:08:18 includes working modphp, and xdebug as well Jul 21 15:08:26 not sure but it looks that way Jul 21 15:08:45 in fact I needed it for a customer using only php-cgi so I didn't bother with mod-* Jul 21 15:09:26 hmm, unfortunate timing I guess... Jul 21 15:09:34 and the previosu problem I have (virtclass-native vs cross compilation) was to merge apache2-native and apache2 in one recipe Jul 21 15:10:11 is your recipe for apache 2.4 or 2.2 ? Jul 21 15:17:54 ericben: 2.4 Jul 21 15:19:48 ericben: I have to go now but let's try to get this sorted out... if it's OK I'd like to get these recipes in a separate layer first rather than pushing to meta-oe and then moving them Jul 21 15:20:18 I'll have some time to work on it on monday Jul 21 15:20:22 bbl Jul 21 15:41:59 So I can't figure out why my kernel config doesn't seem to be propagated to the deployed kernel. Jul 21 15:43:12 I've set everything properly in the defconfig in sources for the recipe, it is getting propagated to tmp/work/ and is reflected in menuconfig Jul 21 15:44:16 compile happens w/o problems, etc but hen with I boot and zcat /proc/config.gz i find they aren not set Jul 21 16:50:18 So I've done some more digging and there are a few more copies of the kernel config floating around in the work directory Jul 21 16:53:20 in /tmp/work/foo there are at least 4 configs Jul 21 16:53:23 ./linux-mainline-3.2.18-r121b/package/boot/config-3.2.18 Jul 21 16:53:24 ./linux-mainline-3.2.18-r121b/packages-split/kernel-dev/boot/config-3.2.18 Jul 21 16:53:25 ./linux-mainline-3.2.18-r121b/defconfig Jul 21 16:53:26 ./linux-mainline-3.2.18-r121b/git/.config Jul 21 16:55:42 and the first two don't reflect the changes I made to the second two. Correct me if I'm wrong, but I gather OE copies the defcofin in the kernel recipe from sources (in my case meta-ti's linux-mainline config) to defconfig in build Jul 21 16:56:22 and .config is generated from defconfig during the configure stage Jul 21 16:56:55 but where do the first two fit into this? Jul 21 16:57:51 Or is this something I should bug the guys over in #angstrom about? Jul 21 17:29:46 Ugh, the first two are automatically generated but something Jul 21 19:17:07 so when I do bitbake virtual/kernel -f why doesn't bitbake rebuild the kernel? Jul 21 19:18:49 Doing -c clean first removes the kernel from tmp/deploy/.../images/, Jul 21 19:19:24 but executing bitbake for the kernel doesn't actually recompile anything Jul 21 19:19:36 spacecolonyone, -c cleansstate Jul 21 19:20:37 GNUtoo: task do_cleanstate does not exist Jul 21 19:21:21 you're using oe-classic? Jul 21 19:21:26 cleansstate Jul 21 19:21:28 not cleanstate Jul 21 19:21:32 with 2 s Jul 21 19:21:47 doh Jul 21 19:23:06 so is it: clean removes X, clean all removes everything (causing redownload of sources), and cleans state does something in between? Jul 21 19:27:36 yes Jul 21 19:27:51 it does clean + removes the sstate Jul 21 19:28:11 cleanall does cleansstate + remove download Jul 21 19:28:17 was this in the manual and i missed it? Jul 21 19:28:23 no idea Jul 21 19:28:29 :) Jul 21 19:28:50 what constitutes the sstate? Jul 21 20:21:37 GNUtoo: that actually fixed the other problem I was having as well! Your tip fixed two days worth of consternation, Thanks! Jul 21 20:22:06 np Jul 21 21:42:50 hello Jul 21 21:45:24 as an oe beginer, i am trying to make my own distro (mydistro) using the already present machine (qemux86), when everything is built, bitbakes runs the task do_qemuimagetest and tells me this: ERROR: Function failed: No scenario list file named /home/admin/workspaces/oe/openembedded-core/scripts/qemuimage-tests/scenario/qemux86/mydistro found. Jul 21 21:45:40 i would like to know how can i overlay this behavior in my meta Jul 21 21:45:47 suggestions ? **** ENDING LOGGING AT Sun Jul 22 02:59:59 2012