**** BEGIN LOGGING AT Wed Sep 14 02:59:57 2011 Sep 14 07:31:34 HI all Sep 14 07:31:57 I was looking into share state stuff just want to double check that i got this stuff right Sep 14 07:32:54 while creating checksum it includes all the stuff expect those that is mentioned in the vardepsexclude and BB_BASEHASH_WHITELIST Sep 14 07:33:31 BB_BASEHASH_WHITELIST handles global variables and vardepsexclude deals with local dependencies Sep 14 07:36:32 does oe-core also cache PARALLEL_MAKE global var? Sep 14 07:40:05 good morning Sep 14 08:13:53 gm Sep 14 08:14:21 what's the score with kernel downloads at the moment, while kernel.org is off the air? Sep 14 08:14:47 seems that the actual source archives are on github, but some of the recipes are calling up patch files Sep 14 08:24:01 hi JaMa|Off Sep 14 08:24:38 you said that: Sep 14 08:24:40 GNUtoo|work: make sure that your new package is before ${PN}-doc in PACKAGES variable Sep 14 08:24:43 some time ago Sep 14 08:25:12 during the do_package I went into package-split dir Sep 14 08:25:18 I did 2 ls: Sep 14 08:25:26 first ls: Sep 14 08:25:28 qt4-embedded qt4-embedded-dbg qt4-embedded-doc Sep 14 08:26:15 second ls: http://pastie.org/2530651 Sep 14 08:26:29 I'll investigate Sep 14 08:27:35 GNUtoo|work: and what's wrong? Sep 14 08:27:51 I did that in the recipe: Sep 14 08:28:03 ahhh wait a second Sep 14 08:28:32 -PACKAGES += "${LIB_PACKAGES} ${DEV_PACKAGES} ${DBG_PACKAGES} ${OTHER_PACKAGES}" +PACKAGES += "${QT_BASE_NAME}-demos-doc ${LIB_PACKAGES} ${DEV_PACKAGES} ${DBG_PACKAGES} ${OTHER_PACKAGES}" Sep 14 08:28:47 bitbake.conf set ${PN}-doc Sep 14 08:29:01 so how to prepend in PACKAGES variable ? Sep 14 08:29:15 I'll look in the manual Sep 14 08:29:43 =+ Sep 14 08:35:50 thanks a lot anyway Sep 14 08:37:17 http://pastebin.com/8gUEqYbK Sep 14 08:37:40 can't build a gnome image Sep 14 08:58:32 hi guys Sep 14 08:59:05 am using something like this : SERIAL_CONSOLE += "115200 ttyO0" in my local.conf Sep 14 08:59:19 but i would like to move this parameter to a image.bb file Sep 14 08:59:41 but it happesn that this then gets either ignored or overwriten by machine.conf Sep 14 08:59:49 rob_w: is it really appropriate for an image? Sep 14 09:00:10 surely it would be better to either modify the machine .conf or just keep it in your local.conf Sep 14 09:00:17 since it's hardware-related Sep 14 09:00:25 yeah i know Sep 14 09:00:48 the dilemma is . i am building different images for different baseboards on a same machine.conf Sep 14 09:01:16 i dont want to create a new machine.conf for each baseboard but rather handle that with just a different defconfig Sep 14 09:02:57 what would be your suggestion for handling multiple baseboards on a same arch / machine.conf ? Sep 14 09:03:48 GNUtoo|work: i created an new user and stated with a new build, seems building now . i guess there were some environment vars set. Sep 14 09:03:57 so, if you're set on not having multiple machine configs one possibility would be to allow a variable through from the environment Sep 14 09:04:04 ok Sep 14 09:05:06 rob_w: i.e. add something like MACHINE_VARIANT to BB_ENV_EXTRAWHITE, add some code that checks that in the machine.conf and then do MACHINE_VARIANT="B" bitbake some-image Sep 14 09:05:39 AFAIK though traditionally you would just have multiple machine conf files Sep 14 09:05:57 they can inherit from a common .inc file if duplication is your concern... Sep 14 09:07:36 hmm right Sep 14 09:07:51 thx for that thoughts Sep 14 09:09:27 then another thing , who has some aufs expierence and might answer me some questions to that ? Sep 14 09:33:06 there is a thread in oe about aufs: Re: [oe] bitbaking aufs Sep 14 09:57:10 I would like to announce that progear machine in OE is now not supported anymore. I no longer have hardware Sep 14 09:57:28 but as no one except me used this then it is not a problem ;) Sep 14 10:01:14 hrw: just one of many machines no longer supported in OE-dev I imagine... Sep 14 10:02:50 yep Sep 14 10:05:04 is a machine trickle Sep 14 10:07:52 mckoan: ? Sep 14 11:45:10 hi, liboil fails at math_vfp.c with | math_vfp_asm.S:107: Error: selected processor does not support `fldmias r1!,{s0}' , Sep 14 11:45:30 I've looked at theses instructions are indeed vfp stuff according to arm manual Sep 14 11:45:40 my machine is an armv6 with vfp Sep 14 11:45:45 *the machine Sep 14 11:46:24 should I add -mfpu=foo in CFLAGS if it finds armv6 features Sep 14 11:46:40 or is there a more correct way of fixing Sep 14 11:46:43 it's oe-core Sep 14 11:46:54 and the machine is in a not-yet-pubilshed overlay Sep 14 11:47:03 it will be published when ready tough Sep 14 11:48:02 I'll look which kind of vfp the machine has Sep 14 11:49:15 like CFLAGS_armv6 += "-mfpu=foo" Sep 14 12:30:47 can somebody give me a pointer that how bitbake in oe-core decides to use sstate cache Sep 14 12:32:17 if it does not have cache for a particular package the first task that executed is do_fetch ..... but when we build for the second time the first task that is executed is do_package_setscene Sep 14 12:32:42 Hi, all! Sep 14 12:32:45 and this task is never executed when we first build the recipe Sep 14 12:33:11 so just want to know that how bitbake decides that he has to run do_package_setscene instead of do_fetch Sep 14 12:33:40 is there some guidelines on converting from oe-dev to oe-core? Sep 14 12:34:01 slapin, yes, in the wiki there is a page which reference what changed Sep 14 12:36:59 ERROR: QA Issue: No GNU_HASH in the elf binary: Sep 14 12:37:37 GNUtoo|work: I use external overlay with oe-dev and unable to build anything: http://pastebin.com/hVuLuFAu Sep 14 12:38:56 I have not found guide to add local layers and on this .bbappend stuff and how to use it effectively. Sep 14 12:40:09 So, now I have to self-host my custom layer and add it somehow to bblayers.conf, so no more central repository. Sep 14 12:41:49 I'll look later Sep 14 12:42:00 right now I've a problem with vfp and liboil: Sep 14 12:42:13 | math_vfp_asm.S:107: Error: selected processor does not support `fldmias r1!,{s0}' Sep 14 12:42:19 gcc uses that: Sep 14 12:42:27 -mfloat-abi=softfp Sep 14 12:42:30 which is wrong Sep 14 12:43:03 rk1router, you must pass the oe LDFLAGS to the undelining build system like autotools Sep 14 12:43:29 slapin, yes no more central repo Sep 14 12:44:17 slapin, for the error read it Sep 14 12:44:36 '${TUNE_CCARGS seem not terminated Sep 14 12:57:15 GNUtoo|work: but no reference to file in error Sep 14 12:58:10 bitbake.conf Sep 14 12:58:34 re-read attentively the whole pastebin Sep 14 13:27:26 TUNE_CCARGS ??= "" Sep 14 13:27:26 TARGET_CC_ARCH = "${TUNE_CCARGS}" Sep 14 13:27:31 GNUtoo|work: Sep 14 13:28:06 it was grep TUNE_CCARGS ./sources/openembedded-core/meta/conf/bitbake.conf Sep 14 13:28:24 ok Sep 14 13:28:53 I don't see any unterminated string literal, it is from stock openembedded-core Sep 14 13:29:03 not touched by me Sep 14 13:29:20 hmmm Sep 14 13:29:24 I've no idea then Sep 14 13:29:31 try to look at: Sep 14 13:29:34 bitbake code Sep 14 13:29:36 bitbake -e Sep 14 13:30:25 I use koen's scripts to fetch stuff and build nano immediately. oe-dev works fine with the same bitbake version. Sep 14 13:31:31 bitbake -e nano produce the same output Sep 14 13:42:52 slapin, same output? than what? Sep 14 13:43:01 than bitbake.conf? Sep 14 13:54:34 slapin: what's your bitbake version ? Sep 14 13:56:30 ericben: http://paste.debian.net/129976/ Sep 14 13:56:43 ericben: this was the hack I was talking about Sep 14 13:58:10 dodathome, GNUtoo|work: bitbake is 1.12 (auto-selected by scripts), bitbake.conf was not touched. same output = same error Sep 14 14:00:20 slapin: I had a similar issue after I switched to oe master branch in an oe environment setup by angstrom scripts Sep 14 14:02:54 slapin: I've started over in a fresh oe setup. So far it looks good Sep 14 14:14:30 valhalla, hi long time no seen Sep 14 14:15:18 otavio, hi, do you have neon issues on armv6 with qt-embedded? Sep 14 14:16:51 hmmm: qt4-embedded_4.7.4.bb:QT_CONFIG_FLAGS_append_armv6 = " -no-neon " Sep 14 14:17:28 hi GNUtoo|work Sep 14 14:18:06 valhalla, did you migrate to oe-core yet? Sep 14 14:19:43 log_do_configure has that : http://www.pastie.org/2532012 ouch.... conclusion if the toolchain has neon it enables it.... Sep 14 14:19:51 even with -no-neon....strange Sep 14 14:20:22 GNUtoo|work: I am not using qt4 on arm up to now Sep 14 14:20:32 ah ok Sep 14 14:20:38 so what GUI do you use? Sep 14 14:20:40 efl? Sep 14 14:20:44 or nothing? Sep 14 14:20:53 GNUtoo|work: for now, nothing Sep 14 14:20:58 ok Sep 14 14:21:02 GNUtoo|work: most of our work is still in x86 Sep 14 14:21:05 GNUtoo|work: up to now Sep 14 14:21:08 ahhh ok Sep 14 14:23:53 x86 such as geode or similar I guess Sep 14 14:24:06 GNUtoo|work: have you touched the translation building of qt4? it fails to build here and I need it to release Sep 14 14:24:09 :-( Sep 14 14:24:21 no but I've touched the docs locally Sep 14 14:24:29 let me show you my changes Sep 14 14:25:30 GNUtoo|work: I am starting to Sep 14 14:25:41 otavio, http://www.pastie.org/private/morqmrbsd1y54mluema Sep 14 14:25:55 valhalla, ok Sep 14 14:26:21 valhalla, there is a meta-pandora Sep 14 14:27:17 GNUtoo|work: awesome :D Sep 14 14:27:54 GNUtoo|work: regarding x86 ... yes but now also with atom, vortex and semproms Sep 14 14:28:08 ah vortex...isn't that ultra-slow? Sep 14 14:28:15 ok Sep 14 14:28:37 GNUtoo|work: i am fighting with qt4 building the translation but it seems it doesn't has the lrelease tools mangled before building Sep 14 14:28:40 * otavio checks Sep 14 14:28:47 ok Sep 14 14:28:47 GNUtoo|work: yes but the PMX is not that bad Sep 14 14:29:11 I'm learning the QT world....I'm new to building QT Sep 14 14:29:28 PMX? what's that? Sep 14 14:30:45 GNUtoo|work: I've noticed it (not used yet, however, I'm just restarting) Sep 14 14:31:00 ok Sep 14 14:31:56 GNUtoo|work: the lastest Vortex one. http://www.vortex86sx.com/ Sep 14 14:33:09 ah ok Sep 14 14:44:52 ok fixed locally Sep 14 14:44:55 the fix was that: Sep 14 14:45:11 QT_CONFIG_FLAGS_append_armv6-vfp = " -no-neon " Sep 14 14:45:17 there was already that: Sep 14 14:45:18 QT_CONFIG_FLAGS_append_armv6 = " -no-neon " Sep 14 14:45:35 but since we have vfp...it didn't took it Sep 14 14:45:55 I should wait that eric patches go in for proposing mines? Sep 14 14:46:12 because I wonder what to base the PR and INC_PR on otherwise Sep 14 14:46:28 GNUtoo|work: can you check the md5 of your qt 4.7.4 file? Sep 14 14:46:36 GNUtoo|work: here it seems to have changed Sep 14 14:47:19 ok Sep 14 14:47:21 I'll look Sep 14 14:48:19 ddf7d83f912cf1283aa066368464fa22 qt-everywhere-opensource-src-4.7.4.tar.gz Sep 14 14:50:09 GNUtoo|work: can you download it once again and check? I am getting a different one Sep 14 14:50:37 ok Sep 14 14:55:19 ddf7d83f912cf1283aa066368464fa22 qt-everywhere-opensource-src-4.7.4.tar.gz Sep 14 14:55:25 seem the same at first sight Sep 14 14:55:31 GNUtoo|work: I am finishing to download it Sep 14 15:01:18 GNUtoo|work: I downloaded it from qt.nokia and it is different Sep 14 15:01:32 9831cf1dfa8d0689a06c2c54c5c65aaf qt-everywhere-opensource-src-4.7.4.tar.gz Sep 14 15:01:32 ah? strange Sep 14 15:01:40 I downloaded from SRC_URI address Sep 14 15:01:43 http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.4.tar.gz Sep 14 15:01:58 sure it's not just a partial fetch? Sep 14 15:02:23 I'll check Sep 14 15:02:23 bluelightning: yes Sep 14 15:03:26 pb_: have you had time to look at the log? Sep 14 15:05:26 otavio: is conf/machine/vortex86sx.conf working there? Sep 14 15:05:40 9831cf1dfa8d0689a06c2c54c5c65aaf qt-everywhere-opensource-src-4.7.4.tar.gz.1 Sep 14 15:05:41 mckoan: used to Sep 14 15:05:49 GNUtoo|work: yse; this is mine too Sep 14 15:06:15 otavio: which bootloader do you use on it? Sep 14 15:06:16 mckoan: now a days I've been working at merge them into a generic x86 machine Sep 14 15:06:22 mckoan: syslinux Sep 14 15:06:43 otavio: I'll try a build later Sep 14 15:06:53 GNUtoo|work: you might compare the both? Sep 14 15:07:11 GNUtoo|work: we ought to check what changed Sep 14 15:07:50 otavio: I looked at it briefly but unfortunately the log is not very illuminating because it doesn't show the actual commands being used Sep 14 15:08:05 pb_: oh I see Sep 14 15:08:07 (it's a kbuild-style "quiet" log, so it just says "CC ...") Sep 14 15:08:17 could you try again with V=1 or whatever? Sep 14 15:08:22 pb_: I might rebuild passing V=1 Sep 14 15:08:51 yes, please Sep 14 15:09:02 otavio, yes we should look what changed or ask to the list if someone knows Sep 14 15:09:23 GNUtoo|work: since you have both, a diff -u might help Sep 14 15:09:29 ok Sep 14 15:09:54 pb_: will do and send an updated log for you Sep 14 15:10:28 diff -Nurd rather Sep 14 15:11:51 d Sep 14 15:11:58 I usually use Nur Sep 14 15:12:07 does a -e exist for diff Sep 14 15:12:12 so you could do diff -Nerd Sep 14 15:12:36 hehe Sep 14 15:13:01 the diff is huge.... Sep 14 15:13:18 morning kergoth Sep 14 15:13:59 couldn't you download the src_uri QT and look because I'll have some trouble pastebining that Sep 14 15:15:23 GNUtoo|work: but the diff seems logical? Sep 14 15:15:32 GNUtoo|work: which SRC_URI you used? Sep 14 15:15:42 GNUtoo|work: you ought to be using a mirror Sep 14 15:16:16 GNUtoo|work: because I used the SRC_URI here Sep 14 15:16:30 GNUtoo|work: and here it expands to the nokia one Sep 14 15:16:57 ah indeed Sep 14 15:17:27 GNUtoo|work: so your mirror is busted or nokia changed it Sep 14 15:17:41 strange.... Sep 14 15:17:46 GNUtoo|work: yes Sep 14 15:19:00 I'll recheck everything Sep 14 15:20:10 the diff between9831cf1dfa8d0689a06c2c54c5c65aaf and ddf7d83f912cf1283aa066368464fa22 is 1783590 line huge Sep 14 15:20:54 WOW Sep 14 15:21:09 Which mirror you used? Sep 14 15:22:10 let me look Sep 14 15:22:35 wget http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.4.tar.gz Sep 14 15:22:44 maybe there is something strange wrong Sep 14 15:22:59 and http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.7.4.tar.gz Sep 14 15:23:04 so the exact same one Sep 14 15:23:10 let me re-download it to see Sep 14 15:30:49 strange indeed Sep 14 15:30:56 I must go unfortunately Sep 14 15:31:03 maybe I did an error somewhere tough Sep 14 15:31:31 GNUtoo|work: can you update the patches and resend them? Sep 14 15:32:05 can I send them tomorrow? Sep 14 15:32:12 because I'll loose my train otherwise Sep 14 15:32:34 yes; but a mail warning to not merge them would be nice Sep 14 15:32:46 i can send the mail if you're in a hurry Sep 14 15:34:07 otavio: which image did you test with vortex86sx? Sep 14 15:34:21 mckoan: we have a internal one Sep 14 15:34:45 mckoan: but any x11 one ought to work Sep 14 15:34:52 yes I'm in a hurry, thanks a lot Sep 14 15:35:24 otavio: ok I'll try x11-image then, obrigado Sep 14 15:35:35 mckoan: you're welcome Sep 14 15:35:41 mckoan: are you brazilian? Sep 14 15:35:52 otavio: no italian :-D Sep 14 15:35:56 oh ok Sep 14 15:37:44 otavio: sorry last question, are you using main branch? Sep 14 15:38:02 mckoan: in fact currently we moved to oe-core Sep 14 15:38:15 mckoan: but i used to use oe.dev Sep 14 15:53:47 have a nice rest of the day Sep 14 15:56:24 mckoan|away: ping me if you have problems with the vortex; i might have solve them here so I might help just in case Sep 14 16:02:19 hi wondering if anyone could assist me? Sep 14 16:02:28 i am build for sarge at91 Sep 14 16:02:35 building* Sep 14 16:02:40 i only have 2mb flash Sep 14 16:02:50 could anyone advise which distro i should use? Sep 14 16:03:00 i tried angstrom with bitbake console-image Sep 14 16:03:11 but the rfs generated is too huge Sep 14 16:04:17 kaylessa: most probably micro is your better option for this case Sep 14 16:04:42 u mean mirco distro? Sep 14 16:05:45 kaylessa: yep Sep 14 16:05:54 ok thanks alot Sep 14 16:05:58 i got another question Sep 14 16:06:27 how do i go about create a binary with helloworld only ie to say kernal os with helloworld only Sep 14 16:06:43 i do not need a rfs for my machine Sep 14 16:08:08 create an initramfs Sep 14 16:08:43 care to explain further? Sep 14 16:09:16 build helloworld-static and put it in an initramfs. Kernel + single binary Sep 14 16:09:56 ok can i try to figure it out Sep 14 16:10:04 or do you ask how to *build* the binary? Sep 14 16:10:27 let me explain my situation Sep 14 16:10:34 i am new to embedded system Sep 14 16:10:40 currently doing a project on OE Sep 14 16:10:51 i have a at91rm9200 board Sep 14 16:11:07 i am trying to figure out how to build a binary for my board with OE Sep 14 16:11:17 it will print for example helloworld only Sep 14 16:11:29 wondering if u guys could help Sep 14 17:23:11 anyone have an idea about this one? Sep 14 17:23:13 http://pastebin.com/sVSvcJu5 Sep 14 17:26:18 hi crofton Sep 14 17:26:30 gm woglinde Sep 14 17:26:54 What up! Sep 14 17:26:59 Crofton looks like a typo in the packagename Sep 14 17:27:05 hmmm Sep 14 17:27:41 ot multiple calls to gtk-icon-cache bbclass http://git.openembedded.org/cgit.cgi/openembedded-core/commit/?id=229ba02322ce49d13e2d64eff6bb637f23f1f16b Sep 14 17:27:41 missing space? Sep 14 17:28:52 I guess python is not adding space to += (not like bitbake RDEPENDS += does) Sep 14 17:29:00 yes looks like Sep 14 17:31:50 this commit seems wrong as it adds another hicolor-icon-theme to RDEPENDS for every pkg in packages Sep 14 17:32:46 jama yes Sep 14 17:32:47 maybe it should set only RDEPENDS_${PN} Sep 14 17:33:54 hi effem Sep 14 17:34:13 poor koen Sep 14 17:35:40 hm koen only tested building but not image creation Sep 14 17:35:44 that was the problem Sep 14 17:35:56 or is Sep 14 17:37:19 ericben: I have the qt4 patches fixed locally regarding the md5 and sha256 sums Sep 14 17:39:25 woglinde: or only on packages with only one subpackage with icons dir.. Sep 14 17:42:15 woglinde, I'll beat him when I get a chance Sep 14 17:42:28 ah Sep 14 17:42:37 hm here was near "death" or so Sep 14 17:44:15 03Christopher Larson  07master * r224db31c46 10bitbake.git/lib/bb/taskdata.py: Sep 14 17:44:15 taskdata: fix string formatting of an error message Sep 14 17:44:15 Signed-off-by: Christopher Larson Sep 14 17:45:52 he's home now Sep 14 17:46:18 I know Sep 14 17:46:25 I read the mail too Sep 14 17:55:21 JaMa|Off, woglinde what change do you suggest Sep 14 17:59:16 Crofton: check which recipe is causing it Sep 14 17:59:30 Crofton: and if it really has multiple packages with icons dir Sep 14 18:00:50 I think it is the angstrom gnome task Sep 14 18:01:20 I think it is some dependency of angstrom gnome task Sep 14 18:01:28 read Packages file Sep 14 18:01:30 yeah Sep 14 18:01:49 I am at the gnuradio conf atm, so only using about 10% on this :) Sep 14 18:01:53 k Sep 14 18:21:46 JaMa|Off, ping Sep 14 18:22:57 GNUtoo: I fixed the md5 locally and pushed them into my public three Sep 14 18:23:01 tree Sep 14 18:23:28 ok Sep 14 18:26:28 btw I've a personal issue with kernel.bbclass, it doesn't output all the /etc/modutils stuff Sep 14 18:27:20 I cleaned the kernel with cleansstate Sep 14 18:27:20 and rebitbaken it Sep 14 18:27:20 and some autoload from the machine config are still absent Sep 14 18:27:20 they were added recently Sep 14 18:27:22 tough the modules in questions are in the rootfs Sep 14 18:32:51 where to start debugging it? Sep 14 18:32:52 the autoload code is in python populate_packages_prepend () { Sep 14 18:32:52 in kernel.bbclass Sep 14 18:32:53 but I wonder where the log is outputed Sep 14 18:32:53 there is no populate_packges.log Sep 14 18:32:57 hmmm Sep 14 18:47:13 I'll workarround in machine config with seding _ to - Sep 14 18:47:17 in the modules names Sep 14 18:47:21 and try Sep 14 20:31:32 is there a way to print out what recipe we are parsing when building cache? Sep 14 20:31:52 im running code from a bbclass and I want to see which particular recipe is triggering the issue Sep 14 20:32:26 msm: bitbake -DDD is probably the best option, but be prepared for a flood of messages... Sep 14 20:34:03 im getting no messages when its building the cahce Sep 14 20:34:05 cache* Sep 14 20:37:53 msm: hmm, just tested here and you're right... that's something that's broken recently Sep 14 20:39:47 he he, maybe i should wait on this issue then Sep 14 20:41:04 Hi! I have some issues with compiling git-native. Does anybody here has ever had any issues with compiling git-native in oe-core? Sep 14 20:41:23 mike111: i usually compile it, what are you seeing? Sep 14 20:41:50 libgit.a: could not read symbols: Archive has no index; run ranlib to add one Sep 14 20:42:56 I have tried to compile it by myself, it also fails, but i can run "ranlib libgit.a" and this problem disappears Sep 14 20:43:21 is ranlink in your build env? Sep 14 20:43:24 ranlib* Sep 14 20:44:30 there is ranlib in my host environment, but I'm not so sure about oe Sep 14 20:45:10 you can do a -c devshell and see what the env looks like? Sep 14 20:45:29 I just checked, there is ranlin in my "tmp" folder Sep 14 20:45:38 and it runs fine? Sep 14 20:46:01 that is as much as I know =) Sep 14 20:46:02 "ranlib -v" runs just fine Sep 14 20:46:12 I try devshell now **** ENDING LOGGING AT Thu Sep 15 02:59:57 2011