**** BEGIN LOGGING AT Mon Jun 13 02:59:57 2011 Jun 13 08:58:33 morning all Jun 13 15:03:21 Morning all Jun 13 15:05:28 hi sgw Jun 13 15:13:23 what was the workaround for the git-native, perl native thing .. I recall something about it, but can't find the details. Jun 13 15:14:31 zeddii: I think this is the automake/autoconf issue? Jun 13 15:16:14 this all built fine on friday, now I'm getting a perl interpreter failure (not existing), so looks like a dependency. I'm manually building it now. Jun 13 15:17:27 hi sgw Jun 13 15:17:28 zeddii: right, but the failure is automake-native (really) looking for perl Jun 13 15:17:46 RP__: afternoon to you. Jun 13 15:17:54 sgw: Am I meant to be taking anything from your RFC or not? Jun 13 15:18:04 aha! Jun 13 15:18:24 sgw, and the workaround is to force build perl-native I'll assume (which I'm doing now) Jun 13 15:18:54 zeddii: so automake-native and autoconf-native need to be rebuilt, they probably needed a PR bump after that perl-native change (or something), nothing actaully changed in their recipes. Jun 13 15:19:03 argh. yes. Jun 13 15:19:09 I just hit it again. Jun 13 15:19:26 zeddii: workaround it to force autoconf-native and automake-native to rebuild. Jun 13 15:19:38 * zeddii lays the smack-down on them Jun 13 15:22:56 RP__: regarding RFC, wanted to see if there were any objections or issues from them. you could grab them now (maybe minus gconf-dbus, I need to figure out what to do with that one, since it has a bad SRC_URI otherwise). Jun 13 15:28:29 sgw: ok, I was just wondering which bits were RFC in that context Jun 13 15:41:22 RP__: any progress on the meta-toolchain issue? Bug #1160? Jun 13 15:47:11 Good Morning All ! Jun 13 16:09:08 morning all Jun 13 16:39:23 what's the recommended method for dealing with changes in poky/master? Do we trawl through the log and try to figure out which packages might be affected and rebuild those, or if we simply rerun a build will it figure out what needs updating...? Jun 13 16:43:02 jefferai, it should figure it out Jun 13 16:43:10 if it doesn't it's a bug Jun 13 16:43:48 cool, thanks Jun 13 16:51:43 jefferai: FYI at the moment bitbake needs a hint in the form of PR or PV increasing to know when to rebuild something, so as a matter of course if we update a recipe and PV isn't changing we bump up PR by one Jun 13 16:52:15 in future we will be detecting changes and effectively managing the PR value automatically Jun 13 16:55:25 RP__: ping Jun 13 17:26:49 sgw: I have some patches for the meta-toolchain issue Jun 13 17:28:53 RP__: Yeah, I saw that, I am pulling patches together to run a test on stuff. Jun 13 18:24:07 meh -- after updating master and then re-running bitbake core-image-sato, I get Jun 13 18:24:09 | /home/jmitchell/yocto/build/tmp/work/i686-linux/git-native-1.7.5.1-r1/temp/run.do_configure.20540: /home/jmitchell/yocto/build/tmp/sysroots/i686-linux/usr/bin/automake: /home/jmitchell/yocto/build/tmp/sysroots/i686-linux/usr/bin/perl: bad interpreter: No such file or directory Jun 13 18:24:33 I built all packages off master at the end of last week, so it wasn't a huge upgrade Jun 13 18:28:02 meta-intel anybody ? Jun 13 18:28:14 meta-n450/conf/machine/n450.conf:require conf/machine/atom-pc.conf Jun 13 18:28:28 and there is no atom-pc.conf anywhere in meta-intel Jun 13 18:28:48 where is it supposed to some from Jun 13 18:58:11 does Dexuan Cui hang around here? Jun 13 21:12:39 khem, it comes from meta-yocto Jun 13 21:13:13 jefferai, not sure but he's based in China so it's pretty early for him Jun 13 21:13:17 I guessed Jun 13 21:13:29 but meta-intel is a machine layer which other distros may use Jun 13 21:13:42 so this dependency should not exist Jun 13 21:13:58 plus atom-pc.conf sounds like a machine conf file anyway Jun 13 21:14:06 it belongs to machine layer Jun 13 21:18:08 khem, I can't talk to that. I'd missed that atom-pc was even removed from oe-core. I guess the discussion will pan out on the ml Jun 13 21:24:27 but it can be added to meta-intel/meta-atompc or some such Jun 13 21:24:49 oe-core only supports emulators Jun 13 21:33:57 khem, poky wants to support 4 "generic" hardware development devices, the atom-pc.conf is one of the. I guess we could copy atom-pc.conf to meta-intel/common, but then we are dealing with code duplication Jun 13 21:34:27 khem: oe-core supports qemu only, poky support the 4 generic targets. Jun 13 21:35:00 sgw: machine layers should be fairly independent of distro layers Jun 13 21:35:23 unless machine layers want explicit deps on a given distro Jun 13 21:35:43 thats fine but then it should be made clear by documenting it Jun 13 21:35:56 I know all that Jun 13 21:37:08 khem, I get it, this is still all evolving, and this points out an interesting problem with the layering where we are testing meta-intel with poky, so we don't see the problem just now uncovered with angstrom, so I agree it needs fixing, just need to figure out the right way to do it. Jun 13 21:38:10 khem: see _RP's reply on the ML, I guess it is all figured out ! Jun 13 21:42:22 oh good, then you can work on my locking problem :) Jun 13 21:42:50 * Crofton is wearing my kernel driver developer hat today Jun 13 22:17:39 fray: ping Jun 13 23:02:13 how to override recipes of same versions in different layers ? Jun 13 23:11:03 dvhart: how layer priority works ? Jun 13 23:11:24 bigger priority number wins or smaller ? Jun 13 23:15:44 bigger wins Jun 13 23:16:02 it should be in the manual Jun 13 23:16:17 * incandescant definitely helped work a patch for that Jun 13 23:19:59 bigger wins followed by order in bblayers Jun 13 23:20:03 later wins Jun 13 23:20:10 but prio number takes precedence Jun 14 00:27:14 incandescent dvhart: thanks **** ENDING LOGGING AT Tue Jun 14 02:59:57 2011