**** BEGIN LOGGING AT Sun Dec 04 02:59:58 2011
Dec 04 10:25:28 <JaMa|Off> 003 will be closed in an hour if nobody has something important to push..
Dec 04 10:30:21 <mrmoku> ouch... still have to test 002 :P
Dec 04 10:30:34 <mickey|munich> ~seen morphis
Dec 04 10:31:06 <mrmoku> JaMa|Off: still hanging with that libtool thing
Dec 04 10:31:12 <mrmoku> I removed sstate-cache
Dec 04 10:31:16 <mrmoku> renamed the tmp-eglibc
Dec 04 10:31:25 <mrmoku> disabled config.mk
Dec 04 10:31:27 <mrmoku> nothing helps
Dec 04 10:31:54 <mrmoku> anyway... bbl
Dec 04 10:36:40 <JaMa|Off> mrmoku: then send me whole log I guess it could be something like this http://git.openembedded.org/openembedded-core/commit/?id=94b7566ac9d07ad3e1b55f12988f53812d3651cd
Dec 04 10:40:31 <JaMa|Off> bbl too
Dec 04 11:02:53 <mrmoku> JaMa|Off: http://pastebin.com/vE3J1vJZ
Dec 04 11:30:37 <angelox|laptop_> good morning people
Dec 04 13:01:56 <mickey|munich> ~seen morphis
Dec 04 13:02:29 <GNUtoo> hi mickey|munich 
Dec 04 13:03:14 <mickey|munich> morning GNUtoo , what'sup?
Dec 04 13:03:21 <GNUtoo> many things
Dec 04 13:03:26 <mickey|munich> did hns talk to you yet? (Nikolaus Schaller from goldelico)
Dec 04 13:03:32 <GNUtoo> no
Dec 04 13:03:35 <GNUtoo> let's PM about that
Dec 04 13:04:37 <mickey|munich> do you know why vala has been updated?
Dec 04 13:04:42 <mickey|munich> it breaks a bunch of things...
Dec 04 13:05:08 <mrmoku> mickey|munich: morphis is the one to ask :)
Dec 04 13:05:17 <mickey|munich> ya, been trying to get hold of him
Dec 04 13:05:21 <mrmoku> and yes... it caused major breakages
Dec 04 13:05:23 <mickey|munich> i don't like some of the changes in so
Dec 04 13:05:26 <mickey|munich> fso, actually
Dec 04 13:05:33 <mrmoku> ok
Dec 04 13:05:37 <mickey|munich> not sure whether they are necessary in 0.14
Dec 04 13:05:44 <mickey|munich> will investigate
Dec 04 13:05:50 <mickey|munich> been off the loop for too long
Dec 04 13:06:00 <mrmoku> watching your vala 2 video right now
Dec 04 13:06:01 <mickey|munich> will also resume work on the vala book, btw.
Dec 04 13:06:09 <mrmoku> :)
Dec 04 13:06:11 <mickey|munich> ah, right, the live stream has been recorded
Dec 04 13:09:13 * mickey|munich summons morphis
Dec 04 13:50:05 <mrmoku> hmm... wgetpaste not working anymore
Dec 04 14:48:46 <taruti> what is the status of xrandr -o 1?
Dec 04 14:49:04 <GNUtoo> taruti, on what device?
Dec 04 14:49:30 <taruti> gta02
Dec 04 14:51:14 <GNUtoo> yes it works under shr-core again
Dec 04 14:51:27 <GNUtoo> *it works again under shr-core
Dec 04 14:54:30 <taruti> ok :)
Dec 04 16:17:33 <zub> pespin: hola! can you guess what's wrong in this: http://fpaste.org/rja9/
Dec 04 16:18:05 <zub> pespin: (let's forget about the Elm.shutdown() for now... though, it seems to crash for me, but that's not the issue I care about at the moment)
Dec 04 16:19:25 <pespin> zub, which problem do you get?
Dec 04 16:19:33 <zub> ** Message: test.vala:4: s=(null)
Dec 04 16:19:40 <zub> and I think it's a fundamental issue
Dec 04 16:19:46 <zub> and I don't see a solution with EFL
Dec 04 16:19:47 <zub> :-/
Dec 04 16:20:26 <zub> if you have a look at the generated C... and at hod vala implements lambdas, it becomes obvious
Dec 04 16:20:28 <pespin> yeah
Dec 04 16:20:37 <pespin> afair, that's why I'm using objects on callbacks ;)=
Dec 04 16:21:18 <zub> to be correct, all the delegates should be owned... but EFL doesn't support anything like GDestroyNotify... at least I don't see it in EFL
Dec 04 16:21:21 <pespin> just put all the stuff in an object, then use a method on that object to be called when the callback happens
Dec 04 16:21:29 <zub> :-/
Dec 04 16:21:39 <pespin> then ref the object so it doesn't get deleted
Dec 04 16:21:40 <zub> I know how to work around it... but it means libeflvala is broken
Dec 04 16:21:44 <zub> and it will be borken
Dec 04 16:21:45 <zub> broken
Dec 04 16:21:57 <pespin> why? explain
Dec 04 16:22:03 <zub> because of %^
Dec 04 16:22:24 <zub> sigh... you pass lambda, it's 100% ok from Vala point of view
Dec 04 16:22:28 <zub> you get no error, no warning
Dec 04 16:22:36 <zub> but you get undefined behaviour at runtime
Dec 04 16:22:49 <zub> even with methods it works only as long as something else keeps the instance alive
Dec 04 16:23:03 <zub> that's what I call broken...
Dec 04 16:23:07 <pespin> the instance of stuff used inside the lambda?
Dec 04 16:23:08 <zub> yes, you can work around this
Dec 04 16:23:38 <pespin> I was told in vala to do what I'm doing long time ago
Dec 04 16:23:45 <pespin> I don't know if there's a better way I'm sorry ;)
Dec 04 16:23:56 <zub> this is not for me :-/
Dec 04 16:24:09 <zub> "sort-of-work if you keep working around issues"
Dec 04 16:24:17 <zub> stable robust lib... yeah :(
Dec 04 16:24:41 <pespin> I don't know what more to do there hehe
Dec 04 16:25:53 <zub> in general it means that for all delegates in EFL you have to make sure yourself that their associated data (instance - this, if it's a method, or Vala's BlockData if it's a lambda) is kept alive
Dec 04 16:26:11 <pespin> yeah
Dec 04 16:27:00 <zub> one could make some eflvala glue probably - keeping all delegates that are registered alive as long as the efl instance that they are registered to lives
Dec 04 16:27:21 <zub> so all smart_Callback_add's would also keep the delegates in some map
Dec 04 16:27:29 <zub> but this would be quite an overhead
Dec 04 16:27:39 <pespin> I agree
Dec 04 16:28:13 <pespin> that's what I said, the best way I've seen is using gobjects as containers
Dec 04 16:28:27 <pespin> if you don't want to struggle with how to keep them alive, you can just object.ref()
Dec 04 16:28:38 <pespin> and on the method called on the callback, at the end: object.unref()
Dec 04 16:29:12 <zub> you mean - app should do this, or lib?
Dec 04 16:29:24 <zub> for lib - from simple call you doin't know if the callback is gonna be reused
Dec 04 16:29:29 <zub> with EFL it often will (button click)
Dec 04 16:30:55 <pespin> btw, afair you can use lambda in callback as long as you  call it inside a class and access fields inside an object
Dec 04 16:31:16 <pespin> app
Dec 04 16:31:18 <zub> ehm?
Dec 04 16:31:25 <zub> app = no solution :-/
Dec 04 16:31:36 <pespin> yeah, using the gobject glue
Dec 04 16:32:31 <pespin> for instance, this works -> bt_ok.smart_callback_add( "clicked", this.cb_create_account );
Dec 04 16:32:43 <pespin> or using a lambda which uses fields of the same object
Dec 04 16:32:48 <zub> works *as long as* something else keeps this alive
Dec 04 16:32:57 <pespin> of course
Dec 04 16:32:58 <zub> I think with the lambda it would be wrong
Dec 04 16:33:06 <pespin> afair I use lambdas there too
Dec 04 16:33:07 <zub> unless you keep the lambda itself alive
Dec 04 16:33:08 <pespin> let me find it
Dec 04 16:33:12 <zub> it might work by accident
Dec 04 16:33:18 <zub> look at the generated code
Dec 04 16:33:22 <pespin> I always keep gobjects alive
Dec 04 16:33:48 <pespin> either by adding them to data structures such as HashTable passing ownership of objects to it, or by manually kalling this.ref()
Dec 04 16:34:00 <zub> for lambdas: when the scope they are in is left - if nothing else keeps their block data alive, their block data is deleted
Dec 04 16:34:39 <pespin> this works -> nickname.val.smart_callback_add("changed", () => {
Dec 04 16:34:39 <pespin> 							account.dbus.nickname = nickname.val_get();
Dec 04 16:34:39 <pespin> 													});
Dec 04 16:35:09 <pespin> because all instances used in lambda are keeped alive by the object itself
Dec 04 16:35:41 <pespin> yeah, but there's no much problem about keeping gobjects alive
Dec 04 16:36:14 <zub> what is "account" in the example of yours? is it this.account, or some global account?
Dec 04 16:36:46 <pespin> this.account
Dec 04 16:37:01 <pespin> so as I said, always use a gobject as glue to keep ref of everything you use alive
Dec 04 16:37:04 <zub> then I think it can only work by accident, as the lamba does need the value of this
Dec 04 16:37:19 <pespin> yes, and what's the problem?
Dec 04 16:37:32 <zub> working-by-accident is not a problem?
Dec 04 16:37:35 <pespin> I keep this alive
Dec 04 16:37:48 <pespin> it's not working by accident, I'm keeping the gobject alive
Dec 04 16:37:54 <pespin> and with it, everything needed by the callback
Dec 04 16:39:43 <pespin> you may want to look at etalk code for more details/examples if you want :)
Dec 04 16:42:53 <zub> ok, now I see why using onlu stuff from this works: in this case vala doesn't create a BlockData for the lambda and passes only this... so it will work (with the usual: as long as the isntance is alive)
Dec 04 16:43:07 <pespin> yep
Dec 04 16:44:44 <zub> pespin: have you analyzed the generated C code?
Dec 04 16:44:51 <zub> or you just concluded by trial-and-error?
Dec 04 16:46:39 <pespin> zub, I think I looked into it wsome time ago
Dec 04 16:46:47 <pespin> and also asked in #vala
Dec 04 16:46:55 <pespin> and I arrived to that conclusion
Dec 04 16:47:27 <pespin> you have to keep alive everything you use into the callback, and so an easy way is to add everything to a gobject and then keep alive the gobject
Dec 04 16:48:19 <zub> or you can just keep the delegate alive and this solves the issue
Dec 04 16:48:35 <zub> I'm wriin a sort-of-widget, so I use the well-known chernobyl design pattern
Dec 04 16:50:16 <zub> the more I poke into vala and EFL, the more I'm disappointed :(
Dec 04 17:03:53 <dos1> mrmoku: ping
Dec 04 17:04:59 <dos1> mrmoku: is there some gta02 shr-core image which is known to be not-so-broken, or should i just download latest?
Dec 04 17:05:36 <JaMa|Wrk> dos1: use latest staging if you want to work on shr-settings
Dec 04 17:06:47 <dos1> JaMa|Wrk: now i want something working quickly just to make photos, and then something to work on :)
Dec 04 17:07:06 <dos1> JaMa|Wrk: another question, ubifs or jffs2?
Dec 04 17:07:25 <mrmoku> dos1: do whatever JaMa|Wrk says :-)
Dec 04 17:07:28 * mrmoku dinner
Dec 04 17:08:34 <JaMa|Wrk> dos1: check stabilizing page if someone reported something bad, but latest staging works for me
Dec 04 17:09:05 <dos1> JaMa|Wrk: ok then, looks like latest staging is the way to go
Dec 04 17:09:43 <dos1> JaMa|Wrk: but i see something about jffs2 image being broken on ml
Dec 04 17:10:02 * JaMa|Wrk is using only uSD.. so no idea
Dec 04 17:10:10 <dos1> ok
Dec 04 17:12:25 <dos1> i was always using uSD too, but now i lended one to my gf so there's no usd for FR ;x
Dec 04 17:13:40 * JaMa|Wrk checking what's on his nand partition :)
Dec 04 17:14:05 <JaMa|Wrk> hmm looks like old shr-u
Dec 04 17:17:53 <dos1> i have now some reeeaaaly old shr-u
Dec 04 17:18:07 <dos1> with illume1
Dec 04 17:18:26 <PaulFertser> dos1: i bet you're going to opkg upgrade it, reflashing is for the sissies? ;)
Dec 04 17:19:01 <dos1> PaulFertser: haha :D
Dec 04 17:19:40 <dos1> PaulFertser: i will do that when my uSD returns :D
Dec 04 17:38:50 <JaMa|Wrk> GNUtoo: how is kernel upgrade going? if you have something usable I'll be happy to give you r/w on gitorious repo to push it there
Dec 04 17:40:15 <GNUtoo> not yet
Dec 04 17:40:24 <GNUtoo> I'm upstreaming rather
Dec 04 17:40:27 <GNUtoo> not upgrading
Dec 04 17:40:35 <GNUtoo> I've some problem with serial console
Dec 04 17:40:42 <GNUtoo> it's broken on crespo and om-gta02
Dec 04 17:41:49 <JaMa|Wrk> ah, ok thanks
Dec 04 17:44:37 <GNUtoo> I've sent a patch for making it compile with mainline
Dec 04 17:44:41 <GNUtoo> let's see how it goes 
Dec 04 17:44:44 <GNUtoo> but that'll be long
Dec 04 17:49:02 <mrmoku> dos1: works?
Dec 04 17:54:31 <dos1> mrmoku: waiting for battery, was completely flat ;x
Dec 04 17:57:57 <mrmoku> hehe
Dec 04 18:06:00 <leirbag> hi all, I would like to know if someone could help me to understand some part of the MMC driver in U-Boot ? I would like to reduce the time of the init, currently, it takes about 1s, on Linux it's fastest. I tried to read the spec of the controller, but there is some obscure part ... 
Dec 04 18:08:33 <lindi-> leirbag: newer u-boot versions probably have better driver?
Dec 04 18:09:37 <leirbag> I don't wanna to port the s3c24x0 to newer u-boot currently, maybe later :), and the architecture have been totally reviewed
Dec 04 18:10:02 <PaulFertser> leirbag: try Qi then ;)
Dec 04 18:10:37 <leirbag> I can't, I did the support of multi block and I need ext4 (I added the support too ...), it's for a personnal need :)
Dec 04 18:11:43 <leirbag> but I will compare the driver with qi ... maybe ... :)
Dec 04 18:14:25 <leirbag> it seems in qi that the driver is the same
Dec 04 18:14:39 <leirbag> udelay(1250000); /* FIXME: 74 SDCLK cycles */
Dec 04 18:14:52 <leirbag> if I try to reduce the time, it doesn't work anymore
Dec 04 18:15:05 <leirbag> 125ms is BIG for 74SDCLK :/
Dec 04 18:15:43 <leirbag> mmcinit takes about 1s
Dec 04 18:43:11 <mrmoku> JaMa|Wrk: btw. this is bb -e output: http://pastebin.com/GWvXcSfR
Dec 04 18:44:38 <JaMa|Wrk> mrmoku: ?
Dec 04 18:45:04 <JaMa|Wrk> mrmoku: looking at subversion issue or?
Dec 04 18:48:15 <JaMa|Wrk> mrmoku: please try to upgrade to 1.7.1 and see if you still have the same issue
Dec 04 18:48:40 <JaMa|Wrk> or I'll add it when I'm back @home 
Dec 04 18:52:25 <mrmoku> JaMa|Wrk: ok
Dec 04 19:40:42 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * r51452fac6974 10aurora/aurora-daemon/src/applications/app-settings/SettingsPage.qml: aurora-daemon: settings: remove unused signal
Dec 04 19:40:43 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * rf63c307f717b 10aurora/aurora-daemon/src/ (9 files in 2 dirs): 
Dec 04 19:40:43 <CIA-69> freesmartphone.org: aurora-daemon: about: create an about app
Dec 04 19:40:43 <CIA-69> freesmartphone.org: - This app includes shows the device's marketing name
Dec 04 19:40:43 <CIA-69> freesmartphone.org: - Create an class for the device informations
Dec 04 19:40:43 <CIA-69> freesmartphone.org: - device informations: device cpu info,device codename and device marketing name
Dec 04 20:08:08 <JaMa|Off> mrmoku: should I add it or do you have it already?
Dec 04 20:18:11 <mrmoku> JaMa|Off: heh... I added it... built... did some daywork... checked now to see it built 1.6.15 :P
Dec 04 20:18:23 <mrmoku> but that one built fine
Dec 04 20:23:00 <mrmoku> JaMa|Off: building with fixed preferred version now
Dec 04 20:26:14 <JaMa|Off> :)
Dec 04 20:26:47 <JaMa|Off> do you still use shr-chroot?
Dec 04 20:26:59 <paulk-desktop> hi there
Dec 04 20:28:20 <paulk-desktop> would it be possible to release built shr-lite images for crespo (Nexus S) via the official SHR feeds? (mainly, build.shr-project.org)
Dec 04 20:28:25 <mrmoku> JaMa|Off: yup, sure
Dec 04 20:28:52 <JaMa|Off> mrmoku: ok, so I'll try to rebuild it here
Dec 04 20:29:20 <JaMa|Off> paulk-desktop: shr-core?
Dec 04 20:29:33 <paulk-desktop> JaMa|Off, I think so
Dec 04 20:29:39 <paulk-desktop> it uses cornucopia at least
Dec 04 20:29:52 <JaMa|Off> every shr- is using cornucopia
Dec 04 20:30:00 <paulk-desktop> ok
Dec 04 20:30:08 <JaMa|Off> mrmoku: "good" I can reproduce it here
Dec 04 20:30:31 <paulk-desktop> how long does it take to download SHR source + build shr-lite?
Dec 04 20:31:11 <mrmoku> JaMa|Off: the libtool problem?
Dec 04 20:32:56 <JaMa|Off> mrmoku: yes
Dec 04 20:33:00 <mrmoku> good :)
Dec 04 20:33:29 <mrmoku> JaMa|Off: 1.7.1 does not fix it
Dec 04 20:34:11 <JaMa|Off> mrmoku: ok, can you push or share 1.7.1 patch?
Dec 04 20:34:33 <nschle85> paulk-desktop: it depends on download bandwidth and speed of you computer
Dec 04 20:35:05 <paulk-desktop> 3Ghz dual core with 4GB ram
Dec 04 20:35:32 <JaMa|Off> paulk-desktop: 10 hours maybe
Dec 04 20:35:37 <paulk-desktop> mhh
Dec 04 20:35:38 <paulk-desktop> I see
Dec 04 20:35:45 <paulk-desktop> I'll just get the chroot for today
Dec 04 20:35:58 <paulk-desktop> does it contain the cross compiler?
Dec 04 20:36:11 <paulk-desktop> or is it built too?
Dec 04 20:36:17 <paulk-desktop> s/built/to build/
Dec 04 20:36:33 <nschle85> paulk-desktop: all needed things are build from scratch
Dec 04 20:36:44 <paulk-desktop> ok
Dec 04 20:37:07 <JaMa|Off> GNUtoo: what's status of crespo in shr-core? buildhost is free, so I can start crespo build if it's worth it
Dec 04 20:37:54 <nschle85> paulk-desktop: you also need round about 40GB freee disk space
Dec 04 20:38:04 <paulk-desktop> wow, that much!
Dec 04 20:39:39 <GNUtoo> JaMa|Off, I just built crespo:
Dec 04 20:39:54 <GNUtoo> * telephony used to work => currently broken
Dec 04 20:39:59 <GNUtoo> including data
Dec 04 20:40:11 <GNUtoo> apart that it's mostly fine apart alsa and wifi
Dec 04 20:40:27 <GNUtoo> alsa has some issues but mostly work
Dec 04 20:40:33 <GNUtoo> wifi doesn't work yet
Dec 04 20:40:36 <JaMa|Off> ok, good enough, I'll start build on buildhost then
Dec 04 20:40:43 <mrmoku> JaMa|Off: moment
Dec 04 20:40:51 <GNUtoo> and you need to mkbootimg to boot it
Dec 04 20:41:51 <GNUtoo> wifi can be fixed by waiting for a patch in compat wireless
Dec 04 20:41:56 <GNUtoo> it should work after that
Dec 04 20:42:03 <JaMa|Off> paulk-desktop: build started.. it will be part of staging 004 and it should not take so long as it's also a8
Dec 04 20:42:09 <GNUtoo> it's a dummy irq handler for function2 of the sdio card
Dec 04 20:42:32 <GNUtoo> then about alsa it can also work, mark brown backported it to crespo
Dec 04 20:42:41 <JaMa|Off> thank you
Dec 04 20:42:43 <GNUtoo> but I broke my back speaker trying
Dec 04 20:42:46 <paulk-desktop> ok JaMa|Off, thanks!
Dec 04 20:45:08 <GNUtoo> ahh sorry wrong machine
Dec 04 20:45:13 <GNUtoo> I built for om-gta02 not crespo
Dec 04 20:45:27 <paulk-desktop> ???
Dec 04 20:45:29 <GNUtoo> so when I did opkg upgrade not a lot was upgraded
Dec 04 20:45:40 <paulk-desktop> is it the reason why telephony doesn't work?
Dec 04 20:45:46 <GNUtoo> maybe
Dec 04 20:45:54 <GNUtoo> because maybe it's fixed in master
Dec 04 20:46:06 <GNUtoo> and I didn't build it yet
Dec 04 20:47:17 <mrmoku> JaMa|Off: hmm... how do you want it?
Dec 04 20:47:29 <mrmoku> I have wgetpaste problems... guess it's the spamfilter
Dec 04 20:47:46 <mrmoku> requires a captcha since some time when the paste contains links
Dec 04 20:47:46 <GNUtoo> building it right now
Dec 04 20:48:30 <mrmoku> JaMa|Off: scp'ed to the buildhost: 0001-subversion-update-1.7.0-to-1.7.1.patch
Dec 04 20:48:31 <JaMa|Off> mrmoku: then feel free to push it to shr branch in oe-core and PV update in meta-smartphone/master
Dec 04 20:48:37 <JaMa|Off> ok :)
Dec 04 20:48:43 <mrmoku> :)
Dec 04 20:48:53 <angelox|laptop> sry, anyone: what are palm devices's code names? (machine names) 
Dec 04 20:51:41 <JaMa|Off> mrmoku: now feel free to revert "don't assume subversion-native" in oe-core if you need to start build
Dec 04 20:51:55 <JaMa|Off> mrmoku: it will use 1.7.1 from shr-chroot
Dec 04 20:52:16 <mrmoku> JaMa|Off: I tried that too... but it still wanted to build it
Dec 04 20:52:55 <JaMa|Off> mrmoku: and if you add ASSUME_PROVIDED += "subversion-native" to conf/local.conf too?
Dec 04 20:53:53 <mrmoku> will try
Dec 04 20:53:58 <JaMa|Off> mrmoku: in worst case remove BBCLASSEXTEND from all 3 versions
Dec 04 20:54:22 <JaMa|Off> mrmoku: and it should be fine without it or at least say what's pulling it in
Dec 04 21:03:02 <JaMa|Off> mrmoku: done... pushing now
Dec 04 21:08:16 <mrmoku> JaMa|Off: looks like adding it to local.conf did help
Dec 04 21:08:18 <mrmoku> it is building :)
Dec 04 21:10:10 <CIA-69> SHR: 03Martin.Jansa 07meta-smartphone * r66775c7dd39b 10/meta-shr/conf/distro/include/preferred-shr-versions.inc: meta-shr: prefer newer subversion 1.7.1
Dec 04 21:12:04 <JaMa|Off> bbl
Dec 04 21:14:01 * mrmoku off 
Dec 04 21:22:48 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * r73b647d7064a 10aurora/aurora-daemon/src/applications/ (Makefile.am app-about/About.qml): aurora-daemon: about: add app-about to Makefile
Dec 04 21:22:52 <CIA-69> freesmartphone.org: 03barklome 07settings-rework * r322210d2ec0f 10aurora/aurora-daemon/data/theme/icons/ (Makefile.am apps/about.svg): aurora-daemon: about: add provisory icon
Dec 04 21:51:10 <leirbag> 500ms to init a SD card by linux ... it's slow :P
Dec 04 23:55:08 <karl223> no n900 yet (later today or tomorrow). I was looking into how fsoaudiod to get a picture. What I wanted to ask is following...
Dec 04 23:58:00 <karl223> will duck_on mute a audio stream if another one does have a higher priority, does it lower the volume of a stream or does it depend on a config somewhere?
Dec 04 23:58:44 <karl223> (i'll reads chatlogs later)
**** ENDING LOGGING AT Mon Dec 05 02:59:58 2011