**** BEGIN LOGGING AT Fri Aug 07 02:59:58 2015 Aug 07 05:31:22 i have a recipe with a dependency. that compiles and install on the image just fine. However, i cant locate it once the image is loaded. i'm wondering if the recipe just skipped it without a warning Aug 07 05:31:34 running bitbake dependency shows no option Aug 07 07:49:23 hello. Aug 07 07:50:08 I am coming again with the command: usermod -p password root Aug 07 07:50:49 i got this message when debugging: usermod : cannot lock /etc/passwd; try again later Aug 07 08:36:30 guys, anyone here tried the meta-raspberrypi? I created an image and booted, but the login is not working with root + no password, even though EXTRA_IMAGE_FEATURES = "debug-tweaks" in my local.conf. Aug 07 09:36:52 hi, can yocto unpack zip archives automatically? It does not seem so. Aug 07 09:39:15 lpapp, I think that it can ? Aug 07 09:39:29 lpapp, see bitbake/lib/bb/fetch2/__init__.py Aug 07 09:40:02 lpapp, elif file.endswith('.zip') or file.endswith('.jar'): Aug 07 09:45:59 hmm, interesting, thanks. I am not sure why it complains then. Aug 07 09:48:50 morning all Aug 07 09:48:58 so I have SRC_URI = "file://foo.zip \ Aug 07 09:49:36 but /home/lpapp/Projects/Yocto-daisy-32/src/build/tmp/work/armv5te-foo-linux-gnueabi/foo/0.1/foo-0.1/ remains empty. Aug 07 09:51:06 but if I have another tarball as SRC_URI = "file://foo.tar.xz \ -> then that gets populated into the workdir. Aug 07 09:51:16 morning bluelightning Aug 07 09:53:43 as you can see from the directory name, this is daisy should it matter. Aug 07 09:54:22 I assuma I will need to have a look at the log of the unpack job. Aug 07 09:54:25 assume* Aug 07 09:54:43 lpapp: does foo.zip contain a subdirectory "foo-0.1" ? Aug 07 09:56:33 bluelightning: hmm, not really, no, thanks. I assumed too much about github's download button. Thanks again. Aug 07 09:57:52 lpapp: it doesn't have to, it's just that if it doesn't, S will need to be changed to whatever subdir it does have (or set ;subdir= in SRC_URI in order to put the unpacked files in one if it doesn't have any) Aug 07 09:58:40 yeah, I think I will git archive to create an .xz tarball with Yocto's default expectation. Aug 07 09:58:44 use* Aug 07 11:05:28 hello guys Aug 07 11:07:06 how can I patch udev in yocto? Currently I've created udev_%.bbappend with SRC_URI += "file://accept4_syscall.patch but I received the following error: http://dpaste.com/169PYTY Aug 07 11:07:39 Ox4: did you also specify the path to file? Aug 07 11:07:58 hmm, it seems so: /home/vadimi/yocto/tmp/poky/meta/recipes-core/udev/files/ Aug 07 11:08:14 lpapp: should I set full path to the patch file? Aug 07 11:08:14 and the file is available in that directory, yup? Aug 07 11:08:23 oh wait Aug 07 11:08:25 meta? Aug 07 11:08:38 file is available in poky/firmware/meta-powerbeacon/recipes-bbappend/udev/files Aug 07 11:08:38 I think it is better to patch it in your layer. Aug 07 11:08:56 recipes-bbappend :-) Interesting. Aug 07 11:08:57 lpapp: yes, that's what I am trying to do Aug 07 11:09:10 Ox4: but your log says this, /home/vadimi/yocto/tmp/poky/meta/recipes-core/udev/files/ Aug 07 11:09:17 not meta-powerbeacon Aug 07 11:09:19 or meta-foo. Aug 07 11:09:37 so you have not added the bbappend's files successfully? Aug 07 11:09:38 lpapp: yes, it searches the patch in the wrong directory Aug 07 11:09:49 can you show the .bbappend file's content? Aug 07 11:09:59 lpapp: sure, just a second Aug 07 11:10:52 lpapp: http://dpaste.com/1NX38DB Aug 07 11:12:50 Try to remove the comment from line 2. Aug 07 11:14:33 lpapp: I tried already, but bitbake says the following: ERROR: Fetcher failure: Unable to find file file://accept4_syscall.patch anywhere. The paths that were searched were: Aug 07 11:14:33 /home/vadimi/yocto/tmp/poky/firmware/meta-powerbeacon/recipes-bbappend/udev/files/poky Aug 07 11:15:55 lpapp: but my patch is located in files not in files/poky Aug 07 11:16:28 that is odd Aug 07 11:16:47 either way, you need that line, so that is the right starting point. Aug 07 11:17:02 I would try to clean it up with -c cleanall Aug 07 11:17:03 and rerun Aug 07 11:17:24 and perhaps paste the whole error message. Aug 07 11:19:19 lpapp: I made cleanall but it didn't help :-( Aug 07 11:19:31 ok, wait for bluelightning or someone more experienced :) Aug 07 11:20:15 lpapp: ok :) meanwhile I will look through the yocto source code Aug 07 11:20:37 if you don't set FILESEXTRAPATHS_prepend this definitely will not work Aug 07 11:23:04 Ox4: can you paste the whole error output? Aug 07 11:23:51 lpapp: may be bitbake -e udev might give some hint? Aug 07 11:25:46 lpapp: thank you guys, I fixed the issue :) Aug 07 11:25:52 it was very stupid :-( Aug 07 11:26:42 Ox4: was it something to do with layer.conf? Aug 07 11:27:01 good :) Aug 07 11:43:52 sujith_h: no, the filename was wrong :-( Aug 07 11:45:55 ok, so the path was correct. :-) This is why I wished to see the whole error output. Aug 07 11:46:36 Hi, I'm trying to run a few things to change a file after the entire rootfs has been built. I created a function in my recipe and added it to ROOTFS_POSTPROCESS_COMMAND. However I don't think anything is running (I do a touch /tmp/a at the beginning of the script just to make sure of that). Where is the log of these commands stored? Aug 07 11:49:31 I noticed for oe/support/vim there's a program that is built during compilation and only used during the build (sjiscorr); as it's using $CC it fails to execute on the host. What ways are preffered to fix this? Aug 07 11:50:09 just patch it to change $(CC) to fo4r example gcc? Aug 07 11:50:33 or are there some magical HOSTCC floating around? Aug 07 13:13:28 is it possible to see in yocto what taks are executed when running "bitbake myrecipe" ? It seems that my autgen.sh is not executed, only I am not sure how to verify that Aug 07 13:14:41 harisokanovic: have you checked the do_configure log? Aug 07 13:14:46 sorry harisokanovic ;-) Aug 07 13:14:52 gatisp: have you checked the do_configure log? Aug 07 13:14:55 gatisp: autogen.sh wouldn't be executed by default, autotools.bbclass runs configure directly Aug 07 13:15:02 gatisp: if you go to the workdir and check temp, you might get some clue. Aug 07 13:15:19 (about what tasks were running) Aug 07 13:15:23 right, log.do_configure (and run.do_configure) will show you what's actually being done Aug 07 13:15:36 log.task_order will show which tasks were run and in what order Aug 07 13:16:16 ah right, I will check what I find in those scripts. Thanks. Aug 07 13:16:57 autogen.sh can have all sorts of things in it, but for the most part they usually just run autoreconf which we do anyway Aug 07 13:17:22 my colleague is asking me if there is a simple way to "unsource" the Yocto SDK setup. Aug 07 13:17:27 in the current session. Aug 07 13:17:41 lpapp: I'm afraid not, the env setup script sets a bunch of variables Aug 07 13:17:52 if you want to be able to do that, run it in a subshell Aug 07 13:18:00 then exit that shell when you're done Aug 07 13:18:18 bluelightning, my autogen.sh is a bit more special.. you said that "autogen.sh" would not be run by default, why is that? isn't that a standard file that autotools class should execute if it is there? Aug 07 13:18:18 yeah, I think that is reasonable. I suggested that to him. Aug 07 13:18:47 gatisp: I'm afraid it isn't standard at all... it's a common convention to have one, but it's just a script that can have anything in it Aug 07 13:19:09 gatisp: and quite often what it does have in it is not suitable for cross-compilation, so running it wouldn't actually work very well for our system Aug 07 13:19:58 naturally you can override do_configure to run it, but it then needs to be doing the right things Aug 07 13:20:06 its just renames and removes some files in my cases, so should not affect cross-compilation Aug 07 13:20:24 gatisp: yes but does it then go on to run autoreconf / configure ? Aug 07 13:20:32 bluelightning, can't i simply do do_configure_prepend()? Aug 07 13:20:39 gatisp: yes, you can Aug 07 13:20:58 yeah, thats what it does Aug 07 13:20:59 bluelightning: continuing from the other question about logs of tasks, do you know where the log for tasks defined in ROOTFS_POSTPROCESS_COMMAND is stored? Aug 07 13:21:20 DS__: should be log.do_rootfs for the image Aug 07 13:21:48 gatisp: that could be an issue depending on how it runs configure Aug 07 13:22:17 gatisp: I suppose if we're then re-running configure after that within autotools.bbclass you might be ok, apart from the wasted time Aug 07 13:22:45 probably It should work fine if i just extract the relevant parts, add them to _prepend and let yocto handle the configure part. Aug 07 13:22:57 also you are typing *really* fast ;) Aug 07 13:23:11 and thinking fast :) Aug 07 13:23:20 like I cannot. Aug 07 13:23:49 well, I guess I am used to answering people's queries, some of the same ones come up moderately frequently ;) Aug 07 13:23:55 gatisp: wouldn't it be better to just apply a patch that renames and removes files instead of a script? Aug 07 13:24:14 choices choices Aug 07 13:24:16 bluelightning: I checked that log, but couldn't find the output of the function I defined Aug 07 13:24:21 I'm afraid it's not even running Aug 07 13:24:39 have you checked bitbake -e? Aug 07 13:25:17 lpapp: I did, and it's there Aug 07 13:25:23 DS__, I did not write that script, just trying to build ostree in yocto; https://github.com/GNOME/ostree/blob/master/autogen.sh Aug 07 13:25:25 interesting. Aug 07 13:26:16 gatisp: gotcha Aug 07 13:26:17 DS__: are you using functions or raw commands in there? Aug 07 13:26:25 I remember that raw commands broke at some point. Aug 07 13:26:49 lpapp: I defined a function, inside it I put raw commands, and put that function inside the postprocess command list Aug 07 13:27:04 I remember reading about not putting raw commands in the command list as well Aug 07 13:27:30 hmm, odd. Aug 07 13:28:00 This rootfs postprocess thing is supposed to be called before "zipping" it all in a single file Aug 07 13:28:10 I want to change some files in the rootfs before doing that Aug 07 13:28:21 after install IIRC. Aug 07 13:28:40 Problem is, I want to change files created by other packages Aug 07 13:29:00 Specifically append some configuration directives in the generated openssl configuration file Aug 07 13:29:33 That's why I want to do in the entire rootfs Aug 07 13:30:48 hmm, we did that with bbappend, I think. Aug 07 13:32:17 lpapp: I saw a patch that already does something similar, however when "logically" separating things it makes no sense for me to create another recipe to do this task Aug 07 13:32:37 This configuration should only be put if I bake the rest of the recipe as well Aug 07 13:32:43 (it's an openssl engine) Aug 07 13:33:34 choices choices :) Aug 07 13:34:25 I think you could paste your file then. Aug 07 13:34:27 lpapp: I just read more carefully the output from bitbake -e, and realized that the ${IMAGE_ROOTFS} from that function isn't pointing to the right place, so that's why I can't see any output - it fails before the first output Aug 07 13:34:36 to see whether there is any typo or other mistakes. Aug 07 13:35:03 oh, right. Aug 07 13:35:15 It's pointing to the rootfs directory *inside* the recipe workdir Aug 07 13:35:35 How can I change the entire rootfs from that function? Aug 07 13:35:35 DS__: when the recipe is in fact the image recipe, that is correct Aug 07 13:35:57 bluelightning: and what if I want to get that path from another recipe? Aug 07 13:36:05 you cannot Aug 07 13:36:06 I thought it would be the same for all recipes Aug 07 13:36:31 image construction is a separate process from what goes on in the context of other recipes Aug 07 13:36:47 Then how can I accomplish what I need? I think I've understood the entire process now from what you said Aug 07 13:36:49 there is a shared sysroot if that's what you mean though Aug 07 13:37:00 Hm, how does it work? Aug 07 13:37:05 That might be what I need Aug 07 13:37:09 let me read back so I understand what you're trying to do Aug 07 13:37:22 I'll just summarize for you. Aug 07 13:37:33 The openssl recipe generates a file openssl.cnf Aug 07 13:37:55 My recipe (an openssl engine) needs to append some stuff into this file, as well as putting the engine into openssl's engine directory Aug 07 13:38:19 ah ok, so... this is actually possible, but it's not quite done the way you're attempting to do it Aug 07 13:38:25 I've been able to put the engine into the directory (it's just a copy), however I need to change the other generated file Aug 07 13:38:33 How do I approach this? Aug 07 13:38:50 the way you would do it would be to define a postinstall script i.e. pkg_postinst_${PN} () { } within your recipe, and that would make the desired changes Aug 07 13:39:01 Hmm Aug 07 13:39:18 So inside my engine recipe I define a pkg_postinst_openssl? Aug 07 13:39:25 within there you would use $D (note _not_ ${D} !) to refer to the path where the image is, if the postinstall script is being run on the host as part of image construction Aug 07 13:39:48 DS__: no, ${PN} - you want this to run when _your_ package is installed Aug 07 13:40:06 Ah, I get it Aug 07 13:40:28 and it wouldn't be possible to associate a postinstall script in one recipe with a package from another recipe anyway Aug 07 13:40:35 So this postinst is run after the files from my recipe get copied to the image root Aug 07 13:40:59 yes, after the packages are installed, we try to run all the postinstall scripts for the packages that were installed Aug 07 13:41:05 Cool Aug 07 13:41:07 any that fail are deferred until first boot Aug 07 13:41:11 And why $D and now ${D}? Aug 07 13:41:22 and not* Aug 07 13:41:33 well, in this case we're talking about the environment variable D as opposed to the bitbake variable D Aug 07 13:42:09 Cool Aug 07 13:42:12 the bitbake variable D always points into the destination directory for do_install - that wouldn't be of any use within a postinstall script that might be running on the target ;) Aug 07 13:42:24 Indeed :) Aug 07 13:42:24 different contexts Aug 07 13:42:32 we shouldn't have named them the same thing, in hindsight Aug 07 13:43:36 choices choices haha :) Aug 07 13:44:09 at least there are now QA checks to catch using the wrong one under most circumstances Aug 07 13:44:19 That's cool Aug 07 13:44:45 bluelightning: keeping on this subject, if I may use your time a little bit more, in the same recipe I get some QA issues related to installed-vs-shipped files Aug 07 13:45:08 have you seen http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-installed-vs-shipped ? Aug 07 13:45:28 Yes Aug 07 13:45:32 I've defined in some FILES_ variables the engine library, however it keeps bugging about the source files Aug 07 13:45:37 ok, great Aug 07 13:45:46 Why would the recipe install the sources if I haven't told them so? Aug 07 13:46:06 are these the debug sources perhaps ? Aug 07 13:46:09 It inherits from cmake, and I've tried to understand the cmake class, but couldn't find anything about installing the sources Aug 07 13:46:31 Yeah it bugs because of the /usr/src/debug files Aug 07 13:46:38 ah right Aug 07 13:46:56 so those are present so gdb can show you relevant source lines when debugging, should you install debugging symbols Aug 07 13:47:04 they're supposed to be packaged in the -dbg package Aug 07 13:47:15 How do I tell bitbake this is not a debug package? Aug 07 13:47:40 well, you've got a few different choices Aug 07 13:47:56 I guess you are getting this because you've set PACKAGES outright, is that correct? Aug 07 13:48:24 bluelightning: no, I haven't defined any PACKAGES in the recipe Aug 07 13:48:42 ok... in that case I wonder why they aren't being packaged as normal Aug 07 13:48:53 In fact I only defined FILES with the engine library because QA also spit an error because of that Aug 07 13:49:12 First it was an error about installing the .so but not shipping Aug 07 13:49:21 After that, it was because of those source files Aug 07 13:49:36 ok, would it be possible for you to pastebin the relevant FILES lines ? Aug 07 13:50:01 bluelightning: sure, I'll pastebin the entire recipe Aug 07 13:50:08 It's not long Aug 07 13:51:09 bluelightning: http://pastebin.com/siyuYfGY Aug 07 13:51:24 You can also see me trying to update the configuration there Aug 07 13:51:43 I've tried to bitbake things with that defined, but I think it didn't work Aug 07 13:52:29 ok, so change your FILES_${PN}-dbg line to a += and that should get rid of the warning I think Aug 07 13:53:16 Will I be able to remove that ugly INSANE_SKIP line after that? Aug 07 13:53:22 should be yes Aug 07 13:53:32 Cool Aug 07 13:53:38 hi! any meta-intel people around? Aug 07 13:53:48 oh, that postinst - ./somescript probably isn't going to work Aug 07 13:53:49 Now about the postinst function. Where is the log for that stored? Aug 07 13:54:10 imagine it was running on the target - where would that script be ? Aug 07 13:54:12 Should I be copying the file from the workdir before? Aug 07 13:54:49 bluelightning: indeed adding the += solved those QA issues Aug 07 13:54:53 Care to explain the reason? Aug 07 13:55:06 I love to know more about the inner workings of bitbake Aug 07 13:55:07 :) Aug 07 13:55:33 sure, it's because it has a default value already that is set to point to the files that it was complaining about - by using = to set it from the recipe, you replaced that default Aug 07 13:55:53 Gotcha. Cool Aug 07 13:56:36 as for openssl_update_conf.sh, you could either install it and package it, or just move its contents to the postinstall script and drop it Aug 07 13:57:13 bluelightning: if I prepend that line with a ${WORKDIR}, would that work? Would that variable still point to the script? Aug 07 13:57:17 nope Aug 07 13:57:41 Gotcha, so I guess I'll just copy the script and then execute it from there Aug 07 13:57:49 Hm Aug 07 13:57:50 About that Aug 07 13:57:51 again, imagine it were running on the target (say, you installed the package using ipk or rpm or whatever from the target) - would ${WORKDIR} be valid there ? Aug 07 13:58:34 bluelightning: Yup, I got it now. I thought it would execute, but with the "environment" of that package set Aug 07 13:59:26 no, actually the postinstall scripts get very little in the way of environment set - at that point it's the package manager doing the running rather than us (strictly speaking that's not true during do_rootfs, but that's a detail) Aug 07 13:59:58 Ok, let's see if copying the contents work Aug 07 14:00:47 I've been able to understand more about this entire part of bitbake. Thanks already in advance bluelightning for all the support Aug 07 14:03:04 np Aug 07 14:03:52 bluelightning: Apparently copying the contents didn't work. I'll try booting the image to see if the function was deferred to run at startup Aug 07 14:04:12 DS__: you should be able to verify that in log.do_rootfs Aug 07 14:04:25 DS__: can you pastebin the updated recipe ? Aug 07 14:05:55 bluelightning: woops, indeed the output is there. When I copy-pasted I forgot to remove a line and that was causing issues Aug 07 14:06:26 I was looking for the "success" output and forgot to check if it had errors Aug 07 14:08:33 bluelightning: awesome! It worked now Aug 07 14:08:34 :) Aug 07 14:08:52 Thanks a lot for your help Aug 07 14:09:05 I got to learn some cool things Aug 07 14:09:24 no worries Aug 07 14:13:17 kergoth: hey Aug 07 14:13:36 kergoth: could you please help with EXTERNAL_TARGET_SYS == TARGET_SYS. This indicates that the prefixes specified by? Aug 07 14:18:19 bluelightning: ended up using blacklisting to get it working right Aug 07 14:18:47 kergoth: oh, I see If it's an ia32 toolchain, make sure you did not let it modify your PATH, and if you did, remove it. Aug 07 14:18:51 kergoth: sorry Aug 07 14:18:54 WarheadsSE_: ok, I guess if you never needed anything else from linux-firmware then that's probably fine Aug 07 14:20:17 yeah, it wasn't linux-firmware I was blacklisting, but the recipes that supplied out-of-tree firmware from vendors Aug 07 14:35:37 ah, I see Aug 07 14:37:34 I was glad to see that it works from the machine/x.conf Aug 07 14:44:41 bluelightning: hi? I am starting to upgrade from dora to fido and somehow it looks like autoconf/automake based systems get __FILE__ to be a full path. Most log messages are now very long? Is that a change that was done on purpose? Aug 07 14:47:52 zecke: hmm, I vaguely remember something about that but I don't recall the details Aug 07 14:47:59 RP ^ ? Aug 07 14:48:12 rburton would be the person to ask but he's away atm Aug 07 15:18:00 Ox4: yeah, unfortunately the ia32 sourcery toolchains include non-prefixed binaries, and those binaries don't automatically set m32/m64 based on the arch of the host, causing breakage in the builds if we let them in the PATH Aug 07 15:30:40 kergoth: after cleaning the ${PATH} I shuld re-run . oe-init-build-env, right? Aug 07 15:31:58 I would probably use a subshell. Aug 07 15:32:04 which you can easily quit. Aug 07 16:25:07 https://casetext.com/posts/hawaii-bans-non-compete-and-non-solicit-clauses-in-high-tech-employment Aug 07 16:26:24 heh Aug 07 16:26:44 kergoth: hey bud, long time no see Aug 07 16:26:52 prpplague: hey, how ya been? Aug 07 16:27:16 kergoth: generally good, alive, get paid, paying bills, you know how it is, hehe Aug 07 16:30:46 prpplague: indeed Aug 07 16:31:10 my son is 8 months old now :) Aug 07 16:31:18 kergoth: wow! Aug 07 16:31:46 kergoth: hehe, mine will be 18 next week! hehe Aug 07 16:32:02 kergoth: time to kick him out and use his room as a lab Aug 07 16:32:36 hehe. nice Aug 07 16:32:40 ours doesn't have a room yet, but he's about to steal my office, of necessity Aug 07 16:34:03 https://www.dropbox.com/s/2p2aw8zawqszjvj/2015-07-31%2009.42.44.jpg?dl=0 Aug 07 16:36:12 kergoth: hehe Aug 07 16:36:16 kergoth: cute! Aug 07 16:36:50 kergoth: i saw a presentation from Digi executive the other day and thought of you, hehe Aug 07 16:39:19 hah Aug 07 17:37:07 anybody knows what should I do with "canonicalization unexpectedly shrank by one character" on dhcp/dhclient build? Aug 07 17:43:17 i'm running into a weird python error on meta-intel builds for "intel-corei7-64" Aug 07 17:43:20 well, I'll "inhibit" it for now, but was wondering if anyone looked at it already... Aug 07 17:43:29 http://pastebin.com/2RnyqJCw Aug 07 17:44:07 doesn't seem to be an issue with 32bit builds Aug 07 17:44:20 anyone run across this before? Aug 07 20:15:45 Anyone played with the idea of creating a 'native' MACHINE? Aug 07 22:21:48 anyone around? Aug 07 22:23:00 nope Aug 07 22:24:04 alrighty Aug 07 22:24:32 so i addded a bitbake recipe that just compiles a C program then copies it into /usr/bin in do_install Aug 07 22:24:44 i added this recipe to IMAGE_INSTALL for my image Aug 07 22:24:49 rebuilt the image Aug 07 22:24:52 binary missing from /usr/bin Aug 07 22:25:04 where do i start to debug? Aug 07 22:25:53 i know that the C program is being compiled, and the binary is ending up in build/tmp/work/core2-32-poky-linux/pin-controller/0.1-r0/image/usr/bin/ Aug 07 22:25:59 it's just not in the image Aug 07 22:31:49 any idea at all? Aug 07 22:37:38 + install -m 0755 /edison-tmp/work/core2-32-poky-linux/pin-controller/0.2-r0/pin-controller-0.2/edmunds-test /edison-tmp/work/core2-32-poky-linux/pin-controller/0.2-r0/image/usr/bin Aug 07 22:37:44 this is from the output of bitbake -v ... Aug 07 22:37:51 clearly, there is some intent to put this into /usr/bin in the image. Aug 07 22:39:16 /edison-tmp/deploy/ipk/core2-32/pin-controller_0.2-r0_core2-32.ipk exists.. Aug 07 22:39:53 ./usr/bin/edmunds-test is in that package.. Aug 07 22:41:04 also from bitbake -v, Aug 07 22:41:05 Installing pin-controller (0.2-r0) on root. Aug 07 22:41:07 Downloading file:/edison-tmp/deploy/ipk/core2-32/pin-controller_0.2-r0_core2-32.ipk. Aug 07 22:41:10 so... **** ENDING LOGGING AT Sat Aug 08 02:59:58 2015