**** BEGIN LOGGING AT Mon Sep 23 02:59:59 2013 Sep 23 06:57:21 Hi everybody. I've problems building a CPAN Module (Module::Runtime). It fails with "Can't load /path/to/usr/lib/perl/5.14.3/auto/Data/Dumper/Dumper.so for module Data::Dumper: /path/to/usr/lib/perl/5.14.3/auto/Data/Dumper/Dumper.so: wrong ELF class: ELFCLASS32 at /path/to/usr/lib/perl-native/perl/5.14.3/XSLoader.pm line 71." Does this ring a bell to anyone? Thanks! Sep 23 06:58:29 Here would be the complete do_compile log: http://pastebin.com/zhMq3gBU Sep 23 07:10:00 Does nobody has an idea what's the problem with the build? Here's the recipe source: http://pastebin.com/NfCQL0c5. Hope it helps! Sep 23 07:22:20 Ok, it seems I found the solution myself: The "inherit cpan" have to be replaced with "inherit cpan_build" and the "do_compile()" function can be removed. :-D Sep 23 08:14:07 good morning Sep 23 08:22:22 rburton: hi ! coming back to you because I have some troubles with my poky image : my image is .hddimg format and I launch it on my target with a usb-key. When i started my project I had loaded a poky image with the same format and was able to write on it (mkdir touch etc ...) and the files were still present after reboot. with my image, files are not kept. So my question is : do you know if there is something to enable in my configuratio Sep 23 08:22:32 rburton: knowing I've done this before Sep 23 08:46:04 elbc: there was a bug in master where that was broken for a few days, so update. Sep 23 09:16:48 rburton: ok thanks ! I want to push my modifications for wayland 1.2 /weston 1.2, you've already said to me that I can create a bug and push a patch for this, is it the better way for this or do I have to create a meta in upstream ? To be clear it was asked to me to have visibility but I don't know what is the better way to do it Sep 23 09:17:30 I'm a beginner so it is not very easy for me Sep 23 09:30:22 elbc: pushing a layer to eg github, sending patches, all are a good start. Sep 23 09:35:50 ok thank you ! Sep 23 09:37:51 anything is better than nothing :) Sep 23 10:11:05 hi to all! I'm building a yocto image for an arm board. I've got two recipes: a makefile-based recipe that needs javac (for arm) and the java-jdk recipe that build javac for arm. Sep 23 10:11:13 During do_compile of the first recipe yocto doesn't find javac binary...how I can tell the yocto build system that the javac is the one built with java-jdk recipe? Sep 23 10:11:15 ps: I've got DEPENDS setted so I'm sure that java-jdk recipe i built for first. thanks to all! Sep 23 10:16:44 soldoKyn: you probably need to use the javac path which was built by java-jdk, no? Sep 23 10:52:23 ndec: ok...there's a clever way to do this? Sep 23 10:53:21 soldoKyn: i am not familiar with these recipes, but i suspect java-jdk would install javac somewhere in sysroot, no? then you can use that path from the other recipe? Sep 23 10:58:05 Hi All, whats up with the duplicated shadow-native.bb in poky, why not just BBCLASSEXTEND="native" the shadow.bb recipe ? Sep 23 10:59:16 nde: yes, should work, thanks! Sep 23 11:23:09 in poky there is a file: ./meta/conf/machine-sdk/i586.conf; can I do somehow bbappend to it inside my layer? Sep 23 11:25:55 Krz_: not easily, no Sep 23 11:26:20 Krz_: you're probably into the realm of anonymous python at that point :/ Sep 23 11:28:21 RP: what if I just create my own myi586.conf inside my layer? Sep 23 11:28:43 Krz_: that will override it Sep 23 11:28:58 RP: I will change the name Sep 23 11:29:02 Krz_: assuming your layer is higher in BBPATH Sep 23 11:29:15 RP: and for meta-toolchain creation I will just use different SDKMACHINE Sep 23 11:29:55 RP: thinking about this... overwriting wouldn't be a bad option, as long as I preserve the original content + add mine Sep 23 11:30:26 Krz_: exactly Sep 23 11:31:56 RP: I can see default priorities for poky are '5', so I just set my layer priority to '4' and use default i586.conf name to overwrite poky's version Sep 23 11:32:14 Krz_: you need to use BBPATH in this case Sep 23 11:32:35 Krz_: BBPATH works for config files like PATH does for executables Sep 23 11:34:11 RP: in all layers I have BBPATH is exactly the same: BBPATH := "${BBPATH}:${LAYERDIR}" Sep 23 11:34:26 RP: how do you want me to change it? Sep 23 11:34:50 Krz_: prepend rather than append Sep 23 11:35:33 RP: so you are telling me I just switch the order and regardless of BBFILE_PRIORITY Yocto will pick up my i586.conf? Sep 23 11:38:20 RP: I'm maybe missing the right switch but trying to avoid the sstate chache for that klcc-cross seems hard. Better to touch the inputs and recreate it? Sep 23 11:44:24 Krz_: yes Sep 23 11:45:03 ant_work: sstate isn't really designed to be avoided. Best you can do is make it machine specific explicitly Sep 23 11:45:46 I've noticed I'm trying to abuse of your beloved buildsystem;) Forgive me :p Sep 23 11:46:01 is there such thing as a package specific do_install? i.e. ${PN}-package_do_install Sep 23 11:48:21 jackmitchell: no Sep 23 11:49:15 rburton: can I check for selected packages in the do_install function? Sep 23 11:49:26 jackmitchell: what do you mean by "selected packages"? Sep 23 11:50:51 so in lmsensors the package is split out into multiple packages, and I want to check if a package has been selected for install so I can do something like if (is_selected(package)) { install xyz } Sep 23 11:51:37 no, you can't do that Sep 23 11:52:01 bitbake builds a canonical package, and the splitting is how you get to control what goes into an image Sep 23 11:52:15 the package build doesn't/can't change depending on what image you're constructing Sep 23 11:52:33 especially because you may not be constructing an image, what is someone does bitbake lmsensors? Sep 23 11:53:17 ok, so, I'm a bit stuck. Sep 23 11:53:31 My problem is that lmsensors-sensord has a DEPENDS on lighttpd because it packages cgi files in the /www directory Sep 23 11:53:47 now I don't want lighttpd in my image Sep 23 11:53:49 RDEPENDS, surely Sep 23 11:53:54 yes RDEPENDS Sep 23 11:54:01 so split out the webby bits into a separate package Sep 23 11:54:03 and don't install it Sep 23 11:54:17 ok, that's what I;ve tried but they're still installing automatically Sep 23 11:54:34 and I was wondering if it was bitbake picking up that they;re used in the do_install function Sep 23 11:54:38 nope Sep 23 11:54:55 there's an explicit lighthttpd dependency somewhere Sep 23 11:55:24 well, the dependancy comes from the new package lmsensors-sensord-cgi Sep 23 11:55:33 but I can't find where the sensord-cgi comes from Sep 23 11:56:46 is there a class generating it? Sep 23 11:56:55 (is this in meta-oe or a private layer?) Sep 23 11:57:18 not that i can see, meta-oe Sep 23 11:57:19 http://pastebin.com/SsydsD2x Sep 23 11:57:33 http://pastebin.com/KeA6GjAA Sep 23 11:57:38 those are my modified recipes Sep 23 11:57:49 with the new sensord-cgi package Sep 23 11:58:13 jackmitchell: i don't see PN-sensors-cgi being added to PACKAGES Sep 23 11:58:33 line 59, it's tagged onto sensord packages Sep 23 11:59:12 oh i was only looking at the first link Sep 23 11:59:21 yeah, the recipe is a bit weird.. Sep 23 12:00:38 so what are those files? Sep 23 12:01:02 AFAIK just a cgi script and maybe a html file Sep 23 12:01:07 the first one sets FILES for a package it doesn't create, and the second creates a package and sets depends, but puts nothing in it Sep 23 12:02:09 ok, that's a good point, I shuffled them around a bit between the recipes, I think it is best for it to all go in the lmsensors-config package Sep 23 12:02:35 hi all, I have git SRC_URI in my linux.bb file. However, after being fetched with --bare --mirror to downloads/git2/, it is unpacked into tmp/work/.../packet-r1/git Sep 23 12:02:50 and not to tmp/work/.../packet-r1/packet Sep 23 12:03:04 and this confuses do_configure() Sep 23 12:03:13 How to fix this? Sep 23 12:03:21 drasko: you need to set S = "${WORKDIR}/git" in the recipe Sep 23 12:03:31 drasko: set S="${WORKDIR}/git" Sep 23 12:04:04 But why? I do not want source dir to be git Sep 23 12:04:13 but rather tmp/work/.../packet-r1/packet Sep 23 12:04:38 drasko: does it matter? that's the idiomatic way of handling git src_uris. Sep 23 12:05:30 OK, let me try Sep 23 12:07:20 One more question... I have set SRC_URI to: git://git.rocketboards.org/linux-socfpga.git;protocol=git;tag=${TAG} Sep 23 12:07:37 Where TAG = "socfpga-3.8" Sep 23 12:08:03 drasko: its best to use a full hash as it has to look up the tag name every time you run bitbake Sep 23 12:08:28 But in unpacked git I have something like this : Sep 23 12:08:30 * (no branch) Sep 23 12:08:51 Why it does not switch to the socfpga-3.8 branch automatically? Sep 23 12:33:08 Who is responsible for https://www.yoctoproject.org/about/news ? It seems somewhat out of date... ;) Sep 23 12:41:55 rburton: so I'm still fighting with this, the new recipe is here: http://pastebin.com/1y5UYdaS Sep 23 12:42:06 which has the new package ${PN}-cgi Sep 23 12:42:28 that package is solely in this recipe now, it doesn't straddle the two recipes anymore Sep 23 12:42:44 however the recipe is still being built regardless Sep 23 12:51:25 ok, it seems the recipe is broken, a simple bitbake lmsensors-libsensors returns ERROR: Nothing PROVIDES 'lmsensors-libsensors' Sep 23 12:53:32 shoudl bitbake be able to directly build packages defined using PACKAGE += "${PN}-packgage" Sep 23 12:59:09 jackmitchell: not to my knowledge, no Sep 23 13:01:27 ah ok, that would be why it's not working then ;) Sep 23 13:04:38 jackmitchell: sometimes this kind of recipes can be rewritten using PACKAGES_DYNAMIC Sep 23 13:05:19 ant_work: I will look into that thanks Sep 23 13:36:13 Saur: I've emailed Jefro who takes care of some of the website bits, thanks Sep 23 13:36:46 drasko: I think you'll find it just checks out the specified revision rather than the branch by name Sep 23 13:37:18 drasko: which as far as the code being checked out is concerned amounts to the same thing Sep 23 13:40:49 bluelightning: You don't happen to know who's responsible for https://wiki.yoctoproject.org/wiki/Governance/SteeringGroupMinutes as well? Or hasn't the advisory board had any meetings since April 2012? (That URL is linked from https://www.yoctoproject.org/about/governance/admininstrative-leadership) Sep 23 13:41:27 the AB has meetings about bimonthly or so Sep 23 13:42:58 B4gder: Yeah, that's what I though. But the minutes of their meetings don't seem to have been updated since April 2012... Sep 23 13:45:27 Saur: have just emailed about that as well Sep 23 13:45:28 thx Sep 23 13:45:46 they are in the yocto-ab archives though, if you dig a little Sep 23 13:45:51 https://lists.yoctoproject.org/pipermail/yocto-ab/2013-August/000856.html is the most recent one Sep 23 13:46:34 B4gder: Thanks Sep 23 13:47:47 any particular thing you were looking for in there? Sep 23 13:59:04 mranostay: yep, I am considering getting a scope and/or LA. Sep 23 14:41:30 is there somewhere a history of this IRC ? Sep 23 14:42:36 Krz_: yes, see topic Sep 23 14:43:12 rburton: good one, but missing private chats Sep 23 14:43:41 well, yes. Sep 23 14:44:07 private chats are not on the channel Sep 23 15:20:19 How do I get opencv headers in "meta-toolchain-qt" Sep 23 15:35:30 I have a simple recipe that I want to kick off when user types 'bitbake meta-toolchain' Sep 23 15:35:48 I can do a bbappend to meta-toolchain, but what do I type there? IMAGE_INSTALL += will not work Sep 23 15:54:39 hmmm, I am getting another error with the lmsensors package Sep 23 15:54:46 | * satisfy_dependencies_for: Cannot satisfy the following dependencies for lmsensors-dev: Sep 23 15:55:02 could this be because lmsensors-dev is essentially an empty package? Sep 23 15:56:05 yes Sep 23 15:56:13 something is pulling it in, but it doesn't exist Sep 23 15:56:32 you can either find what's pulling it in and stop that, or use ALLOW_EMPTY to generate the empty package Sep 23 15:56:41 yeah, I've used allow_empty Sep 23 15:56:47 rebuilding now to see if it works Sep 23 15:59:41 rburton: I also realised that before, even though the -cgi package was being built, it wasn;t being included in the image Sep 23 16:00:00 rburton: it skews the bitbake -g package-depends something rotten though Sep 23 16:00:17 I asssume it builds all sub-packages, but only installs the ones you ask for Sep 23 16:00:28 yes Sep 23 16:00:37 but they still find there way into the dependancy graph Sep 23 16:00:39 package building is isolated from image generation Sep 23 16:00:42 yes, of course. Sep 23 16:00:57 they won't appear in the dependency chart for *your image* though Sep 23 16:01:32 How do I get opencv headers in "meta-toolchain-qt" Sep 23 16:02:18 fenrig: its better to use "bitbake myimage -c populate_sdk" these days, as then you get a sdk containing exactly the development bits for your real image Sep 23 16:02:35 rburton: oh I'll look into that Sep 23 16:02:35 instead of having to start with some meta-toolchain and extend it, missing bits out Sep 23 16:02:46 fenrig: its bigger, but it's more complete. Sep 23 16:02:58 rburton: thx ;) Sep 23 16:13:54 I successfully created meta-toolchain.bbappend. How do I limit my bbappend to i586 only? I want Yocto not to bbappend it for different SDKMACHINES Sep 23 16:16:42 Krz_: there aren't overrides corresponding to SDKMACHINE AFAIK Sep 23 16:19:12 bluelightning: so maybe I can figure out inside bbappend the value of SDKMACHINE and there decide what to do or not? Sep 23 16:19:19 bluelightning: that would be good enough Sep 23 16:19:38 Krz_: you could do that within an anonymous python section in the bbappend yes Sep 23 16:19:55 bluelightning: what's that section? any examples? Sep 23 16:21:35 Krz_: http://stackoverflow.com/questions/17834624/what-is-anonymous-class-in-python Sep 23 16:22:31 bluelightning: cheers! Sep 23 17:40:48 I have a client who, for security reasons, wants to build their app outside of the yocto environment, and then add the app to the image via downloading a debian package containing the app Sep 23 17:41:43 I suspect that I will have to pick apart the debian package to get the app binary, but was wondering if there was a clever way to convince bitbake to use the package Sep 23 17:42:04 FWIW, they are using debian packages with Yocto too Sep 23 17:42:51 you should be able to (assuming deb styl packages are used) simply override the package_write_deb task Sep 23 17:43:09 if deb isn't being used.. override do_package or something to tear apart what they've given you and put it into the YP format Sep 23 17:50:38 there is bin_package.bbclass which is designed to extract a dep/rpm/etc. package and repackage it as appropriate Sep 23 17:51:32 I think bin_package is the best approach if you have to do this, since the real output package will get the correct dependencies etc. Sep 23 17:56:39 hum, I'm still not able to get wifi on my FRI2 Sep 23 17:56:45 anybody can help ? :) Sep 23 18:00:00 seebs: I think I am seeing some strange interaction with pseudo and mkfs.btrfs, got a few to chat about it? Sep 23 18:00:11 I can try. Sep 23 18:01:01 oh right Sep 23 18:01:20 bluelightning: thanks for the pointer! Sep 23 18:02:02 the issue is that modules are being built but don't end up in tmp/deploy/images/fri2/modules-fri2.tgz Sep 23 18:02:03 seebs: the latest mkfs seems to use ftw() to walk the file tree and symlinked files are returning the size of busybox (for example) instead of a symlink (like 1000byts) Sep 23 18:02:10 hmm. Sep 23 18:03:09 Intuitive answer: that is probably a bug in pseudo, I'd guess I'm not processing the flags. Sep 23 18:04:20 Huh. Well, there's an interesting thing. Currently, both ftw() and nftw() are doing no magic at all. Sep 23 18:04:38 Except the initial path cleanup for chroot. Sep 23 18:04:47 seebs: I did not dig much deeper, I tried with nftw and looked at the flags, that seemed correct. Sep 23 18:04:57 I think I have been assuming that they call stat() and thus pick up pseudo's processing. Sep 23 18:05:37 Just looking at it, ftw() appears to implicitly follow symlinks, I think. Or at least, nftw() has a flag to allow you to tell it not to. Sep 23 18:06:23 seebs: right nftw has a flag, plain ftw() just returns FILE for DIR flags Sep 23 18:07:28 There's the flags it passes to the per-file function, and also the invocation flags. nftw() apparently supports a FTW_PHYS flag to not follow symlinks, which would make me assume ftw() follows symlinks. I suppose I could test this theory. Sep 23 18:08:09 someone asking about the FRI2 I hear? Sep 23 18:10:27 dvhart: abelloni is trying to get wifi working and having trouble Sep 23 18:10:50 yeah right Sep 23 18:11:01 actually, the modules are in tmp/deploy/images/fri2/modules-fri2.tgz Sep 23 18:11:12 but they never end up in the filesystem Sep 23 18:11:32 I used core-image-minimal and core-image-sato with the same results Sep 23 18:12:58 I'm using a quite recent master, updated this afternoon Sep 23 18:14:46 core-image-minimal would not work Sep 23 18:14:52 but core-image-sato should Sep 23 18:15:01 checking... Sep 23 18:15:38 Okay, quick sanity check. Without pseudo involved, both ftw() and nftw() yield the target's information for a symlink, unless it's nftw with FTW_PHYS. Sep 23 18:16:15 abelloni, see the reference manual for why minimal isn't affected by the MACHINE_EXTRA_RECOMMENDS Sep 23 18:16:38 dvhart: I specifically added linux-firmware so it shouldn't matter Sep 23 18:16:56 yeah.... I'm not seeing the kernel-module* listed though Sep 23 18:16:57 hrm Sep 23 18:17:08 anyway, the firmwares are there, it is the modules that are not on the target Sep 23 18:17:11 I... don't recall that being removed Sep 23 18:17:23 but yes, from the machine and kernel bbappend, it's missing Sep 23 18:17:26 huh Sep 23 18:17:47 abelloni, I'll do a git search to see if that was removed Sep 23 18:18:16 However, sato should install kernel-modules I thought.... Sep 23 18:20:33 abelloni, would you consider adding the following to fri2.conf and rebuilding? Sep 23 18:20:48 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += " kernel-module-iwlwifi" Sep 23 18:21:04 It needs a full list of those, but that should resolve your problem Sep 23 18:21:28 sgw, bluelightning, I thought sato included the kernel-modules package. Do you know if that has changed? Sep 23 18:22:44 abelloni, I would also really appreciate it if you could open a bug for this. I'm tracking a lot of issues right now and that would help make sure it doesn't get lost. Could you do that? Sep 23 18:23:09 dvhart: I don't think so, it's a MACHINE_EXTRA_RRECOMMNEDS for most platforms (including in ia32-base.inc) Sep 23 18:23:56 sgw_, ah right. Sep 23 18:24:05 So kernel-modules should have made it in..... Sep 23 18:24:22 abelloni, are you building using the linux-yocto recipe? Which DISTRO? Poky? Sep 23 18:24:53 * dvhart does a poky sato build for fri2 to verify Sep 23 18:34:36 wow, full sstate builds are freakin' fast Sep 23 18:38:44 yup Sep 23 18:39:12 certainly a lot faster than classic... Sep 23 18:40:39 it's just so rare that I get to build that way with everything in flux during the development cycles Sep 23 18:40:47 returning to it is always a bit of a surprise :-) Sep 23 18:57:34 yeah, each time i pull on master it builds a bunch of new stuff, but after that it gets fast again... Sep 23 18:58:53 * mr_science still wondering where khem was on Friday... Sep 23 19:15:01 is there a way to remove a native package from the native sysroot? Sep 23 19:15:30 gjohnson: you mean that you want OE to use the one installed on your machine instead? Sep 23 19:17:13 ndec: No, I did a bitbake on a native package in my case qtbase-native which installed some binaries in the i686-linux sysroot. I want to remove the files that qtbase-native installed Sep 23 19:18:06 bitbake -c clean qtbase-native, does that work? Sep 23 19:21:12 ndec: yes that worked! Thanks. I thought clean just cleared the work directory Sep 23 19:21:44 no, it cleans the sysroot too. but i wasn't sure for -native stuff ;-) Sep 23 19:22:09 btw, you have cleansstate too that also removes anything from the sstate. and cleanall that just removes everything. Sep 23 20:05:43 jwessel, Hey, would you mind having a look at Yocto BZ 5232 Sep 23 20:06:01 jwessel, I think this is related to the serial/vga work you're doing for the bootloader / installer Sep 23 21:16:06 dvhart: did you reproduce the issue or is it just me ? Sep 23 22:06:12 abelloni, hrm, need to check, been working on something else for a while Sep 23 22:07:54 abelloni, for sato: Sep 23 22:07:55 np, it is simply to know if I'm doing something wrong or if I'm crazy ;) Sep 23 22:07:57 $ tree lib/modules | grep iwl Sep 23 22:07:57 │   │   │   └── iwlwifi Sep 23 22:07:57 │   │   │   │   └── iwldvm.ko Sep 23 22:07:57 │   │   │   └── iwlwifi.ko Sep 23 22:08:23 abelloni, so iwlwifi.ko is included in the rootfs I build for fri2, DISTRO=poky, core-image-sato, with current master Sep 23 22:08:35 abelloni, how are you building? Sep 23 22:08:45 are you building DISTRO=poky core-image-sato? Sep 23 22:09:57 hum really weird Sep 23 22:10:27 I got the modules in fri2-poky-linux/core-image-sato/1.0-r0/rootfs Sep 23 22:10:36 but not on the target Sep 23 22:10:51 I'll check the hddimage directly then Sep 23 22:11:36 $ bitbake core-image-sato -e | grep "MACHINE_EXTRA_RRECOMMENDS=" Sep 23 22:11:37 MACHINE_EXTRA_RRECOMMENDS="kernel-modules eee-acpi-scripts linux-firmware-iwlwifi-6000g2a-5" Sep 23 22:11:47 might want to verify that too Sep 23 22:11:57 did you run out of space on the target disk? ;-) Sep 23 22:12:14 nope Sep 23 22:12:25 got an 8G sdcard Sep 23 22:13:56 right, no modules in core-image-sato-fri2.ext3 Sep 23 22:14:07 I'm not so crazy Sep 23 22:14:28 I got DISTRO?=poky in my local.conf Sep 23 22:14:39 and the MACHINE_EXTRA_RRECOMMENDS are the same Sep 23 22:14:55 would that be because I built core-image-minimal first ? Sep 23 22:17:30 shouldn't be .... no Sep 23 22:17:39 abelloni, I can't explain that :/ Sep 23 22:18:25 abelloni: Sep 23 22:18:28 dvhart@rage:/build/yocto/master/fri2_20130404080424/build/tmp/deploy/images/fri2 Sep 23 22:18:29 $ mkdir mnt Sep 23 22:18:29 dvhart@rage:/build/yocto/master/fri2_20130404080424/build/tmp/deploy/images/fri2 Sep 23 22:18:29 $ sudo mount core-image-sato-fri2.ext3 -o loop mnt Sep 23 22:18:29 dvhart@rage:/build/yocto/master/fri2_20130404080424/build/tmp/deploy/images/fri2 Sep 23 22:18:31 $ find mnt -name "iwlwifi.ko" Sep 23 22:18:48 mnt/lib/modules/3.8.13-yocto-standard/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko Sep 23 22:19:43 abelloni, I'd suggest keeping your build dir around, and building from skratch in another directory Sep 23 22:19:53 then at least we'll know if it has something to do with existing state Sep 23 22:20:46 ok, I'll do that Sep 23 22:21:44 sorry it's causing you grief :/ Sep 23 22:22:16 honestly, it is not so bad ;) Sep 23 22:22:39 I would just want to understand, for the sake of quality Sep 23 22:23:00 maybe it is a bug, maybe not Sep 23 22:23:33 ok, it is building from scratch now and I'm going to bed, we'll know tomorrow Sep 23 22:26:09 oh, unrelated topic Sep 23 22:26:19 it doesn't reboot when i use reboot Sep 23 22:26:38 I have to unplug and plug it again, is there another way ? **** ENDING LOGGING AT Tue Sep 24 02:59:59 2013