**** BEGIN LOGGING AT Fri Dec 10 02:59:57 2010
Dec 10 07:07:02 <JaMa|Off> mrmoku`: angstrom toolchain worked ok for u-boot
Dec 10 07:08:35 <mrmoku`> JaMa|Off: ok
Dec 10 07:57:10 <DocScrutinizer> moaning
Dec 10 08:06:03 <mrmoku> DocScrutinizer: :P
Dec 10 08:06:39 <mrmoku> DocScrutinizer: what is your take on the dangernous of n900 overclocking?
Dec 10 08:06:50 <mrmoku> how easily can it cause damages?
Dec 10 08:08:10 <mrmoku> s/dangernous/dangerousness/
Dec 10 08:09:16 <DocScrutinizer> ~omap-oc
Dec 10 08:09:16 <apt> i heard omap-oc is http://mg.pov.lt/maemo-irclog/%23maemo.2010-08-01.log.html#t2010-08-01T22:16:05  read that!
Dec 10 08:09:41 <DocScrutinizer> TI says it will eat your SoC
Dec 10 08:10:04 <mrmoku> ahh... good to know :-)
Dec 10 08:11:36 <mrmoku> DocScrutinizer: ok... that bad... we will remove the overclocking patches from our kernel then
Dec 10 08:20:19 <PaulFertser> mrmoku: remove patches that many people find mad useful?
Dec 10 08:21:06 <mrmoku> PaulFertser: well if it eats SoCs those people finding the patches usefull are the first ones to complain ;)
Dec 10 08:21:37 <PaulFertser> mrmoku: there doesn't seem to be many of them
Dec 10 08:21:39 <JaMa|Off> mrmoku: can you test u-boot binary for me? (angstrom gcc + our binutils)
Dec 10 08:21:57 <JaMa|Wrk> mrmoku: I cannot flash combined.bin from here :/
Dec 10 08:22:01 <mrmoku> JaMa|Wrk: link?
Dec 10 08:23:38 <PaulFertser> DocScrutinizer: it would be interesting to know how exactly the SoC gots damaged because of OC.
Dec 10 08:23:53 <JaMa|Wrk> mrmoku: http://build.shr-project.org/tests/jama/u-boot/u-boot.bin.shr.ang.binutils.toolchain
Dec 10 08:24:08 <mrmoku> PaulFertser: you mean there are not many that complained for a broken SoC or not many that find it usefull?
Dec 10 08:24:13 <JaMa|Wrk> mrmoku: booting maemo should be enought for test
Dec 10 08:24:29 <mrmoku> JaMa|Wrk: ok
Dec 10 08:25:31 <PaulFertser> mrmoku: i mean i haven't seen many people with dead SoC but Doc should certainly know better, i guess he stil reads tmo.
Dec 10 08:26:39 <DocScrutinizer> no, actually I don't
Dec 10 08:26:44 <[Rui]> JaMa|Wrk: hi, no I didn't view any mail about that, but I'll upgrade to check
Dec 10 08:27:59 <DocScrutinizer> but there are clear numbers for expected lifespan of SoC until failure, for certain cpu-clock. TI did good tests to get those numbers, as they are part of their product specs they are liambe are correct
Dec 10 08:28:00 <mrmoku> JaMa|Wrk: works
Dec 10 08:31:15 <DocScrutinizer> And Nokia has set the limits to 500MHz 100% of time, and 600MHz for short sprints, to guarantee a device lifespan of maybe 5 to 10 years. Going to 600MHz 100% and maybe even higher will *significantly* reduce lifespan, due to electromigration kicking off exponentially starting @ 500
Dec 10 08:32:05 <DocScrutinizer> significantly here means factors of 2, 5, 10... depending on how much you OC the SoC
Dec 10 08:32:12 <JaMa|Wrk> mrmoku: ok.. upgrading gcc now :)
Dec 10 08:32:59 <DocScrutinizer> I'd bet @1GHz the lifespan is reduced to maybe 1/10
Dec 10 08:34:10 <lindi-> is there anything I can do to a stuck blue pixel on my fr screen? :)
Dec 10 08:34:20 <DocScrutinizer> nope
Dec 10 08:34:29 <lindi-> appeared yesterday
Dec 10 08:34:37 <DocScrutinizer> seen your comment
Dec 10 08:34:40 <DocScrutinizer> :-/
Dec 10 08:35:05 <lindi-> ok, maybe I'll just hope more won't appear
Dec 10 08:35:14 <JaMa|Wrk> someone offered display replacement, but not sure it's worth it :/
Dec 10 08:35:18 <DocScrutinizer> if it gets worse, ping me
Dec 10 08:35:30 <lindi-> JaMa|Wrk: surely not for a single pixel
Dec 10 08:36:13 <DocScrutinizer> lindi-: ^^^
Dec 10 08:36:47 <DocScrutinizer> I got a few screens, and you for sure qualified for a free replacement
Dec 10 08:38:41 <CIA-107> freesmartphone.org: 03morphis 07utilities * r2d1fa4ae24a3 10/palmpre/fso-installer/Makefile: palmpre: fso-installer: add initial version of the Makefile
Dec 10 08:53:49 <DocScrutinizer> (cpu lifespan) compare to an incandescent lamp. 1000h@230V. Do you think @460V is will survivie 500h?
Dec 10 08:55:00 <DocScrutinizer> there's a certain level (of voltage, freq, current, whatever) above which massive effects start to kick in
Dec 10 08:55:40 <DocScrutinizer> usually components are designed in a way so they have an average lifespan of X at rated operating conditions
Dec 10 08:56:30 <DocScrutinizer> you *can* go beyond what's the device is rated for, but usually people have a clear idea of what that will result in
Dec 10 08:56:46 <DocScrutinizer> just for CPUs they think it's different... WHY?
Dec 10 09:01:29 <DocScrutinizer> there are idiots claiming "I'm clocking the N900 @ 1.2GHz and it's just working fine for me" -WTH!? run a CPU @ 240% rated max continuous clock, and think that won't have any severe adverse effects??
Dec 10 09:02:17 <GNUtoo|laptop> DocScrutinizer, hi, I clocked my cpu to 1.2GHz by error
Dec 10 09:02:30 <GNUtoo|laptop> basically someone switched to power kernel
Dec 10 09:02:39 <GNUtoo|laptop> and I didn't saw it was going until 1.2GHz
Dec 10 09:02:46 <GNUtoo|laptop> then I used ondemand...
Dec 10 09:02:52 <DocScrutinizer> so you bitten out 30% of its lifespan during hours
Dec 10 09:03:02 <GNUtoo|laptop> not during hours
Dec 10 09:03:07 <GNUtoo|laptop> because it's ondemand
Dec 10 09:03:15 <GNUtoo|laptop> so I don't really know how much
Dec 10 09:04:28 <DocScrutinizer> yeah, depends if you got a runaway process forcing the cpufreq-governor to run it at max speed all the time
Dec 10 09:05:16 <DocScrutinizer> if it sat idle on your desk for weeks with 1.2GHz only theoretically enabled, then nothing bad will have happened
Dec 10 09:05:31 <GNUtoo|laptop> ok
Dec 10 09:05:52 <GNUtoo|laptop> I don't know the exact implications of overclocking
Dec 10 09:05:58 <GNUtoo|laptop> on the long time
Dec 10 09:06:19 <GNUtoo|laptop> the most short-time one is increasing heat
Dec 10 09:06:37 <[Rui]> DocScrutinizer: it may work for sometime, but the overheating alone for some continuously long time may indeed have adverse effects :)
Dec 10 09:07:14 <GNUtoo|laptop> which can be really problematic if you have the nokia900 in some closed place
Dec 10 09:07:16 <JaMa|Wrk> mrmoku: can you please test another? gcc-4.4.4 this time and it's smaller as with gcc-4.5 http://build.shr-project.org/tests/jama/u-boot/u-boot.bin.shr.ang.binutils.gcc.toolchain
Dec 10 09:07:42 <DocScrutinizer> yeah, and heat * current-density (Amperes / cross section) ^ 3 == electromigration
Dec 10 09:08:02 <GNUtoo|laptop> ok
Dec 10 09:08:03 <[Rui]> hehe
Dec 10 09:08:06 <[Rui]> well, bbye!
Dec 10 09:08:06 <DocScrutinizer> (this formula outa my ass, but not completely made up)
Dec 10 09:09:19 <GNUtoo|laptop> so, mrmoku did you push a new fsodeviced config for nokia900 for the ondemand stuff?
Dec 10 09:12:54 <DocScrutinizer> in fact the temperature creates a Gauss curve of molecule vibration, and electron energy (proportional to electrons / (mm^2 * s) ) will set the threshold on this curve, for the metal atoms that get hit out of crystal lattice
Dec 10 09:14:20 <DocScrutinizer> see wikipedia -> electromigration for details
Dec 10 09:16:32 <DocScrutinizer> just as a sidenote: in modern microelectronics chips - like SoC - you easily find current density peaks of 100s of kA/mm^2
Dec 10 09:20:35 <GNUtoo|laptop> I know a bit what electromigration is, and it can be bad
Dec 10 09:21:03 <GNUtoo|laptop> basically it's some electrons going out of the traced circuit
Dec 10 09:21:07 <GNUtoo|laptop> or something like that
Dec 10 09:22:31 <GNUtoo|laptop> I must go bye
Dec 10 09:27:53 <CIA-107> freesmartphone.org: 03morphis 07msmcomm * r9fcb60e8a7cf 10/ (21 files in 2 dirs): msmcommd and libmsmcomm: reorganize namespaces into Msmcomm.Daemon and Msmcomm.LowLevel
Dec 10 09:37:07 <mrmoku> JaMa|Wrk: boots too
Dec 10 09:37:30 <JaMa|Wrk> mrmoku: thanks again.. going for vanilla gcc-4.5 now
Dec 10 09:37:35 <mrmoku> ok
Dec 10 09:42:59 <DocScrutinizer> electromigration basically is to metal atoms in wires and electrons in a integrated circuit, what is erosion to sand and water in a river. It moves material (sand, metal) down the direction of flow (of water, electrons)
Dec 10 09:52:15 <mrmoku> DocScrutinizer: does that explain the feeling that computers get slower over time?
Dec 10 09:52:25 <DocScrutinizer> no
Dec 10 09:52:33 <mrmoku> ok :)
Dec 10 09:53:37 <DocScrutinizer> it also doesn't explain why people think they are able to tell apart performance of a system clocked @ 600MHz from one clocked @800MHz
Dec 10 09:54:24 <DocScrutinizer> usually you say speed increasing measures are futile unless you gain a factor 2 at least
Dec 10 09:55:24 <DocScrutinizer> except for timing critical go/nogo cases, like video playback, where 1% can make the difference between dropping frames and smooth playback
Dec 10 11:23:57 <mrmoku> mickey|office: to force unload of a plugin, when for example cpufreq is not available... I have to do that in the factory function? Or is it possible in the constructor too? probably not...
Dec 10 11:39:11 <mickey|office> mrmoku: the canonical way is to just not register any dbus objects if your plugin can't operate
Dec 10 11:39:21 <mickey|office> right now plugins can't really be unloaded completely
Dec 10 11:39:25 <mrmoku> mickey|office: for now there is no dbus involved
Dec 10 11:39:43 <mickey|office> mrmoku: i see. in that case, don't register any idle sources or timeouts or what not
Dec 10 11:39:49 <mickey|office> just don't do anything 
Dec 10 11:39:55 <mrmoku> ok :)
Dec 10 11:40:08 <mickey|office> i will add 'can't init, please remove me as much as possible' later
Dec 10 11:40:46 <mrmoku> though the comments indicate that if the factory function returns something different than for example 'fsodevice.kernel26_cpufreq' the module will get unloaded immediately
Dec 10 11:42:02 <mickey|office> yes, this has been in preparation
Dec 10 11:42:07 <mickey|office> i just didn't complete that part :)
Dec 10 11:42:29 <mickey|office> bottom line is also a gobject problem
Dec 10 11:42:35 <mickey|office> since it's not really possible to unload types
Dec 10 11:42:47 <mrmoku> ahh ok :-)
Dec 10 11:42:53 <mrmoku> thanks for clarifying
Dec 10 11:43:49 <mrmoku> I might be better of then to go the 'prepared' way and check if cpufreq is available in the factory function
Dec 10 11:44:07 <mrmoku> so if someday that part works....
Dec 10 11:44:27 <mickey|office> correct
Dec 10 11:44:33 <mickey|office> it will automagically start working then
Dec 10 11:44:44 <mrmoku> good, will correct that part then
Dec 10 11:44:59 <mrmoku> mickey|office: another question would be if it makes sense to have on instance per cpu
Dec 10 11:45:14 <mrmoku> right now all cpus are handled equally
Dec 10 11:45:26 <mrmoku> not that we have more than one right now ;)
Dec 10 11:51:13 <mrmoku> hmm... no... will leave that for later :)
Dec 10 11:56:31 <mickey|office> hehe
Dec 10 11:57:02 <mickey|office> yes, can think about individual and an aggregate (that holds the whole picture) eventually
Dec 10 11:58:52 <mrmoku> yup
Dec 10 12:17:04 <mrmoku> GNUtoo|laptop: yep, pushed a config
Dec 10 12:25:21 <playya> mickey|office, IIRC: vala uses g_type_register_dynamic for modules, so it should be possible to unregister types
Dec 10 12:45:38 <mrmoku> JaMa|Wrk: next u-boot to test in sight?
Dec 10 12:48:53 <JaMa|Wrk> mrmoku: almost
Dec 10 12:50:20 <mrmoku> ok, will wait then before flashing something else :-)
Dec 10 12:50:48 <JaMa|Wrk> mrmoku: still building gcc-cross (without linaro patches), because I've upgraded armv[457] gcc to OE HEAD in normal tmpdir..
Dec 10 12:51:51 <JaMa|Wrk> so about 10 mins
Dec 10 12:55:26 <mrmoku> JaMa|Wrk: ok
Dec 10 13:11:33 <JaMa|Wrk> mrmoku: http://build.shr-project.org/tests/jama/u-boot/u-boot.bin.shr.ang.binutils.gcc-4.5v.toolchain
Dec 10 13:14:32 <JaMa|Wrk> 4 more kB are gone, only 1kB bigger then failing u-boot from SHR toolchain
Dec 10 13:18:43 * mrmoku flashes
Dec 10 13:20:22 <mrmoku> JaMa|Wrk: bingo... hangs at starting kernel
Dec 10 13:27:17 <mrmoku> JaMa|Wrk: http://old.nabble.com/-U-Boot---PATCH--armv7:-fix-linker-file-for-newer-ld-support-td30110827.html
Dec 10 13:57:48 <JaMa|Wrk> mrmoku: wow I was trying to find some report in the morning but havent found this one
Dec 10 14:02:22 <mrmoku> JaMa|Wrk: u-boot gcc-4.5 have been the google terms :P
Dec 10 14:02:33 <mrmoku> anyway... have to go now... xmas party at one sons school
Dec 10 14:02:42 <mrmoku> after that xmas party at the other sons sports cleb
Dec 10 14:02:49 <mrmoku> s/cleb/club/
Dec 10 14:02:50 <apt> mrmoku meant: after that xmas party at the other sons sports club
Dec 10 14:03:02 <mrmoku> maybe I can test another u-boot in between... if you have one :)
Dec 10 14:03:04 <mrmoku> bbl
Dec 10 15:04:08 <JaMa|Wrk> mrmoku: sorry I had to discuss something with boss.. so no new u-boot and now looking on that patch it does not apply at all to our sources and seems like build error not runtime .. :/
Dec 10 15:32:24 <mrmoku> JaMa|Wrk: hmm :/
Dec 10 15:38:32 <mrmoku> JaMa|Wrk: somehow I have the feeling current master would work
Dec 10 15:38:44 <mrmoku> maybe we should look into porting the patches
Dec 10 15:38:50 <mrmoku> (and try to get them upstream too)
Dec 10 15:42:47 <JaMa|Wrk> mrmoku: still not on xmas party? :)
Dec 10 15:43:00 <JaMa|Wrk> mrmoku: than I'll throw you another binary..
Dec 10 15:43:03 <mrmoku> JaMa|Wrk: already back from the first one :-)
Dec 10 15:43:09 <mrmoku> yeah
Dec 10 15:43:33 <JaMa|Wrk> but no big hope.. I just removed all remaining OE patches (not only linaro)
Dec 10 15:43:42 <mrmoku> ok
Dec 10 15:44:05 <mrmoku> good thing if we know it's not OE-gcc specific
Dec 10 15:44:48 <JaMa|Wrk> http://build.shr-project.org/tests/jama/u-boot/u-boot.bin.shr.ang.binutils.gcc-4.5vv.toolchain
Dec 10 15:45:47 <JaMa|Wrk> HeinervdmOff: shr-t build has completely broken SRCPV versioning.. not sure why but all packages started with 0, fso after upgrade has 1, but persistent db has right number, it's just ignored somehow :/
Dec 10 15:46:30 <JaMa|Wrk> HeinervdmOff: or even better.. I'm stupid, my fault, will fix now
Dec 10 15:46:56 <JaMa|Wrk> shr@opmbuild:~/shr-testing/tmp$ mv cache/ cache-bad
Dec 10 15:46:56 <JaMa|Wrk> shr@opmbuild:~/shr-testing/tmp$ mv ../cache/ .
Dec 10 15:47:23 <mrmoku> JaMa|Wrk: hmm... this one hangs even earlier
Dec 10 15:47:42 <mrmoku> Booting maemo from eMMC.... is the last thing it says
Dec 10 15:48:04 <JaMa|Wrk> bad, so we need some OE patches in the end :/
Dec 10 15:48:24 <JaMa|Wrk> mrmoku: so I'll try to rebase those patches on something newer
Dec 10 15:48:34 <mrmoku> JaMa|Wrk: good :)
Dec 10 16:43:15 <mrmoku> JaMa|Wrk: off for the next one... bbl
Dec 10 16:45:01 <JaMa|Wrk> mrmoku: I'm going to dance school so no more u-boots for today :)
Dec 10 17:15:03 <alexxy> JaMa|Off: can you rebuild ffphonelog?
Dec 10 17:15:17 <alexxy> seems its broken after latest update
Dec 10 17:18:04 <JaMa|Off> y, but it will take a while.. buildhost is building gcc now and I'm leaving
Dec 10 17:21:29 <JaMa|Off> PR bumped so I won't forget, thanks for noticing alexxy 
Dec 10 17:23:48 <alexxy> ahh 
Dec 10 17:23:49 <alexxy> ok
Dec 10 18:55:47 <PaulFertser> mickeyl: i changed the timeout to 5 several days ago but still can't provide any results because there's some more severe instability now forcing me to reboot by cutting the power, not sure why or how, i didn't change anything. 
Dec 10 19:12:15 <mrmoku> PaulFertser: did you see lindi's GPRS stability thing?
Dec 10 19:12:53 <PaulFertser> mrmoku: the throttling trick?
Dec 10 19:13:03 <PaulFertser> mrmoku: my problems are not related to GPRS anyway?
Dec 10 19:13:55 <lindi-> PaulFertser: what sort of instability?
Dec 10 19:23:34 <mrmoku> PaulFertser: yeah, the throttling
Dec 10 19:25:38 <mrmoku> PaulFertser: did not want to say it might be related... interesting though
Dec 10 19:25:42 <mrmoku> ~lart calypso
Dec 10 19:25:42 * apt gives calypso a good seeing to
Dec 10 19:28:59 <PaulFertser> lindi-: no idea, i once/twice couldn't resume (and no jtag, and no ramconsole, sorry) and once it got "stuck" with the screen turned off and orange led on.
Dec 10 19:31:56 <lindi-> PaulFertser: if led is on then you have a different bug :)
Dec 10 19:32:53 <gena2x> bugs bugs bugs...
Dec 10 19:33:16 * gena2x finally restored sd card
Dec 10 19:33:36 <gena2x> debsums nice tool
Dec 10 19:37:41 <lindi-> gena2x: agree
Dec 10 19:37:42 <lindi-> +d
Dec 10 19:40:32 <PaulFertser> lindi-: indeed
Dec 10 19:40:38 <PaulFertser> lindi-: that's why i mentioned it.
Dec 10 19:44:35 <gena2x> with particular debugging kernel log options here, it can resume only once
Dec 10 19:44:44 <gena2x> better to say without
Dec 10 19:45:16 <gena2x> without other option, sound driver oopses on suspend
Dec 10 19:46:49 <gena2x> ^^^ ready pointers to find Bugs
Dec 10 19:53:54 <lindi-> I think I found a bug in ip_output.c today
Dec 10 19:54:33 <lindi-> no idea whom to ask except by sending email to lkml
Dec 10 19:56:08 <gena2x> oh, i can believe in bugs in arm or even-specific code and more probably in fr-specific code
Dec 10 19:56:54 <gena2x> but in IP protocol implementation?
Dec 10 19:57:59 <gena2x> s/ bugs in arm or even-specific/ bugs in arm-specific/
Dec 10 19:59:24 <lindi-> gena2x: this is not arm specific
Dec 10 19:59:34 <lindi-> gena2x: in mainline on amd64 :)
Dec 10 20:00:16 <gena2x> lindi-: ah, 64-bit specific? probability meter increased :)
Dec 10 20:01:04 * gena2x reading sd card specification to attempt to hack glamo sd speed
Dec 10 20:01:45 <lindi-> gena2x: I think it's on all architectures
Dec 10 20:08:08 <GNUtoo> too bad...JaMa is off
Dec 10 20:09:08 <mrmoku> GNUtoo: he's going to try to port the n900 patches to current u-boot
Dec 10 20:11:58 <GNUtoo> ok
Dec 10 20:12:20 <GNUtoo> did he look at the oe iphone3g patches?
Dec 10 20:13:14 <mrmoku> dunno
Dec 10 20:14:41 <gena2x> ~seen gena2x
Dec 10 20:14:47 <apt> gena2x is currently on #openmoko (27m 3s) #openmoko-cdevel (27m 3s). Has said a total of 11 messages. Is idling for 5s, last said: '~seen gena2x'.
Dec 10 20:14:51 <gena2x> ~ThibG
Dec 10 20:14:57 <gena2x> ~seen ThibG
Dec 10 20:14:58 <apt> thibg <~ThibG@81-64-13-28.rev.numericable.fr> was last seen on IRC in channel #openmoko, 89d 7h 16m 47s ago, saying: 'my FR is booting!'.
Dec 10 20:15:06 <mrmoku> GNUtoo: btw. I had the wandering wlan symptom again the other day
Dec 10 20:15:12 <mrmoku> GNUtoo: and digged into it
Dec 10 20:15:35 <mrmoku> it's the udev persistent netif name functionality causing it
Dec 10 20:16:31 <GNUtoo> ok
Dec 10 20:16:38 <mrmoku> solution is easy and probably obsoletes the nokia hack
Dec 10 20:16:50 <GNUtoo> ah?
Dec 10 20:17:08 <mrmoku> moment
Dec 10 20:17:15 <GNUtoo> what's the solution?
Dec 10 20:17:17 <GNUtoo> ok
Dec 10 20:17:59 <mrmoku> GNUtoo: this file is autogenerated: 70-persistent-net.rules
Dec 10 20:18:26 <mrmoku> and tries to keep interface names the same for one mac
Dec 10 20:18:28 <GNUtoo> yes I know
Dec 10 20:18:37 <mrmoku> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:df:*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
Dec 10 20:18:43 <GNUtoo> but I don't know how tough
Dec 10 20:18:46 <mrmoku> using a wildcard for the mac works fine :-)
Dec 10 20:19:01 <GNUtoo> i know that too
Dec 10 20:19:07 <mrmoku> /lib/udev/rules.d/75-persistent-net-generator.rules
Dec 10 20:19:16 <mrmoku> is calling the following script
Dec 10 20:19:24 <GNUtoo> i even documented the wildcard hack on the wiki
Dec 10 20:19:29 <GNUtoo> ah ok
Dec 10 20:19:30 <mrmoku> /lib/udev/write_net_rules
Dec 10 20:19:47 <GNUtoo> i'll look when fsck will finish
Dec 10 20:19:57 <mrmoku> we can just add a 70-persistent-net.rules with that wildcarded rule to the image
Dec 10 20:20:16 <GNUtoo> yes good idea
Dec 10 20:20:30 <GNUtoo> the downside is random ip tough
Dec 10 20:20:40 <GNUtoo> because of random mac
Dec 10 20:20:43 <mrmoku> ahh, ok
Dec 10 20:20:47 <GNUtoo> can be good or bad
Dec 10 20:20:54 <mrmoku> then we can keep the nokia rule in addition
Dec 10 20:21:14 <mrmoku> worked fine for me for a bunch of reboots now
Dec 10 20:21:32 <GNUtoo> good is when you get 10 min of free airport wifi based on mac address
Dec 10 20:21:57 <mrmoku> though I moved it to 00-udev-rules-nokia.... 
Dec 10 20:21:59 <GNUtoo> just reboot and you have another 10 min...in theory
Dec 10 20:22:02 <mrmoku> hehe
Dec 10 20:22:09 <mrmoku> nice :P
Dec 10 20:22:18 <mrmoku> we could make it configurable ;)
Dec 10 20:22:33 <GNUtoo> i never tried tough(midori crash)
Dec 10 20:23:02 <GNUtoo> just make it static then
Dec 10 20:23:14 <mrmoku> ok
Dec 10 20:23:24 <GNUtoo> and let the experienced people modify it if they whish
Dec 10 20:23:25 <mrmoku> btw. I didn't find the TODO the other day
Dec 10 20:23:31 <GNUtoo> ah?
Dec 10 20:23:40 <mrmoku> I thought it is on our wiki?
Dec 10 20:23:49 <GNUtoo> hardware comparison on fso wiki
Dec 10 20:24:00 <GNUtoo> links to it
Dec 10 20:24:12 <GNUtoo> so it's in fso wiki
Dec 10 20:24:12 <mrmoku> ahh ok
Dec 10 20:24:37 <mrmoku> hmm
Dec 10 20:24:48 <mrmoku> that's just three points... it was more IIRC
Dec 10 20:24:50 <GNUtoo> let me connect a bt mouse and keyboard
Dec 10 20:25:31 <mrmoku> twl4030 support
Dec 10 20:25:41 <GNUtoo> ah?
Dec 10 20:25:57 <GNUtoo> emtooth has libs issue here
Dec 10 20:26:10 <GNUtoo> so no bt kbd
Dec 10 20:26:48 <mrmoku> the last point is twl4030 support in fsodeviced
Dec 10 20:27:05 <GNUtoo> what's in this pm chip?
Dec 10 20:27:18 <GNUtoo> there is also bt inclusion in todo
Dec 10 20:28:06 <GNUtoo> battery too
Dec 10 20:28:24 <GNUtoo> keyboard light pr bump
Dec 10 20:28:29 <mrmoku> GNUtoo: ahh, ok found the *real* TODO :)
Dec 10 20:28:37 <GNUtoo> lol ok
Dec 10 20:28:40 <mrmoku> http://wiki.freesmartphone.org/index.php/Hardware/N900/TODO
Dec 10 20:28:46 <GNUtoo> yes
Dec 10 20:29:01 <mrmoku> there is a bit of todo here too
Dec 10 20:29:02 <mrmoku> http://wiki.freesmartphone.org/index.php/Hardware/N900
Dec 10 20:29:10 <mrmoku> with just three points
Dec 10 20:29:12 <GNUtoo> indeed
Dec 10 20:29:14 <mrmoku> confused me :)
Dec 10 20:29:38 <GNUtoo> bb on laptop soon
Dec 10 20:30:00 <GNUtoo> i'm still there in the meantime
Dec 10 20:31:31 <mrmoku> GNUtoo: will remove the ondemand thing as it's fixed :-)
Dec 10 20:31:46 <GNUtoo> ok
Dec 10 20:42:08 <GNUtoo|laptop> hi mickeyl 
Dec 10 21:28:50 <GNUtoo|laptop> mrmoku, ah stefan reviewed the oe patches
Dec 10 21:29:03 <GNUtoo|laptop> I'll look at it tommorow
**** ENDING LOGGING AT Sat Dec 11 02:59:57 2010