**** BEGIN LOGGING AT Sat Dec 03 02:59:57 2011 Dec 03 05:18:42 anyone else notice that the docs.openmoko.org SSL cert has expired? Dec 03 08:02:42 SHR: 03Martin.Jansa 07shr-chroot * r7221f2bdd162 10/OE/bin/shr_sync.sh: shr_sync: fix ipk sync Dec 03 08:45:22 JaMa: moin, I better rebuild from scratch when switching to systemd branch? Dec 03 08:48:46 mrmoku: I expected you'll switch to efl branch Dec 03 08:49:25 and 002 is almost finished on buildhost (only images are in queue) Dec 03 08:49:34 so I plan to merge jansa/efl to shr today Dec 03 09:02:30 JaMa: hehe, ok Dec 03 09:02:42 SHR: 03Martin.Jansa 07shr-chroot * rb625d1a39dfb 10/ (1479 files in 57 dirs): system upgrade Dec 03 09:02:51 but if you want, you can use systemd branch too :) Dec 03 09:03:08 JaMa: depends on what I should do... Dec 03 09:03:49 mrmoku: fwiw: elsa/xserver-common change is now separate commit in systemd branch Dec 03 09:04:02 so if you still wont to work on systemd you can revert last 2 commits Dec 03 09:05:17 * JaMa off to gym Dec 03 09:05:23 JaMa: have fun :) Dec 03 09:05:23 and then daywork.. Dec 03 09:05:29 (with the gym) Dec 03 09:09:34 SHR: 03mok 07meta-smartphone * r3372e2e76177 10/meta-shr/recipes-shr/shr/ (2 files in 2 dirs): shr-e-gadgets_git.bb: add patch for label_get --> text_get api change Dec 03 09:09:34 SHR: 03Martin.Jansa 07meta-smartphone * r52e2d880f5ab 10/meta-shr/recipes-shr/3rdparty/ (2 files in 2 dirs): ffalarms: fix genlist callbacks API break Dec 03 09:09:34 SHR: 03Martin.Jansa 07meta-smartphone * r49a6903638be 10/meta-shr/recipes-shr/shr/ (4 files in 2 dirs): libphone-ui-shr: add few patches for new elementary API Dec 03 09:09:35 SHR: 03Martin.Jansa 07meta-smartphone * rb0227465bf44 10/meta-shr/recipes-efl/e17/enjoy_svn.bbappend: enjoy: add bbappend to enable fso Dec 03 09:09:35 SHR: 03Martin.Jansa 07meta-smartphone * r1e5e7d634104 10/meta-shr/recipes-shr/3rdparty/iliwi_git.bb: iliwi: bump SRCREV to fix changed gen* API Dec 03 09:09:35 SHR: 03Martin.Jansa 07meta-smartphone * r9113092935f7 10/meta-shr/recipes-shr/3rdparty/ (2 files in 2 dirs): ffphonelog: fix for gen* api Dec 03 09:18:11 I'm trying to use usb keyboard on FR in Qtmoko Dec 03 09:18:18 Although keyborad is working but the text is only appearing on the console Dec 03 09:18:30 How can I get X application to work with usb keyboard Dec 03 09:24:10 X and Qtmoko? Dec 03 09:24:58 there is wrapper to run X apps iirc Dec 03 09:25:10 mrmoku: I mean GUI. I don't know if it's X or not Dec 03 09:25:21 ah.. Dec 03 09:26:10 Any help is appreciated :) Dec 03 09:27:11 * JaMa|Off doesnt know Qtmoko Dec 03 09:27:53 JaMa|Off: What distro do you advice me to use ? Dec 03 09:28:14 depends on your needs Dec 03 09:29:14 * JaMa|Off likes shr-core-staging Dec 03 09:29:17 I want to have a daily phone like others Dec 03 09:29:53 * JaMa|Off off, changing trams.. Dec 03 09:33:57 mrmoku: How can I contribute to openmoko development ? Dec 03 10:08:33 waraqa: depends on what part? Dec 03 10:08:40 <[Rui]> hi Dec 03 10:08:57 yo [Rui] Dec 03 10:09:20 waraqa: and what distro? Dec 03 10:11:45 hey! Dec 03 10:12:35 yo Slyon Dec 03 10:20:58 mrmoku: What distro are you using ? Dec 03 10:22:55 waraqa: I'm involved in SHR Dec 03 10:23:17 I tried SHR unstable but when talking the voice in not clear to the caller Dec 03 10:23:46 mrmoku: Do you use it to call people ? Dec 03 10:24:51 mrmoku: Everyone I talked to told me the voice is distorted. Dec 03 10:26:43 <[Rui]> waraqa, did you have a buzz fix? Dec 03 10:27:02 http://wiki.openmoko.org/wiki/Buzz_Fix Dec 03 10:27:18 [Rui]: My FR is A7 Dec 03 10:27:31 <[Rui]> waraqa, ah... ok, then... :) Dec 03 10:28:09 <[Rui]> waraqa, well, the sound is not perfect, anyway, and if it catches too much ambient noise then it gets tricky (eg, in a moving car) Dec 03 10:29:03 [Rui]: This problem only occur in SHR Dec 03 10:29:24 waraqa: did you try to lower the volume? Dec 03 10:29:27 <[Rui]> even the new version? Dec 03 10:29:38 <[Rui]> waraqa, I mean. not the unstable, the shr-core one? Dec 03 10:30:05 No, I only tried unstable. Dec 03 10:30:45 <[Rui]> ok. Dec 03 10:31:04 <[Rui]> iirc unstable is kind of stuck right now, all activity is mostly on shr-core Dec 03 10:31:12 I only now noticed there is version. Dec 03 10:31:23 new version Dec 03 10:31:50 I thought shr-unstable is the most updated one Dec 03 10:32:41 <[Rui]> waraqa, not really, sorry :) I also need to update my shr-core, hoping now it won't go nuts so easy? :) Dec 03 10:33:17 <[Rui]> mrmoku, it sort of suddenly starts waking up randomly, gets lots of active display time, battery lasts even less as a result :| Dec 03 10:33:46 What is shr-core intended to be (stable, testing, unstable) ? Dec 03 10:34:10 shr-core in theory is neutral Dec 03 10:34:27 it just tells that is build based on the new openembedded-core Dec 03 10:34:38 right now it's still quite unstable though :/ Dec 03 10:34:43 but we're working on it Dec 03 10:34:48 <[Rui]> where one gets an up to date efl, for instance :) Dec 03 10:35:01 http://trac.shr-project.org/trac/wiki/Stabilizing Dec 03 10:37:07 ~seen morphis Dec 03 10:37:17 morphis <~morphis@dslb-092-076-172-134.pools.arcor-ip.net> was last seen on IRC in channel #openmoko-cdevel, 1d 13h 51m 39s ago, saying: 'gn8'. Dec 03 10:47:19 mickey|munich: I won't make it :/ Dec 03 10:47:52 ok, no problem Dec 03 10:48:00 ah, btw. Dec 03 10:48:27 would it perhaps be possible that you pick me up on Essen main station? It's unclear whether i can make it by car or whether i need to go by train Dec 03 10:48:38 s/on/at/ Dec 03 10:48:39 mickey|munich meant: would it perhaps be possible that you pick me up at Essen main station? It's unclear whether i can make it by car or whether i need to go by train Dec 03 10:48:53 ok, we have to get a good timing Dec 03 10:49:05 as it looks I'm coming with Slyon Dec 03 10:49:07 and he' Dec 03 10:49:12 s quite flexible Dec 03 10:49:20 when would you hit Essen? Dec 03 10:49:36 and Gnutoo probably could need a pickup too Dec 03 10:49:39 i could make it anytime that would be good for you Dec 03 10:49:44 ok Dec 03 10:49:47 slyon is here btw. Dec 03 10:49:50 yeah Dec 03 10:49:51 i'll talk with him Dec 03 10:49:54 good Dec 03 10:49:56 yo! Dec 03 10:49:58 hi Dec 03 10:50:12 I can depart whenever that fits Dec 03 10:50:53 ok, cool. i will only know shortly before the meeting, so lets just plan for it and if i can't make it by car i'll ping Dec 03 10:51:02 ok, good Dec 03 10:51:38 * mrmoku back to daywork :/ Dec 03 10:51:51 *nod* Dec 03 10:57:19 <[Rui]> mrmoku, on a sat? that's too bad Dec 03 10:57:31 <[Rui]> mickey|munich, hey, hi... gal ok? Dec 03 10:57:43 <[Rui]> good nights already? Dec 03 10:58:41 [Rui]: hey... nights have been fairly well (about 4 hours between feedings), but recently they have gone worse again... 2-3 hours. I guess the teeth are coming... Dec 03 11:04:23 * mrmoku has nights ruined by 4 dents coming out in parallel :/ Dec 03 11:04:35 s/dents/teeth/ Dec 03 11:04:51 the fat ones Dec 03 11:05:07 uh oh, that must hurt Dec 03 11:05:27 [Rui]: (sat) that's what you get when you're doing your own business :P Dec 03 11:05:32 indeed Dec 03 11:11:59 <[Rui]> mrmoku, ah... then it's ok :) I envy your cuorage Dec 03 11:12:02 <[Rui]> courage Dec 03 11:16:43 mickey|munich: btw. big fat greetings to Nikolaus please :) Dec 03 11:17:49 <[Rui]> mickey|munich, mrmoku, lilbernie has regressed from a 20:30 to 07:00 sleep to waking up at least once in the middle of the night with hunger but... nights are mostly ok Dec 03 11:40:41 mooo Dec 03 11:44:02 mickey|munich: meeting Nikolaus? Could you rise my concerns about whole audio section being prone to all sorts of odd effects/design-bugs in GTA04? Dec 03 11:44:24 to be frank, it's workse than in GTA02 Dec 03 11:44:29 worse* Dec 03 11:44:38 in some respects Dec 03 11:45:44 and I really don't wanna see a resurrection of friggin buzz-issue Dec 03 11:49:22 N.B. buzz is non-fixable for GTA02-headset jack Dec 03 11:49:36 and GTA04 is waaaay worse even Dec 03 12:28:26 err... guys, you don't need a pickup from Essen main station... just take the the S-Bahn, and then it's a ten minutes or so walk Dec 03 12:32:30 DocScrutinizer: well, to fix it they surely need a bit more specific feedback than "it's bad"... Dec 03 12:32:45 sure Dec 03 12:33:02 also, don't you think it's a bit late in the game? it's not like they published the design only yesterday... :-( Dec 03 12:33:14 I gave a lot of feedback already, but it's just too much to post all this in meails Dec 03 12:33:18 mails* Dec 03 12:34:14 antrik: so what? I offered my help like 9 months back, answer "not yet". Now they approach me with "could you join in" Dec 03 12:35:02 no my fault, after all, don't you think so? Dec 03 12:35:16 good morning people Dec 03 12:35:24 so shall I just STFU now? Dec 03 12:35:34 DocScrutinizer: sorry, didn't know that Dec 03 12:36:10 seems strange though that they ask for feedback only now, when they are already selling the devices... Dec 03 12:36:57 a true OM successor Dec 03 12:37:37 or should I say sequel Dec 03 12:37:43 ouch... that's nasty ;-) Dec 03 12:40:56 DocScrutinizer: I'm glad to hear you are trying to help. too bad though it's too much for email... perhaps you could give him a call? Dec 03 12:41:50 I offered to visit him, but got "no time until january" or sth answer Dec 03 12:42:28 now it's up to me to rise concerns about my available free time, now that I started an employment Dec 03 12:44:29 I see Dec 03 12:49:27 DocScrutinizer: hi doc, ya, Nikolaus is here, will forward your concerns Dec 03 12:51:11 mickey|munich: thanks Dec 03 12:55:39 freesmartphone.org: 03barklome 07aurora * rda93e4499cc6 10/aurora-daemon/src/applications/app-settings/Makefile.am: aurora-daemon: settings: do not install non-installable file Dec 03 12:55:45 hi mickey|munich Dec 03 12:55:50 hi GNUtoo Dec 03 12:56:34 mickey|munich: I think you're somewhat familiar with the nasty high number of variables that made BUZZ on GTA02 appear or vanish. It's not exactly simple to evaluate/investigate Dec 03 12:56:57 ya, i vaguely remember ;) Dec 03 12:57:25 starting with way you hold device, and not even ending at carrier's voice-processing to improve audio quality Dec 03 12:58:36 GTA04 audio looks *extremely* prone esp to buzz issue (there are other flaws - e,g, regarding ESD - as well) Dec 03 12:59:12 for instance I don't have buzz nor buzzfix Dec 03 12:59:34 and here ESD would kill a core component (companion chip) -> no economic repair Dec 03 12:59:52 * GNUtoo doesn't understand a thing: mplayer2 now works, it's the same binary Dec 03 13:00:38 GNUtoo: or you have tolerant peers on your phonecalls ;-P Dec 03 13:01:26 I don't Dec 03 13:01:42 last time I checked I had no buzz Dec 03 13:01:48 this is the first time I hear about gta04 audio issues Dec 03 13:02:27 well, this is the first time I hear about somebody who thinks there was a way those issues might already have shown Dec 03 13:04:40 lindi-: do you think if *anybody* inside OM would've heard about buzz issue showing on one of our ~180 PV units, we would have produzed a batch of thousands and have sold them? now guess how many PV units GTA04 were build and are in actual usage Dec 03 13:07:12 it's up to you to ponder how many of those 3 or 7 already did a true phonecall with wired headset, and if they actually were in a situation regarding all the other parameters (2G, band, distance from BTS, way to hold device, etc) so buzz actually would have shown Dec 03 13:08:57 very basic rules apply here: you never get bugfree software, you never get completely tested hw Dec 03 13:09:23 you have to trust in your experienced EE stuff to tell if there's sth fishy Dec 03 13:11:03 lindi-: you're free to look at sheet 7 of schematics in http://projects.goldelico.com/upload/gta04-main/files/GTA04A3-1-complete.pdf Dec 03 13:11:25 and discuss with me why you think this circuit is *not* prone to buzz Dec 03 13:11:54 DocScrutinizer: I don't know about such electronics stuff Dec 03 13:12:12 I just said that today indeed is the first day I hear anybody mention anything about gta04 audio issues Dec 03 13:12:32 hmm, so how's that comment "first time I hear about..." helping? Dec 03 13:12:54 not sure if it is helping anybody, it's just a statement :) Dec 03 13:13:08 it feels like criticism Dec 03 13:15:45 you probably also haven't heard about the constant quiescent current across that resistor meant to detect "no headset plugged in", and about the battery consumption this adds to overall system consumption Dec 03 13:16:00 SHR: 03Martin.Jansa 07libphone-ui-shr * r52ae61ca1cd1 10/src/view/ (5 files): Revert "replace genlist with gen for new API change in r64245" Dec 03 13:16:05 SHR: 03Martin.Jansa 07libphone-ui-shr * r44ae24272dab 10/src/view/ (6 files): genlist callbacks change s/label_get/text_get/g Dec 03 13:16:05 SHR: 03Martin.Jansa 07libphone-ui-shr * r5d9521ab7b33 10/src/view/ (phone-log-view.c quick-settings-view.c): s/Elm_Toolbar_Item/Elm_Object_Item/g Dec 03 13:16:43 neither about the transzorbs between the two lines of a differential paired line rather than to GND Dec 03 13:17:02 SHR: 03Martin.Jansa 07meta-smartphone * rb6307cbb855f 10/meta-shr/recipes-shr/shr/ (4 files in 2 dirs): libphone-ui-shr: bump SRCREV, drop applied patches Dec 03 13:17:31 no i don't recall hearing about them either Dec 03 13:17:46 only about leds consuming too much :) Dec 03 13:18:03 hah, now that's sth I haven't heard about Dec 03 13:18:26 the indicator LEDs or screen BL? Dec 03 13:18:35 in gta02v5 I mean? Dec 03 13:18:42 duh Dec 03 13:18:47 yeah Dec 03 13:18:50 DocScrutinizer, btw is there a line between CPU and modem for waking the CPU when a call arrives, in the GTA04? Dec 03 13:19:04 I *think* so Dec 03 13:19:09 ok Dec 03 13:19:10 not sure about that either Dec 03 13:19:31 I haven't already started to give schematics a full review Dec 03 13:20:01 GNUtoo: would be a bit silly to forget *that* one, don't you think? ;-) Dec 03 13:20:27 yes but it could happen Dec 03 13:20:28 oooh, we seen even worse ooopses :-D Dec 03 13:21:39 but regarding modem and standby/wakeup etc, I'm concerned about it using USB for interface, and the power consumption this introduces Dec 03 13:22:05 I'd like to hear if this has been taken into account and what's the concept to deal with it Dec 03 13:23:31 the OMAP mentorgraphics MUSB_CORE is a piece of crap and eats some 60mA for simply being activated, not transferring any real data over USB Dec 03 13:25:10 * mrmoku more and more comes to the conclusion EE is no fun at all ;) Dec 03 13:25:28 so to allow inbound data from GPRS while device in low power mode (aka zeroclock, or [eeeew] suspend) you need some auxiliary signalling path Dec 03 13:38:41 or an alternative or augmented protocol on USB Dec 03 13:44:33 ouch about musb Dec 03 13:44:46 yeah indeed Dec 03 13:45:18 learnt a lot of nasty things about musb_hdrc core during my H-E-N enterprise Dec 03 13:45:24 ok Dec 03 13:45:47 I guess I'll have to learn too about MMC+Glamo Dec 03 13:46:00 if I want to fix for my microsd card Dec 03 13:46:07 that's almost same level of hell Dec 03 13:46:12 :-D Dec 03 13:46:24 I've some -16 errors Dec 03 13:46:53 #define EBUSY 16 /* Device or resource busy */ Dec 03 13:47:19 whatever that means in that particular context Dec 03 13:47:28 yes I'll look Dec 03 13:50:43 bbl Dec 03 14:09:17 [2011-12-03 14:16:25] GNUtoo: would be a bit silly to forget *that* one, don't you think? ;-) --- not really, as OMAP is designed for zeroclock, not suspend. And an always active USB connection would signal any inbound call via "RING" on AT-interface Dec 03 14:10:27 alas exactly USB is not really co-working nicely with zeroclock, in that musb_core doesn't/mustn't zeroclock even when CPU does Dec 03 14:10:39 AFAIK Dec 03 14:12:01 if you go the path of suspend-to-ram then that line also needs a function to wake SOC on inbound data, not only on inbound call Dec 03 14:12:17 * DocScrutinizer afk again Dec 03 15:04:37 hi lars_ Dec 03 15:05:15 what's the advantages of the C FIQ handler? Dec 03 15:06:19 GNUtoo: it is easier to write C than assembler Dec 03 15:06:59 yes but it has many drawbacks Dec 03 15:07:36 GNUtoo: which ones do you mean? Dec 03 15:07:42 I'd vote for removing it Dec 03 15:07:51 + * Major Caveats for using this Dec 03 15:07:55 GNUtoo: yes Dec 03 15:08:10 GNUtoo: it's not a matter of vote, somebody needs to rewrite it in assembler Dec 03 15:08:36 ah just removing it won't work? Dec 03 15:08:54 GNUtoo: well then you don't have FIQ handlers at all? Dec 03 15:09:19 really? isn't already a FIQ handler in assembly in mainline? Dec 03 15:09:43 GNUtoo: hmm? Dec 03 15:09:59 btw what is FIQ exactly? Dec 03 15:10:02 fast interupt? Dec 03 15:10:05 GNUtoo: yes Dec 03 15:10:12 GNUtoo: ARM has two kinds of interrupts Dec 03 15:10:47 GNUtoo: reading from the battery is afaik done using an fiq handler Dec 03 15:11:08 yes that's what's written in the wiki Dec 03 15:11:42 GNUtoo: so if you want to read from the battery you need to have an fiq handler. either written in C or assembler Dec 03 15:12:09 ok Dec 03 15:12:16 arch/arm/include/asm/fiq.h Dec 03 15:12:19 what's that? Dec 03 15:12:22 it's in mainline Dec 03 15:13:02 GNUtoo: that Dec 03 15:13:21 GNUtoo: that's just a framework where you can register your fiq handler Dec 03 15:13:47 ok Dec 03 15:14:03 GNUtoo: mainline does not have a handler for reading gta02 battery using an fiq Dec 03 15:14:58 so what should I do exactly, can't I modify the gta02 battery driver instead? Dec 03 15:15:17 GNUtoo: I would focus on upstreaming something easier first Dec 03 15:15:24 ok Dec 03 15:15:28 such as: Dec 03 15:15:33 GNUtoo: the battery driver is this https://gitorious.org/shr/linux/commit/d639c61f8338dcc221f88f350e2804e12e2dfaaf?format=patch Dec 03 15:15:41 "HDQ generic GPIO bitbang driver using FIQ Dec 03 15:15:48 ARM: s3c24xx: Set ARCH_NR_GPIOS according to the selected SoC types. Dec 03 15:15:51 ok Dec 03 15:16:03 GNUtoo: it has this hdq_fiq_handler Dec 03 15:16:13 GNUtoo: which is registered to be called when an FIQ occurs Dec 03 15:16:42 it's about a hundred lines of C so rewriting it in assembler isn't horrible but not fun either Dec 03 15:17:09 ok Dec 03 15:17:38 GNUtoo: I'm trying to get the alsa resume cache corruption bugfix upstreamed first, it's the last one in the wiki page Dec 03 15:19:36 http://www.pastie.org/2960076 applies on top of 3.1 Dec 03 15:19:45 ok Dec 03 15:19:53 GNUtoo: yep Dec 03 15:20:13 GNUtoo: the problem is that you often need to study the whole subsystem, then rewrite the commit message to be better, then find the right person to send the patch to Dec 03 15:20:25 ok Dec 03 15:20:40 GNUtoo: if you want to help one thing would be to figure out what to do with https://gitorious.org/shr/linux/commit/5a7eaa51c3e7298416d1faf17ba96678498b6a7e?format=patch Dec 03 15:21:01 GNUtoo: it would be interesting to see what mechanism is generally used for gps power control on androids, n900 etc. Dec 03 15:21:13 GNUtoo: since "power_on" in /sys is not very nice interface Dec 03 15:21:41 I only have freerunner so I don't really know how other linux based phones do this Dec 03 15:22:09 ok Dec 03 15:22:13 the problem is different Dec 03 15:22:28 the problem is: what interfaces from mainline do you want/need Dec 03 15:22:36 not how other phones that are not mainline do it Dec 03 15:22:48 GNUtoo: sure but you might want to mention this in the commit message Dec 03 15:22:54 ok Dec 03 15:23:11 I'm more concerned about having a device that boot first Dec 03 15:23:43 I guess I need the patch I've shown in the pastebin first I guess Dec 03 15:23:53 but I fear that FIQ thing after that Dec 03 15:25:19 GNUtoo: but 2.6.39 boots, or are you trying to boot 3.x? Dec 03 15:26:02 the patches I cherry-picked were against 3.1 Dec 03 15:26:16 I need that microsd issue fixed.... Dec 03 15:26:24 oh right Dec 03 15:26:26 so I wanted to try a higer revision Dec 03 15:26:31 but the SD card is connected to glamo Dec 03 15:26:31 like 3.1 Dec 03 15:26:35 yes Dec 03 15:26:40 so it's quite unique Dec 03 15:26:43 but some patch are backported Dec 03 15:26:47 like mmc core patches Dec 03 15:27:06 so I wanted to see if glamo behaved better with a more recent kernel Dec 03 15:27:27 (that require porting some stuff including glamo forward tough) Dec 03 15:27:37 ok Dec 03 15:27:41 GNUtoo: well you don't need FIQ to boot Dec 03 15:27:57 GNUtoo: you only need it for getting battery current consumption readings and using the vibrator afaik Dec 03 15:28:18 ok Dec 03 15:28:56 GNUtoo: how familiar are you with git? Dec 03 15:29:47 I'm ok with git Dec 03 15:29:53 but git has too much functions Dec 03 15:29:57 so I don't know all of them Dec 03 15:30:40 GNUtoo: then you might want to just rebase the patches on top of 3.1.4 Dec 03 15:30:58 ok Dec 03 15:31:04 GNUtoo: if you only care about testing SD then you can ignore all the wlan and touchscreen stuff Dec 03 15:31:09 ok Dec 03 15:31:30 else I could try to mainline some patches Dec 03 15:31:35 but I wonder how to do it: Dec 03 15:31:39 more precisely: Dec 03 15:31:47 I am not the author of the patches Dec 03 15:32:34 but I can try Dec 03 15:32:47 I've already two patches in the kernel Dec 03 15:33:07 one is a rebase of a wireless patch for another driver Dec 03 15:33:13 one is support for a board Dec 03 15:34:36 yep I see Dec 03 15:36:30 GNUtoo: so you have all the experience to do more :) Dec 03 15:36:46 ok Dec 03 15:40:22 GNUtoo: anyways, 2.6.39 seems to sometimes hang in resume, this is a problem Dec 03 15:41:01 ok Dec 03 15:44:38 GNUtoo: btw 3.2.0-rc* are even more stable on my spitz than 3.1 was.. so if you plan to submit patches mainline maybe try 3.2-rc4 as base Dec 03 15:46:42 ok Dec 03 15:47:02 but zauruses are totally mainlined if I remember well Dec 03 15:47:16 yes, that's true Dec 03 15:48:36 I meant that efford and needed time to rebase patches and test on 3.1.4 and 3.2.0-rc will be similar and if you plan to submit it then better to be as close to linux-next as possible Dec 03 15:50:14 well, for testing patches that are supposed to go upstream, -next is probably more useful than the current -rc Dec 03 15:51:27 true, but to be able to add 3.2 with gta patches to OE when 3.2 gets out is 3.2-rc good compromise IMHO Dec 03 15:51:41 and then rebase to -next just before submitting them Dec 03 15:52:06 rebases just before submitting are frowned upon... Dec 03 15:52:32 it means they are pretty much untested Dec 03 15:53:20 at least that's my understading... Linus policies are a bit complex in this regard ;-) Dec 03 15:53:50 lindi-, http://www.pastie.org/2960222 Dec 03 15:53:55 that is upstream Dec 03 15:54:13 but I agree that if the purpose is preparing patches for the next local adaptation, rather than for immediate upstream submission, -rc is fine Dec 03 15:54:20 antrik: ah.. I meant rebase and test again, but it should be easier to do it from 3.2-rc to -next then 3.1.3 to -next Dec 03 15:54:41 indeed :-) Dec 03 15:55:04 developing against stable releases is generally not a good idea Dec 03 15:56:18 GNUtoo: oh really? can you please add link to the upstream commit to the wiki? Dec 03 15:59:54 done Dec 03 16:00:07 I've moved to another page and added the whole commit message Dec 03 16:02:28 GNUtoo: hmm? but the complete patch is not upstream? Dec 03 16:02:51 GNUtoo: it also modifies arch/arm/mach-s3c2410/include/mach/gpio.h Dec 03 16:03:22 I didn't make theses patches Dec 03 16:03:23 GNUtoo: also I would not remove that patch from the page since the patch still is exists in 2.6.39 Dec 03 16:03:28 so I'm not fluent with that Dec 03 16:04:08 in any case, I think we want to list the patch on the page even if it has been upstreamed Dec 03 16:04:40 I'll rewrite that entry Dec 03 16:05:22 ok Dec 03 16:06:47 Slyon: nice talk :) Dec 03 16:07:09 mrmoku, thank you :) Dec 03 16:07:42 mrmoku, maybe we should collect all shr presentation material at some central space in shr-trac? Dec 03 16:08:52 GNUtoo: reload? Dec 03 16:09:23 ? Dec 03 16:09:28 Slyon: that's a good idea Dec 03 16:10:12 Slyon: and there's one point you said which made me think we should change that Dec 03 16:10:14 GNUtoo: I updated the wiki :) Dec 03 16:10:21 Slyon: confusion on build.shr-project.org Dec 03 16:10:22 GNUtoo: seems there might be other patches that are also upstream. Dec 03 16:10:30 GNUtoo: nice, we don't need to do all the work, we can just watch :) Dec 03 16:10:45 Slyon: would be an easy thing to have a page there explaining stuff Dec 03 16:10:50 mrmoku, yeah. we should even have a "real" download page... written in html Dec 03 16:10:55 GNUtoo: half of "s3c24xx: Fix level irqs on external interrupts. Dec 03 16:10:56 yes Dec 03 16:10:56 yup Dec 03 16:10:58 GNUtoo: seems to be upstream too! Dec 03 16:11:34 mrmoku, i'll create a page at shr trac and put pespin's and my slides there Dec 03 16:11:41 GNUtoo: or hmm Dec 03 16:12:04 Slyon: great Dec 03 16:12:04 GNUtoo: actually not Dec 03 16:12:27 GNUtoo: we should go through all the patches and see if they are partially already upstream Dec 03 16:18:41 ok Dec 03 16:38:40 bbs Dec 03 16:38:46 reboot (USB issue) Dec 03 17:05:38 lindi-, any idea of what the offset is? Dec 03 17:05:50 like PLAT_PHYS_OFFSET Dec 03 17:06:00 I'm searching it since too long Dec 03 17:16:54 http://wiki.openmoko.org/wiki/Neo_FreeRunner_Memory_Mapping Dec 03 17:17:02 0x30000000 Dec 03 17:17:40 hmmm Dec 03 17:17:55 the mem seem discontinuous Dec 03 17:18:12 64+64 Dec 03 17:29:14 hi DocScrutinizer Dec 03 17:29:34 freesmartphone.org: 03mickey 07vala-terminal * r0fefa3808758 10/ (4 files in 3 dirs): Dec 03 17:29:34 freesmartphone.org: fix make distcheck Dec 03 17:29:34 freesmartphone.org: bump vala requirement to 0.12 Dec 03 17:29:34 freesmartphone.org: release as vala-terminal 0.13 Dec 03 17:31:14 my first commit since months ;) Dec 03 17:31:46 I've some issues too with making commits Dec 03 17:32:37 mickey|munich: great! do you have commit for meta-fso too or should I bump it there? Dec 03 17:32:43 hi GNUtoo Dec 03 17:33:13 DocScrutinizer, I've some issues getting the log buffer of my kernel on om-gta02 Dec 03 17:33:16 when I do that: Dec 03 17:33:23 md 0x307b2321 Dec 03 17:33:30 it resets the CPU with data abort error Dec 03 17:33:37 ummm Dec 03 17:33:43 NFC Dec 03 17:33:44 JaMa|Wrk: please bump that, i'm somewhat out of the loop wrt. oe Dec 03 17:33:51 c07b2321 b __log_buf is in system.map Dec 03 17:34:09 and 0x30000000 seem to be the physical offset Dec 03 17:34:27 mickey|munich: ok.. btw there is typo in commit release as vala-terminal 0.13 (should be 1.3 according to configure.ac) Dec 03 17:35:04 oops, indeed Dec 03 17:35:08 oh well Dec 03 17:35:12 the tarball name counts Dec 03 17:35:20 GNUtoo: tbh I didn't even know we got a log buffer other than the RAM based dmesg buffer on GTA02 Dec 03 17:35:37 * JaMa|Wrk haven't seen tarball, but noticed while updating PV in _git recipe Dec 03 17:35:39 that's what I'm after: dmesg buffer Dec 03 17:35:41 a looong time ago I pushed for that mtdlog thing Dec 03 17:35:48 bbl, dinner Dec 03 17:35:54 else I'll just recompile and add early printk on serial console Dec 03 17:36:57 GNUtoo: I think lindi- was the expert about that stuff, back when Dec 03 17:37:42 ok Dec 03 17:37:57 some magic patch in kernel writing the buffer to swap on kernel panic etc Dec 03 17:38:24 I almost forgot about each detail of all that Dec 03 17:38:47 just that original buffer in RAM was waaay too smal, just holding 16k or sth Dec 03 17:38:47 there is also other stuff such as: Dec 03 17:38:54 *ramconsole Dec 03 17:38:58 *mtdoops Dec 03 17:38:59 etc... Dec 03 17:39:03 yes, that's the one I think Dec 03 17:39:25 couldn't recall the names Dec 03 17:40:13 ramconsole writing stuff to a ringbuffer instead of console, mtdoops somehow saving back from swap on boot - IIRC Dec 03 19:47:48 JaMa|Off: yay :-) Dec 03 19:48:32 hehe Dec 03 19:48:55 but I'll start new 003 build before leaving.. :) Dec 03 19:49:40 * JaMa|Off a bit sad that nobody replied on "staging" email or added more test results.. Dec 03 19:50:13 JaMa|Off: I was waiting for you changing your nick :) Dec 03 19:50:45 systemd branch still wants elsa-systemd Dec 03 19:51:02 ah :) but still @Wrk.. :) Dec 03 19:51:21 yes you have to revert last 2 patches and the should be enough Dec 03 19:51:26 ok Dec 03 19:51:41 actually one, but I guess you will need initscripts installed for /etc/init.d/functions Dec 03 19:51:48 which are used from xserver-common Dec 03 19:51:50 JaMa|Off: another small question... shr branch from oe-core is fine too? Dec 03 19:52:09 yup I've dropped jansa/test because it was the same as shr now Dec 03 19:52:20 ok, that's why it looked quite old :) Dec 03 19:52:26 DocScrutinizer: linux 3 has ramoops, unfortunately only as a platform driver Dec 03 19:52:41 mrmoku: it is still in repo ? Dec 03 19:53:04 http://git.openembedded.org/openembedded-core-contrib/refs/heads there is only jansa/pull now Dec 03 19:53:44 mrmoku: and jansa/test in meta-oe is also gone.. I'll try to live with just local jansa/test with shr and jansa/systemd merged to it (not worth publishing) Dec 03 19:53:55 JaMa|Off: it is on my lapop Dec 03 19:54:01 including the origin one though Dec 03 19:56:24 JaMa|Off: origin/jansa/test Dec 03 19:56:31 from git origin -r Dec 03 19:57:08 ok keeping meta-oe jansa/test Dec 03 19:57:29 in case you're using Makefile it will be easier for track both shr and jansa/systemd branches.. Dec 03 19:57:45 lindi-: mhm, nice. Alas I actually forgot how things worked for GTA02. Seems GNUtoo is highly interested though Dec 03 19:58:13 lindi-: I know you had all the bits together back when we talked about it Dec 03 19:58:37 my ramconsole patch was not accepted upstream in case you wonder that :) Dec 03 19:59:19 maybe I wondered about that, I just can't recall what were the problems and if we got it into default gta02 kernel or not Dec 03 19:59:34 depends on what default gta02 kernel means :) Dec 03 19:59:38 I know I pushed to get this nice function Dec 03 19:59:58 mainline almost has it Dec 03 20:00:08 just only for oops messages and only as platform driver Dec 03 20:00:28 but I think the platform driver requirement was fixed later but not sure if that is in linus's tree yet Dec 03 20:00:35 so can you help GNUtoo and answer his questions? Dec 03 20:01:30 [2011-12-03 18:29:36] DocScrutinizer, I've some issues getting the log buffer... Dec 03 20:01:32 pespin_: hey, are you using efm? Dec 03 20:01:43 lindi-, my problem is that I'd like to get the log buffer with md within uboot Dec 03 20:01:49 I tried that: Dec 03 20:01:50 mrmoku, I'd guess nobody uses it :P Dec 03 20:02:16 I rarelly use a file manager. When I need some I usually run pcmanfm Dec 03 20:02:24 c07b2321 b __log_buf is in system.map | sed 's/^c/0x3/' Dec 03 20:02:25 ok :) Dec 03 20:02:34 why? Dec 03 20:02:37 I retried it today... got a lot better Dec 03 20:02:45 but I'm missing some things Dec 03 20:02:51 hmm I'll give it a try then :P Dec 03 20:02:52 like binding keys to actions on files Dec 03 20:03:08 or shortcuts for the favorites Dec 03 20:03:29 GNUtoo: but don't you need to be manually present when the crash occurs that way? Dec 03 20:03:55 ? Dec 03 20:05:13 TAsn: do you use efm? Dec 03 20:05:58 heck no :P Dec 03 20:06:03 :P Dec 03 20:06:15 do I strike you as a self hater? :P Dec 03 20:06:16 who's using it? P Dec 03 20:06:23 dunno Dec 03 20:06:28 fun ;) Dec 03 20:06:54 I retried it today Dec 03 20:06:57 freesmartphone.org: 03barklome 07settings-rework * ra5284c19fb3d 10aurora/aurora-daemon/src/applications/app-settings/ (5 files in 5 dirs): aurora-daemon: settings: clean qmldir file Dec 03 20:07:00 and it's almost usable Dec 03 20:07:10 yeah Dec 03 20:07:13 it's getting better all the time Dec 03 20:07:48 * mrmoku wanted to know how to fire gitk in the current folder when pressing a key Dec 03 20:10:32 I just added a new script Dec 03 20:10:33 called Dec 03 20:10:35 filemanager Dec 03 20:10:39 that calls nautilus Dec 03 20:10:42 with --no-desktop Dec 03 20:10:44 and just use that Dec 03 20:10:47 everywhere Dec 03 20:11:20 heh Dec 03 20:11:25 TAsn: shame on you ;) Dec 03 20:11:58 :P Dec 03 20:12:01 s/enlightenment\/developer/gnome-junkie/ ;) Dec 03 20:12:06 haha Dec 03 20:12:11 nah Dec 03 20:12:12 honestly Dec 03 20:12:21 I hate almost everything they do in gnome land Dec 03 20:12:24 especially gconf Dec 03 20:12:30 j/k Dec 03 20:12:34 they used to be so great Dec 03 20:12:36 ages ago Dec 03 20:12:39 but now they suck :P Dec 03 20:13:01 but why? they know better than you how your desktop should behave ;) Dec 03 20:13:11 true :P Dec 03 20:13:17 I used to have all those pesky config options Dec 03 20:13:23 and now they removed them Dec 03 20:13:26 that made me a lot happier Dec 03 20:13:44 cause now I don't waste my time on tweaking the env to what I like Dec 03 20:13:50 :) Dec 03 20:13:58 btw. I'm still quite happy with e Dec 03 20:14:12 just some things that used to work better in kde... Dec 03 20:14:22 like pa integration Dec 03 20:14:31 or removeable disks integration Dec 03 20:14:46 yeah Dec 03 20:14:50 both are the very weak spots Dec 03 20:14:58 both will be fine before release though Dec 03 20:15:08 nice... looking forward :) Dec 03 20:15:13 me too Dec 03 20:15:19 although I don't think I'll be moving to pa Dec 03 20:15:27 (alsa still works better) Dec 03 20:15:44 at least worked better the last time I tried Dec 03 20:17:59 one thing I like about pa is the moving of streams between devices Dec 03 20:18:09 which is the thing I'm missing in e's mixer :) Dec 03 20:36:02 JaMa|Off: hmm... I tried to be tricky and put TCLIBCAPPEND = "-systemd" Dec 03 20:36:13 in my local conf to keep the other tmpdir Dec 03 20:36:42 build failed with a libtool version mismatch error on subversion-native Dec 03 20:36:49 dunno if that is related Dec 03 21:19:20 freesmartphone.org: 03barklome 07settings-rework * r0696c1792aa3 10aurora/aurora-daemon/src/applications/app-settings/ (5 files in 5 dirs): Dec 03 21:19:20 freesmartphone.org: Revert "aurora-daemon: settings: clean qmldir file" Dec 03 21:19:20 freesmartphone.org: It still being used by SettingsPage Dec 03 21:19:20 freesmartphone.org: This reverts commit a5284c19fb3de5570283c5f550a0cd52f6069fb8. Dec 03 21:31:32 freesmartphone.org: 03barklome 07settings-rework * rd28d5527cab1 10aurora/aurora-daemon/src/applications/app-settings/main.qml: aurora-daemon: settings: remove non-used close function Dec 03 21:52:49 GNUtoo, hi! I'm trying the gstreamer + BT stuff Dec 03 21:53:02 ok Dec 03 21:53:09 the test in gstreamer-properties work OK Dec 03 21:53:20 I get sound on the headsets Dec 03 21:53:28 but enjoy still outputs sound to speakers Dec 03 21:54:19 ah ok hmmm Dec 03 21:54:24 ugh weird Dec 03 21:54:27 it seems it wasn't saved Dec 03 21:54:42 I reopened gst-properties and I get default device u.u Dec 03 21:55:35 Is there someway to get a device's name (e.g. "Nokia N900" | "Palm Pre") from dbus or even from a file (maybe in /proc) ? Dec 03 21:56:30 angelox|laptop, afaik fso gets it from /proc/cpuinfo Dec 03 21:56:33 or similar Dec 03 21:57:52 pespin_: but that would return the common device name? or just cpu informations (like org.freesmartphone.Device.Info.GetCpuInfo) Dec 03 21:57:59 i'm without any device to test :( Dec 03 22:01:46 btw excuse me interrupting your conversation pespin_<->GNUtoo ; i thought you both would continue talking after my question :( Dec 03 22:02:00 GNUtoo: how do you plan to type those u-boot commands? Dec 03 22:02:14 angelox|laptop, np :) Dec 03 22:02:18 angelox|laptop, grep Hardware /proc/cpuinfo Dec 03 22:02:38 lindi-, md? Dec 03 22:04:35 GNUtoo: thanks,didn't know there were that section in cpuinfo Dec 03 22:05:03 else maybe you can get that too with fso Dec 03 22:08:20 GNUtoo: yes Dec 03 22:08:30 GNUtoo: is your phone constantly connected to your PC? Dec 03 22:08:37 lindi-, yes Dec 03 22:08:37 GNUtoo: here the crashes happen randomly Dec 03 22:08:57 lindi-, md crash? Dec 03 22:09:08 GNUtoo: linux crash on resume Dec 03 22:09:13 ah ok Dec 03 22:09:41 ahh I guess you want to dump dmesg for dumping the error on resume Dec 03 22:21:37 angelox|laptop: grep Hardware /proc/cpuinfo even works on maemo Dec 03 22:22:14 FYI: N900 codename is RX-51 Dec 03 22:22:40 Freerunner's is GTA02 Dec 03 22:23:53 N950: RM-680; N9: RM-696; Neo1973: GTA01 Dec 03 22:25:20 I don't think the marketing names appear anywhere in a rootfs on any defined location Dec 03 22:31:57 htcdream: trout, nexusone:mahimahi, nexus S: herring Dec 03 22:32:02 I'll go bye Dec 03 22:38:05 DocScrutinizer: So it will show the code name..i'll need to do an comparing database for what i'm thinking Dec 03 22:38:21 right Dec 03 22:38:31 and i haven't anymore n900 :( Dec 04 01:04:57 DocScrutinizer: grep Hardware /proc/cpuinfo,will for example return "Hardware : RX-51" or "Hardware :RX-51" or even "Hardware: RX-51" Dec 04 01:06:11 moment please Dec 04 01:06:35 ok Dec 04 01:07:34 Hardware : Nokia RX-51 board Dec 04 01:08:17 Thanks Dec 04 01:11:16 mrmoku: weird it should not be related Dec 04 01:53:24 good night guys **** ENDING LOGGING AT Sun Dec 04 02:59:58 2011