**** BEGIN LOGGING AT Thu Feb 04 02:59:57 2010 Feb 04 06:49:33 hi, any tips to solve the "sudo: must be setuid root" issue when running "sudo" command in a chroot+qemu-arm-static environment? Feb 04 06:52:17 * persia tests Feb 04 06:53:13 Well, it doesn't happen in my lucid armel chroot (on amd64), so I wonder if there is some other factor involved. Feb 04 06:53:26 What does `ls -l /usr/bin/sudo` show? Feb 04 06:53:51 it's of correct attribute Feb 04 06:54:24 -rswr-xr-x ? Feb 04 06:54:25 -rwsr-xr-x 2 root root 98880 Jan 29 15:29 /usr/bin/sudo Feb 04 06:54:47 the problem, I think, is in /usr/bin/qemu-arm-static Feb 04 06:54:56 is it? Feb 04 06:55:04 Hrm. I saw this before when the rootfs data had been copied in and out of a FAT32 filesystem, but that's not your issue.] Feb 04 06:55:21 Well, I'd agree, except that I don't get that message :) Feb 04 06:55:33 How did you construct your chroot? Feb 04 06:55:50 build-arm-chroot lucid Feb 04 06:56:09 I chroot this arm rootfs in a x86 PC Feb 04 06:56:32 so "sudo" after "chroot" is executed via qemu-arm-static actually Feb 04 06:56:55 Indeed. Feb 04 06:57:18 Looking at build-arm-chroot, I don't know of any reason that command wouldn't build the chroot you expect. Feb 04 06:57:33 so, do you mean you could run sudo command correctly in such a chroot env? Feb 04 06:57:39 I'm on amd64. Are you on i386? I wonder if that might be a difference. Feb 04 06:58:06 y Feb 04 06:58:37 I'm running Karmic on i386 Feb 04 06:59:35 In that case, I'm inclined to agree with you that it's qemu-arm-static, as that seems to have been changed between karmic and lucid. Feb 04 06:59:47 I tried chroot into an "installed arm rootfs from livecd" as well. same error. Feb 04 06:59:48 build-arm-chroot is the same. Feb 04 07:01:12 so I don't think it's caused by build-arm-chroot. Feb 04 07:01:44 Neither I, as my chroot is also created by build-arm-chroot (albeit embedded from another script) Feb 04 07:02:49 Anyone else using build-arm-chroot with Karmic? Do you get the error eggonlea mentions? Feb 04 07:06:51 persia, what's your Ubuntu version on amd64? Feb 04 07:07:22 lucid Feb 04 07:07:27 Upgraded just a few hours back. Feb 04 07:07:58 I don't recommend this for production use unless you're prepared to get two pieces when it breaks, but it's a good way to check to make sure one's preferred bugs get fixed. Feb 04 07:08:13 * eggonlea testing in Lucid/vmware Feb 04 07:08:40 Now there's an idea! Feb 04 07:09:21 If you see a difference, file a bug clearly indicating that it doesn't work in karmic and it does work in Lucid. I'm not sure we can get an update, but a backport is likely possible if a few people can test. Feb 04 07:19:09 * eggonlea hates the slow network... Feb 04 07:19:24 Indeed. Feb 04 07:52:26 same error in lucid/vmware + build-arm-chroot/qemu-arm-static Feb 04 07:56:08 Very odd. I wonder why I don't get the error. Feb 04 07:57:02 Please file a bug about this (`ubuntu-bug qemu-kvm`) Feb 04 07:57:15 do you have i386 host? Feb 04 07:57:16 ok Feb 04 07:58:31 I don't. Just amd64. Feb 04 08:09:01 bug filed. Feb 04 08:09:11 thanks for your kindness. Feb 04 14:16:10 persia: Great to see qemu-arm-static support in ubuntu-dev-scripts! You might want to test for presence of build-arm-chroot instead of checking whether the arch is either i386 or amd64 (error would then be "you need the qemu-arm-static package..." and you could use a suggests instead of recommends); BTW the package just got renamed to qemu-kvm-extras-static Feb 04 16:12:06 asac: hi Feb 04 18:05:44 lool: I did in mk-sbuild-lv. I'm not as sure how to do that with pbuilder-dist. I'd appreciate a hand if you have any ideas. Feb 04 18:10:20 persia: Sure Feb 04 18:10:26 persia: I thought you implemented that though? Feb 04 18:12:31 python != shell :) Feb 04 18:12:52 Plus, the logic in pbuilder-dist is particularly opaque to me. Feb 04 18:13:07 (plus I don't use pbuilder, which makes verification interesting) Feb 04 18:22:23 persia: Sorry, to clarify: you're more confortable writing shell than python and you would prefer me to improve the logic in pbuilder-dist; correct? Feb 04 18:22:59 dmart: asac is travelling in the west coast; might be easier to email him Feb 04 18:23:04 lool: please :) Feb 04 18:23:18 lool: I did... not urgent anyway. Thanks Feb 04 18:24:08 dmart: hi Feb 04 18:24:17 Oh, hi there Feb 04 18:24:23 what can i do ;)? Feb 04 18:24:26 how's the sprint? Feb 04 18:24:36 lool: He isn't travelling, he's at the sprint, and has been for 4 days Feb 04 18:24:48 quite good ... some crisis here and there ;) ... but we seem to have a good new lead on dove Feb 04 18:24:52 will know more soon Feb 04 18:25:47 StevenK: He is not at home, so he is on travel for work, hence travelling; sorry if my English explanations suck, but the effect is the same :-) Feb 04 18:26:36 * persia blames the awkwardnesses of English spelling and grammar Feb 04 18:27:19 at least it's not C++ grammar Feb 04 18:27:20 :P Feb 04 18:27:23 Haha Feb 04 18:27:37 At least that's documented in a single way :) Feb 04 18:28:04 * StevenK laments his lack of C++ to make a joke that builds on dmart's joke Feb 04 18:28:07 C++? haha Feb 04 18:28:53 dmart: wonder ... could you add examples or give pointers how to properly do the "mov" fixes for thumb2 Feb 04 18:28:56 ? Feb 04 18:29:10 would like to get the thumb2 list down a bit more this week Feb 04 18:30:36 I had some thoughts about that... did you get a chance to look at the stuff on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto Feb 04 18:30:57 It still rather incomplete, but progressing gradually. Feb 04 18:31:58 I've tried to keep the amount of extra information down, but it may still be quite indigestible to a newcomer. Feb 04 18:33:17 I was thinking maybe we should schedule a sort of mini-sprint with some mobile team guys sometime next week... the best way to get people up to speed may be for everyone to pick up a package and try to work out how to fix it... then watch the discussion on IRC. Feb 04 18:33:44 Does that sound like a good idea? Feb 04 18:35:02 dmart: no ... didnt know that page exists Feb 04 18:35:04 * asac checks Feb 04 18:35:31 looks like a good start Feb 04 18:35:34 will check that Feb 04 18:35:39 thanks Feb 04 18:35:41 dmart: ^ Feb 04 18:36:03 dmart: yes. i like the idea of making porting sessions Feb 04 18:36:12 i think we fixed almost all swp ones now Feb 04 18:36:17 (boost upload pending) Feb 04 18:36:26 so mov is the most pressing one left i think Feb 04 18:36:49 Yes... particularly since these don't generally show up as ftbfs, we need to be more careful. Feb 04 18:38:38 OK; I'll probably try and flesh out the missing bits of that wiki page by early next week and we can discuss the way forward at the ubuntu-mobile IRC meeiting. Feb 04 18:40:21 asac: ^ I was trying to look at the evolution-data-server update to help sanity-check, but looking in debian/patches I couldn't find the new patches described in the update. Feb 04 18:40:50 Should I see the patches after apt-get source, or do I actually need to build the package (or look in bzr etc.) Feb 04 18:43:55 dmart: i also committed it to bzr, yes. Feb 04 18:44:06 dmart: you couldnt find the patches? Feb 04 18:44:07 hmm Feb 04 18:44:14 guess i messed that Feb 04 18:44:17 darn ;) Feb 04 18:44:47 I think I have the right package version; debian/changelog mentions the patches Feb 04 18:45:05 I tried a build anyway... it hasn't fallen over yet, but it's not finished... Feb 04 18:45:09 yes Feb 04 18:45:17 i think i failed to add it to bzr Feb 04 18:45:33 darn Feb 04 18:45:54 sigh ... i knew i should have uploaded without doing bzr first Feb 04 18:45:59 guess i have to redo it Feb 04 18:46:28 * asac hopes he still has the build tree somewhere Feb 04 18:46:36 As far as I can tell, if one uploads whilst ignoring bzr, automated systems do the right thing. Feb 04 18:46:55 good still have it in a porter bux Feb 04 18:47:13 persia: i remembered seb wanting me to commit it Feb 04 18:47:17 so i wanted to be nice Feb 04 18:47:21 * asac goes and redoes Feb 04 18:47:24 asac: You might have it in your checkout still Feb 04 18:47:27 or in the package itself Feb 04 18:47:53 Ah no Feb 04 18:47:59 Your debdiff is definitely empty Feb 04 18:48:24 i did the checkout in /tmp/ ;) Feb 04 18:48:32 but i found it on the porter machine :-P Feb 04 18:48:33 \o/ Feb 04 18:49:28 dmart: you can check boost1.40 Feb 04 18:50:18 ok... I'll try and take a look, probably tomorrow. Feb 04 18:51:04 yes Feb 04 18:51:08 make more sense Feb 04 18:51:11 dmart: check boost1.40 Feb 04 18:51:15 i think thats uploaded ;) Feb 04 18:51:24 ok, will do Feb 04 20:29:36 hi all, I'm looking for some information about running openjdk on ARM, does anybody here have links to some info on this (are there binary packages available for it, etc..)? Feb 04 20:39:42 Marrs: https://launchpad.net/ubuntu/+source/openjdk-6 Feb 04 20:40:04 Marrs: The latest lucid version is still building on armel, but yes, there are usually binaries available for armel Feb 04 20:40:49 There's been a couple reports about some code paths causing VM issues, so heavy testing and reporting of any issues would be very welcome. Feb 04 20:40:52 ideally, I'm looking for a stable binary release, so that would be the karmik one? Feb 04 20:41:04 karmic that is :) Feb 04 20:41:31 persia: I'm definitely going to try to kick its tires :) Feb 04 20:42:31 karmic is a stable binary release, but if you find issues, those are easier to fix in lucid (and moreso if previously verified in lucid). Feb 04 20:42:51 I'd recommend starting with karmic, and maybe testing against lucid in a chroot if you encounter issues. Feb 04 20:42:57 persia: understood Feb 04 20:43:40 btw, I'm not so experienced in the ARM architecture, I'm more of a Java guy, could you take a look at this ARM based board and tell me if you think it will run openjdk? (looking up link now..) Feb 04 20:44:00 Better question is whether it can run Ubuntu, and which releases :) Feb 04 20:44:16 Running OpenJDK is mostly a side-effect of that. Feb 04 20:44:44 fair enough... supplier says it can run ubuntu, I have yet to find out which version, but this is the board: http://www.msc-ge.com/de/produkte/com/exm32/3640-www.html Feb 04 20:45:55 whoops, that was the german page, hit the english flag in the top right corner for an instant translation ;) Feb 04 20:46:21 Deutsh ist also gut. Feb 04 20:46:26 * persia can't spell today Feb 04 20:46:36 ;) ok Feb 04 20:47:56 I'd recommend against this one. I think it can run Jaunty with a custom kernel, but it wouldn't be able to run karmic or lucid. Feb 04 20:48:25 ouch :( Feb 04 20:48:32 what's the main problem? Feb 04 20:50:53 or, what type of board should I look for Feb 04 20:56:40 You want something that can handle the ARMv7 ISA. Feb 04 20:57:04 So, if looking at something using an i.MX processor, you'll want at least the i.MX51. Feb 04 20:57:49 There's also stuff from other vendors, of course :) Feb 04 20:59:25 ok Feb 04 21:03:35 if you have any links to a board you could recommend, that would be welcome Feb 04 21:06:14 Marrs: The boards which are officially supported in Ubuntu kernels aren't that cheap or common, but it's improving quickly; popular boards around here are OMAP 35xx or 34xx based boards e.g. beagleboard Feb 04 21:06:25 beagleboard is probably the one we get the most pinged about Feb 04 21:06:41 thanks Feb 04 21:06:54 I'll look for those and see if we can use them Feb 04 21:16:23 lool: +available Feb 05 00:28:19 I just tried to build a Lucid rootfs with rootstock but it doesn't seem to work when I try and boot it in qemu. rootstock didn't look to finish cleanly but there wasn't a good error message - I dug the image, rootfs and log out of the tmp directory. I was using debotstrap from Karmic, but I got the latest rootstock from launchpad and ran the script locally. Is it surprising it didn't work, or is there something curious going on? Feb 05 00:28:54 i.e, is this a bug I should try and report, or just something that would be expected this early on in the release cycle... Feb 05 00:30:12 Oh, and while I'm here: does anyone else get keyboard and mouse working in X when booting a graphical rootfs in qemu? I don't, and have to ssh in in order to do anything - is that also a bug? Feb 05 00:32:35 who_, the karmic rootstock cant build lucid yet, it needs the patch from http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31 Feb 05 00:33:09 ogra: I used rootstock from trunk in LP: would that have had the patch? Feb 05 00:33:38 yes, that should have it but is in active development atm, i havent tried to build anything with it under karmic Feb 05 00:33:55 it works under lucid Feb 05 00:33:56 (i.e revision 42) Feb 05 00:35:58 ogra: so would my best bet be to use rootstock revision 31? Are you interested in any bug reports atm for using trunk rootstock on karmic? Feb 05 00:36:25 sure, i might want to backport it, but dont expect them to be high prio atm :) Feb 05 00:36:38 rev31 should definately work Feb 05 00:36:43 ogra, just a note rootstock is failing (revision 42 just ran) with --dist lucid "mount: mount point /dev/pts does not exist" i'm guessing the verstaile kernel is missing CONFIG_DEVTMPFS same bug i ran into with the beagle kernel on karmic -> lucid.. Feb 05 00:37:05 rcn-ee, that shouldnt be an issue, its just a warning Feb 05 00:37:39 there is a patch already in the code to use the versatile kernel from the archive under lucid, sadly the kernel package needs fixing first (doesnt boot at all) Feb 05 00:37:42 i was thinking that too, since it worked a week ago, not sure why rootstock is dying shortly after... Feb 05 00:38:03 well, i'm currently actively developing features in trunk :) Feb 05 00:38:13 might be that they introduce new bugs Feb 05 00:38:37 ogra: and about using qemu with X: that's a problem I have with all my rootfs', (ones that work on real hardware...) Feb 05 00:38:44 i saw those, everything looked safe... Feb 05 00:39:35 well, the code surely needs cleanup, i'm currently caring more for shrinking my TODO than having it perfect ... i'll do a deep code review sometime next week Feb 05 00:40:36 btw i plan to add a plugin system that will spit out compete SD card images so you can just use "--board beagle" and will have something that can be dd'ed and booted right away Feb 05 00:41:04 will indeed need people to submit plugins for their HW Feb 05 00:42:13 sounds like a plan, i uploaded the logs here http://rcn-ee.homeip.net:81/dl/rootstock/ ... What prompted it, my alpha-2 lucid image got corrupted on rcn-ee.net.... So, I'm going to cheat and dist upgrade karmic and upload that.. ;) Feb 05 00:42:19 who_, sorry, i dont use qemu with any framebuffer so i cant tell much about that, i guess using an initramfs would help though, suspecting the input drivers you need are modules Feb 05 00:42:20 ogra: that sounds sweet. I will try and do one for IGEPv2 Feb 05 00:43:06 ogra: ok, that's a good starting point for me to get googling on :) - I'm a little new to this level of things. Thanks Feb 05 00:43:55 * ogra commits todays tasksel tool for the rootstock GUI Feb 05 00:44:31 that would be cool.. main thing the beagle's need, is the /etc/e2fsck.conf tweak.. (no real time clock battery) well until util-linux considers that not an error.. Feb 05 00:44:52 final question before I go to bed: Does anyone else find they have a curious bug where, after some unspecified period of time, certain commands stop executing? It's happened to me with a rootfs on SD and one over nfs. Feb 05 00:45:24 After some time (different amounts each time) things like ifconfig, sudo, synaptic stop executing, but things like dmesg, top, xterm, still start fine Feb 05 00:45:48 rcn-ee, i convinced the maintainer to look into it, we finally found an x86 box it occured on, that convinced him ;) Feb 05 00:45:54 so it might be fixed Feb 05 00:46:00 s/be/become/ Feb 05 00:46:08 the system is essentially useless though. If I am connected to a serial terminal I see messages about things being idle 120 seconds... Feb 05 00:46:44 cool the musb port just passed my stress test..., cwillu_at_work, give http://rcn-ee.homeip.net:81/dl/linux-image-2.6.32.7-x7.1_1.0cross_armel.deb a try... (load the beagle at 100% and transfer many gigs..) make sure "dmesg | grep fifo" returns 5... Feb 05 00:47:30 sweet, thanks for that ogra.. i have a couple atmel boards at work that need the same tweak for debian.. ;) Feb 05 00:49:16 who_, i'D file a bug and attach dmesg etc to it, but note that with karmic only armv6 chips are supported, with lucid we even switched to v7 and thumb2 Feb 05 00:51:31 ogra: I'll get a dmesg log onto launchpad. This is an OMAP3, so shouldn't be troubled by the change to v7, as I understand it.. right? Feb 05 00:51:41 right Feb 05 00:52:50 who_, are you still on the 2.6.28 kernel with your IGEPv2? Feb 05 00:53:13 rcn-ee: yea, but I built their latest kernel tonight. Will try it out on the board when I get in tomorrow :) Feb 05 00:53:47 * ogra needs to go now Feb 05 00:54:01 Thanks for the help, ogra :) Feb 05 00:54:34 who_, if you boot lucid, make sure you enable CONFIG_ARM_ERRATA_430973 Feb 05 00:54:52 rcn-ee: thanks. there's no way I'd have got that on my own :) Feb 05 00:55:11 who_, neither me... spent about 2 weeks with dave martin debuggin that one... Feb 05 00:55:26 rcn-ee: is there any ubuntu-on-igep information around other than what's on the igep wiki? Feb 05 00:56:15 well you can follow my beagleboard wiki on elinux... but the kernel is still external.. i don't have that board, but it should be pretty easy to integrate into the kernel builds i already do... Feb 05 00:57:08 rcn-ee: the thing that struck me just now when I looked at the BeagleBoardUbuntu page was that there seems to be a better system for getting SGX video acceleration working on Ubuntu... Feb 05 00:57:12 also you need CONFIG_DEVTMPFS, for lucid ( i couldn't get the beagle to mount with out it..) however it didn't get added to mainline till 2.6.32... Feb 05 00:57:32 rcn-ee: again. thanks :) Feb 05 00:57:47 it should mount thought Feb 05 00:57:57 just spill an error in initramfs Feb 05 00:58:29 there are several safety nets in initramfs's init to make sure it still mounts Feb 05 00:58:43 I'll re-test it, but it errored but never recovered... we still don't use an initramfs on the beagle.. Feb 05 00:59:12 and there's no initramfs for IGEPv2 either... Feb 05 00:59:17 you should start to ;) Feb 05 00:59:33 i know.. ;) on my list too... Feb 05 00:59:36 its just an update-initramfs away :) Feb 05 00:59:45 (and a mkimage indeed :) ) Feb 05 00:59:50 anyway, really off now Feb 05 00:59:56 bye Feb 05 01:00:11 now that we've transitioned to u-boot.scr scripts it's easy to tweak too... Feb 05 01:04:07 rcn-ee: can you tell me a tiny bit about the 'build_sgx_module.sh' script that you've got Feb 05 01:04:29 sure i can, what question do you have.. Feb 05 01:04:36 (I'm looking at http://elinux.org/BeagleBoardUbuntu) Feb 05 01:04:59 2.6-stable.. branch i'm hoping.. Feb 05 01:05:16 rcn-ee: how does it differ from what I'd get if I followed the 'standard' instructions on the TI grpahics SDK? Feb 05 01:06:14 who_, it's very similar now (specially with the current revision) but it isn't tied to a specific TI kernel.. which in the past has been a big problem.. Feb 05 01:07:14 rcn-ee: the reason for my questions is that I'd like to be able to have video acceleration on the IGEPv2 with Ubuntu. All of the docs from ISEE (the board manufacture) are about using it on their poky system with their kernel Feb 05 01:08:18 who_, very similar, i actually used Angstrom's (poky is based off) instructions to originally write the script... Feb 05 01:08:55 rcn-ee: okay, I'll take a look at it when I'm not about to go to bed and see if I can make enough sense of it to use it for my IGEP :) Feb 05 01:10:01 rcn-ee: could you just explain this sentence a bit: "Use the "build_sgx_module.sh" script in 2.6-stable, module source is now in the *.bin " - does that mean "TI now provide the module source in their .bin file so we can build the modules with any kernel we like"? Feb 05 01:11:24 Yeah, with the latest version TI moved the 'external' gpl modules into their SDK.. (they didn't take bug reports since it was external) so now you need the SDK to build the kernel modules, before i actually build them on my chroots at the same time as the *.deb files... Feb 05 01:12:11 it's kinda clugy for ubuntu/debian but users now have to build the kernel modules on their own... (too many pages of license stuff and not enough time for me..) Feb 05 01:12:48 but as long as you have the correct things enabled, you can build it on any 'dss2' enabled kernel... Feb 05 01:17:11 rcn-ee: okay I think I understand. unless I'm using the exact kernel that ISEE used, I'm not likely to have much luck using the modules (binary) they are shipping, right? (they provide omaplfb.ko and pvrsrvkm.ko) Feb 05 01:18:34 who_, that is correct... and those two modules are pretty easy to generate once you have the sdk anyways... just use the script as reference, and you'll get it... Feb 05 01:18:55 but if I am using their kernel (and there aren;t many reasons I can see right now not too..) I should be able to skip the module compilation step and jump to http://elinux.org/BeagleBoardUbuntu#Startup_Script and follow from there? Feb 05 01:19:15 yeap, you can just use theirs... Feb 05 01:19:37 any chance did they have a version on them? Feb 05 01:19:38 rcn-ee: any reason not to use 2.6.28-10? Feb 05 01:20:12 musb bugs... on the beagle.. ;) i think you guys have a good working ehci port correct? Feb 05 01:20:13 rcn-ee: they specify that they're for use with 2.6.28-10 which is what they see as the kernal they are supporting Feb 05 01:20:32 rcn-ee: yea, the usb is stable for us... Feb 05 01:20:51 they had weird version numbers like : 1.3.13.1607 Feb 05 01:21:02 rcn-ee: what did? Feb 05 01:21:08 the kernel modules... Feb 05 01:22:13 rcn-ee: oh, okay. I don't know. they ship them in a folder called kernel-modules-sgx530_3.00.00.09-r0_igep0020b - but that would appear to be of no use ;) Feb 05 01:23:11 okay 3.00.00.09 (1.3.13.1607 was for that) is safe for those directions on elinux... the much older 3.00.00.06 needed other tweaks.. Feb 05 01:24:12 rcn-ee: thanks again. will these modules do anything to accelerate video playback, or do I need to go to the dsp framework for that? Feb 05 01:25:19 who_, by the way, since your using that one.. use this older revision, it gives you a bigger picture of what i did before i wrapped it all up in the script... http://elinux.org/index.php?title=BeagleBoardUbuntu&oldid=16127 Feb 05 01:25:57 who_, nope... just '3D' i've been chewing on the dspbridge, and gst-dsp but haven't got the two to work together yet... Feb 05 01:27:04 i sneak the /usr/bin /usr/lib files into hte modules package when you use the script to make it very easy for users to install... Feb 05 01:28:15 sweet. that old revision is brilliant. thanks. As for DSP bridge, the IGEP wiki _looks_ to haveit documented well here http://wiki.myigep.com/trac/wiki/HowToSetupUseIGEPDSPFramework . I haven't tried it though - I need to start with the basics :P Feb 05 01:29:14 rcn-ee: I have to go to bed now, which is a shame because I'm learning a lot! Feb 05 01:29:39 there's always the next day too.. just keep messing around with it... Feb 05 01:29:41 rcn-ee: thanks for the help... I'm sure I'll be back at some later date to ask some more things :) Feb 05 01:30:46 rcn-ee: yea, I need to get on top of my toolchain so I can iterate things fast :) It's been a frustrating week with 1 dead PSU and the _weird_ bug I described above where the system just starts hanging. Hopefully next week will be full of productive joy :) Feb 05 01:31:36 it pays to have lots of extra hardware.. ;) Feb 05 01:31:47 rcn-ee: indeed! anyway, thanks very much for the help. Feb 05 01:32:04 your welcome, later.. **** ENDING LOGGING AT Fri Feb 05 02:59:56 2010