**** BEGIN LOGGING AT Mon Oct 10 02:59:59 2016 Oct 10 05:34:10 halstead, ping Oct 10 05:34:22 Hello armpit Oct 10 05:34:27 outside Riga to help setup Oct 10 05:34:49 jefro said 7:30 Oct 10 05:35:33 armpit, I'm in Oregon but will be supporting today's effort as best I can. I think jefro will be there shortly. Oct 10 05:36:00 oh, thought you where going to be here Oct 10 05:38:16 armpit, I'm not feeling well. I would have been completely worthless after a long flight. Oct 10 05:38:32 ah, take care of yourself Oct 10 05:55:47 Jefro, do the rooms need help setting up? Oct 10 05:56:28 sure.. run away Oct 10 06:16:50 morning! Oct 10 07:13:50 are there any of the people working on meta-qt5 here? Oct 10 07:14:14 in that case; are there any plans to make the sdk stuff work without having to run qtcreator from a terminal where you source the environment-setup script? Oct 10 08:43:20 I'm trying to make the core-image-sato build a little faster and smaller by making the vala dependency in vte optional... but it's proven to be a little tricky Oct 10 08:44:03 vala.bbclass adds vala and vala-native to DEPENDS unconditionally Oct 10 08:45:06 it does not seem possible to conditionally inherit a class (see my attempt at http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=jku/vte-vala) Oct 10 08:47:35 I guess my only real option is to not depend on vala class but copy paste the useful bits to the vte recipe? Oct 10 09:57:54 Hi, Oct 10 09:57:54 Are Poky release and oe-core release in sync? Oct 10 09:57:54 i.e oe-core releases v2.2 in October. And poky v2.2 is released with v2.2 oe-core? Oct 10 10:06:48 basically, yes Oct 10 10:07:14 we have too many names for things, adding confusion by having out of sync releases would be madness Oct 10 10:13:32 Crofton|work: thanks Oct 10 10:52:57 ls -l Oct 10 10:53:03 wrong window, sorry Oct 10 10:53:33 but, I do have a question: I want to run ldd on target platform. How do I find out what I have to bitbake in order to have ldd built? Oct 10 10:54:40 hyde: its part of glibc, so just install the "ldd" package Oct 10 10:55:46 bitbake ldd says "nothing provides ldd" (note, I am oe/bitbake n00b) Oct 10 10:56:48 sure Oct 10 10:56:53 you build recipes, and install packages Oct 10 10:57:01 hyde: you can also just run the loader directly with --list "$argument", e.g. /lib/ld-linux-x86-64.so.2 --list /bin/bash Oct 10 10:57:08 pretty hard to not build glibc, so you've already got it built Oct 10 10:57:23 fwiw the way to look this up is $ oe-pkgdata-util find-path /usr/bin/ldd Oct 10 10:57:24 ldd: /usr/bin/ldd Oct 10 10:59:00 rburton: thanks, found it (it's built, it just wasn't in the image, worked after scp) Oct 10 10:59:46 What I am doing is trying to get Qt X11 platform plugin libqxcb.so to work... Oct 10 11:00:59 so next is figuring out why a bunch of libs are missing, and how do I get them added to the image Oct 10 11:17:23 using externalsrc.bbclass a bit... looks like someone wanted to add support for extra SRC_URIs for externalsrc recipes Oct 10 11:17:44 there's the local_srcuri variable in the class. however I don't think it's working... Oct 10 11:18:21 nothing is actually hooked up to process SRC_URI. do_fetch and do_unpack are empty Oct 10 11:20:19 ok, I am running this command in build dir: $ oe-pkgdata-util find-path /usr/lib/libxcb-shape.so.0 Oct 10 11:20:40 adn get output: libxcb-shape: /usr/lib/libxcb-shape.so.0 Oct 10 11:21:54 but running bitbake libxcb-shape gives error: ERROR: Nothing PROVIDES 'libxcb-shape'. Close matches: libxcb-native Oct 10 11:22:42 can someone shed a tiny bit of light on this? I guess I am being mixed up between what oe-pkgdata-util does, and what bitbake does, or...? Oct 10 11:28:36 hmm, maybe just libxcb to have all the libxcb-XXXX... Oct 10 11:28:40 nevermind, SRC_URI and externalsrc seem to work just fine, proably just an sstate problem Oct 10 11:29:23 hyde: I'm not sure about the terminology but I think a package "rule" can create many package binaries Oct 10 11:30:33 if you do "bitbake libxcb" that will create libxcb-dev and bunch of other packages Oct 10 11:33:24 hyde: find-path tells you what *package* contains the file, not the recipe name you can pass to bitbake. Oct 10 11:33:35 note that if pkgdata knows about it, then you've already built it Oct 10 11:34:04 a recipe generally creates many packages, for example libfoo libfoo-doc libfoo-dbg libfoo-dev libfoo-locale-en-gb Oct 10 11:34:13 it's like debian source and binary packages... Oct 10 11:34:14 for the library, the docs, the debug info, the headers, and the translations specifically Oct 10 11:37:14 and what do I add to DEPENDS in a .bb file, packages or recipes? Oct 10 11:37:18 looks like recipes Oct 10 11:38:05 yes, depends Oct 10 11:38:08 argh Oct 10 11:38:09 recipes Oct 10 11:39:22 I wonder why meta-qt5 doesn't install anything under /usr/lib/qt5/plugins in image Oct 10 11:39:41 (that's where Qt looks for platform plugin .so) Oct 10 11:40:29 ...and what would be the proper way to have these installed (they are built, now I copied them by hand to target board, but I am missing some libraries, which the above libxcb stuff is all about) Oct 10 12:22:05 oh the urls are broken, damn Oct 10 12:23:07 rburton: depends are recipes and rdepends ar packages, right? Oct 10 12:23:45 yes Oct 10 12:55:33 any idea why an EFI image generated by wic would result on an sdcard not recognized as UEFI by the target BIOS ? Oct 10 13:23:11 I'm setting up a continuous deployment system with yocto and I have a hard time figuring out how to let bitbake use my previously build packages when assembling a new image. Essentially I would like to first build all changed packages, upload them into my debian repository and then from that repository build an image. How would you recommend I perform the last step? (build an image from a set of packages) Oct 10 14:00:40 ecdhe: you want to persist the sstate cache between builds, not the built packages. Oct 10 14:13:21 Im assuming you miss-tabbed my nick :) Oct 10 14:13:51 is the build from sstate cache to package deterministic? as in, will I always get the exact same packages from it? Oct 10 14:14:17 moreover, I just had an issue when building were bitbake recommended me to clear my cache, which would mean it wouldn't work Oct 10 14:14:30 I think the answer is probably "yes unless there's a bug or something incredibly unlikely happens". Oct 10 14:14:39 :/ Oct 10 14:14:51 I would like to, once I have built my packages, use the same definition everywhere Oct 10 14:15:02 Basically, it's intended to be deterministic, but sometimes we find bugs. Oct 10 14:15:07 otherwise I might get my running systems divergent from the newly produced systems Oct 10 14:15:34 yeah. In theory, if you have the same configuration, you should get deterministic output, except when there's bugs. Which there sometimes are. Oct 10 14:16:02 so what happens between the sstate cache and the finished package, what steps are performed? Oct 10 14:17:46 this is a non-trivial question to ask, because sstate can cache multiple steps in a package build. Oct 10 14:18:07 In theory, I think, if you have a full build in sstate, the final package is basically just the RPM or whatever. Oct 10 14:18:17 And if you have sstate for the filesystem, you might just unpack your previously-built filesystem? Not sure. Oct 10 14:18:20 Memory vague. Oct 10 14:18:36 but if the sstate cache is a cache, it does not solve my issue Oct 10 14:18:53 I want the packages I have on my deployed systems to be _exactly_ the same as the ones I'm using to build my package Oct 10 14:19:43 also, if it is a cache, it caches something, but I havent understood what yet Oct 10 14:19:52 Okay, so... Imagine that you have two sets of binaries, and they're byte-for-byte identical, but one set has newer timestamps in the filesystem. Is that exact enough? Oct 10 14:19:58 ecksun: if you just need packages then sstate cache contains the final packages and it will just extract them Oct 10 14:20:07 It caches any and all parts of the build process. Oct 10 14:20:16 ie bitbake some-image; rm tmp ; bitbake some-image Oct 10 14:20:24 seebs, yes, but I dont want anythign from the build-process, I want the final output binary Oct 10 14:20:27 So let's say you have a typical build. Unpack, apply patches, run configure, compile, install. Oct 10 14:20:30 the second run will just extract all the packages from the build and create the image Oct 10 14:20:53 sstate will have a cachecd copy of the unpacked-but-not-patched files, the patched files, the configure output, the compile output, and the final image stuff created by the install. Oct 10 14:21:02 (erm, extract all the packages from the sstate) Oct 10 14:21:05 s/ecd c/ed c/ Oct 10 14:21:26 And if you nuke sstate and rerun the build, you should get identical (except for, say, timestamps) packages every time. Oct 10 14:21:47 should get :D Oct 10 14:21:50 It may be that you would be better off using bitbake to build RPMs or whatever package format you want, and then assembling filesystems from those. Oct 10 14:21:59 thats what I would prefer Oct 10 14:22:13 Yeah. You are not required to use bitbake for your final image creation if you don't want to. Oct 10 14:22:28 well, what I would like to is hook into the middle of it Oct 10 14:22:43 in between the "compile output" and the "final image stuff" Oct 10 14:23:05 What do you want to do at that point? Oct 10 14:23:06 ecksun: fundamentally speaking, images are built from packages, and packages can either come from an actual build, or a previous actual build going into sstate and being extracted again. the resulting images *will* be identical. Oct 10 14:23:48 seebs, use the previously built packages Oct 10 14:24:01 rburton, alright Oct 10 14:25:51 I mean, when you say you want to "hook into the middle of it", what do you want to do differently from what bitbake already does? Oct 10 14:26:09 I dont want to rebuild packages every time Oct 10 14:26:16 I want to use my repository for everything Oct 10 14:26:27 basically, build -> upload to repo -> package from repo into image Oct 10 14:26:42 this might be what bitbake does, and kind of sounds like to from rburton Oct 10 14:28:07 Ahh, yes. That is indeed what it would usually do. Oct 10 14:28:45 but I'm very uncomfortable with letting a cache (which is what I understand the sstate cache folder to be) be the cannonical definiton of my system Oct 10 14:29:01 Ahh, I see. Oct 10 14:29:03 It's not! Oct 10 14:29:09 the sstate cache is not a cache? Oct 10 14:29:11 The *definition* is the recipes+bitbake. Oct 10 14:29:17 no Oct 10 14:29:18 Oh, no, it is a cache. It's not the definition. Oct 10 14:29:20 well Oct 10 14:29:27 Im testing my output Oct 10 14:29:28 not my source Oct 10 14:29:29 The definition is the files used to build the cache. The cache is purely an optimization. Oct 10 14:29:37 In theory it changes nothing (except timestamps). Oct 10 14:29:50 yeah, in theory, but that assumes that all builds are reproducable Oct 10 14:29:54 which I do not dare to do Oct 10 14:30:07 Well, in theory, theory and practice are the same! Oct 10 14:30:11 :D Oct 10 14:30:38 that is why I want to use my final output packages to construct my images, because that is going to be the exact same packages I will install on my running systems Oct 10 14:31:04 moreover, though that might be a separate discussion, I'm hoping I can include packages not defined with recipes into this Oct 10 14:31:08 So you want some way to ensure that the packages that don't change. Oct 10 14:31:11 Hmm. Oct 10 14:31:12 yes Oct 10 14:31:15 Well, not directly with bitbake. Oct 10 14:31:43 :( Oct 10 14:31:43 Hmm. So what you sort of want is a way to freeze a package and say "even if other things change that imply this package should change, keep using this version we built way back here." Oct 10 14:31:52 yes, more or less Oct 10 14:32:05 and any change to the package should consistute a new version Oct 10 14:32:07 Huh. Oct 10 14:32:07 *thinks* Oct 10 14:32:16 Okay so I can see a way to make this work, and it's horrible but it might work. Oct 10 14:32:25 that doesnt sound good: D Oct 10 14:32:37 Yeah, you're outside the designed use cases, I think. Oct 10 14:32:44 yes, I get that feeling Oct 10 14:32:52 So, imagine a thing which takes an image spec, and makes from it a New Layer. Oct 10 14:32:57 bitbake does not feel optimized for a continuous development workflow Oct 10 14:33:00 giving each package a new version is basically what PRserv does Oct 10 14:33:28 And the new layer has a single recipe which installs the sysroots and dev tree from that image, and which lists itself as PROVIDES all the things it provides, and as PREFERRED_PROVIDER for all those things. Oct 10 14:33:34 neverpanic, I dont know much about it, but was hoping it could help me figure out when to bump versions or not Oct 10 14:33:44 So if you have this layer, it will pick all that stuff up from a tarball and use it unconditionally. Oct 10 14:33:48 If you want to not recompile a certain package even when one of its dependencies changes, may I suggest using something else, but not bitbake? ;-) Oct 10 14:33:51 ecksun: sounds like you want to use locked signatures to ensure that nothing gets rebuilt. if the hash is the same and you pull from the same sstate cache then you're forced that the same binaries are used. Oct 10 14:34:43 neverpanic, no, I dont mind recompiling when dependencies change, then its just a new version and should be treated as such Oct 10 14:34:49 That being said, reproducible build results would be great, make it so! ;-) Oct 10 14:35:02 ecksun: Yes, that's what PRserv already does, I think. Oct 10 14:35:18 neverpanic, yes, thats my very limited understanding as well, I will probably look in to it soon Oct 10 14:35:54 seebs, there are several things I dont grasp enough to understand your suggestion :( Oct 10 14:36:07 that's probably for the best, I suspect it's a really bad idea. Oct 10 14:36:11 :D Oct 10 14:37:23 rburton, hmm, could be, but once again, I dont want to use a cache for anything persistent Oct 10 14:37:43 I will check out locked signatures though, to see what they are Oct 10 14:38:10 I would like to better understand what happens when bitbake assembles the final image, how can I go about understanding that? Oct 10 14:38:13 ecksun: maybe we shouldn't have used the word cache. just a package index isn't enough to build an image. Oct 10 14:38:14 The intent is that rebuilding packages should produce identical results unless Something Changed. And if something changed, the cache would be ignored anyway. Oct 10 14:38:25 rburton, oh, thats interesting, why is that not enough? Oct 10 14:38:43 because theres lots of metadata that isn't in a rpm/deb/whatever Oct 10 14:38:48 seebs, yes, that would be awesome, however I cannot assume that, especially not for my own packages, sadly :( Oct 10 14:38:49 ... I just realized, I actually do not currently have a copy of bitbake/oe-core on this machine to look at. Oct 10 14:38:57 rburton, oh, thats worrysome, metadata like what? Oct 10 14:39:01 In that case, yeah, you need some kind of checksum thing. Oct 10 14:39:07 ecksun: like what goes into an image, for a start Oct 10 14:39:19 the list of packages basically? Oct 10 14:39:32 and all the scripts to run, and all the native dependencies required to run those scripts Oct 10 14:39:50 which scripts to run? I thought all such things were included in package definitoins? (pre-install scripts and such) Oct 10 14:39:56 image-wide scripts Oct 10 14:40:09 can you give me an example? Oct 10 14:41:20 if there are image-wide scripts thats problematic to me, because I have no way of applying changes to such scripts on my running systems (if they are not part of a package) Oct 10 14:41:52 Yeah, look at post-install scripts. They can do lots of weird stuff. Oct 10 14:41:56 So yeah, that is a problem for you! Oct 10 14:42:09 ... Not that I have a solution in mind, but at least you know about it. Oct 10 14:42:10 but should they not be part of one package or another? Oct 10 14:42:23 Oh, I see. They are, but they can have effects on other things. Oct 10 14:42:42 Like, some of the stuff that gets done for secure systems might go mess with ssh config, even though it's not part of the ssh package... Oct 10 14:42:44 as I said, my main worry is that my production systems will diverge from my newly produced systems Oct 10 14:43:12 seebs, yeah, thats an issue I dont have a really good solution to Oct 10 14:43:22 package postinsts are obviously in the package, its more image scripts that you may or may not have Oct 10 14:43:23 debians conf.d folders work quite fine though, in most cases, I think Oct 10 14:43:43 rburton, yes, I need to find out if I have any of those and try to remove them Oct 10 14:43:47 Well, one strategy would be to just add a disclaimer in your docs. Oct 10 14:43:49 or understand how they work at the very least Oct 10 14:43:59 DISCLAIMER: Images may not be reproducible or identical. SUCK IT UP PRINCESS. Oct 10 14:44:04 :D Oct 10 14:44:31 ecksun: the default ones are just stuff like "run ldconfig" or "if debugging enabled, wipe root password" Oct 10 14:44:34 ... Of course, now that I'm more likely to be using than making yocto-based stuff, I should probably advise against this. Oct 10 14:44:51 rburton, okay, how can I find them? Oct 10 14:45:29 rburton, could you link me to some documentation that details that behaviour? Oct 10 14:46:22 I have been considering using https://wiki.debian.org/Multistrap as I think that might do what I want Oct 10 14:46:31 but I would prefer to use bitbake proper if possible Oct 10 14:52:55 btw, thank you all for your help, it has given me a lot of insight Oct 10 14:53:31 np Oct 10 14:57:37 as you guys suggested, PR service and checksum might help me figure out at least what packages to rebuild or not Oct 10 15:15:35 ERROR: core-image-sato-1.0-r0 do_image: Taskhash mismatch 279d7fa1310f436e0058f1742627a68b versus 0fbf14dc55abb7932bb8e70145c26691 for /scratch/dogwood/minnowmax-psplash-test/poky/meta/recipes-sato/images/core-image-sato.bb.do_image Oct 10 15:15:36 * kergoth sighs Oct 10 15:40:43 I would like to find the source of do_rootfs, how do you recommend I go about doing that? Oct 10 15:41:10 read rootfs.bbclass. Oct 10 15:41:18 or rather, image.bbclass and rootfs_*.bbclass Oct 10 15:41:40 how do I know to search in there? Oct 10 15:42:05 every image recipe has 'inherit image' in it Oct 10 15:42:10 which tells you to read image.bbclass Oct 10 15:42:16 aha, okay Oct 10 15:42:20 cool Oct 10 15:42:22 so read the recipe, and go from there :) Oct 10 15:42:28 make sense :) Oct 10 15:42:56 alternatively, inspect bitbake -e recipename, which has all the variables and functions, but it's not broken up, so there's a lot to go through Oct 10 15:43:27 yeah, that seems more or less equivalent with what I did: grep -irIn do_rootfs Oct 10 15:45:21 so Im guessing this is the definition: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image.bbclass#n199 Oct 10 15:45:44 Probably! Oct 10 15:46:10 You wanna look at bitbake -e output at least a little to be sure, because conceivably you could have an image that inherited something else that overrode that. Oct 10 15:46:43 good point Oct 10 15:46:57 I'm also noticing that my local image.bbclass is very different from the one I just linked, need to figure out why that is Oct 10 15:47:04 indeed, -e shows you the final results, including appends Oct 10 15:47:05 different branch? Oct 10 15:47:50 probably, from which branch is yocto released? Oct 10 15:49:28 there is no generic release branch. development occurs on master until it's frozen, then it's branched off to a named branch for that release codename Oct 10 15:49:35 master right now is 2.2 Oct 10 15:50:23 kergoth, I see, thanks Oct 10 15:50:49 just look at your local layers and see what branch they're on, presumably they're either on a stable branch for a previous release, or an old master Oct 10 15:51:17 jupp, Im on 2.0.2, which matches well Oct 10 15:51:21 so you were correct Oct 10 15:59:00 Hi guys, I'm having an issue with useradd it doesn't seem to be compatible with package management *.deb. Has anyone encountered this? Oct 10 15:59:30 it works for me Oct 10 15:59:34 I messed with that just the other day Oct 10 15:59:50 are you using package management and deb files tho? Oct 10 15:59:59 yes Oct 10 16:00:02 both Oct 10 16:00:45 https://bitbucket.org/snippets/scypho/EBoqL Oct 10 16:00:46 I get this error: "Unable to read tmp/work/[machine]/[image name]/[version]/apt/preferences.d - Directory exists (2: No such file or directory) Oct 10 16:00:55 haha, awesome error Oct 10 16:01:05 lol yeh.. Oct 10 16:01:09 fwiw deb is the least-tested package format Oct 10 16:01:23 I probably can't help you more than that, sadly :( Oct 10 16:01:37 ... that's a very odd error. Oct 10 16:05:58 thanks for the snippet. Is your recipe named useradd? Just curious Oct 10 16:06:09 Mine has a custom name but inherits from useradd Oct 10 16:09:18 Geoff_, no, mosquitto_%.bbappend i think (Am on phone now, so cant check) Oct 10 16:11:47 if you pm me in a couple of hours I can provide the rest Oct 10 16:32:35 Hmm, I'm having to bitbake an image inside a vbox vm with a dynamic hdd Oct 10 16:32:49 however bitbake is halting due to running out of space, any idea? Oct 10 16:33:39 CTtpollard: probably ran out of space in your VM? Oct 10 16:33:45 check with df Oct 10 16:33:46 don't use a dynamic hdd, fix virtualbox, get more space, .. Oct 10 16:34:17 Anticom: the hdd is dynamic so should balloon when needed Oct 10 16:34:40 CTtpollard: nope Oct 10 16:34:41 which it has been doing, but has now stopped (the media hosting the hdd has 80% space left) Oct 10 16:34:55 there's a limit to it too (iirc 10GB by default) >>> #vbox Oct 10 16:35:02 you can turn off the check Oct 10 16:35:15 rburton: won't help when there's no space left i suppose Oct 10 16:35:32 CTtpollard: just check how much space is *actually* left inside your vm Oct 10 16:35:35 no, if its actually full you'll get comedy errors as 20 gcc invocations all run out of space Oct 10 16:35:38 instead of making assumption Oct 10 16:35:40 s* Oct 10 16:35:49 but they might be doing file system games which trip up the space detection Oct 10 16:35:54 I suppose with a dynamic hdd it expects you to just blindly try writing data even if there's no space for it? seems a bit odd. it should act like it has more space than it does, instead Oct 10 16:35:59 Anticom: less than a gig, I know how much is left I'm just curious to why it's not expanding anymore Oct 10 16:36:10 CTtpollard: #vbox Oct 10 16:36:41 been there, done that. Even dynamically allocated hdd's in vbox have a limit you can set. You've probably reached that very limit Oct 10 16:36:49 CTtpollard: TL;DR; shut down vm, use VBoxeManage to enlarge your vdd, boot gparted, enlarge partition to new vdd size, reboot into your OS Oct 10 16:37:31 BB_DISKMON_DIRS defaults to 1GB of space Oct 10 16:42:17 Anticom: ok, I'll look to resize it into a new dynamic disk with a higher threshold Oct 10 18:16:14 Any experts out there regarding tweaking UBoot configuration for a board (e.g. BeagleBone?). I am working on a writing project that would show how UBoot might run some alternative code if a board fails to boot a certain number of times in a row. I am seeking out a subject matter expert for this that I might be able to talk with... thanks. Oct 10 19:20:26 hi everyone Oct 10 19:20:49 im having some trouble bitbaking an intel edison yocto image Oct 10 19:21:15 libwebsockets checksum mismatch Oct 10 19:22:24 is anyone avaiblable to help? I'm new to this and so frustrated by the process Oct 10 19:23:14 is anyone avaiblable to help? I'm new to this and so frustrated by the process #yocto Oct 10 19:31:31 so, just a note, I can't help much with that, but I can let you know that IRC is pretty asynchronous, it may be an hour or five before a response shows up. Oct 10 20:19:13 is there an predefined image type that could be built directly instead of having to install using image-live ? hdddirect looked like it could be what I'm looking for, but it is not documented much, and does not appear to support UEFI ? Oct 10 20:19:51 can I have a recipe which does do_install_class-native() { Oct 10 20:20:30 can I have a recipe which does do_install_class-native() routine for native and not do make install, but for do_install_class-target() does a regular make install? Oct 10 20:21:58 in fact that hdddirect image can't even be booted in CSM mode :) Oct 10 20:25:13 davis: at worst, you could use a different recipe for your native case ? Oct 10 20:27:17 i could. I'm curious though. if you have a do_install, does it simply work by calling that instead of make install or is that something which is invoked post make install? Oct 10 20:28:11 when I first started this thing, install was inherit in make, i've broken that out and made targets for install so it builds a normal system. Oct 10 20:38:52 do_install is supposed to call "make install" when it's the way to install Oct 10 20:39:45 classes like autotools do that for you, but for a simple Makefile-based software, you have to write do_install yourself **** ENDING LOGGING AT Tue Oct 11 02:59:58 2016