**** BEGIN LOGGING AT Wed Sep 07 02:59:57 2011
**** BEGIN LOGGING AT Wed Sep 07 04:07:22 2011
Sep 07 08:37:04 <Jay7> hi ant_work
Sep 07 08:37:17 <Jay7> so, is devtmpfs code working?
Sep 07 08:42:48 <ant_work> hi
Sep 07 08:42:50 <ant_work> seems yes
Sep 07 08:43:16 <ant_work> I'll ask bluelightning about other handhelds
Sep 07 08:43:25 <ant_work> otherwise we can remove the device files
Sep 07 08:43:27 <bluelightning> hi all
Sep 07 08:43:40 <ant_work> hello
Sep 07 08:53:48 <bluelightning> ant_work: what were you going to ask me?
Sep 07 08:57:04 <ant_work> do we need an extended device_table-minimal ?
Sep 07 08:57:15 <ant_work> Zaurus kernel all usung devtmpfs
Sep 07 08:57:25 <ant_work> render this osolete
Sep 07 08:58:05 <ant_work> and fwiw I sent a patch which got ignored to the oe-core ML
Sep 07 08:58:17 <ant_work> so we should get rid of /files in meta-hh
Sep 07 08:58:36 <ant_work> dunno how other devioces can cope, though
Sep 07 08:58:43 <bluelightning> ant_work: do other machines we have need those files? I have to admit I don't know
Sep 07 08:59:06 <bluelightning> I guess if they do they must have some reference to the files though right?
Sep 07 08:59:11 <ant_work> this adds /dev/input event interface. if udev is working, no problems afaik
Sep 07 08:59:22 <bluelightning> which patch got ignored?
Sep 07 08:59:35 <ant_work> mom
Sep 07 08:59:54 <bluelightning> s/ignored/missed
Sep 07 09:00:10 <ant_work> http://patches.openembedded.org/patch/7729/
Sep 07 09:01:14 <ant_work> remember devtmpfs was added with 2.6.30
Sep 07 09:03:36 <ant_work> fwiw device_table-minimal.txt is the fallback if you don't set the var
Sep 07 09:03:45 <ant_work> and I find that bad
Sep 07 09:04:02 <ant_work> imagine we want to get rid of all the initial devices (possible)
Sep 07 09:04:08 <ant_work> we should overlay that file
Sep 07 09:04:22 <ant_work> or create a bogus devicers-empty.txt and ude that
Sep 07 09:05:59 <bluelightning> hmm
Sep 07 09:06:11 <bluelightning> this is something for a wider discussion on the mailing lsit
Sep 07 09:06:13 <bluelightning> list
Sep 07 09:08:02 <ant_work> you see, deices just take a couple of kb in the cpio.gz ;)
Sep 07 10:53:52 <lumag_work> morning!
Sep 07 10:55:06 <bluelightning> hi lumag_work
Sep 07 10:55:32 <lumag_work> bluelightning, ant_work. I'm currently cleaning linux.inc. Can we drop a check for old (<141) udev? oe-core/meta-oe have only v145, 164 and 173.
Sep 07 10:56:09 <ant_work> +1 for me
Sep 07 10:56:21 <bluelightning> lumag_work: I'm not sure we can... remember 2.6.21 is needed for older ipaqs and that means old udev
Sep 07 10:56:33 <bluelightning> we don't have that working atm but I intend to look into it
Sep 07 10:56:54 <ant_work> hm... I fear klibc does not compile anymore with 2.6.2x. pretty sure :/
Sep 07 10:57:24 <bluelightning> ant_work: you wouldn't need klibc for those non-kexecboot-using machines though right?
Sep 07 10:57:27 <lumag_work> Also linux-handhelds-2.6 has it
Sep 07 10:57:37 <ant_work> I rempved the 2.62 compatibility patches from the recipes I touched, in general
Sep 07 10:57:40 <lumag_work> Also linux-handhelds-2.6 has it's own kernel .inc file
Sep 07 10:58:15 <ant_work> well, if someone will complain we still have all patches in oe-dev :p
Sep 07 10:59:30 <ant_work> bluelightning: ah, about logo & SRC_URI, you were prophet yesterday :)
Sep 07 10:59:44 <lumag_work> Also I'm not sure about Angstrom-specific cortex-a8 fixup there.
Sep 07 10:59:54 <lumag_work> Should we also drop it?
Sep 07 11:00:09 <bluelightning> lumag_work: ah, so it does... actually none of the old kernels use linux.inc it seems, so yep let's drop it
Sep 07 11:00:18 <ant_work> I would remove that and any machine override if the machine is not h-h
Sep 07 11:00:43 <bluelightning> lumag_work: don't think any of our machines have cortexa8
Sep 07 11:00:46 <bluelightning> so it should go
Sep 07 11:00:53 <bluelightning> ant_work: yep those should go too
Sep 07 11:01:20 <ant_work> I'm tempted to nuke th OABI checks too
Sep 07 11:02:10 <bluelightning> is sa1110 capable of using EABI?
Sep 07 11:02:19 <ant_work> yes
Sep 07 11:02:25 <ant_work> simpad and collie
Sep 07 11:02:36 <ant_work> was added with gcc4.4 iirc
Sep 07 11:02:36 <lumag_work> bluelightning, kind of. It uses special toolchain hacks to rewrite bx instructions to mov.
Sep 07 11:03:05 <ant_work> that's better explained ;)
Sep 07 11:03:34 <bluelightning> lumag_work: ok, if so I don't see a need for OABI support either
Sep 07 11:05:19 <lumag_work> Are we sure that no distro will use OABI? Or we can just play safe, drop non-EABI support but still keep the hook for oabi-compat
Sep 07 11:12:03 <lumag_work> Same applies to bigendian targets? Can we drop support for that.
Sep 07 11:43:44 <ant_work> afaik xscale is le
Sep 07 11:44:15 <ant_work> other chips can run be, mostly routers I'd say
Sep 07 11:47:17 <ant_work> Jay7: btw after patch "Don't grab evdev's exclusively. Flush input on start/exit instead" seems that walking dosn the menu is slower than before
Sep 07 11:47:41 <ant_work> just up-down
Sep 07 11:48:25 <ant_work> on poodle was almost 'perfect', like 2.6.24 after ading the keymappatch
Sep 07 11:56:26 <lumag_work> ant_work, I know about be. but what about meta-hh boxes? Seems to me that none of them uses be mode
Sep 07 11:56:58 <ant_work> right
Sep 07 12:52:39 <bluelightning> lumag_work: re your libm/libcrypt addition for opie-taskbar... the libcrypt one is correct; however the libm one may be due to lack of linking that to libopiecore2 & libopiepim2
Sep 07 12:53:15 <bluelightning> if that's the case I'd like to fix it there rather than in opie-taskbar
Sep 07 13:07:13 <lumag_work> ok, I'll check
Sep 07 13:42:28 <bluelightning> thx
Sep 07 15:10:43 <lumag_work> bluelightning, I checked opie-taskbar. It might be that libopie* don't have respective dependency on libm. However I get unresolved symbol sqrt from calibrate.o
Sep 07 15:10:59 <bluelightning> oh... hmm
Sep 07 15:12:51 <bluelightning> lumag_work: ok, so I guess it should be added... sorry for the confusion
Sep 07 15:13:01 <lumag_work> no problem
Sep 07 15:13:36 <bluelightning> it might also need to be added to libopiepim2/libopiecore2 though if it somehow isn't being linked in already...
Sep 07 15:15:49 <bluelightning> lumag_work: btw re the _git recipe patches, would it be OK if I just merge the patches upstream and then update OPIE_SRCREV ?
Sep 07 15:16:04 <lumag_work> It seems so.
Sep 07 15:16:22 <bluelightning> that would save adding the patches to the recipes now then some time very soon removing them :)
Sep 07 15:16:48 <bluelightning> I'll try to get to that this evening
Sep 07 20:10:32 <lumag> evening!
Sep 07 20:24:55 <ka6sox> morning
Sep 07 21:14:18 <Jay7> night :)
**** ENDING LOGGING AT Thu Sep 08 02:59:57 2011