**** BEGIN LOGGING AT Wed Nov 16 02:59:57 2011 Nov 16 22:10:54 bluelightning: what about the steps to commit 3.1? I'd remove 2.6.39 and .git. Nov 16 22:11:36 ant____: presumably JaMa is ok with removing the git recipe? I think it was him who submitted the patch to add it Nov 16 22:12:09 yes, he insistds doing that now and then (only for spitz). Dunno why...he's not doing any kernel work/testing... Nov 16 22:13:18 if you mind we can ask him, or better, I'll submit the remove-patch to ml Nov 16 22:13:40 my point is about reordering /kernel a bit Nov 16 22:14:01 yeah I'd say submit the patch and if he disagrees he can reply Nov 16 22:14:26 and about hx4700 I'd move it to 3.1.1 Nov 16 22:15:33 yeah let's go with that also Nov 16 22:16:20 ok, I'll split the patches then Nov 16 22:16:32 thanks Nov 16 22:16:48 ah, wait, maybe I'll bake a collie-kernel before.... Nov 16 22:17:08 btw JaMa's onlike atm Nov 16 22:20:39 now I'm tempted to use COMPATIBLE_MACHINE instead of DEFAULT_PREFERENCE Nov 16 22:20:58 for linux_3.1 Nov 16 22:21:25 how does that behave crossing layers? Nov 16 22:21:55 I remember using Angstrom scripts some ti kernel was appearing Nov 16 22:22:05 from their layer Nov 16 22:22:06 ant____: should be OK, assuming something else provides what's needed Nov 16 22:22:58 well, or the opposite, foreign kernels sneaking in Nov 16 22:23:16 maybe was just a bad recipe Nov 16 23:05:42 hm..I seee we have the h1940 in 2.6.39 Nov 16 23:06:09 what to do with that two ipaqs? Any maintainer? Nov 16 23:11:38 ant____: h1940 kernel is maintained by anarsoul Nov 16 23:11:50 it's all in mainline though so in theory it should be fine to upgrade Nov 16 23:12:01 I should really test it though... hmm Nov 16 23:12:09 yes, I don't see patches for that one Nov 16 23:13:07 ok, ideally I'll have to refresh and shrink both ipaq's defconfig Nov 16 23:13:26 so I'll see if the hx4700 patches do apply Nov 16 23:13:57 it will take a while but is worth: we could unify with one single recipe Nov 16 23:14:16 btw, PR is needed or can we live without now? Nov 16 23:15:52 PR = "r0" for a new version surely? Nov 17 00:11:34 well, linux.inc has any Nov 17 00:11:50 we have linux-kexecboot with inc_pr though Nov 17 00:12:15 I'd like to standardize... Nov 17 00:12:43 in fact the PR should be increased once a new kexecboot release peeks out Nov 17 00:13:01 maybe the we could embed kexecboot version/tag in the PR Nov 17 00:13:15 this would be much clearer Nov 17 00:15:44 I'll think about that Nov 17 00:15:46 gn **** ENDING LOGGING AT Thu Nov 17 02:59:57 2011