**** BEGIN LOGGING AT Mon Jun 22 02:59:57 2009
Jun 22 05:26:44 <DocScrutinizer> omg, 'time cp /media/mmcblk0p2/1MB-file  /media/mmcblk0p2/1MB-file2' : 2m27s  :-((
Jun 22 05:30:26 <mrmoku> ouch
Jun 22 05:36:24 <mrmoku> DocScrutinizer, broken SD?
Jun 22 05:36:34 <DocScrutinizer> dunno
Jun 22 05:36:43 <mrmoku> I'm doing that in 7.16s
Jun 22 05:37:01 <DocScrutinizer> lemme logread
Jun 22 05:39:26 <Q-Master> mrmoku: can you tell me who's responsible for shr-contacts? this HUGE font which is there now is not quite useable
Jun 22 05:39:58 <DocScrutinizer> spammed with auth notice dbus-daemon:would reject...rules...foo iface=...gsm.data
Jun 22 05:41:03 <DocScrutinizer> no IO-errors
Jun 22 05:41:15 <mrmoku> Q-Master, the font changed for contacts? the list or the edit window?
Jun 22 05:41:26 <Q-Master> list
Jun 22 05:42:05 <mrmoku> in efl2 then?
Jun 22 05:45:56 <mrmoku> Q-Master, for the 'old' efl frontend the font did not change for me...
Jun 22 05:46:15 <mrmoku> the new one is using a elm genlist for the contacts... which could have changed
Jun 22 05:49:57 <Q-Master> mrmoku: seems that I'm using the new one
Jun 22 05:50:07 <Q-Master> efl2
Jun 22 05:50:37 <mrmoku> Q-Master, just installed the new one... and checked
Jun 22 05:50:38 <DocScrutinizer> omg, 'time cp /media/mmcblk0p2/1MB-file /dev/null' : 0m0.707. should flush buffers?
Jun 22 05:50:51 <DocScrutinizer> s/omg, //
Jun 22 05:50:55 <mrmoku> well... it makes it readable for blind people too... so I would call that a feature :)
Jun 22 05:52:02 <Q-Master> mrmoku: it takes AGES to list through ~200 contacts... the list is not inertial and scrolls very slow... 8(
Jun 22 05:52:13 <mrmoku> yep
Jun 22 05:52:18 <mrmoku> will try to fix that
Jun 22 05:53:18 <Q-Master> thnx
Jun 22 05:56:34 <mrmoku> raster, ping
Jun 22 05:57:45 <Q-Master> btw, is it possible to make illume's configs look not too big for that DPI we use in it?
Jun 22 05:59:07 <tobii_> morning
Jun 22 05:59:08 <mrmoku> Q-Master, don't get what you mean?
Jun 22 05:59:54 <Q-Master> mrmoku: just try to open some background config in wrench. It'll be mostly off-screen.
Jun 22 06:00:29 <Q-Master> we have 239(if i remember right) dpi on screen, but illume is in ~144 dpi 
Jun 22 06:00:44 <lindi-> DocScrutinizer: flushing buffers does not remove read cache?
Jun 22 06:00:50 <Q-Master> so everything is almost twice as big as it should be
Jun 22 06:01:18 <Q-Master> and x11-16 engine segfaults sometimes...
Jun 22 06:01:41 <DocScrutinizer> lindi-: sync doesn't. ls -R /media does though
Jun 22 06:01:45 <mrmoku> Q-Master, 285 says Xserver start script... I just tried to change it to 285... everything get's very tiny for me then
Jun 22 06:01:47 <DocScrutinizer> it seems
Jun 22 06:06:04 <DocScrutinizer> well, anyway writing to uSD takes same time, irrespective of source. So seems uSD really *bad*
Jun 22 06:06:46 <Q-Master> mrmoku: yes. I've thought that the gui must be adopted to dpi, but not dpi to gui... 8)
Jun 22 06:06:51 <Q-Master> that suxx
Jun 22 06:08:08 <DocScrutinizer> PaulFertser: would you like me to investigate any details of sdio-driver wrt this 8KB/s write rate?
Jun 22 06:15:56 <lindi-> mrmoku: blah, just use dpi of 96 :-)
Jun 22 06:19:51 <Q-Master> lindi-: for blind ppl? 8)
Jun 22 06:23:23 <mrmoku> lindi-, hmm... which one... the one as parameter for Xglamo or the config for illume?
Jun 22 06:24:05 <lindi-> mrmoku: I didn't know illume took dpi as parameter. shouldn't it query it from X?
Jun 22 06:24:24 <mrmoku> lindi-, well it does... but you can manually override it to tweak scaling
Jun 22 06:26:45 <F4t> hey, does anyone know how do i compile connman from git using the openmoko crosstools?
Jun 22 06:27:35 <DocScrutinizer> mrmoku: random tweaking DPI will get us into scaling hell
Jun 22 06:29:33 <mrmoku> DocScrutinizer, what is the native dpi for gta02?
Jun 22 06:29:41 <DocScrutinizer> mrmoku: AIUI e.g. fontsize in pt is a absolute size. So apps need to use a small fontsize to work properly on small screen (if they work properly)
Jun 22 06:30:34 <DocScrutinizer> duh, no coffe yet :-/  640 pixel per ... errr... 
Jun 22 06:31:01 <DocScrutinizer> 2.5 inch
Jun 22 06:31:37 <mrmoku> that would be 256 then...
Jun 22 06:32:25 <DocScrutinizer> X should calculate DPI from screen geometry and res
Jun 22 06:33:07 <mrmoku> DocScrutinizer, /etc/X11/Xserver does -dpi 285 which is wrong anyway then
Jun 22 06:34:17 <DocScrutinizer> Hmm, sorry, toldya "no coffee".    2.25'
Jun 22 06:34:56 <mrmoku> :)
Jun 22 06:35:46 <DocScrutinizer> inch-scale is kinda weird ;-)
Jun 22 06:36:29 <DocScrutinizer> 1/2 1/4 1/8
Jun 22 06:37:19 <DocScrutinizer> you should refer to toploy datasheet for exact values
Jun 22 06:39:08 <Q-Master> DocScrutinizer: anyway the nowadays dpi in illume is wrong for almost all it's configs. 8(
Jun 22 06:42:28 <DocScrutinizer> mrmoku: basically there are two concepts: either apps are doing correctly and calculate size of fonts (pt) and graphics from correct geometry and DPI - this means we probably want 3PT..4pt fonts everywhere (like e.g. xchat is doing correctly). Or #2 we pretend by fake geometry we have a 14' screen, and all apps use this nonsense with 12pt
Jun 22 06:44:12 <DocScrutinizer> that's my 2cent on the topic. Probably raster should know much better
Jun 22 06:44:34 <mrmoku> yeah... maybe we should get raster to give some advise
Jun 22 07:33:25 <raster> dpi?
Jun 22 07:33:27 <raster> eh?
Jun 22 07:38:16 <DocScrutinizer> moin raster :-)
Jun 22 07:38:44 <raster> DocScrutinizer: boo!
Jun 22 07:39:27 <rhkfin> raster: now that I remember: is it intentional that in the keyboard the 'hilight' (=the popup) of the letter when releasing the button is always a small letter, never a capital even if the SHIFT is used?
Jun 22 07:40:15 <raster> rhkfin: hmm that'd be a bug
Jun 22 07:40:45 <rhkfin> raster: ok, just checking if you already knew it
Jun 22 07:40:51 <DocScrutinizer> nah, that's a mere timing thing
Jun 22 07:43:15 <DocScrutinizer> shift is reset as soon as you release any char key. so the "shrink" after key release shows what the key actually got printed at on it that very moment
Jun 22 07:43:51 <DocScrutinizer> compare CAPS
Jun 22 07:44:41 <rhkfin> DocScrutinizer: ah, you're right
Jun 22 07:45:07 <rhkfin> (but it still happens :)
Jun 22 07:45:21 <rhkfin> so bug -> triaged already :)
Jun 22 07:50:17 <DocScrutinizer> rhkfin: for this to become a bug you at least need to specify expected behaviour in contrast to actually observed. Should the popup show sth that's not the same as the key imprint? or should shift be reset with a time delay only after shrink of popup finished?
Jun 22 07:53:55 <rhkfin> DocScrutinizer: ok.. well.. I think the popup needs to be the same as the printed letter, after all the popup is there (AFAIK) to make it easier for the user to know what did he press. I leave it to the developers to decide how they do it :)
Jun 22 07:57:40 <DocScrutinizer> rhkfin: AIUI the popup is there to show what user *will* get *when* he releases button now. shrink is a nice eyecandy but I'd not consider it a feedback to know what you *have* pressed. After all you see it as a actual char printed in input field or kbd topbar 
Jun 22 07:58:59 <rhkfin> DocScrutinizer: well, whatever, just wanted to check you know about it. It's up to you what'll happen to it if anything.
Jun 22 07:59:33 <DocScrutinizer> bottom line: this seems to me to be absolutely correct behaviour of kbd, according to a spec that maybe isn't like you would want it to be
Jun 22 07:59:53 <rhkfin> right :)
Jun 22 08:03:56 <Q-Master> raster: the speech was about illume's forms which are showed off-screen with this dpi settings.
Jun 22 08:04:42 <raster> Q-Master: nothing wrong with dpi
Jun 22 08:04:53 <raster> e's config dialogs just were not designed for such a small screen
Jun 22 08:04:56 <raster> and need a redo
Jun 22 08:05:11 <Q-Master> raster: I'm just speaking abou this. 8)
Jun 22 08:05:15 <Q-Master> +t
Jun 22 08:05:56 <Q-Master> raster: btw, sometimes x11-16 engine segfaults when entering some config forms
Jun 22 08:06:42 <Q-Master> e.x. background settings
Jun 22 08:06:51 <raster> yup
Jun 22 08:06:58 <raster> as i keep saying. the engine is incomplete
Jun 22 08:07:04 <raster> it was writen for a sub-case of evas's rendering
Jun 22 08:07:17 <raster> which is why i tel people not to use it unless they really know what they are doing
Jun 22 08:07:21 <raster> and generally they dont
Jun 22 08:09:13 <DocScrutinizer> raster: could we get rid of bold topbar for terminal-kbd? without predictive word selector a much smaller bar would do to hold the 2 buttons
Jun 22 08:09:25 <Q-Master> raster: with other engines the illume'
Jun 22 08:09:27 <Q-Master> s
Jun 22 08:09:41 <Q-Master> drawing is damn slow
Jun 22 08:10:58 <raster> thats because the freerunner is so slow
Jun 22 08:11:19 <raster> and it has 4x the pixels to draw that any machine of that class was designed for
Jun 22 08:11:43 <raster> the glamo was inteded for qvga displays
Jun 22 08:11:57 <raster> and the 2442 is of an age where qvga was "top of the line" in displays
Jun 22 08:14:14 <raster> DocScrutinizer: it's part of the .edj
Jun 22 08:14:27 <raster> it can be removed
Jun 22 08:14:40 <DocScrutinizer> ooh, so you say I can easily change myself?
Jun 22 08:14:48 <raster> yes
Jun 22 08:14:49 <DocScrutinizer> :-)
Jun 22 08:14:52 <raster> its part of the design
Jun 22 08:35:40 <DocScrutinizer> raster: there's a myriad of .edj. Would you know off top of your head which one is the one for/including terminal-kbd?
Jun 22 08:42:23 <ptitjes> good morning
Jun 22 08:44:59 <methril|work> good morning
Jun 22 08:46:11 <ptitjes> hello methril|work 
Jun 22 08:47:10 <onen|openBmap> hi ptitjes :-)
Jun 22 08:47:21 <ptitjes> hello onen|openBmap 
Jun 22 08:50:07 <ptitjes> what's up guys
Jun 22 08:50:08 <ptitjes> ?
Jun 22 08:50:17 <fredrin> i'm up and back in norway 
Jun 22 08:51:40 <DocScrutinizer> fredrin: hey welcome back in EU
Jun 22 08:52:04 <fredrin> thanks, good to be back, even though norway is not a member of EU
Jun 22 08:52:10 <fredrin> we like to keep our fish and oil thanks 
Jun 22 08:52:42 <fredrin> :)
Jun 22 08:52:53 <ptitjes> heh
Jun 22 08:53:05 <ptitjes> you can keep both without any problems ;)
Jun 22 08:53:11 <DocScrutinizer> EU was meant Europe here ;-)
Jun 22 08:53:41 <fredrin> :) I thought so 
Jun 22 09:01:22 <raster> DocScrutinizer: illume.edj
Jun 22 09:01:23 <raster> :)
Jun 22 09:01:34 <DocScrutinizer> thnx
Jun 22 09:04:34 <PaulFertser> DocScrutinizer: i think raster did some tests of uSD write speed. And don't forget that if you have GPS powered on, sd clock is slowed down by a factor of 8.
Jun 22 09:06:03 <PaulFertser> DocScrutinizer: in fact if you could reproduce unable to get a fix while accessing SD problem it'd be interesting to see how that slowing down factor impacts GPS reception. Probably it's not needed at all on gps-fixed units. Can be easily changed runtime, via sysfs node.
Jun 22 09:06:20 <DocScrutinizer> well, gps should be off. and 8KB/s is *really* odd
Jun 22 09:07:30 <DocScrutinizer> maybe I should read ot that sysfs node to see if sth is strange there? name?
Jun 22 09:08:12 <DocScrutinizer> also notice it's only writing speed that slows down to unbearable
Jun 22 09:08:18 <DocScrutinizer> read  is fine
Jun 22 09:09:22 <PaulFertser> DocScrutinizer: /sys/module/glamo_mci/parameters/sd_slow_ratio
Jun 22 09:10:08 <DocScrutinizer> 8
Jun 22 09:10:16 <PaulFertser> Sure, that's default.
Jun 22 09:10:20 <DocScrutinizer> :-/ ?
Jun 22 09:10:32 <PaulFertser> The driver slows down the clock by a factor of 8 whenever gps is powered on.
Jun 22 09:11:32 <DocScrutinizer> gps is off. well should at least
Jun 22 09:13:21 <PaulFertser> DocScrutinizer: sorry, i'm talking about a completely different issue. It's just that it keeps bothering me so i keep mentioning it on any occassion :)
Jun 22 09:14:05 <PaulFertser> DocScrutinizer: can you tell me your command to test writing speed?
Jun 22 09:15:38 <DocScrutinizer> omg, 'time cp 1MB-file  /media/mmcblk0p2/1MB-file2' : 2m27s  :-((
Jun 22 09:15:55 <DocScrutinizer> grrr "/omg, //
Jun 22 09:16:06 <DocScrutinizer>   s/ even
Jun 22 09:16:32 <max_posedon> DocMobilizer, uSD mounted sync or async?
Jun 22 09:18:00 <DocScrutinizer> sync
Jun 22 09:18:35 <DocScrutinizer> ext3 data=ordered
Jun 22 09:18:40 <max_posedon> so, as for me, test is useless. e.g. I don't see any reason to use sync
Jun 22 09:19:25 <DocScrutinizer> nevermind
Jun 22 09:20:01 <DocScrutinizer> I didn't select sync, but nevertheless 8MB/s is a joke
Jun 22 09:21:22 <DocScrutinizer> err 8KB/s
Jun 22 09:21:48 <Q-Master> onen|openBmap: hi
Jun 22 09:21:54 <DocScrutinizer> I take a nap, bbl
Jun 22 09:22:00 <onen|openBmap> Q-Master: hi
Jun 22 09:25:39 <DocScrutinizer> I  could use NFS over GPRS with better performance ;-) that's a write speed I haven't seen since 8'-floppy
Jun 22 09:28:30 <DocScrutinizer> and probably it's absolutely prohibitive for the swap lately en vogue for opkg upgrade ;-P
Jun 22 09:29:22 <PaulFertser> DocScrutinizer: i can't reproduce it here
Jun 22 09:29:42 <PaulFertser> DocScrutinizer: time bash -c 'dd if=/dev/zero of=1mbfile bs=1M count=1; sync'
Jun 22 09:29:54 <DocScrutinizer>  i guess my uSD is borked
Jun 22 09:30:09 <PaulFertser> DocScrutinizer: is it the same you had problems with
Jun 22 09:30:41 <dos1> ~70 messages :)
Jun 22 09:31:27 <DocScrutinizer> nope, not the 16G, but the one withnstale "NFS link of TZ file" and broken kernel after droptest
Jun 22 09:31:56 <PaulFertser> dos1: do you think shr apps can be really "lightning fast" if one chooses the right (read extremely) minimal theme and does some tweaks?
Jun 22 09:32:39 <PaulFertser> DocScrutinizer: yeah, your droptest lead to very unexpected results. I can't imagine how to explain it.
Jun 22 09:32:40 <DocScrutinizer> PaulFertser: I run a fsck.ext3 on it to fix it
Jun 22 09:32:44 <dos1> PaulFertser: minimal theme + x11-16 should make them fast, if not lightning fast ;)
Jun 22 09:33:02 <PaulFertser> dos1: faster than dumb nokia cell phone or not?
Jun 22 09:33:25 <dos1> PaulFertser: it depends. i have seen fast dumb nokia phones and slow dump nokia phones :D
Jun 22 09:33:39 <dos1> i think faster than slow dump nokia phones is possible ;)
Jun 22 09:33:52 <Q-Master> dos1: howdy!
Jun 22 09:34:04 <PaulFertser> dos1: i've never seen a dumb nokia phone that was fast enough for my liking. They all suck because of animation or lack of shortcuts.
Jun 22 09:35:32 <dos1> PaulFertser: Nokia 3410 was fast enough i think :)
Jun 22 09:35:34 <DocScrutinizer> PaulFertser: I'll reboot eventually and redo test, then reboot from SD and try writespeed, then swap uSD
Jun 22 09:35:51 <PaulFertser> DocScrutinizer: good plan. But take a nap first ;)
Jun 22 09:36:01 <dos1> PaulFertser: but with newer models i agree
Jun 22 09:36:06 <DocScrutinizer> good plan ;-D
Jun 22 09:36:24 <dos1> and i think SHR could be faster
Jun 22 09:36:49 <DocScrutinizer> let's see if I can c&p your dd cmd
Jun 22 09:36:56 <Q-Master> dos1: what's wrong with shr-contacts? it's font is huge...
Jun 22 09:37:17 <dos1> Q-Master: where?
Jun 22 09:37:36 <Q-Master> dos1: shr unstable efl2
Jun 22 09:37:45 <dos1> Q-Master: ah, efl2
Jun 22 09:37:54 <dos1> Q-Master: that's elementary update
Jun 22 09:38:17 <PaulFertser> DocScrutinizer: it doesn't seem to provide very reproducable results, at least first run was slower. Probably some filesystem-inode-allocation-or-smth-related differences.
Jun 22 09:38:49 <Q-Master> dos1: and it's dumb slow when scrolling. 200contacts are scrolled ages till the end
Jun 22 09:39:26 <dos1> Q-Master: yep, that list should have scale_set
Jun 22 09:39:43 <Q-Master> dos1: when?
Jun 22 09:39:49 <DocScrutinizer> duh, 4.29s
Jun 22 09:41:41 <mrmoku> dos1, scale_set ?
Jun 22 09:41:58 <dos1> mrmoku: it worked with shr-settings
Jun 22 09:42:12 <DocScrutinizer> I think ext3 is a bad idea anyway
Jun 22 09:42:16 <mrmoku> dos1, some kind of howto for me?
Jun 22 09:43:22 <mrmoku> is it something to stuff into .edc?
Jun 22 09:44:11 <DocScrutinizer> lets see what a bs of 1k will do
Jun 22 09:45:43 <Q-Master> DocScrutinizer: I'm using ext3 on uSD now. booting from it
Jun 22 09:46:11 <dos1> mrmoku: i think no, that's function
Jun 22 09:46:18 <DocScrutinizer> PaulFertser: bs=1K count=1024: 1m31,  11.7kB/s
Jun 22 09:46:56 <DocScrutinizer> max_posedon was right with his sync I guess
Jun 22 09:48:23 <PaulFertser> DocScrutinizer: yes, sync is not something you want to have on a regular system.
Jun 22 09:50:52 <dos1> ok, now i have my opimd messages gui functional :)
Jun 22 09:51:14 <dos1> with replying to incoming messages and storing sent messages :)
Jun 22 09:52:33 <rhkfin> dos1: wow, sound's great :)
Jun 22 09:53:06 <dos1> rhkfin: nwo i have 65 messages stored in sqlite database ;)
Jun 22 09:53:12 <dos1> rhkfin: incoming and outgoing
Jun 22 09:53:38 <rhkfin> dos1: nice :)
Jun 22 09:53:43 <dos1> rhkfin: gui is experimental and for testing, but it works for me and i'm using it as standard sms app :)
Jun 22 09:54:32 <dos1> rhkfin: i will write mail how to install, configure and test it
Jun 22 09:54:36 <dos1> but later
Jun 22 09:54:37 <rhkfin> dos1: screenshots!
Jun 22 09:54:39 <rhkfin> dos1: ok :)
Jun 22 09:55:08 <dos1> rhkfin: few are on scap.linuxtogo.org, but old ;)
Jun 22 09:55:35 <dos1> rhkfin: i think it's functionality is more important that look ;)
Jun 22 09:56:33 <rhkfin> dos1: yes but the look makes people interested.. If one writes a library or backend/engine/whatever, it's hard to get poeple interested if they can't see from a screenshot what can it be used for..
Jun 22 09:57:32 <dos1> rhkfin: i like that testing app from look'n'feel, but it was intended to be testing script only, as there is no other app which could handle opimd messages :P
Jun 22 09:57:33 <mrmoku> dos1, did you update the opimd docs?
Jun 22 09:57:58 <mrmoku> and more importantly... update the specs?
Jun 22 09:59:18 <dos1> mrmoku: specs for contacts - yes
Jun 22 09:59:20 <Q-Master> dos1: what about switching from dictionary to list in opimd contacts?
Jun 22 09:59:28 <dos1> mrmoku: for messages i think only missing is delete in specs
Jun 22 09:59:36 <dos1> mrmoku: but i'll update it soon
Jun 22 09:59:54 <dos1> Q-Master: write mail about it on smartphones-standards please
Jun 22 10:00:25 <dos1> Q-Master: i'm not the right person to change API. right now i was only adding new methods/signals, not changing old :P
Jun 22 10:00:53 <mrmoku> dos1, signals... I'm interested in signals ;)
Jun 22 10:01:12 <dos1> mrmoku: oh, then IncomingMessage is also missing in specs ;)
Jun 22 10:01:18 <Q-Master> dos1: where to write?
Jun 22 10:01:37 <dos1> Q-Master: http://projects.linuxtogo.org/mailman/listinfo/smartphones-standards
Jun 22 10:01:38 <mrmoku> dos1, I'm planning to switch efl2 to libfso-glib... so please add it :P
Jun 22 10:01:38 <SHR-WugBranler> tracfeed: Ticket #524 (SDcard IO Error and FS corruption when receiving call (unstable image)) updated <http://trac.shr-project.org/trac/ticket/524#comment:3>
Jun 22 10:01:50 <dos1> mrmoku: ok :)
Jun 22 10:02:28 <Q-Master> dos1: ok. from at home.
Jun 22 10:14:19 <farhaven> hi there
Jun 22 10:14:32 <farhaven> i'm having an odd problem with shr here
Jun 22 10:14:59 <farhaven> if i receive a call while something is running (i.e. simple_lock or tangogps) the screen gets garbled and the sdcard's partitions get thrashed
Jun 22 10:15:15 <farhaven> which isn't really optimal because i'm booting from the sdcard
Jun 22 10:15:32 <farhaven> did anyone experience something similar and maybe knows a way out?
Jun 22 10:16:09 <PaulFertser> farhaven: sounds _very_ nasty.
Jun 22 10:16:15 <farhaven> aye :)
Jun 22 10:16:31 <PaulFertser> farhaven: is it easily reproducible?
Jun 22 10:16:34 <farhaven> especially since after i set up everything the way i like it and go "hey, lets see if it works now" it doesn't
Jun 22 10:16:38 <farhaven> yep
Jun 22 10:16:49 <PaulFertser> farhaven: can you try to shield the sd card?
Jun 22 10:16:53 <farhaven> for me, it's just installing shr-testing, starting tangogps and calling my mobile from my home phone
Jun 22 10:16:57 <farhaven> shield?
Jun 22 10:17:02 <farhaven> how would i do that?
Jun 22 10:20:16 <PaulFertser> farhaven: with foil
Jun 22 10:20:25 <rhkfin> dos1: wanna add your opimd updates here: http://wiki.openmoko.org/wiki/Talk:Community_Updates/June_25%2C_2009
Jun 22 10:20:47 <farhaven> PaulFertser: but isn't there a rather high risk I short circuit the traces leading to the sdcard?
Jun 22 10:21:03 <farhaven> or maybe i could try gum wrapper
Jun 22 10:21:08 <farhaven> it has paper on one side...
Jun 22 10:21:39 <PaulFertser> farhaven: yes, be accurate and creative ;)
Jun 22 10:21:43 <farhaven> hehe
Jun 22 10:22:05 <farhaven> what makes me wonder though is this only happens if i run some app in the background
Jun 22 10:22:15 <farhaven> first i though there might be interference with the gps
Jun 22 10:22:16 <onen|openBmap> PaulFertser: ping
Jun 22 10:22:18 <PaulFertser> farhaven: there was one or two reports about GSM interfering with SD card. Probably this is pure SD-card issue, probably even glamo (as you also see screen corruption)
Jun 22 10:22:21 <PaulFertser> onen|openBmap: pong
Jun 22 10:22:48 <farhaven> PaulFertser: yeah, and there's also a buttload of error messages from glamo.mci in the dmesg
Jun 22 10:22:50 <onen|openBmap> PaulFertser: please upgrade your obm to the last version in my git tree. (commit cf2ad7df869c1c0a07dfae9f2c5e1036a458c952)
Jun 22 10:23:02 <onen|openBmap> PaulFertser: you simply needs to pick up openbmap/logger.py
Jun 22 10:23:06 <farhaven> anyway, i'll try shielding the card, thanks for the hint
Jun 22 10:23:28 <PaulFertser> farhaven: that's one of the possible reasons. Don't raise your hopes too much.
Jun 22 10:23:32 <onen|openBmap> PaulFertser: and if you could review this last commit, at the same time ;-)
Jun 22 10:23:44 <PaulFertser> onen|openBmap: thanks, will do soon
Jun 22 10:24:01 <farhaven> PaulFertser: hehe, i'll also try playing around a bit more, maybe i can track this down to a single source
Jun 22 10:24:16 <onen|openBmap> PaulFertser: this rejects the log if it took too much time to gather data, for whatever reason
Jun 22 10:24:23 <PaulFertser> farhaven: another possibility is to use glamo slow clock workaround.
Jun 22 10:24:31 <farhaven> i tried that already
Jun 22 10:24:38 <farhaven> didn't help that much :)
Jun 22 10:24:56 <farhaven> oddly enough, the issue seems more severe in unstable
Jun 22 10:25:10 <farhaven> i had that crash _once_ with testing, but the card still booted
Jun 22 10:25:21 <farhaven> when it happened in unstable, all hope was lost
Jun 22 10:31:41 <PaulFertser> farhaven: is it statistically proven?
Jun 22 10:32:05 <farhaven> i didn't run any high impact tests if that's what you mean :)
Jun 22 10:32:18 <farhaven> i'm atm making a backup of my rootfs, but i'll stress test it a bit after that
Jun 22 10:35:54 <DocScrutinizer> PaulFertser: do you know about pppd and how it handles leases? is it using dhcpcd for this? or is this implemented in pppd directly?
Jun 22 10:38:43 <PaulFertser> DocScrutinizer: directly, no dhcpcd involved.
Jun 22 10:39:18 <PaulFertser> DocScrutinizer: pppd implements IPCP protocol to obtain ip addresses and it configures ppp-interface itself according to that data.
Jun 22 10:39:51 <DocScrutinizer> any lease time defined?
Jun 22 10:41:32 <DocScrutinizer> PaulFertser: after 24h gprs connectivity stalls here, and I don't see any inbound package or outbound lease renewal request at the time this happens
Jun 22 10:43:24 <PaulFertser> DocScrutinizer: no lease time afaik. Probably your operator sucks and does some weird thing.
Jun 22 10:47:26 <DocScrutinizer> fsck. sure he does. I hoped he would give a leasetime of 24h on establishing GPRS though. pppd has *no* means to auto-renew the lease after expiry of some certain time (--leasetime=1440)? :-/ Need a nasty 'sleep xxx; mdbus ' hack in pppd scripts then, to tear down and reestablish GPRS after 23:55
Jun 22 10:48:37 <onen|openBmap> I cannot find a doc specifying it: when making dbus calls in python, the timeout argument, is in? seconds?
Jun 22 10:49:15 <onen|openBmap> stefan_schmidt: hallo. thanks for putting obm in the feeds :-)
Jun 22 10:51:03 <DocScrutinizer> PaulFertser: maxconnect?
Jun 22 10:53:17 <PaulFertser> DocScrutinizer: pppd can do lcp pings regularly and reestablish the connection if it's unable to ping anymore.
Jun 22 10:53:57 <DocScrutinizer> PaulFertser: for obvious reasons I don't want do use this ;-)
Jun 22 10:54:02 <PaulFertser> DocScrutinizer: lcp-echo-failure 2 and lcp-echo-interval 10 and persist should do the trick.
Jun 22 10:54:24 <PaulFertser> DocScrutinizer: i'm not sure lcp ping costs anything, it's sub-ip level.
Jun 22 10:54:45 <DocScrutinizer> it cost bat life anyway
Jun 22 10:55:14 <stefan_schmidt> onen|openBmap: np
Jun 22 10:55:32 <onen|openBmap> stefan_schmidt: maybe you know the answer to my question above?
Jun 22 10:55:42 <Ainulindale> stefan_schmidt: hey you
Jun 22 10:55:52 <Ainulindale> stefan_schmidt: we'll have a full blown 28 pages article in our french linux mag
Jun 22 10:55:56 <Ainulindale> stefan_schmidt: with ~7 pages on FSO
Jun 22 10:55:59 <Ainulindale> thanks to mickey
Jun 22 10:56:26 <onen|openBmap> stefan_schmidt: in dbus python calls, using timeout keyword, what is the unit? seconds?
Jun 22 10:58:19 <stefan_schmidt> Ainulindale: wow, thats indeed a lot. Good work.
Jun 22 10:58:30 <Ainulindale> stefan_schmidt: and his tutorial is really great
Jun 22 10:58:37 <Ainulindale> It'll be released under CC in 4 months
Jun 22 10:58:42 <Ainulindale> So we'll be able to put it online
Jun 22 10:59:16 <DocScrutinizer> PaulFertser: as connectivity dies silently (no traffic inbound to tear down connection), I probably even need RTC-alarm to re-establish GPRS after 23:55 :-(   --   nasty
Jun 22 10:59:16 <stefan_schmidt> onen|openBmap: not offhand. Just check some other code?
Jun 22 10:59:19 <stefan_schmidt> Ainulindale: nice
Jun 22 10:59:25 <Ainulindale> And the french editor in chief told me that if you want to translate into german and publish it into the german equivalent it's doable, you have to contact them
Jun 22 10:59:50 <Ainulindale> So it might be a good thing to do
Jun 22 11:00:00 <stefan_schmidt> Ainulindale: hmm
Jun 22 11:00:04 <onen|openBmap> stefan_schmidt: I dig through code, find connection.call_blocking() which calls send_message_with_reply_and_block, but I cannot find the source code of this one :-S
Jun 22 11:00:09 <admiral0> what about english, italian?
Jun 22 11:00:29 <stefan_schmidt> Ainulindale: I wonder if they accept 18 pages articles. All i wrote so far where <10 pages
Jun 22 11:00:44 <onen|openBmap> stefan_schmidt: Ainulindale: let's remove the shr part ;-)
Jun 22 11:01:08 <stefan_schmidt> onen|openBmap: I meant check how other code uses the timeout
Jun 22 11:01:14 <Ainulindale> stefan_schmidt: 28 pages
Jun 22 11:01:27 <stefan_schmidt> Ainulindale: err, sorry, typo
Jun 22 11:01:31 <Ainulindale> stefan_schmidt: ~7 on FSO, ~7 on H:1
Jun 22 11:01:38 <Ainulindale> ~10 on building SHR with OE
Jun 22 11:01:38 <onen|openBmap> stefan_schmidt: yep. I prefer to get it from the source, the dbus code itself. nevermind, I will figure it out :-)
Jun 22 11:01:42 <Ainulindale> ~4 on custom SHR software
Jun 22 11:01:42 <stefan_schmidt> Ainulindale: Ah, so it could be split
Jun 22 11:02:55 <stefan_schmidt> Ainulindale: May not be a bad idea. But I'm fully booked with university exams in july. No change to squeeze it in.
Jun 22 11:03:14 <stefan_schmidt> If we would like to do this I could only help starting from august
Jun 22 11:03:17 <DocScrutinizer> Ainulindale: make a special edition out of it. adding 10pp of index and glossary and it's about the amount of a regular issue ;-)
Jun 22 11:03:51 <PaulFertser> DocScrutinizer: i'm amazed at how many things in life actually suck :-/ And you can't do anything about it. They suck because of stupidity or malice, not because it's inherent to life, and you're still helpless and the best you can do is invent a workaround :-/
Jun 22 11:05:45 <DocScrutinizer> yup, here the workaround includes a decent at binary (over dbus, with ability to handle concurrent RTC schedules, which fso seems not to support despite I've been told different)
Jun 22 11:06:59 <stefan_schmidt> have to run guys. cu
Jun 22 11:10:26 <farhaven> whoa
Jun 22 11:10:39 <farhaven> dmesg says "bus error" now when i call my phone :D
Jun 22 11:10:49 <farhaven> neat
Jun 22 11:11:51 <DocScrutinizer> farhaven: dbus error?
Jun 22 11:12:04 <farhaven> nope
Jun 22 11:12:18 <farhaven> root@om-gta02 ~ $ dmesg              
Jun 22 11:12:18 <farhaven> Bus error
Jun 22 11:12:18 <farhaven> @om-gta02 /home/root $ dmesg
Jun 22 11:12:18 <farhaven> Bus error
Jun 22 11:12:24 <farhaven> that's what it says
Jun 22 11:12:34 <farhaven> and nope, the second prompt line isn't truncated at the beginning
Jun 22 11:12:45 <farhaven> i guess my rootfs is fried once again
Jun 22 11:13:16 <DocScrutinizer> U bet
Jun 22 11:13:55 <farhaven> hehe
Jun 22 11:13:57 <PaulFertser> DocScrutinizer: you see? Another report of GSM activity influencing SD card.
Jun 22 11:14:05 <DocScrutinizer> yup
Jun 22 11:14:07 <PaulFertser> In a particularly nasty way.
Jun 22 11:14:16 <farhaven> luckily i have qtopia in my nand flash
Jun 22 11:14:23 <farhaven> so i have a working phone in any case
Jun 22 11:14:30 <DocScrutinizer> had goosepimples already when reading your conversation :-/
Jun 22 11:14:40 <farhaven> hehe
Jun 22 11:15:29 <farhaven> there has to be some fix for this
Jun 22 11:15:44 * DocScrutinizer sometimes wonders if he'd be better off with butcher instead of EE for a profession ;-)
Jun 22 11:15:49 <farhaven> like temporarily suspending the sd card when gsm stuff happens
Jun 22 11:15:52 <farhaven> lol
Jun 22 11:16:27 <farhaven> hmm, fsck has been worse... just a few wrong block counts and zero dtimes
Jun 22 11:17:07 <PaulFertser> farhaven: is it with additional shielding?
Jun 22 11:17:21 <farhaven> nah, haven't tried that, but i guess time's due
Jun 22 11:17:42 <farhaven> i just hope i don't fry anything
Jun 22 11:18:26 <DocScrutinizer> farhaven: shouldn't be possible to fry anything
Jun 22 11:18:41 <DocScrutinizer> though we never really tested
Jun 22 11:19:38 <farhaven> so how do i do it? just wrap the card in gum wrapper?
Jun 22 11:20:17 <DocScrutinizer> I really doubt that will help any way
Jun 22 11:20:30 <farhaven> so do i, but i'm desperate
Jun 22 11:20:54 <PaulFertser> farhaven: no screen corruption this time?
Jun 22 11:21:19 <farhaven> nope
Jun 22 11:21:47 <farhaven> this was with testing btw
Jun 22 11:22:57 <DocScrutinizer> farhaven: you might want to crank up drive power of glamo sdcard if lines
Jun 22 11:23:19 <farhaven> how?
Jun 22 11:23:22 <DocScrutinizer> no, I don't know how to do this ;-)
Jun 22 11:23:27 <farhaven> damn :D
Jun 22 11:23:29 <PaulFertser> farhaven: by a kernel parameter
Jun 22 11:23:45 <farhaven> does one exist or is this purely hypthetical?
Jun 22 11:23:59 <PaulFertser> farhaven: glamo_mci.sd_drive
Jun 22 11:24:18 <farhaven> what are the options to that parameter?
Jun 22 11:24:18 <DocScrutinizer> farhaven: you also should test while gps enabled, if this helps
Jun 22 11:24:38 <farhaven> first it has to work without anything :P
Jun 22 11:24:57 <farhaven> damn, gotta go eat... bbl
Jun 22 11:25:08 <DocScrutinizer> farhaven: nah, it might work *better* with gps
Jun 22 11:28:30 <PaulFertser> farhaven: 0, 1, 2. 
Jun 22 11:30:45 <SHR-WugBranler> tracfeed: Ticket #527 (gprs does not rememeber login, apn, pass) created <http://trac.shr-project.org/trac/ticket/527>
Jun 22 11:30:48 <PaulFertser> farhaven: zero is the weakest, 3 is the strongest.
Jun 22 11:31:07 <PaulFertser> farhaven: see 93a92d72b7b77c8238116316ef24dfb740beae91 for reference about this and others parameters.
Jun 22 11:48:04 <farhaven> thx
Jun 22 11:48:16 <farhaven> DocScrutinizer: not that i know of :)
Jun 22 11:48:32 <farhaven> the first two occasions of this freeze + sdcard destruction happened while tangogps was running
Jun 22 11:48:42 <farhaven> but that might be a coincidence
Jun 22 11:48:47 <farhaven> re btw
Jun 22 11:51:46 <farhaven> PaulFertser: where can i view those commits without checking out some repo?
Jun 22 11:52:00 <farhaven> i.e. is there something like gitweb running somewhere?
Jun 22 11:56:12 <PaulFertser> farhaven: git.openmoko.org
Jun 22 11:56:18 <farhaven> thx
Jun 22 12:08:44 <Blu3> paulfertser, i may have a related gsm/sd card issue.  when i fire up pidgin which does a lot of gprs network traffic, within minutes my sdcard goes offline and suffers corruption.  i have to reboot and fsck it
Jun 22 12:09:29 <Blu3> that only happens when doing a lot of gprs chatter though.  not due to calls
Jun 22 12:10:12 <PaulFertser> Blu3: have you tried with another card?
Jun 22 12:12:03 <Blu3> paulfertser a lot of time spent with apps is python instantiating.  on my phone, it takes some five-ten seconds for an app to start running because python is scouring the filesystem looking for libraries and modules.
Jun 22 12:12:16 <Blu3> and we don't have the memory to preload things
Jun 22 12:12:26 <farhaven> hmm, i just tried that sd_drive thingie
Jun 22 12:12:29 <farhaven> so far it seems to work
Jun 22 12:12:31 <PaulFertser> Blu3: yes, same here. How is that relevant?
Jun 22 12:12:50 <PaulFertser> farhaven: really? Sounds like good news.
Jun 22 12:13:01 <farhaven> hehe, i hope it stays like this
Jun 22 12:13:10 <farhaven> i'll do some more testing under higher load
Jun 22 12:13:18 <Blu3> hmm, another thing i note wrt. to the sd corruption, is that i'm usually running gps
Jun 22 12:13:51 <farhaven> hehe, that sounds familiar to me
Jun 22 12:14:02 <Blu3> what's the reason for the 8x slowdown, and sysfs pathname to change that?
Jun 22 12:14:03 <farhaven> my first two corruptions also occured while using gps
Jun 22 12:14:38 <PaulFertser> Blu3: the reason is anectotical evidence that it might help. Change it (and other sd parameters) in /sys/modules/glamo_mci/
Jun 22 12:16:25 <PaulFertser> Blu3: what really reduces SD-GPS interference is drive strength. I don't see how slower SD clock can help, probably it's just useless.
Jun 22 12:16:41 <PaulFertser> Blu3: it'd be nice to test it (hint-hint)
Jun 22 12:16:48 <farhaven> wow, it really seems to work...
Jun 22 12:16:51 <farhaven> what's the default value of sd_drive and are there any downsides of increasing it?
Jun 22 12:16:53 <Blu3> paul, i have, i have two 4G cards and they both give me corruption without any gprs period
Jun 22 12:17:15 <Blu3> this 2G card i have in it now is the most reliable of all.  works fine unless i do the above
Jun 22 12:17:28 <farhaven> so it doesn't really work fine :P
Jun 22 12:17:40 <Blu3> paulfertser, you were talking earlier about how to make apps lightning fast
Jun 22 12:17:59 <Blu3> thus i mentioned the python issues
Jun 22 12:18:11 <Blu3> python isn't the fastest interpreted language
Jun 22 12:18:27 <Blu3> and loading, is very slow
Jun 22 12:18:45 <Blu3> hmm
Jun 22 12:18:58 <Blu3> overnight my phone seems to have gone OOM.  it is unresponsive
Jun 22 12:19:17 <Blu3> and ffalarms has an app crash dialog displayed
Jun 22 12:20:08 <Blu3> in ~40 minutes of time, my two terminals have finally echoed 'uptime\n' and 'reboot\n', but they haven't executed yet :D
Jun 22 12:20:51 <farhaven> lol
Jun 22 12:21:14 <PaulFertser> farhaven: default is 0, the downside of increasing is potential degradation of GPS reception quality, leading to inability to get a fix (probably this downside is valid only for units without hardware gps fix).
Jun 22 12:21:30 <farhaven> hmm
Jun 22 12:21:46 <farhaven> yeah, probably, because i have kind of a fix here
Jun 22 12:21:57 <farhaven> it displays gps time, but no sattelites reachable
Jun 22 12:22:05 <PaulFertser> Blu3: yes, but SHR apps are all C, FSO is being rewritten in vala. Also python is fast enough after it's loaded if used wisely.
Jun 22 12:22:06 <farhaven> that might be because of my window shades, though
Jun 22 12:22:14 <Blu3> yup
Jun 22 12:23:28 <Blu3> i've not looked into vala yet, i understand it's a ...layering?, on top of C? to add certain language conveniences often found in interpreted languages i think?
Jun 22 12:23:50 <DocScrutinizer> farhaven: shr-settings-gps is *always* showing time afaik
Jun 22 12:23:57 <farhaven> i mean tangogps
Jun 22 12:24:04 <PaulFertser> Blu3: it's a new language modelled after python and c# iirc. Compiled into C code.
Jun 22 12:24:19 <farhaven> i'll check whether i can get a fix...
Jun 22 12:24:21 <Blu3> ok
Jun 22 12:24:29 <PaulFertser> farhaven: stress-test the card while doing it.
Jun 22 12:24:43 <PaulFertser> farhaven: because if there's no card access, the clock is disabled completely anyway.
Jun 22 12:24:51 <PaulFertser> farhaven: do you have a hardware fix?
Jun 22 12:25:33 <farhaven> yeah, i have a gta02v6
Jun 22 12:25:53 <DocScrutinizer> farhaven: all this sd-drive and sd-clock tweaking was to fix a hw-issue that spoils gps by usd-clock. the most important fix though was switching off clock during non-access periods
Jun 22 12:25:53 <farhaven> with a little capacitor soldered into the sd card slot
Jun 22 12:25:55 <PaulFertser> farhaven: so stress-test the card and try to get a fix outside.
Jun 22 12:26:25 <DocScrutinizer> farhaven: not all gta02A6 have gps-hw-fix
Jun 22 12:26:31 <DocScrutinizer> afair
Jun 22 12:26:52 <farhaven> well, it was advertised with the fix and it has this little capacitor soldered in
Jun 22 12:26:57 <farhaven> so i'd say it's fixed
Jun 22 12:26:57 <DocScrutinizer> farhaven: the little C in slot is the fix
Jun 22 12:27:22 <farhaven> hmm, even with an idle sdcard, there's no satellite fix
Jun 22 12:27:24 <DocScrutinizer> yup
Jun 22 12:27:46 <farhaven> i'll turn sd_drive down a bit
Jun 22 12:28:39 <DocScrutinizer> idle sdcard should have no impact on gps
Jun 22 12:28:45 <Blu3> ahh, if only my prompt would come back.  i could run echo b > /proc/sysrq-trigger and reboot it
Jun 22 12:28:53 <DocScrutinizer> no matter which drive-power
Jun 22 12:29:51 <PaulFertser> farhaven: no, with an idle sdcard sd_drive value is irrelevant.
Jun 22 12:30:05 <farhaven> hmm
Jun 22 12:30:17 <farhaven> i'll play around with agps a bit, maybe that helps
Jun 22 12:30:27 <PaulFertser> farhaven: are you sure conditions are decent where you are atm?
Jun 22 12:31:01 <farhaven> should be
Jun 22 12:31:32 <DocScrutinizer> farhaven: removing pickle, and sitting at plain blue sky for 1pmin always helps
Jun 22 12:31:32 <farhaven> almost clear sky, only a few layers of insulation wool over my head and open skylights
Jun 22 12:31:34 <PaulFertser> farhaven: sd clock is turned off completely when there's no sd card access.
Jun 22 12:31:51 <DocScrutinizer> 10
Jun 22 12:32:33 <DocScrutinizer> but you need to make sure there's no access
Jun 22 12:32:34 <farhaven> anyway, gps performance is secondary
Jun 22 12:32:52 <farhaven> which is a problem if the sd is my / :)
Jun 22 12:33:05 <PaulFertser> DocScrutinizer: i still can't understand how the fs can get corrupted, i think SD<->controller exchange is checksummed.
Jun 22 12:33:26 <DocScrutinizer> dunno
Jun 22 12:33:54 <Blu3> dunno, but it gets fracked in a big way
Jun 22 12:34:03 <farhaven> i'm not sure whether fs corruption was from io errors or because i hard shutdown my phone
Jun 22 12:34:21 <DocScrutinizer> ooohohoh
Jun 22 12:34:31 <farhaven> though i doubt the latter could cause such severe damage
Jun 22 12:34:36 <Blu3> i've gotten the same result on four different cards.  i'm chalking up the 4gig cards constant corruption to some incompatibility with them
Jun 22 12:34:49 <PaulFertser> DocScrutinizer: also you see, he says that pure hardware fix is not enough and he has to lower sd_drive (i think the default was 2 during the time that issue was found and investigated).
Jun 22 12:34:58 <Blu3> mine goes R/O by the kernel after the corruption
Jun 22 12:35:42 <farhaven> lucky you :)
Jun 22 12:35:53 <farhaven> here, / disappears
Jun 22 12:35:58 <Blu3> well, that just prevents further corruption
Jun 22 12:36:03 <Blu3> i use mine for /home
Jun 22 12:36:05 <DocScrutinizer> PaulFertser: hw fix only on clock. we always knew data lines would do same damage
Jun 22 12:36:14 <Blu3> so my root fs (nand) is still running fine
Jun 22 12:36:21 <PaulFertser> DocScrutinizer: how does hw fix help anything then?
Jun 22 12:36:46 <DocScrutinizer> filter clock on idle, in pre-sw-fixed times
Jun 22 12:37:08 <DocScrutinizer> notw we have pads for C on all lines
Jun 22 12:38:08 <PaulFertser> DocScrutinizer: the sw fix (to disable clock on idle) was trivial comparing to a hassle of hardware-fixing all future phones.
Jun 22 12:38:42 <DocScrutinizer> hmm, what's your point?
Jun 22 12:39:48 <PaulFertser> DocScrutinizer: i thought that hw fix really helps.
Jun 22 12:40:12 <PaulFertser> And now it looks like it is almost completely useless.
Jun 22 12:40:22 <DocScrutinizer> PaulFertser: with clock stop, on second thought it's useless
Jun 22 12:42:20 <PaulFertser> DocScrutinizer: so clock stop is mandatory anyway (and it was supposed glamo does that automatically) and it looks like the only real fix is lowering drive strength. But now we see it has some very nasty side-effects as it sometimes fail to resist GSM-interference. Not cool.
Jun 22 12:43:01 <DocScrutinizer> euphemism of the day, nah week
Jun 22 12:43:36 <PaulFertser> DocScrutinizer: probably we should even switch the kernel default to some "safe" value. Because corruption of SD rootfs is worse than harming GPS reception.
Jun 22 12:44:12 <PaulFertser> farhaven: can you please try with drive strength 1?
Jun 22 12:44:21 <DocScrutinizer> hmm, we needed some decent tests on a xx number of devices/uSD
Jun 22 12:44:52 <farhaven> PaulFertser: weather just turned bad, big cloud directly overhead, so i think reception would be very bad anyway
Jun 22 12:44:58 <PaulFertser> DocScrutinizer: even if like 1/50th of units experience corruption with strength==0, i guess we should better increase it.
Jun 22 12:45:01 <DocScrutinizer> alas it seems there's no more manpower left over in TPE to do this
Jun 22 12:45:30 <PaulFertser> farhaven: test if can provoke any corruption with strength 1.
Jun 22 12:45:36 <PaulFertser> farhaven: please 
Jun 22 12:45:42 <DocScrutinizer> PaulFertser: we should have 12pF on datalines as well
Jun 22 12:45:59 <farhaven> ah, yup, will do
Jun 22 12:46:02 <DocScrutinizer> :-/
Jun 22 12:46:14 <PaulFertser> DocScrutinizer: obviously. Probably it was obvious from the day that sd clock interference was discovered.
Jun 22 12:46:22 <DocScrutinizer> at least we got the pads
Jun 22 12:46:35 <DocScrutinizer> yup
Jun 22 12:46:55 <DocScrutinizer> was obvious. I insisted on that the very first day
Jun 22 12:47:10 <PaulFertser> DocScrutinizer: no doubt
Jun 22 12:47:16 <DocScrutinizer> that's why we got the pads at last
Jun 22 12:48:35 <DocScrutinizer> but fitting those C on MP can't be done with decent tests again. So TPE decided we shouldn't have them
Jun 22 12:48:48 <PaulFertser> DocScrutinizer: is it a hint to farhaven that he should find some 12pF and solder it there?
Jun 22 12:49:08 <DocScrutinizer> I'd say can't hurt
Jun 22 12:49:23 <DocScrutinizer> 10..12
Jun 22 12:49:45 <farhaven> hehe, my soldering skills when it comes to surface mount stuff are more than limited
Jun 22 12:50:55 <DocScrutinizer> PaulFertser: worst thing that can happen it will currupt SD ;-)
Jun 22 12:51:34 <PaulFertser> :)
Jun 22 12:51:36 <DocScrutinizer> and removing those C is easy. that's why I'd prefer to have them instead of *not*
Jun 22 12:51:57 <Blu3> what size are the pads designed for, 6904?
Jun 22 12:51:59 <Blu3> -9
Jun 22 12:52:14 <DocScrutinizer> hehe
Jun 22 12:52:30 <DocScrutinizer> PZPE possibly
Jun 22 12:52:36 <DocScrutinizer> 0603
Jun 22 12:52:52 <Blu3> hmm, i need to restock
Jun 22 12:53:57 <DocScrutinizer> Blu3: if you really need to know please nag me later and I look up in BOM
Jun 22 12:54:19 <DocScrutinizer> or layout
Jun 22 12:54:33 <farhaven> hmm, how can i generate lots of sd card load?
Jun 22 12:54:35 <Blu3> no pressing worry.  i need to order some more supplies for things but it'll be a couple weeks.  too many things on my plate right now
Jun 22 12:54:45 <Blu3> farhaven, run pidgin ;)
Jun 22 12:54:45 <farhaven> dd if=/dev/zero of=foo bs=1024k count=500 should suffice, right?
Jun 22 12:54:48 <farhaven> hehe
Jun 22 12:55:10 <Blu3> seriously, pidgin does a huge amount of disk i/o
Jun 22 12:55:20 <Blu3> rather ostentatious :/
Jun 22 12:55:46 <DocScrutinizer> farhaven: yup
Jun 22 12:56:33 <DocScrutinizer> farhaven: though for this particular test I recommend /dev/urandom
Jun 22 12:57:21 <farhaven> k
Jun 22 12:57:37 <DocScrutinizer> and maybe bs=10k, in a while true loop
Jun 22 12:58:16 <DocScrutinizer> or count=50
Jun 22 12:59:21 <farhaven> okay, first try with bs=1024k and count=500 worked
Jun 22 12:59:23 <farhaven> laggy but stable
Jun 22 13:02:58 <farhaven> second try was fine also
Jun 22 13:03:05 <farhaven> cool, sd_drive=1 seems to solve it
Jun 22 13:03:20 <DocScrutinizer> I remeber I suggested to Sean to reward the guy who found the sd-gps issue and he was excited. I bet nothing ever happened in the end
Jun 22 13:04:20 <DocScrutinizer> farhaven: you don't know if corruption took place on the written data
Jun 22 13:04:40 <farhaven> hmm, then dd with if=/dev/zero would be better
Jun 22 13:04:53 <farhaven> and if something different than 0x00 ended up in there, corruption happened
Jun 22 13:05:10 <DocScrutinizer> yup, it won't spill gps that much, but easier to check
Jun 22 13:05:51 <Blu3> farhaven, use 0x55 and 0xaa for test patterns
Jun 22 13:06:07 <farhaven> how would i do that with dd?
Jun 22 13:06:14 <farhaven> and how could i then easily check that file?
Jun 22 13:06:15 <DocScrutinizer> hehe
Jun 22 13:06:34 <farhaven> maybe i'll write a little perl script to do that
Jun 22 13:07:04 <Blu3> python :)
Jun 22 13:07:09 <farhaven> nah :D
Jun 22 13:07:18 <farhaven> damnit, it has to be python :D
Jun 22 13:07:22 <Blu3> root@nibbly-bits:~# which perl
Jun 22 13:07:22 <Blu3> root@nibbly-bits:~#
Jun 22 13:07:26 <PaulFertser> farhaven: and don't forget to call the device while you're doing it.
Jun 22 13:07:29 <DocScrutinizer> echo \0x55\0xaa >xxx; dd if=xxx of=xxx bs=2 count=100k
Jun 22 13:07:48 <farhaven> DocScrutinizer: neat, thx
Jun 22 13:07:51 <farhaven> PaulFertser: heh
Jun 22 13:07:54 <Blu3> actually, i was suggesting 0x55 full count, check, 0xaa full count, check
Jun 22 13:08:09 <PaulFertser> farhaven: the point is to find out if 1 is enough to prevent corruption in all possible circumstances.
Jun 22 13:08:13 <Blu3> the reason is that 0x55 and 0xaa are alternating bit patters
Jun 22 13:08:34 <farhaven> Blu3: smart :D
Jun 22 13:08:35 <Blu3> i.e. 0101 vs 1010
Jun 22 13:10:03 <DocScrutinizer> Blu3: no edges on datalines
Jun 22 13:11:02 <DocScrutinizer> but actually 0xff 0x00 is better for that
Jun 22 13:11:32 <Blu3> 'tis not the edges i'm interested in, it's detecting bit flips more easily.  writing all 1, or all 0 is sometimes too constant of a pattern
Jun 22 13:11:43 <Blu3> i also use high vs low nibbles
Jun 22 13:12:13 <DocScrutinizer> Blu3: use memtest then ;-)
Jun 22 13:12:24 <Blu3> if this were parallel, i'd use a walking bit pattern to test traces
Jun 22 13:12:44 <farhaven> okay, so i did while true; do printf "\x55" >> foo; done
Jun 22 13:12:49 <farhaven> and called the phone
Jun 22 13:12:56 <farhaven> and foo contains all uppercase Us
Jun 22 13:13:01 <farhaven> looks good then, right?
Jun 22 13:13:07 <Blu3> mhm
Jun 22 13:13:20 <farhaven> i'll repeat with 0xaa
Jun 22 13:13:50 <PaulFertser> DocScrutinizer: probably drive strength 1 is exactly good and both avoids corruption and allows gps to work. In this case we just need to make it default.
Jun 22 13:14:06 * Blu3 wonders what went OOM in the night
Jun 22 13:14:52 <DocScrutinizer> PaulFertser: well, at least with THAT particular uSD
Jun 22 13:16:08 <farhaven> \xaa looks good also
Jun 22 13:16:13 <PaulFertser> DocScrutinizer: i think most users use the kernel where 0 (weakest) is default. So if we change it to 1 at least it won't became less stable (though gps reception might be harmed a little).
Jun 22 13:16:27 <farhaven> i have another uSD here, i think i could also try that one
Jun 22 13:16:53 <DocScrutinizer> PaulFertser: ack, and OK from OM-EE ;-)
Jun 22 13:17:14 <Blu3> hmm
Jun 22 13:17:55 <PaulFertser> DocScrutinizer: :D but more testing is needed. If one is unable to use GPS while stress-testing the card with 1, then we're better off with huge warning somewhere so those unlucky guys who have corruption know what to do.
Jun 22 13:18:48 <Blu3> are there enough time slices with tango gps running that it can download maps and store them on an SD card, with other SD card read/write stuff going on?  i need to script up some testing toys
Jun 22 13:18:50 <DocScrutinizer> I leave that decission up to you
Jun 22 13:20:05 <PaulFertser> I'll wait for the test results of farhaven and Blu3. Too bad nobody seem to have access to equipment used by Andy where he was able to actually measure levels in dB.
Jun 22 13:20:33 <DocScrutinizer> that wasn't andy afair
Jun 22 13:20:41 <farhaven> PaulFertser: with sd io created by the endless loop and by dd, it worked fine
Jun 22 13:20:42 <DocScrutinizer> done in TPE
Jun 22 13:20:44 <PaulFertser> DocScrutinizer: ah, it was written in his commit message.
Jun 22 13:20:53 <farhaven> though i don't know how stable it is
Jun 22 13:21:18 <PaulFertser> farhaven: that's good to hear. Please also try to estimate if it harms GPS performance.
Jun 22 13:22:19 <PaulFertser> I think lindi- might be interested to test gps performance while stresstesting SD card with sd drive strength set to 1 too.
Jun 22 13:22:43 <farhaven> yeah, i'll try it once i'm sure the reason for not getting a fix isn't the weather
Jun 22 13:22:44 <PaulFertser> bbl
Jun 22 13:33:37 <Blu3> i can't do any testing right now.  'tis already difficult to get a fix in here and it's heavily overcast with dark thunderstorms a short bit off.  and i'm getting the evil eye from my boss :>
Jun 22 13:33:46 <DocScrutinizer> farhaven: best bet is to remove uSD, to have a reference with sure interference-free setup
Jun 22 13:34:11 <farhaven> yeah, good idea
Jun 22 13:34:26 <farhaven> Blu3: same here, except for the work thingie :D
Jun 22 13:34:36 <Blu3> heheh
Jun 22 13:46:13 <DocScrutinizer> if anybody has an old cellphone with protruding antenna (better even: pull-out antenna): please remove SIM from FR, run a dd to uSD and touch the uSD with tip of old cellphone while call and *talking to the old phone* (otherwise it won't send even if call is established - tx-stop-on-silence)
Jun 22 13:46:41 <mrmoku> ptitjes, ping
Jun 22 13:51:18 <farhaven> DocScrutinizer: couldn't we just use some 900MHz transmitter sending noise?
Jun 22 13:51:39 <farhaven> i have the suspicion in my house that might be easier to find than an old cellphone
Jun 22 13:51:57 <DocScrutinizer> sure you can, if you may or dare, and have a 2W transmitter ;-)
Jun 22 13:52:19 <farhaven> hehe, that might fry my brain
Jun 22 13:52:40 <DocScrutinizer> duh, how?
Jun 22 13:53:04 <DocScrutinizer> gsm900 is 2W max afaik
Jun 22 13:53:23 <DocScrutinizer> or was it 1W
Jun 22 13:53:31 <farhaven> 1 i think
Jun 22 13:53:32 <farhaven> not sure
Jun 22 13:54:21 <DocScrutinizer> at least 1800 is half as much. nevertheless if you have the tools, please test with max power and on all 4 bands. thanks in advance
Jun 22 13:54:48 <farhaven> i'll talk so some friends of mine who might have that stuff
Jun 22 13:55:01 <DocScrutinizer> cool :-)
Jun 22 13:57:00 <DocScrutinizer> farhaven: btw this way I found the true cause of buzz ;-)
Jun 22 13:57:35 <mrmoku> ptitjes, nvm... found it :)
Jun 22 13:59:17 <mrmoku> ptitjes, hmm... ping again :P
Jun 22 14:13:25 <SHR-WugBranler`> tracfeed: Ticket #527 (gprs does not rememeber login, apn, pass) closed <http://trac.shr-project.org/trac/ticket/527#comment:1>
Jun 22 14:19:17 <Frank1> did anyone of you has a recently build shr-unstable image?
Jun 22 14:19:44 <Blu3> my shr-unstable is current via opkg as of 24hrs ago
Jun 22 14:25:12 <Frank1> @Blu3, you build/installed it or just updated via opkg?
Jun 22 14:25:27 <Blu3> 4mo install, kept current w/ opkg
Jun 22 14:27:24 <Frank1> ah ok, no i need a rootfs image and the last on the server is 5 days old
Jun 22 14:27:33 <ptitjes> mrmoku: pong
Jun 22 14:28:41 <mrmoku> ptitjes, hey
Jun 22 14:28:53 <mrmoku> ptitjes, I wanted to switch to libfso-glib... but if I understand correctly
Jun 22 14:28:56 <mrmoku> not possible
Jun 22 14:28:57 <mrmoku> :(
Jun 22 14:29:20 <ptitjes> ha ok
Jun 22 14:29:35 <mrmoku> how is async dbus stuff proceding in vala land?
Jun 22 14:30:00 <DocScrutinizer> no async in vala yet
Jun 22 14:30:08 <ptitjes> yes there is
Jun 22 14:30:16 <DocScrutinizer> huh?
Jun 22 14:30:40 <ptitjes> mrmoku: libfso is not generated with async directives yet
Jun 22 14:30:52 <mrmoku> ptitjes, what would it need to get that? :D
Jun 22 14:30:59 <ptitjes> work
Jun 22 14:31:06 <DocScrutinizer> mickey|zzZZzz told me different some days ago - well I might be mistaken
Jun 22 14:31:17 <mrmoku> hmm... any ETA estimates?
Jun 22 14:31:27 <ptitjes> no
Jun 22 14:31:49 <mrmoku> I did not want to fiddle with libframeworkd-glib anymore... 
Jun 22 14:31:54 <mrmoku> but if it is like that...
Jun 22 14:31:56 <ptitjes> well I'm tired because I quite not sleep this week
Jun 22 14:31:59 <mrmoku> I guess I will have too
Jun 22 14:32:06 <DocScrutinizer> well anyway first dbus needs to support async ;ßl
Jun 22 14:32:18 <ptitjes> thus I am a bit in a bad mood
Jun 22 14:32:20 <mrmoku> -o
Jun 22 14:32:30 <ptitjes> so maybe we'll have to speak about that later
Jun 22 14:32:37 <mrmoku> ptitjes, then take a nap... and lets talk later :)
Jun 22 14:32:44 <farhaven> neat, GPS works with sd_drive=1
Jun 22 14:32:48 <ptitjes> like July when this will be better
Jun 22 14:33:02 <mrmoku> hehe... ok. understood that
Jun 22 14:33:22 <DocScrutinizer> farhaven: good
Jun 22 14:33:24 <ptitjes> I quite killed myself in a truck some minutes
Jun 22 14:33:25 <ptitjes> ago
Jun 22 14:33:39 <ptitjes> because I felt asleep while driving
Jun 22 14:33:49 <farhaven> DocScrutinizer: but... :D
Jun 22 14:33:52 <farhaven> io error
Jun 22 14:33:57 <farhaven> i'll retry with sd_drive=2
Jun 22 14:33:59 <ptitjes> and my boss made me reproaches about the fact I was asleep
Jun 22 14:34:09 <ptitjes> and indeed he is responsible for that
Jun 22 14:34:19 <ptitjes> so here is why I'm really pissed off
Jun 22 14:34:22 <ptitjes> c u guys
Jun 22 14:35:21 <DocScrutinizer> farhaven: IO-error on GSM tx?
Jun 22 14:35:34 <farhaven> IO error on GSM ring
Jun 22 14:35:41 <farhaven> i don't know whether that counts as tx
Jun 22 14:35:59 * Blu3 is falling asleep too, but not driving :>
Jun 22 14:36:07 <farhaven> and it looks like gps needs a fix for this issue to appear
Jun 22 14:36:13 <DocScrutinizer> hmm, yes, but maybe it's a different source of problem then
Jun 22 14:36:58 <farhaven> could be
Jun 22 14:37:05 <farhaven> maybe it's just a coincidence
Jun 22 14:37:08 <DocScrutinizer> sd-io has nothing to do with gps-fix afaik
Jun 22 14:37:34 <farhaven> hmm, the fs is definitely unusable now
Jun 22 14:37:36 <DocScrutinizer> coincidence is major problem of EE debuging
Jun 22 14:37:43 <farhaven> fsck complains about short reads while reading inodes
Jun 22 14:37:48 <farhaven> hehe, i figured
Jun 22 14:38:03 <DocScrutinizer> I refuse to even think about errors that aren't happening at least twice
Jun 22 14:38:35 <farhaven> ugh, is it a bad sign if mkfs.ext2 complains about not being abled to read and erase sector 0?
Jun 22 14:38:47 <Blu3> is it R/O?
Jun 22 14:38:54 <farhaven> nope
Jun 22 14:39:02 <Blu3> don't work on a R/W fs :)
Jun 22 14:39:10 <Blu3> remount / R/O before fsck
Jun 22 14:39:12 <farhaven> well, it isn't mounted
Jun 22 14:39:16 <Blu3> ok
Jun 22 14:39:17 <farhaven> mkfs
Jun 22 14:39:24 <farhaven> fsck complained about a lot of short reads
Jun 22 14:39:33 <farhaven> so i aborted, because the fs is broken anyway
Jun 22 14:39:43 <Blu3> aye
Jun 22 14:39:44 <farhaven> luckily i made a backup :)
Jun 22 14:39:47 <Blu3> :)
Jun 22 14:40:08 <farhaven> damnit, what is this? "ext2fs_mkdir: Attempt to read block from filesystem resulted in short read while creating root dir"
Jun 22 14:40:17 <farhaven> sounds like the card is fubar
Jun 22 14:41:05 <DocScrutinizer> are you running system from bat or from usb?
Jun 22 14:41:22 <farhaven> usb
Jun 22 14:41:40 <farhaven> and this is the first time mkfs.ext2 complains about anything
Jun 22 14:41:47 <DocScrutinizer> with a good bat inserted nevertheless
Jun 22 14:42:00 <farhaven> yep
Jun 22 14:42:06 <farhaven> the bat is new and 100% charged
Jun 22 14:43:19 <DocScrutinizer> farhaven: ok, at least it seems you easily can reproduce the bug now
Jun 22 14:43:30 <farhaven> yep
Jun 22 14:44:01 <DocScrutinizer> could you post exact steps to reproduce to hw-ml please
Jun 22 14:44:21 <farhaven> sure, second...
Jun 22 14:44:31 <DocScrutinizer> or to according ticket at track, whatever you prefer
Jun 22 14:44:59 <farhaven> hmm, yeah, i already opened a ticket on the shr trac
Jun 22 14:45:07 <farhaven> i'll append some more info to that
Jun 22 14:45:46 <farhaven> damnit, i think the sdcard is broken
Jun 22 14:45:57 <farhaven> maybe it was the cards fault after all
Jun 22 14:46:00 <DocScrutinizer> please use om-trac. this isn't a shr-issue
Jun 22 14:46:04 <farhaven> okay
Jun 22 14:46:27 <DocScrutinizer> make sure it isn't your card first, though
Jun 22 14:46:30 <DocScrutinizer> ;-)
Jun 22 14:47:21 <farhaven> hehe
Jun 22 14:47:40 <farhaven> i'm getting an awful lot of io errors while doing mkfs, so yeah, looks like the card is broken
Jun 22 14:47:57 <farhaven> which is pretty sad because it lasted only a week and it was advertised as being compatible to the fr
Jun 22 14:48:55 <DocScrutinizer> farhaven: I bought a 16G card which was broken from very beginning
Jun 22 14:49:30 <DocScrutinizer> (please use OM trac) or hw-ml of course
Jun 22 14:49:31 <farhaven> hmm, i'll get in touch with the guy who sold the card
Jun 22 14:49:38 <farhaven> yup
Jun 22 14:57:54 <Blu3> farhaven, try building your FS via your desktop machine
Jun 22 14:58:17 <Blu3> every single one of my SD cards works perfectly on my desktop, but are really touchy inside the phone
Jun 22 14:58:25 <Blu3> the 4G cards don't work period
Jun 22 15:09:28 <dos1|neo> i've just send my first openbmap log :)
Jun 22 15:09:36 <dos1|neo> GPS worked today
Jun 22 15:09:40 <dos1|neo> dunno why
Jun 22 15:10:46 <farhaven> Blu3: hehe, i don't have an sdcard reader :)
Jun 22 15:11:02 <Frank1> @farhaven, digicam?
Jun 22 15:11:05 <Blu3> doh!
Jun 22 15:11:18 <farhaven> Frank1: good call, but that's buried somewhere...
Jun 22 15:11:33 <farhaven> atm i'm checking whether it might've been contact issues
Jun 22 15:11:34 <farhaven> which i hope
Jun 22 15:12:38 <farhaven> and else...
Jun 22 15:12:47 <farhaven> my brother has an eeepc, maybe i can use that
Jun 22 15:15:27 <farhaven> ah, now this looks a bit better
Jun 22 15:18:07 <farhaven> yay, lucky me, mkfs works again :D
Jun 22 15:36:35 <Blu3> good :)
Jun 22 15:41:58 <farhaven> hmm, so far, gps+receiving a call+sd_drive=2 worked
Jun 22 15:42:09 <farhaven> lets see for how long :D
Jun 22 15:48:49 <Blu3> heheheh
Jun 22 16:05:11 <Weiss> i went ahead and added community members to the wiki as proposed on OM-Community
Jun 22 16:05:16 <Weiss> http://wiki.openmoko.org/wiki/Who_is_Who
Jun 22 16:05:45 <Weiss> any obvious errors or omissions?
Jun 22 16:27:40 <Frank1> in the gsm gadget there are two part one for fso and one for qtopia since they have different services, any way to find out which is running on a system?
Jun 22 17:04:17 <CIA-45> freesmartphone.org: 03mickey 07cornucopia * rb90c30724e2f 10/fsousaged/src/plugins/controller/plugin.vala: 
Jun 22 17:04:17 <CIA-45> freesmartphone.org: fsousaged: fix resource policy handling; since we can't use the
Jun 22 17:04:17 <CIA-45> freesmartphone.org: enumeration code in here, it always transferred 0 instead of the
Jun 22 17:04:17 <CIA-45> freesmartphone.org: real value :/
Jun 22 17:04:37 <CIA-45> freesmartphone.org: 03mickey 07cornucopia * r43f742d77256 10/tests/ (org.fresmartphone.Usage.py testserver.py): tests: start w/ dbus unit tests
Jun 22 17:12:50 <DocScrutinizer> are there tools and manpage/howto/spec for *.edc, or is user supposed to edit textfile and learn semantics by intuition?
Jun 22 17:19:27 <dos1|neo> DocScrutinizer: i'm using intuition ;D
Jun 22 17:20:04 <DocScrutinizer>  /usr/sbin/intuition ?
Jun 22 17:21:11 <DocScrutinizer> I'm totally stuck with illume.edc and terminal-kbd useless topbar
Jun 22 17:23:08 <DocScrutinizer> found something that looks like right area around line 1460, but NO idea how to slim down that nuisance
Jun 22 17:24:26 <dos1|neo> hmm
Jun 22 17:24:52 <dos1|neo> but removing topbar only on terminal keyboard?
Jun 22 17:25:27 <dos1|neo> it would be nice
Jun 22 17:26:14 <dos1|neo> DocScrutinizer: have you looked at terminal keyboard "source"?
Jun 22 17:26:47 <DocScrutinizer> duh, no. wouldn't dare
Jun 22 17:27:50 <DocScrutinizer> dos1|neo: raster told me I can change "easily" in .edj :-/
Jun 22 17:29:29 <Blu3> aren't .edj files binary?
Jun 22 17:31:52 <DocScrutinizer> edje_decc illume.edj
Jun 22 17:45:06 <DocScrutinizer> dos1|neo: looking at those .edc and scratching my head, I start to adore qt-designer and even ncurses
Jun 22 17:47:51 <dos1|neo> DocScrutinizer: hehe ;)
Jun 22 17:48:13 <dos1|neo> i was only editing simple edc's
Jun 22 17:48:35 <dos1|neo> my elementary apps don't use edc/edj files
Jun 22 17:48:57 <dos1|neo> maybe that's bad - layouting, theming etc.
Jun 22 17:50:08 <dos1|neo> but i'm to lazy to understand edc ;)
Jun 22 17:50:14 <DocScrutinizer> it's a real PITA we got a rather cool system, but all our docs are even worse than ALSA specs
Jun 22 17:52:02 <DocScrutinizer> pondering this whole situation I feel like it's not far away I can use windoof as well
Jun 22 17:53:25 * mrmoku thinks it's a long time ago DocScrutinizer used Windoof... for giving such a statement ;)
Jun 22 17:53:54 <dos1|neo> hehe ;)
Jun 22 17:54:06 <DocScrutinizer> mrmoku: yes, and I stopped using it mainly for its opaqueness
Jun 22 17:55:00 <Frank1> please, no discussion about windows, i have to search problems there tomorrow again and do not want to think about it just now
Jun 22 17:55:05 <DocScrutinizer> this argument is moot meanwhile it seems
Jun 22 17:57:01 <DocScrutinizer> not that windoof got any better, but OM at least is doing a great job in comming near wrt missing transparency
Jun 22 18:00:12 <wpwrak> DocMobilizer: if you feel like making the world a better place, how about having a look at the lovely critters in http://svn.openmoko.org/trunk/gta02-core/docs/ecn/ ? you should recognize some of them :-)
Jun 22 18:01:38 <dos1|neo> mrmoku: i have recipe for opimd-utils
Jun 22 18:03:29 <DocScrutinizer> wpwrak: oh well - let's see. Though I still don't get how world will become a better place this way  -- especially for my possie ;-D
Jun 22 18:04:50 <wpwrak> DocScrutinizer: at least it's an opportunity to show the world how it could have been done right :) and who knows, maybe this turns into more than just a fetish project ...
Jun 22 18:05:10 <DocScrutinizer> k k
Jun 22 18:09:00 <budfive_> wpwrak: Hey, could you look at my proposed patch in https://docs.openmoko.org/trac/ticket/2277 (second to last comment on the bug)? It fixes the ifdown/ifup problem.
Jun 22 18:10:04 * [Rui] wavews
Jun 22 18:13:42 <dos1|neo> mrmoku: under which directory that recipe should be placed? freesmartphone?
Jun 22 18:16:37 <wpwrak> budfive_: doesn't look too bad. not sure if it's the root of this evil, but i looks like an improvement
Jun 22 18:16:42 <wpwrak> s/but i/but it/
Jun 22 18:16:44 <dos1|neo> mrmoku: that's pim.py and my messages GUI, but it depends on shr-settings (config)
Jun 22 18:17:29 <budfive_> wpwrak: do the current consumption numbers make sense?
Jun 22 18:18:16 <budfive_> if so, should the patch be integrated into the om kernel?
Jun 22 18:19:45 <wpwrak> budfive_: (current) i would have thought that the difference beween the module being up and it being unbound should be much larger
Jun 22 18:20:10 <wpwrak> budfive_: (fix) yeah. if it helps, in with it. if it's not good, it can always be reverted later :)
Jun 22 18:21:08 <budfive_> wpwrak: ok. Where should i send it to get it in? I don't have git access.
Jun 22 18:27:04 <mrmoku> dos1|neo, hmm... do you think it is something permanent? Why not do some shr-settings-playground subpackage? and install also wifiman.py?
Jun 22 18:27:27 <DocScrutinizer> wpwrak: please remove "Problem pointed out by Joerg Reisenweber <joerg@openmoko.org>" in http://svn.openmoko.org/trunk/gta02-core/docs/ecn/ecn0020.txt. It implies none of the other points were mentioned by me ;-)
Jun 22 18:31:25 <PaulFertser> budfive_: openmoko-kernel ML
Jun 22 18:31:48 <PaulFertser> budfive_: have you seen the latest lindi-'s comment?
Jun 22 18:32:23 <PaulFertser> budfive_: i think it adds one important datapoint. Because your numbers say there's still something wrong with the patch, i'm afraid.
Jun 22 18:33:00 <budfive_> haven't looked at lindi's comment yet
Jun 22 18:33:28 <budfive_> PaulFertser: re what's wrong: are you talking about the extra current consumption, or the other issues?
Jun 22 18:33:38 * PaulFertser wonders why the difference is so small between using and not using wifi.
Jun 22 18:33:49 <PaulFertser> budfive_: current consumption
Jun 22 18:34:29 <budfive_> PaulFertser: If my measurements are correct, I'd say the extra consumption is irrelevant. Do we have any reason to believe they're wrong?
Jun 22 18:34:56 <PaulFertser> budfive_: why do you think it's irrelevant?
Jun 22 18:35:23 <budfive_> PaulFertser: it's 4%
Jun 22 18:35:30 <PaulFertser> budfive_: also can't see how unbind after rmmod can make any difference.
Jun 22 18:35:48 <PaulFertser> budfive_: there's something fishy in here, i'm afraid.
Jun 22 18:36:17 <PaulFertser> budfive_: what if those 4mA will still be consumed in suspend? That's what worries me.
Jun 22 18:36:40 <budfive_> PaulFertser: Yeah, I will not claim to understand this well. To really do this right, much more time will need to be spent than what I put into it. In the meantime, it does seem to improve things dramatically.
Jun 22 18:38:12 <PaulFertser> budfive_: otoh non-working things motivate hackers to fix issues. Workarounds make issues hidden or not important and then we'll have kludges all over, i'm afraid... 
Jun 22 18:38:52 <dos1|neo> mrmoku: it's not shr-settings part. only opimd-config calls shr-settings PIM module (that's my laziness :P)
Jun 22 18:39:28 <PaulFertser> budfive_: also pay attention to the latest lindi-'s comment, the commit he mentions is already .28, that is it's using the new SDIO stack etc.
Jun 22 18:42:25 <dos1|neo> mrmoku: in the end i want to make it phonegui libriary - i like it ;)
Jun 22 18:43:10 <dos1|neo> so i think it's something pernament
Jun 22 18:43:38 <lindi-> PaulFertser: yes
Jun 22 18:43:47 <dos1|neo> especially opimd-cli, which is must have when developing opimd 
Jun 22 18:44:02 <dos1|neo> mrmoku: so where? ;)
Jun 22 18:44:24 <dos1|neo> mrmoku: and good thought about shr-settings-playground
Jun 22 18:44:30 <dos1|neo> mrmoku: i'll do it :)
Jun 22 18:45:32 <PaulFertser> lindi-: are you interested in improving FR stability? ;) Have you seen discussion about SD drive strength?
Jun 22 18:53:24 <wpwrak> DocMobilizer: ;-) credits are a tricky thing. in fact, i wouldn't mind if you claimed authorship of all those audio-related ecns :)
Jun 22 18:55:10 <mrmoku> dos1|neo, don't know then... is it in vala? :P
Jun 22 18:56:17 <mrmoku> dos1|neo, and what does it cover exactly?
Jun 22 18:57:07 <wpwrak> DocMobilizer: rehar is currently hacking and slashing at the audio part, over in #gta02-core
Jun 22 18:59:53 <dos1|neo> mrmoku: it's in python. and now it's cli for adding/editing/deleting/quering messages/contacts, and gui message app+daemon to recieve. also simple script for resolving contacts (but needs to be changed :P)
Jun 22 19:00:20 <dos1|neo> mrmoku: it's in python cause they are mostly test scripts
Jun 22 19:01:28 <Frank1> is there a way to configure the auto-suspend to false so even after restart the phone does not use auto-suspend?
Jun 22 19:02:13 <Blu3> frank1, shr?  set your shr power settings to 0 for suspend or idle/dim
Jun 22 19:02:36 <Frank1> yeah but after reboot it is on again
Jun 22 19:02:52 <Frank1> you mean in the settings dialog right?
Jun 22 19:03:36 <dos1|neo> Frank1: setting timeouts is persistent
Jun 22 19:04:05 <dos1|neo> shr-settings -> Power -> scroll down -> set proper timeouts to 0
Jun 22 19:04:49 <Frank1> okay will do so. thanks
Jun 22 19:06:43 <lindi-> PaulFertser: too busy, and wlan/muxer has priority as i have not hid sd issues
Jun 22 19:07:01 <PaulFertser> lindi-: ok
Jun 22 19:09:58 <PaulFertser> That's an interesting message from Steve Mosher on the ML. Looks like they're going to reverse-engineer existing hardware to make development boards of it. Did i intepret it right?
Jun 22 19:12:15 <mrmoku> dos1|neo, what about freesmartphone/opimd-tools.bb ?
Jun 22 19:13:39 <dos1|neo> mrmoku: i have opimd-utils now, but i can change ;)
Jun 22 19:13:49 <mrmoku> fine too :P
Jun 22 19:21:52 <dos1|neo> mrmoku: mail sent
Jun 22 19:23:20 <[Rui]> how does one close a window in Elementary? Not the main window, just another one...?
Jun 22 19:23:28 <wpwrak> PaulFertser: i'm kinda curious myself what they'll end up doing  :)
Jun 22 19:23:48 <Blu3> tap the very top of the screen then hit the large [x]
Jun 22 19:24:09 <PaulFertser> wpwrak: do you know of any commercial efforts like that (turning proprietary devices into devboards)?
Jun 22 19:24:09 <Blu3> i.e. tap on the name of the program
Jun 22 19:24:41 <dos1|neo> [Rui]: delete it
Jun 22 19:24:55 <[Rui]> dos1|neo: elm_delete(win) ?
Jun 22 19:25:09 <dos1|neo> elm_object_delete(win)? something like that
Jun 22 19:25:14 <[Rui]> I don't find elm_delet
Jun 22 19:25:25 <dos1|neo> in python it's win.delete()
Jun 22 19:25:37 <[Rui]> dos1|neo: neither anything for delete in Elementary.h
Jun 22 19:25:50 <[Rui]> anyone know if it merely is missing from libelm 0.3.0 ?
Jun 22 19:26:07 <dos1|neo> [Rui]: then evas_object_delete
Jun 22 19:26:08 <wpwrak> PaulFertser: hmm, nothing large comes to mind. but there are probably very small ones.
Jun 22 19:26:26 <dos1|neo> [Rui]: you could also elm_object_hide
Jun 22 19:27:43 <[Rui]> evas_object_delete doesn't exist either
Jun 22 19:28:26 <[Rui]> ah... it seems it's just del
Jun 22 19:28:49 <dos1|neo> ;D
Jun 22 19:28:52 <[Rui]> not that it did anything...
Jun 22 19:29:15 <[Rui]> well, time to help make dinner :)
Jun 22 19:29:16 <[Rui]> brb
Jun 22 19:29:58 <dos1|neo> mrmoku: could you also add it to feed? i knew that i forgot about something :x
Jun 22 19:33:47 <Frank1> hmm, possible to listen with mdbus to only one signal?
Jun 22 19:36:40 <dos1|neo> mrmoku: and please build frameworkd-config-shr :)
Jun 22 19:37:09 <McKael> Hmm, in shr-unstable, are we supposed to use libframeworkd-phonegui-efl0 or libframeworkd-phonegui-efl2?
Jun 22 19:37:49 <dos1|neo> McKael: unless you want really-uber-unstable, then 0
Jun 22 19:38:00 <McKael> dos1|neo: ok
Jun 22 19:38:16 <dos1|neo> McKael: 2 is for opimd and genlist integration
Jun 22 19:38:33 <McKael> I'm trying to see why USSD (service data) messages are not displayed correctly
Jun 22 19:38:51 <dos1|neo> McKael: hmm? what happens?
Jun 22 19:38:58 <dos1|neo> here they work
Jun 22 19:39:47 <McKael> There are no CR, everything is on the same line
Jun 22 19:40:23 <dos1|neo> oh, yep
Jun 22 19:40:50 <McKael> and sometimes it's unreadable as texts are superimposed
Jun 22 19:40:58 <dos1|neo> McKael: it should be easy to fix
Jun 22 19:41:14 <dos1|neo> McKael: just replace "\n" with "<br>"
Jun 22 19:41:38 <dos1|neo> McKael: or use some markup function (i think there are some)
Jun 22 19:41:52 <McKael> dos1|neo: that would be nice... but I'm still fighting to find out how that SHR stuff is supposed to work :)
Jun 22 19:42:02 <dos1|neo> McKael: when you finish, please send patch :)
Jun 22 19:42:33 <dos1|neo> if you want you can send it to me - seba.dos1 on gmail
Jun 22 19:42:39 <dos1|neo> i'll commit it
Jun 22 19:43:17 <DocScrutinizer> wpwrak: so what do you want me to do wrt ECN?
Jun 22 19:44:25 <McKael> dos1|neo: still trying to find where the source code is, TBH.
Jun 22 19:45:01 <wpwrak> DocMobilizer: maybe discuss the audio changes with rehar. he's working on the schematics right now. then someone can fill in the blanks. admittedly, the audio ecns consist largely of blanks :)
Jun 22 19:45:14 <wpwrak> DocMobilizer: also, if anything imporant is missing, please holler
Jun 22 19:46:32 <dos1|neo> McKael: git.shr-project.org
Jun 22 19:46:56 <dos1|neo> McKael: shr.git repository, libframeworkd-phonegui-efl folder
Jun 22 19:47:06 <McKael> dos1|neo: ok
Jun 22 19:47:10 <dos1|neo> McKael: then src/view IIRC
Jun 22 19:47:32 <McKael> is that "unstable"?
Jun 22 19:48:06 <dos1|neo> McKael: hmm? don't understand
Jun 22 19:48:27 <McKael> I mean, is it the source used to build daily "unstable" packages?
Jun 22 19:48:56 <dos1|neo> McKael: yes
Jun 22 19:50:34 <McKael> dos1|neo: ok, thanks, will have a look (probably not today)
Jun 22 19:51:00 <DocScrutinizer> wpwrak: how should I discuss with rehar. Don't know him
Jun 22 19:51:11 <McKael> dos1|neo: is shr.git big, if I want to clone it?
Jun 22 19:51:37 <DocScrutinizer> wpwrak: also I don't know abot actual changes
Jun 22 19:51:44 <dos1|neo> McKael: a bit, but not so big
Jun 22 19:52:58 <bumbl> dos1|neo: will efl gui 2 be a complete rewrite?
Jun 22 19:53:19 <dos1|neo> bumbl: ask mrmoku ;)
Jun 22 19:53:38 <dos1|neo> bumbl: i think it's going to be vala rewrite
Jun 22 19:53:42 <bumbl> ah ok
Jun 22 19:54:46 <McKael> shr.git is 8.8MB big :)
Jun 22 19:54:49 <wpwrak> DocMobilizer: rehar = Rene Harder, he hangs out on #gta02-core
Jun 22 19:55:38 <wpwrak> DocMobilizer: (changes) well, it should basically be the cleanups you had in mind. at least the ones that don't add a lot of new stuff
Jun 22 20:01:07 <dos1|neo> abraxa is in #gta02-core
Jun 22 20:01:21 <dos1|neo> ~seen abraxa
Jun 22 20:01:38 <bumbl> or #pyneo
Jun 22 20:01:44 * dos1|neo spanks bzzbot...
Jun 22 20:01:46 <dos1|neo> hey!
Jun 22 20:01:54 <dos1|neo> where is bzzbot?
Jun 22 20:03:28 <bumbl> spank mwester
Jun 22 20:03:44 <bumbl> who is not in either
Jun 22 20:06:01 <Frank1> is there a way to see which program is registered for a signal on dbus?
Jun 22 20:16:12 <dos1|neo> mrmoku: ping
Jun 22 20:18:44 <mrmoku> dos1|neo, pong
Jun 22 20:19:50 <dos1|neo> mrmoku: when efl2 segfaults?
Jun 22 20:19:56 <dos1|neo> mrmoku: on deleting?
Jun 22 20:20:07 <mrmoku> dos1|neo, right now I'm struggling with saving
Jun 22 20:20:20 <mrmoku> it saves just fine... and after that it segfaults :P
Jun 22 20:21:17 <dos1|neo> mrmoku: but it segfaults on deleting?
Jun 22 20:21:25 <mrmoku> ouch... it doubled my contact :(
Jun 22 20:21:29 <dos1|neo> mrmoku: i din strange thing in opimd ;p
Jun 22 20:21:48 <dos1|neo> s/din/did/
Jun 22 20:22:11 <mrmoku> yeah, deleting segfaults too
Jun 22 20:22:33 <dos1|neo> mrmoku: but every time, or sometimes?
Jun 22 20:22:40 <dos1|neo> mrmoku: after removing some item, path for others is updated
Jun 22 20:23:17 <mrmoku> dos1|neo, you mean... paths change?
Jun 22 20:23:20 <dos1|neo> mrmoku: i noticed that it's bad when i had problems with deleting in my ui ;x
Jun 22 20:23:28 <dos1|neo> mrmoku: yep, on deleting
Jun 22 20:23:35 <mrmoku> dos1|neo, bad thing ;)
Jun 22 20:23:37 <dos1|neo> mrmoku: i'll change that
Jun 22 20:25:15 <dos1|neo> mrmoku: maybe that's why it segfaults ;x
Jun 22 20:25:32 <mrmoku> dos1|neo, that would explain why I can't find that damn segfault ;)
Jun 22 20:25:55 <dos1|neo> mrmoku: hehe ;D
Jun 22 20:32:50 <mrmoku> dos1|neo, btw. I won't switch to libfso-glib, because it does not support async calls (yet)
Jun 22 20:35:55 <mrmoku> dos1|neo, so... you say opimd messages are ready to be implemented?
Jun 22 20:36:17 <dos1|neo> mrmoku: basics - yes
Jun 22 20:36:32 <mrmoku> dos1|neo, basics means it can replace SIM messages?
Jun 22 20:36:48 <dos1|neo> mrmoku: yes
Jun 22 20:37:15 <dos1|neo> mrmoku: now really basics, but in few days i should have everything needed by phonegui-efl gui
Jun 22 20:37:40 <mrmoku> dos1|neo, will start to implement something then
Jun 22 20:37:43 <dos1|neo> now timestamp handling and (read/unread)/(sent/unsent) handling
Jun 22 20:37:55 <dos1|neo> but data from sim is readable
Jun 22 20:38:10 <dos1|neo> _sim_timestamp field for instance
Jun 22 20:38:17 <mrmoku> what about folders?
Jun 22 20:38:29 <dos1|neo> mrmoku: dunno how they work
Jun 22 20:38:37 <dos1|neo> mrmoku: but something is there
Jun 22 20:38:46 <dos1|neo> mrmoku: i will look at it later
Jun 22 20:38:50 <mrmoku> k
Jun 22 20:39:21 <mrmoku> but one queries messages of one folder, right?
Jun 22 20:40:18 <dos1|neo> mrmoku: there is Folder field
Jun 22 20:40:50 <dos1|neo> Query({'Folder':'My folder'}) should work
Jun 22 20:41:05 <dos1|neo> there is also Direction field
Jun 22 20:41:20 <dos1|neo> with 'in' or 'out' value
Jun 22 20:41:55 <dos1|neo> mrmoku: and it doesn't touch messages when SIM backend is selected as default
Jun 22 20:42:35 <dos1|neo> mrmoku: if other is selected, it disables SimBuffersSms, and then stores messages in that backend
Jun 22 20:43:02 <dos1|neo> but then ophonekitd doesn't even know there are new messages
Jun 22 20:44:16 <dos1|neo> that's why i wrote opimd-utils - it has daemon to display incoming messages via opimd signal
Jun 22 20:44:29 <dos1|neo> i have also patched oeventsd
Jun 22 20:44:41 <dos1|neo> to listen to opimd signal, not ogsmd
Jun 22 20:45:00 <dos1|neo> it works even when SIM backend is selected
Jun 22 20:45:24 <mrmoku> hmm... buildhost has DNS problems :(
Jun 22 22:22:11 <Zork|Gone> Ainulindale: when opkg upgrading I get http://pastebin.com/m27887cb9  (just to let you know) i'll wait a bit with upgrading
Jun 22 22:35:27 <[Rui]> hms... elm_label isn't multi-line/wrappable ?
Jun 22 22:41:32 <[Rui]> lol uneditable entries are editable via cut/paste :)
Jun 22 22:44:00 <TAsn> ffs real life is killing my real life.
Jun 22 22:44:01 <TAsn> night.
Jun 22 22:44:06 <TAsn> :)
Jun 22 22:49:07 <[Rui]> TAsn: night
Jun 23 01:27:26 <Blu3> hmm
Jun 23 01:27:56 <Blu3> frameworkd-dbg seems to have a memleak, it's constantly growing in size
**** ENDING LOGGING AT Tue Jun 23 02:59:57 2009