**** BEGIN LOGGING AT Tue Aug 04 16:58:21 2020 Aug 04 16:59:58 rewitt: the aws cli implicitly reads an env variable - i do not specify it inside FETCHCMD_s3, but i have to add it to BB_ENV_EXTRAWHITE to pass it through bitbake. Aug 04 17:00:46 i'm running bitbake in a container via ecs - https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html Aug 04 17:01:17 it is required that i have the variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI present for the aws cli so that proper authentication can be done for s3 access Aug 04 17:02:07 for now i cheated by writing the value of AWS_CONTAINER_CREDENTIALS_RELATIVE_URI to a file, and i source it inside FETCHCMD_s3. but i think this is a bug in bitbake and i shouldn't need this workaround. **** ENDING LOGGING AT Tue Aug 04 17:02:41 2020 **** BEGIN LOGGING AT Tue Aug 04 17:16:18 2020 Aug 04 17:16:52 that's a bit confusing, since really i think anything plumbed through BB_ENV_EXTRAWHITE should be transparently passed through bitbake Aug 04 17:17:11 You may, I'm trying an experiment out. Sorry, I'm not an expert on this code, just trying to help since I think I remembered you asking yesterday as well. Aug 04 17:46:43 mischief: I think I got it to work, but it is definitely not how I would expect it to work either. If I "export FOOBAR=stuff; bitbake somerecipe" then foobar is in the environment of any of the tasks. I tested this by overriding do_compile and running "env". Aug 04 17:49:39 mischief: No I'm wrong. I was going to say doing the export in local.conf causes it to show up in the environment, however that doesn't even required BB_ENV_EXTRAWHITE. I agree with you. It seems like a bug or needs to be documented better. Aug 04 17:56:24 i do not know the value of my env var beforehand; the ecs agent poplates it for me in the container environment, so i need to pass it through Aug 04 17:57:37 i guess to be fair the BB_ENV_EXTRAWHITE docuentation does say 'Specifies an additional set of variables to allow through (whitelist) from the external environment into BitBake's datastore.' - its explicit that it is in the datastore Aug 04 17:57:59 i was just not aware that this does *not* also include exporting the variable into subprocesses Aug 04 17:58:15 and it was some kind of accident that it worked some of the time Aug 04 18:00:00 Hey all, is this the appropriate venue for a Bitbake question? I couldn't find a specific IRC for that. Aug 04 18:00:45 mischief: IIRC if you mark a variable as "export" it gets put in all task taskhashes (unless excluded), so if you made BB_ENV_EXTRAWHITE do that automatically, it would result in rebuilding everything anytime one changed Aug 04 18:02:48 JPEW: okay. if i add my variable to BB_ENV_EXTRAWHITE, and write an export statement for it, how do i exclude it from task hashes? Aug 04 18:03:55 I'm reading up on Bitbake and I'm a little confused as to the use of the `rdeptask` task flag. If a runtime dependency needs to be deployed before another recipe can begin execution, what is the use of having a task depend on another in this way? Since it's guaranteed that the dependency recipe will be finished before your recipe begins. Aug 04 18:05:03 mischief: Add the variable to BB_HASHBASE_WHITELIST **** BEGIN LOGGING AT Tue Aug 04 18:09:00 2020 Aug 04 18:11:21 jadelclemens: it's not used commonly, but for e.g. insane.bbclass uses it to make sure the package data for all RDEPENDS is present before running the QA tests (which is the example in the manual) Aug 04 18:11:44 JPEW: if i write 'export FOO', but foo is never explicitly referenced anywhere, do i still need to add it to BB_HASHBASE_WHITELIST? is the value of FOO from the external environment hashed into all tasks? Aug 04 18:12:47 jadelclemens: Or for example, a package ensures that all of its RDEPENDS have written out their package files with: classes/package_rpm.bbclass: do_build[recrdeptask] += "do_package_write_rpm" Aug 04 18:14:31 mischief: I believe so. export is tricky because bitbake can't figure out if its actually used in a task or not (since it's just part of the env, the build program could do *anything* with it), so it assumes its a dependency of every task Aug 04 18:16:26 mischief: You have to be careful with them, especially if they are "global" (apply to all recipes like local.conf or bitbake.conf).... at least that's my understanding. Aug 04 18:17:45 JPEW: okay, understood. the variable in my case is needed by the aws cli in the s3 fetcher, so its use is indeed hidden from bitbake. Aug 04 18:19:02 mischief: Right, it sounds like its some sort of credentials, which you want to be accessible (e.g. tasks can use it), but not be factored into the task hashes (e.g. changing credentials should not cause a rebuild) Aug 04 18:45:40 JPEW: as a followup, does BBMULTICONFIG change task hashes? Aug 04 18:45:54 e.g. setting it, and then building mc::target Aug 04 19:04:50 mischief: AFAIK, BBMUTLICONFIG doesn't have anything special so it follows the normal rules for variables Aug 04 19:05:18 mischief: meaning, it's only included in task hashes if it is referenced by another variable or task that is include in the hash Aug 04 19:07:25 mischief: At least, for the BBMULTICONFIG variable itself. Obviously pulling in the other config file could change all sorts of things :) Aug 04 19:08:38 And I can't think of any reason you would need to reference BBMULTICONFIG in another variable or task Aug 04 19:26:06 Hello, I have a potentially silly question, but I have been too dense to google it Aug 04 19:26:43 in my image recipe is there a place where I can put files that I want to show up in /etc/ later? Aug 04 19:27:39 for example, I have added the avahi-daemon recipe to my image recipe, but now I want to configure AVAHI as well Aug 04 19:27:50 thank you for any tips Aug 04 19:28:03 hirnschlag: make a recipe to install files and include that new recipe in your image Aug 04 19:28:19 if you need to modify a recipe's files, you can make a bbappend in your own layer Aug 04 19:29:25 thank you! Is that the only/standard way of doing that? Aug 04 19:30:32 standard - yes. you can write shell functions which fiddle with your image afterwards, but afaik it is usually reserved for instances where recipes cannot do what you want Aug 04 19:31:13 I'll give that a shot Aug 04 19:36:40 is there any news or info why downloads.yoctoproject.org is unreachable? is it scheduled maintenance? Aug 04 19:40:22 noless: I saw something earlier today about it being some NAS that wasn't behaving ok Aug 04 19:51:03 hello there ! I've got questions about EXTRA_OECMAKE variable.. it's like this var is never took into account from my recipe.. I noticed the existence of EXTRA_OECMAKE_BUILD in run.compile* but no insight from mega-manual.. Aug 04 19:51:31 it looks to regard Ninja.. do you have any clue, regarding EXTRA_OECMAKE var ? **** BEGIN LOGGING AT Tue Aug 04 19:56:21 2020 Aug 04 20:00:26 hi, I'm getting "realpath: command not found" while trying to build a backported kernel module: the command is "sfile="$(realpath --relative-to $kroot "$(readlink -f "$0")")"" Aug 04 20:05:48 coreutils_8.30.bb lists "realpath" in "bindir_progs". but I don't know much about yocto Aug 04 20:24:58 david-e: are you building this on target or in a recipe? Aug 04 20:39:50 RP in a recipe; I guess I found a way to fix it adding realpath to HOSTTOOLS in meta/conf/bitbake.conf Aug 04 20:41:03 does your kernel module recipe depend on coreutils-native? Aug 04 20:43:47 the bbappend file I'm using does not depend on it Aug 04 20:45:21 david-e: I'm kind of surprised that isn't in HOSTTOOLS already but I guess we mustn't use it much Aug 04 20:45:56 adding a DEPENDS on coreutils-native would likely fix it, as would adding it to HOSTTOOLS at the local/distro level Aug 04 20:54:54 mischief: I've added DEPENDS += "coreutils-native" , so thank you for the tip Aug 04 20:55:09 and RP thank you too **** BEGIN LOGGING AT Tue Aug 04 21:11:48 2020 Aug 04 21:30:46 Is it just me or is downloads.yoctoproject.org down? (and am I the one milionth person to ask this?) Aug 04 21:35:29 millionth Aug 04 21:35:30 and yes. Aug 04 21:35:33 WeZzy: we know, its being worked on but there are some issues needing in person access at the datacentre Aug 04 21:37:28 Ok, good luck fixing the issues and thanks for looking into it **** BEGIN LOGGING AT Tue Aug 04 23:53:34 2020 **** BEGIN LOGGING AT Wed Aug 05 02:49:23 2020 **** ENDING LOGGING AT Wed Aug 05 02:59:57 2020