**** BEGIN LOGGING AT Thu Aug 02 03:00:01 2018 Aug 02 03:23:02 New news from stackoverflow: Yocto recipe written in python giving me an error when trying to build with Bitbake Aug 02 09:49:01 Hello Aug 02 09:49:57 when i run tests for the qemu, i include the tests on the local.conf and then run bitbake -c testimage Aug 02 09:50:27 i added "bb.tests.data.TestConcatOverride.test_remove \" Aug 02 09:51:08 which is not a part of the openembedded/openembedded-core/ but openembedded/bitbake Aug 02 09:51:33 however, the test is not running and no error is being thrown Aug 02 09:52:02 is there any way to add this test to run with the testimage? Aug 02 09:52:22 or are the bitbake tests different from testimage? Aug 02 10:36:33 anybody? Aug 02 10:54:12 kinsifous, they are different Aug 02 10:54:51 that's a test for bitbake, you can run it with bitbake-selftest Aug 02 11:07:27 whoever gave me an answer before, Thank you. My session ended and logged me out. Aug 02 11:13:35 [12:54] kinsifous, they are different [12:54] that's a test for bitbake, you can run it with bitbake-selftest Aug 02 11:13:52 mihai: thank you Aug 02 11:14:05 malencora: thanks for the tip Aug 02 11:48:25 Perhaps an "invalid" question since I'm still using pyro, but I started getting an error all of a sudden where quilt can't apply the default-gcc.patch..? Aug 02 11:48:53 rejects in tools/Makefile and tools/env/Makefile Aug 02 11:51:17 Aaa, nevermind :p Aug 02 12:50:40 if a recipe foo has a DEPENDS = "bar", then is bar built to completion, or at least through do_deploy(), before foo "runs"? Aug 02 12:52:15 i guess what i'm asking is, in this case, does bitbake/yocto still run through the tasks just once through firing the configured/addtask'ed tasks for both recipes, or does it run twice, once for each recipe? Aug 02 12:52:19 ...i think... Aug 02 12:52:53 i think the answer is just once Aug 02 12:53:28 which is why i needed a do_deploy[depends] = "virtual/kernel:do_deploy" in my foo recipe Aug 02 12:56:50 or am i not making sense? Aug 02 12:56:55 :) Aug 02 12:59:43 \/ Aug 02 12:59:48 works. Aug 02 13:05:56 If you have some DEPENDS Aug 02 13:06:33 The recipe is gonna be built after the do_sysroots/deploy, yes Aug 02 13:07:18 But the wirte_rpm/package tasks of the dependecy can be executed in parallel Aug 02 13:08:45 do_deploy[bar] = "virtual/kernel:do_deploy" Aug 02 13:09:08 Will start to build the recipe after virtual/kernel:do_deploy is completed Aug 02 13:11:53 i don't understand what the "do_deploy[bar] = "virtual/kernel:do_deploy" syntax means. Aug 02 13:12:37 yates: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#variable-flags Aug 02 13:13:36 i think i understood "do_deploy[depends] = "virtual/kernel:do_deploy"", meaning the do_deploy of foo (the line being inside foo.bb and foo.bb having a do_deploy task) depends on the do_deploy of the virtual/kernel recipe(s) completion Aug 02 13:17:53 does such a file make any sense? tmp/stamps/intel_corei7_64-poky-linux/nel-base/1.0-r0.do_image_complete_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene.0e1332570d90af079b91f4b3f31cdd2a.intel-corei7-64 Aug 02 13:18:06 if not does it ring any bell what could be wrong? Aug 02 13:18:19 u1106: I think I saw a patch on the mailing list about that.... Aug 02 13:18:52 JPEW: any keyword I could search for? Aug 02 13:19:17 rm_work setscene Aug 02 13:19:45 i don't understand what the term "runtime" means in the context of bitbake. i would say run at bitbake time is build-time. re: section 3.10.5, https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies Aug 02 13:20:09 s/run at bitbake/everything run at bitbake/ Aug 02 13:20:22 u1106: Looks there was a patch, but RP reverted it and did something else Aug 02 13:22:54 u1106: https://patchwork.openembedded.org/series/12629/ Aug 02 13:23:57 JPEW: thanks, but i'm not sure which of the variable flag types in that section match [bar]. bar is a recipe, and none of the variable flags seem to be recipes Aug 02 13:24:44 in any case, i'm good. do_deploy[depends] ... does what i want Aug 02 13:25:24 JPEW: Thanks! Hmm, 19-June, unlikely I have that (in Rocko) Aug 02 13:25:53 yates: "runtime" referes to when the compile code runs on the target... for example if your program links against libfoo.so, it has a runtime dependency on libfoo.so. Aug 02 13:26:34 yes, that's the "normal" definition, but it doesn't seem to make sense here. Aug 02 13:27:24 why does bitbake need to know about runtime dependencies ? Aug 02 13:27:48 yates: when bitbake generates the packages from a recipe, it need to add the meta-data into the package that indicates what other package each (runtime) depends on Aug 02 13:28:09 aha. now THAT makes sense! thank you! Aug 02 13:33:54 yates: FYI, OE has code to automatically detect link time dependencies for compiled executables, which is why you don't see RDEPENDS for every library a program links against (it trawls through the ELF files to find the libraries the program is expecting) Aug 02 13:34:50 JPEW: $ git log --grep "Simplify looping" --all --oneline Aug 02 13:34:50 52b11de rm_work: Simplify looping code Aug 02 13:34:50 $ git branch -r --contains 52b11deeb921ba20 Aug 02 13:34:50 upstream/master Aug 02 13:34:50 upstream/master-next Aug 02 13:34:51 so not in any release yet I guess. Do you know whether that bug/problem had serious consquences? The reason I was looking in my stamps was that my rootfs had been updated, but bitbake thought that it did not have to re-run linux-intel:do_bundle_initramfs Aug 02 13:36:24 (rootfs_cpio that is) Aug 02 13:36:53 u1106: I didn't follow the coversation, I just remember seeing the patches... It looks simple enough that it could get backported? Aug 02 13:37:45 what mailing list would that have been on? I don't seem to see it on the Yocto list Aug 02 13:37:57 Here is the original patch (that was reverted): https://patchwork.openembedded.org/series/11989/ Aug 02 13:38:36 Looks like it did eventually case a problem with filenames being too long Aug 02 13:38:59 openembedded-core Aug 02 13:42:45 JPEW: pretty impressive - i had no idea about all that Aug 02 13:44:51 Yes I have seen that problem with too long names making the build fail completely. It happens after creating 10s of images in the same build area. Starting from scratch with a new build area helps. So I could guess the bug has no other serious conseqences than creating nonsense files, which eventually make the build fail. Today I did not hit that, my build area is relatively new. So I guess linux-intel:do_bundle_initramfs not being called might be an Aug 02 13:44:51 unrelated issues. The weird filename just raised my attention. Thanks for your help Aug 02 13:45:16 JPEW: ^^^ Aug 02 13:45:28 u1106: np Aug 02 14:40:37 Hi All, Aug 02 14:40:41 How to debug custom yocto layer ? Aug 02 14:41:12 please provide me some input Aug 02 15:16:23 webreformer: bitbake -e Aug 02 15:17:26 ok, probably a very stupid, basic question: many python functions do things with "d", e.g., "d.getVarFlag("SWUPDATE_IMAGES_NOAPPEND_MACHINE", image, True)". what is "d"? Aug 02 15:18:14 bitbake "data store" (I think there is some better official name) Aug 02 15:19:16 JPEW: i see. are the functions like getVarFlag standard python functions or defined in bitbake? if the latter, are they defined somewhere? Aug 02 15:20:11 No, "d" is a class and those are member functions.... I don't have the exact source code path right now, but the bitbake manual can give more info Aug 02 15:20:57 so more to your question, they are defined by bitbake Aug 02 15:21:12 thanks - i go dig Aug 02 15:21:20 (in the right place) Aug 02 15:21:44 yates: Be careful, you might find the cookie monster Aug 02 15:21:52 bitbake/lib/bb/data_smart.py Aug 02 15:22:02 thanks! Aug 02 15:22:04 haha, yeah, it's a bit odd the way it's implemented, an artifact of our performance requirements Aug 02 15:22:10 (cookie monsters are welcome...) Aug 02 15:22:19 cookie monster is how overrides are handled, to avoid scanning the entire datastore to apply them Aug 02 15:22:41 or it's not a joke? Aug 02 15:22:46 No Aug 02 15:23:10 in most cases, 'd' is just available to you.. there are a few where it's 'e' (or environment), and to get 'd' (data) you need to do e.data..... Aug 02 15:23:26 event handlers have d now too Aug 02 15:23:33 as for the things to use.. d.expand, d.getVar, d.getVarFlags, d.setVar, d.setVarFlags are the common ones Aug 02 15:23:36 got d? Aug 02 15:23:45 :) Aug 02 15:23:45 kergoth ahh that got resolved, didn't realize that.. Aug 02 15:24:11 yeah, long standing annoyance.. it made sense at the time we implemented them, having everything in the event object, but writing 'd = e.data' all the damn time got old :) Aug 02 15:24:23 yates, I want to debug my yocto layer running inside board. Aug 02 15:24:48 question from someone, and I'm having a hard time finding a definitive resource.. 'VIRTUAL-RUNTIME' settings, I'm claiming they are 'distro' settings and can be used anywhere, by any recipe -- thus have to be globally set. Aug 02 15:24:52 webreformer: gdb? Aug 02 15:25:03 depends on what exactly you're debugging Aug 02 15:25:05 they are claiming, no they are image settings and can be set in an image context.. and other recipes should not use them Aug 02 15:25:31 webreformer, gdb is the debugger.. if you are doing kernel debugging (including modules) it is different then userspace debuggings.. Aug 02 15:25:50 userspace debugging, usually you want to generate a debug image, and tell gdb to use that debug image (when cross debugging) Aug 02 15:26:04 if you are debugging ON the target, then you need to add the debug symbols and sources onto the target image. Aug 02 15:26:30 webreformer: you can also do remote debugging using gdb. i've found that to be helpful for embedded linux systems Aug 02 15:27:03 yes, that is the typical usage Aug 02 15:27:04 I agree with you, nothing states they're image only, in fact aren't they already used in packagegroups too? Aug 02 15:27:41 yates, Yes, i am expecting remote debugging. Aug 02 15:28:19 Where I can find more relevant information ? Aug 02 15:29:02 use of gdb isn't really yocto specific, there are lots of good resources for that. you haven't really given enough info about what sort of debugging you need to do to be able to elaborate much Aug 02 15:29:18 kergoth, that is exactly what I thought.. Aug 02 15:29:30 a trick i often do, if the applicaiton you want to debug does not depend on hardware on the embedded system, or that hardware can be substituted on a desktop system (e.g., a usb serial dongle), is to natively compile the app on a desktop linux and debug there. that is MUCH easier and faster. Aug 02 15:29:38 https://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#platdev-gdb-remotedebug Aug 02 15:29:41 (debuggign with GDB) Aug 02 15:30:02 whoops.. thats an old manual.. Aug 02 15:30:05 let me get you a recent one Aug 02 15:30:15 yates: that's a very good point, yeah, only work on hardware if you have to Aug 02 15:30:23 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-gdb-remotedebug Aug 02 15:30:39 I want to debug custom yocto layer which acts as Application manager Aug 02 15:30:53 there that includes everything you need to get a proper gdb-server on the target, cross-gdb in the SDK, generate a regular and debug image.. Aug 02 15:31:06 as well as configure cross-gdb to use the debug symbols from the debug image Aug 02 15:31:30 kergoth: right! Aug 02 15:31:43 debugging a layer? as in the build doesn't work right? bitbake -e and inspecting the working directories are the ways to do that (for the most part) Aug 02 15:32:55 I want to debug C++ code build by 'layer' ? Aug 02 15:33:21 webreformer: what C++ code? Aug 02 15:33:37 what layer? Aug 02 15:35:02 I have custom layer. recipe inside it build C++ code Aug 02 15:35:16 follow the last link I posted Aug 02 15:35:20 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-gdb-remotedebug Aug 02 15:35:27 this is how you cross-debug code.. Aug 02 15:35:38 it tells you everything you should need to setup the debugging on target, as well as the host, etc Aug 02 15:35:49 customer layer doesn't matter.. code is code to the debugger Aug 02 15:35:53 'er.. custom Aug 02 15:36:09 I don't know exact terminologies here. sorry for that Aug 02 15:36:23 the system, including debugging is setup to be extended with custom layers without having to change anything to do debugging.. Aug 02 15:36:37 just follow the instructions in the manual. If you have questions about any instructions, ask those.. Aug 02 15:36:48 sure Aug 02 15:36:58 (actual GDB debugging steps are captured by the original GNU manuals..) Aug 02 15:55:44 is there a human-readable doc for getVar and getVarFlag? i am not too good with python... Aug 02 15:57:26 i guess it's obvoius? Aug 02 15:58:05 if FOO = "a value" and FOO[a] = "another value", then getVar(FOO) = "a value" and getVarFlag(FOO, a) = "another value"? Aug 02 16:13:10 d.getVar(value, [True/False]) -- the optional true/false is do you want the variable expanded or preserved.. True expands.. Aug 02 16:13:44 d.getVarFlags(value, flag, [True/False]) flags are variables like: VAR[flag] = 'value' Aug 02 16:13:55 d.setVar(variable, value) Aug 02 16:14:05 d.setVarFlags(variable, flag, value) Aug 02 16:14:15 thats about it.. pretty simple Aug 02 16:16:21 what does "expanded" and "preserved" mean? Aug 02 16:16:51 variable = "${foobar}" Aug 02 16:16:58 foobar = 'foo' Aug 02 16:17:07 ah Aug 02 16:17:10 d.getVar('variable', False) == "${foobar}" Aug 02 16:17:18 d.getVar('variable', True) == "foo" Aug 02 16:17:19 got it Aug 02 16:17:27 the default value is True BTW Aug 02 16:17:42 (at least in any recent versions, it was False until YP 2.0 I believe Aug 02 16:19:46 that if foo = 'foo', bar = '${foo}', and 'whatisthis' = '${bar}' ? what would d.getVar('whatisthis', True) return? Aug 02 16:19:53 s/that is/what if/ Aug 02 16:20:33 i meant s/that if/what if/ Aug 02 16:21:10 is expansion recursive? Aug 02 16:22:07 i think this gets into earlly/late expansion? Aug 02 16:28:06 yes, expansion is recursive, that would expand to foo Aug 02 16:29:09 it's always expanded when the getVar happens, which is generally when the task is run in the case of a task, but also when the user runs bibake -e, etc. you can force early expansion with := Aug 02 16:29:47 i.e. foo="1"; bar="${foo}"; baz:="${bar}"; foo="2" -- getVar('bar') == '2', getVar('baz') == '1' Aug 02 16:44:13 Hi, I'm an intern taking on a yocto project set up for our development board. Just wanted to introduce myself because I will have questions. Aug 02 16:54:47 how active is this chat? Aug 02 17:14:25 hi vmeson Aug 02 17:34:03 Hi I'm currently running into errors while running my build in bitbake, this is my command: bitbake phytec-headless-image -c populate_sdk Aug 02 17:35:03 im getting a fuction failed: patch_do_patch Aug 02 17:36:08 that doesn't tell us much of anything, you need to post the actual error log, ideally to a pastebin Aug 02 17:37:26 ok https://pastebin.com/4CnYvpnF Aug 02 17:38:51 thats my error output Aug 02 17:42:53 this is my log file of failure https://pastebin.com/dBdrBfMJ Aug 02 17:51:45 last file indicates you have a patch from the meta-phytex layer that does not apply Aug 02 17:51:55 you need to manually apply it and fix the patch it references.. Aug 02 17:52:06 patch in question is located at: /opt/PHYTEC_BSPs/yocto_ti/sources/poky/../meta-phytec/recipes-bsp/barebox/files/0001-Makefile-add-TARGETCC.patch Aug 02 18:35:07 @fray how can I go about manually applying the patch? This is my first time. I'm completely new and learning. Aug 02 18:36:00 this is one area, I'm not sure I can explain over IRC... there have been Yocto Project classes in the past that talk about this stuff, you might want to search those for more tutorial like steps Aug 02 18:36:22 (I have MY way of doing this, but it's often very different then the general recommended way for new users) Aug 02 18:41:44 I tried adding this on to the .bb file "SRC_URI += "file://example.patch" with the patch in question which i got from a stackoverflow post and I tested the build again and it gave me errors as before. I removed that line and now bitbake hasn't prompted any errors and I'm on task 1442 already. Aug 02 18:42:32 Hello, currently my build sym links /var/log -> volatile/log, how can I remove this link? I would like my log files to persist over reboots. Aug 02 18:43:43 Now I'm confused as to how to continuing the build. Thanks for your help @fray I will look around for more information. Aug 02 18:43:46 ideally we'd be able to use devtool to fix patches, but i think there's still an open issue to get a good workflow for it Aug 02 18:59:22 I'm trying to install the package "kernel-image-initramfs" into my image, which installs files to /boot. I get an error when the package install tries to overwrite some files which are already there Aug 02 18:59:28 ln: failed to create symbolic link '/Image': Permission denied Aug 02 19:01:13 How do I tell yocto to prefer the files from "kernel-image-initramfs"? Alternatively, how do find out what package installed those files so I can remove it Aug 02 19:01:50 armpit: a6be8399295203c76d049363b79b3566929ca60b (rm_work: Stop appending _setscene....) in sumo-mnut was reverted on master Aug 02 19:02:32 armpit: It had some issue and was replaced in favor of: https://patchwork.openembedded.org/series/12629/ Aug 02 19:04:08 the error is Aug 02 19:04:09 Collected errors: Aug 02 19:04:09 * check_data_file_clashes: Package kernel-image-image-4.4.38-l4t-r28.2+g41a10d67c1f0 wants to install file /home/tpreston/muos/build/tmp/work/jetson_tx2-poky-linux/resin-image/1.0-r0/rootfs/boot/Image Aug 02 19:04:09 But that file is already provided by package * kernel-image-initramfs Aug 02 19:49:45 I think I need to remove MACHINE_ESSENTIAL_EXTRA_RDEPENDS_remove = "kernel-image" Aug 02 19:50:54 So that it isn't included in `packagegroup-core-boot` Aug 02 21:10:57 Does anyone know if you add a HOSTTOOLS_NONFATAL to local.conf that if that binary requires a library it looks for it in build/tmp/? Aug 02 21:11:08 sorry poorly worded Aug 02 21:12:03 if you add a binary to HOSTTOOLS_NONFATAL, lets say confdc, and that confdc requires a library called confdexec it looks for it in build/tmp/lib (which doesn't exist) Aug 02 21:12:39 is there another way to specify where HOSTTOOL_NONFATAL libraries exist? Aug 02 21:16:09 it isn't bitbake looking for libraries Aug 02 21:16:13 its confdc Aug 02 21:16:58 do a readelf -d /path/to/confdc Aug 02 21:21:08 kergoth: you're correct and i don't even need to do a readelf because confdc is a script. So if confdc is a script and referencing a library in a certain location how should I handle that in bitbake? Aug 02 21:22:00 it sounds like the confdc script it operating relative to $0, and since we symlink it, $0 points to the symlink, not the real script. the script should be checking for that and calling readlink to handle it, but it's not Aug 02 21:22:37 kergoth: wow ur good Aug 02 21:22:48 I'd do: cd build; mkdir bin; echo '#!/bin/sh' >bin/confdc; echo '/path/to/real/confdc "$@"' >>bin/confdc; PATH="$PWD/bin:$PATH" Aug 02 21:22:58 then it's symlinking the wrapper script rather than the real thing Aug 02 21:23:06 chmod +x bin/confdc too of course Aug 02 21:23:50 dealing with $0 in a portable way in shell is a pain. it's not even guaranteed to be the absolute path, in some shells it could just be 'confdc' and you'd then have to find it in PATH yourself Aug 02 21:23:53 * kergoth does a fair bit of scripting Aug 02 21:24:12 let me give this a try Aug 02 21:40:40 damnit, why is linux-yocto failing on me repeatedly Aug 02 21:47:27 kergoth: symlinking the wrapper fixed the path problem but now I get a confdc: Cannot Fork error Aug 02 21:47:43 it's recursing. the wrapper is calling itself Aug 02 21:47:55 it has to either remove its own location from PATH, or explicitly call the full absolute path of the real binary Aug 02 21:48:06 hence i had /path/to/real/confdc in the above example Aug 02 21:48:40 ok let me try to fix Aug 02 22:05:22 kergoth: my wrapper has the full path to the real confdc binary. Wrapper in tmp/hosttools/confdc looks like this #!/bin/sh /home/user/confd/bin/confdc "$0" What is wrong with that? Aug 02 22:05:41 $0 is wrong, it's $@ Aug 02 22:05:51 looks fine otherwise Aug 02 22:05:52 sorry typo here Aug 02 22:06:04 it is $@ in the script Aug 02 22:08:08 just a sec, the wrapper overwrote the one in my home directory Aug 02 22:11:05 kergoth: bitbake seems to be putting the /home/user/confd/bin/confdc in the tmp/hosttools directory even though build/bin/confdc is first in the patch Aug 02 22:11:07 path Aug 02 22:47:36 kergoth: r u still there? wrapper script is working but i have another question regarding the use of update-alternatives class Aug 02 22:49:54 kergoth: for example i had a dnf error because two different components were using the same xml file. However, if I try to use ALTERNATIVE, ALTERNATIVE_LINK_NAME, ALTERNATIVE_TARGET they all seem to default to /usr/bin. But I need a path to /usr/confd/../../ Aug 02 22:52:50 grep -nrI ALTERNATIVE oe-core/meta|grep ':.*/' Aug 02 22:52:59 plenty of usages for paths other than usr/bin there Aug 02 22:53:25 existing recipes are always a good reference Aug 03 02:45:31 fancer: okay, finally got my base cross canadian changes + the majority of yours merged to master, first a set of general fixes, then the cross-canadian specific bits, there's still a fancer-integrate branch with the bits that haven't been merged, mainly linux-libc-headers, hte glibc recipe split to the components, strace-external, and the ct-ng specifics. i'll look over those again later **** ENDING LOGGING AT Fri Aug 03 03:00:00 2018