**** BEGIN LOGGING AT Fri Jul 12 02:59:58 2013 Jul 12 08:33:12 morning all Jul 12 08:33:59 morning bluelightning Jul 12 08:35:02 hi stefan_schmidt_w Jul 12 08:36:25 morning #oe Jul 12 09:30:15 hi all Jul 12 09:38:00 hi pb_ Jul 12 09:38:03 hi silviof Jul 12 09:41:16 bluelightning: good morning Jul 12 10:00:35 ericben: Hi, can you merge 3 patches from dylan-next in meta-oe it's a while.. Jul 12 14:02:12 hi. anyone knows what 'package_stagefile_shell' refers to? i am seeing that in meta-beagleboard and meta-ti in an area that deals with device tree. i can't find a definition for this function. Jul 12 14:06:40 ndec: that function is part of package staging or shared state functionality Jul 12 14:09:32 isn't oe-classic legacy/cruft? Jul 12 14:09:52 ant_work: mostly yes Jul 12 14:09:59 ant_work: I think some do still use it Jul 12 14:10:35 FWIW, I am preparing the layer index to be able to index OE-Classic, as a reference particularly for recipes that haven't been migrated yet Jul 12 14:10:50 openembedded Jul 12 14:10:54 oops Jul 12 14:13:12 bluelightning: hide well the link anyway Jul 12 14:13:40 ant_work: sure, it'll be prefixed with an alert mentioning how it's legacy stuff :) Jul 12 14:13:50 ;) Jul 12 14:14:29 btw meta-security arrived yesterday: http://layers.openembedded.org/layerindex/layer/meta-security/ Jul 12 14:14:44 hasn't been announced yet, I will poke Saul/Andrei to do that Jul 12 14:14:53 (on the mailing lists) Jul 12 14:15:16 what's meta-security's mission? Jul 12 14:15:42 pb_: I've not been closely involved but I believe just to add a number of security tools we've been missing up to now Jul 12 14:16:05 denix: hmm. what does that mean? Jul 12 14:16:06 ah right, very good Jul 12 14:16:35 ndec: it is in linux.inc Jul 12 14:16:36 ndec: that means it's a remnant from oe-classic days Jul 12 14:16:58 i can see where it's used, i can't see where it's implemented. Jul 12 14:17:26 i am wondering, if i am not mixing master and dylan here. Jul 12 14:17:28 ndec: btw, we are migrating away from linux.inc in meta-ti... Jul 12 14:18:17 ndec: it's not master vs. dylan, it's rather oe-core vs. oe-classic :) Jul 12 14:18:20 denix: we are adding a new BSP layer for a vendor that uses DTC. what's the recommended method to use DT? Jul 12 14:18:31 ndec: see how it was used http://tinyurl.com/o3wnn8v Jul 12 14:18:34 bluelightning: so, it's definitely not used by sstate these days? Jul 12 14:19:06 denix: so, we aren't looking at the right recipe, right? Jul 12 14:19:18 ndec: we use linux-dtb.inc directly from oe-core Jul 12 14:19:42 denix: I'm pretty sure it isn't Jul 12 14:20:04 ndec: generally speaking you should use a linux-yocto kernel to live in peace Jul 12 14:20:25 ant_work: yeah. i know.. we will get there... Jul 12 14:20:46 we start simple , and will get there.. Jul 12 14:21:07 working with a large variety of 'interesting' vendor trees... Jul 12 14:21:25 ant_work: yeah, right... once everyone is building from k.org mainline... :) Jul 12 14:21:41 ndec: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux-ti-staging_3.8.bb Jul 12 14:21:42 ndec: just a couple of days ago fenrig hit same issues on #yocto Jul 12 14:21:57 (package_stagefile_shell) Jul 12 14:21:59 denix: thanks, i found it. Jul 12 14:22:12 ant_work: ah.. i missed that ;_) Jul 12 14:22:31 ndec: like I said, new recipes don't use old linux.inc. I keep it around for some of old recipes we have there... Jul 12 14:22:35 while we talk about dtc... why is it that we use dtc-native instead of using dtc from the kernel tree? Jul 12 14:23:10 denix: we just happened to copy/paste from an old (not working) recipe... that's what happen when you are lazzy Jul 12 14:23:28 ndec: I'm lazy too to clean that mess up :) Jul 12 14:23:48 true. i could be safely lazy if you weren't ;-) Jul 12 14:24:04 denix: what my question on dtc compiler above? Jul 12 14:24:29 ndec: +1 :) Jul 12 14:25:03 ndec: not sure why build own dtc and not use one from kernel Jul 12 14:25:59 for example, the dtc-native in dylan doesn't work well with our recent kernel. Jul 13 02:53:39 okay, time to commit or get off the pot Jul 13 02:54:28 i have a "light" openbox image with no connman, wicd, or network-manager (or systemd for that matter) Jul 13 02:55:05 just old-school init scripts and the default udhcp client Jul 13 02:56:17 the only thing that works cleanly so far, as far as a light-weight gui for wireless, is wifi-radar Jul 13 02:57:01 which depends (by default) on the old dhcpcd package Jul 13 02:59:05 so, would it make any sense to go with dhcpcd ? or forget that and hack wifi-radar to use udhcp? **** ENDING LOGGING AT Sat Jul 13 02:59:58 2013