**** BEGIN LOGGING AT Tue Jun 14 02:59:57 2011
Jun 14 15:29:50 <ant_work> heh
Jun 14 15:29:53 <ant_work> +config ARM_ATAG_DTB_COMPAT
Jun 14 15:29:55 <ant_work> +       bool "Supplement the appended DTB with traditional ATAG information"
Jun 14 15:29:57 <ant_work> +       depends on ARM_APPENDED_DTB
Jun 14 15:29:58 <ant_work> +       help
Jun 14 15:30:00 <ant_work> +         Some old bootloaders can't be updated to a DTB capable one, yet
Jun 14 15:30:02 <ant_work> +         they provide ATAGs with memory configuration, the ramdisk address,
Jun 14 15:30:04 <ant_work> +         the kernel cmdline string, etc.  To allow a device tree enabled
Jun 14 15:30:05 <ant_work> +         kernel to be used with such bootloaders, this option allows
Jun 14 15:30:07 <ant_work> +         zImage to extract the information from the ATAG list and store it
Jun 14 15:30:08 <ant_work> +         at run time into the appended DTB.
Jun 14 15:30:11 <ant_work> let's hope kexec is not broken
Jun 14 15:30:21 <ant_work> by this
Jun 14 15:44:34 <ant_work> bluelightning: how's going with meta-handhelds?
Jun 14 15:44:45 <ant_work> lot of fixes in oe-core
Jun 14 15:45:07 <ant_work> too many to backport. now is almost no-return point
Jun 14 15:45:54 <bluelightning> I hope I will be able to release it by early next week
Jun 14 15:45:59 <ant_work> I'll finish to repackage klibc (possibly) today
Jun 14 15:45:59 <bluelightning> what do you mean?
Jun 14 15:46:15 <ant_work> I mean all perl-native/runtime fixes
Jun 14 15:46:44 <ant_work> and gcc-4.6 compatibility fixes
Jun 14 15:47:11 <bluelightning> so do you mean that you are eager to move to oe-core because of these things, and you're being held back by lack of meta-handhelds?
Jun 14 15:47:11 <ant_work> oe-dev will not have all those
Jun 14 15:47:22 <ant_work> well, almost :p
Jun 14 15:47:36 <ant_work> I have a prototype layering
Jun 14 15:47:47 <ant_work> but don't want to reinvent the wheel
Jun 14 15:47:54 <bluelightning> I'm sorry it's taken so long, it's partly because I did not realise the process I have to go through to get this released
Jun 14 15:48:19 <ant_work> I've diffed some of the most sensible packages
Jun 14 15:48:25 <ant_work> udev is now on pair
Jun 14 15:48:29 <ant_work> kernel too
Jun 14 15:48:41 <bluelightning> unfortunately at release time it will be somewhat broken but I hope it won't take too long to make the required fixes on top of it
Jun 14 15:48:45 <ant_work> klibc will be upgraded this weekend upstream
Jun 14 15:49:11 <ant_work> so we'll have not many packages needed
Jun 14 15:49:39 <ant_work> blocker is now the decision about kdrive/xorg
Jun 14 15:50:00 <ant_work> having only one (the one in oe-core) would be the safe move, isn't?
Jun 14 15:50:15 <ant_work> er.. meta-oe
Jun 14 15:51:48 <ant_work> bluelightning: I forgot Jay7 promised a kexecboot *release* before oe-dev goes ro
Jun 14 15:51:51 <ant_work> ;)
Jun 14 15:52:40 <bluelightning> if xorg can completely replace kdrive then sounds good... I have to admit to not knowing much about X on handelds being an opie guy :)
Jun 14 15:53:00 <ant_work> heh..imagine I'm more a console-guy
Jun 14 15:54:02 <bluelightning> people are talking about making oe-dev read-only, but frankly I think we're some months away from being able to do that
Jun 14 15:54:12 <bluelightning> too many people working & relying on oe-dev still
Jun 14 15:56:57 * bluelightning needs to try more recent versions of kexecboot
Jun 14 15:57:35 <ant_work> with 2.6.3x we have an issue: keyboard maps seems wrong
Jun 14 15:57:56 <ant_work> I've seen this on zaurus and on mips(ben nanonote)
Jun 14 15:58:24 <ant_work> and this happens before any loadkeys
Jun 14 15:58:43 <ant_work> it happens in the initramfs just after boot
Jun 14 16:02:01 <ant_work> well, klibc 1.5.23 release happened today
Jun 14 16:02:17 <ant_work> unfortunately some of our patches are still floating
Jun 14 17:38:47 <Jay7> bluelightning: welcome back :)
Jun 14 17:39:39 <bluelightning> Jay7: thx :) switched to using work laptop @ home and didn't join same channels
Jun 14 17:40:24 <Jay7> yeah, kbdmap is wrong on recent kernels.. I suspect we should provide kernel patches for machines
Jun 14 17:40:42 <Jay7> or load appropriate keymaps on kexecboot start
Jun 14 17:40:49 <Jay7> (in init mode)
Jun 14 17:42:59 <bluelightning> surely it should not be different to older kernels, and if it is it's a bug?
Jun 14 19:50:26 <Jay7> bluelightning: when I've talked about nanonote's kernel and keymap patch kernel devel says me that keymap shouldn't be fixed in kernel
Jun 14 19:50:47 <Jay7> it should be loaded by init scripts
Jun 14 19:50:55 <bluelightning> how is it that it worked before and now it doesn't then?
Jun 14 19:50:57 <Jay7> I'm not sure this is right
Jun 14 19:51:08 <Jay7> but it is
Jun 14 19:51:36 <Jay7> well.. someone should compare RP's kernel keymap with current one..
Jun 14 19:51:40 <bluelightning> well without any further information, on the face of it it sounds very wrong to me
Jun 14 19:52:15 <Jay7> I think kernel should have right keymap out of the box
Jun 14 19:52:25 <bluelightning> I would have to agree
Jun 14 19:53:12 <bluelightning> the fact that we were using -RP branch rather than mainline before which might explain it perhaps
Jun 14 19:53:33 <bluelightning> I think it would be a bit unfortunate if we had to use initscripts as a bandaid
Jun 14 19:53:40 <bluelightning> though
Jun 14 19:54:02 <bluelightning> how badly broken is the "default" keymap?
Jun 14 19:57:19 <Jay7> bluelightning: not sure..
Jun 14 19:57:32 <Jay7> akita/spitz looks useful
Jun 14 19:57:41 <Jay7> but poodle/collie/tosa are wrong
Jun 14 19:58:00 <Jay7> nanonote have patch with right keymap
Jun 14 19:58:45 * Jay7 is moving to laptop and sofa
Jun 14 22:11:20 <ant__> Jay7: can you rewrite that menu->current lines adding some checks/printf?
Jun 14 22:12:10 <Jay7> ant__: I can't imagine why this produces align trap.. it may produce sigsegv but not align...
Jun 14 22:12:37 <Jay7> but may be good idea to add checks for NULL before using current
**** ENDING LOGGING AT Wed Jun 15 02:59:57 2011