**** BEGIN LOGGING AT Thu Aug 10 03:00:02 2017 Aug 10 03:00:38 Might someone recommend a boot on getting started with Yocto ? Aug 10 03:11:25 https://www.amazon.com/Embedded-Systems-Project-Software-Development/dp/0133443248/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=0BKRYV4BY6C91YG3MJKE Aug 10 03:12:19 https://www.amazon.com/Embedded-Linux-Development-Yocto-Project/dp/1783282339 Aug 10 07:02:57 Hi, has anyone tried hooking up eatmydata or similar libs which disable fsync() into yocto? They could potentially improve build times a lot.. Aug 10 07:05:11 mcfrisk: actually my experience is that the underlying storage is not that important Aug 10 07:06:04 LetoThe2nd: yes, but in full sstate cache builds which build several rootfs'es, I can see that disk IO is high even though there is memory available as fs cache. Thus something is syncing stuff to disks, a lot. Aug 10 07:06:54 mcfrisk: i just gave it some rough testing, like tmpfs vs ssd vs hd Aug 10 07:07:11 I found https://wiki.yoctoproject.org/wiki/Profiling and there was very little benefit from eatmydata. Aug 10 07:07:52 and the difference was in the range where i expect it to be measurement tolerance, given a box with enough ram to hold the full build in tmpfs Aug 10 07:08:36 and as i expect sync on tmpfs to be very, very cheap it should not make that much of a difference Aug 10 07:09:57 LetoThe2nd: ok. hmm. In our case we can't move to tmpfs since build tmp is too big, but we try to avoid IO on build machines by tuning values, and forcing stuff into ram, but in maney places fsync()'s are flushin stuff to disk when there is still RAM available.. Aug 10 07:10:31 YMMV, of course Aug 10 07:10:42 or just get more ram :-) Aug 10 07:18:10 LetoThe2nd: more RAM doesn't actually help, we've measured it. And we would need more RAM on not one or few but on tens of build machines. On a 32 core machine more than 64 gigs of RAM doesn't help yocto build performance. Aug 10 07:19:07 mcfrisk: very well possible, yes. Aug 10 08:23:09 hello Aug 10 08:23:28 if you do a package split, does the default package get all files automatically, that are not assigned elsewhere? Aug 10 08:27:02 robsta, not all but there's a default list that catches a lot of normal things Aug 10 08:28:26 (default only assuming you don't define files_${PN} yourself of course) Aug 10 08:29:32 jku: ok Aug 10 08:29:48 but you need to define PACKAGES = Aug 10 08:29:51 always, right? Aug 10 08:29:53 for the split Aug 10 08:35:45 generall yes (with some exceptions like using PACKAGE_BEFORE_PN) Aug 10 08:36:17 which you may want to look at based on the original question btw Aug 10 09:12:41 Good morning, can anybody help me building a mender getting started example. Everytime I build with bitbake core-image-base I get the following errors: https://thepasteb.in/p/0ghJwG5v2QAh5 Aug 10 09:30:05 TheSilentHunter: i'd say, do bitbake -e core-image-minimal | less, find out where IMAGE_ROOTS_MAXSIZE gets set and change it then. Aug 10 09:33:54 thanks jku Aug 10 09:46:01 # $IMAGE_ROOTFS_MAXSIZE Aug 10 09:46:01 # set? /home/DISK2/yocto-poky/meta-mender/meta-mender-core/classes/mender-install.bbclass:127 Aug 10 09:46:01 # "${MENDER_CALC_ROOTFS_SIZE}" Aug 10 09:46:01 IMAGE_ROOTFS_MAXSIZE="106496" Aug 10 09:46:50 so check mender-install.bbclass to see whats going on there :) Aug 10 09:47:35 is it also possible to just set the value in local.conf? Aug 10 09:48:42 ok when I change it there I get: | WARNING: bootloader config not specified, using defaults Aug 10 09:48:42 | Aug 10 09:48:42 | WARNING: overhead-factor was specified, but size was not, so bitbake variables will be used for the size. In this case both IMAGE_OVERHEAD_FACTOR and --overhead-factor will be applied Aug 10 09:48:42 | ERROR: Actual rootfs size (21772 kB) is larger than allowed size 16384 kB Aug 10 09:51:13 in the mender-install.bbclass I have: Aug 10 09:51:17 # Gently apply this as the default image size. Aug 10 09:51:17 # But subtract IMAGE_ROOTFS_EXTRA_SPACE, since it will be added automatically Aug 10 09:51:17 # in later bitbake calculations. Aug 10 09:51:18 IMAGE_ROOTFS_SIZE ?= "${@eval('${MENDER_CALC_ROOTFS_SIZE} - (${IMAGE_ROOTFS_EXTRA_SPACE})')}" Aug 10 11:09:09 So, I want to "export =LD_PRELOAD=libeatmydata.so" to all native tools executed during build by bitbake in all tasks. Is the only way to do this to add LD_PRELOAD to preserved_envvars_exported of bitbake/lib/bb/utils.py ? It seems the BB_ENV_EXTRAWHITE only exports the variable to the recipes/classes but not to the execution shell of do_configure etc. Aug 10 11:11:02 libeatmydata.so turns all sync() system calls to no-ops which should improve build performance. Aug 10 12:59:12 If you are having problems running a Yocto / Bitbake build through Jenkins on remote nodes and it stops at the `grep 'Python 3'` stage it might be that you have forgotten to stop Ubuntu using /bin/dash as the /bin/sh interpreter. /bin/sh needs to be a symlink to /bin/bash or your oe-init-build-env sourcing down into oe-buildenv-internal will fail. It will not fail when you run it by hand on the machine, only when Jenkins tries to run it. That has conf Aug 10 12:59:42 who is Jenkins? Aug 10 12:59:59 yates: brother of Hudson Aug 10 13:00:39 As Nipsey Russell used to say, "RRRRRRRiiiiiiiiggggghttt" .... Aug 10 13:01:19 you did ask ;-) Aug 10 13:03:52 Brother / Strange clone of. Aug 10 13:04:13 https://jenkins.io/ Aug 10 13:04:33 http://hudson-ci.org/ Aug 10 13:06:02 thanks Aug 10 13:06:23 a "continuous integration" tool Aug 10 13:06:48 yates: Those posts help? Do you use an CI system with Yocto? It has been a struggle getting Jenkins to run a (Gerrit) repo from inside a jenkinsfile pipeline job that executes a bitebake / yocto job. If I can spend some more time getting this into the cloud using containers I am sure I could make it much harder or easier. Aug 10 13:07:41 TafThorne: they help me understand what the heck you're talking about, yes. Aug 10 13:07:50 My key buzz word score for the week is up though. I think my CV value just jumped by a good 30% Aug 10 13:08:43 as for being on-board, i'm afraid i'm about as far opposite that type of development methodology as anyone... Aug 10 13:09:23 i want to enter opcodes into the front panel, like on the old DEC PDP 11/70 ... Aug 10 13:11:31 LetoThe2nd: how do you feel about your replacement in the alternative Emperor: Battle for Dune timeline? http://www.frictionlessinsight.com/revpics2/EmperorBFD/EmperorBFDd_small.jpg (Now I feel old having realised the release date for that game that I was as thinking of as new compared to Dune 2000) Aug 10 13:12:45 TafThorne: there is no replacement, there is only me :) Aug 10 13:12:50 yates: Does having something enter the opcodes for you every time you change them to make sure they are correct not sound like a good idea? Aug 10 13:13:23 LetoThe2nd: That nexus in the far future. Its not good. My tip is avoid high places. Aug 10 13:13:56 TafThorne: why should i? i will survive in an eternal dream. Aug 10 13:14:03 LetoThe2nd: Not that can/do/would/could without free will or damming man kind. Thank you for the sacrefice. Aug 10 13:15:30 yates: Anywho this is not my baby, I just run the day care. I agree it is a good idea to make sure that my opcodes work on at least one other DEC PDP 11/70 and not just the one I have probably tinkered with. Turns out I needed to tinker with others. Aug 10 13:16:17 Really I just wanted to share my triumph with the universe and hope that a future Google search of the chat logs reveals a nugget of incite into what is going on to a future me. Aug 10 13:17:40 TafThorne: what doesn't sound good to me is a) the high overhead of developing good test suites, b) the high overhead for each developer to learn the CI tool, test suites, etc.c) the problem of breaking the whole project when someone makes a mistake. other more subtle problems might include specification / functionality drift, development costs, manpower requirements, higher likelihood of tool bugs due to the number Aug 10 13:17:40 of tools required, etc... Aug 10 13:18:51 i would say that for the majority of projects, those things apply. but for HUGE, on-going projects, J/H might be the right solution. Aug 10 13:19:38 yates: We resolve most of those issues with 0 automated tests. To date it is just an automated build system. Well a couple of linters and cppcheck things run and one small set of unit tests on a build that was never getting executed. Aug 10 13:20:07 ship it! Aug 10 13:20:13 * yates snickers Aug 10 13:21:37 yates: We have also Siloed the CI specifc knowledge in two developers heads and some wiki pages. If anyone else ever touched the config files there are clues. Most people (there are only 6 of us) do not touch the Makefiles other than to expand a lists. Aug 10 13:22:20 yates: We are a looooonnnngg way from CD and in truth not very well into CI either. Aug 10 13:23:22 you'll not be convincing me anytime soon. sorry. i believe in a minimal set of tools (emacs, gnumake, etc.). but i'm old. i'm stubborn. Aug 10 13:23:34 EMACS! Aug 10 13:23:35 yocto is a very painful step for me. Aug 10 13:23:51 yocto itself Aug 10 13:23:51 its a bit of mind... bend for me too Aug 10 13:25:11 i also have separates in my home stereo (preamp/power amp, etc.). it's a life-view/mindset Aug 10 13:26:14 but nevertheless, best-of-luck to you and your company. Aug 10 13:26:26 i didn't mean to be discouraging. Aug 10 13:26:57 Yer mist of my life is a confusing (to others) bundle of string and tape holding together an impossibly (seeming to others) system of things. Aug 10 13:28:09 Also I like XML and get my head aroudn the idea of meta meta meta data (it gets fuzzy after that) so Yocto is OK. Jenkins calling nodes and other stuff is OK. Everything is fine. Until someone moves the coffee cup that was balacning out the weight on the other end of the desk.... Aug 10 13:29:36 it seems you're smart enough to see the forest in spite of the trees... Aug 10 13:29:39 yates: thank you. I think I will need the luck. Aug 10 13:30:03 I am lead to understand that I have an odd view of things. Aug 10 13:30:20 I can see the value in all your points too. Aug 10 13:31:00 As long as I can get someone else to try typing in the opcodes now and then I am happy to leave a paper trail and nothing else. When no one else will do so a machine doing it to check it works elsewhere seems prudent. Aug 10 13:31:30 thank you Aug 10 13:31:34 yates: good luck to you and your company too. I'll get back to the forest to see if the buttler has got lots somewhere in the trees. Aug 10 13:32:52 One last thing. Yocto (or bitbake (or meta-oe)) does still need /bin/bash instead of /bin/dash as the /bin/sh interpreter? I should not be reporting my strange edge case in a ticket somewhere should I? Aug 10 13:33:35 TafThorne: the oe-init-environment (or whatever) doesn't set that up automagically? Aug 10 13:34:33 i don't see why it would be any different by hand versus with jenkins. i would start looking at that discrepancy first. Aug 10 13:34:41 (looking back at your first post) Aug 10 13:35:53 if i'm understanding your problem correctly. Aug 10 13:54:43 yates: I will look into it. I know that not having the symlink caused a mysterious failure when jenkins was trying to run things. AFAIK that system uses ssh to connect to a node, runs some java magic and then inside that java magic spaws a shell for it to use. That shell is the default (I think) but in Ubutnu the sh interpreter seems to be left as /bin/sh which results in /bin/dash. I think you understand my problem correctly. Aug 10 14:03:05 i don't really see much different between approaches 2.2 and 2.4 in the linux kernel development manual (http://www.yoctoproject.org/docs/1.6/kernel-dev/kernel-dev.html). Aug 10 14:03:30 one seems to be that you use the original defconfig file, but it seems you don't have to. Aug 10 14:04:16 is it that, in the section 2.4 approach, you are specifying your own linux kerenl versuion, commit id, etc? Aug 10 14:04:59 whereas in the 2.2 approach you utilize the existing kernel version? Aug 10 14:05:07 can you define your own machine in either case? Aug 10 14:11:52 yates: is this about 2.2. Modifying an Existing Recipe vs 2.4. Working With Your Own Sources? Aug 10 14:12:55 when i'm trying to build libvncserver, it obviously tries to link against the hosts lgcrypt. seems to be caused by TARGET_LDFLAGS += "-lgcrypt" Aug 10 14:13:05 what might lead the linker astry here? Aug 10 14:13:07 also, in the 2.4 approach, you define your own, uniquely-named kernel recipe, while in 2.2 you have to use an existing kernel recipe and write a bbappend? Aug 10 14:13:30 TafThorne: yes Aug 10 14:15:15 yates: I think it is trying to convey the options of patching a file or replacing a file. Aug 10 14:17:50 WHICH file are you referring to? you mean some in-tree kernel file, e.g., blah.dts? Aug 10 14:17:56 yates: Patching a kernel file makes sense for the first example. Making your own recipe for a kernel file makes little sense. I think it was done to make the two sections similar. The same advice works for any application. Adding your own application, config file or similar makes more sense. I am still new(ish) to this so I may be mistaken. Aug 10 14:18:24 (sorrry was typing looonngg resposne. Will be AFK for a few minues now while I help witha Ruby issue in meat psace) Aug 10 14:29:08 yates: back Aug 10 14:31:01 khem: going back to my question late yesterday. so kernel is decided by machine, and machine is decided by conf/machine/ in the layer from which the image recipe is built? Aug 10 14:31:27 TafThorne: why does making my own recipe for kernel file make little sense? Aug 10 14:31:35 yates: Did my explanation make sense? Although it talks about kernel stuff those section apply equally to application code. You are not as likely to have your own kernel or kernel module or (i do not know that much about kernel development, insert name of some large replacable chunk here). You are much more likely have your own application or a patched version of applciation. Aug 10 14:32:55 TafThorne: because I only ever patch kernel files or replace single files. I do not re-write whole large chunks. For _me_ it makes little sense to do things from scratch. It make more sense to change a few lines or a single file. Aug 10 14:34:09 yates: Re...kernel is decided... question: I believe that is correct. Unless no preferred kernel is indicated in which case you ultimately end up at the default one for your distribution or version of Yocto. Aug 10 14:35:05 yates: p.s. I was making a poor assumption. I write applications or tweak drivers. I usually stay well out of kernel space and code. Sorry about that. Aug 10 14:35:46 no, that's not the issue. we are doign the same thing, very small tweaks, e.g., to dts files to reconfigure pin muxing. Aug 10 14:38:01 there is another consideration here: even if you write your own kernel recipe, which kernel/u-boot git sources are you going to use? it seems you can a) use someone elses and patch, or b) create your own set (from some sensible existing kernel/u-boot) and put them into your own git repo. Aug 10 14:39:25 What I done Aug 10 14:39:26 https://github.com/Quectel-Community/meta-quectel-community/tree/master/recipes-kernel/linux Aug 10 14:40:08 fyi, we are using the variscite dart 6ul som board, and want to leverage their kernel/u-boot work, but tweak to taste for some new/modified interfaces on their P1/P2 connector. Aug 10 14:41:41 you are utilizing approach 2.2 Aug 10 14:41:48 Which I cannot claim is correct. Basically I ended up with two patches. One for linux-yocto that patched things on some systems but not the Pi I was testing with and the one for Pi linux-raspberrypi. These were both developed based on my Ubuntu PCs kernel source and some adjustments. Aug 10 14:42:09 I am using approach 2.2. The driver I was working with already existed. It is a 1 line change to add a new device to it. Aug 10 14:42:44 When I needed to add ppp and ppp config files. I used approach 2.4 https://github.com/Quectel-Community/meta-quectel-community/tree/master/recipes-quectel-community/quectel-ppp Aug 10 14:43:56 Well... it is config files so they did not need compiled. That does not mater here, I think. In the non-public code here I also have compiled code of our own that is more like the 2.4 approach. Aug 10 14:45:26 i'm confused by https://github.com/Quectel-Community/meta-quectel-community/tree/master/recipes-quectel-community/quectel-ppp Aug 10 14:45:33 is that an image recipe? Aug 10 14:46:13 yates: you should be able to write bbappends for respective recipes if you are only tweaking Aug 10 14:47:09 khem: so approach 2.2 Aug 10 14:47:10 ? Aug 10 14:50:15 khem: we can certainly do that for the short term, the goal being to verify our new hardware works. Aug 10 14:52:29 but there are other considerations long-term in which we may not want to use that method. essentially the dependency on someone else's kernel/uboot. e.g., what if they pull it off github for some reason? Aug 10 14:56:38 is my thinking right? Aug 10 14:59:09 or it could simply be the more streamlined (I think..) process of code change/compile/test/checkin instead of code change/compile/test/patch/checkin Aug 10 15:00:06 yates: quectel-ppp_0.1.bb is a recipe. Not a special one, just a recipe. It causes some things to happen. It is included as part of an image recipe elsewhere (or you can add it to local.conf). Aug 10 15:01:22 armpit: FWIW we have the reduced qemumips test suites in morty Aug 10 15:01:38 k Aug 10 15:02:12 yates: in this age of distributed SCMs your concerns about repo disappearingare addressed, you can create a github fork anytime Aug 10 15:02:38 so I would suggest to cross that bridge when you arrive there Aug 10 15:05:03 khem: until github goes the way of Google Code. Hopefully there will be some warning though. Not like that python node js mess of last year when the dev pulled their code. Aug 10 15:07:24 gh goes down we have bigger problem. in worst case someone will have a local copy Aug 10 15:07:50 you would have cloned one for the projects you are interested in Aug 10 15:08:00 so nothing changes, Aug 10 15:11:54 Yer. At least with Yocto there is a local copy of the source we just used (until I delete it). So we could (should) back that up from time to time. Aug 10 15:13:16 usually I advice people to create premirrors Aug 10 15:14:03 which is simple http server hosting all tar balls Aug 10 15:14:36 TafThorne: i see (re recipe). thanks for the clarification. Aug 10 15:15:28 khem: s/essentially/e.g./ ... that was just one consideration. Aug 10 15:15:34 yates: you are welcome. It was my first non-tutorial Yocto work. I cannot vouch for its quality but it seems to work. Aug 10 15:15:50 how do you invoke it from the image .bb ? Aug 10 15:16:11 require? Aug 10 15:17:52 but i'm paranoid. paranoia will destroy ya'. Aug 10 15:19:15 yates: We should hold hands and cry while we figure this stuff out. I have many of the same goals as you it sounds. I got my .dts patches laid out yesterday, testing today. Aug 10 15:19:27 yates: to me and with regards to invoking my quectel driver mods? Magic. You include the layer in your layers file. Then the bitbake system skims over all the recipes it has, Noticed that there is a bbappend for a recipe it is already using (the kernel) so it applies that. Aug 10 15:22:06 majuk: knock yourself OUT dude. Aug 10 15:22:33 That's plan B. Aug 10 15:23:00 yates: to me and with regards to invoking my quectel ppp config file mods? You have to include the layer in the layers file and then make something require or install that recipe. It is not a bbappend so it will not just modify something. I do also have recipies that give newer versions of applications. When there are multiple recipies that provide the same thing (quectel-ppp in my case) the bitbake system picks the one of highest priority. I have Aug 10 15:23:56 *local.conf Aug 10 15:24:26 If you happen to figure out where to shoe-horn in u-boot DDR tuning register, hit a brother up. Aug 10 15:24:34 *registers Aug 10 15:25:58 TafThorne: I don't think you hit the character limit on that last message. Aug 10 15:26:06 I *do think Aug 10 15:26:30 Man I need more coffee. Aug 10 15:26:31 The bit where I got lost is what happens after local.conf? The answer is those machine or image recipies you mentioned earlier. What I now have is a .conf in meta-my_company_name layer's /conf directly. That overrides the raspberrypi3:${MACHINE} (gaining all of its powers) Aug 10 15:26:56 aha. Aug 10 15:27:22 http://www.aosabook.org/en/yocto.html may be helpful for the big picture / basics of how bitbake works Aug 10 15:27:43 Then in meta-my_company_name layer's recipies-core/images directory I have some image-name.bb files that themselves have include recipes-core/images/rpi-basic-image.bb (again like the highlander steeling powers) and then inside them they have IMAGE_INSTALL += "packagegroup-tafts-list-of-things" Aug 10 15:28:50 Then if we tug on that string somewhere there is a pacakge group in my meta-my_company_name layer that defines the packagegroup-tafts-list-of-things package ground and in that packagr group it includes more pacakge groups! Aug 10 15:29:56 Only joking. well... it could be package groups. It actually is a .bb file that has `inherit packagegroup` and then has `RDEPENDS_${PN} = "\ (list of pacakges including quectel-ppp` Aug 10 15:30:55 majuk: serious or joke? I cannot see from here Aug 10 15:31:22 TafThorne: Serious. Couple messages back it, you cut off at "I have" Aug 10 15:31:37 Looks like there was supposed to be more there. Aug 10 15:31:54 1/3 : (16:23:00) TafThorne: yates: to me and with regards to invoking my quectel ppp config file mods? You have to include the layer in the layers file and then make something require or install that recipe. It is not a bbappend so it will not just modify something ... Aug 10 15:32:05 2/3 ... I do also have recipies that give newer versions of applications. When there are multiple recipies that provide the same thing (quectel-ppp in my case) ... Aug 10 15:32:16 3/3 : ... I do also have recipies that give newer versions of applications. When there are multiple recipies that provide the same thing (quectel-ppp in my case) Aug 10 15:32:27 majuk: better? Aug 10 15:33:19 I am waaaaayyyy tooooooo verbose most of the time. I do really try to be more succinct. Imagine what happens when I get excited or forget. ] Aug 10 15:33:37 ...I'm unconcerned, just pointing it out. Aug 10 15:50:35 majuk: thanks. Missing half my speach would (possibly) confuse poor yates: more than reading it all. Hopefully kergoth's suggested reading will be more clear and complete. Aug 10 16:17:34 TafThorne: ha. np. thanks for the mini-manual! :) Aug 10 16:23:52 khem: can i still define my own machine even if i only use bbappends for the kernel recipe? i probably won't, but i'm curious Aug 10 16:29:07 yates: That's what I have done. My custom layer has a custom board [which is my ref board with a few minor mods] + 2 bbappends [patches] & 1 bb [installs some misc files to rootfs] Aug 10 16:38:44 yates: yes you can Aug 10 16:39:27 yates: you can derive your machine from an existing machine. You might have to take care of overrides etc. since sometimes bsps define some operations specific to machines Aug 10 16:50:32 yates: you are welcome. Good luck. Aug 10 17:39:13 section 2.2 doesn't say anything about creating an image recipe. do i need to create my own image recipe in my custom layer in order to use my bbappended kernel? if i do not and instead use the image recipe from the "base" layer (the one which contains the kernel recipe), how is my custom layer's kernel's bbappend file is utilized? Aug 10 17:53:13 ? Aug 10 18:05:21 i'm stuck. i sure would appreciate a hint Aug 10 18:09:50 TafThorne: permission to pm? Aug 10 18:15:43 do i use my own image recipe and "inherit" from the base layer recipe? Aug 10 18:29:05 khem: is this correct? Aug 10 18:34:58 i'm trying to append a version string to the installed /etc/issue and /etc/issue.net on a yocto-built distro. oe-core offers a base-files bb recipe that has a function do_install_basefilesissue. i wrote a common bbclass that appends onto this function but i believe that append isn't executing Aug 10 18:35:34 is inheriting that bbclass in a base-files_%.bbappend file not the correct approach to appending onto do_install_basefilesissue? Aug 10 18:53:28 ERROR: ERROR: Nothing PROVIDES 'hw-test-image' Aug 10 18:54:18 yet there is a meta-custom/recipes-custom/images/hw-test-image.bb Aug 10 19:12:39 there is a kernel recipe meta-variscite-fslc/recipes-kernel/linux/linux-variscite_4.1.15.bb, and i have a meta-ebtron/recipes-kernel/linux/linux-variscite_4.1.15.bbappend, yet i'm getting "ERROR: No recipes available for: /home/yocto-project-x5-hw-test/sources/meta-ebtron/recipes-kernel/linux/linux-variscite_4.1.15.bbappend" Aug 10 19:14:00 nm **** BEGIN LOGGING AT Thu Aug 10 19:21:32 2017 Aug 10 21:27:33 is there a variable aside from $THISDIR that might be used for pulling the directory of a recipe or bbappend file? Aug 10 21:46:27 yates: have you added the meta-variscite-fslc to your bblayers.conf ? Aug 10 23:37:23 Is there something like vardepsexclude for python functions? Or asked differently, is it safe to use time.gmtime() in a python function? Aug 11 01:01:50 sagner: it won't be called until the function is run, so yes, of course, but the timestamp won't be included in the checksum — probably what you want Aug 11 01:01:58 usually including it in the checksum is bad anyway **** ENDING LOGGING AT Fri Aug 11 03:00:01 2017