**** BEGIN LOGGING AT Wed Mar 18 02:59:58 2020 Mar 18 03:21:56 New news from stackoverflow: Why .ipkg format is mainly considered for the embedded devices...? [closed] Mar 18 05:13:08 Hello...I am creating Debian Package .deb files as output of an application. I have preinst postinst maintainer scripts as part of deb package. I currently have this included as pkg_preinst_${PN} and related functions Mar 18 05:13:17 the actual script is written inside these functions Mar 18 05:13:31 is there a way to include external scripts as part of this functions ? Mar 18 05:14:21 I used include /preinstscript.sh as first line of pkg_preinst_${PN} but it did not work Mar 18 06:59:25 hello... I m getting "mkdir: cannot create directory ‘/var/DIRNAME : Permission denied' Mar 18 06:59:58 "dpkg : error processing archive DEBIANPACKAGENAME.deb (--unpack): Mar 18 07:00:26 "new DEBIANPACKAGENAME package pre-installation script subprocess returned error exit status 1" Mar 18 07:01:01 I have a mkdir inside the pkg_preinst_${PN}. and that is throwing this error when do_rootfs runs Mar 18 07:01:29 how do I successfully create this directory inside /var as part of my preinst procedure Mar 18 07:32:05 kiwi_29: You are getting that during image build, right? You're post install script need to handle the case where it's run during rootfs creation. I think most script do that by checking if env variable D is set. Mar 18 07:36:38 Well wasn't that reply from me well timed Mar 18 07:37:26 Well, kiwi_29, if you're looking at logs later you might want to have a look at: https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#post-installation-scripts Mar 18 08:52:37 Hi, when using devtool to build & deploy a custom application, can I specify a build mode via command line? Something like `devtool --mode=debug build myapp` such that i can use some kind of ${mode} variable inside my recipe, e.g. via EXTRA_OECMAKE += "BUILD_MODE=${mode}"? Mar 18 08:53:42 Erlkoenig: nope, it doesn't work like that. Mar 18 08:54:15 Erlkoenig: closest match probably is to do devtool edit-recipe and tinker it there. Mar 18 08:55:00 milloni: probably. incidently, gcc-dbg does not contain the source either Mar 18 08:55:22 Mh, okay... Mar 18 08:55:52 yann: i wouldn't expect it to, unless i'm missing something -dbg packages in general are not meant to contain source, -dev packages are Mar 18 08:56:38 Erlkoenig: once *could* maybe extend devtool with some form of "environment passing" mechanism, but 1) thats pretty much contradicting the mindset and 2) still someone would have to do it and send patches :) Mar 18 08:56:39 no, -dev package are supposed to ship headers and libs. -dbg packages OTOH ship debug symbols and source code to make sense out of them Mar 18 08:57:56 i wonder if gcc is somewhat special, because source is packaged Mar 18 08:58:07 Hm. I could make a "myapp-buildmode.bbappend" that just contains MYAPP_BUILD_MODE="debug" and autogenerate that on demand... Mar 18 08:58:41 yann: recent yocto? try gcc-src Mar 18 08:58:51 rburton: re yesterdays evening topic: technically i agree on the "full bitbake" mindset, but the thing is that the esdk is already there and ready to be used. Mar 18 08:59:01 LetoThe2nd: and not finished Mar 18 08:59:07 Erlkoenig: what exactly are you trying to solve as an issue? Mar 18 08:59:08 rburton: not so recent yet, sumo in this case :( Mar 18 08:59:25 Erlkoenig: if you are using devtool, there is an append already under the hood anyways. Mar 18 08:59:36 yes indeed Mar 18 08:59:45 rburton: what do you mean exactly? Mar 18 08:59:51 I would like to be able to easily test debug and release versions for my application Mar 18 09:00:05 And add the respective build commands to my IDE Mar 18 09:00:10 LetoThe2nd: esdk is a great idea but its complex and was never quite "done" Mar 18 09:00:56 rburton: its close enough for what i envision as a start, hence the idea. Mar 18 09:01:18 Erlkoenig: make two recipes, one inherit the other and just adding your debug flag? then build one or the other?\ Mar 18 09:01:36 LetoThe2nd: why not just ship bitbake and a sstate cache fragment directly Mar 18 09:01:43 Hmm, good idea! Mar 18 09:02:00 Erlkoenig: does not work well with devtool though because to it it's two different recipes so you would have to do your changes twice. But for when you are stopping to use devtool, should be okayish Mar 18 09:02:39 rburton: hum but how would one package up the sstate? Mar 18 09:02:54 Erlkoenig: also, you could use PACKAGECONFIG for that, pass a flag to make with ETXRA_OECONF or EXTRA_OEMAKE with it. Then from your local.conf you can put PACKAGECONFIG_pn-myrecipe_append = " debug" ? Mar 18 09:03:08 LetoThe2nd: using the same method the esdk does ;) Mar 18 09:03:26 rburton: hmmm good point. Mar 18 09:03:30 LetoThe2nd: is your goal just 'this container works out of the box' Mar 18 09:03:31 will have to think about it. Mar 18 09:03:45 I'd rather not modify the local.conf programmatically :) The idea was to have the usual "Build release" and "Build debug" buttons in the IDE to work as usual Mar 18 09:04:07 rburton: the goal is: "this appliance can build for $TARGETIMAGE out of the box." Mar 18 09:04:31 rburton: I don't see a gcc-src even in poky's master Mar 18 09:06:35 well, I can surely tune the host gdb configuration to find the source in work-shared, anyway Mar 18 09:11:15 yann: what are you actually trying to do? Mar 18 09:13:00 trying to indentify the root cause of a abort that appears to happen during thread creation. Most of the stack is within libstdc++, hence the need for the source files :) Mar 18 09:13:22 I'll trick gdb with a symlink into work-shared, that ought to be sufficient for me Mar 18 09:13:45 gdb on target or remote gdb? Mar 18 09:14:13 remote Mar 18 09:15:51 i mean, using gdbserver? https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#platdev-gdb-remotedebug covers generating a debug filesystem for all the symbols. Mar 18 09:15:59 but if you don't have -src packages then -dbg should have them Mar 18 09:16:15 unless your distro/bsp is turning them off :) Mar 18 09:16:48 yes using gdbserver, with a partial roofs extracted from the relevant *-dbg.ipk Mar 18 09:17:25 so my gdb has all the syms and source it needs... except for the libstdc++ ones that don't appear to end up in such a package Mar 18 09:19:39 thread creation via std::thread doesn't work? does pthread_create work? Mar 18 09:21:11 yann: on my list of things to do is look at debuginfod so this just magically works Mar 18 09:21:30 Erlkoenig: why shouldn't it work? Mar 18 09:22:04 Trying to help yann :) ... maybe something with passing bound parameters Mar 18 09:22:09 yeah that particular item is particularly sexy :) Mar 18 09:52:55 yann: you want the gcc-runtime recipe, not gcc Mar 18 09:53:10 New news from stackoverflow: Old version of library is included in image after updating bitbake file Mar 18 09:54:09 yann: but yeah that doesn't built a src package Mar 18 10:02:30 yann: file a bug :) Mar 18 10:23:17 New news from stackoverflow: (EE) open /dev/dri/card0: No such file or directory in Yocto Mar 18 10:30:42 hello, I am currently exploring different bootloader + update agent combinations for a Phytec i.MX6UL SoM.... can anyone share opinions on whether their barebox+RAUC offering (implemented in a Yocto BSP) is better than u-boot + SWUpdate (that some other SoM vendors use)? Mar 18 10:32:19 I am considering making my own u-boot + SWUpdate BSP since it currently seems to me these components have wider adoption in the embeddded Linux community overall Mar 18 10:33:13 If I am wrong about it, I would like to know before investing a considerable amount of time Mar 18 10:40:49 eduardas: there is no one true answer Mar 18 10:52:04 eduardas, barebox has a nice shell with paths and files instead of simple environment variables. If you want to stay with phytec, you can use it. Phytec is the only vendor I know, that provides barebox as default. Mar 18 10:57:46 On Debian using docker with debian I installed a SDK. Installed to /home/user/sdk/ and zipped it. Now I would like to give this SDK to other developers, but I am getting an issue that the "./arm-poky-linux-gnueabi-gcc: No such file or directory". I used file command and its an ELF 64 bit executable, x86-64. When i open the file, I can clearly see that there is an "ld-linux-x86-64.so.2" link inside the Mar 18 10:57:48 executable that has a wrong path. I expect there should be a better method to do all this already when building the SDK. Any reccomendations? Mar 18 10:58:38 Other developers are using ubuntu and arch-linux. Mar 18 10:59:57 pi1: why do you "install and then re-zip" the sdk, first and foremost? Mar 18 11:01:13 LetoThe2nd: I found the rootfs and the toolchain there, so I assumed this would be the folder I was looking for. Do you have a better solution? Mar 18 11:01:27 pi1: how did you "install to /home/user/sdk"? Mar 18 11:01:33 pi1: bitbake $YOURIMAGE -c populate_sdk ? Mar 18 11:02:50 I did bitbake $MYIMAGE -c populate_sdk and found in /tmp/deploy/sdk a script which I ran. Can I ship this script instead? Mar 18 11:03:11 yes Mar 18 11:03:24 pi1: thats exactly what its meant for, yes. Mar 18 11:03:30 LetoThe2nd: any other reccomendations to ship the toolchain. Mar 18 11:03:54 pi1: that is the recommendation to ship the toolchain. Mar 18 11:04:33 LetoThe2nd: do you mean to run the script in the sdk folder or to ship the sdk folder? Mar 18 11:04:57 pi1: you just ship the .sh that you find in /tmp/deply/sdk/... Mar 18 11:04:58 Ship the script, it's basically an SDK installer meant for distribution Mar 18 11:05:12 LetoThe2nd: No other files? Mar 18 11:05:26 pi1: it's self contained Mar 18 11:05:37 impressive. I will try Mar 18 11:05:46 pi1: seriously, i don't get whats so complicated about it. Mar 18 11:06:10 pi1: plus, we have rather good documentation on it. and plusplus, it is also explained in live coding session #3 (IIRC) Mar 18 11:06:40 LetoThe2nd: When you see that it's a shell script, it's not that far off to assume it's a script copying files from the build dir or so. Mar 18 11:06:49 LetoThe2nd: I missunderstood. I saw that the SDK was much bigger than this script, and I did not know it was self contained Mar 18 11:07:19 erbo: i never had that idea, to be honest. Mar 18 11:07:20 I guess not everyone has seen the trick of embedding compressed data in a shell script. Mar 18 11:07:39 Thanks guys Mar 18 11:10:55 LetoThe2nd: But you are the master, not the apprentice :) Mar 18 11:11:28 erbo: its not so long since i was a complete newb too. Mar 18 12:06:24 Anybody knows how can I debug cmake issues when working on a recipe (using devtool) in an eSDK? Mar 18 12:08:02 I added some message() calls to my CMakeLists.txt. If Itry to build not using devtool then I can see my messages, but when runnint devtool build they are ignored making it difficult to debug and find out what the issue is Mar 18 12:18:06 nemgti-og: have you tried with -d? Mar 18 12:33:17 I have the suspicion that my messages are not delivered here. Can anybody reply this back to know if my suspicions are correct - or not? Mar 18 12:35:22 qschulz: - I didnt see your message before. So, I have not try with -d. Should I try it in this way: "devtool -d build " Mar 18 12:36:18 Ah ok... I am looking at the help menu. I got it qschulz Thanks Mar 18 12:38:23 nemgti-og: aren't you just missing a DEPENDS at build time? Or could it be that your cmake does not take the --sysroot passed by Yocto? Mar 18 12:38:44 nemgti-og: devtool uses bitbake under the hood Mar 18 12:39:29 nemgti-og: look for missing DEPENDS in the recipe, or hardcoded or set with := CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS in your cmake Mar 18 12:40:04 qschulz: I am guessing the second of your options Mar 18 12:42:40 qschulz: I mean, if I run cmake by myself the command will be found. Only when tryingto build via devtool is the command not found. So I think no DEPENDS are missing -> I understand DEPENDS is used to mark other recipe's files as dependencies Mar 18 12:44:24 qschulz: also... unfortunately the option -d won't give me addition useful info. :/ Thank you for the hint anyways Mar 18 12:45:32 nemgti-og: DEPENDS is used to say which other recipe you depends on at build time. So if you need some binaries, header files or libraries from other SW, they have to be in DEPENDS. If you need some binaries for other things than linking, then most probably you want the -native variant of the recipe in DEPENDS Mar 18 12:48:45 qschulz: Ok. But if my binnary (the command to execute by cmake) is not provided by any other recipe, but instead is already provided in my environment, should I declare it anyways in DEPENDS? Mar 18 12:49:42 qschulz: it might be that I am instead missing a RDEPENDS? The doc says "List a package'sruntime dependencies (i.e. other packages) that must be installed in order for the built package to run correctly" Mar 18 12:52:47 No... reading further it seems to me that I am also not missing a RDEPENDS Mar 18 12:56:37 nemgti-og: you don't want to have host contamination in Yocto, so if no recipe is providing this binary, you have to create this recipe (look up first on layers.openembedded.org and on google, there might be one available already) Mar 18 12:59:05 nemgti-og: but IIRC, host contamination is possible in Yocto and not detected, so even if you should fix that, there's a bigger problem in the picture. Is your binary not in $PATH for example? Just throwing ideas Mar 18 13:02:03 qschulz: Thanks. Yes the binary is accessible via the $PATH. So... the recomended practice is to provide such binary via a recipe --> does this apply too when working with an eSDK? So my eSDK should have a recipe that provides the binary? Since the binary is already in my host (in /usr/bin) I thouth I could simply install the eSDK and "devtool buid" with it Mar 18 13:08:06 nemgti-og: the thing is, you would require other devs/users of your recipe to install your binary in their host distribution. And then starts the nightmare of people having different versions of the same binary provided by differnet distros/versions of distros. Mar 18 13:09:29 qschulz: Now I see it. You're right. Thanks again! Mar 18 13:17:26 Hi. Since my settings were deleted for some reason, can someone remind me how to set `ARM_INSTRUCTION_SET` for specific recipe inside *local.conf*? Mar 18 13:17:51 `ARM_INSTRUCTION_SET-PN`? I can't remember Mar 18 13:31:21 _pn- Mar 18 13:36:56 ah thanks Mar 18 13:38:26 Another question please: Is there any way to force build of a specific recipe? If I use `bitbake ` it probably has logs of hashes and it does not rebuild the recipe if it does not see a reason (by the hash) Mar 18 13:44:08 nacknick: you could try bitbake -c cleansstate This will remove the shared state of the recipe/package in question and therefore it will be rebuilt next time you run bitbake on it or any other recipe that depends on it Mar 18 13:48:43 khem: Are you around yet? Mar 18 14:50:31 JPEW: now yes Mar 18 14:56:21 Is there a way to add a file during the building process to the `/lib` directory of the final image? Mar 18 14:58:22 nacknick: create a recipe which installs that file in /lib and add the package created by this recipe to the final image? Mar 18 15:01:21 qschulz I'm not sure how to install file into the /lib directory. What is the command? Mar 18 15:06:26 nacknick: install ${S}/myfile ${D}{base_libdir} in do_install task? if it has to be in /lib even when using multilib, nonarch_base_libdir instead of base_libdir Mar 18 15:06:43 is anyone using Android Verified Boot (libAVB) in u-boot and the abvtool with Yocto-produced images? is it a bad idea? Mar 18 15:08:28 nacknick: I feel like you would like to watch: https://www.youtube.com/user/TheYoctoProject/videos Mar 18 15:09:12 nemik: maybe something to ask on #u-boot also to check how well supported this is (is it even upstreamed?) Mar 18 15:09:52 qschulz: Thanks. I already watched some of the videos Mar 18 15:10:25 nacknick: BTW, the install command is not Yocto specific ;) Mar 18 15:10:43 I know. It's Linux's Mar 18 15:12:05 nacknick: I didn't know it existed before I worked with Yocto, that's why I'm sharing Mar 18 15:12:35 Haha me too Mar 18 15:12:59 Have you never installed something using a source tarball and "make install" and wondered what all the lines starting with "install" do ;-) Mar 18 15:18:03 khem: I got an AUH failure for diffoscope because it doesn't build for musl https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/diffoscope/diffoscope_136.bb#n16 Mar 18 15:18:11 does anybody know why when bitbaking nativsdk recipes, the packages are placed under ${D}${datadir}? Where in my case looks like "/opt/opky-ivi-systemd/2.6.2". In my poky-ivi-systemd.conf I have set SDKEXTPATH to something different than Mar 18 15:18:16 khem: Is there a way to make the AUH happy in this case? Mar 18 15:18:56 khem: Perhaps RECIPE_NO_UPDATE_REASON_libc-musl = "Dependencies don't build for musl" ? Mar 18 15:39:04 nemgti-og: thats the nativesdk prefix, that gets relocated when you install the SDK Mar 18 15:39:36 rburton: yes thanks! I have found the variables that hold this path. Thank you! Mar 18 15:39:52 nemgti-og: you don't need to change it, consider it a implementation detail Mar 18 15:41:28 rburton: but if I change the installatin path of my eSDK, the recipes that DEPENDS/RDEPENDS on other recipes will try to find such dependencies based on that won't they? Mar 18 15:41:34 no Mar 18 15:41:38 they get relocated Mar 18 15:41:55 at SDK installation time you decide where it goes Mar 18 15:42:12 aham.... yes Mar 18 15:42:27 khem: do we need to autoconf binutils, or can we just run configure directly Mar 18 16:28:53 If I have a project where recipe A depends on B depends on C. Then I rebuild C (say via force compile/deploy). How can I rebuild A to get it build based upon C? Mar 18 16:30:09 bri92: if I'm not mistaken, Yocto should already do it by itself Mar 18 16:31:07 Hmmm... perhaps I have a broken dependency... Need to look more. Thanks. Mar 18 16:31:31 bri92: better define what's the issue :) what do you want to do, what have you done, what's the error you're havin Mar 18 16:32:55 Problem is, the issue is as above. I rebuild C and see the end products in tmp/deploy, and then try to rebuild A but it doesn't run any tasks. Mar 18 16:33:18 Normally, though, if building from a clean slate, A, B, and C get built. Mar 18 16:33:44 (and A includes the C end products) Mar 18 16:34:15 bri92: by "depends" you mean an actual DEPENDS right? Mar 18 16:34:27 bri92: what version of yocto are you using? Mar 18 16:34:30 yes Mar 18 16:34:34 Thud Mar 18 16:36:08 bri92: what files from C do you need in A? specifically, where do you get them from? Mar 18 16:37:02 C deploys an elf file into tmp/deploy. A uses that file to generate a bigger binary. Mar 18 16:37:57 bri92: Yocto has no knowledge of that file in A recipe, so it does not know it needs to rebuild A Mar 18 16:38:23 bri92: specifically, it knows a file has changed for a recipe and that it needs rebuild if it's in SRC_URI (maybe some other mechanisms, but that one, for sure) Mar 18 16:39:07 Oh. hmmm... Can you make it depend on the deploys? I (I guess mistakenly) thought that it did Mar 18 16:39:08 in your case, I doubt very much it is passed in SRC_URI in A Mar 18 16:39:20 It's not Mar 18 16:39:53 bri92: what is the name of the task in recipe A using the deployed file? Mar 18 16:40:42 compile Mar 18 16:41:25 I think you should be able to do do_compile[depends] += "recipeB:do_deploy" in recipeA Mar 18 16:42:02 Ahha... that makes some sense (I've seen that convention around)... Mar 18 16:42:17 Very cool. Mar 18 16:42:50 this means that your do_compile of recipeA depends on do_deploy of recipeB (typo, should be recipeC from your example). so iff do_deploy gets run again for some reason, the do_compile of recipeA will have to be re-run as well since it's a dependency Mar 18 16:42:56 I *think* Mar 18 16:43:19 I will try it. Mar 18 16:44:09 I've been yocto-ing a good bit for the past few months, and wow does it have a steep learning curve... Mar 18 16:48:31 bri92: why are you deploying an elf to deploydir? if you want to run a binary during the build, write a native recipe to install it into the sysroot, and then just DEPEND on that recipe Mar 18 16:49:04 It's a boot binary, get loaded via JTAG or burnt to QSPI flash Mar 18 16:49:26 gotcha Mar 18 16:49:29 bri92: it's very important to YP that if there's anything to be improved in our docs or other way, that you share what you would have liked (even better, a patch to docs). The project knows it's not easy but for long time contributors it's hard to see what to improve for beginners Mar 18 16:49:38 then yes you want to do the explict depends on the do_deploy Mar 18 16:50:05 as depends is just shorthand for "this recipe's do_configure depends on these recipe's do_populate_sysroot" Mar 18 16:50:30 DEPENDS Mar 18 16:50:39 I got another question I have been postponing. After sourcing the environment-setup script of my eSDK I can't run devtool - it complains that there is no python3.5.real (No such file or directory) in order to solve this I have to manually rm (only after sourcing the environment-setup script) python3 from ${SDKTARGETSYSROOT}/usr/bin. Does anybody know why this happens? Mar 18 16:50:41 right Mar 18 16:51:09 nemgti-og: is there a python3.5.real in the sdk somewhere? Mar 18 16:51:15 *should* be alongside the python3.5 wrapper Mar 18 16:52:41 actually, python3.5.real is located in the same directory ${SDKTARGETSYSROOT}/usr/bin Mar 18 16:55:05 right, so figure out why it isnt being ran :) Mar 18 17:06:29 rburton: we need to autoconf it Mar 18 17:06:45 khem: but i want to test a new autoconf release Mar 18 17:06:52 rburton: I was doing it in patches but thats too error prone Mar 18 17:07:27 yeah go for it Mar 18 17:07:56 khem: but binutils aborts if the autoconf version isn't exactly 2.69 :) Mar 18 17:08:23 there are patches which modify confugure.ac or other related files so other option is to regenerate configure in everyone of those patches manually Mar 18 17:08:27 using 2.69 Mar 18 17:08:33 and refresh those patches Mar 18 17:08:37 why isn't the usual autotools reconfiguring usable? it calls autoconf directly Mar 18 17:08:54 as I said we modiy configure.ac Mar 18 17:08:58 (i tried patching the version check out but then it broke because aclocal isn't modified) Mar 18 17:09:12 right, i mean why does binutils have a custom do_configure instead of using the autotools class Mar 18 17:09:27 it does not need reconf Mar 18 17:09:48 only autoconf to regenerate configure Mar 18 17:09:51 not bootstrap it Mar 18 17:10:29 perhaps fallback to adding configure changes to relevant patches Mar 18 17:10:39 and dont call autoconf is easier way forward Mar 18 17:10:49 even though that means pain to maintain those patches Mar 18 17:11:39 JPEW: I think AUH has issues here Mar 18 17:12:07 the recipe clearly says its not compatible with musl Mar 18 17:12:18 Well... I dont really see it. What I know is, if I remove python3 from ${SDKTARGETSYSROOT}/usr/bin, then the next time I run devtool, it will use python3 from another directory (i.e. ./buildtools/sysroots/x86_64-pokysdk-linux/usr/bin/python3) Mar 18 17:13:58 JPEW: perhaps RECIPE_NO_UPDATE_REASON_libc-musl is a good workaround Mar 18 17:14:22 but I would think fixing it in AUH might be better Mar 18 17:34:10 khem: file a bug and cc kanavin Mar 18 18:06:48 <[Sno]> RP: is it worth to do a upgrade of perl (5.30.1 -> 5.30.2) soon or is release more or less done? Mar 18 18:09:13 <[Sno]> https://metacpan.org/pod/release/SHAY/perl-5.30.2/pod/perldelta.pod#Selected-Bug-Fixes Mar 18 18:16:17 ugh perl scares me always Mar 18 18:16:27 is it bugfix only release ? Mar 18 18:21:14 erbo ...many thanks for prompt reply. I will check the information you provided Mar 18 18:51:52 [Sno]: I'm probably nervous of that at this point Mar 18 19:31:45 <[Sno]> khem: yes Mar 18 19:32:01 <[Sno]> RP: that's why I'm asking before acting :F Mar 18 19:32:03 <[Sno]> :D Mar 18 20:10:51 is cmake ran during do_configure task? Mar 18 20:12:41 nemgti-og: yes Mar 18 20:13:25 thanks erbo. I guess RDEPENS is not needed during do_configure right? is DEPENDS needed at this stage? Mar 18 20:14:30 nemgti-og: correct, DEPENDS are for build time dependencies and RDEPENDS for run-time Mar 18 20:22:03 erbo: I have a recipe that basically download a binary release from a github repo and another recipe that executes this binary on its CMakeLists.txt (add_custom_command block). In the second recipe, I have added a DEPENDS_${PN} += ", but when running devtool build (in my eSDK), cmake cannot find the executable (File not found) Mar 18 20:22:22 Do you by any chance have a clue of what I might be missing? Mar 18 20:22:25 there's no such thing as DEPENDS_${PN} Mar 18 20:22:44 then should it be simple DEPENDS += ? Mar 18 20:22:45 RDEPENDS is per-package, because a single recipe emits multiple binary packages. DEPENDS is recipe-wide build dependencies Mar 18 20:22:46 yes Mar 18 20:23:22 Thanks. I'll give it a try Mar 18 20:23:28 i don't know where people keep getting DEPENDS_${PN} from, it's not used anywhere in any layers Mar 18 20:23:53 I don't know, maybe we are all newbies - at leats I am :D Mar 18 20:25:24 New news from stackoverflow: do_rootfs error due to package installation Mar 18 20:25:34 that's fair enough, but i'd suggest 1) the yocto project docs and 2) looking at some existing recipes in oe-core, preferably both, as it'll help you get a good understanding. you can also use `recipetool create ` to create a recipe automatically given an upstream url to its sources Mar 18 20:26:38 kergoth, you're the father of bitbake, right ? Mar 18 20:26:43 the project has an admittedly high learning curve, having as much flexibility as it does comes with a certain cost Mar 18 20:27:05 one of them, yeah, it was a few of us that started the project. i'll take the blame for a lot of its code, i was still learning python at hte time :) Mar 18 20:28:46 kergoth: is recipetool create doing the same as devtool add? Mar 18 20:29:14 and thanks for the hints. I will comply Mar 18 20:29:26 kergoth, well I'll give you credit for it. But there is a thing that confuses me, compared to GNU make, in that references to undefined variables are kept as is during immediate expansion, instead of evaluating to nothing as in make. Is that really the intended behaviour in bitbake ? Mar 18 20:30:00 that comes down to the original inspirations and code, actually. in retrospect it was a terrible decision Mar 18 20:30:13 originally we were inspired by and even used a little of the code from gentoo's portage Mar 18 20:30:28 gentoo's recipes were shell scripts, though, and we didn't want to go in that direction Mar 18 20:30:49 we left them unexpanded to keep a certain feature parity and to let the shell expand them if bitbake didn't Mar 18 20:30:58 but it just causes a ton of confusion bout when expansion occurs, now Mar 18 20:31:11 we should have used a different syntax entirely, ex %{} ala .spec Mar 18 20:31:58 it was also to deal with unhandled syntax without having to directly parse the shell code Mar 18 20:32:13 for example, ${foo:-bar} as used in a shell script would never be expanded by bitbake Mar 18 20:32:17 unless you had a foo:-bar variable Mar 18 20:32:34 so that really should be left as is Mar 18 20:32:54 I prototyped patching bitbake to warn/error on unexpanded variables and got bit by those :) Mar 18 20:34:18 aha Mar 18 20:36:26 like i said, if we'd used a different syntax entirely for our own expansions it'd have been a nonissue, but a bit late to do anything about it now without adding a new file format entirely Mar 18 20:37:35 which would be nice, but no one ever cares enough to take on that particular pain :) Mar 18 20:37:39 including me Mar 18 20:37:53 understandably Mar 18 20:38:02 our file format has a lot of quirks, actually. the mixed declarative and imperative nature is quite irritating Mar 18 20:38:13 it looks declarative, but a lot of things are order dependent, so it really isn't Mar 18 20:39:20 there's also a very tight binding between bitbake and the metadata due to the file format. the latter makes assumptions about how the former does its work. the fact taht recipes and classes can add tasks and poke into *how* bitbake does its job makes it harder to introduce a new format without also mirroring that Mar 18 20:41:13 kergoth, RP, so it sounds like that's not going to change, so I'd say merging http://lists.openembedded.org/pipermail/bitbake-devel/2020-January/020851.html is better than having incorrect examples in the manual Mar 18 20:41:54 agreed, we should definitely mention the behavior Mar 18 20:42:09 probably in more places than just there, as it affects more than just immediate expansion Mar 18 20:42:41 Hmm, if we made emit_var also emit non-exported variables into the shell and then didn't expand bitbake variables in shell functions, it'd still be able to access those variables, but at runtime in the shell, I wonder how much would break. we'd still need to handle ${@} the way we do now, though Mar 18 20:47:15 hello every body :) Mar 18 20:49:18 does any body have good tutorial for kernel linux (not only kernel module ) and how it work and maybe some historical decisions Mar 18 20:49:25 thanks a lot Mar 18 21:25:31 md_micheal: learning the kernel is difficult Mar 18 21:25:35 there's no single resource Mar 18 21:25:47 i suggest you find someone who knows stuff about it and ask them Mar 18 21:26:22 or do you mean the kernel in yocto? in that case see meta-skeleton Mar 18 22:20:10 /quit **** ENDING LOGGING AT Thu Mar 19 03:00:02 2020