**** BEGIN LOGGING AT Thu Jul 14 02:59:57 2011
Jul 14 03:12:22 <Tartarus> fray, figured
Jul 14 03:13:32 <Tartarus> fray, so at the high level, keep unused bits out of oe-core
Jul 14 03:13:43 <Tartarus> and we can talk more later about the value the dynamic bits may add
Jul 14 03:14:04 <fray> we'd gone through the motions of shared config.cache.. that didn't work due to configure scripts having the same var names but different contents.. and a big static file of values.. which got out of date easily..
Jul 14 03:14:23 <fray> so we settled on a combination of recipe specific config vars (to fix bad configure scripts) and the cached values for speed..
Jul 14 03:14:50 <fray> ya, anything that contributes to maintenance outside of the recipes themselves needs to be considered
Jul 14 03:15:56 <Tartarus> sgw: OK, I'm zap'ing for sure and it's not 'taking'
Jul 14 03:17:12 <Tartarus> and, afk
Jul 14 10:01:46 <RP__> Tartarus: I suspect your problem is debug-tweaks not being enabled
Jul 14 10:02:14 <RP__> Tartarus: Our local.conf.sample has it as does the one in OE-Core but perhaps you're not using it?
Jul 14 14:06:29 <Tartarus> RP__: nope, debug-tweaks isn't set, but is that needed for zap_rootfs_password to 'stick' ?
Jul 14 14:07:03 <RP__> Tartarus: debug-tweaks also does something to dropbear iirc
Jul 14 14:07:59 <Tartarus> could be, but no passwd root ssh works once I zap the pw in terminal
Jul 14 14:09:20 <RP__> Tartarus: I haven't looked in detail, I just remembered about the dropbear thing and wondered if that was the difference
Jul 14 14:09:26 <Tartarus> k
Jul 14 14:13:24 <bluelightning> so, I'm contemplating a change specific to mpc8315e-rdb that will require us to add two config variables to local.conf when building for that machine, or kernel do_configure will bail out.
Jul 14 14:13:33 <bluelightning> is this a good idea?
Jul 14 14:13:54 <bluelightning> obviously we would need to adjust the autobuilder configuration for this machine
Jul 14 14:14:38 <bluelightning> (this is to fix nfsroot booting)
Jul 14 14:17:58 <Tartarus> Well, what's the required change?
Jul 14 14:18:15 <Tartarus> We don't have to do anything like that for nfsroot'ing 8377s here and they're +- the same
Jul 14 14:18:30 <Tartarus> RP__: so the siteinfo stuff, waiting on sgw to put that in his tree and such?
Jul 14 14:18:56 <bluelightning> Tartarus: it's so that the MAC addresses are set correctly in the dtb
Jul 14 14:19:09 <bluelightning> Tartarus: the default value is 00 00 00 00 00 00
Jul 14 14:19:18 <Tartarus> Er
Jul 14 14:19:22 <Tartarus> Are they not set in u-boot?
Jul 14 14:19:56 <bluelightning> yes, but the version of u-boot provided seems incapable of passing the value to the OS
Jul 14 14:20:17 <bluelightning> that's what Bruce tells me at least
Jul 14 14:20:20 <Tartarus> And they aren't set to trash?
Jul 14 14:20:44 <bluelightning> the values in ethaddr and eth1addr in u-boot from the factory are showing up correctly
Jul 14 14:21:00 <Tartarus> Right, and they're also set to something valid is my question
Jul 14 14:21:08 <Tartarus> Freescale ships invalid factory values sometimes
Jul 14 14:21:11 <bluelightning> yes, they are correct
Jul 14 14:21:19 <Tartarus> ok
Jul 14 14:21:25 <Tartarus> So what's your change to the dtb?
Jul 14 14:21:47 <Tartarus> And why isn't the answer to just fix the kernel recipe to have an updated dts file?
Jul 14 14:22:37 <bluelightning> depends what you mean by "fix"... if there's a way in the dts to tell it to grab the mac address from elsewhere rather than hard-coding it, I'd much rather choose that, but I'm unaware of such an option
Jul 14 14:23:09 <bluelightning> right now my fix is to just set the hardcoded value from a variable
Jul 14 14:24:12 <bluelightning> I've only looked at this stuff recently though so it's entirely possible I've missed something
Jul 14 14:26:31 <bluelightning> according to Bruce the proper fix will be to update u-boot so it passes the values across correctly
Jul 14 14:27:06 <bluelightning> we haven't gone down that route yet due to problems the last time we updated u-boot on one of these boards
Jul 14 14:27:39 <Tartarus> Ah
Jul 14 14:28:01 <Tartarus> Yeah, I don't know if that kind of work-around belongs in oe-core, but perhaps poky
Jul 14 14:28:33 <bluelightning> yeah, it's for poky... we don't support that machine in oe-core
Jul 14 14:41:16 <RP__> Tartarus: I was a little disappointed in the siteinfo patch in that you've lumped all the changes into one patch :(
Jul 14 14:41:30 <Tartarus> RP__: How much more could it be broken up?
Jul 14 14:41:35 <RP__> Tartarus: just makes review harder and hence take longer. You hit my review slow path
Jul 14 14:41:57 <Tartarus> The problem I had was I didn't see a place to split it up more without leaving the tree in a broken state
Jul 14 14:44:27 <RP__> Tartarus: right, its certainly a not so easy change to split up. I'll get to it, its just going to take a little longer
Jul 14 14:45:15 <Tartarus> k
Jul 14 14:45:27 <Tartarus> I'll keep banging away on the next and harder part of siteinfo
Jul 14 14:45:40 * Tartarus really is tempted to blow it all away and start over and see how bad it really is
Jul 14 14:45:49 <fray> heh
Jul 14 14:47:19 <RP__> Tartarus: It would be an interesting experiment
Jul 14 14:48:04 <Tartarus> We've built up a lot of cruft and probably a handful of bugs
Jul 14 15:10:54 * Tartarus really needs to start throwing subdirs into sstate-cache
Jul 14 17:30:51 <jefferai> looks like intel owns 134.134  :-)
Jul 14 18:54:03 <mgross> quick config question: how do I use bash env variable within local.conf?  I a path in a config I want to share but it has my absolute path name in it.
Jul 14 18:55:03 <fray> inside of bitbake everything is within the bitbake variables, not environment..  but I'm not sure I understand what you are trying ot do
Jul 14 18:59:00 <Tartarus> Are there any particular packages on Ubuntu 10.04 that need to be installed, other than expect for the qemu tests to be runnable?
Jul 14 18:59:15 <mgross> for one example I want to check in a config that changes the down load directory to be off of $HOME.
Jul 14 18:59:18 <Tartarus> In one of my VMs (it's configured network wise like a real machine tho), it couldn't bring up networking
Jul 14 18:59:26 <Tartarus> no obvious tap failures
Jul 14 18:59:58 <mgross> and have my team members get the same behavior.
Jul 14 19:00:01 <Tartarus> and blah, change nothing, re-run, now it goes
Jul 14 19:00:19 * mgross goes to lunch
Jul 14 19:00:21 <Tartarus> I take that back, it fails quick'ish
Jul 14 19:00:23 <Tartarus> missed it before, heh
Jul 14 19:04:16 <incandescant> mgross, you need to change the DL_DIR variable in local.conf
Jul 14 19:26:04 <mgross> incandescant: yeah but I want my team to share that change without me going to every ones system and fat finering it in there.
Jul 14 20:12:26 <incandescant> mgross, well, you can edit local.conf.sample but that will only work for people that don't have a local.conf
Jul 14 20:14:00 <incandescant> mgross, alternatively you can add DL_DIR to BBENVEXTRAWHITE and then you can set it in your env
Jul 14 20:14:04 <Tartarus> mgross: Are you using some other setup scripts?  ie kergoth's or koen's?
Jul 14 20:14:14 <Tartarus> Or just the built-in stuff?
Jul 14 20:14:48 <Tartarus> You could always just have your team start work from a repo that has local.conf tweaked for local
Jul 14 20:15:59 <incandescant> or site.conf, iirc?
Jul 14 20:16:40 <Tartarus> yeah
Jul 14 20:58:32 <mgross> Tartarus incandescant i think I'll just use sed in the build scripts that call into the yocto stuff.
Jul 14 21:26:27 <Tartarus> OK, anyone around that can tell me if the test stuff should normally run for core-image-minimal?
Jul 14 21:26:31 <Tartarus> or just things like core-image-sato?
Jul 14 21:26:39 * Tartarus kicks a core-image-sato build now
**** ENDING LOGGING AT Fri Jul 15 02:59:57 2011