**** BEGIN LOGGING AT Tue Mar 21 03:00:02 2017 Mar 21 10:38:32 how can I display all vardeps for a task? i'm trying to retrigger a do_unpack if a certain variable is changed, I tried doing do_unpack[vardeps] += "MY_VARIABLE" .. am I doing it wrong? Mar 21 10:48:31 does anybody have a pointer at hand that explains what goes into the sdk, and what not? seems like one for a project i have lacks some headers Mar 21 10:49:04 LetoThe2nd: i believe the -dev and -dbg package split goes into the sdk by default Mar 21 10:49:11 LetoThe2nd: afaik the logic is the same as the dev-pkgs code, so its just all corresponding -dev packages Mar 21 10:49:18 gah Mar 21 10:49:27 if you've a package that is unconventially split the you might trip it up Mar 21 10:49:47 rburton: i've got a package that is unconventionally just a c++ header in the end. Mar 21 10:50:25 so i suspect the header is packaged into the standard package, and -dev/-dbg go missing Mar 21 10:50:46 if its a header then it will be in PN-dev Mar 21 10:50:56 but if PN isn't in the image then there's no way bitbake knows to put PN-dev into the SDK Mar 21 10:51:10 add the dev to TOOLCHAIN_TARGET_TASK Mar 21 10:53:17 ok, let me look this up Mar 21 10:53:18 LetoThe2nd: RDEPENDS_${PN}-dev = "cppzmq-dev" Mar 21 10:53:23 LetoThe2nd: is how i solve the same issue Mar 21 10:54:52 jackmitch_work: inside the header recipe, you mean? Mar 21 10:55:23 LetoThe2nd: then when the application that requires the header is pulled into the sdk the -dev version of it depends on the -dev version of the header only package Mar 21 10:56:12 jackmitch_work: ah, gotcha. sounds strange, but let me give it a try. Mar 21 11:11:15 if i do do_unpack[vardeps] += "MY_VARIABLE", why won't do_unpack re-run when value of MY_VARIABLE changes? Mar 21 11:11:46 i was under the impression that the vardeps decide what goes into the task hash, so the value of MY_VARIABLE should now be part of the hash? Mar 21 11:12:32 it should Mar 21 11:13:16 MY_VARIABLE is a variable in bitbake-land and not a shell environment variable right Mar 21 11:13:22 yes Mar 21 11:13:31 it is assigned in local.conf Mar 21 11:14:32 rburton: and even if unpack itself does not refer to MY_VARIABLE, bitbake will still trigger the rerun of task, right? It doesn't try to be smart and conclude that since nothing in the unpack-body references MY_VARIABLE, it excludes it from the hash? Mar 21 11:15:33 not if you've added it explicitly Mar 21 11:15:51 rburton: is there a way to list vardeps for a specific task? Mar 21 11:16:00 bitbake -e lists flags Mar 21 11:18:42 weird, it does not show me any vardeps for the unpack-task. is it suppose to be around the place where the task function is declared rburton ? Mar 21 11:20:01 grep :) Mar 21 11:48:21 rburton: there's no mention of MY_VARIABLE except where it's being defined Mar 21 11:49:03 rburton: do_unpack[vardeps] is correct, right? or should I use base_do_unpack[] or some other weird name? i noticed there are several layers of task functions of unpack Mar 21 11:51:23 do_unpack should be okay. maybe you're defining that somewhere where it's too late? Mar 21 11:51:35 worked examples are so much easier instead of trying to guess what you're doing Mar 21 11:51:41 rburton: it's in a recipe bbappend Mar 21 11:53:38 well, im working in a uboot recipe. i'd like to hack the config a little bit, so ive added a task that uses sed to modify ${S} and insert this task before do_compile. sed only runs when a certain variable (MY_VARIABLE) is 1, otherwise it is a NO-OP. My problem is when MY_VARIABLE goes from 1 to 0, ${S} is still tainted, so what Im trying to achieve is that do_unpack runs everytime MY_VARIABLE changes. This should Mar 21 11:53:39 then undo my sed change, when MY_VARIABLE goes from 1 to 0 Mar 21 11:53:56 it's a hack, i know, but it's because U-boot doesn't support config fragments like the kernel Mar 21 11:54:11 cant you write your sed so that it always works? Mar 21 11:55:18 i could, but then i'd have to undo the change introduced by MY_VARIABLE=1 when MY_VARIABLE=0, which means I have to know what was there before Mar 21 11:55:34 you could write your sed in a unpack postfunc, that might be better Mar 21 11:55:35 and i would prefer not hard coding that, but instead let bitbake just unpack from source instead Mar 21 11:55:43 and automatically re-run unpack for you Mar 21 11:55:59 you mean like a do_unpack_append() ? Mar 21 11:57:03 (i tried doing that, but i get very exotic syntax errors when i _append to unpack) Mar 21 11:57:08 no, a postfunc Mar 21 11:57:15 could you give an example? Mar 21 11:57:16 do_unpack[postfunc] = "my_function" Mar 21 11:57:21 grep the tree for examples Mar 21 11:57:27 ah, ok. i did not know those existed, thanks Mar 21 11:57:40 if you append to unpack you'll have to match existing python indentation, and of course be python as unpack is a python function Mar 21 11:57:56 so postfuncs/prefuncs are actually better for anything non-trivial Mar 21 11:58:09 ok, i'll try Mar 21 12:01:30 rburton: if i add a postfunc to a task, will any variable referenced in the postfunc be added to the vardeps of the task? Mar 21 12:01:41 or do i still need to have the explicit [vardeps] Mar 21 12:04:00 it can detect in that case Mar 21 12:09:45 excellent, now it works perfectly. thanks rburton Mar 21 12:41:09 rburton: TOOLCHAIN_TARGET_TASK triggers the dependency for the sdk, but the -dev package seems to have an implicit dependency on the main package - which in turn does not exist. is there a way to get rid of that? Mar 21 12:43:30 LetoThe2nd: RDEPENDS_${PN}-dev = "" Mar 21 12:43:42 yes by default PN-dev depends on PN, see bitbake.conf Mar 21 12:52:22 rburton: that seems to have done the trick, thanks! Mar 21 13:33:25 hello all Mar 21 13:33:55 after a package downgrade I have the following error: Mar 21 13:34:37 * opkg_download_file: .../build/tmp-glibc/deploy/ipk/aarch64/....ipk: No such file. Mar 21 13:34:38 * opkg_install_pkg: Failed to download .... Perhaps you need to run 'opkg update'? Mar 21 13:34:38 * opkg_solver_install: Cannot install package ... Mar 21 13:35:06 the package itself compiles fine Mar 21 13:35:34 should I clean the dependency cache for the rootfs? how? Mar 21 14:23:22 hey Mar 21 14:26:22 rburton: "yep, https://layers.openembedded.org/layerindex/recipe/24253/ tells you why so you can fix it" not sure I understand how to fix it Mar 21 14:29:05 related: is there any documentation (or at least a hint) how to configure the tty font? Mar 21 14:36:09 hi, i was debugging a build issue on our side (on master), which said Mar 21 14:36:09 tar (grandchild): xz: Cannot exec: No such file or directory Mar 21 14:36:09 adding hz in HOSTTOOLS 'fixes' the issue. but i am not sure if this is the right thing to do. i haven't followed the most recent discussions about HOSTTOOLS. Mar 21 14:36:45 there are many sources that use tar.xz, so i would expect this would work already. Mar 21 14:59:58 can an image recipe have a do_install too? e.g. add a couple of files? Mar 21 15:00:14 no Mar 21 15:00:18 do_install is what packages do Mar 21 15:00:31 you can do anything in a rootfs postprocess hook though Mar 21 15:01:06 rburton: i actually only want to inject two files that are only relevant for one specific image Mar 21 15:01:20 so rootfs postprocess hook is the keyword? Mar 21 15:01:32 or preprocess, as build-appliance-image does Mar 21 15:01:44 IMAGE_PREPROCESS_COMMAND += "inject_my_files; " Mar 21 15:02:14 joshuagl: rburton: great, thanks Mar 21 15:21:01 nevermind.. i found my issue.. i needed a dependency on xv-native in my recipe.. it's been silently working for years ;-) Mar 21 15:28:54 xv-native? i dread to think Mar 21 15:32:05 rburton: xz-native ;-) Mar 21 15:32:41 phew :) Mar 21 15:33:25 the qcom firmware come as a 'self extracting' file which ends up using xz.. and it just worked fine so far ! Mar 21 16:09:20 can anyone tell me why the login prompt is rendered with a different font than the actual shell after login? Mar 21 16:09:26 and how to change the font for the login prompt? Mar 21 22:02:57 anyone else seeing mtd-utils do_install start mysteriously failing on morty after working fine for months? Mar 21 22:07:56 georgem: what's the error? Mar 21 22:47:27 bluelightning: | install: cannot stat '/opt/kbuild/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/mtd-utils/1.5.2-r0/git//include/libubi.h': No such file or directory Mar 21 22:47:30 | WARNING: /opt/kbuild/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/mtd-utils/1.5.2-r0/temp/run.do_install.9028:1 exit 1 from 'install -m 0644 /opt/kbuild/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/mtd-utils/1.5.2-r0/git//include/libubi.h /opt/kbuild/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/mtd-utils/1.5.2-r0/image/usr/include/mtd/' Mar 21 22:47:35 | ERROR: Function failed: do_install (log file is located at /opt/kbuild/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/mtd-utils/1.5.2-r0/temp/log.do_install.9028) Mar 21 22:47:38 ERROR: Task (/opt/kbuild/setup-scripts/sources/openembedded-core/meta/recipes-devtools/mtd/mtd-utils_git.bb:do_install) failed with exit code '1' Mar 21 22:48:49 that's odd... I guess my first guess would be a missing dependency in the makefile making it non-deterministic Mar 21 22:49:05 since that's the sort of error you see under those circumstances **** ENDING LOGGING AT Wed Mar 22 03:00:01 2017