**** BEGIN LOGGING AT Wed Sep 28 02:59:56 2011
Sep 28 13:13:57 <ant_work> bluelightning: wb
Sep 28 13:35:53 <bluelightning> hi ant_work
Sep 28 13:45:14 <ant_work> I read RP talks about transition out of OE-Core
Sep 28 13:46:02 <ant_work> to meta-oe
Sep 28 13:46:32 <ant_work> what about opposite flow?
Sep 28 13:46:53 <ant_work> any time-window for those merges?
Sep 28 13:47:30 <ant_work> (I don't agree the idea of having obsolete recipes in meta-oe, though)
Sep 28 13:47:46 <ant_work> what's that? the trash bin?
Sep 28 13:59:59 <bluelightning> yeah I'm not especially keen on that idea either
Sep 28 14:01:27 <bluelightning> as for timeline, someone just needs to do the work
Sep 28 14:01:36 <bluelightning> if nobody else gets to it I will try to spend some time
Sep 28 14:01:40 <bluelightning> on it
Sep 28 14:11:11 <ant_work> let say I have 3 cases right now (tzcode/data, udev, X)
Sep 28 14:11:22 <ant_work> first is trivial
Sep 28 14:11:28 <ant_work> second need som ediscussion
Sep 28 14:11:45 <ant_work> third is...in -contrib branches
Sep 28 14:12:11 <ant_work> we'll have to ask JaMa about the status
Sep 28 14:20:10 <ant_work> and about udev, we (handheld) have 2 options: disable the caching overriding the udev defaults file , move to systemd
Sep 28 14:20:34 <ant_work> but the INIT_MANAGER seems up to the distro
Sep 28 14:21:15 <ant_work> so I really would like to understand where oe-core/Yocto  is going
Sep 28 14:22:19 <ant_work> same applies to X server
Sep 28 14:23:45 <bluelightning> well within Yocto people have been talking about systemd
Sep 28 14:23:56 <bluelightning> but there must always be the choice I think, lots of people won't want it
Sep 28 14:24:04 <bluelightning> so OE-core won't be able to mandate it
Sep 28 14:25:01 <ant_work> but then how are they immune of the RO issue on boot making udev-cache fail? maybe oe-core's udev doesn't cache..will check
Sep 28 14:25:14 <ant_work> immune from sounds better...
Sep 28 15:39:33 <bluelightning> ant_work: did you find anything?
Sep 28 15:42:35 <ant_work> yes, it looks lik ether eis no check for $DEVCACHE in oe-core
Sep 28 15:42:58 <ant_work> so it is always rebuilt..should error out as well
Sep 28 15:43:03 <ant_work> on first boot
Sep 28 15:45:05 <ant_work> it's complicated stuff: RO/RW depends on the initscripts too
Sep 28 15:45:20 <ant_work> on the order of them
Sep 28 15:45:47 <bluelightning> hmm :/
Sep 28 15:46:09 <ant_work> I should do a build w/out meta-oe udev
Sep 28 15:46:31 <ant_work> and initscripts...
Sep 28 15:47:39 <ant_work> hm., initscripts are not in meta-oe, just systemd
Sep 28 15:47:45 <ant_work> better
Sep 28 15:53:34 <ant_work> bluelightning: lazy fix to continue using unpatched udev from meta-oe would be adding an override in meta-handhelds
Sep 28 15:53:38 <ant_work> http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-core/udev/udev/default
Sep 28 15:53:58 <ant_work> ^^ commented out #DEVCACHE="/etc/dev.tar"
Sep 28 15:54:23 <ant_work> as we did on oe-classic before Tartarus fixes (whic koen refuses)
Sep 28 15:58:53 <bluelightning> ant_work: we just have to fight harder for these changes if they are important
Sep 28 16:00:40 <ant_work> someone will update oe-core recipe sooner or later.. we'll have to watch and poin him to the meta-ore recipe
Sep 28 16:00:47 <ant_work> that's how I see it
Sep 28 16:14:26 <ant_work> bluelightning: shortly browsing the layers....well it appears anyone has own xserver set of recipes :/
Sep 28 16:14:38 <bluelightning> you mean everyone?
Sep 28 16:15:22 <ant_work> meta-intel, ...
Sep 28 16:15:39 <ant_work> I'm looking at meta-ti which correctly uses .bbappend ;)
Sep 28 16:16:16 <ant_work> I meant each one
Sep 28 16:16:44 <bluelightning> meta-intel uses bbappends too
Sep 28 16:20:22 <ant_work> the issues is the renaming we have in meta-oe
Sep 28 16:20:24 <ant_work> the issue seems to me that once / if the jama/x11 patches in meta-openembedded-contrib and openembedded-core-contrib
Sep 28 16:21:43 <ant_work> so we need first to get acceptance in oe-core...
Sep 28 16:23:04 <ant_work> JaMa said he was a bit upset: oe-core would have 'stealed' from oe-classic and would be refusing to follow developement
Sep 28 16:27:59 <bluelightning> stolen? I don't understand...
Sep 28 16:29:19 <ant_work> his words
Sep 28 16:29:56 <bluelightning> have the patches been sent to the oe-core list? if so, were they rejected?
Sep 28 16:29:58 <ant_work> I don't understand why he is rebasing almost daily those -contrib branches w/out a pull request
Sep 28 16:30:06 <ant_work> heh
Sep 28 16:31:14 <ant_work> the thing is a monster-patchset anyway
Sep 28 16:32:06 <bluelightning> well, patches to the oe-core list are the only way the changes can get into oe-core...
Sep 28 16:33:45 <ant_work> 16 pathes for oe-core
Sep 28 16:34:07 <ant_work> acceptable?
Sep 28 16:34:13 <bluelightning> we've had much bigger ones :)
Sep 28 16:35:01 <ant_work> as far as I understand, once those 16 are in we can remove xserver from meta-oe
Sep 28 16:35:53 <ant_work> as per 11 patches for meta-openembedded
Sep 28 16:36:20 <ant_work> this would be very good!
Sep 28 16:36:45 <ant_work> then we could concentrate on our customization for hh
Sep 28 16:38:46 <ant_work> bbl, bye
Sep 28 20:51:57 <ant__> Jay7: pls measure tosa screen
Sep 28 21:41:06 <Jay7> ant__: [01:23:27] <Jay7> ~61x80
Sep 28 21:41:24 <ant__> oki
Sep 28 21:41:32 <ant__> missed it
Sep 28 21:41:35 <ant__> thx
Sep 28 21:41:52 <ant__> I'll post the file for review
**** ENDING LOGGING AT Thu Sep 29 02:59:56 2011