**** BEGIN LOGGING AT Tue Jan 15 02:59:57 2008 Jan 15 03:08:23 what to whack... dbus? dialer? libgsmd-tool works fine, but the GUI has no clue and returns random error messages (like, method Dial with signature s does not exist, or no reply received) Jan 15 03:14:49 * Kero wonders whether, when the Dialer application calls "Dial" on org.openmoko.Dialer, it is actually talking to itself... Jan 15 03:24:24 * Kero whacks ldd, for using /bin/bash which does not exist Jan 15 03:25:00 ipkg install bash! Jan 15 03:26:26 and to my surprise: Cannot find package bash. Jan 15 03:27:30 ash and sh complain about "applet not found" Jan 15 03:31:57 Odd Jan 15 03:32:01 It should be there. Jan 15 03:32:13 However - ln /bin/bash /bin/whatever Jan 15 03:32:17 should work Jan 15 03:34:57 what is applet? Jan 15 03:35:29 ah Jan 15 03:35:41 it may be busybox Jan 15 03:36:02 complaining it dpesn't know what to run Jan 15 07:10:23 honors and salutes to everyone Jan 15 07:12:00 salutare cosmin! Jan 15 07:12:11 hello Jan 15 07:12:42 i have a question for all you gurus and occult leaders Jan 15 07:13:27 where did the /media/mmcblk0 dissapear in the last openmoko build for qemu? Jan 15 07:14:34 i am using MokoMakefile and i made "make download images" and "make flash-qemu-official" Jan 15 07:15:17 and i cannot find any catalog that is large enough for my purposes Jan 15 07:52:37 openmoko: 03werner * r3833 10/branches/src/target/kernel/2.6.24.x/patches/ (gta01-jbt6k74.patch smedia-glamo.patch): (log message trimmed) Jan 15 07:52:37 openmoko: Applied "fix-lcm-init-and-glamo-spi-gpio.patch" Jan 15 07:52:37 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=2daebe556bfa6842917ee930e7df7de1a51af2f0 Jan 15 07:52:37 openmoko: Allows panel to work on 2.6.24 Jan 15 07:52:37 openmoko: Signed-off-by: warmcat Jan 15 07:52:41 openmoko: smedia-glamo.patch: Jan 15 07:52:43 openmoko: - drivers/mfd/glamo/glamo-spi-gpio.c (glamo_spigpio_probe): initialize Jan 15 08:01:06 openmoko: 03werner * r3834 10/branches/src/target/kernel/2.6.24.x/config/defconfig-2.6.24-rc7: Jan 15 08:01:06 openmoko: Applied "add-vfat-nls-to-kern.patch" Jan 15 08:01:06 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=3535365795b39e664f3c90dd3d253ada5bccb6b0 Jan 15 08:01:06 openmoko: SD Card / VFAT in monolithic kernel Jan 15 08:01:06 openmoko: Signed-off-by: Andy Green Jan 15 08:01:06 openmoko: - defconfig-2.6.24-rc7: changed CONFIG_FAT_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, Jan 15 08:01:11 openmoko: CONFIG_NLS, CONFIG_NLS_CODEPAGE_437, and CONFIG_NLS_ISO8859_1 from "m" to "y" Jan 15 08:08:32 good morning Jan 15 08:31:34 morning Jan 15 08:55:15 Good morning Jan 15 08:55:36 where is the SD card located in Openmoko u/ QEMU? Jan 15 08:55:57 it used to be somewhere like /media/mmcblk0 Jan 15 08:56:29 but i made an update and now i can't find it Jan 15 08:56:35 can somebody help me? Jan 15 08:57:31 miha, does df output tell you if it is mounted? Jan 15 08:57:44 miha, check dmesg output for /dev/mmcblk0 entry? Jan 15 08:58:58 i have no /media/mmcblk0 entry Jan 15 08:59:06 mmcblk0 is entirely gone from /media Jan 15 09:00:31 miha, run "dmesg | grep mmc" on the Neo to check if your mmc is first detected Jan 15 09:02:28 openmoko: 03werner * r3835 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: (log message trimmed) Jan 15 09:02:28 openmoko: Applied "glamo-core-comment-unused-vars.patch", Jan 15 09:02:28 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=841192953ef0052e375c48936612fd0591587aed Jan 15 09:02:28 openmoko: Just kill genuine compile warnings about unused vars by commenting since they Jan 15 09:02:28 openmoko: look like they may be used for something eventually Jan 15 09:02:32 openmoko: Signed-off-by: Andy Green Jan 15 09:02:34 openmoko: smedia-glamo.patch: Jan 15 09:02:50 sais someth like : mmc0: SD card claims to support the incompletely defines 'low voltage range'. This will be ignored. Jan 15 09:08:24 and some other messages like <7>mmc_set_power(0|1|2, vdd=0|20) Jan 15 09:13:02 but it does not detect the card Jan 15 10:06:17 morning Jan 15 10:26:29 Kero: some operating systems do not set the 500mA mode on the neo unless you have a driver for it, and you usually don't on these operating systems Jan 15 10:41:39 openmoko: 03werner * r3836 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: (log message trimmed) Jan 15 10:41:39 openmoko: Merger of "glamo-core-fix-irq-demux-desc-lock.patch", Jan 15 10:41:39 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=b51600d1168afff39fda4719d97fabcebdc3f8c9 Jan 15 10:41:39 openmoko: and a further refinement from "glamo-mmc-driver-2.6.24-incomplete.patch" Jan 15 10:41:39 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=bce576562d0b4e9c83ac9939bec424862994220f Jan 15 10:41:43 openmoko: desc gets overwritten inside the demux handler... it doesn't unlock what it Jan 15 10:41:45 openmoko: thinks it does... Jan 15 10:45:48 openmoko: 03thomas * r3837 10/trunk/src/target/ipkg/ (144 files in 5 dirs): * Add ipkg for future development Jan 15 10:48:36 openmoko: 03werner * r3838 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: (log message trimmed) Jan 15 10:48:36 openmoko: Applied "glamo-core-interrupt-enable-b9-madness.patch", Jan 15 10:48:36 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=110f15e3db695251bbc1367c10cebbc2cea44f80 Jan 15 10:48:36 openmoko: Setting "General Interrupt Register 1" to 0xffff not only enabled all Jan 15 10:48:36 openmoko: irqs, but also routed interrupts to the internal RISC processor, which Jan 15 10:48:40 openmoko: isn't what we want. Jan 15 10:48:42 openmoko: Signed-off-by: Andy Green Jan 15 11:03:36 openmoko: 03chris * r3839 10/trunk/src/target/OM-2007.2/applications/openmoko-dialer2/ (3 files in 2 dirs): Jan 15 11:03:36 openmoko: * src/phone-kit/moko-network.c: Jan 15 11:03:36 openmoko: Increase timeout to 60 seconds Jan 15 11:03:36 openmoko: * src/phone-kit/moko-sms.c: (moko_sms_send): Jan 15 11:03:36 openmoko: Don't try to resolve recipient number Jan 15 11:11:28 openmoko: 03werner * r3840 10/branches/src/target/kernel/2.6.24.x/patches/ (gta02-core.patch smedia-glamo.patch): (log message trimmed) Jan 15 11:11:28 openmoko: Applied "detect-glamo-irq-pullup.patch" Jan 15 11:11:28 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=c6be860fc5bb86ae5af7e26b61dba43566d43d3c Jan 15 11:11:28 openmoko: Runtime detection of if the glamo IRQ# line is blessed with a pullup or not Jan 15 11:11:28 openmoko: GTA-02 < A5 do not have it but can be reworked Jan 15 11:11:31 openmoko: Signed-off-by: Andy Green Jan 15 11:11:33 openmoko: gta02-core.patch: Jan 15 12:13:28 openmoko: 03werner * r3841 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: Jan 15 12:13:28 openmoko: Applied "glamo-core-fix-uninitialized-spinlock.patch", Jan 15 12:13:28 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=627980eebea2e1449f60a54d44095c89385d8d39 Jan 15 12:13:28 openmoko: Uninitialized spinlock makes death on 2.6.24 Jan 15 12:13:28 openmoko: Signed-off-by: Andy Green Jan 15 12:13:32 openmoko: smedia-glamo.patch: Jan 15 12:13:34 openmoko: - drivers/mfd/glamo/glamo-core.c (glamo_probe): initialize glamo->lock Jan 15 13:13:55 march ? Jan 15 13:14:05 wtf .... did you guys have a break through or what ? Jan 15 13:19:49 dbmoodb: I think it was decided that "spring" was too vague, as it did not define which side of the equator. So it appears someone set it back to "March". I still suspect May/June is a better bet. Jan 15 13:20:16 ok Jan 15 14:13:07 wow Jan 15 14:13:36 any suggests for openmoko with treo650 Jan 15 14:15:28 only found this, http://blog.mikeasoft.com/2007/07/01/openmoko-on-a-treo-650/ Jan 15 14:15:37 no more information Jan 15 14:39:01 arw... delayed till march :) Jan 15 14:39:19 thats just around the corner Jan 15 14:42:56 that be true Jan 15 14:43:31 just wonder if they will make the mark tho Jan 15 14:44:23 they still working on that battery thing ? Jan 15 14:45:53 freesmartphone.org: 03emdete * r38 10/trunk/software/ (8 files in 2 dirs): Jan 15 14:45:53 freesmartphone.org: make modem power/reset control optional (if used with pseudo tty) Jan 15 14:45:53 freesmartphone.org: allow pygsmd be activated via dbus (i.e. from a gsm0710 muxer) Jan 15 14:45:53 freesmartphone.org: add a dummy module for a gsm0710muxer Jan 15 14:46:53 * Stephmw starts pondering flash/gnash Jan 15 15:04:36 if I get good software for gta01 by march, I'd be delighted !! Jan 15 15:06:32 do i smell skeptisism ? Jan 15 15:08:53 it's too easy to break simple calling features. I'm disappointed that's still the case half a year after I got my unit. Jan 15 15:08:56 It's a demotivator. Jan 15 15:10:14 i see Jan 15 15:12:00 There needs to be an automated build hose, with qemu or a real neo that tests each build before commit Jan 15 15:13:10 that would be pretty nifty, and you could write various little moko.tests that would test different aspects of the image Jan 15 15:13:31 SpeedEvil: Presumably s/build hose/build host/ Jan 15 15:13:54 or s/build hose/build house/ maybe Jan 15 15:14:16 But you're proposing two repositories then, I guess... you commit to the build host's rep, then it commits to the 'real' repository if tests pass Jan 15 15:14:52 sounds like debian Jan 15 15:15:06 continuous integration environments I've used always just labelled the latest version that passes tests, then send email to the guys who commited stuff that broke the build Jan 15 15:16:08 although what you're talking about would be really easy with darcs as the revision control manager Jan 15 15:18:00 bye all Jan 15 15:18:35 * Sup3rkiddo curses python dbus for the dependencies Jan 15 15:24:17 SpeedEvil: no, it is a matter of priorities. Of course I am biased, since I own a gta01 Jan 15 15:24:40 and there is a gta02 to worry, for FIC/openmoko Jan 15 15:24:59 lets just hope the devs dont get lazy and not-really-optimize-considering-the-processor-is-faster :( Jan 15 15:25:09 but suffice to say, I would probably have worked on software for openmoko, had I been able to *use* the device. Jan 15 15:25:20 wirp: yes Jan 15 15:25:36 cbrake_away: opptimisation is always good. Jan 15 15:25:39 and my software might just have enhanced gta02, too. Jan 15 15:27:01 You can not make a continuous build environment for OpenEmbedded and then point to ppl who break stuff... OpenEmbedded is waaaaay to complex and not-monitored-the-right-way for that. Jan 15 15:27:41 howto run openmoko in treo650? Jan 15 15:29:23 lennie: spend lots of time making it work? I don't think it's a supported platform for OM Jan 15 15:29:49 plus, user stories like "Neo has an incoming call, answers, talks&listens", are you going to verify there's real audio coming out of the loudspeaker? both ways? Jan 15 15:30:04 and automatically inserting the headphones to see whether audio follows automagically? Jan 15 15:30:27 Stephmw, just for fun Jan 15 15:30:33 *that* is the basic functionality I'm talking about, that should be tested before any commit. Jan 15 15:31:22 Stephmw, if can run openmoko,that will be very interesting Jan 15 15:31:37 but gsmd, dbus, dialer and the applet all can (and do, afaiac) break, with no tests of their own. Jan 15 15:31:45 So the conclusion is "it does not work" Jan 15 15:32:28 Kero: from experience at a manufacturers, the 'automation' we used was lots of manual labour and test scripts... Jan 15 15:33:02 not exactly workable solution in this instance Jan 15 15:33:14 right. Jan 15 15:33:24 * Stephmw starts typing in irc-english and drops random words Jan 15 15:33:24 Noone is going to build a nice testing system for OpenMoko now Jan 15 15:33:36 it's too much work, to build it now. Jan 15 15:33:49 and that's without the headphones being inserted ;) Jan 15 15:36:41 I did know of a place that did automated physical testing Jan 15 15:37:09 each rig was adapted to the handset (which was gutted and hard-wired to the rig) Jan 15 15:37:56 Stephmw: heard of many such things. Wear&tear of shoes, emulating walking and what not. Jan 15 15:38:19 but it takes effort to set up that kind of thing Jan 15 15:38:53 an investment which is managable at the start, and worth it. But right now, it's a huge endeavor Jan 15 15:39:30 absolutely... it also needs the hardware to be fairly stable ;) Jan 15 15:43:17 true. Jan 15 15:45:23 freesmartphone.org: 03mickeyl * r39 10/trunk/software/gsm0710muxd/ (27 files in 5 dirs): gsm0710muxd: autotoolize Jan 15 15:45:48 freesmartphone.org: 03mickeyl * r40 10/trunk/software/gsm0710muxd/data/ (gsm0710muxd init.d.gsm0710muxd): gsm0710muxd: rename init script Jan 15 15:49:20 <_magellan_> is anyone successfully building and being able to flash the device using Moko makefile Jan 15 15:50:29 <_magellan_> I can build but when I flash the device, the boot stops at the Angstrom text banner with no gui Jan 15 16:04:05 freesmartphone.org: 03mickeyl * r41 10/trunk/software/gsm0710muxd/ (AUTHORS Makefile.am): gsm0710muxd: fix AUTHORS, add Makefile.am Jan 15 16:21:45 * magumbade is back Jan 15 17:02:57 hello, qemu-neo1973 doesn't compile(gcc-3.4.6): http://pastebin.com/m52f11073 Jan 15 17:18:36 <_magellan_> is anyone successfully building and being able to flash the device using Moko makefile Jan 15 17:19:00 <_magellan_> I can build but when I flash the device, the boot stops at the Angstrom text banner with no gui Jan 15 17:19:27 _magellan_, you probably meant dfu for flahing..=) Jan 15 17:32:52 <_magellan_> you can flash with moko makefile Jan 15 17:33:06 <_magellan_> all it does is run the dfu command Jan 15 17:33:36 anyone for my compilation issue? Jan 15 17:35:43 * Sup3rkiddo didnt know that..thanks Jan 15 17:37:55 <_magellan_> make flash-neo-local Jan 15 17:38:10 _magellan_, ah, thats qemu Jan 15 17:38:29 _magellan_, that flashes qemu, not the actual device Jan 15 17:38:39 <_magellan_> let me look Jan 15 17:38:50 <_magellan_> cause it connects to the device in usb Jan 15 17:39:38 _magellan_, apologies, i read it as flash-qemu-local Jan 15 17:42:17 <_magellan_> sup3rkiddo: it flashes the device Jan 15 17:42:42 <_magellan_> are you able to build? Jan 15 17:42:57 _magellan_, just a sec Jan 15 17:43:13 _magellan_, are you on bleeding edge tree? Jan 15 17:43:46 hi all one more time :) Jan 15 17:49:51 <_magellan_> Im just doing make openmoko-devel-image Jan 15 17:53:01 _magellan_, last build was 48 hours ago Jan 15 17:55:28 <_magellan_> Sup3rKiddo: did you actually load that and turn the OM on? Jan 15 17:55:58 _magellan_, yep Jan 15 17:56:09 _magellan_, but i used dfu-util Jan 15 18:02:44 <_magellan_> crap, what is wrong with mine. I went back and tried it with DFU and I still fail to boot Jan 15 18:04:11 _magellan_: what does it do? Jan 15 18:04:12 _magellan_, boot?, as in kernel panic? Jan 15 18:05:47 <_magellan_> no there is no kernel panic, it starts, and then goes to the splash screen and then just as the status bar gets full, it goes back to text mode and displays the Angstrom text banner and just sits there Jan 15 18:06:22 _magellan_: you've got a matching kernel and image? Jan 15 18:06:27 from where? Jan 15 18:06:48 <_magellan_> well I used the kernel and image built by moko makefile Jan 15 18:07:05 Try a make update, and another make openmoko-devel-image Jan 15 18:07:11 Just as a sanity check Jan 15 18:07:26 It should go _much_ faster than the first Jan 15 18:07:34 <_magellan_> I have, but Im not before giving it another go Jan 15 18:07:36 <_magellan_> right Jan 15 18:07:56 Also - try downloading images Jan 15 18:08:07 ah Jan 15 18:08:11 of course Jan 15 18:08:20 Have you ever flashed u-boot? Jan 15 18:08:34 uh oh Jan 15 18:08:41 If not. Jan 15 18:09:00 And if the new image happens to take up less space than you've ever used on the root filesystem, jffs2 can get confused Jan 15 18:09:22 you need to do - as described in the wiki - connect to the uboot console and do 'nand erase rootfs'. Jan 15 18:09:35 Note that 'nand erase' on its own will brick your device. Jan 15 18:09:52 jffs2 being confused can cause partial boots Jan 15 18:10:30 <_magellan_> I have never had to mess with u-boot Jan 15 18:10:51 <_magellan_> and Im not lookin forward to it Jan 15 18:11:12 <_magellan_> but I do have the full developers kit so I can recover should it crap out Jan 15 18:11:13 you just hold down the other button on boot Jan 15 18:11:18 and it goes to the uboot menu Jan 15 18:11:36 then you connect over /dev/ttyACM0 on the system it's plugged into Jan 15 18:11:36 <_magellan_> well you have to do that to flash it Jan 15 18:11:41 nad it pretends to be a serial port Jan 15 18:11:50 then you send 'nand erase rootfs' Jan 15 18:11:57 and it says 'ok' after some time Jan 15 18:12:00 then you dfu Jan 15 18:12:34 <_magellan_> All this is in the wiki? Jan 15 18:12:51 yes Jan 15 18:12:54 I think in u-boot Jan 15 18:13:00 or maybe [[bootloader]] Jan 15 18:13:46 <_magellan_> any way I can confirm that this is the problem before I do it Jan 15 18:14:20 <_magellan_> Im flashing another (clean) neo right now. Jan 15 18:14:38 _magellan_: this is risk free - if you don't typo 'nand erase rootfs' Jan 15 18:16:24 <_magellan_> hah, don't put it by me Jan 15 18:19:59 <_magellan_> alright Im going to load it on a clean on and if it still doesn't take then I will nand erase and start again Jan 15 18:20:10 nand erase rootfs! Jan 15 18:20:14 Not nand erase Jan 15 18:29:43 hi Jan 15 19:04:01 * * OM Bug 1182 has been created by andrew.paulsen(AT)packetdigital.com Jan 15 19:04:02 * * Charging current measurement is incorrect (fix) Jan 15 19:04:03 * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1182 Jan 15 19:05:26 openmoko Jan 15 19:07:25 why? Jan 15 19:07:56 why not? Jan 15 19:08:20 openmoko Jan 15 19:17:59 are bug reports (like 1181 and 1182) the best way to get fixes into the kernel? Jan 15 19:19:29 one would think that at least attaching a patch as you did would get you an email from someone telling you the best way to get the fix in... Jan 15 19:19:29 <_magellan_> SpeedEvil: the nand clean didn't work Jan 15 19:20:10 <_magellan_> I did "nand erase clean rootfs" Jan 15 19:21:33 _magellan_: I think it's just 'nand erase rootfs' Jan 15 19:21:40 per http://wiki.openmoko.org/wiki/Flashing_openmoko Jan 15 19:22:28 <_magellan_> Im going to go back and try that Jan 15 19:23:00 <_magellan_> it says one way at http://wiki.openmoko.org/wiki/Nand_erase and the other at your address Jan 15 19:23:40 question on the margin: is openmoko slowing down or it is my feeling? korekt my if I'm wrong. Jan 15 19:23:43 excellent Jan 15 19:26:29 yoyo, That depends on what you mean slowing down? Do you mean development? Buzz about the project? Phone sales? Jan 15 19:27:14 kdean06: development and bug corrections Jan 15 19:35:00 * * OM Bug 1183 has been created by cwixon(AT)usa.net Jan 15 19:35:01 * * Suggested initscripts for gllin and gpsd Jan 15 19:35:02 * * http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1183 Jan 15 19:35:22 yoyo: I think we can blame the holidays for a lot of that, at least the last month or so Jan 15 19:35:53 is the hype somewhat over now? Jan 15 19:36:04 Holidays and the "pressure" for GTA02. Development is (right now) mostly hardware oriented, and there's now twice as much hardware but not twice as many developers. Jan 15 19:36:23 yeah :) Jan 15 19:36:38 * cb23 doesnt care about software status: the problem is, if you have no drivers, you cant really test the hardware :/ Jan 15 19:36:41 gta02 is already kinda late :/ but better late then buggy :) Jan 15 19:37:34 flaushy: 'kinda' late? 5 months late from when I started tracking it... Jan 15 19:37:41 but I agree, better late than buggy Jan 15 19:37:45 I'm kinda the opposite - I couldn't care less about how good the hardware is if the software to do stuff is half-functional. :) Jan 15 19:38:04 Yeah I think like you kdean06 Jan 15 19:38:07 and I'm having a good time with my gta01, or would be if I had it back from Shiloh yet :-/ Jan 15 19:38:17 Just if it isn't any hardware pb Jan 15 19:38:27 but maybe its TO late... Jan 15 19:38:27 kdean06: I don't understand it. openmoko is open source project (free) theoretically there shoot by any pressure deadlines or so :/ Jan 15 19:38:36 <_magellan_> I wonder how things are going to be once "the switch" happens Jan 15 19:38:46 But... for people wanting to buy an '02, one important criterion is that the hardware be solid Jan 15 19:38:55 personaly(as consumer) i would like hardware that is not buggy because you can't change it...software can be updated... Jan 15 19:39:00 if the hw is solid, then you can buy it, play with what works now, and update when sw is complete Jan 15 19:39:05 yoyo, OpenMoko is a Free Software project but the release of Freerunner (NOT OpenMoko) is directly tied to the stability of OpenMoko Jan 15 19:39:11 indeed wurp2 Jan 15 19:39:15 if the hw has a bug, you might have bought something that will never be fully usable Jan 15 19:39:36 That's kinda true... Jan 15 19:39:45 I was thinking about that yesterday, actually, and power management. Jan 15 19:39:54 I know, buggy hardware is bade think Jan 15 19:40:17 but endless waiting is also bad... Jan 15 19:40:23 <_magellan_> wurp2: you are correct, nand erase rootfs works and nand erase clean rootfs does not even though the doc says it does. Im back up and running Jan 15 19:40:59 _magellan_: Excellent! Do you want to update the wiki, or shall I? ;-) Jan 15 19:41:16 I'm half torn... On one hand as someone who PAID for the GTA01 device, if FIC KNOWS there's a hardware defect, I expect some kind of "meeting" with owners of the known-defective device. On the other hand, we're all fully warned that this is developmental stuff... Jan 15 19:41:24 That nand erase clean rootfs meme seems to keep popping up Jan 15 19:41:31 <_magellan_> will you? I don't have an account for it atm Jan 15 19:41:32 I know I've been guilty of saying it sometimes :-( Jan 15 19:41:37 _magellan_: OK Jan 15 19:41:52 _magellan_: Creating an account is trivial, though, for the future... Jan 15 19:42:18 <_magellan_> I know, but the last thing I need is another account right now Jan 15 19:42:18 kdean06: i prefer good hardware, since i didnt want to buy a gta01 and a gta02 i must wait for gta02 Jan 15 19:42:28 and u can always work on the softwarelateron Jan 15 19:43:04 wurp2: kinda late : ETA has been shifted back Jan 15 19:43:10 No, I agree that BOTH need to be working. :P But I care more, personally, about the software (mainly for the reasons stated - I have no control over it). Jan 15 19:43:34 I'll probably buy a GTA02 once the price drops OR when FIC offers incentive to GTA01 owners. Jan 15 19:45:18 * zash will buy when gta02 i aviable Jan 15 19:46:23 I know you must get this a lot, but are there any rough estimates on when gta02 will be released? Jan 15 19:46:41 real soon now Jan 15 19:46:45 ~march says /topic Jan 15 19:46:46 Forward, MARCH! Shoulder, ARMS! Oh, so we want to be stupid, right, says /topic ? Think we're special, that we can do everything different than everyone else, right? Platoon, HALT. Get back, right now! Jan 15 19:46:55 lol@apt Jan 15 19:47:19 one time I'w read a sentence on some web page. "... openmoko is a think what you must have.. " Jan 15 19:47:23 flaushy: Very late. ETA was October, as late as September Jan 15 19:49:05 but, on the other hand, I'd rather just keep getting their best guess. Building software (or designing hw) is not like building a house - you can't know how long it will take to solve a problem until you've done it Jan 15 19:49:26 by which time it's a little late for estimates Jan 15 19:49:37 ETA is a good estimate tho Jan 15 19:49:50 from my point of view you can see the progress, they run into trouble etc Jan 15 19:49:51 wurp2: if you can't know how long you need, then you can't publish a date... Jan 15 19:50:06 better they sort it out now, and do not try to hit the ETA Jan 15 19:51:03 kdean06: software is delevoping, i saw it with the zaurus and other devices :) Jan 15 19:51:16 good hardware is the key, then the software follows Jan 15 19:51:18 I know. :) I use it myself. :) Jan 15 19:51:25 Oh, sorry, misread that. Jan 15 19:51:32 uh? Jan 15 19:51:52 openmoko Jan 15 19:52:07 Does anyone have authority to ban barko the bot? Jan 15 19:52:13 flaushy, I read that "The software is developing, I saw it on the Zaurus" meaning "the software is coming along" rather than what you meant. :) Jan 15 19:52:23 okie Jan 15 19:52:28 :) Jan 15 19:52:49 i hope my university tries to get some hands on on it :) Jan 15 19:53:51 then we could do some stuff in our internships :) Jan 15 19:53:59 math Jan 15 19:55:01 why Jan 15 19:56:44 barko? Jan 15 19:56:55 yes Jan 15 19:57:29 b a r k o ??? Jan 15 19:57:56 what Jan 15 19:59:19 what? Jan 15 20:00:21 i asked something Jan 15 20:00:52 until now i only see some words? Jan 15 20:01:04 namely the channel repeated all over Jan 15 20:01:05 openmoko: 03werner * r3842 10/branches/src/target/kernel/2.6.24.x/patches/ (gta02-core.patch smedia-glamo.patch): (log message trimmed) Jan 15 20:01:05 openmoko: Applied r3788 and r3790 changes from 2.4.22.5 tree: Jan 15 20:01:05 openmoko: fbset-gta02-core.patch: Jan 15 20:01:05 openmoko: - arch/arm/mach-s3c2440/mach-gta02.c (gta02_glamo_pdata): increase maximum xres Jan 15 20:01:05 openmoko: from 480 to 640, to support rotation Jan 15 20:01:07 openmoko: - arch/arm/mach-s3c2440/mach-gta02.c (gta02_glamo_pdata): initialize Jan 15 20:01:09 openmoko: fb_mem_size to 4MB (half of the SRAM available on the chip) Jan 15 20:01:15 sleep time : sii ja i trzymajcie sie cieplo :) Jan 15 20:13:22 I've never used cu before but i'm attempting to do it now and my keyboad is acting "odd" is this normal (and a sign of me not knowing what to expect) or buggy behavior? For instance, attempts to type "setenv boot_menu_timeout 65000" have the spacebar deleting sometimes, and _ making spaces and such. Jan 15 20:15:03 openmoko: 03werner * r3843 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: (log message trimmed) Jan 15 20:15:03 openmoko: Applied "defeat-glamo-lcm-reset-since-uboot-does-it.patch", Jan 15 20:15:03 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=5fc5b83b6fcab7ed5c54f96990358e9b67c42083 Jan 15 20:15:03 openmoko: We don't need to go around resetting the video and lcm so much Jan 15 20:15:04 openmoko: now that U-boot got there first Jan 15 20:15:05 openmoko: Signed-off-by: Andy Green Jan 15 20:15:07 openmoko: smedia-glamo.patch: Jan 15 20:18:00 kdean06, i'm not really sure if it will work, but why not try screen with no initialization strings set? Jan 15 20:18:23 ? Jan 15 20:19:49 Perhaps the missing information would be useful. :) I'm attempting to do a nano erase, but can't actually type the characters. I'm connecting to uBoot on a GTA01bv4's "default" uboot version and connecting as root via Debian Sid. Jan 15 20:19:54 nand* Jan 15 20:20:51 o/ Jan 15 20:20:58 you *really* don't want to do just "nand erase" - unless you've got a debug board. I'm hoping you've got a third word on that command ... Jan 15 20:21:18 rwhitby, No, nand erase rootfs, but I can't get the "nan" part. :) Jan 15 20:21:29 kdean06: I don't use cu to connect Jan 15 20:21:39 I think i was using screen Jan 15 20:21:53 I did notice that if I type quickly I get weird behavior, and sometimes even if not Jan 15 20:22:28 but backspace, persistence, and being very careful to check the line before I hit enter worked around the problem Jan 15 20:22:46 Oh, so screen CAN be used there... What method is that, I haven't seen it mentioned. Jan 15 20:23:06 I think I just did "screen /dev/ttyASDRASERF" or whatever that ttyA thing is ;-) Jan 15 20:23:12 but I'm not 100% sure Jan 15 20:23:30 searching google for site:wiki.openmoko.org + your search terms is useful Jan 15 20:23:46 Ah yes, the Google search. :) Jan 15 20:23:50 And have you read that manual I sent a link to here a couple of days ago? Jan 15 20:24:07 I didn't see a link, so no. :) Jan 15 20:24:15 There is a link to it from the wiki, but it's in a subtle place Jan 15 20:24:22 I'll check if you re-link it. Jan 15 20:24:37 openmoko: 03werner * r3844 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: (log message trimmed) Jan 15 20:24:37 openmoko: Applied "fix-fb-size-patch-dodji.patch", Jan 15 20:24:37 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=7f7c87b23579e3b212cfa5e92082ef255a455f3c Jan 15 20:24:37 openmoko: Contrary to what the name suggests, this patch mainly removes unusued Jan 15 20:24:37 openmoko: variables. The size change was already made when adding Dodji's main patch, Jan 15 20:24:41 openmoko: so it's not in this update. Jan 15 20:24:43 openmoko: - drivers/mfd/glamo/glamo-core.c (glamo_engine_reclock): debug-print the clock Jan 15 20:25:08 http://openmoko.togaware.com/survivor/openmoko.html Jan 15 20:25:27 It was very helpful, although I'm not 100% sure it was helpful re: u-boot prompt Jan 15 20:25:54 http://openmoko.togaware.com/survivor/Interacting_with.html Jan 15 20:26:03 That tells the screen command Jan 15 20:26:16 Screen works well, thanks. :) Jan 15 20:26:34 you're welcome :-) Jan 15 20:28:12 openmoko: 03werner * r3845 10/branches/src/target/kernel/2.6.24.x/patches/smedia-glamo.patch: (log message trimmed) Jan 15 20:28:12 openmoko: Applied "glamo-hold-engines-reset.patch", Jan 15 20:28:12 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=e669c89084dd131ad1329f3c251e4528e2e544c7 Jan 15 20:28:12 openmoko: There seems to be a serious problem letting mfd engines out of reset Jan 15 20:28:12 openmoko: on the glamo. It appears slowly clocked engines could block access Jan 15 20:28:16 openmoko: to the shared memory for long periods making problems for MMC. Jan 15 20:28:18 openmoko: Signed-off-by: Andy Green Jan 15 20:29:56 Hrm... It appears as if cu isn't the problem but pasting. :P Jan 15 20:31:11 pasting to the GSM modem? Jan 15 20:31:47 oh, to uboot Jan 15 20:35:09 If I paste via cu or screen while connected to uboot, it takes input "oddly" - not pasting works fine using screen. Jan 15 20:37:35 kdean06: That jibes with my experience with typing quickly Jan 15 20:38:04 I didn't avoid cu because of any issue with it; I avoided it because I had used screen before, but not cu Jan 15 20:38:54 (I'm using screen right now - I hadn't actually used it to talk to some serial input device) Jan 15 20:39:41 kdean06: look in openmoko/developers/werner/neocon - it's a terminal utility that will insert a delay between characters. I haven't tried it myself but it should help with your u-boot pasting problem. Jan 15 20:40:08 I can just stop being lazy. :P Jan 15 20:41:13 <_magellan_> Has openmoko-terminal2 been taken out of the build tree? Jan 15 20:41:24 Since there's a utility, I'm assuming it's a known problem and the cause is too much input too quickly - I don't use use uboot enough to need to install something to make being lazier easy, at least not yet. Just as long as it's not user error or a bug on my PC side, I'm good. Jan 15 20:43:00 Has anyone successfully built MokoMakefile recently? Jan 15 20:43:24 <_magellan_> I have but I had to remove openmoko-terminal2 from the build to get it to work Jan 15 20:43:31 I always get errors - first it was failure to download some file, now it's u-boot-openmoko vs uboot-openmoko Jan 15 20:43:50 _magellan_: Thanks, let me look into that Jan 15 20:43:51 <_magellan_> have you updated the makefile? Jan 15 20:43:57 yep Jan 15 20:44:56 wurp2: The u-boot-openmoko one may not be a real error - look earlier in the log to see if something else failed first Jan 15 20:45:23 I always use make update-makefile && make setup update openmoko-devel-image to run it Jan 15 20:45:28 mmontour: OK, will do Jan 15 20:45:51 I see an error compiling gcc-cross_4.1.2.bb Jan 15 20:46:19 <_magellan_> I think someone was haveing that problem earlier, was it you or someone else Jan 15 20:46:23 openmoko: 03werner * r3846 10/branches/src/target/kernel/2.6.24.x/patches/ (pnp_fixes.patch series): Jan 15 20:46:23 openmoko: Applied "pnp_fixes.patch", Jan 15 20:46:23 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=c7751f33688574a9512545ebc159481bac103de9 Jan 15 20:46:23 openmoko: From: Samuel Ortiz Jan 15 20:46:23 openmoko: pnp_fixes-patch: Jan 15 20:46:25 openmoko: - drivers/pnp/Kconfig: also allow PnP if we only have SDIO Jan 15 20:46:26 Not me Jan 15 20:46:29 openmoko: - drivers/pnp/resource.c (pnp_check_dma): don't request a DMA Jan 15 20:46:36 I will search logs Jan 15 20:47:27 <_magellan_> I don't think they talked of a fix but I remember it Jan 15 20:47:32 is there list of languages/compilers/interpreters this thing supports? Jan 15 20:51:45 openmoko: 03werner * r3847 10/branches/src/target/kernel/2.6.24.x/patches/ (4 files): (log message trimmed) Jan 15 20:51:45 openmoko: Added the Atheros WiFi driver from Samuel Ortiz : Jan 15 20:51:45 openmoko: - "atheros_2_0_function.patch", Jan 15 20:51:45 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=e1ba2e32f166b646167e774a8d6c6e2881627a14 Jan 15 20:51:45 openmoko: - "atheros_2_0_hcd-patch", Jan 15 20:51:49 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=5ed9588b6ae2fb4da1351ea0e0bd1eaff1ebcd30 Jan 15 20:51:51 openmoko: - "atheros_2_0_sdio_stack.patch", Jan 15 20:54:18 anybody knows the foobar dialer and can me give a screenshot? :) Jan 15 21:01:09 openmoko: 03werner * r3848 10/branches/src/target/kernel/2.6.24.x/config/defconfig-2.6.24-rc7: Jan 15 21:01:09 openmoko: Applied most of "wlan-config-changes.patch", Jan 15 21:01:09 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=6019b5e4106a916ebaaffaf8d8653e800dd17c2b Jan 15 21:01:09 openmoko: defconfig-2.6.24-rc7: enabled CONFIG_WIRELESS_EXT, CONFIG_PNP, Jan 15 21:01:09 openmoko: CONFIG_PNP_DEBUG, CONFIG_SDIO, CONFIG_SDIO_S3C24XX, CONFIG_SDIO_S3C24XX_DMA, Jan 15 21:01:12 openmoko: CONFIG_SDIO_AR6000_WLAN, and CONFIG_MMC_DEBUG Jan 15 21:01:14 openmoko: defconfig-2.6.24-rc7: monolithized CONFIG_MII and CONFIG_USB_USBNET Jan 15 21:03:12 SirBob1701: This thing? Jan 15 21:03:19 ? Jan 15 21:03:43 regarding your last comment Jan 15 21:03:47 what is 'this thing'? Jan 15 21:04:18 wurp2: oh openmoko in general Jan 15 21:05:02 C and Python that I know of Jan 15 21:05:11 and of course bash and ash Jan 15 21:05:22 and awk and sed Jan 15 21:05:43 Probably anything you have C code for that isn't platform specific is either supported or will be Jan 15 21:06:05 And there was a note about a flavor of Java that would be supported on the gta02, but I dunno if that's generally available yet Jan 15 21:06:26 wurp2: interesting. i'll have to take a look at what projects are going on to see if i can help out Jan 15 21:06:56 The trick is getting your cross platform build to go through the first time :-) Jan 15 21:07:31 They really need to set up a known label that points to the latest build that goes through from nothing to finished product Jan 15 21:08:32 wurp2: i think the sites they have suck. hard to find out whats under development by who Jan 15 21:11:43 openmoko: 03werner * r3849 10/branches/src/target/kernel/2.6.24.x/patches/gta02-core.patch: (log message trimmed) Jan 15 21:11:43 openmoko: Applied most of "mach-gta02_wifi.patch", Jan 15 21:11:43 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=2066e0986693a33c77ae214b4d41071c4f556932 Jan 15 21:11:43 openmoko: gta02-core.patch: Jan 15 21:11:43 openmoko: - arch/arm/mach-s3c2440/mach-gta02.c (gta02_sdio_resources, gta02_sdio_dev, Jan 15 21:11:46 openmoko: gta02_machine_init): added SDIO resources Jan 15 21:11:48 openmoko: - arch/arm/mach-s3c2440/mach-gta02.c (gta02_machine_init): added power up and Jan 15 21:12:36 I've wondered how they manage that very well Jan 15 21:14:38 I don't really see how you *can*, on a project that is doing open source development with proprietary-type expectations about when stuff will get done Jan 15 21:14:52 I mean, joe blow signs up to fix some bug Jan 15 21:15:08 How long do you wait before you assume joe blow isn't going to deliver? Jan 15 21:18:46 I don't think that's so much a problem of Free Software vs proprietary - it's a matter of project management. I've seen no real person "in charge" of projects - that person would set a timeline for Joe Developer to deliver before considering him a non-deliverer. If he vanishes prior to that the project manager would choose to re-assign or whatever. Jan 15 21:19:35 ya i have no idea how they manage it Jan 15 21:19:36 lol Jan 15 21:20:35 There is one problem there, however... Free Software developers have "need" or "passion" as a motivator for writing software - but there's not motivation there to do it in a timely manner. Jan 15 21:22:00 The only people setting a time frame of the "speedy" delivery of these apps is FIC because they're basing their mass market product release around it. Everyone else is free to download it and submit a patch on a timeframe they see fit. Jan 15 21:22:19 Or I suppose it's technically OpenMoko Inc setting the timeframe. Jan 15 21:24:26 openmoko: 03werner * r3850 10/branches/src/target/kernel/2.6.24.x/patches/ (series suspend-prelim1.patch): (log message trimmed) Jan 15 21:24:26 openmoko: Applied the preliminary power-saving patches for GTA02: Jan 15 21:24:26 openmoko: - "matt-suspend-prelim1-pcf50633.patch", Jan 15 21:24:26 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=e52762af763ec931a68ced7aeefccf11fc2c802b Jan 15 21:24:26 openmoko: - "matt-suspend-prelim1-pm-i2c.patch", Jan 15 21:24:30 openmoko: http://git.openmoko.org/?p=kernel.git;a=commit;h=bb908eb228af05fd532b2df7eb6bb50baf725bc2 Jan 15 21:24:32 openmoko: - "matt-suspend-prelim1-smedia-glamo-interdiff.patch", Jan 15 21:31:48 kdean06: Timeframe on fixes still seems like an issue to me, basically because of turnover. Jan 15 21:32:08 You only know how long someone will take to deliver something, or indeed if someone will consistently deliver, based on history Jan 15 21:32:30 and in OS lots of people may become interested for 3 months then move on, without necessarily even telling you that they did so Jan 15 21:33:02 It's not really OS specific, it's more just the telecommuting + no stick to hit non-performers with Jan 15 21:33:47 And unless they have some tie, other than that of community, I don't really know it's fair to expect that of them. You can expect a Red hat employee to be responcible to fix a Fedora bug, but until a patch is in the maintainers hand, no single developer has that burden, or so I believe. Jan 15 21:34:12 openmoko: 03werner * r3851 10/branches/src/target/kernel/2.6.24.x/config/defconfig-2.6.24-rc7: Jan 15 21:34:12 openmoko: We need CONFIG_PACKET for DHCP to work. Jan 15 21:34:12 openmoko: defconfig-2.6.24-rc7: monolithized CONFIG_PACKET Jan 15 21:34:40 I agree Jan 15 21:35:01 Although I'll say that as a (rare) contributor, I feel very obligated to deliver what I say I will Jan 15 21:35:27 Far easier are the times when you discover a bug, and while you're tracking down that it's not your problem, you see the fix Jan 15 21:35:39 So you deliver bug report & patch simultaneously :-) Jan 15 21:36:09 But I know there are lots of things in OM that I would feel inclined to fix, if I could be sure I wasn't duplicating effort Jan 15 21:36:26 and if it was easier to get a stable codebase to work from Jan 15 21:36:39 which is a totally separate, solvable problem Jan 15 21:37:04 Well, documentation itself is also important. :P Jan 15 21:37:11 True Jan 15 21:37:14 But that's a pipe dream Jan 15 21:37:15 :-/ Jan 15 21:37:48 I'd LOVe to know who's working on ringtone management, for instance, and know what kind of spec said app needs to adhere to. Jan 15 21:37:50 Whether it's proprietary or open source, often the things I want to know can only be found by either testing or reading the source Jan 15 21:38:14 Oh, project mgmt documentation Jan 15 21:38:21 I thought you meant docs on the sw itself Jan 15 21:38:36 They're directly tied. Jan 15 21:38:40 In my mind, anyway. Jan 15 21:39:20 Well, what you want is easy Jan 15 21:39:33 Just find one of the source files that deals with ringtons Jan 15 21:39:38 s/ringtons/ringtones/ Jan 15 21:39:38 wurp2 meant: Just find one of the source files that deals with ringtones Jan 15 21:39:40 One could read source all day, but do you REALLY want to find out by reading ALL of the OM source that the working for certain things are there? I'd MUCH rather know WHO is working on Project X. Jan 15 21:39:45 Then look at the check in log :-) Jan 15 21:40:01 darcs supports finding out line by line who contributed what Jan 15 21:40:20 In svn you have to dig around for that, but even w/o that, you can probably see what you want from the file's history Jan 15 21:40:53 I know I'm not telling you anything you don't already know... and I understand what you want is something more approachable and formal Jan 15 21:40:53 I thought it was called 'svn blame' Jan 15 21:41:08 Stephmw: wow, lemme look that up Jan 15 21:41:13 I didn't know it had that! Jan 15 21:41:24 ;) Jan 15 21:41:42 what pissed me off is that SynergyCM/Continuous *didn't* Jan 15 21:41:55 I see Jan 15 21:42:07 Very nice! Jan 15 21:42:34 closed source SCMs always piss me off Jan 15 21:43:08 I would be interested in one that could deal with the workload we had on that one though Jan 15 21:43:53 Interested in an open source rcs that could deal with the workload? Jan 15 21:44:08 well, I don't work there anymore, so it's purely academic Jan 15 21:44:17 I have never heard of a volume problem with either svn or cvs Jan 15 21:44:35 either in total file space or # of transactions per minute Jan 15 21:44:54 I'm sure it's possible to find the limit, but I thought the limits were too large to be a practical limit Jan 15 21:45:35 3-4k developers, ~13mloc (checkout zipped==3gb)... Jan 15 21:45:54 I wouldn't think that would be a problem... Jan 15 21:45:56 hmm, halve developers, half of them worked on another product Jan 15 21:46:06 Although that's higher than I've heard of on one project Jan 15 21:46:18 (# of devs, not # of mloc) Jan 15 21:46:33 now add on, by-yearly branches from mainstream, by-weekly branches per product variety and about 400 products Jan 15 21:46:57 err.. that's a bit vague Jan 15 21:47:12 1/2 year branches from mainstream and 2-weekly product branches Jan 15 21:47:17 That's a lot, but I would still expect it to be a disk space and network issue, not an SCM issue Jan 15 21:47:46 with that many concurrent changesets I think it would quickly become unmanageable with svn or cvs Jan 15 21:48:01 I would be much more worried about the project mgmt problems of 1500 developers in one source tree :-) Jan 15 21:48:17 took me 2 months to get the hang of it ;) Jan 15 21:48:24 and I still hiccuped occasionally Jan 15 21:50:33 wurp2: tbh, the whole process was way too heavy, I'm glad they're refactoring it Jan 15 21:52:46 i take it 1973 was the original planned release date of the openmoko? Jan 15 21:52:53 lol Jan 15 21:52:58 haha Jan 15 21:53:06 Moniker42: yeah, it kept slipping Jan 15 21:53:25 Moniker42: originally it was a hw fault: Hardware too big to fit in containers Jan 15 21:54:52 Stephmw, too big enough to fit in shipping containers? :) Jan 15 21:55:31 Moniker42: yah, then they noticed the label on the pcb: "TODO: miniaturise" Jan 15 21:56:28 that, and each model cost several million dollars ;) Jan 15 21:56:47 * Stephmw grins Jan 15 22:25:27 http://boston.craigslist.org/gbs/m4w/533096562.html Jan 15 22:30:37 Pure plagarism - or old news. :P Jan 15 22:31:19 http://stallman.org/extra/personal.html Jan 15 22:32:27 * SpeedEvil ponders what a RMS groupie would look like. Jan 15 22:32:40 * Stephmw shudders Jan 15 22:32:50 SpeedEvil: I've seen em Jan 15 22:33:06 SpeedEvil: anywhere RMS goes on conference he's got bearded groupies Jan 15 22:33:21 Female ones I mean. Jan 15 22:33:31 Or are they like dwarves :) Jan 15 22:33:43 females? at FOSS conferences? Jan 15 22:33:56 * Stephmw chuckles Jan 15 22:34:03 what's a female? Jan 15 22:34:15 man woman Jan 15 22:34:35 seriously, last year's FOSDEM had women there... but I'd say it was under 10% Jan 15 22:34:50 "No manual entry for woman" SpeedEvil my computer doesn't know either Jan 15 22:37:18 GN Jan 15 22:50:33 I think RMS was dating a nice Brazilian girl Jan 15 22:50:54 I guess they broke up ;-) Jan 15 22:55:01 openmoko: 03werner * r3852 10/branches/src/target/kernel/2.6.24.x/patches/ (gta02-acc.patch series): Jan 15 22:55:04 openmoko: Applied r3799 and r3800 from the 2.6.22.5 tree. Jan 15 22:55:06 openmoko: Note that lis302dl.c has moved from drivers/spi/ to drivers/input/misc/ Jan 16 02:54:47 Has a datasheet for the LCD surfaced? **** ENDING LOGGING AT Wed Jan 16 02:59:57 2008