**** BEGIN LOGGING AT Tue Aug 03 02:59:57 2010
Aug 03 06:30:43 <vanous> JaMa: some hockey here in distro kernels :)
Aug 03 06:31:28 <vanous> i had manually installed 2.6.32-16 but would like to replace it by the opkg provided one
Aug 03 06:31:31 <vanous> what is the default kernel now?
Aug 03 06:31:44 <vanous> better say
Aug 03 06:31:51 <vanous> what package is to install it?
Aug 03 06:32:03 <vanous> kernel-2.6.32.16 or kernel-image-2.6.32.16
Aug 03 06:34:51 <vanous> as i had removed it at first and it took all dependences, but now i don't know what package holds the dependences to bring them back 
Aug 03 06:59:22 <JaMa> vanous: 2.6.32.16 is default now
Aug 03 06:59:43 <JaMa> vanous: ie some kernel-modules are deps of task-base package
Aug 03 06:59:59 <JaMa> vanous: but safer to download whole modules.tgz
Aug 03 07:00:16 <vanous> ok
Aug 03 07:00:17 <mrmoku> I think question was if kernel or kernel-image is the correct one
Aug 03 07:01:12 <vanous> well, mrmoku, i thought it would bring the deps with it, so the question was _what is the right kernel package to safely install all modules with it_ :)
Aug 03 07:01:29 <mrmoku> yeah :)
Aug 03 07:01:47 <mrmoku> JaMa: did the origami trick work out? :P
Aug 03 07:03:03 <JaMa> kernel depends on kernel-2.6.34 which depends on kernel-image-2.6.34
Aug 03 07:03:28 <JaMa> mrmoku: haven't tried yet, yesterday was different pub and she wasn't there
Aug 03 07:03:58 * JaMa has to prepare it for Thursday party :)
Aug 03 07:07:37 <JaMa> 2.6.32.17 :)
Aug 03 07:41:12 <mrmoku> JaMa: ahh... machine arch for task-shr-feed... good thing :-)
Aug 03 07:41:25 <mrmoku> ohhhh alignment traps fix :D
Aug 03 07:42:06 <mrmoku> hmm... just finished building qt4 and yet inclined to rm -rf tmp ;)
Aug 03 07:44:35 <JaMa> mrmoku: not really fix :/
Aug 03 07:45:03 <JaMa> mrmoku: it fixes some alignment traps with futexes, but still lots of other traps as before :/
Aug 03 07:45:15 <zub> morgen
Aug 03 07:45:39 <zub> JaMa: FYI: I sent the webkit-efl patch to the OE ML + contacted Chaitanya to let him know
Aug 03 07:46:12 <mrmoku> JaMa: ohh.. k... pity :P
Aug 03 07:46:19 <zub> his reply was he's gonna update ventura to the new api
Aug 03 07:46:20 <JaMa> zub: seen that
Aug 03 07:46:22 <zub> ok
Aug 03 07:46:26 <JaMa> thanks
Aug 03 07:46:30 <zub> n/p
Aug 03 10:33:05 <rhkfin> JaMa: SHR-T from 29th of May, I concider this as ~critical: > 1) Importing contacts from SIM sometimes imports only partial number,
Aug 03 10:33:08 <rhkfin> > the last digit is missing
Aug 03 10:33:29 <rhkfin> (it also keeps telling me it couldn't add a contact..)
Aug 03 10:36:47 <vanous> rhkfin: is this an issue in -u, would you know?
Aug 03 10:37:06 <rhkfin> no idea
Aug 03 10:37:18 <rhkfin> but don't think so, as I haven't heard anyone else report it
Aug 03 10:38:48 <rohezal> Weiss: here is a clipping technique without XClipmask instead it uses "xor" and "and". Is it hard accelerated?
Aug 03 10:44:10 <vanous> rhkfin: this happens with...Pisi?
Aug 03 10:44:39 <vanous> rhkfin: or the sim manager?
Aug 03 10:44:46 <rhkfin> vanous: SIM manager
Aug 03 10:51:57 <rohezal> http://www.int.gu.edu.au/~anthony/info/X/Programing.hints
Aug 03 10:52:09 <rohezal>     XSetClipMask( display, gc, bitmapmask );
Aug 03 10:52:10 <rohezal>     XSetClipOrigin( display, gc, 0, 0 );
Aug 03 10:52:10 <rohezal>     XCopyArea( display, pixmap, XtWindow(widget), gc, 0, 0,
Aug 03 10:52:10 <rohezal>                    width, height, 0, 0 ); 
Aug 03 10:52:10 <rohezal>     /* clean up */
Aug 03 10:52:10 <rohezal>     XSetClipMask( display, gc, None );
Aug 03 10:57:22 <JaMa> Martix: pushed 2.6.32.17, 1.9M, but had to move brtfs/xfs to modules too
Aug 03 11:04:29 <Martix> JaMa: Alsa is moved to modules, too?
Aug 03 11:12:05 <JaMa> Martix: y
Aug 03 11:12:31 <JaMa> Martix: http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=b196b4ea4b124c2ea22d5823847a653252dbdcf3
Aug 03 11:15:17 <Martix> ok, thanks
Aug 03 11:49:36 <Weiss> rohezal: blitting with those raster ops should be accelerated, yep..
Aug 03 11:49:37 <dos1> can someone ping me if he'll have some information about Poland today in his news media?
Aug 03 11:50:48 <rohezal> Weiss: testing with XClipmask now
Aug 03 11:51:13 <rohezal> Weiss: 50 FPS most time but every third second it falls to 11 FPS. Then it went up to 50 FPS. Its quite smooth. 
Aug 03 11:51:30 <rohezal> Blitting the background (640x480) and one 64x64 Skull Sprite.
Aug 03 11:55:40 <Weiss> with transparency?
Aug 03 11:57:08 <Weiss> copying the whole background every time?
Aug 03 11:57:41 <rohezal> yes
Aug 03 11:57:47 <rohezal> sounds crazy i know^^
Aug 03 11:57:51 <rohezal> but 50 is realy fast
Aug 03 11:57:55 <rohezal> the glamo isnt this bad :) 
Aug 03 11:58:16 <rohezal> Weiss: but the strange thing is: every third second the speed is about 11 FPS
Aug 03 11:58:25 <rohezal> then it went up for 2 seconds
Aug 03 12:00:19 <Weiss> very cool :D
Aug 03 12:00:28 <rhkfin> dos1: what's your plan concidering Poland..?
Aug 03 12:00:36 <Weiss> what does "top" say? is something else taking CPU time periodically?
Aug 03 12:00:41 <Weiss> (SD card access?)
Aug 03 12:00:42 <dos1> rhkfin: my plan?
Aug 03 12:00:57 <rohezal> im checking it
Aug 03 12:00:59 <dos1> rhkfin: i'm curious, cause i'm from Poland
Aug 03 12:01:13 <rhkfin> dos1: ok :)
Aug 03 12:01:57 <rhkfin> thought you're going to do something that might get to the news abroad :)
Aug 03 12:04:02 <rohezal> Weiss: looks like a CPU problem. running top and myblit is decreasing the the 11 FPS to 8 FPS
Aug 03 12:04:17 <rohezal> Weiss: but its 50 FPS when in the 2 other seconds
Aug 03 12:04:23 <Weiss> rohezal: how much CPU usage is your program taking?
Aug 03 12:04:37 <rohezal>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
Aug 03 12:04:37 <rohezal>  1563 root      20   0 11392 4524 1608 R 97.4  3.6  39:12.87 X                  
Aug 03 12:04:37 <rohezal>  1837 root      20   0  2480 1108  900 R  1.9  0.9   0:01.34 top                
Aug 03 12:04:37 <rohezal>  1838 root      20   0 16112 2964 2348 S  0.3  2.4   0:00.70 myblit             
Aug 03 12:04:53 <rohezal> Weiss: top output
Aug 03 12:15:14 <rohezal> i can upload the source with the makefile. just make and it works. should i upload it so you can test it yourself?
Aug 03 12:18:22 <Martix> ~seen radekp
Aug 03 12:18:24 <apt> radekp <~radek@63.120.broadband10.iol.cz> was last seen on IRC in channel #openmoko, 3d 20h 34m 49s ago, saying: 'hmm gotta go for now bbl'.
Aug 03 12:20:11 <mrmoku> rhkfin: that was an issue with fsogsmd... looong ago
Aug 03 12:20:19 <mrmoku> should not happen in shr-u
Aug 03 12:21:55 <mrmoku> dos1: no poland related news here
Aug 03 12:25:12 <rohezal> dont know if someone want to look at it but its up
Aug 03 12:25:12 <rohezal> http://rapidshare.com/files/410770570/myblit.zip
Aug 03 12:25:24 <rohezal> the blitting with transparent pixel and XsetClipMasp
Aug 03 12:25:26 <rohezal> the blitting with transparent pixel and XsetClipMask
Aug 03 12:27:06 <vanous1> dos1: nothing here, just zimny lech...
Aug 03 12:29:50 <rohezal> Weiss: upload done when u want to look at it
Aug 03 12:30:51 <dos1> nice then
Aug 03 12:31:10 <dos1> it's really shame what happened around this cross today...
Aug 03 12:32:18 <mrmoku> dos1: polish secret service blocking the news then :P
Aug 03 12:34:32 <rohezal> Weiss: just want to know. you will implement sometime the clipping support via XsetClipMask with Hardware acceleration right?
Aug 03 12:35:15 <dos1> mrmoku: i hope so :P
Aug 03 12:37:18 <Martix> dos1: what happend?
Aug 03 12:37:32 <Weiss> rohezal: the Xrender stuff? I'll try..
Aug 03 12:38:41 <rohezal> Weiss: Xrender would be great :). But this function alone would be enough for me too (the whole xrender would be better of course :) ) 		XSetClipOrigin(mainwindow->display, mainwindow->gc, 0+mover, 60);
Aug 03 12:38:41 <rohezal> 		XSetClipMask(mainwindow->display, mainwindow->gc, skullImage.clipmask);
Aug 03 12:39:57 <dos1> Martix: bunch of stupid people disallowed to move cross from Presidential Palace (which scouts placed there after airplane crash) to church
Aug 03 12:40:30 <dos1> they did riot in name of "protecting holy cross"
Aug 03 12:40:35 <Weiss> rohezal: but that maps on to Xrender I think (or rather, I guess/assume..)
Aug 03 12:43:40 <rohezal> <-noob. ^^ i dont know.
Aug 03 12:47:02 <rohezal> but use only xlib
Aug 03 12:47:04 <rohezal> not xrender
Aug 03 12:52:44 <Martix> dos1: oh
Aug 03 13:01:43 <Weiss> rohezal: never mind.. I was just commenting on which bit of the driver is missing to support this
Aug 03 14:34:01 <rohezal> Weiss: you want to know. are you working for FIC or are you doing it in your freetime?
Aug 03 14:39:00 <rohezal> Weiss: you want to nkow = just want to know. srr
Aug 03 14:59:16 <Weiss> rohezal: free time definitely :)
Aug 03 14:59:32 <rohezal> Weiss: wtf... respect man :)
Aug 03 15:47:55 <mickey|office> no one here is still working for FIC
Aug 03 15:58:52 <rohezal> mickey: i read that some people are  still paid for coding... is it wrong?
Aug 03 16:18:15 <dos1> rohezal: yep, it seems to be wrong
Aug 03 16:18:44 <dos1> rohezal: Openmoko Inc is now just company behind WikiReader :P
Aug 03 16:19:09 <rohezal> does the wikireader sells well? 
Aug 03 16:19:29 <rohezal> dos1: or better asked: well enough for the company to survice
Aug 03 16:20:17 <dos1> rohezal: you should probably ask them somehow. i don't think many people here are still interested in what Om Inc does
Aug 03 16:21:12 <dos1> but AFAIK they do some contests and promotions, so probably well enough
Aug 03 16:22:10 <rohezal> ohh sounds like there were some problems between OM Inc and the community
Aug 03 16:22:33 <rohezal> just out of curiosity, has it something to do with the nda for the glamo?
Aug 03 16:33:02 <ChristW> I can't reacht my FR at the moment! WiFi and USB don't work. What can I do to reach it and/or update it?
Aug 03 16:33:41 <Weiss> rohezal: not really.. just OM Inc's management was catastrophically bad at community relations
Aug 03 16:34:22 <Weiss> there's an article somewhere on the web about how a company can kill off a free software project even while funding it - the things OM did could almost have been taken straight from that
Aug 03 16:34:59 <rohezal> sounds hard
Aug 03 16:35:06 <rohezal> hmm ok enough interwebz today
Aug 03 16:35:13 <rohezal> im going to buy some beer :D
Aug 03 16:35:19 <rohezal> thx weiss for your help
Aug 03 16:35:21 <rohezal> bye guys
Aug 03 16:35:57 <Weiss> enjoy
Aug 03 16:39:12 <tmzt> Weiss: esr's?
Aug 03 16:42:12 <Weiss> oo maybe
Aug 03 16:42:53 <Weiss> it really does read depressingly like a list of things OM did
Aug 03 16:43:25 <tmzt> wasn't it about Sun?
Aug 03 16:43:32 <tmzt> not sure if it was esr or the ex-Sun guy
Aug 03 16:44:05 <Weiss> might have been this: http://www.itwire.com/opinion-and-analysis/open-sauce/30541-lca-2010-wanna-kill-a-foss-community
Aug 03 16:45:30 <Weiss> items 1, 3, 4, maybe 7, maybe 9, definitely 10
Aug 03 16:48:38 <ChristW> Still, too bad it _was_ handled this way. I still think Sean's intentions were good, but, indeed, the actual implementation (of the process) sucked.
Aug 03 16:50:30 <ChristW> ...so here I am, upgrading my phone over GPRS, since the bunch of lunatics that are still interested in getting this thing going broke something :-D
Aug 03 16:50:33 <Weiss> yeah, I agree with that totally
Aug 03 16:51:00 <ChristW> (for the humor-impaired... that was tongue-in-cheek)
Aug 03 16:51:31 <ChristW> It's great that this little phone does all this... and more. But there's a lot of man-power missing!
Aug 03 16:52:39 <ChristW> Had I been Sean, I think I'd been focussing on getting the kernel and the base system rock-solid, and pushing things upstream, and letting the community fill in user land apps. But hey, it's not my call!
Aug 03 17:00:22 <tmzt> ChristW: isn't that what they did?
Aug 03 17:01:13 <ChristW> Well, first there was 2007.2, then there was Om2008(.something), then there were other changes... It was a road map... to hell.
Aug 03 17:01:42 <tmzt> ChristW: yes, but gta01 wasn't intended as a finished device and the userland wasn't all there
Aug 03 17:01:52 <tmzt> there's a great discussion on the gta03 list
Aug 03 17:27:38 <lindi-> DocScrutinizer: hmm, are those "NEW:" and "new:" names in http://wiki.openmoko.org/wiki/Neo1973_Audio_Subsystem actually just comments? I don't see any kernel implementing either one of those
Aug 03 17:28:20 <DocScrutinizer> larsc was about to implement them, but seems that never happened
Aug 03 17:28:35 <larsc> what what what?
Aug 03 17:28:56 <DocScrutinizer> ALSA aliases
Aug 03 17:29:11 <DocScrutinizer> or even sane renaming
Aug 03 17:29:15 <lindi-> DocScrutinizer: ok, I'll mark them as comments
Aug 03 17:29:21 <lindi-> no more renamings please :)
Aug 03 17:29:34 <lindi-> .32 already renames things and breaks things :P
Aug 03 17:30:11 <DocScrutinizer> yeah, it's actually so great when headphones controlls speaker, and speaker controlls earpiece, and sidetone controlls mic, or somesuch
Aug 03 17:31:48 <lindi-> one reads what registers the controls change and then reads the datasheet to figure out what they do :)
Aug 03 17:32:06 <DocScrutinizer> "it's utter BS and completely wrong, but we got used to it and now we love it - so let's keep it"
Aug 03 17:32:53 <DocScrutinizer> lindi-: datasheet won't help you out of hat, unless you know to read schematics
Aug 03 17:33:55 <lindi-> DocScrutinizer: yep that too
Aug 03 17:34:22 <DocScrutinizer> what a steaming pile of shit the GSM mic master control is on the "playback" tab of mixers even
Aug 03 17:35:22 <DocScrutinizer> but meh, do what you want - I gave up on OM audio long ago. Will be borked forever, as nobody cares to do it correctly
Aug 03 17:36:57 <lindi-> heh, no userland alsa tool probably was prepared for this sort of complexity
Aug 03 17:37:15 <DocScrutinizer> and in the end, if ever it gets fixed, then OM community is missing their best running gag: "My audio sucks! please help!!!"
Aug 03 17:37:43 <lindi-> well surely that won't help with call quality problems much
Aug 03 17:37:56 <DocScrutinizer> pff
Aug 03 17:38:11 <lindi-> anyways, I'm currently trying to route audio from aplay to GSM :)
Aug 03 17:38:20 <lindi-> GSM to arecord works already
Aug 03 17:38:45 <DocScrutinizer> users fiddling with alsa mixer settings in statefiles and elsewhere, without any decent clue due to general madness of OM alsa config - that's what doesn't help
Aug 03 17:39:41 <lindi-> yep it's pretty confusing :)
Aug 03 17:40:10 <lindi-> I'm used to being able to just strace to see what is happening but it kind of does not help here
Aug 03 17:40:22 <DocScrutinizer> the whole ALSA statefiles and naming and all was evidently a "messe hack" to show off something on very first gta01 prototypes. And it never got replaced by something decent
Aug 03 17:41:18 <lindi-> DocScrutinizer: sure but you can do renaming in userland if you really want to
Aug 03 17:41:49 <DocScrutinizer> instead of doing a clean cut, everybody was fiddlng with controls and inventing one layer above another layer, to deal with that shit
Aug 03 17:42:10 <DocScrutinizer> renaming in userland being one of those botch layers
Aug 03 17:42:48 <DocScrutinizer> as that OM GTA02 specific patch had to go into *every* app dealing with audio and mixer
Aug 03 17:43:23 <DocScrutinizer> so why not just dump OM the OS and use andridiot instead?
Aug 03 17:43:35 <lindi-> I'm not using OM OS
Aug 03 17:43:37 <DocScrutinizer> just as proprietary
Aug 03 17:43:39 <lindi-> I'm using OM hardware
Aug 03 17:44:03 <lindi-> I don't know much about android hardware
Aug 03 17:44:20 <DocScrutinizer> yeah, and your own proprietary OS which you cheatingly claim is debian
Aug 03 17:44:35 <lindi-> it's debian with pretty tiny modifications
Aug 03 17:44:43 <lindi-> I think even my desktop has larger modifications
Aug 03 17:45:01 <DocScrutinizer> ALSA control renaming in userspace -c'mon don't kid me
Aug 03 17:45:21 <lindi-> I'm not doing that
Aug 03 17:45:32 <lindi-> I said you could if you wanted :)
Aug 03 17:45:46 <DocScrutinizer> anyway, /me leaving... *yawning*
Aug 03 18:03:38 <Trevinho> Hello... I'm using SHR-unstable from µSD... It works quite well
Aug 03 18:03:55 <Trevinho> but I've a lot of Alignment trap messages from kernel
Aug 03 18:04:22 <Trevinho> I've read something about it, but is it an issue?
Aug 03 18:04:30 <Trevinho> Can or should it be solved?
Aug 03 18:04:44 <Trevinho> I don't know if all this logging could cause a little slowdown of the running applications...
Aug 03 18:04:51 <Weiss> Trevinho: should be fixed pretty soon I think - there was a patch of some kind
Aug 03 18:04:51 <Trevinho> and how could I hide it?
Aug 03 18:04:59 <Trevinho> ok...
Aug 03 18:05:17 <Trevinho> Weiss: is the patch public or available somewhere?
Aug 03 18:05:58 <Weiss> best to ask JaMa or one of the distro people - definitely public, but takes a lot of rebuilding
Aug 03 18:06:07 <Weiss> assuming that it corrects the real cause of the traps
Aug 03 18:07:20 <Trevinho> Mh, ok... I've not found it anywhere...
Aug 03 18:31:49 <Martix> somebody knows about any D-Bus benchmark?
Aug 03 18:34:47 <gena2x> heh
Aug 03 18:42:06 <Martix> gena2x: D-Bus performance is going to be crucial for us, we use D-Bus a lot :-)
Aug 03 18:43:32 <gena2x> yeah, this fact is always in mi mind while i am thinking about fso :)
Aug 03 18:43:38 <gena2x> s/mi/my/
Aug 03 18:43:39 <apt> gena2x meant: yeah, this fact is always in my mind while i am thinking about fso :)
Aug 03 18:44:19 <Martix> maybe FSO is the right benchmark :-)
Aug 03 18:44:46 <Martix> mickeyl: no offence, I like FSO :-)
Aug 03 18:48:04 <Martix> mickeyl: back to my question, do you know about D-Bus benchmarks?
Aug 03 19:04:38 <dos1> ohhh, ts filtering is must-have :x
Aug 03 19:04:57 <dos1> (how could i live without it on 2.6.24 and Om2007.2?)
Aug 03 19:05:09 <dos1> (and yep, testing 2.6.34 now :D)
Aug 03 19:15:52 * dos1 wants 2.6.34 as soon as possible
Aug 03 19:16:07 <dos1> 2.6.32 is unstable for me
Aug 03 19:16:42 <dos1> (well, i'm kind of person who can live with unstable software, but i still prefer when my system does not hang randomly :P)
Aug 03 19:17:36 <dos1> gena2x: by "fixing touchscreen in 2.6.34" you mean fixing filtering, or what?
Aug 03 19:26:05 <Martix> dos1: wasnt ts filtering on Om 2007.2 implemented by userspace tslib?
Aug 03 19:29:55 <dos1> Martix: dunno. I just remember that at beginning it worked just like now with 2.6.34
Aug 03 19:30:28 <dos1> Martix: and some time later touchscreen became much more useable
Aug 03 19:41:42 <gena2x> dos1: this seem very uneasy question.
Aug 03 19:42:14 <gena2x> i am currently in attempt to decide what to do with touchscreen.
Aug 03 19:42:45 <gena2x> i mean to form my proposal about touchscreen
Aug 03 19:42:53 <gena2x> so many possibilities.
Aug 03 19:43:17 <gena2x> ts driver in .34 is bad, and unapplicable for openmoko.
Aug 03 19:43:34 <gena2x> if you'll see data it produces, you'll understand it is too bad.
Aug 03 19:43:44 <gena2x> and as it can do 1 event per HZ
Aug 03 19:43:55 <gena2x> filtering this will add huge latency.
Aug 03 19:44:34 <gena2x> second possibility is merging openmoko ts driver to .34, but larsc is strictly agains it.
Aug 03 19:45:00 <gena2x> openmoko driver is much better than unstream one.
Aug 03 19:45:25 <gena2x> and third possibility is to avoid jitter somehow, this is best possibility.
Aug 03 19:45:49 <gena2x> i had few ideas about it, but seem nothing really work.
Aug 03 19:46:27 <gena2x> but changing some glamo registers sounds really promising.
Aug 03 19:47:08 <gena2x> may be i'll try more things to avoid jitter, but if i'll ideas fail i'll prepare patch for in-kernel filtering.
Aug 03 19:47:15 <gena2x> s/i'll/all/
Aug 03 19:47:17 <apt> gena2x meant: may be all try more things to avoid jitter, but if i'll ideas fail i'll prepare patch for in-kernel filtering.
Aug 03 19:47:54 <gena2x> and this will be just other patch larsc do not want to accept but exist in all distributions...
Aug 03 19:49:47 <gena2x> of course, would be nice hear _some_ opinion about this from other people.
Aug 03 19:50:25 <gena2x> it's clear that ts driver is must have.
Aug 03 20:05:35 <JaMa> Trevinho: there is eglibc patch fixing only traps from futexes - will be in feeds soon (but other traps are still there from loader) it should be fixed, but it's harder then it looks
Aug 03 20:05:57 <JaMa> Trevinho: and read ML or use google to see how to disable logging it.. I wrote it at least 3 times..
Aug 03 20:06:01 <Trevinho> ok, thanks
Aug 03 20:06:06 <Trevinho> I've already found that
Aug 03 20:06:22 <Trevinho> but would you suggest to disable just the loggin or ignoring them completely?
Aug 03 20:06:35 <Trevinho> I mean... 
Aug 03 20:06:50 <Trevinho> echo 0 > /proc/cpu/alignment or echo 2 > /proc/cpu/alignment ?
Aug 03 20:07:08 <Trevinho> by default they are set to 3 (fixup and log)
Aug 03 20:07:32 <Trevinho> 0 disables everything, 2 fixes them but doesn't log anything
Aug 03 20:08:53 <mickeyl> Martix: yes, philip van hoof did a couple of benchmarks for tracker. why?
Aug 03 20:09:35 <Trevinho> JaMa: did you read?
Aug 03 20:10:02 <mrmoku> Trevinho: 0 will make the apps segfault
Aug 03 20:10:11 <mrmoku> probably 2 is what you want
Aug 03 20:10:23 <Trevinho> ok, fine
Aug 03 20:14:19 <dos1> JaMa: syncing is ok?
Aug 03 20:15:25 <JaMa> dos1: seems like somebody already started it :)
Aug 03 20:15:34 <dos1> JaMa: no, it was dry run
Aug 03 20:15:50 <JaMa> Trevinho: fixup without logging
Aug 03 20:15:58 <dos1> just wanted to see what changed ;)
Aug 03 20:16:04 <JaMa> hehe :)
Aug 03 20:16:09 <mrmoku> when will we rebuild from scratch?
Aug 03 20:16:10 <Trevinho> thanks JaMa
Aug 03 20:16:11 <JaMa> dos1: we need another rebuild
Aug 03 20:16:21 <mrmoku> :)
Aug 03 20:16:28 <dos1> yeah
Aug 03 20:16:47 <JaMa> mrmoku: we can try now or wait for more testing...
Aug 03 20:17:05 <dos1> testing what?
Aug 03 20:17:07 <JaMa> but the problem is that it's triggered ie after next eglibc bump
Aug 03 20:17:28 <JaMa> dos1: multimachine builds (see my e-mail in oe-devel)
Aug 03 20:17:34 <mrmoku> eglibc bump already in sight?
Aug 03 20:17:35 <dos1> oh
Aug 03 20:17:41 * dos1 has to register on oe-devel
Aug 03 20:18:04 <JaMa> mrmoku: already built for armv6, but because of multimachine it fails to build on gta0* now..
Aug 03 20:18:29 <mrmoku> JaMa: but building from scratch now including that bump should work, no?
Aug 03 20:19:36 <JaMa> mrmoku: yes if you build it in right order
Aug 03 20:19:44 <JaMa> mrmoku: and then it will maybe fail again with next one
Aug 03 20:20:46 <Martix> mickeyl: why? benchmarking FCSE and preempt
Aug 03 20:21:50 <Trevinho> I've another question related to the qi/uboot "hack" for the glamo... Using it with latest SHR it generally brings a very common White screen... There are some images which "fixes" this: http://www.bsdmn.com/openmoko/glamo/242/shrkernel_nows/ but... How they do?
Aug 03 20:22:21 <mickeyl> Martix: i see. one could write some programs that ping/pong with different payloads, but i wonder whether general purpose benchmark wouldn't be more suited than dbus benchmarks
Aug 03 20:26:54 <mrmoku> JaMa: ok, then let's wait a bit... until it is fixed or we're forced to update for some reason
Aug 03 20:27:46 <JaMa> mrmoku: I'll rebuild here (gta02+n900) and if it goes well I'll start rebuild on buildhost tomorrow
Aug 03 20:27:51 <mrmoku> dos1: now it's in tv news ;)
Aug 03 20:28:00 <mrmoku> JaMa: ok, fine
Aug 03 20:28:12 <mrmoku> dos1: even with photo :P
Aug 03 20:28:18 <dos1> mrmoku: hehe, here too at the same time :D
Aug 03 20:28:27 <mrmoku> heh :)
Aug 03 20:28:38 <dos1> but well, here it's today in every tv news :P
Aug 03 20:29:47 <dos1> i had real fun while looking at those people on live tv relation :D
Aug 03 20:30:24 <dos1> but well, it's really sad that those people even exist :(
Aug 03 20:33:31 <JaMa> mrmoku: there is linux_2.6.33 + MeeGo patches for n900 in my gitorious branch.. but for some reasons few parts fail to build (seems like a bit strange defconfig)
Aug 03 20:34:05 <mrmoku> hmm
Aug 03 20:34:52 <JaMa> maybe because of bleeding edge toolchain (as gta02 snd module)
Aug 03 20:35:06 <mrmoku> that failed too?
Aug 03 20:36:16 <JaMa> mrmoku: yes.. it fails to build as module because it optimizes one symbol out even when it's used
Aug 03 20:37:13 <JaMa> mrmoku: that's why we have http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commit/46af6d0212cc5923622afa4f15354ab22ffe6a57
Aug 03 20:38:15 <gena2x> Trevinho: /about ws fix/: the following patch added to 'nows' images: http://www.bsdmn.com/openmoko/glamo/gcc44wsfix.diff
Aug 03 20:39:16 <gena2x> Trevinho: i didn't publish it as patch, as actully this is only thing for Weiss to analyse.
Aug 03 20:40:12 <gena2x> Trevinho: sooner or later i hope we'll have better fix and it will be in kernel in one or other way.
Aug 03 20:40:38 <gena2x> Trevinho: so far, no regressions noticed, so you may use this patch until better one will not be ready.
Aug 03 20:41:10 <Trevinho> ok, fine gena2x
Aug 03 21:07:02 <[Rui]> hi
Aug 03 21:07:12 <[Rui]> weird thing with suspend
Aug 03 21:07:46 <[Rui]> like,... not suspending, but modem being put in suspending mode, then no suspend, no calls, no shutdown (via graphical tools, perhaps shutdown -h now will work)
Aug 03 21:12:00 <lindi-> 2.6.32?
Aug 03 21:15:15 <[Rui]> lindi-: yeah, stock shr-u from July 30th
Aug 03 21:15:27 <lindi-> [Rui]: anything in dmesg?
Aug 03 21:15:42 <[Rui]> I am trying to reproduce it together with the pter
Aug 03 21:15:47 <[Rui]> puter
Aug 03 21:16:43 <[Rui]> lindi-: I'm going to power off and do some fsck on the µ-sd
Aug 03 21:17:07 <[Rui]> dmesg is showing some bad mojo [   61.295000] EXT2-fs error (device mmcblk0p1): ext2_lookup: deleted inode referenced: 483210
Aug 03 21:18:46 <lindi-> [Rui]: looks broken yes
Aug 03 21:22:14 <[Rui]> lindi-: yeah. fsck done, booting.
Aug 03 21:27:16 <[Rui]> lindi-: well, I can't reproduce it now, so maybe it was something bad at fs level
Aug 03 21:44:31 <Martix> compiling on FR and I've got error: ar: invalid option -- '.' when running ar cr .....
Aug 03 21:45:16 <Martix> Busybox ar sucks, can I replace it? binutils already installed
Aug 03 21:46:08 <lindi-> Martix: you should mention what OS you have
Aug 03 21:46:49 <Martix> SHR
Aug 03 21:49:41 <[Rui]> android-rpc ?
Aug 03 21:49:50 <[Rui]> weird package....
Aug 03 21:52:33 <Martix> [Rui]: ar? that comes from UNIX
Aug 03 21:55:12 <Martix> /usr/arm-oe-linux-gnueabi/bin/ar solves problem
Aug 03 21:56:07 <[Rui]> Martix: huh? That was a WTF moment, there... :)
Aug 03 21:56:19 <[Rui]> ar is not "android rpc" :)
Aug 03 21:59:19 <[Rui]> "Description: Android RPC library" weird that it's here
Aug 03 22:01:23 <Martix> oh, I see
Aug 03 22:07:10 <[Rui]> Martix: no problem, I could only look at "android-rpc" and think... WTF?! :)
Aug 03 22:27:51 <Gnutoo|htcdream> hi Deubeuliou 
Aug 03 22:31:16 <leviathan> Gnutoo|htcdream: hi
Aug 03 22:31:25 <leviathan> how functional is your rebased kernel?
Aug 03 22:31:56 <leviathan> Gnutoo|htcdream: and did you already take a look into codeauroras work for upstream?
Aug 03 22:31:58 <Gnutoo|htcdream> it should work better than the previous one
Aug 03 22:32:02 <leviathan> hmm, ok
Aug 03 22:32:36 <Gnutoo|htcdream> Deubeuliou: for alsa we should use msm7k or 7kv2 driver
Aug 03 22:32:47 <Gnutoo|htcdream> and change the interfaces
Aug 03 22:33:09 <Gnutoo|htcdream> leviathan: you mean dwalker's tree
Aug 03 22:33:17 <Gnutoo|htcdream> not yet
Aug 03 22:33:28 <Gnutoo|htcdream> I'm too busy with rebase
Aug 03 22:34:05 <Gnutoo|htcdream> oops I forgott to check if there are logs with irssi by default
Aug 03 22:37:09 <Gnutoo|htcdream> anyway according to #htc-linux there are different possibilities for thr sound
Aug 03 22:37:32 <Gnutoo|htcdream> that is to say different methos to talk to the dsp
Aug 03 22:38:19 <Gnutoo|htcdream> the android-msm kernel has a qdsp5 like interface
Aug 03 22:38:37 <Gnutoo|htcdream> also for nexusone
Aug 03 22:39:13 <Gnutoo|htcdream> but codeaurora's kernel has different interfaces for qdd
Aug 03 22:39:16 <Gnutoo|htcdream> *qsd
Aug 03 22:40:37 <leviathan> Gnutoo|htcdream: yes
Aug 03 22:40:48 <Gnutoo|htcdream> so better at fisrt using msm7k or 7kv2 driver
Aug 03 22:40:54 <leviathan> would be cool to stick together with them
Aug 03 22:40:59 <Gnutoo|htcdream> and do the little adaptation
Aug 03 22:41:10 <leviathan> they have power about upstream
Aug 03 22:41:17 <leviathan> especialy daniel walker
Aug 03 22:41:46 <Gnutoo|htcdream> I'll get nexusone after the hollidays
Aug 03 22:42:00 <Gnutoo|htcdream> ok
Aug 03 22:43:17 <Gnutoo|htcdream> I've asked a question about buffer management on msm ml
Aug 03 22:43:22 <Gnutoo|htcdream> no response
Aug 03 22:43:28 <leviathan> Gnutoo|htcdream: hmh
Aug 03 22:43:33 <leviathan> yes, they are a bit slow
Aug 03 22:43:33 <Gnutoo|htcdream> indeed
Aug 03 22:43:45 <leviathan> but you can watch daniels panel patch
Aug 03 22:43:52 <Gnutoo|htcdream> did the mail reach the ml?
Aug 03 22:43:57 <leviathan> hmm
Aug 03 22:43:59 <leviathan> mom
Aug 03 22:44:07 <Gnutoo|htcdream> maybe they re in hollidays
Aug 03 22:44:17 <Gnutoo|htcdream> *on
Aug 03 22:44:23 <Gnutoo|htcdream> i ll go
Aug 03 22:44:41 <leviathan> hmm
Aug 03 22:44:48 <leviathan> it reached the ml
Aug 03 22:44:54 <leviathan> but no respons
Aug 03 22:45:10 <Gnutoo|htcdream> ok
Aug 03 22:45:36 <leviathan> with the patches from daniel
Aug 03 22:45:47 <leviathan> we can make boot official kernel on dream
Aug 03 22:45:52 <leviathan> but there is nothing
Aug 03 22:45:58 <leviathan> not even keyboard drivers
Aug 03 22:46:06 <leviathan> only a nice penguin on the display
Aug 03 22:46:24 <leviathan> we should at least import the msm usb driver for ethernet gadget
Aug 03 22:46:29 <leviathan> after examina
Aug 03 23:17:51 <GNUtoo|htcdream> leviathan: about wifi...I've not checked my mail yet...but as I said before...there are many issues ans the easiest one go first
Aug 03 23:20:25 <GNUtoo|htcdream> leviathan: did you try camera long time ago? it's higly dependasnt on pmem
Aug 03 23:20:32 <GNUtoo|htcdream> no?
Aug 03 23:21:55 <GNUtoo|htcdream> too bad nexusone got no keyboard
Aug 03 23:22:08 <GNUtoo|htcdream> hmmm
Aug 03 23:22:50 <GNUtoo|htcdream> palm pre has 2.6.24 and because of that...no compat-wireless
Aug 03 23:23:15 <GNUtoo|htcdream> thr minimum kernel is 2.6.27 for compat-wireless
Aug 03 23:23:28 <GNUtoo|htcdream> leviathan: are you still there?
Aug 03 23:29:09 <GNUtoo|htcdream> hmmm do I have some sort of PM? I don't remember how to switch channel in irssi
Aug 03 23:29:50 <GNUtoo|htcdream> maybe with ctrl which I didn't map yet
Aug 03 23:31:57 <GNUtoo|htcdream> I'll sleep
Aug 03 23:31:59 <GNUtoo|htcdream> bye
**** ENDING LOGGING AT Wed Aug 04 02:59:57 2010