**** BEGIN LOGGING AT Mon Aug 01 02:59:58 2016
Aug 01 04:02:03 <Technicus> Hello.
Aug 01 04:03:12 <Technicus> Hey, how do I print only the ip address of wlan0?
Aug 01 04:19:03 <Snert_> ifconfig | grep "ip addy"  iirc
Aug 01 04:19:10 <Snert_> "" if there's a space.
Aug 01 07:55:16 <boucman_work> morning
Aug 01 07:59:05 <essa> morning
Aug 01 07:59:49 <lpapp> good morning, why is my Yocto directory using 6.5 GB after the build even with rm_work in the local.conf?
Aug 01 08:00:24 <essa> maybe download directory is not freed?
Aug 01 08:06:30 <lpapp> 2.8G    downloads
Aug 01 08:06:36 <lpapp> 898M    sstate-cache
Aug 01 08:06:37 <lpapp> 2.9G    tmp
Aug 01 08:06:43 <lpapp> those are the main contributors ^^^
Aug 01 08:06:52 <lpapp> even with rm_work, that is a lot when we wish to put Yocto under Jenkins.
Aug 01 08:06:59 <lpapp> several branches, etc, easily fills up the disk quickly.
Aug 01 08:07:38 <essa> I've never tried to even move my work directory (calculate directory size is also scary)
Aug 01 08:09:37 <lpapp> sorry?
Aug 01 08:09:50 <lpapp> move which work directory, where, why?
Aug 01 08:10:03 <essa> to another hard drive, for example
Aug 01 08:10:32 <boucman_work> lpapp: under jenkins you can probably share stuff between jobs (at least downloads)
Aug 01 08:11:08 <CTtpollard> +1 to sharing downloads and using local source mirror between jobs
Aug 01 08:11:17 <boucman_work> did you build a lot of images ? could you check the size of tmp/deploy ?
Aug 01 08:11:36 <boucman_work> yocto does not remove previously built images, so they tend to stack...
Aug 01 08:14:49 <lpapp> boucman_work: actually, I would much rather prefer removing those directories.
Aug 01 08:14:52 <lpapp> after the build.
Aug 01 08:15:16 <lpapp> as we have been using an internal network mirror for a couple of years now, already.
Aug 01 08:15:43 <lpapp> but yes, some kind of quick mirroring is crucial IMHO anytime.
Aug 01 08:15:55 <boucman_work> lpapp: you mean removing download after the build ?
Aug 01 08:16:10 <lpapp> not only for speeding things up, but also for reliability so that we do not rely on a community in a serious project, etc.
Aug 01 08:16:18 <boucman_work> you can do that, also check the handling of local pre-mirrors so you can use your infrastructure
Aug 01 08:16:30 <lpapp> yes, exactly, that is what I meant, removing the disk hog washes.
Aug 01 08:16:34 <boucman_work> but yocto will need to recreate download at each build which will take time
Aug 01 08:16:59 <lpapp> downloading is very fast on a gigabit internal network
Aug 01 08:17:04 <lpapp> so I am not too worried about that.
Aug 01 08:17:53 <boucman_work> ok, your call... yes you can remove the download directory, it won't break yocto. Jenkins has different plugins that can cleanup workspaces
Aug 01 08:38:07 <lpapp> boucman_work: we store the logs, we cannot entirely clean up everything.
Aug 01 08:40:14 <boucman_work> lpapp: what I do is I define the logs as "build-artifacts" so jenkins save them out of the workspace. I then clean-up the entire workspace. but YMMV
Aug 01 08:41:36 <lpapp> yes, that makes sense.
Aug 01 08:42:18 <lpapp> keeping the logs and remove the rest, although if someone wishes to investigate about a failure at a particular time, it might be difficult without the files.
Aug 01 08:42:23 <lpapp> I guess I need to understand my case better.
Aug 01 08:44:09 <lpapp> cheers.
Aug 01 09:16:15 <jubr> boucman_work: did you know about RM_OLD_IMAGE = "1"? Reclaims disk space by removing previously built versions of the same image from the images directory.
Aug 01 09:17:49 <jubr> Note it only removes n when building n+1, so older ones need to be done once manually
Aug 01 09:18:08 <boucman_work> jubr: I had seen it somewhere, but I never can find it when I need it. This is awesome, thx
Aug 01 09:18:22 <jubr> np m8
Aug 01 09:18:51 <boucman_work> it should be more prominently documented somewher in the mega-manual... I have no idea where would make more sense (maybe close to rm_work, since they are solving the same type of problem)
Aug 01 09:19:23 * jubr agrees
Aug 01 09:19:48 <BlitzBlizz> hi guys
Aug 01 09:20:52 <lpapp> jubr: I think I also requested that feature in 2013 :)
Aug 01 09:20:55 <lpapp> or maybe 2014
Aug 01 09:21:09 <lpapp> although that was something like rm_old_work
Aug 01 09:21:19 <BlitzBlizz> i've got a problem with a usb to ethernet driver on the raspi3. the driver seems to be included, but the device doesn't appears. can anybody help?
Aug 01 09:21:51 <lpapp> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6646
Aug 01 09:21:53 <yocti> Bug 6646: enhancement, Medium, 1.9, richard.purdie, RESOLVED FIXED, Implement rm_old_work
Aug 01 09:22:15 <boucman_work> BlitzBlizz: any kernel message when you plug (dmesg)
Aug 01 09:22:24 <lpapp> so apparently, rm_old_work and RM_OLD_IMAGE are different.
Aug 01 09:22:34 <boucman_work> is it listed when you do "ifconfig -a" or "ip link list"
Aug 01 09:23:18 <boucman_work> lpapp: rm_work is about removing the intermediate products of building a package (sources, .o files, temporary deployment directories...)
Aug 01 09:23:22 <lpapp> I saw this mega manual a couple of weeks ago...
Aug 01 09:23:37 <lpapp> I have been using the reference manual for looking things up... I guess I should use the mega manual now?
Aug 01 09:23:43 <lpapp> boucman_work: yes
Aug 01 09:23:53 <rburton> the mega manual is just all the manuals squished into one for searching
Aug 01 09:23:56 <jubr> `grep -r --color rm_old_work ../sources/poky/` only gave me a newline :(
Aug 01 09:23:59 <boucman_work> rm_old_image is removing stuff from "deploy" so it's about removing the final product of builds that you don't need anymore. It's much more dangerous (when your an integrator. devs don't care about old build)
Aug 01 09:24:08 <lpapp> http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-RM_OLD_IMAGE
Aug 01 09:24:09 <jubr> we're stuck with Freescale's i.MX6 releases
Aug 01 09:24:14 <lpapp> it is already documented ^^^
Aug 01 09:24:32 <boucman_work> jubr: rm_work not rm_old_work
Aug 01 09:24:50 <lpapp> jubr: from the bugreport, https://github.com/OpenAZBox/oe-core/blob/master/meta-openpli/classes/rm_old_work.bbclass
Aug 01 09:24:55 <lpapp> boucman_work: no, he is probably referring to my bugreport
Aug 01 09:25:00 <lpapp> where rm_old_work got implemented.
Aug 01 09:25:01 <boucman_work> oh, ok
Aug 01 09:25:04 <lpapp> perhaps it was renamed or so?
Aug 01 09:25:10 <lpapp> I do not have time to investigate...
Aug 01 09:26:08 <jubr> oh, was it renamed to `rm_work`? I've had that one around since the early 201x years I believe
Aug 01 09:26:16 <lpapp> no
Aug 01 09:26:24 <lpapp> rm_old_work was based on rm_work in ideas
Aug 01 09:26:30 <lpapp> but it was meant to do something different
Aug 01 09:26:34 <lpapp> at least when I requested :)
Aug 01 09:26:44 <lpapp> it is possible that it was merged back; I would not know.
Aug 01 09:27:22 <rburton> rm_old_work wasn't merged iirc
Aug 01 09:27:23 <jubr> rm_work is more prune_work, not a complete rm_, it leaves logs
Aug 01 09:27:34 <BlitzBlizz> boucman_work it is not listed in ifconfig -a and also not in ip link list
Aug 01 09:27:56 <lpapp> rburton: ah, ok.
Aug 01 09:27:58 <jubr> I guess it's meant to completely remove older work dirs, incl logs?
Aug 01 09:28:09 <lpapp> I remember it was for git things.
Aug 01 09:28:18 <lpapp> as rm_work was not removing old git stuff.
Aug 01 09:28:40 <rburton> rm_old_work was designed to remove non-current workdirs but leave the current one
Aug 01 09:28:43 <lpapp> and that caused me quite some headache when debugging in-tree git stuff.
Aug 01 09:28:52 <rburton> i believe bitbake does this itself now
Aug 01 09:29:27 <BlitzBlizz> this is the output of dmesg |grep usb: http://pastebin.com/58AD9Dsn
Aug 01 09:30:41 <lpapp> it sounds like we ought to use RM_OLD_IMAGE because when we build an image, we move it to a dedicated release directory on the network
Aug 01 09:31:06 <lpapp> so that it is not only stored in the release manager's local directory. In this way, RM_OLD_IMAGE could spare quite a bit of disk space.
Aug 01 09:31:50 <lpapp> in fact, I cannot imagine a use case right now where it would not make sense to set that to 1.
Aug 01 09:31:52 <jubr> lpapp: have you looked at using something like Artifactory?
Aug 01 09:32:31 <jubr> lpapp: as a dev, you sometimes want build n-x, to check back when you started breaking stuff, hehe
Aug 01 09:33:18 <lpapp> jubr: as a dev, I use NFS
Aug 01 09:33:26 <lpapp> and git bisect, for that purpose.
Aug 01 09:33:33 <lpapp> I have not heard about Artifactory yet.
Aug 01 09:34:44 <jubr> It's an Artifact Repository, the free version has enough functionality to be useable :)
Aug 01 09:35:33 <BlitzBlizz> boucman_work: this is the output of dmesg |grep usb: http://pastebin.com/58AD9Dsn
Aug 01 09:36:15 <lpapp> jubr: I am skimming through the website, but I have difficulties understanding what the project is about :)
Aug 01 09:36:15 <boucman_work> BlitzBlizz: can you just post the last 20 lines of dmesg, just after plugging your UBS link, and without the grep ?
Aug 01 09:36:48 <boucman_work> (also check if you device appears in "lsusb"
Aug 01 09:36:54 <lpapp> but in general, I thought the word "artefact" carries some negative meaning.
Aug 01 09:37:10 <lpapp> but words are just words, I guess.
Aug 01 09:37:39 <jubr> lpapp: basically it can store any type of build artifact that should persist after it has been created. Yeah, esp in visual domain it has neg connotation, but not here.
Aug 01 09:37:44 <boucman_work> lpapp: artefact in jenkins speak is "something that resulted from the build and is not part of the source"
Aug 01 09:38:10 <BlitzBlizz> boucman_work: http://pastebin.com/nxbKAAy2 last 20 lines
Aug 01 09:38:14 <jubr> We've actually started using the paid version in the cloud.
Aug 01 09:39:08 <lpapp> I am still trying to make up a use case where RM_OLD_IMAGE = "1" would not make sense
Aug 01 09:39:40 <lpapp> I thought when people build releases, they archive them in some central place and so collecting them on a local disk does not make so much sense.
Aug 01 09:39:46 <lpapp> but my perception is very limited.
Aug 01 09:39:50 <boucman_work> ok... your device seems to be correctly detected by the USB layer...
Aug 01 09:40:17 <rburton> lpapp: i'll often build a number of images with varying configurations (different package versions maybe) for testing
Aug 01 09:40:26 <boucman_work> lpapp: you are saving your results on a separate drive, some people don't. Thus we need to keep RM_OLD_IMAGE="0"
Aug 01 09:40:36 <rburton> lpapp: but i generally copy the images once generated so i'm not trying to remember what the timestamps meant
Aug 01 09:42:57 <jubr> I actually implemented some like IMAGE_LABEL, that adds a suffix to your image name after the timestamp, so you know what it was for, like IMAGE_LABEL = "fix-usb-booboo" or "sprint20-2"
Aug 01 09:43:05 <HyP3r> My kernel module driver recipie is working the first time: the recipie is running with success, but how can I check if the kernel module was imported into the rootfs?
Aug 01 09:43:35 <BlitzBlizz> boucman_work: a "modprobe mcs7830" brings up ""modprobe: FATAL: Module msc7830 not found in directory /lib/modules/4.1.21" but bitbake runs without error after including the driver via "bitbake -c menuconfig virtual/kernel"
Aug 01 09:43:38 <HyP3r> here is the script: http://pastebin.com/mBum4ddQ
Aug 01 09:45:35 <boucman_work> BlitzBlizz: ok, first question... does the file actually exist ? could you quickly check in /lib/modules ?
Aug 01 09:47:12 <boucman_work> HyP3r: check on the device :P you should have a file named wf111 or something similar deep in /lib/modules on the target
Aug 01 09:47:15 <BlitzBlizz> boucman_work not doesn't exist in /lib/modules
Aug 01 09:47:32 <boucman_work> BlitzBlizz: ok, then it hasn't been compiled.
Aug 01 09:47:58 <boucman_work> try "bitbake -C compile virtual/kernel" then "bitbake <your image>"
Aug 01 09:50:01 <BlitzBlizz> boucman_work: ok i will give it a try.
Aug 01 09:53:25 <HyP3r> boucman_work: is somewhere in the working directory the target rootfs? So I can take a look
Aug 01 09:54:23 <boucman_work>  tmp/work/<the most specific subdir>/<the name of your image>/<a couple subdirs>/rootfs
Aug 01 09:54:32 <boucman_work> yeah... I know. not very precise :P
Aug 01 09:54:50 <boucman_work> (and if you use rm_work, it will probably be empty)
Aug 01 09:55:48 <jubr> HyP3r: you might need RM_WORK_EXCLUDE
Aug 01 09:57:57 <HyP3r> Yes the working directory of the recpie gets wiped after work, but I wanted to take a look into the rootfs, but ok I'll search for the directory
Aug 01 09:59:10 <HyP3r> I have in the whole build directory no folder rootfs \o/
Aug 01 10:01:50 <boucman_work> HyP3r: if you use rm_work, that's normal. Please look at RM_WORK_EXCLUDE in the manual, and add your image's recipe there... (and probably your kernel recipe too)
Aug 01 10:02:27 <BlitzBlizz> boucman_work: bitbake <my image> failed with this error: http://pastebin.com/bCBhQqMS
Aug 01 10:02:30 * jubr stops googling RM_WORK_EXCLUDE to fish for the correct man deeplink
Aug 01 10:04:06 <boucman_work> BlitzBlizz: please update meta-raspberrypi
Aug 01 10:04:30 <boucman_work> rburton: we've seen this task-mismatch thing quite a lot on IRC recently, do you know what causes it ?
Aug 01 10:05:22 <rburton> either metadata changing on disk after the controller has forked, or metadata that depends on variables that change (such as TIME)
Aug 01 10:05:43 <rburton> fwiw i never see it with oe-core/meta-intel but i know some BSPs use DATETIME in their image classes but don't exclude it
Aug 01 10:07:39 <boucman_work> yeah, that seems to happen only with meta-raspberry and only since a week or so...
Aug 01 10:09:20 <rburton> £10 says their image class uses DATETIME or similar, but doesn't add it to the hash dependencies whitelist
Aug 01 10:09:38 <BlitzBlizz> boucman_work: ok i updated meta-raspberry and will built it again now
Aug 01 10:54:32 <BlitzBlizz> boucman_work: device still not listed in ifconfig -a and ip link list after building it again
Aug 01 10:55:46 <boucman_work> is the module in /lib/modules now ?
Aug 01 10:55:52 <boucman_work> can you modprobe it ?
Aug 01 11:06:26 <BlitzBlizz> no can't modprobe it
Aug 01 11:13:16 <BlitzBlizz> boucman_work: in menuconfig, there is a <M> in front of the driver. should i chance it to <*> ?
Aug 01 11:13:23 <BlitzBlizz> change
Aug 01 11:14:13 <boucman_work> in theory M should work... i'm not sure in what package does your module end, though...
Aug 01 11:14:39 <boucman_work> can you go in the workdir of your kernel, there should be a package-split subdir, and the module should be somewhere in there
Aug 01 11:14:46 <boucman_work> could you tell me where ?
Aug 01 11:14:55 <BlitzBlizz> ok. wait a second
Aug 01 11:21:15 <BlitzBlizz> boucman_work: there is nothing "/buildDir/poky-krogoth-15.0.0/rpi3_bin/tmp/work/raspberrypi3-poky-linux-gnueabi/linux-raspberrypi/1_4.1.21+gitAUTOINC+ff45bc0e89-r0/packages-split/kernel"
Aug 01 11:21:44 <boucman_work> nothing at all ?
Aug 01 11:22:13 <BlitzBlizz> boucman_work: empty directory
Aug 01 11:22:22 <boucman_work> hmm
Aug 01 11:22:39 <boucman_work> is it in you RM_WORK_EXCLUDE ?
Aug 01 11:23:30 <BlitzBlizz> boucman_work: here: "/buildDir/poky-krogoth-15.0.0/rpi3_bin/tmp/work/raspberrypi3-poky-linux-gnueabi/linux-raspberrypi/1_4.1.21+gitAUTOINC+ff45bc0e89-r0/packages-split" there is the module directory "kernel-module-mcs7830"
Aug 01 11:24:07 <BlitzBlizz> boucman_work: RM_WORK_EXCLUDE in conf/local.conf?
Aug 01 11:26:53 <boucman_work> yes, what does it contain ?
Aug 01 11:28:04 <BlitzBlizz> there is no line in conf/local.conf. the module directory contains many subdirecories and in the end, there is the file "mcs7830.ko"
Aug 01 11:28:36 <BlitzBlizz> no line containing RM_WORK_EXCLUDE in conf/local.conf
Aug 01 11:30:02 <BlitzBlizz> boucman_work: ...linux-raspberrypi/1_4.1.21+gitAUTOINC+ff45bc0e89-r0/packages-split/kernel-module-mcs7830/lib/modules/4.1.21/kernel/drivers/net/mcs7830.ko
Aug 01 11:30:57 <BlitzBlizz> sorry /drivers/net/usb/mcs7830.ko
Aug 01 11:32:40 <boucman_work> ok
Aug 01 11:33:13 <boucman_work> add "kernel-module-mcs7830" to your image (it's probably not installed at all)
Aug 01 11:34:55 <BlitzBlizz> boucman_work: i never did this. could you guide me?
Aug 01 11:41:22 <boucman_work> add the following line in your  local.conf
Aug 01 11:42:15 <boucman_work> IMAGE_INSTALL_append +="kernel-module-mcs7830"
Aug 01 11:42:19 <boucman_work> should do the trick
Aug 01 11:42:30 <jubr> BlitzBlizz: +=" k
Aug 01 11:42:35 <boucman_work> (and then rebuild your image and tell me if the module is there
Aug 01 11:42:42 <jubr> _append && += nice
Aug 01 11:43:02 <jubr> IMAGE_INSTALL_append = " kernel-module-mcs7830"
Aug 01 11:44:18 <BlitzBlizz> ok. it's building...
Aug 01 11:48:00 <HyP3r> To this script again: http://pastebin.com/mBum4ddQ The compilation is not generating a simple Kernel Module, there are some binary helpers and config files: http://pastebin.com/9vYAr8Am
Aug 01 11:48:35 <HyP3r> With the script, my hope was that all the files (not only the kernel module) is imported into the sysroot
Aug 01 11:49:21 <HyP3r> But it seems like "inherit module" is ignoreing this
Aug 01 11:51:11 <essa> why weston requires virtual/mesa? What should I choose, if I want to use powervr-sgx for graphics?
Aug 01 11:52:42 <HyP3r> How can I force yocto to import the other files also into the rootfs, the folderstructure seems allready good for the rootfs
Aug 01 11:54:04 <essa> HyP3r: create recipe for your files, it's pretty easy
Aug 01 11:54:43 <HyP3r> so then I have to recpies?
Aug 01 11:55:21 <HyP3r> *two
Aug 01 11:55:41 <essa> HyP3r: if you need to copy two files, you can create single recipe
Aug 01 11:55:59 <essa> just set SRC for multiple files
Aug 01 11:56:06 <jubr> HyP3r: I don't know how well inherit module will play together with extra FILES_${PN} stuff, you might have to break them up. Maybe with PACKAGES_prepend = "${PN}-cfg "?
Aug 01 11:56:44 <jubr> and then FILES_${PN}-cfg = "/usr"
Aug 01 11:57:57 <HyP3r> jubr: https://github.com/01org/luv-yocto/blob/master/meta/classes/module.bbclass seens more like it setting to FILES_${PN} = ""
Aug 01 11:58:38 <jubr> kernel-module-split does that for you
Aug 01 11:58:49 <HyP3r> https://github.com/01org/luv-yocto/blob/master/meta/classes/kernel-module-split.bbclass#L33
Aug 01 11:58:53 <jubr> hehe
Aug 01 11:58:59 <HyP3r> this is searching for the *.ko files
Aug 01 11:59:14 <jubr> so you prolly want to put all the other stuff in a separate pkg
Aug 01 11:59:24 <jubr> don't interfere with the kernel-module-split stuff
Aug 01 12:00:02 <HyP3r> so I have two recpies? One for Kernel Module and one for the additional files?
Aug 01 12:00:12 <jubr> you can gen multiple pkgs with simgle recipe
Aug 01 12:00:40 <HyP3r> How?
Aug 01 12:00:51 <jubr> read back my suggestions :)
Aug 01 12:03:47 <BlitzBlizz> boucman_work: thank you very much for your help. it works :-)
Aug 01 12:04:18 <boucman_work> np
Aug 01 12:04:25 <HyP3r> Take a look at this: http://pastebin.com/RdUipktY
Aug 01 12:05:03 <HyP3r> seems like yocto has created a pkg for the kernel module and a pkg for wf111 with the binarys
Aug 01 12:06:14 <boucman_work> yes, that's how yocto works...
Aug 01 12:06:33 <HyP3r> I don't know how yocto works, but it seems correct right?
Aug 01 12:06:53 <boucman_work> yes
Aug 01 12:08:21 <HyP3r> :)
Aug 01 12:08:48 <jubr> the magic lies in kernel-module-split.bbclass
Aug 01 12:09:39 <jubr> all the files install()'d in ${D} are divided over all the PACKAGES, first-come first-serve
Aug 01 12:10:42 <jubr> it even added a nice RDEPENDS_wf111: kernel-module-unifi-sdio
Aug 01 12:11:19 <HyP3r> jup, pretty cool
Aug 01 12:30:47 <yann|work> what's the correct way of changing the rootfs type from ext3 to squashfs ?  I could not find much on this in the docs
Aug 01 12:39:36 <boucman_work> yann|work: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-IMAGE_FSTYPES
Aug 01 12:40:02 <boucman_work> use bitbake -e to check how it is currently set, then change it wherever it makes sense to whatever you want
Aug 01 12:42:01 <yann|work> boucman_work: this adds generation of a squashfs, but on one hand there is still an ext4 generated,and  I was in the process of doublechecking but I guess the iso will still install an ext
Aug 01 12:45:31 <boucman_work> hmm
Aug 01 12:45:59 <boucman_work> ok, so it's the live image you want to use the squashfs, not just the yocto generation
Aug 01 12:46:12 <boucman_work> no idea... I don't really have the time to dig into it right now...
Aug 01 13:08:24 <HyP3r> Now I'm at the package dbus-cxx
Aug 01 13:09:08 <HyP3r> It crashing away with this: http://pastebin.com/7AhrMncL
Aug 01 13:09:23 <HyP3r> configure.ac:110: error: possibly undefined macro: AC_MSG_RESULT
Aug 01 13:09:43 <HyP3r> With a deeper look in this line stands: PKG_CHECK_MODULES(DBUS_VER,dbus-1 >= 1.2,AC_DEFINE(HAVE_DBUS_12,[],[If defined, dbus 1.2 or higher is present]),[AC_MSG_RESULT(dbus < 1.2)])
Aug 01 13:10:46 <HyP3r> So dbus-1 is not up to date?
Aug 01 13:13:31 <HyP3r> But it seems really up to date.: http://pastebin.com/Pj0kx4vg
Aug 01 13:18:08 <HyP3r> Hm. pkg-config give me the same result: http://pastebin.com/6WuFLWvC
Aug 01 13:20:17 <yann|work> boucman_work: ok, looking into image-live seems a good idea
Aug 01 23:06:55 <daddio> Any examples of a yocto recipe using cmake with nested CMakelists.txt files? doesn't seem to be working ut of the box
Aug 01 23:08:01 <daddio> I'm trying to make a layer for apitrace https://github.com/apitrace/apitrace
**** ENDING LOGGING AT Tue Aug 02 02:59:57 2016