**** BEGIN LOGGING AT Wed Sep 14 02:59:57 2011
Sep 14 08:17:21 <Snafflehog> Morning all, where can I find the patches that have been applied to a specific build, I want to check if a certain patch is applied to the beagleboard build
Sep 14 10:28:23 <Snafflehog> I've been following scott rifenbarks guide for kernel development and I have managed most of it however I do not know where to specify that poky should use the local git repository that I have cloned
Sep 14 10:32:08 <bluelightning> Snafflehog: that would be in your kernel recipe's SRC_URI
Sep 14 10:32:15 <bluelightning> (I would think)
Sep 14 10:32:25 <dongxiao> it seems that poky@yoctoproject.org doesn't work?
Sep 14 10:38:25 <bluelightning> dongxiao: hmm, you may be right :/
Sep 14 12:33:32 <Snafflehog> Ok, so to patch the beagleboard kernel properly, I would go through this process: clone poky-git, checkout bare yocto-kernel, clone new checked out kernel, branch the kernel to work on custom beagleboard, make new machine to use local kernel, finally compile?
Sep 14 12:45:14 <Snafflehog> I then get a bit confused by this bit: In a layer, create a linux-yocto_git.bbappend file (http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html) - what does it mean by in a layer, which layer specifically or is it any layer?
Sep 14 12:45:35 <Snafflehog> Should it not be in the linux recipe?
Sep 14 12:51:43 <bluelightning> Snafflehog: so, ideally these customisations would be in the form of a bbappend file in your own layer
Sep 14 12:52:23 <bluelightning> that way they remain independent of the original recipe, so if that is updated you avoid problems with merging
Sep 14 12:52:29 <bluelightning> (among other things)
Sep 14 12:52:30 <Snafflehog> ok, I've got: meta-custom/recipes-kernel/linux/linux-yocto_git.bbappend - as mentioned in the manual
Sep 14 12:52:45 <GNUtoo|work> hmmm
Sep 14 12:52:50 <GNUtoo|work> hi
Sep 14 12:52:51 <Snafflehog> is that right, or should my bbapend be somewhere else
Sep 14 12:53:00 <GNUtoo|work> I've a problem with liboil:
Sep 14 12:53:07 <GNUtoo|work> | math_vfp_asm.S:107: Error: selected processor does not support `fldmias r1!,{s0}'
Sep 14 12:53:30 <bluelightning> Snafflehog: that sounds right, is it meant to be _git though?
Sep 14 12:53:32 <GNUtoo|work> my target is an armv6
Sep 14 12:54:09 <GNUtoo|work> -march=armv6 -mthumb-interwork -mfloat-abi=softfp -mtune=arm1136jf-s -mthumb-interwork -mno-thumb is used for compiling math_vfp.c
Sep 14 12:54:42 <GNUtoo|work> if I put to hardfp it fais during do_configure because it tries to mix soft and hard fp
Sep 14 12:54:50 <GNUtoo|work> shouldn't armv6 be hardfp?
Sep 14 12:54:58 <bluelightning> Snafflehog: ok so that part is probably out of date (depending on what version of Yocto you are currently using), either way it needs to match up with a .bb file under meta/recipes-kernel/linux/
Sep 14 12:56:21 <GNUtoo|work> is there some docs about softfp vs hardfp? maybe in debian wiki
Sep 14 12:56:26 <GNUtoo|work> I'll look
Sep 14 12:58:25 <Snafflehog> bluelightning: there is no _git .bb in the meta/recipes-kernel/linux so should it be named linux-yocto_2.6.37.bbappend
Sep 14 12:59:43 <bluelightning> Snafflehog: yes I think so
Sep 14 12:59:50 <GNUtoo|work> ah soft != softfp....
Sep 14 13:00:00 <GNUtoo|work> I tought they were the same but they are not
Sep 14 13:00:40 <Snafflehog> softfp is hard fp with a soft compatibility I believe, like a hybrid (don't quote me on that)
Sep 14 13:00:48 <GNUtoo|work> yes indeed
Sep 14 13:00:52 <GNUtoo|work> http://wiki.debian.org/ArmHardFloatPort/VfpComparison
Sep 14 13:04:12 <GNUtoo|work> aha
Sep 14 13:04:13 <GNUtoo|work> #if defined(__VFP_FP__) && !defined(__SOFTFP__)
Sep 14 13:04:42 <GNUtoo|work> ** compile with -mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp
Sep 14 13:04:43 <GNUtoo|work> hmmm
Sep 14 13:04:57 <Snafflehog> bluelightning: ok, so I followed the manual as clsoe as I could and it says there is not a valid machine set in the local.conf - where do I specify that I want it to use he local kernel I have downloaded?
Sep 14 13:05:23 <Snafflehog> which has the new machine branch
Sep 14 13:05:41 <GNUtoo|work> I guess I need arm vfp docs
Sep 14 13:05:43 <bluelightning> Snafflehog: so, er, those are two separate problems I think
Sep 14 13:06:11 <bluelightning> Snafflehog: MACHINE in local.conf must match up with a file in conf/machine, whether that's within your layer or one of the base layers
Sep 14 13:06:39 <Snafflehog> ok, so I need a new machine conf to match my cutom machine in meta-custom - that makes sense
Sep 14 13:06:49 <bluelightning> yeah I think you will
Sep 14 13:07:12 <bluelightning> for pointing the kernel recipe at your local checkout, in your bbappend you will need to specify your own value for SRC_URI
Sep 14 13:07:37 <bluelightning> (disclaimer, I haven't read the kernel guide closely)
Sep 14 13:08:20 <bluelightning> if there are things missing from the manual I'm sure scottrif will be happy to fix them though
Sep 14 13:08:56 <Snafflehog> ok thanks, one last thing in the machine it says prefferred_provider_virtual_kernel - should I set this to linux-yocto_2.6.37 to make sure it uses my specific kernel build
Sep 14 13:08:57 <bluelightning> so, you are using a different MACHINE value? I.e. not beagleboard?
Sep 14 13:09:14 <Snafflehog> i've created a beagle-custom machine
Sep 14 13:09:33 <Snafflehog> which I want to point to my beagle-custom branch of the kernel
Sep 14 13:09:45 <bluelightning> well, the PREFERRED_PROVIDER would be linux-yocto with no version, then you'd set PREFERRED_VERSION
Sep 14 13:10:00 <bluelightning> but I think linux-yocto and 2.6.37 are the defaults anyway
Sep 14 13:10:28 <Snafflehog> yes 2.6.37 is the default, I didn't realise there was also a preffered_version as it is not documented in the machine.conf file
Sep 14 13:10:56 <bluelightning> hmm... is that what our manual is recommending? it sounds like it will make more work
Sep 14 13:10:56 <Snafflehog> so I could set prefferred_version to 3.0.4 if I wanted to build the latest?
Sep 14 13:11:43 <bluelightning> you can set PREFERRED_VERSION to match PV from the recipe to be built, so if you set 3.0.4 there must exist a linux-yocto_3.0.4.bb
Sep 14 13:12:11 <Snafflehog> ok
Sep 14 13:12:24 <bluelightning> plus FYI I think because these recipes build from git they set their own PV, thus you'd need to set PREFERRED_VERSION to something like "3.0.4+git%"
Sep 14 13:12:29 <bluelightning> % being a wildcard
Sep 14 13:12:33 <Snafflehog> ok
Sep 14 13:13:20 <Snafflehog> it does seem a very long winded process, as all I want to do is apply a patch to the 2.6.37 kernel
Sep 14 13:16:49 <bluelightning> yes
Sep 14 13:17:05 <bluelightning> Snafflehog: have you spoken to tomz or dvhart about this at all?
Sep 14 13:17:27 <Snafflehog> no, what is the best way to contact them, email or ping them here?
Sep 14 13:17:43 <bluelightning> Snafflehog: they both hang out here, in US daytime
Sep 14 13:18:28 <bluelightning> Snafflehog: thinking about it though, if you're just applying one patch I think all you need to do is add it to the end of SRC_URI in your bbappend
Sep 14 13:19:09 <Snafflehog> yes I'm looking at other options now because my beagle-custom won't buld x-load as the configuration for it is not linked
Sep 14 13:19:28 <bluelightning> yeah for what you want to do I think the new MACHINE is overkill
Sep 14 13:19:32 <Snafflehog> so I would have to copy all the configs for all the programs to work on beagle-custom
Sep 14 13:19:50 <bluelightning> well, there aren't too many but yes you'd need to
Sep 14 13:19:58 <Snafflehog> could I point at the beagleboard machine
Sep 14 13:20:13 <Snafflehog> then in my bbappend file specify my beagle-custom kernel branch?
Sep 14 13:20:18 <bluelightning> I would just stick with MACHINE = "beagleboard" yes
Sep 14 13:20:32 <bluelightning> so your bbappend should consist of:
Sep 14 13:20:59 <bluelightning> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
Sep 14 13:21:34 <bluelightning> SRC_URI_append_beagleboard = " file://mypatch.patch"
Sep 14 13:22:23 <bluelightning> and then as long as mypatch.patch appears in a linux-yocto/ subdir under where the bbappend file is then all will be well
Sep 14 13:24:50 <Snafflehog> is there anyway I can output to the console so I know it's reading my .bbappend?
Sep 14 13:26:09 <Snafflehog> I have the following set: meta-custom/recipes-kernel/linux/patch/spi.patch and meta-custom/recipes-kernel/linux/linux-yocto_2.6.47.bbappend
Sep 14 13:26:32 <Snafflehog> with the patch settings you suggested in the .bbappend
Sep 14 13:26:53 <Snafflehog> and the layer is also added to my builds bblayers.conf
Sep 14 13:32:12 <bluelightning> Snafflehog: you mean 2.6.37 in the above path right?
Sep 14 13:32:38 <bluelightning> FYI in recent versions bitbake will error out if it finds a bbappend with no matching recipe
Sep 14 13:33:02 <bluelightning> "bitbake-layers show_appends" will list appends being used
Sep 14 13:33:32 <bluelightning> that's no guarantee their contents are being used, however bitbake -e can be used to inspect the variables you've set (just SRC_URI in this case)
Sep 14 13:33:53 <Snafflehog> yes .37 was what i meant
Sep 14 13:35:25 <GNUtoo|work> hmmm I'm progressing with the vfp issue....modifying CCAS and adding -mfpu=vfp inside makes it compile when using the problematic Makefile with exported path to use oe compiler
Sep 14 13:41:06 <GNUtoo|work> ok that seem to fix it:
Sep 14 13:41:13 <GNUtoo|work> export CCASFLAGS="${CFLAGS} -mfpu=vfp"
Sep 14 13:43:17 <Snafflehog> bluelightning: the bitbake-layers does not list my append, I have the layer in my bblayers.conf - the only error I get is that : Parsing recipes..WARNING: No bb files matched BBFILE_PATTERN_custom '^/mnt/yocto/poky/meta-custom/'
Sep 14 13:43:17 <Snafflehog> done.
Sep 14 13:43:54 <bluelightning> Snafflehog: can you pastebin your layer.conf file for your custom layer?
Sep 14 13:45:00 <Snafflehog> http://pastebin.com/wsP5D7iD
Sep 14 13:49:46 <bluelightning> Snafflehog: ah, thought so... your BBFILES needs this on the end also: ${LAYERDIR}/recipes-*/*/*.bbappend
Sep 14 13:50:08 <bluelightning> Snafflehog: was that an example you copied from somewhere?
Sep 14 13:50:23 <Snafflehog> yes, from the meta-skeleton, it makes perfect sense
Sep 14 13:51:37 <bluelightning> Snafflehog: hmm ok so that needs updating
Sep 14 13:52:22 <Snafflehog> yes, as it's found the bbappend fine now - just compiling and will update if it picks it up
Sep 14 13:56:20 <Snafflehog> bluelightning: it has found the bb append file, bitbake -e picks up the new SRC_URI however the kernel did not get re-compiled on build - is there a make clean or something similar I should be running to force it to pick up changes?
Sep 14 13:57:25 <bluelightning> Snafflehog: bitbake won't rebuild something it's already built automatically unless the version changes (i.e. PR, PV, and PE in some cases)
Sep 14 13:57:41 <bluelightning> Snafflehog: you can do bitbake -c clean virtual/kernel then bitbake virtual/kernel
Sep 14 13:57:46 <bluelightning> to force it
Sep 14 13:58:33 <Snafflehog> ok, I knew I had used clean before but had forgotten the syntax
Sep 14 14:02:54 <otavio> Hello
Sep 14 14:03:50 <Snafflehog> hi
Sep 14 14:03:52 <otavio> RP__: sgw: it would be important to me to get  qt 4.7.4 merged since I am working at fixing the translation support of it but will have to handle with conflicts on them if it is not merged before
Sep 14 14:06:40 <Snafflehog> bluelightning: i have now run into issues with kernel config options not being set in the compile, could this be to do with a syntactically incorrect bbappends?
Sep 14 14:07:21 <bluelightning> Snafflehog: you mean the warning produced by do_check_config (or similar name)?
Sep 14 14:07:48 <Snafflehog> http://pastebin.com/g7WtU3Ft
Sep 14 14:14:46 <bluelightning> Snafflehog: hmm, I know we do have these warnings by default, I don't think it's anything for you to worry about given that you haven't modified the actual kernel config (which is what it's referring to)
Sep 14 14:15:37 <Snafflehog> bluelightning: ok, I've never specifically seen the kernel being built so I wasn't sure if it was out of the ordinary or not
Sep 14 14:17:02 <bluelightning> ok
Sep 14 14:17:10 <bluelightning> ideally we would not have any warnings out of the box
Sep 14 14:21:51 <Snafflehog> cd ..
Sep 14 14:28:15 <Snafflehog> ls
Sep 14 14:29:21 <Snafflehog> bluelightning: ok, this patch doesn't seem to have been applied - is there a way to compile the current work dir into a bootable image for example:
Sep 14 14:29:41 <Snafflehog> patch the kernel work dir
Sep 14 14:29:55 <Snafflehog> bitbake -c compile linux-yocto
Sep 14 14:30:10 <Snafflehog> bitbake -c compile image-core-minimal
Sep 14 14:30:50 <Snafflehog> and that at least I could check that the patch is working as it should and narrow the issue down to one with the automatic build process
Sep 14 14:30:59 <bluelightning> Snafflehog: so, if you've cleaned linux-yocto, then just bitbake core-image-minimal, it will rebuild the kernel and then rebuild a new image
Sep 14 14:31:12 <bluelightning> images are special because they have the date in the output file, so they always rebuild
Sep 14 14:31:47 <bluelightning> Snafflehog: how do you know it hasn't been applied
Sep 14 14:31:49 <bluelightning> ?
Sep 14 14:32:02 <Snafflehog> so I could patch the linux-yocto in the work dir and then bitbake -c compile linux-yocto and that would compile the image file too?
Sep 14 14:32:24 <Snafflehog> The patch implements the SPI interface on the beagleboard and the /dev/spi* interfaces are not created
Sep 14 14:34:49 <bluelightning> you could yes, but it would be better to figure out why this patch file hasn't been added because that should work just fine
Sep 14 14:34:56 <zeddii> is this yocto 1.0 ? or a 1.1 -rc ? patching linux-yocto via a bbappend is no different than any other package. If I can see the bbappend, it might be clear what's wrong.
Sep 14 14:35:34 <bluelightning> zeddii: hi bruce
Sep 14 14:35:35 <Snafflehog> zeddii: http://pastebin.com/19TXGyKa
Sep 14 14:35:41 <Snafflehog> that is the bbappend file
Sep 14 14:36:10 <zeddii> and you've got the patch in a plain old 'linux-yocto' subdir ?
Sep 14 14:36:30 <Snafflehog> meta-custom/recipes-kernel/linux/linux-yocto
Sep 14 14:36:44 <Snafflehog> it shows as SRC_URI in bitbake -e
Sep 14 14:36:51 <Snafflehog> so it is picking the patch up
Sep 14 14:37:01 <Snafflehog> 5
Sep 14 14:37:14 <Snafflehog> yocto
Sep 14 14:37:41 <Snafflehog> sorry, this window is stealing my terminal focus those should have been sent ^^
Sep 14 14:37:57 <zeddii> and you see the patch in tmp/work/beagleboard-poky*/linux-yocto-3.0*/
Sep 14 14:38:26 <Snafflehog> its 2.6.37 but yes the patch is in there
Sep 14 14:38:47 <Snafflehog> this is the patch: http://pastebin.archlinux.fr/434036
Sep 14 14:38:50 <zeddii> where's the spi.patch ? can I see it ? is it a proper git am-able patch ?
Sep 14 14:38:51 <zeddii> hehe
Sep 14 14:38:53 * zeddii looks
Sep 14 14:40:43 <zeddii> give my machine a minute to wheeze to life. I'll toss that in over here and do a quick test. if it's failing and you aren't being told, there may be a missing exit code catch, etc.
Sep 14 14:41:01 <Snafflehog> ok thanks
Sep 14 14:41:16 * zeddii is still watching recipes parse
Sep 14 14:41:41 <Snafflehog> if it does get working then this is a patch that should be applied to the 2.6.37 beagle kernel anyway - it may already be in 3.0 i'm not sure
Sep 14 14:42:26 <zeddii> definitely. I'll let you know ASAP. you'll be around for a few more minutes ?
Sep 14 14:42:50 <zeddii> I'm actually cleaning linux-yocto now .. I remind myself not to rush the disk :)
Sep 14 14:42:57 <Snafflehog> yep around for a couple of hours yet (unfortunatly ;) )
Sep 14 14:43:46 <Snafflehog> do you also work at intel?
Sep 14 14:43:50 <zeddii> cool. I've got the patch and the bbappend. I'll toss it in here and see what it does. easier than pontificating endlessly about it. it is supposed to be a one-liner to add something like this.
Sep 14 14:44:09 <zeddii> Wind River for me.
Sep 14 14:44:25 <zeddii> grah. toolchain build.
Sep 14 14:44:31 * zeddii remembers patience again.
Sep 14 14:45:00 <Snafflehog> ah I'm in the UK, so over the pond then I assume
Sep 14 14:45:21 <zeddii> yep. I'm a canadian savage.
Sep 14 14:45:45 <Snafflehog> hehe
Sep 14 14:49:42 <Snafflehog> do you have a beagle to test with or are you just watching for errors in the compile?
Sep 14 14:52:16 <zeddii> I've got a beagle here, but I'll get it building first and let you know.
Sep 14 14:52:23 * zeddii is at gcc-intermediate now.
Sep 14 15:13:11 <kergoth> anyone else seen pseudo not functioning correctly, recently? This wasn't occurring before updating my layer yesterday. Now anything that tries to do something it doesn't have the rights to dies off, which means 5-10 recipes from a minimal image choke and die in do_install
Sep 14 15:13:16 <kergoth> s/layer/layers/
Sep 14 15:29:34 * zeddii is built .. now needs to add the patch.
Sep 14 15:32:02 <bluelightning> halstead: do you have any news on when the mailing lists will be back up?
Sep 14 15:37:35 <otavio> RP__: I can prepare the amended patches for qt 4.7.4 and send to mailing list with an updated pull request. Do you mind?
Sep 14 15:40:06 <Snafflehog> zeddii: any luck or still chugging away?
Sep 14 15:53:58 <sgw> morning all
Sep 14 15:54:45 <zeddii> Snafflehog, chugging. I'll know in about 10 minutes. I had to search for food in the middle.
Sep 14 15:55:15 <zeddii> I just created my own custom layer, added it and your patch, and am building now. (my toolchain build finally finished).
Sep 14 15:55:49 <Snafflehog> good stuff
Sep 14 16:00:51 <zeddii> I must have messed up my layer conf. bitbake ignored my patch (i.e. nothing to do with the kernel recipes), I'm double checking now.
Sep 14 16:03:45 <Snafflehog> I had to add an extra line to my layers.conf so it would pick up the bbappend file, is that it?
Sep 14 16:04:23 <Snafflehog> BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
Sep 14 16:04:23 <Snafflehog>             ${LAYERDIR}/recipes-*/*/*.bbappend"
Sep 14 16:05:13 <zeddii> could be, I threw it together quickly.
Sep 14 16:05:17 * zeddii checks
Sep 14 16:05:40 <zeddii> ah yes.
Sep 14 16:05:43 <zeddii> I only had .bb
Sep 14 16:10:36 <zeddii> Snafflehog, are you working out of master ?
Sep 14 16:10:47 <Snafflehog> yes the latest git
Sep 14 16:11:17 <zeddii> ok. so of course it worked fine here. but I did it in meta-yocto. I'm switching back to my custom layer and will try once more.
Sep 14 16:11:35 <zeddii> you should see this: http://pastebin.com/eDPpgwLq
Sep 14 16:11:46 <zeddii> as your top commit in the 'linux' subdir.
Sep 14 16:13:14 <Snafflehog> if poky/ is my top directory where about would it be from there?
Sep 14 16:14:13 <zeddii> for me: build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-2.6.37+git5+aeea99683c7283f1f3320bf2ee7085ee252d4e7e_2+3ddb22772862a8223640fa97580569924f51bddc-r21/linux
Sep 14 16:14:28 <sgw> zeddii: ping
Sep 14 16:14:39 <zeddii> pong.
Sep 14 16:15:12 <sgw> zeddii: Just wanted to check in with you is there going to be any kernel patches for RC2 or RC3?
Sep 14 16:15:25 <Snafflehog> how do you see the commits in git?
Sep 14 16:16:45 <Snafflehog> anyway mate, i'm at work and we're closing up - if you get me on email then we can keep discussing as I'm keen to get this resolved, i'll PM you my email.
Sep 14 16:17:22 <zeddii> sgw. a few config changes. I'm trying to get a pull request out early this afternoon. I'm fighting with infrastructure a bit.
Sep 14 16:17:49 <zeddii> Snafflehog, sounds good. will let you know.
Sep 14 16:19:27 <sgw> zeddii: early would be good, we are going to start the RC2 build around 1pm PST.
Sep 14 16:22:47 <zeddii> ok. I'm rushing!
Sep 14 16:22:55 * zeddii scramble madly!
Sep 14 16:22:58 <zeddii> :)
Sep 14 16:40:05 <msm> is there a way to build up a cache for hob so it does not need to go through the "loading…" everytime you start?
Sep 14 16:41:16 <incandescant> we didn't have a good handle on cache requirements and invalidation so it didn't make it for 1.1, sorry
Sep 14 16:41:29 <msm> incandescant: no problem
Sep 14 16:41:34 <msm> just curious...
Sep 14 16:42:55 <incandescant> msm: clearly we need it! We are worried about serving up stale data, though...
Sep 14 16:43:28 <msm> yes, no point in rushing though if it's not ready
Sep 14 17:51:42 <kergoth> this site.conf version is just idiotic. my site.conf isn't based on the sample at all, and the sample is EMPTY. an empty file isn't changing something "incompatibly"
Sep 14 18:21:05 <sgw> zeddii: ping
Sep 14 19:19:54 <msm> anyone have any idea why im seeing ERROR: cannot map 'allarch' to a linux kernel architecture
Sep 14 19:21:10 <msm> seems like I need to limit my kernel recipe somehow, not sure what is appropriate
Sep 14 19:21:42 <msm> if I do COMPATIBLE_MACHINE = "(machine_name)" it goes away, i did not want to explictly list all machines it was compatible with… or is this standard practice?
Sep 14 19:31:41 <zeddii> msm we typically have to list all the compatible machines, otherwise "bad things happen".
Sep 14 19:32:52 <msm> hmmm, ok
Sep 14 19:43:36 <msm> ok so i was wrong this message 'ERROR: cannot map 'allarch' to a linux kernel architecture' is not going away
Sep 14 19:43:45 <msm> i must not have cleared the cache right before
Sep 14 19:56:09 <msm> aha
Sep 14 19:56:11 <msm> typo
Sep 14 19:58:41 <msm> maybe
Sep 14 19:58:50 <msm> in meta/classes/sanity.bbclass
Sep 14 19:59:01 <msm> is TARGE_ARCH supposed to be TARGET_ARCH?
Sep 14 19:59:25 <msm> but then the check does not make sense, because I think they should always be eual
Sep 14 19:59:30 <msm> equal*
Sep 14 20:00:31 <incandescant> that does look like a typo, but I can't speak to the validity of the check
Sep 14 20:01:37 <msm> it looks like target arch can be TUNE_ARCH, allarch, SDK_ARCH, BUILD_ARCH, etc
Sep 15 01:30:47 <Guest85296> hello
Sep 15 01:38:59 <khem> yes Guest85296
Sep 15 01:40:26 <Guest85296> hey
Sep 15 01:40:33 <Guest85296> u there?
**** ENDING LOGGING AT Thu Sep 15 02:59:57 2011