**** BEGIN LOGGING AT Fri Mar 22 02:59:58 2013 Mar 22 03:03:32 walters: layer priority? Mar 22 03:04:08 walters: maybe you can overlay just the one .bbappend Mar 22 03:41:32 appends are cumulative Mar 22 03:41:37 applied in layer priority order, yes, but cumulative Mar 22 03:41:46 so depends on the content whether it'll be easy to overirde it Mar 22 09:08:37 in case anyone is interested: the quick start guide misses the "chrpath" package in the required software for redhat Mar 22 09:11:28 LetoThe2nd: please file a bug! Mar 22 09:11:42 rburton: where? Mar 22 09:13:24 bugzilla.yoctoproject.org Mar 22 09:19:53 sorry, but i will not register just for that... Mar 22 09:20:25 if it was a wiki i would have instantly fixed it, but thats just overkill imho. Mar 22 09:30:48 morning all Mar 22 09:52:33 I noticed that in YP there is not xinput-calibrator, how do you calibrate an image-sato system? Mar 22 10:01:06 mckoan: that's in meta-oe Mar 22 10:01:43 mckoan: it will be moved to oe-core soonish Mar 22 10:02:33 mckoan: out of curiosity, what touchscreen are you calibrating? Mar 22 10:04:45 i'm missing touchscreen hardware to test this on, which makes integrating it somewhat tricky Mar 22 10:08:21 rburton: ADS7846 Mar 22 10:10:13 rburton: I know it is in meta-oe because it works if I use image-sato with oe-core Mar 22 10:10:40 rburton: do you mean that it will be moved to YP soonish? Mar 22 10:12:35 mckoan: i want to integrate it into oe-core Mar 22 10:13:05 rburton: I'm confused, there is not xinput-calibrator in YP Mar 22 10:13:52 rburton: find meta* -name 'xinput-cal*' Mar 22 10:14:07 yeah, it's in meta-oe. i want to move it to oe-core when i have hw to test it. Mar 22 10:14:18 (or, someone else can send the patch to move it, if they've tested it) Mar 22 10:15:26 so patches welcome! Mar 22 10:18:42 mckoan: YP is not repository Mar 22 10:19:53 rburton, JaMa: I will try adding git://git.openembedded.org/meta-openembedded to my YP Mar 22 10:20:52 mckoan: start by using correct terminology Mar 22 10:21:25 mckoan: and it's the meta-oe subdirectory of that which you would add to your bblayers.conf, FYI Mar 22 10:22:33 JaMa: ok http://www.openembedded.org/wiki/LayerIndex column Layer name ;-) Mar 22 10:22:46 bluelightning: ack, thx Mar 22 10:23:14 mckoan: adding meta-oe does have some unintended side-effects, so be careful. you might find it safer to copy just the calibrator out. Mar 22 10:23:21 mckoan: also key is the "Repo subdir" column Mar 22 10:24:08 bluelightning: ok, BTW correct terminology is quite puzzling though Mar 22 10:25:10 rburton: I tried copying just the calibrator out, but there are dependecies too Mar 22 10:26:06 rburton: I'm finding easier to work under oe-core only rather than YP Mar 22 10:26:49 mckoan: what do you mean by YP? Mar 22 10:26:50 rburton: moreover I dont' understand this needing of redundancy Mar 22 10:27:15 * rburton guesses Poky? Mar 22 10:28:06 rburton: LOL yes $ git clone git://git.yoctoproject.org/poky.git Mar 22 10:28:08 mckoan: the Yocto Project provides releases of poky (incorporating bitbake, oe-core, meta-yocto, and docs) in order to have a single tested release Mar 22 10:28:27 but the components are also separate so that people can use them separately as desired Mar 22 10:28:54 poky is literally just a known good combination of bitbake + oe-core + meta-yocto Mar 22 10:29:00 (and meta-yocto is tiny) Mar 22 10:29:01 well, meta-yocto and meta-yocto-bsp these days Mar 22 10:30:40 true Mar 22 10:31:53 rburton: poky is a combination of bitbake + oe-core + meta-yocto, and with oe-core you mean 'meta' dont'you? Mar 22 10:32:24 meta/ and a few other directories Mar 22 10:33:37 mckoan: we mean the entire contents of oe-core which includes meta/ Mar 22 10:35:49 mckoan: I was talking about "YP" Mar 22 10:45:46 confusion is caused by using the same name for different meanings (meta-oe is a repo subdir but also a directory name) Mar 22 10:46:12 and in some cases the same meaning have different names :-D Mar 22 10:46:48 the big confusion for me is the difference between Poky and oe-core+bitbake is meta-yocto Mar 22 10:46:54 should be meta-poky Mar 22 10:47:29 rburton: that too Mar 22 10:47:42 yes the meta-oe meta-openembedded thing annoys me as well Mar 22 10:48:03 I hope one day we can rename meta-oe to meta-misc or something similar Mar 22 10:48:16 mckoan: just remember that one and you've saved a lot of confusion. the important thing is that you can't download/run or do anything with "yocto" Mar 22 10:48:18 bluelightning: :-D Mar 22 10:48:24 yocto is an umbrella project Mar 22 10:48:28 * rburton starts reciting from his presentation Mar 22 10:48:34 (FYI, I'm still polishing the patchset to move the networking pieces out of meta-oe to meta-openembedded) Mar 22 10:48:41 bluelightning: meta-misc-and-others Mar 22 10:48:42 er to meta-networking I mean Mar 22 10:48:47 gah Mar 22 10:49:31 I'll try doing something with this xinput-calibrator (and related) stuff then Mar 22 10:49:40 thank you all for your precious help Mar 22 10:49:43 mckoan: would be much appreciated :) Mar 22 10:51:51 as happened with "oe-classic" it seems that fate is that I always take care of xinput-calibrator :-D Mar 22 10:53:46 mckoan: hardware and experience, excellent :) Mar 22 10:54:20 rburton: LOL Mar 22 10:55:30 rburton: far more experience with hw than metadata directory organization ;-) Mar 22 11:31:54 newbie question - if i have built core-image-sato for a test, and now want to build it for a different machine - is it enought to change the MACHINE variable? Mar 22 11:32:18 LetoThe2nd: yep Mar 22 11:32:56 and the re-fire bitbake, correct? Mar 22 11:35:02 LetoThe2nd: that's right Mar 22 11:35:14 thanks rburton & bluelightning Mar 22 11:35:46 if the two machines share an architecture then they'll re-use lots of the build results Mar 22 11:36:17 hehe, unfortunately rather not at the moment ;) Mar 22 11:37:02 i'm just once again trying to get some basic grasp of how things work concerning all those yocto components. Mar 22 11:41:08 hm no, it actually seems to reuse a lot of the host stuff indeed. Mar 22 11:43:07 LetoThe2nd: a lot of native stuff isn't target dependent Mar 22 11:43:21 rburton: yeah i grasped that much :) Mar 22 11:43:31 (only the toolchain) Mar 22 11:44:21 on the other hand, that seems like by default, poky builds a *real* lot for the host.. where to dive into that a bit? some recipe-thing i guess? Mar 22 11:45:27 LetoThe2nd: we make minimal assumptions about the host Mar 22 11:45:55 pretty much that you have a compiler and a few tools, then we build the rest. otherwise you'll end up having the wrong compiler version or automake. Mar 22 11:46:12 sure. Mar 22 11:46:13 even with these minimal deps we get breakage from new distros Mar 22 11:47:45 yeah. well i usually use ptxdist which in the end is of course not too different concerning these things, but its the small things that are handled in another way :) Mar 22 11:49:18 LetoThe2nd: feedback on the differences welcome :) Mar 22 11:49:58 rburton: i might feedback once i have enough grasp of both that the feedback might actually be valuable ;) Mar 22 13:19:11 whats the recommended way to fix the tun/tap adresses for runqemu? modify them in runqemu-ifup? Mar 22 13:23:17 respectively setting up bridging to the real net? Mar 22 14:33:11 LetoThe2nd: you mentioned chrpath was missing, which quickstart was that on? Mar 22 14:33:31 LetoThe2nd: I just checked and I can't spot where its missing from :/ Mar 22 14:35:00 LetoThe2nd: you can presetup tun/tap devices which runqemu will use Mar 22 14:35:26 LetoThe2nd: runqemu-gen-taptun Mar 22 15:04:20 any idea why deploy scripts would fail to copy u-boot and x-load binaries to tmp/deploy/images? Sometimes they end there after recompiling some packages but not when compiling from scratch. Mar 22 15:10:54 mcfrisk: what are you building when compiling from scratch? Mar 22 15:13:51 I'm building the image target Mar 22 15:14:31 rootfs and kernel end up in deploy/images, and from logs I see that x-load and u-boot were compiled and deploy called. Mar 22 15:17:00 if that's what it's reporting, I can't imagine how it would not be deploying the files in that case... Mar 22 15:17:20 if it were unable to copy the files for some reason it should be erroring out Mar 22 15:18:19 besides some bug, the only way I can imagine it not doing the copy was if it had already copied the file before and you then deleted it and then built the image without clearing the stamp for x-load or u-boot Mar 22 15:18:33 but it doesn't sound like that's what happened Mar 22 15:18:41 maybe the log.do_deploy for kernel has the uImage and other files but same logs for x-load and u-boot don't show u-boot.bin or MLO binaries. Mar 22 15:20:25 mcfrisk: are you using x-load / u-boot recipes not from OE-Core? Mar 22 15:21:18 mcfrisk: what exactly do you mean by "from scratch"? i.e. how exactly did you clear things out / start fresh? Mar 22 15:22:08 from scratch I mean rm -rf tmp && bitbake ... Mar 22 15:23:08 mcfrisk: ok but you're not deleting sstate-cache ? Mar 22 15:23:12 mcfrisk: lack of 'install -d ${DEPLOY_somethingDIR}' in do_deploy? Mar 22 15:23:22 mcfrisk: (not that you should have to, just checking) Mar 22 15:23:38 no, I'm saving & sharing the sstate Mar 22 15:24:39 mcfrisk: ok, is SSTATE_MIRRORS set or is this build machine only using its own sstate-cache? Mar 22 15:25:06 sharing sstate on one machine Mar 22 15:25:14 ok Mar 22 15:25:42 so one thing to try would be to bitbake -c clean u-boot then bitbake u-boot and see if the file is deployed; if not do the same with -c cleansstate instead Mar 22 15:26:06 bbl, meeting Mar 22 15:31:25 bluelightning_: thanks! cleansstate did the trick. now files are there. Mar 22 17:23:15 halstead: did something just happen to the bugzilla? Mar 22 17:25:19 halstead: DNS disappeared :/ Mar 22 17:27:22 halstead: and back now. Must have been something on my DNS chain breaking :/ **** ENDING LOGGING AT Sat Mar 23 02:59:58 2013