**** BEGIN LOGGING AT Thu Dec 03 03:01:14 2015
Dec 03 08:29:26 <Newie> Hi anyone onliine?
Dec 03 08:33:59 <raykinsella78> yup
Dec 03 08:59:40 <Ulfalizer> http://pastie.org/10600885  any idea why this recipe gives the error at the end of the paste? somehow a directory gets created in ${D}, seemingly by the do_package task.
Dec 03 08:59:51 <Ulfalizer> it's a reduced version of a problem i'm having with a larger recipe
Dec 03 09:00:11 <Ulfalizer> commenting out the S assignment fixes the error
Dec 03 09:03:03 <Ulfalizer> providing a do_install that copies some files into ${D} makes no difference. a directory ${D}/foo still gets created.
Dec 03 09:09:20 <bluelightning> Ulfalizer: S = "foo" wouldn't be valid... it's supposed to be the entire path
Dec 03 09:10:44 <Ulfalizer> heh, d'oh, i'm an idiot :)
Dec 03 09:10:53 <Ulfalizer> i was sure it was relative to ${WORKDIR}
Dec 03 09:11:00 <Ulfalizer> that's almost certainly it then
Dec 03 09:11:18 <Ulfalizer> thanks
Dec 03 09:17:10 <rburton> maybe something worth sanity checking
Dec 03 09:22:33 <Ulfalizer> rburton: yeah, that's probably better than randomly creating a directory in ${D} at least
Dec 03 09:25:50 <rburton> *could* detect its relative and base it on workdir
Dec 03 09:25:52 * rburton can't decide
Dec 03 09:26:13 <rburton> bluelightning: do you have an opinion?  too early here to form concrete opinions :)
Dec 03 09:26:37 <rburton> sanity checking can be done fatally in insane whereas magically turning it into an absolute path would need to happen… somewhere
Dec 03 09:27:03 <bluelightning> rather than allow relative paths I'd just error out if it doesn't start with /
Dec 03 09:27:12 <Ulfalizer> rburton: my newb opinion is that it's confusing to let it be either absolute or relative
Dec 03 09:27:18 <bluelightning> to be honest this is the first time I've heard of this coming up
Dec 03 09:27:38 <rburton> ditto, but it took Ulfalizer a day to figure out it, so that's bad :)
Dec 03 09:28:14 <bluelightning> indeed, if we can avoid difficult-to-debug situations that would be ideal
Dec 03 09:28:19 <Ulfalizer> even without a warning, the behavior of creating a directory in ${D} is confusing. i still don't know why it does that.
Dec 03 09:28:34 <rburton> because that's what pwd was when it did the mkdir
Dec 03 09:29:12 * rburton looks at the recipe
Dec 03 09:29:18 <rburton> iiinteresting
Dec 03 09:29:23 <rburton> because in a normal recipe you get a different error
Dec 03 09:29:34 <rburton> WARNING: m4: the directory m4 (m4) pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to
Dec 03 09:29:34 <Ulfalizer> why does it do a mkdir? isn't it just do_install that's supposed to put stuff in ${D}?
Dec 03 09:30:05 * rburton looks again
Dec 03 09:30:10 <Ulfalizer> it seems do_package creates the directory, which seems odd
Dec 03 09:31:04 <rburton> oh, because do_package likely runs in $B
Dec 03 09:31:08 <rburton> which is $S by default
Dec 03 09:31:10 <tasslehoff> Upgraded from 1.8 to 2.0 (angstrom) and now resolv.conf is managed by Connection Manager insted of Systemd. How/where do I add a new nameserver entry?
Dec 03 09:31:39 <Ulfalizer> rburton: and it happens to be in ${D} before that?
Dec 03 09:32:23 <rburton> do_package() has a dirs of SHILBWORKDIR PKGDESTWORK D, so mkdir's those and cd's into D
Dec 03 09:33:31 <Ulfalizer> are any of those based on S?
Dec 03 09:33:56 <Ulfalizer> gotta go, bbl
Dec 03 09:34:42 <rburton> how bad would it be to make bb.utils.mkdirhier throw an exception if the path isn't absolute i wonder
Dec 03 09:40:55 <rburton> oh, B = S, and B is defaults [dirs]
Dec 03 09:41:02 <rburton> so it splats that directory around quite a bit
Dec 03 09:41:07 <rburton> probably worth a sanity check
Dec 03 10:34:49 <Ulfalizer> rburton: what do you mean by default [dirs]?
Dec 03 10:34:55 <Ulfalizer> +s
Dec 03 10:36:01 <Ulfalizer> +1 on sanity check either way
Dec 03 10:39:53 <rburton> there's a task flag called dirs which lists the directories it wants created
Dec 03 10:40:04 <rburton> B is the default, and B defaults to S
Dec 03 12:07:18 <mtownsend1973> Hi,  I'm trying to use the gitsm fetcher with something like gitsm://url-to-my.git;branch=xbuild-test-branch;protocol=ssh with git:// it checks out the right branch but with gitsm it checks out master, am I doing something wrong here?
Dec 03 12:21:20 <otavio> mtownsend1973: it seems like a bug to me; check the fetcher code inside bitbake to see if it covers the branch param
Dec 03 12:26:26 <mtownsend1973> otavio: There's no mention of branch in gitsm, does it not rely on the git fetcher for this or is it completely separate?
Dec 03 12:42:56 <otavio> mtownsend1973: I did not look at the source code, I suggest you to take a look and see if you can figure this out
Dec 03 13:41:40 <Ulfalizer> what basic packages (tar, etc.) are guaranteed to be available and do not require explicit native-* DEPENDS? how do i find out? what's the underlying mechanism?
Dec 03 13:42:19 <Ulfalizer> or *-native rather
Dec 03 13:47:54 <vmeson> s/guaranteed/required/ see apt-get/dnf/zypper/yum install on: http://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html
Dec 03 13:48:26 <vmeson> Ulfalizer: what do you mean by:  how do i find out? what's the underlying mechanism?
Dec 03 13:49:03 <Ulfalizer> vmeson: is the tar used the native host one? i had assumed yocto built some of the tools itself.
Dec 03 13:49:06 * vmeson wonders if he  missed some earlier discussion...
Dec 03 13:49:39 <Ulfalizer> i'm curious about 'ar' in this case
Dec 03 13:50:57 <Ulfalizer> more generally, when listing *-native packages as dependencies, do the installed tools end up in PATH and become available in tasks?
Dec 03 13:51:02 <Ulfalizer> maybe i'm missing something basic here
Dec 03 13:52:17 <Ulfalizer> and if so, is there a set of *-native tools that are guaranteed to be available (even if they're not available on the host)
Dec 03 13:52:20 <Ulfalizer> ?
Dec 03 13:56:17 <vmeson> Ulfalizer: I don't know if there are any implicitly available -native pkgs. I assumed that it would be all explict dependencies and that the pkgs needed on the host would be the only assumptions.
Dec 03 13:59:40 <rburton> Ulfalizer: ar is part of binutils, so we assume the host has one
Dec 03 13:59:47 <rburton> cant compile a compiler without a compler
Dec 03 14:07:04 <Ulfalizer> makes sense
Dec 03 14:08:06 <Ulfalizer> is there some  err_exit <msg>  or similar shell helper included by default?
Dec 03 14:12:12 <rburton> if you're running in a shell task, bberror/bbfatal/bbwarn/bbnote exist
Dec 03 14:12:25 <rburton> (meta/classes/logging.bbclass)
Dec 03 14:19:11 <Ulfalizer> is errors being printed to stdout what bitbake/yocto expects?
Dec 03 14:19:44 <Ulfalizer> or what's conventional
Dec 03 14:19:55 <Ulfalizer> bberror/bbfatal seem to do so
Dec 03 14:21:36 <Ulfalizer> guess it doesn't make much difference if it just prints to the log at the moment like the comment at the top says
Dec 03 14:22:25 <rburton> bberror/bbfatal will route the message through a pipe so it appears in the proper logs and causing a hard/soft error
Dec 03 14:23:00 <rburton> (so they're identical to bb.error bb.fatal etc as used in pythonic functions)
Dec 03 14:23:29 <Ulfalizer> ah, it's because i'm running an old yocto version :/
Dec 03 15:18:21 <Hunk> hello, i have a question. What is the best way to update an application level software on yocto ( for example a gui )
Dec 03 15:19:57 <rburton> Hunk: the package manager
Dec 03 15:20:12 <Hunk> smart package manager?
Dec 03 16:06:09 <bengardiner> hi guys -- thanks again for helping me out yesterday by confirming that my setup (multiple builders contributing to a shared sstate cache with a common prserv) was sane
Dec 03 16:07:19 <bengardiner> I'm still not out of the woods yet though -- so my next "am I crazy" question follows:
Dec 03 16:08:39 <bengardiner> with yocto daisy, is there anything that would prevent a file installed to ${sbindir} via a do_install() in a bbappend from getting deployed to the native sysroot when sstate cache satisfies a -native DEPENDS ?
Dec 03 16:09:26 <bengardiner> (I did have a missing FILES_${PN} += "${sbindir}/paxctl" in the bbappend; but even after adding that in I've still got a problem
Dec 03 16:22:03 <kergoth>  you shouldn't need tha tFILES bit
Dec 03 16:22:10 <kergoth> sbindir is included in the default FILES_${PN}
Dec 03 16:22:17 <kergoth> see meta/conf/bitbake.cnof
Dec 03 16:25:21 <bengardiner> true. then add FILES_${PN} truly had no effect
Dec 03 16:26:06 <kergoth> sstate is irrelevent here. whether it comes from sstate or not, the same files will end up in the sysroot
Dec 03 16:26:19 <kergoth> but no, a file in sbindir should, afaik, end up in the native sysroot sbin
Dec 03 16:26:21 * kergoth shrugs
Dec 03 16:27:07 <bengardiner> kergoth: OK...
Dec 03 16:27:10 <bengardiner> damn
Dec 03 16:28:02 <kergoth> examine the 'image' dir under workdir (${D}) and make sure the file is in usr/sbin there, then examine the native sysroot and make sure it ended up there
Dec 03 16:28:19 <kergoth> you could also examine the contents of the do_populate_sysroot sstate tarball
Dec 03 16:29:13 <bengardiner> roger. so what I've been doing is 'find tmp -name paxctl'. I get no hits in the cases where the build failed
Dec 03 16:30:08 <kergoth> that works too
Dec 03 16:44:01 <bengardiner> so, when it works, the file is in sbin/paxctl ; not usr/sbin/paxctl
Dec 03 17:42:05 <rburton1> khem: there?
Dec 03 17:52:42 <Kaa> Hello! How to avoid useless package rebuilding if ABI of depenencies is not changed?
Dec 03 18:03:04 <kergoth> Kaa: not possible at the moment. bitbake doesn't analyze task output, only uses task input via metadata checksumming. if recipe B depends on A and A changes and is rebuilt, B will be rebuilt, regardless of whether the rebuild of A changed anything
Dec 03 18:27:54 <bengardiner> kergoth: where would I find the "do_populate_sysroot sstate tarball" ?
Dec 03 18:28:02 <kergoth> your SSTATE_DIR
Dec 03 18:29:17 <bengardiner> roger. with a bunch of them there... do I use printsigs to figure out which one was created from this most recent build?
Dec 03 18:30:47 <kergoth> actually, thinking about it, you could examine the sstate manifest
Dec 03 18:30:58 <kergoth> i dont recall the path, but it's under tmp
Dec 03 18:31:21 <bluelightning> I'm not sure you'll get the signature from the manifest, but you will be able to see that from stamps
Dec 03 18:32:23 <kergoth> his issue is that a file he's installing isnt' ending up in the sysroot, just figured he could verify what was included by examining the manifest, but perhaps thats more trouble than its worth
Dec 03 18:32:55 <bluelightning> ah ok
Dec 03 18:33:42 <bluelightning> bengardiner: where is the file being installed to?
Dec 03 18:34:51 <kergoth> aside: anyone familiar with kernel-yocto know the best way to override the defconfig? i.e. where in its task graph would i have to inject to change the base configuration? or would i have to inject the custom defconfig as a fragment (ugly)?
Dec 03 18:36:09 <kergoth> the handling of meta is voodoo from my perspective :)
Dec 03 18:37:12 <bluelightning> kergoth: AFAIK you just put the defconfig in SRC_URI
Dec 03 18:37:35 <bluelightning> it won't be used verbatim, parts may be overridden based on e.g. KERNEL_FEATURES
Dec 03 18:38:20 <kergoth> yeah, i'd expect that, just want the option to override the baseline, expecting fragments and whatnot to build on that. i guess if i wanted to override, then i'd just have to use a monstrous fragment, but that wouldn't be ideal
Dec 03 18:38:37 <kergoth> wanting to fix the meta-mentor kernel_set_defconfig recipetool command for linux-yocto
Dec 03 18:46:25 <Kaa> kergoth: Can I use virtual packages to disable dependency rebuilding?
Dec 03 18:46:56 <kergoth> a virtual isn't special. it's just a naming convention used sometimes when multiple recipes provide the same functionality, so you can pick which one you want.
Dec 03 18:47:10 <kergoth> has nothing to do with how bitbake decides whether something needs rebulding
Dec 03 18:50:04 <Kaa> Hm, may be exist some ways - how to reduce updates size?
Dec 03 18:51:11 <Kaa> Because I work on very complicated project and we try switch to package distro to avoid big update images.
Dec 03 20:02:06 <bengardiner> bluelightning: paxctl being installed to ${sbindir} via a do_install() override in a bbappend
Dec 03 20:03:28 <bluelightning> bengardiner: is this a native recipe or one for the target?
Dec 03 20:03:51 <bengardiner> yes, native. It is getting built by DEPENDS="paxctl-native"
Dec 03 20:04:19 <bluelightning> hmm, in that case it should definitely show up in the sysroot
Dec 03 20:05:14 <bengardiner> when I -c cleansstate paxctl-native and rebuild, I find paxctl native in work/.../paxctl-native/.../image/sbin/paxctl
Dec 03 20:05:36 <bengardiner> and the DEPENDS="paxctl-native" bb can invoke paxctl from the path
Dec 03 20:06:05 <bengardiner> when I then rm -rf tmp and cleansstate the DEPENDS... bb and try to rebuild... paxctl is missing
Dec 03 20:06:57 <bluelightning> ok, what about under sysroot-destdir/ under the paxctl-native work directory ?
Dec 03 20:08:16 <bengardiner> not there, no
Dec 03 20:08:31 <bengardiner> now we're getting somewhere?
Dec 03 20:10:26 <bluelightning> ok, so that does at least line up with it not being in the sysroot
Dec 03 20:10:34 <bluelightning> even though it should be there...
Dec 03 20:10:45 <bluelightning> would you be prepared to pastebin your recipe?
Dec 03 20:11:11 <bengardiner> well -- I'm probably doing something wrong with the paxctl bbappend... yes, I should get them up somewhere . gist ok?
Dec 03 20:11:21 <bluelightning> yep that works
Dec 03 20:13:52 <bengardiner> https://gist.github.com/BenGardiner/907b96111d8b1331a90e -- if you please
Dec 03 20:29:47 <bluelightning> bengardiner: so there is something a bit wrong with the bbappend
Dec 03 20:29:51 <bluelightning> bengardiner: install ${D}/sbin/paxctl ${sbindir}/paxctl
Dec 03 20:30:24 <bengardiner> oh... I'm missing a ${D} in the dest aren't I?
Dec 03 20:30:38 <bluelightning> yep
Dec 03 20:30:47 <bluelightning> also you'll want -m 0755
Dec 03 20:30:52 <bengardiner> :) *facepalm*
Dec 03 20:31:03 <bluelightning> I'm a bit puzzled as to how that didn't cause do_install to just fail
Dec 03 20:31:40 <bengardiner> fakeroot?
Dec 03 20:32:21 <bluelightning> possibly, but I wasn't aware that it would let you overwrite files actually owned by root (or pretend to do so)
Dec 03 20:32:44 <bluelightning> I might go and check that now
Dec 03 20:34:39 <bluelightning> well, FWIW I was blocked from installing a binary over the top of one on my system here under pseudo, so I'm not sure that was it
Dec 03 20:34:44 <rburton1> bluelightning: interestingly i found out a do_install wasn't doing what i wanted, the log had a syntax error in but the task didn't fail
Dec 03 20:35:07 <fray> pseudo will report failures trying to overwrite files you don't ACTAULLY have access to
Dec 03 20:35:17 <bluelightning> rburton1: hmm :(
Dec 03 20:35:48 <bluelightning> bengardiner: btw that fakeroot stuff is unnecessary, do_install is already marked fakeroot (and virtual/fakeroot is already a dependency as a result)
Dec 03 20:45:40 <bengardiner> ok... I'm afraid I can't say why the fakeroot was introduced since I inherited the bbappend at one point. But I'm guessing it was added due to install to a path without ${D}
Dec 03 20:47:26 <bluelightning> does adding the ${D} fix it btw?
Dec 03 20:47:42 <bluelightning> I'm not sure how that could have broken it if so though
Dec 03 20:58:51 <bengardiner> I'm gonna try it and get back to you. repro of the issue requires build, clean, build so...
Dec 03 20:58:54 <bengardiner> :)
Dec 03 21:01:25 <bengardiner> I'm gonna try with https://gist.github.com/BenGardiner/907b96111d8b1331a90e#file-paxctl_0-9-bbappend
Dec 03 21:11:53 <bengardiner> I think I see why it needed fakeroot
Dec 03 21:11:54 <bengardiner> | NOTE: make -j 8 -e MAKEFLAGS= DESTDIR=/home/bengardiner/src/ln-manifest/stacks/raspberrypi-ln-testing/poky/build/tmp/work/x86_64-linux/paxctl-native/0.9-r0/image install | install -D --owner 0 --group 0 --mode a=rx paxctl /home/bengardiner/src/ln-manifest/stacks/raspberrypi-ln-testing/poky/build/tmp/work/x86_64-linux/paxctl-native/0.9-r0/image/sbin/paxctl | install: cannot change ownership of `/home/bengardiner/src/ln-manifest/
Dec 03 21:14:49 <bluelightning> it already has fakeroot though
Dec 03 21:14:56 <bengardiner> oh right
Dec 03 21:15:16 <bluelightning> if we didn't then nothing we installed and packaged would get the right permissions :)
Dec 03 21:15:29 <bengardiner> :)
Dec 03 21:39:51 <bengardiner> more weirdness (to me). that "install -m 0755 ${D}${base_sbindir}/paxctl ${D}${sbindir}/paxctl" line seems to expand to "install -m 0755 <build-dir>/tmp/work/x86_64-linux/paxctl-native/0.9-r0/image/<build-dir>/tmp/sysroots/x86_64-linux/sbin/paxctl <build-dir>/tmp/work/x86_64-linux/paxctl-native/0.9-r0/image/<build-dir>/tmp/sysroots/x86_64-linux/usr/sbin/paxctl"
Dec 03 21:42:11 <kergoth> that's expected with a native recipe
Dec 03 21:42:37 <kergoth> prefix for a native recipe isn't usr, it's the sysroot path + usr, to deal with relocation issues
Dec 03 21:43:16 <bluelightning> we really need a FAQ somewhere covering that...
Dec 03 21:45:00 <bengardiner> ok... hmmm. so the "oe_runmake DESTDIR=${D} install" above isn't installing to <build-dir>/tmp/work/x86_64-linux/paxctl-native/0.9-r0/image/<build-dir>/tmp/sysroots/x86_64-linux/ though , just <build-dir>/tmp/work/x86_64-linux/paxctl-native/0.9-r0/image
Dec 03 21:45:45 <bengardiner> above *it*
Dec 03 21:48:22 <bengardiner> should I do "oe_runmake DESTDIR=${D}${base_prefix} install" ?
Dec 03 21:58:04 <bluelightning> bengardiner: is there no prefix handling in the makefile?
Dec 03 21:58:57 <bengardiner> yeah -- $(DESTDIR) is in there but nothing else
Dec 03 21:59:20 <bengardiner> e.g. "$(INSTALL) -D --owner 0 --group 0 --mode a=rx $(PROG) $(DESTDIR)/sbin/$(PROG)"
Dec 03 21:59:29 <bluelightning> ok, then that may be the right thing to do in that case
Dec 03 22:00:16 <bluelightning> the other option for all of this is you patch the makefile to use ${sbindir} instead of /sbin (or sed it with a do_configure_prepend())
Dec 03 22:05:22 <bengardiner> thanks bluelightning, kergoth (again)
Dec 03 22:05:30 <bengardiner> I'll let you know how it turns out
Dec 03 22:05:34 <bengardiner> ttyl
Dec 03 22:05:41 <bluelightning> np - please do
Dec 04 02:10:08 <Marex> Hi
Dec 04 02:10:20 <Marex> shall I test my stuff against poky/master or poky/master-next now ?
Dec 04 02:10:26 <Marex> it seems master-next is dead since last month ...
Dec 04 02:11:16 <Marex> master it is I guess
Dec 04 02:12:30 <khem`> Marex: always master
Dec 04 02:12:56 <Marex> khem`: at one point, my nios2 junk was landing in master-next, so I stuck with it for a bit
Dec 04 02:13:16 <kergoth> master-next is temporary and rebased, not a good idea to use it directly unless you need to do integration testing imo
Dec 04 02:13:18 <Marex> khem`: how is my nios2 patch for meta-altera doing ? :)
Dec 04 02:13:18 <khem`> master-next is rebased
Dec 04 02:13:23 <khem`> often
Dec 04 02:13:49 <khem`> Marex: I have them applied locally but did not build yet
Dec 04 02:13:55 <Marex> khem`: :)
Dec 04 02:14:18 <Marex> I am about to do a bitbake -k world to see how things look
Dec 04 02:18:10 <khem`> brave
Dec 04 02:18:55 <Marex> khem`: well where do you think I keep finding those obscure nios2 failures ? :-)
Dec 04 02:20:16 <Marex> khem`: I have like 12 packages failing on nios2, mostly because they either need atomic ops (which nios2 doesnt have) or they are related to OpenGL which needs some floating point stuff that's missing too
Dec 04 02:22:00 <khem`> Marex: most of them should go into meta-nios2/altera layer
Dec 04 02:22:07 <khem`> unless its something common
Dec 04 02:22:15 <khem`> which you can always find
Dec 04 02:22:37 <khem`> when trying less treaded paths
Dec 04 02:22:52 <Marex> khem`: you mean the fixes ?
Dec 04 02:23:01 <Marex> khem`: the fixes should go into mainline
Dec 04 02:23:08 <khem`> yes fixes
Dec 04 02:23:15 <khem`> I agree they should go into mainline
Dec 04 02:23:22 <Marex> well that's what I am doing
Dec 04 02:23:31 <khem`> meanwhile we can stage them in meta-altera
Dec 04 02:23:44 <Marex> and if something's broken in oe-core, I'm submitting it for oe-core
Dec 04 02:24:23 <khem`> thats fine. may be thats not always the case
Dec 04 02:24:27 <Marex> how did you even land this job of maintaining meta-altera ? :)
Dec 04 02:28:46 <khem`> I have cyclone boards
Dec 04 02:29:16 <Marex> khem`: so you just rolled your own meta-altera ?
Dec 04 02:29:37 <khem`> it was yves who had a version
Dec 04 02:29:44 <khem`> and then I just gave shape to it
Dec 04 02:30:10 <Marex> oh good
Dec 04 02:31:00 <Marex> khem`: are you in touch with Yves ?
Dec 04 02:31:07 <khem`> Yes
Dec 04 02:31:18 <Marex> excellent
Dec 04 02:31:40 <Marex> http://rocketboards.org/foswiki/view/Documentation/YoctoDoraBuildWithMetaAltera this looks horrible btw. I think they should store metalayers out of the main poky tree
Dec 04 02:31:54 <Marex> and the build directory should certainly be out of the poky tree
Dec 04 02:32:06 <khem`> that veryyyy old
Dec 04 02:32:24 <khem`> it should be redone
Dec 04 02:32:28 * khem` makes a note
Dec 04 02:32:29 <Marex> khem`: read again ;-)
Dec 04 02:33:10 <Marex> khem`: it's just the name of the article which is wrong
Dec 04 02:33:23 <khem`> I know
Dec 04 02:33:50 <Marex> ok, but they're talking about yocto 2.0 there, so what's old about it ?
Dec 04 02:33:53 <khem`> I would prefer to have a git submodules
Dec 04 02:34:02 <Marex> oh I see
Dec 04 02:34:06 <khem`> the page itself
Dec 04 02:34:24 <khem`> content is right
Dec 04 02:40:06 <Marex> I see
Dec 04 02:57:04 <Marex> heh, looks like I might want to add nios2 into debian
Dec 04 02:57:09 <Marex> that'd be real weird
**** ENDING LOGGING AT Fri Dec 04 03:00:40 2015