**** BEGIN LOGGING AT Fri Apr 12 02:59:58 2013 Apr 12 03:56:18 hii GM all Apr 12 04:01:34 evenin' Apr 12 06:48:52 hii all. Apr 12 06:50:07 i have a doubt. reagarding creation of rootfs .. how can i control which files to be copied into final rootfs.. like i need only files which are in package-split/${PN} Apr 12 06:54:30 Sj: If your image only install ${PN} then you should only get those files in the rootfs Apr 12 06:55:10 unless that package (or anything else) depends on ${PN}-something Apr 12 06:55:20 erbo: so i need to see image.bb class for that right? Apr 12 06:56:35 I'd start looking at the image recipe. Also bitbake -g yourimage will give you a set of files detailing the dependencies.. I would look into package-depends.dot to see what pulls in the undesired package Apr 12 07:12:27 good morning Apr 12 07:26:07 good morning Apr 12 08:59:50 morning all Apr 12 09:02:40 bluelightning: hi Apr 12 09:02:58 hi mckoan, bluelightning Apr 12 09:06:12 morning all Apr 12 09:08:02 hi mckoan, silvio__, apelete Apr 12 09:08:12 apelete: just merged your patch, sorry for the delay Apr 12 09:12:50 bluelightning: no problem, thanks for merging it Apr 12 09:13:29 hi bluelightning , mckoan , apelete Apr 12 09:14:30 hi silvio__ Apr 12 09:30:50 hi all Apr 12 09:33:15 hi pb_ Apr 12 09:34:04 hi pb Apr 12 09:38:02 hi bluelightning, silvio_ Apr 12 10:04:57 hi Apr 12 10:05:33 is there a reference Makefile-only recipe for oe ? Apr 12 10:09:11 hi afournier1 Apr 12 10:09:27 hi silvio Apr 12 10:11:00 afournier1: there is http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-addpkg-makefile Apr 12 10:11:30 thanks bluelightning Apr 12 10:11:31 afournier1: broadly, you need to ensure all the options get passed in and that the makefile isn't hardcoding anything like the name of the compiler Apr 12 10:11:48 (if it is, you would need to patch that out) Apr 12 10:11:58 i am rewriting the Makefile indeed as everything is hardcoded, Apr 12 10:12:09 but i'd like to make it oe friendly Apr 12 10:12:13 (as much as possible) Apr 12 10:12:41 afournier1: I'm not a makefile expert but I think it should be possible to default values in the makefile but allow overriding them on the make command line Apr 12 10:12:59 not on this one i think Apr 12 10:13:15 when you have g++ instead of $(CXX) for example Apr 12 10:16:38 right, I'm assuming the makefile would use variables Apr 12 13:58:51 I cannnot add a library to my sdk in the "i686" area, someone can give me suggest/help? Apr 12 14:01:58 silvio__: it needs to be -nativesdk to go on the host side of the SDK Apr 12 14:03:44 i need to make a specific recipe? Apr 12 14:04:23 silvio__: or use BBCLASSEXTENDS with the existing recipe (the preferred method) Apr 12 14:04:31 er, BBCLASSEXTEND I meant Apr 12 14:37:06 thanks bluelightning , now i m tring Apr 12 14:41:28 bluelightning, like this: ' BBCLASSEXTEND = "native nativesdk" '? I found it in ncurses Apr 12 14:45:58 silvio__: you only need to add nativesdk for this (if BBCLASSEXTENDS = "native" was already there then just add to that though) Apr 12 14:46:25 argh I mean if BBCLASSEXTEND = "native" was already there then just add to that though Apr 12 14:50:17 bluelightning, ok, thanks, I have still same thing not clear in the sdk creation task(s), could u suggest me some resource to read, that explain it? I cant found any stuff Apr 12 14:54:31 silvio__: I don't think there is anything Apr 12 14:54:39 silvio__: we only have the existing SDK recipes as examples Apr 12 14:58:27 Yes, ok i try to read, but for example i don know how works all, and I try to make clear to me how it works... Apr 12 14:59:27 bluelightning, btw waht is the difference with BBCLASSEXTEND = "multilib:" ? Apr 12 15:00:40 silvio__: that's for handling multilib, e.g. if you want 32-bit libraries on a 64-bit system (to run some prebuilt 32-bit binary) Apr 12 15:01:07 BBCLASSEXTEND is just a generic method for creating a separate variant of a recipe Apr 12 15:02:49 bluelightning, ah ok, clear now, some trouble with "aclocal" now... but i can go on thanks Apr 12 16:22:31 Is qemu-native broken in master ? couldnt any info on the mailing lists... Apr 12 16:22:44 *find* Apr 12 16:38:02 broken in any particular way? Apr 12 16:38:48 i specified the "kernel-image" package in my image for x86 targets but I don't see the kernel image in the resulting filesystem Apr 12 16:42:40 moin Apr 12 16:43:47 ah i think i see what happened, i listed the new x86-specific package group in the wrong place Apr 12 16:44:41 wooo it works now Apr 12 16:45:18 although for some reason it is installing both the kernel built by my recipe and the yocto kernel Apr 12 16:46:12 pb_, it doesn't compile Apr 12 16:46:23 the package doesn't compile Apr 12 16:46:51 jkroon_: maybe pastebin the log file which shows the failure Apr 12 16:49:34 yeah.. well, i thought I wasnt the only one hit by this Apr 12 18:23:11 Do you know why bitbake gets so mad at me ( http://paste.debian.net/249159/ ) when I move SRC_URI = "http://code.call-cc.org/egg-tarballs/${EGG}/${EGG}-${PV}.tar.gz" from a recipe to the class file? Apr 12 18:25:01 mario-goulart: do you have SRCPV used in PV or somewhere in recipe? Apr 12 18:26:07 JaMa: no. No SRCPV anywhere in that layer, according to git grep. Apr 12 18:26:25 The class code is here: http://paste.debian.net/249161/ Apr 12 18:26:40 If I move SRC_URI to a recipe, it works. Apr 12 18:47:33 Compiling qemu-native in OE master gives me alot of of unknown type name 'fdt32_t' Apr 12 19:04:55 jkroon I looked at it Apr 12 19:05:07 and I am bit puzzeld too Apr 12 19:10:47 woglinde, which distro are you on, im using fedora 18 Apr 12 19:13:20 ubuntu 12.10 Apr 12 19:13:26 the header are included right Apr 12 19:13:44 must be something gcc and attribute declaration Apr 12 19:13:48 +with Apr 12 19:13:55 huh Apr 12 19:14:31 or arm gcc and attribute declaration Apr 12 19:14:44 when I put the typedefs directly into fdt.h it works Apr 12 19:16:03 hm okay ppc fails too for devicetree Apr 12 19:19:10 hm I wonder if the kernel headers interfere Apr 12 19:19:16 but does not seem so Apr 12 19:31:54 hm hm Apr 12 19:38:32 ah okay running preprocessor only Apr 12 19:38:38 now lets see whats in Apr 12 19:40:27 hm intressting the typedefs are not it Apr 12 19:41:09 args now I see it Apr 12 19:41:28 the header includes the one from qemu not from the device tree lib Apr 12 19:41:30 damn Apr 12 19:45:34 but I do not understand why the header is there Apr 12 19:49:17 jkronn now I understand it Apr 12 19:49:39 devictree lib changed the types upstream Apr 12 19:50:14 how do i tell Apr 12 19:50:29 ok :-/ Apr 12 19:50:31 erh Apr 12 19:50:43 but they are in the header that qemu exchanges Apr 12 19:50:50 I will try something later Apr 12 19:57:14 woglinde, you know a way to workaround it, disable building qemu-native ? Apr 12 19:57:45 I can set ASSUME_PROVIDED += "qemu-native" in local.conf, but then sanity checker complains Apr 12 19:57:56 And I cant find where to disable the sanity checker Apr 12 20:09:03 jkroon_: why does sanity checker complain? Apr 12 20:09:35 jkroon_: missing qemu-arm? Apr 12 20:09:45 JaMa, yeah Apr 12 20:10:48 hm yes putting the typedefs into the qemu libfdt_env.h fixes it Apr 12 20:11:04 wonder why nobody else stumbled over it Apr 12 20:15:37 jkroon_: doesn't INSANE_SKIP_${PN} = True get you that? Apr 12 20:15:53 hm but I wonder too why jama did not see it Apr 12 20:16:06 disabling the sanity checker i mean... Apr 12 20:16:26 jama can you try bitbake -c cleansstate qemu-native Apr 12 20:16:39 bitbake qemu-native for master Apr 12 20:17:52 mr_science, you mean patching the qemus bb recipe ? id rather avoid that Apr 12 20:20:40 yeah, it would be the second part of your workaround but not a real fix... Apr 12 20:22:34 if I want to modify the PACKAGECONFIG of a package called "foo", how can I do that? add PACKAGECONFIG_foo = "..." to local.conf ? Apr 12 20:22:49 (aside from using .bbappends) Apr 12 20:24:03 that is what you need.. PACKAGECONFIG_foo = '...' Apr 12 20:24:30 jkroon I will cook up a patch Apr 12 20:24:48 but can only send them tomorrow Apr 12 20:24:49 woglinde, thanks Apr 12 20:24:53 ok Apr 12 20:24:55 no worries Apr 12 20:25:06 so it will be included next week Apr 12 20:25:28 and I really wonder nobody notice it this close before release Apr 12 20:31:23 a release is close ? Apr 12 20:35:43 yes Apr 12 20:46:53 * jkroon_ sighs and reverts to an older OE Apr 12 20:49:02 ? Apr 12 20:50:21 I cant get around the qemu thing, ill just revert to an older revision of oecore Apr 12 20:52:04 woglinde: I have qemu-native disabled in my builds and I reported qemu not building on qemuarm about month ago (in bitbake world status thread) Apr 12 20:53:15 woglinde: http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/035373.html Apr 12 20:54:28 hehe okay Apr 12 20:54:32 the fix is easy Apr 12 20:57:02 woglinde, how do you do when you disable it ? Apr 12 20:57:12 I do not disable it Apr 12 20:57:12 oh, that was for JaMa Apr 12 20:57:18 I patched the header Apr 12 20:58:34 jkroon_: see that link I've sent to woglinde Apr 12 20:58:47 woglinde: patch comming? Apr 12 20:59:05 I'll start another world in +- 30 minutes Apr 12 20:59:34 if it's the same issue as target build for qemuarm (sorry I wasn't following what issue you've discussed here) Apr 12 21:03:55 jama no tomorrow Apr 12 21:04:10 I have my git send-email setup on another computer Apr 12 21:07:13 ok Apr 12 23:42:08 dv_: delayed response (going through scrollback), but it's PACKAGECONFIG_pn-foo, not PACKAGECONFIG_foo. it's not *package* specific, it's overriding the recipe value with an override Apr 12 23:44:09 kergoth: ah, thanks. Apr 12 23:44:42 see bitbake -e | grep PACKAGECONFIG= to verify it's being set to what you think it is Apr 12 23:44:43 np Apr 12 23:45:02 i am currently struggling with a weird problem in meta-oe Apr 12 23:45:21 bitbake cannot find yasm, even though it is in the layer, and all the other recipes are found Apr 12 23:46:27 almost certainly a COMPATIBLE_HOST / COMPATIBLE_MACHINE making it not a valid provider for your configuration Apr 12 23:47:01 but I do not see anything like this mentioned in the recipe Apr 12 23:47:36 https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-support/yasm/yasm_1.2.0.bb do you? Apr 12 23:48:29 * kergoth shrugs Apr 12 23:48:48 either the recipe isnt' being caught by bbfiles for some odd reason, or it's not being seen as buildable. check -DDD Apr 12 23:56:02 hmm can I somehow instruct bitbake to rescan all recipes again? Apr 12 23:56:20 rm -rf tmp/cache will force a reparse of everything Apr 12 23:56:34 though its unlikely that's the problem Apr 12 23:56:46 this is safe? I see eglibc stuff there Apr 12 23:56:57 also, I just need this to see anything with -DDD . Apr 12 23:59:38 dv_: you need to keep persistent cache Apr 12 23:59:52 dv_: don't do it if you have PERSISTENT_DIR set to tmp/cache Apr 13 00:00:42 this is very weird. it completely ignores the yasm .bb file! Apr 13 00:00:51 good point, though it depends. if you don't care about your package feeds, it won't matter too much. I'm used to having moved PERSISTENT_DIR Apr 13 00:03:41 in fact, I can put *anything* inside yasm_1.2.0.bb , and bitbake will not notice Apr 13 00:12:44 okay, cleaning up the cache helped after the second try. weird.. **** ENDING LOGGING AT Sat Apr 13 02:59:58 2013