**** BEGIN LOGGING AT Fri Mar 03 03:00:01 2017 Mar 03 10:34:25 kanavin: so ovmf still need ossp-uuid Mar 03 10:34:44 i wonder if that can be ported to libuuid or something Mar 03 10:36:34 rburton: yes, I dropped the removal patch already Mar 03 10:36:44 rburton: now looking into remaining issues, which are multilib Mar 03 10:36:53 the esdk fails are all due to master too Mar 03 10:37:35 rburton: yep, and there's also a stripping fail which is debian 9 (testing) specific Mar 03 10:37:41 I'm seeing it here too Mar 03 10:44:21 hello Mar 03 10:45:17 is there a method to find out what recipe/package provides a binary in yocto? for example adduser/addgroup or useradd/groupadd Mar 03 10:46:55 i know that the former pair is provided by busybox but i want to remove busybox since we've found that is not as full-featured as their counterparts Mar 03 10:48:11 on target, use the package manager Mar 03 10:48:15 on the build host, use oe-pkgdata-util Mar 03 10:48:27 thank you rburton Mar 03 10:53:51 rburton, oe-pgkgdata-util seems to apply only to recipes that i already use Mar 03 10:54:19 yes Mar 03 10:54:21 rburton, my problem is to find out what new recipe i need to add Mar 03 10:54:34 to provide the missing binaries Mar 03 10:54:50 $ dpkg -S /usr/sbin/useradd Mar 03 10:54:51 passwd: /usr/sbin/useradd Mar 03 10:54:59 if you want proper useradd, look on your host :) Mar 03 10:55:23 rburton, sure, but shadow-utils does not seem to be present Mar 03 10:55:56 because my host is fedora 23 Mar 03 10:56:33 so you suggest i should also investigate on a debian-based system? Mar 03 10:56:50 i have one little ubuntu server install under the desk Mar 03 10:57:37 not really used, until no Mar 03 10:57:41 w Mar 03 11:16:32 RP: should BB_CURRENT_MC be set anywhere? I updated to bitbake+OE-core master just now, and it only seems to be used in meta/conf/bitbake.conf:require conf/multiconfig/${BB_CURRENT_MC}.conf Mar 03 11:18:08 pohly: bitbake sets it Mar 03 11:18:35 pohly: even if its unset, it looks for a strange but harmless file Mar 03 11:18:52 Argh, I checked out "master", not "origin/master". My bad. Mar 03 11:18:55 joshuagl, rburton: I've fired a new master test build on the new AB. Hoping for green, finally Mar 03 11:20:16 RP: ACK Mar 03 11:20:22 RP, rburton: BuildLog could still be a mess as haven't had chance to deploy my fix Mar 03 11:57:26 back: is there a guarantee that if a package provides a file on a debian-based system it will provide same file in a Yocto build? I know this is not the case for Fedora packages Mar 03 11:57:51 and my expectation is that same is true for a Debian-based system Mar 03 12:00:58 there is no such guarantee Mar 03 12:01:30 joshuagl, thank you Mar 03 12:01:53 is there a way to see if a binary is provided by any of the poky distro packages? Mar 03 12:02:43 you can query for files in packages you've built with oe-pkgdata-util Mar 03 12:03:10 joshuagl, my problem is that the packages i've built do not provide all the binaries ia want Mar 03 12:03:19 it's the missing binaries i'm interested in Mar 03 12:04:15 I'd guess, which is all I can do with the current information, that either a) the software isn't configured to build those binaries b) the binaries are split into a separate package Mar 03 12:04:31 what's the recipe in question? and the missing binaries? Mar 03 12:05:36 joshuagl, here's the story: i want to remove busybox from my images. i want to replace the binaries that are currently provided by busybox with their alternatives provided by other packages Mar 03 12:06:11 i have guessed a set of packages that provide a part of those binaries, but there are a few left out Mar 03 12:06:41 currently my approach is: i add packages to the image and build the image. then i check if the binaries were actually added Mar 03 12:06:46 well, chec Mar 03 12:06:47 if not i try another package Mar 03 12:07:06 and for some, i have to try again Mar 03 12:07:20 the question is if there is a way to know, instead of guess Mar 03 12:08:01 I'd check the output of the recipes, oe-pkgdata-util is useful there Mar 03 12:08:44 because recipes can split their output into multiple packages, alternative mechanism means the busybox version of a utility may be preferred, etc Mar 03 12:08:46 joshuagl, my understanding is that oe-pkgdata-util looks only at the recipes selected for building Mar 03 12:09:13 oe-pkgdata-util looks at the generated pkgdata for all built recipes Mar 03 12:09:20 ok Mar 03 12:09:25 but by then is too late :) Mar 03 12:09:41 i'd like to know this before building Mar 03 12:10:05 so that i add exactly the recipes i need to the image Mar 03 12:10:22 you add packages to images, not recipes Mar 03 12:10:39 joshuagl, i stand corrected Mar 03 12:11:13 unfortunately there's no easy way to know ahead of time, for several reasons Mar 03 12:11:20 the closest you can get is reading recipes Mar 03 12:11:33 at least that I'm aware of :-) Mar 03 12:11:39 i get that Mar 03 12:12:12 unfortunately it's hard to look at the recipe and figure what binaries are produced, or at least that's my understanding Mar 03 12:12:18 it is Mar 03 12:13:00 if a recipe is building the same upstream source as the package which provides the file in debian, you can infer that some configuration decision in the recipe results in the binary not being installed Mar 03 12:14:03 right, but this compare thing is a painfull process Mar 03 12:14:41 there's a goal to make it easier to replace busybox, but we aren't there yet Mar 03 12:14:53 do you see any way such a feature could be added to Yocto? Mar 03 12:15:10 it seems an impossible task Mar 03 12:15:22 (to look at hte layers and figure the binaries) Mar 03 12:16:19 for the same reason i can not look at the recipes and see what binaries come out of it Mar 03 12:17:30 about busybox replacement, can i help? :) Mar 03 12:19:02 ahhrhg. esdk builds went green but I broke sdk Mar 03 12:23:01 joshuagl, rburton: restarted the build with a fix Mar 03 12:23:08 * RP -> gone Mar 03 12:25:58 Is anyone seeing runstrip fail during do_populate_sysroot for any tasks on current master? I've got a new and interesting error message I've not seen before Mar 03 12:30:15 above in the logs kanavin was talking about strip and debian9 Mar 03 12:30:51 ant_work: I'm running Debian 9 as well, I'll look for that thanks! Mar 03 12:31:06 seems specific issue :/ Mar 03 12:35:19 kanavin: Does this error look similar to what you've seen on Debian 9? http://pastebin.com/UNBYKAps Mar 03 12:36:14 How can it be that my yocto iso is 5.5gb.... i only added 1.5gb off packages... Mar 03 12:37:51 maka_: mount and ncdu it :) Mar 03 12:38:24 ncdu? Mar 03 12:39:36 ah got it Mar 03 12:41:20 paulbarker: yes Mar 03 12:41:46 seen on the yocto AB too, when the build lands (randomly) on debian testing Mar 03 12:42:47 kanavin: Strangely, the build seems to be continuing despite the do_populate_sysroot error Mar 03 12:42:57 LetoThe2nd: ncdu on the rootfs.img? Mar 03 12:43:08 I've also seen the same message for gcc-cross-arm Mar 03 12:43:21 paulbarker: yeah I guess stripping error is not considered an error Mar 03 12:43:35 maka_: ncdu on the mounted rootfs Mar 03 12:44:00 yea i mounted it on /mnt/disk Mar 03 12:44:03 now im in that folder Mar 03 12:44:08 and now i have to pick something Mar 03 12:44:18 Which im guessing should be rootfs.img Mar 03 12:44:31 kanavin: I'll investigate further when this build finishes. It's running slowly, unsure if that's performance regression due to recipe-specific sysroots or if it's a HW issue with my disk array Mar 03 12:44:38 Oh nvm, i can't even pick anything Mar 03 12:45:05 LetoThe2nd: so, i used ncdu, now i see rootfs.img has 5.1gb. What do i do now? Mar 03 12:45:34 maka_: i'd try to loopmount the image and repeat :) Mar 03 12:45:51 What is it supposed to do if i may ask? Mar 03 12:46:18 maka_: another option would be to look at the deploy/packages and check what the sized ones are. Mar 03 12:46:29 maka_: what do you mean, what is it supposed to do? Mar 03 12:46:39 make, iso's should be mounted with -o loop Mar 03 12:46:54 well, there are 2 packages that are pretty big, 500mb and 600mb Mar 03 12:46:57 maka_, ^ Mar 03 12:47:07 cornel: i used that yes ^^ Mar 03 12:50:05 cornel: I see no way that such a feature could be added. The packages a recipe creates, and their contents, can't be determined until the build has been performed. Mar 03 12:50:22 thank you joshuagl Mar 03 12:51:05 cornel: as for the effort of making busybox easier to replace, I'd imagine help would be welcome. It's not something I've been involved in, I don't even know whether anyone is actively working on it Mar 03 12:52:22 joshuagl, can you poinjt me to a start link? maybe a ticket? Mar 03 12:52:36 i just tried searching the database, to no avail Mar 03 12:52:43 pfff Mar 03 12:54:12 you may find something on the list archives Mar 03 12:55:30 probably the easy thing to do is just create a ticket Mar 03 12:56:00 but anyway replacing busybox is not an easy task Mar 03 12:56:33 it's hard for one project, and it's harder for a big pubic project, in our case Yocto Mar 03 12:57:39 indeed Mar 03 12:58:02 theoretically it's as simple as making coreutils have a higher alternatives priority, but theory rarely reflects reality Mar 03 13:00:01 joshuagl, but coreutils does not provide all binaries provided by busybox, isn't it? Mar 03 13:00:47 I have a long term plan to get a system booting with toybox, with no busybox at all, when toybox hits 1.0.0 Mar 03 13:01:03 but for now toybox doesn't provide everything in busybox either Mar 03 13:04:55 the replacement i have in mind is with the GNU counterparts, not a different licensed busybox :) Mar 03 13:16:35 cornel: indeed, busybox can provide more than just coreutils Mar 03 13:18:54 cornel, joshuagl: check out recipes-extended/images/core-image-full-cmdline.bb and the specific packagegroups used Mar 03 13:19:12 ant_work, thank you Mar 03 13:19:58 ant_work: oh, nice. Had missed that recipe :-) Mar 03 13:21:25 it's an old wish, long ago people used dropbear because busybox was suid Mar 03 13:22:03 packageroup-core-boot contains busybox Mar 03 13:24:52 packagegroupd-core-full-cmdline also includes mc, so I'd treat it as inspiration rather than a solution Mar 03 13:25:07 paulbarker: we've previously done work at making toybox an alternative, can't recall where it is or what the state was, but i can ask around Mar 03 13:26:17 rburton: Toybox currently works, I'm planning to try an upgrade to v0.7.3 this weekend. It just still needs a few things from busybox until toybox implementation is complete Mar 03 13:26:46 iirc there is a Khem's patch pending Mar 03 13:27:00 upstream Mar 03 14:01:14 kanavin: Looks like the runstrip failure is specific to using uninative on Debian 9. Disabling uninative gets rid of the errors. Mar 03 14:02:40 paulbarker: would be good to get that in bugzilla so we can track it Mar 03 14:03:19 zeddii: looks like your new kernels break cryptodev: TOPDIR/tmp/work/qemux86_64-poky-linux/cryptodev-module/1.8-r0/cryptodev-linux-1.8/zc.c:63:8: error: too few arguments to function 'get_user_pages_remote' Mar 03 14:03:19 ret = get_user_pages_remote( Mar 03 14:03:19 ^~~~~~~~~~~~~~~~~~~~~ Mar 03 14:03:39 joshuagl: Good plan. I'll wait until the build is finished to confirm I'm correct then look at filing it Mar 03 14:03:51 paulbarker: thanks Mar 03 14:04:16 does debian-testing have a newer gcc than any other distro we're building on? Mar 03 14:04:51 gcc (Debian 6.3.0-6) 6.3.0 20170205 Mar 03 14:04:56 GNU strip (GNU Binutils for Debian) 2.27.90.20170124 Mar 03 14:05:06 hmm, I have gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1) Mar 03 14:05:10 Fedora 25 Mar 03 14:05:37 gcc 4.9.2 and strip 2.26.1 here, old school \o/ Mar 03 14:05:54 don't need no stinking gcc5 Mar 03 14:14:58 what's interesting is that the strip failure only occurred on the fixincl binary, not on anything else Mar 03 14:46:12 oh, that is interesting Mar 03 14:46:34 GNU strip version 2.26.1-1.fc25 Mar 03 14:46:50 paulbarker: strip 2.27.90? so it's a pre-release Mar 03 14:47:15 Yea, I've been looking at the debian binutils package, they've picked up a pre-release off the 2.28 branch Mar 03 14:48:24 the only other report of similar failures is for PPC not ARM and the patch for that is already in oe-core binutils Mar 03 14:48:45 however, here we're using the host binutils not something compiled in OE. Let me check... Mar 03 14:50:03 Yea, the PPC elf32 bug is already fixed in this version of binutils so it's not that Mar 03 15:34:44 Does anyone know if it's an expected consequnce of the recipe-specific sysroots that I have the full path to my build directory within an image directory? Mar 03 15:34:52 E.g. /ar0/pbarker/work/toganlabs/rpi/poky/build/tmp/work/x86_64-linux/gcc-cross-arm/6.3.0-r0/image/ar0/pbarker/work/toganlabs/rpi/poky/build/tmp/work/x86_64-linux/gcc-cross-arm/6.3.0-r0/recipe-sysroot-native/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/install-tools/fixincl Mar 03 15:37:32 for native stuff i wouldn't be surprised Mar 03 15:38:07 as under image/ is the prefix, which for native is the full target path of the sysroot Mar 03 15:38:54 native is prefixed with the full absolute path, has always been the case, not new with the recipe specific sysroots, just more obvious since the prefix is prefixed :) Mar 03 15:39:15 * kergoth still thinks we should stop that at some point, not as much need for it since we do relocation fixes anyway Mar 03 15:39:36 Ok, just investigating things that look strange around the fixincl binary which is failing to strip Mar 03 15:40:35 The problem with not prefixing the native stuff is easier host contamination Mar 03 15:41:08 i was thinking we prefix it, but with an invalid path that's easy to use as a placeholder for our relocation replacements Mar 03 15:41:12 i.e. /invalid/ Mar 03 15:41:18 is that less of a problem no that gcc basically refuses to anything unless you give it a sysroot? Mar 03 15:41:26 Yeah, that would work Mar 03 15:41:44 otherwise if we go trying to replace / or /usr or something, things could get messy :) Mar 03 15:42:18 it's too bad more projects aren't path relocatable. just not a priority for most folks, sadly :( Mar 03 15:42:31 also, trying to google for info about such relocation is a pain in the ass. all you find is linker/loader stuff Mar 03 15:44:19 Yeah, I've patched libtool to support relation, it was a pain Mar 03 15:44:45 But other than that, it was generally pretty easy to get the basic tools in Yocto relocatable in my proof of concept last year Mar 03 15:46:00 i think i might still have old patches for autoconf/automake for it, somewhere Mar 03 15:54:50 Ok, this is weird. With uninative disabled, fixincl is stripped once and all is good Mar 03 15:55:06 With uninative enabled, fixincl is stripped twice and the second invocation fails Mar 03 15:55:09 http://pastebin.com/dr8dinvn Mar 03 15:55:12 weird Mar 03 16:03:30 do we really want to enable cryptodev in openssl by default? Mar 03 16:03:38 isn't that the sort of thing a BSP would turn on Mar 03 16:03:54 * rburton was wondering why python-native was rebuilding after i patched cryptodev-module Mar 03 16:07:00 does seem machine specific Mar 03 16:10:48 yeah Mar 03 16:11:03 shall fiddle Mar 03 16:24:10 meh, think it's time to stop procrastinating and write unit tests for git shallow so there's a chance in hell of getting it merged Mar 03 16:25:31 yeah! Mar 03 16:25:43 then we can make the kernel fetch with shallow Mar 03 16:28:08 rburton: did you try my v3 ? Mar 03 16:28:11 patch for go Mar 03 16:29:41 sorry not yet Mar 03 16:29:42 rburton: I tried on debian8 stable as well as testing Mar 03 16:29:47 it worked fine here Mar 03 16:44:23 hi Mar 03 16:45:29 Is this the correct place to get help with using the yocto build system Mar 03 16:47:23 jedi-kday: yes Mar 03 16:49:16 hi paul, I've built an image with deb and package management enabled Mar 03 16:50:03 but I don't know how setup sources, should I just create the sources.lst file Mar 03 16:50:27 in /etc/apt/sources.lst? Mar 03 16:51:51 http://www.yoctoproject.org/docs/2.2.1/mega-manual/mega-manual.html#using-runtime-package-management may be helpful there, it's not something I've looked at in a few years though Mar 03 17:06:33 Ok, I'm being stupid. fixincl is only stripped once, there's multiple prints in runstrip() if there's an error. I need to call it a day though, I'll file a bug and see if I can take a look at it again soon **** BEGIN LOGGING AT Fri Mar 03 17:36:04 2017 Mar 03 17:39:46 paulbarker: can you cc me on that bug Mar 03 17:43:04 rburton: if it still fails on your box that will be interesting since it means your build box has something installed which is causing this since vanilla deb8 and deb-testing works fine Mar 03 17:57:12 rburton: I've added you to the cc list. For others, the bug is https://bugzilla.yoctoproject.org/show_bug.cgi?id=11123 Mar 03 17:57:13 Bug 11123: normal, Undecided, ---, paul.eggleton, NEW , Stripping fixincl fails in gcc-cross-arm and gcc-cross-initial-arm do_populate_sysroot on Debian 9 Mar 03 18:20:41 hello Mar 03 18:21:30 kergoth: you mentioned once about using buildhistory-collect-srcrevs and including the results in my local.conf Mar 03 18:21:43 today I tried to do that Mar 03 18:22:03 and it seems to work somewhat Mar 03 18:22:41 i get an error for some recipes where it has a value of NONE but that is ok, i can live with those errors. Mar 03 18:23:03 however I get a failure with meta-intel-iot-security Mar 03 18:23:29 where it says it has a failure expanding SRCPV Mar 03 18:24:07 bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve 'dict_values(['3e2a67bdb0673581a97506262e62db098efef6d7'])' in upstream git repository in git ls-remote output for git.code.sf.net/p/linux-ima/ima-evm-utils Mar 03 18:24:57 any idea what i'm doing wrong? Mar 03 19:20:36 is there anybody out there? Mar 03 19:28:44 davis is Mar 03 19:36:31 davis: sounds like a bug in that layer, then Mar 03 20:18:55 rburton: I think I can see that go-native install is different and could be able to workaround the problem you are seeing. if you have tried v3 and it still fails let me know Mar 03 20:24:48 kergoth: i'm getting a bunch of bugs i'm trying to make sure i'm using the correct syntax Mar 03 20:25:00 this http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#understanding-what-the-build-history-contains Mar 03 20:25:10 refers to using -a option Mar 03 20:25:15 but that did not help Mar 03 20:26:06 that error has nothing to do with buildhistory-collect-srcrevs Mar 03 20:26:13 the SRCREV variable is raising an exception when it's expanded Mar 03 20:26:20 the samew ould occur if you used bitbake -e, or tried to build the recipe Mar 03 20:26:28 so as i said earlier, it's a bug in the layer Mar 03 20:28:00 ahh, ok its a bug. i guess its confirmed if I can rmove the include in my conf, then do a build image cmd. do the -a -f option, redirect the history to a file and then include in conf/local.conf and try again to rebuild and it fails. Mar 03 20:33:54 a better example is Mar 03 20:36:45 Hello everyone, just wondering if anyone tried core-image-base lately Mar 03 20:37:34 I am trying to build it on morty and it fails :/ Mar 03 20:45:05 khem: $ bb contents go-helloworld Mar 03 20:45:05 go-helloworld: Mar 03 20:45:05 /usr/bin/helloworld Mar 03 20:45:07 \o/ Mar 03 20:57:05 bitbake foo-image Mar 03 20:57:13 buildhistory-collect-srcrevs -af > conf/buildhistory.conf Mar 03 20:57:41 then i added include buildhistory.conf to my conf/local.conf Mar 03 20:58:05 then bitbake foo-image again and it fails. so every failure must be due to a bug in the layer. Mar 03 21:06:54 hi all, needed some input for this patch http://lists.openembedded.org/pipermail/openembedded-core/2017-March/133600.html Mar 03 21:08:16 is this a correct way to handle perf while building kernel using externalsrc methodology? Mar 03 21:15:20 I've got some recipes that are installing to ${SYSROOT_STAGING_DIR} inside of do_install(). They work from a clean build but I think the files aren't installed to the ipkg and sstate cache. They should be installing to ${D} _always_, right??? Mar 03 21:16:17 (oops, s/SYSROOT_STAGING_DIR/STAGING_DIR_HOST/) Mar 03 22:09:40 rburton: I have another patch where I have altered native install of go I think thats whats causing issue on your machine Mar 03 22:09:53 rburton: would you be able to try a v4 ? Mar 03 22:19:23 why are bitbake's unit tests contacting remote servers which aren't in our control? that seems really really od Mar 03 22:19:35 particularly for unit rather than system tests Mar 03 22:20:10 the tslib test is failing due to a particular release tarball not being accessible. depending on that rather than hosting something ourselves really doesn't make any sense at all Mar 03 22:21:24 if we want to test git cloning, we should really be working against either pre-constructed git repositories to test particular features, or construct our own on demand, imo Mar 03 22:21:27 hrmph Mar 03 22:25:17 kergoth: for cloning e.g. you would want to interact with another system isnt it Mar 03 22:25:50 i doubt that'd be necessary for 90% of the cases, but for the ones that it is, we should depend on *our* systems Mar 03 22:25:54 not random sites you pick from the net Mar 03 22:29:51 that probbaly is fair Mar 03 22:30:15 might be better to use oe org with yp org as backup Mar 03 22:32:13 * kergoth nds Mar 03 22:32:15 * kergoth nods Mar 03 22:35:22 well, here do_menuconfig fails...ncurses needs to be in sysroot Mar 03 22:49:48 ant_home: you need ncurses-native dep Mar 03 22:50:02 kergoth: i've wanted to fork all the repos that we clone in selftest for a while, got bored of fixing tests when upstream changes Mar 03 22:53:09 khem: v3 worked, but trying v5 now Mar 03 22:55:15 damnit go slipped into the mut i fired on the AB Mar 03 22:55:19 so now its failing everywhere Mar 03 22:55:31 khem: https://autobuilder.yoctoproject.org/main/builders/nightly-musl/builds/406/steps/BuildImages/logs/stdio <— v3 with musl Mar 03 23:00:44 rburton: if v3 worked then I would like to send a v6 with same do_install as in v3 Mar 03 23:03:28 rburton: | /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Mar 03 23:03:31 | # include Mar 03 23:03:53 it seems it build host doesnt have multilib friendly headers Mar 03 23:04:05 I think I need to disable cgo Mar 03 23:10:34 khem: go-helloworld in v5 either installs badly, or doesn't like rebuilds Mar 03 23:10:36 | install: cannot create directory ‘/data/poky-master/tmp/work/corei7-64-poky-linux/go-helloworld/0.1-r0/helloworld’: File exists Mar 03 23:12:36 khem, no. It needs libncurses in recipe-sysroot so it must depend on ncurses Mar 03 23:13:47 having it only as provider for recipe-sysroot-native is not enough Mar 03 23:14:20 rburton: I sent a v6 Mar 03 23:14:38 which hopefully fix the musl/go-cross issue Mar 03 23:15:00 wait let me fix the helloworld too Mar 03 23:18:42 rburton: sent a v7 which should fix go example as well. Mar 03 23:19:57 I have disabled cgo for go-cross but I think the problem there is gcc-runtime Mar 03 23:20:35 it could be a missing dependency but I have to verify Mar 03 23:20:47 meanwhile disabling cgo we will get over this issue regardless Mar 03 23:20:56 trying Mar 03 23:36:32 khem: seems better for my build, yeah Mar 03 23:36:41 shall throw it at the ab later, bed now! Mar 03 23:40:01 rburton: cool, I have already thrown it on my builder Mar 03 23:40:19 will know more about it tomorrow morning if all arches are still sane **** ENDING LOGGING AT Sat Mar 04 03:00:01 2017