| 00:15.25 | *** part/#gpe tigrux (~tigrux@dsl-200-67-236-216.prod-empresarial.com.mx) |
| 00:24.43 | *** join/#gpe FortMax (~aperez@pool-70-111-202-159.nwrk.east.verizon.net) |
| 00:48.25 | *** join/#gpe FortMa1 (~aperez@pool-70-111-202-159.nwrk.east.verizon.net) |
| 01:28.55 | *** join/#gpe franktom (~frank@221.218.108.21) |
| 01:56.27 | *** join/#gpe Timelord (~TL@4.78.4.43) |
| 01:58.20 | *** join/#gpe FortMa1 (~aperez@pool-70-111-202-159.nwrk.east.verizon.net) |
| 02:29.03 | *** join/#gpe aquadran_ (pablo@aquadran.undead.scummvm) |
| 02:52.23 | *** join/#gpe swbrown (~chatzilla@cpe-66-75-245-228.san.res.rr.com) |
| 02:52.37 | swbrown | Where do the 'Online Screenshot's actually go? |
| 03:12.46 | swbrown | After some poking around, found that scap does it and at the commandline, gives you a URL. Got my app ported over: http://wiisard.org/~swbrown/new_html/midtier-on-gpe.png (it's still in development). It's for mass casualty disaster response. |
| 03:13.04 | swbrown | GPE rocks. :) |
| 06:01.43 | *** join/#gpe t-jramir (~t-jramir@c-24-16-143-220.hsd1.wa.comcast.net) |
| 06:33.34 | *** join/#gpe darmou (~darmou@CPE-61-9-146-174.vic.bigpond.net.au) |
| 07:02.29 | *** join/#gpe jumar (~jmh@80.83.52.2) |
| 07:04.37 | *** join/#gpe JiniDog (~jini@p54BFBCC4.dip.t-dialin.net) |
| 07:09.45 | *** join/#gpe __law__ (~law@mail.stiftadmont.at) |
| 08:03.04 | *** join/#gpe ade|desk (~adavey@194.200.143.249) |
| 08:10.52 | ade|desk | morning all |
| 08:34.58 | *** join/#gpe pb_ (~pb@2002:5246:d929:1:20a:5eff:fe00:391e) |
| 08:51.56 | *** part/#gpe jumar (~jmh@80.83.52.2) |
| 09:07.39 | *** join/#gpe priest_ux (~ildar@82.200.129.202.adsl.online.kz) |
| 09:08.54 | *** join/#gpe pH5 (~ph5@e178214157.adsl.alicedsl.de) |
| 09:15.14 | *** join/#gpe ignatoff (~IG@dexter.ee.ukzn.ac.za) |
| 09:20.25 | *** join/#gpe jg (~jg@c-24-63-93-208.hsd1.ma.comcast.net) [NETSPLIT VICTIM] |
| 09:24.06 | *** join/#gpe jsmanrique (~jsmanriqu@reutiliza6.energia.uniovi.es) |
| 09:35.14 | *** join/#gpe eJumbo (~eJumbo@203.196.146.243) |
| 09:45.09 | *** join/#gpe jsmanrique (~jsmanriqu@reutiliza7.energia.uniovi.es) |
| 10:00.11 | *** join/#gpe NoFo (~NoFo@p54A2D705.dip.t-dialin.net) |
| 10:00.24 | NoFo | hi |
| 10:11.51 | jsmanrique | NoFo: hi |
| 10:16.25 | *** join/#gpe bedboi ([U2FsdGVkX@signserv.Signal.Uu.Se) |
| 10:16.34 | bedboi | hi there |
| 10:18.42 | *** join/#gpe franktom (~frank@61.49.162.206) |
| 10:20.21 | *** join/#gpe zecke (fakeuser@p54BD005C.dip0.t-ipconnect.de) |
| 10:21.12 | jsmanrique | hi bedboi |
| 10:24.27 | bedboi | any news so far? |
| 10:28.45 | *** join/#gpe JiniDog (~jini@p54BFFB1D.dip.t-dialin.net) |
| 10:32.03 | *** join/#gpe NoFo (~NoFo@p54A2D705.dip.t-dialin.net) |
| 10:34.53 | jsmanrique | no idea |
| 10:51.18 | *** join/#gpe Philippe_work (~fille@204.107-201-80.adsl.skynet.be) |
| 11:02.18 | bedboi | pb_: there? |
| 11:02.47 | bedboi | about the wrong batter percentage level, iirc i found that bug some months ago |
| 11:03.24 | pb_ | bedboi: hello |
| 11:03.27 | bedboi | i'm downloading kernel cvs to point exactly where the bug is |
| 11:06.58 | bedboi | obviously it is in h3600_asic_battery.c |
| 11:16.53 | *** join/#gpe OSS542 (~jhart@l215202.ppp.asahi-net.or.jp) |
| 11:17.43 | Philippe_work | updated packages for gpe-mini-browser (+ slightly fixed gtk-webcore) at /home/fille/mydev/gpe/base |
| 11:17.54 | Philippe_work | s//home/fille/mydev/gpe/base |
| 11:18.22 | Philippe_work | http://handhelds.org/~philippe |
| 11:18.25 | OSS542 | query: Is there a version of gpe for the SL-C3000 ? |
| 11:18.37 | Philippe_work | hi OSS542 |
| 11:18.46 | OSS542 | Good Evening...+-) |
| 11:18.49 | OSS542 | +-) |
| 11:18.51 | Philippe_work | maybe. I do not know all the devices by heart |
| 11:19.17 | OSS542 | that's the one with the postage stamp sized hard drive |
| 11:19.31 | OSS542 | the 4Gb one |
| 11:19.48 | JiniDog | GPE is not device-specific |
| 11:20.09 | Philippe_work | hmmm. It should work if you already have linux & X on it. |
| 11:20.11 | JiniDog | If there is X and gtk working on your device, it very probably runs on it |
| 11:20.27 | OSS542 | hm... I'll have to check with OZ and find out why it's not in the 3.5.3 distro |
| 11:20.42 | XorA | OSS542: it was planned for 3.5.4 |
| 11:20.56 | OSS542 | I see |
| 11:21.02 | XorA | OSS542: C3000/C1000 support only crept into oe a couple of days after 3.5.3 was released |
| 11:21.11 | OSS542 | should be worth the wait I think |
| 11:21.40 | OSS542 | very pleased with it on my C700 |
| 11:21.56 | XorA | OSS542: it should be buildable from OE |
| 11:22.00 | Philippe_work | when is the planned release of 3.5.4? |
| 11:22.08 | OSS542 | Gpe impresses people on such a small box |
| 11:22.09 | __law__ | i have build t an gpe-image but i always get the error, that i use an wrong kernel :-( |
| 11:22.48 | Philippe_work | __law__ : are you using the correct machine in the local.conf? |
| 11:22.51 | __law__ | after that i get an Segmentation fault |
| 11:22.51 | XorA | Philippe_work: I heard mickeyl mention august, but thats prbably subject to change as always |
| 11:23.15 | __law__ | Philippe_work, yes c7x0 |
| 11:23.32 | Philippe_work | XorA : thanks... Some more time to refine GPE :-) |
| 11:23.46 | XorA | well anyone with a C3000 and wants gpe will have to start making images and debugging them |
| 11:24.00 | OSS542 | I may have to get started on that |
| 11:25.07 | Philippe_work | __law__ : well I would check all your settings again (also the distro one and there is a kernel version config option). I cannot help you really much like this on the top of my head. (I am very bad at doing the configuration itself, too much files in different locations) |
| 11:26.13 | __law__ | perhabs i shouldnt use kernel 2.6 with gpe? |
| 11:26.47 | Philippe_work | __law__ : try that, but I don't know if that will solve any issue you are having. |
| 11:28.38 | XorA | with kernel 2.6 |
| 11:37.04 | __law__ | XorA, any ideas what i do wrong? |
| 11:37.56 | XorA | __law__: no idea, I run straight from an OE build |
| 11:38.54 | __law__ | XorA, i build opie in the same tmp perhabs this is the reason? |
| 11:39.58 | XorA | __law__: I used to do that with no problems |
| 11:41.48 | __law__ | XorA, what kernel are you useing? |
| 11:43.15 | XorA | __law__: 2.6.12-mm1 |
| 11:44.37 | __law__ | me too |
| 11:45.13 | *** join/#gpe molivier (~mac@d03v-195-36-132-39.d4.club-internet.fr) |
| 11:46.52 | *** part/#gpe jsmanrique (~jsmanriqu@reutiliza7.energia.uniovi.es) |
| 11:51.32 | bedboi | maybe the issue is around line 919 |
| 11:53.41 | bedboi | pb_: do you remember which interrupt is risen (?) when AC power is plugged? |
| 11:54.45 | bedboi | or it is just polling? |
| 12:18.28 | bedboi | ah, yep it has a sample interval |
| 12:18.52 | pb_ | bedboi: the AC_IN interrupt |
| 12:19.01 | pb_ | I don't remember the number. |
| 12:19.48 | __law__ | XorA, which machine have you set in you local.conf? |
| 12:20.29 | XorA | __law__: c7x0 |
| 12:22.37 | bedboi | pb_: many thanks |
| 12:25.43 | bedboi | ah, here it is |
| 12:25.45 | bedboi | set_GPIO_IRQ_edge( GPIO_H3800_AC_IN, GPIO_BOTH_EDGES ); |
| 12:25.56 | bedboi | h3600_asic_ac_in_isr the handler |
| 12:27.10 | bedboi | that calls h3600_asic_battery_up |
| 12:27.57 | pb_ | yeah, that's the one |
| 12:28.29 | bedboi | hmm |
| 12:28.41 | bedboi | don't remember where the issue was |
| 12:29.21 | bedboi | #if !CHARGING_RATE_VIA_ADC |
| 12:29.21 | bedboi | <PROTECTED> |
| 12:29.21 | bedboi | <PROTECTED> |
| 12:29.21 | bedboi | <PROTECTED> |
| 12:29.21 | bedboi | <PROTECTED> |
| 12:29.22 | bedboi | <PROTECTED> |
| 12:29.57 | bedboi | maybe when plugging AC active_cur_to_ma returns a value < 10 |
| 12:30.05 | bedboi | no |
| 12:30.24 | bedboi | because it would prevent the battery from being charged |
| 12:30.28 | __law__ | XorA, have you build this image today? |
| 12:30.44 | XorA | __law__: no, I havent done one for a week or so |
| 12:30.49 | bedboi | whereas the problem is just that the percentage is set to 100% |
| 12:31.28 | __law__ | XorA, ok perhabs this is my (the) problem since yesterday there is a new openzaurus3.5.4.cong |
| 12:31.32 | __law__ | conf |
| 12:42.25 | bedboi | pb_: well. when i'm logged through serial cable and checking /proc/asic/battery |
| 12:43.16 | bedboi | if i plug usb cable it accumulated current goes to full level |
| 12:43.47 | bedboi | and then stays there |
| 12:44.10 | bedboi | even if i unplug usb cable |
| 12:44.26 | bedboi | Active current : -479 mA |
| 12:44.27 | bedboi | <PROTECTED> |
| 12:44.32 | bedboi | Full level : 1138 mAh |
| 12:48.02 | pb_ | what was the previous accumulated current? |
| 12:48.09 | bedboi | 1126 |
| 12:48.58 | bedboi | it seems that the state machine is a little broken |
| 12:49.48 | bedboi | strange thing: |
| 12:49.57 | bedboi | Active current : -400 mA |
| 12:49.57 | bedboi | <PROTECTED> |
| 12:50.02 | bedboi | Full level : 1140 mAh |
| 12:50.07 | bedboi | it is increasing |
| 12:50.21 | bedboi | btw the ipaq is not on AC |
| 12:52.53 | pb_ | that does seem unfortunate |
| 12:52.57 | bedboi | yep |
| 12:53.03 | bedboi | definitely |
| 12:53.04 | bedboi | : |
| 12:53.05 | bedboi | :) |
| 12:53.12 | bedboi | can you reproduce it? |
| 12:53.15 | pb_ | I think that the battery monitor chip in the h5400 may not be entirely compatible with what h3600_asic_battery expects. |
| 12:53.25 | bedboi | maybe |
| 12:53.26 | pb_ | dunno, I don't have any working h5400s on hand at the moment. |
| 12:55.02 | bedboi | i can't really understand who is setting dev->state to CHARGING_STATE_FULL |
| 12:55.30 | bedboi | ah, maybe here |
| 12:55.32 | bedboi | #if CHARGING_RATE_VIA_ADC |
| 12:55.32 | bedboi | <PROTECTED> |
| 12:57.09 | pb_ | that's only for h3800 |
| 12:57.14 | bedboi | ah, ok |
| 12:57.19 | pb_ | CHARGING_RATE_VIA_ADC is not true for h5400 |
| 12:57.22 | bedboi | ok |
| 12:57.33 | pb_ | (or h3900) |
| 12:58.30 | bedboi | hmmm, maybe the bug is here |
| 12:58.44 | bedboi | in h3600_asic_battery_set_led |
| 12:59.06 | bedboi | i don't get how come the statement "if ( state != dev->state ) {" is there |
| 13:00.23 | bedboi | cause if you call h3600_asic_battery_set_led with CHARGING_STATE_FULL (for some buggy reason) and the current state is not CHARGING_STATE_FULL |
| 13:00.37 | bedboi | later you set dev->state = state; |
| 13:01.07 | bedboi | so the problem could be in any point you call h3600_asic_battery_set_led |
| 13:03.35 | bedboi | ah so the issue must be in h3600_asic_battery_update |
| 13:03.44 | bedboi | on line 921 |
| 13:03.59 | bedboi | it is in a #if !CHARGING_RATE_VIA_ADC |
| 13:04.11 | bedboi | if (active_cur_to_ma(ds->cur,ds->resistor) < 10) |
| 13:04.11 | bedboi | <PROTECTED> |
| 13:04.40 | bedboi | maybe active_cur_to_ma is giving a value < 10 when the AC is plugged |
| 13:05.16 | bedboi | that's the isse! |
| 13:05.18 | bedboi | issue |
| 13:05.28 | bedboi | cause when you plug you have cur < 0 |
| 13:05.29 | bedboi | ! |
| 13:06.32 | bedboi | pb_: what do you think? |
| 13:07.53 | pb_ | bedboi: why do you think that would cause this effect? |
| 13:08.29 | bedboi | active_cur_to_ma will return a value < 0 |
| 13:09.06 | pb_ | right, and? |
| 13:09.31 | bedboi | then h3600_asic_battery_set_led (CHARGING_STATE_FULL); is called |
| 13:09.37 | pb_ | right, and? |
| 13:09.46 | bedboi | setting dev->state to CHARGING_STATE_FULL |
| 13:10.07 | pb_ | right, and? |
| 13:10.33 | bedboi | well it shouldn't be in that state |
| 13:10.52 | bedboi | cause the battery it's not full |
| 13:11.53 | bedboi | hmmm. maybe ds->cur is always positive |
| 13:12.49 | pb_ | that might be true, but I don't think setting it to that state will actually do any harm. |
| 13:13.30 | bedboi | now i'm charging |
| 13:13.32 | pb_ | if it goes into CHARGING_STATE_FULL prematurely, the only ill effect will be that the LED will stop flashing for fifteen seconds. |
| 13:13.46 | bedboi | Active current : 758 mA |
| 13:13.50 | pb_ | next time h3600_asic_battery_update() is called, it will set the state back to CHARGING, and the LED will start to flash again. |
| 13:13.52 | bedboi | Accumulated current : 1142 mAh |
| 13:13.58 | bedboi | Full level : 1140 mAh |
| 13:14.33 | bedboi | pb_: and that is what happens |
| 13:14.36 | bedboi | i think |
| 13:14.54 | bedboi | btw we get an accumulated current which is equal to Full Level |
| 13:15.05 | pb_ | oh. |
| 13:15.18 | pb_ | I thought you were trying to debug the problem with the battery level being reported wrong, not some cosmetic problem with the LEDs. |
| 13:15.49 | pb_ | I agree that the LED thing might be a bug. I guess you could fix it by delaying the read of the charging current for a bit. |
| 13:15.55 | bedboi | no, not the LED |
| 13:16.08 | bedboi | that's not so interesting :) |
| 13:16.40 | bedboi | pb_: let me rephrase |
| 13:17.05 | bedboi | let's say accumulated current is at "x" mA |
| 13:17.13 | bedboi | and Full level is y mA |
| 13:17.36 | bedboi | the problem is that when you plug the battery |
| 13:17.40 | bedboi | x = y |
| 13:17.46 | bedboi | and then x will increase |
| 13:18.04 | bedboi | the battery will stop charging x is set again to y |
| 13:19.14 | pb_ | ah, okay, I see what you mean. |
| 13:19.28 | pb_ | you're saying that the ACR is destroyed by the false "full" indication? |
| 13:19.43 | pb_ | that probably is a risk, yeah. |
| 13:19.50 | bedboi | yep |
| 13:20.21 | pb_ | by all means add a delay around the ac_in function. |
| 13:20.53 | bedboi | which is h3600_asic_ac_in_isr |
| 13:21.18 | bedboi | i can sleep there, is it safe? |
| 13:21.31 | pb_ | no |
| 13:21.37 | pb_ | you'll have to schedule a callback for later. |
| 13:21.45 | pb_ | bbiab, gotta go to the hardware lab for a while |
| 13:21.54 | bedboi | ok. have fun :) |
| 13:26.59 | *** part/#gpe bedboi ([U2FsdGVkX@signserv.Signal.Uu.Se) |
| 13:27.59 | *** join/#gpe jamey (~jamey@192.208.47.196) |
| 13:29.03 | __law__ | could anyone try do build an gpe-image and flash it to his clamshell :-) |
| 13:31.28 | *** join/#gpe bedboi ([U2FsdGVkX@signserv.Signal.Uu.Se) |
| 13:31.38 | koen|ewi | I could if my clamshell weren't thousands of miles away ;) |
| 13:31.44 | bedboi | hey koen |
| 13:31.46 | bedboi | :) |
| 13:31.49 | koen|ewi | hey bedboi |
| 13:32.10 | bedboi | how you doing? |
| 13:32.16 | koen|ewi | very good |
| 13:32.19 | koen|ewi | and you? |
| 13:32.26 | bedboi | quite well |
| 13:32.35 | bedboi | apart the fact that i have to trash 500 euros |
| 13:32.48 | __law__ | if i flash there is an error message you are runnning kernel `` |
| 13:33.04 | __law__ | expectet 2.6.12-mm1 .... |
| 13:33.27 | koen|ewi | how so? |
| 13:33.29 | __law__ | could it be that gpe cant read my kernel version? |
| 13:33.39 | koen|ewi | __law__: that's probably the checkversion script |
| 13:34.54 | __law__ | koen|ewi, any ideas what i can do? |
| 13:35.24 | koen|ewi | remove the checkversions script |
| 13:35.42 | __law__ | where can i find it? |
| 13:36.08 | koen|ewi | /etc/init.d/ |
| 13:36.28 | __law__ | my Z seg faults on boot :-( |
| 13:36.42 | __law__ | so i cant access to /etc/init.d |
| 13:48.17 | *** part/#gpe priest_ux (~ildar@82.200.129.202.adsl.online.kz) |
| 13:50.44 | bedboi | is anyone working on 6345? |
| 13:55.30 | koen|ewi | the ipaq? |
| 13:55.43 | koen|ewi | they have linux booting |
| 13:55.51 | koen|ewi | and they are trying to get gpe running on it too |
| 13:57.16 | bedboi | wow! |
| 13:57.26 | bedboi | i didn't found anything on that |
| 13:57.36 | XorA | do ipaq models numbers actually mean anything? |
| 13:58.11 | koen|ewi | not really |
| 13:58.27 | koen|ewi | the last number signifies business or personal sales |
| 13:58.34 | koen|ewi | xxx5 vs xxx0 |
| 13:58.41 | XorA | koen|ewi: ah |
| 13:59.00 | *** join/#gpe reenoo (~r@p5489FAC6.dip.t-dialin.net) |
| 13:59.08 | reenoo | afternoon |
| 13:59.16 | *** join/#gpe JiniDog (~jini@p54BFDB52.dip.t-dialin.net) |
| 13:59.41 | XorA | koen|ewi: have you dont an abiword compile recently? |
| 13:59.49 | XorA | s/dont/done/ |
| 14:01.48 | koen|ewi | nope |
| 14:02.39 | XorA | koen|ewi: damn, I get a wierd sucky symbol has changed size error |
| 14:03.00 | koen|ewi | afaik the csl gcc is broken |
| 14:03.14 | koen|ewi | or abiword, depending on whose side you're on :) |
| 14:03.44 | XorA | koen|ewi: ah, that sucks |
| 14:05.02 | *** join/#gpe jg (~jg@192.208.47.82) |
| 14:08.55 | *** join/#gpe koen (~koen@cl-148.ams-05.nl.sixxs.net) |
| 14:11.18 | *** join/#gpe koen|ewi (~koen@ewi546.ewi.utwente.nl) |
| 14:18.41 | ignatoff | any idea what happened to the bluez stuff in the CVS ? its empty ..... |
| 14:41.53 | bedboi | pb_: do you think using task queue is a good way to do that? or i should use tasklets? |
| 14:45.54 | pb_ | ignatoff: in gpe cvs? I don't think we ever had any bluez stuff there. |
| 14:46.00 | pb_ | except gpe-bluetooth, which (last time I looked) was not empty |
| 14:46.18 | pb_ | bedboi: I guess it doesn't matter much. |
| 14:46.22 | bedboi | ok |
| 14:46.27 | bedboi | so implementing |
| 14:46.32 | pb_ | righto |
| 14:46.50 | pb_ | by the way, did you actually confirm that your theory about the bug was correct? |
| 14:46.59 | bedboi | nope. |
| 14:47.05 | bedboi | don't know how to confirm :) |
| 14:47.05 | pb_ | (i.e. by instrumenting the code to see if it was detecting a current less than 10mA) |
| 14:47.12 | bedboi | ah ok |
| 14:47.19 | pb_ | it might be a good idea to do that before trying to implement a fix. |
| 14:47.22 | bedboi | yep |
| 14:47.23 | bedboi | :) |
| 14:51.08 | bedboi | compiling |
| 14:52.46 | ignatoff | pb_: i found what i needed :) thanks ... its under alsa |
| 14:53.40 | ignatoff | pb_ perhaps you know are alsa modules built for familiar-0.8.2 ? |
| 14:54.04 | pb_ | I don't think they are. |
| 14:54.12 | ignatoff | :( |
| 14:54.16 | pb_ | check with koen, though. |
| 14:54.40 | ignatoff | pb_:thanks |
| 14:55.51 | *** join/#gpe Philippe_work (~fille@117.209-200-80.adsl.skynet.be) |
| 15:04.30 | *** join/#gpe tigrux (~tigrux@dsl-200-67-236-216.prod-empresarial.com.mx) |
| 15:10.43 | *** join/#gpe tigrux (~tigrux@dsl-200-67-236-216.prod-empresarial.com.mx) |
| 15:41.56 | *** join/#gpe krokas (~krokas@ppp83-237-108-38.pppoe.mtu-net.ru) |
| 15:48.03 | *** join/#gpe zap (~zap@217.170.93.9) |
| 16:04.07 | bedboi | pb_: my theory is well confirmed |
| 16:04.10 | bedboi | h3600_asic_battery_update: ds->cur: -478 ds->resistor: 77 |
| 16:04.10 | bedboi | h3600_asic_battery_set_full: ds->cur: -478 ds->resistor: 77 |
| 16:05.19 | pb_ | aha. |
| 16:08.21 | bedboi | doing some other testa |
| 16:08.24 | bedboi | tests either |
| 16:09.52 | pb_ | very good |
| 16:17.25 | bedboi | so i'm going to fix it adding that delay |
| 16:17.28 | bedboi | maybe 500 ms |
| 16:17.32 | bedboi | or something? |
| 16:18.34 | pb_ | yeah, try that |
| 16:18.43 | pb_ | could check the ds2760 datasheet to see how often it updates its status |
| 16:22.05 | *** part/#gpe ade|desk (~adavey@194.200.143.249) |
| 16:25.50 | *** join/#gpe _krokas (~krokas@ppp83-237-108-61.pppoe.mtu-net.ru) |
| 16:29.25 | bedboi | h3600_asic_battery_up: ds->cur: 60 ds->resistor: 77 |
| 16:29.25 | bedboi | h3600_asic_battery_up: ds->cur: -85 ds->resistor: 77 |
| 16:29.25 | bedboi | h3600_asic_battery_update: ds->cur: -738 ds->resistor: 77 |
| 16:29.25 | bedboi | h3600_asic_battery_set_full: ds->cur: -738 ds->resistor: 77 |
| 16:29.25 | bedboi | h3600_asic_battery_update: ds->cur: 71 ds->resistor: 77 |
| 16:29.55 | bedboi | ah, battery_up is called two times |
| 16:29.57 | bedboi | hmmm |
| 16:52.05 | *** join/#gpe krokas_ (~krokas@ppp83-237-11-129.pppoe.mtu-net.ru) |
| 17:29.34 | reenoo | anyone happen to know if that guy working on mono is making progress? |
| 17:32.35 | bedboi | at least i found some time to implement that stuff |
| 17:34.15 | bedboi | it works :) |
| 17:34.17 | bedboi | yay |
| 17:35.26 | bedboi | now h5400 reports good battery stats |
| 17:54.45 | *** join/#gpe zecke_ (~ich@83-169-171-16-dynip.superkabel.de) |
| 18:04.22 | *** join/#gpe rob-w (~pocketirc@p213.54.156.204.tisdip.tiscali.de) |
| 18:43.03 | *** join/#gpe france_ (~france@dhcp-208-55.crl.hpl.hp.com) |
| 18:55.52 | *** join/#gpe Timelord0 (~TL@4.78.4.43) |
| 19:00.56 | *** join/#gpe BBrox (~ulmer@bbrox.org) |
| 19:23.29 | *** join/#gpe krokas_ (~krokas@ppp83-237-11-116.pppoe.mtu-net.ru) |
| 19:45.31 | *** part/#gpe krokas_ (~krokas@ppp83-237-11-116.pppoe.mtu-net.ru) |
| 19:46.58 | bedboi | maybe it's time to go home |
| 19:57.16 | *** join/#gpe _law_ (~law@213.173.86.202) |
| 19:58.50 | *** join/#gpe krokas_ (~krokas@ppp83-237-60-251.pppoe.mtu-net.ru) |
| 20:40.04 | *** join/#gpe ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc) |
| 20:40.04 | *** topic/#gpe is The GPE Palmtop Environment - http://gpe.handhelds.org/ | GPE Wiki: http://handhelds.org/moin/moin.cgi/GPEProject | unstable images outdated: http://handhelds.org/~pb/unstable/ | unstable feed now (sort of) working again | familiar snapshots: http://familiar.handhelds.org/snapshots/ |
| 21:04.29 | *** join/#gpe krokas_ (~krokas@ppp83-237-60-237.pppoe.mtu-net.ru) |
| 21:12.22 | koen | heh |
| 21:12.52 | koen | the "transport security administration" folded all my clothes after inspecting my suitcase |
| 21:13.37 | reenoo | transport security administration? |
| 21:14.19 | koen | the people who check your luggage on the airports in the us |
| 21:14.51 | reenoo | ah, ok |
| 21:14.58 | reenoo | so, you're in .us now? |
| 21:15.03 | koen | yes |
| 21:15.09 | koen | New orleans at the moment |
| 21:15.15 | reenoo | vacation? |
| 21:15.21 | koen | yes :) |
| 21:15.25 | reenoo | cool |
| 21:15.53 | *** join/#gpe Philippe (~philippe@ip-213-49-69-98.dsl.scarlet.be) |
| 21:15.58 | reenoo | mardi gras or something? (I forget which time of the year that is) |
| 21:16.15 | Philippe | evening people |
| 21:16.20 | reenoo | bonsoir Philippe |
| 21:16.28 | Philippe | salut reenoo |
| 21:16.40 | koen | no mardi gras afaik |
| 21:17.25 | Philippe | which date are we talking about? |
| 21:20.09 | koen | 13 july 2005 |
| 21:20.21 | reenoo | Philippe: koen is in new orleans atm. I was wondering whether he was there because of mardi gras. but that appears to be not the case. |
| 21:20.34 | Philippe | okay :-) |
| 21:20.46 | Philippe | koen, have fun at that side of the ocean :-) |
| 21:20.52 | reenoo | ok, monotone is stuck again |
| 21:21.02 | reenoo | no more OE development for me it seems |
| 21:22.53 | zecke_ | reenoo: :} |
| 21:23.00 | zecke_ | reenoo: still on pull? |
| 21:23.18 | zecke_ | reenoo: that is ineed unfortunate |
| 21:24.42 | zecke_ | reenoo: vanille is down, that would explain some slowness |
| 21:24.53 | reenoo | zecke: first time I killed it after around an hour. the second time (differnt box) it died after 2 hours. now on my build box and pulling from koen's ewi box it's stuck at 21.9M again |
| 21:25.58 | *** join/#gpe beewoolie-afk (~beewoolie@florence.buici.com) |
| 21:26.03 | reenoo | and it's not like I'm running it on a slow box... (2.4GHz P4 here, dual Xeon 2.something GHz at university) |
| 21:26.52 | reenoo | as a new user or someone evaluating OE I'd have given up after 30 mins on first try |
| 21:27.58 | Philippe | I also got me a fast machine to do OE. But I still need more ram... The new COW patches help though |
| 21:32.37 | koen | bitbake consumes about 30M for the metadata over here |
| 21:33.43 | reenoo | yeah, bitbake is not a big problem any more memory wise |
| 21:36.08 | zecke_ | reenoo: the verifying phase is indeed the problem ;) the db has all information |
| 21:43.56 | reenoo | zecke_: so, you said I could turn that off. how? |
| 21:44.53 | zecke_ | reenoo: that was an educated guess |
| 21:45.17 | zecke_ | reenoo: I think the CPU cycle wasting is a feature and not a necessity (lart my spelling..) |
| 21:46.52 | Philippe | ~lart CPU cycle waste |
| 21:47.56 | reenoo | zecke_: I see |
| 22:25.31 | *** join/#gpe molivier2 (~mac@212.194.137.4) |
| 22:26.30 | zecke_ | reenoo: it definately takes too long |
| 22:40.49 | zecke_ | reenoo: 68 minutes (still too long though) |
| 22:48.22 | Philippe | `night all |
| 23:01.10 | *** join/#gpe jg (~jg@c-24-63-93-208.hsd1.ma.comcast.net) |
| 23:12.14 | *** join/#gpe darmou (~darmou@CPE-61-9-146-174.vic.bigpond.net.au) |
| 23:49.54 | *** join/#gpe darmou (~darmou@CPE-61-9-146-174.vic.bigpond.net.au) |
