**** BEGIN LOGGING AT Wed Nov 29 03:00:02 2017 Nov 29 06:24:17 Hi all, I'm trying to fetch a git repo and compiling it using cmake, but getting error of "bad RPATH", by doing < do_package_qa[noexec] = "1" > provides a work around but not a proper fix. anybody have idea what can be wrong? Nov 29 08:05:05 good morning Nov 29 08:17:40 New news from stackoverflow: how to enable systemd in x11 in yocto Nov 29 08:21:32 mckoan: good morning Nov 29 09:27:56 hi everyone Nov 29 09:29:28 I have a problem with the postinstall scripts, with a package, the scripts are not present in the rpm package, and they are not launched in the do_rootfs Nov 29 09:29:42 how can I debug this? Nov 29 09:31:02 I can see the postinstall script in the pkgdata/runtime/"pkgname" Nov 29 09:31:49 but now I don't know where I can continue to debug this problem Nov 29 09:31:57 If anyone can help me... Nov 29 09:33:41 this is not my first package, I tried to set the pkg_postinst_${PN} but still nothing in the RPM (I'm trying to install a service file... and it is not activated during install) Nov 29 09:45:58 aurele: systemd service ? Nov 29 09:46:19 nayfe, yes systemd service Nov 29 09:46:46 I have a lead, maybe it is because of the package name Nov 29 09:47:41 I have 1 upper case in the package name Nov 29 09:47:41 aurele: you don't need postinstall to install systemd service, you can use SYSTEMD_SERVICE_${PN} = "XXX.service" is it a custom stuff ? Nov 29 09:48:35 nayfe, I noticed the service doesn't install correctly then after investigation the postinstall script are not used in the package Nov 29 09:49:14 do you inherit systemd ? Nov 29 09:49:26 nayfe, then if I fix the postinstall script missing, my service will be activated Nov 29 09:49:36 nayfe, yes Nov 29 09:51:33 aurele: maybe pastbin your recipe? Nov 29 09:58:08 nayfe, https://paste.ubuntu.com/26070905/ Nov 29 09:59:27 nayfe, the content of the file "pkgdata/runtime/onvifCpp" https://paste.ubuntu.com/26070910/ Nov 29 10:05:21 aurele: what's the name of your recipe ? onvifdiscovery ? maybe you need to RDEPENDS castel service ? Nov 29 10:06:27 the name of the package is onvifCpp Nov 29 10:08:22 nayfe, I removed the upper case letter and everything is ok... Nov 29 10:09:22 aurele: good to hear Nov 29 10:12:09 nayfe, Is it written somewhere that packages name should be lowercase? Nov 29 10:13:22 aurele: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-storing-and-naming-the-recipe it says "use lower-case" Nov 29 10:13:59 nayfe, thanks for pointing this.. I will have to fix some packages name Nov 29 10:17:51 aurele: didn't know about too, just grepping lower in manual :) Nov 29 10:18:24 nayfe, I would have search after fixing this recipe Nov 29 10:18:42 nayfe, thanks a lot for your help Nov 29 10:18:54 np Nov 29 10:20:37 entre concurrents on peut bien s'aider :) Nov 29 10:21:15 concurent? Nov 29 10:56:32 Hi! I'm in the process of migrating from 'fido' to 'rocko' at the moment and I'am now faced with the problem that i can't build a gpl-3.0 free build anymore. Nov 29 10:56:33 the problem is that some packages require 'cpp-symlinks' which is a package that is provided by the gcc recipe (which is gpl-3.0). Nov 29 10:56:33 I found out that in 'fido' there are some packages whitelisted in the default-distrovars.inc which is no longer the case in 'rocko'. Nov 29 10:56:33 Has the way changed how to achieve a gpl-3.0 free build? I couldn't find anything about it in the migration instructions except for the gplv2-layer that i have included. Nov 29 11:01:36 is it known that rocko fails to build due to 'Deprecated variable(s) found: "IMAGE_DEPENDS_wic"' in various recipes? poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb poky/meta/recipes-core/ovmf/ovmf-shell-image.bb Nov 29 11:14:02 aj Nov 29 11:14:21 aurele: uppercase letters are not allowed (older releases may not sanity check this enough) Nov 29 11:14:46 (overrides are lowercase, so you can't have a _${PN} where PN containers uppercase) Nov 29 11:37:31 rburton, can you give me an example of override? you talk about writing PN="pkgname" in the recipe? Nov 29 11:37:56 see the docs, but an overide is when you do pkg_postinst_${PN}. the PN bit is the override Nov 29 11:38:06 the variable is pkg_postinst, but its specific to PN Nov 29 11:38:19 distinct from pkg_postinst_${PN}-dev, where the override is ${PN}-dev Nov 29 11:42:26 rburton, ok I understand now thanks for the tip Nov 29 12:48:16 I am trying to use a custom configuration for poky/meta/recipes-connectivity/openssh. To do this I am using a bbappend with FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" and my own sshd_config in the openssh folder, but it is still using the original one, why? Nov 29 12:55:01 wouterstreamit: is your bbappend path is correct and sshd_config? Nov 29 13:02:19 Yes. After inspecting with bitbake -e openssh I found that in the expansion of FILESPATH the original file was included before mine (probably because the ${PN} folder in the original bb directory is included in FILESPATH before FILESEXTRAPATH is added). As I only needed one small change I have solved it in a better way now using a sed -i command in a do_install_append function Nov 29 13:07:45 I would still like to learn how to work around the original problem though as I'd expect overriding a file included with file:// in the original recipe with one of your own should be a lot easier Nov 29 13:48:37 New news from stackoverflow: Yocto/OpenEmbedded Recipe Including library paths from host Nov 29 13:54:44 hahaha "I have the luxury of dealing with the endless error and warning paradise that is OpenEmbedded. " Nov 29 13:54:58 (from the above stackoverflow) Nov 29 13:57:31 lol Nov 29 13:57:58 clearly we need to comment on his indentation Nov 29 14:03:43 the poor chap is trying to build something which has bare makefiles Nov 29 14:03:57 crofton: i love stackoverflow, i give a hint to look at already made recipe here https://github.com/savoirfairelinux/meta-sfl and my answer get deleted because it's only a link :p Nov 29 14:07:37 yeah, they have rulez Nov 29 14:07:48 I'm reluctant to start answering things on SO, because it could be a horrible time sink Nov 29 14:08:02 I find it interesting seeing what crazy shit people do Nov 29 14:08:13 at least skim Nov 29 14:08:36 I ddi find one of anders answers and use it to help a customer Nov 29 14:08:49 so it has value when we feed it properly Nov 29 14:10:26 Crofton|work: this one however is just fixing someone's mutiply-broken recipe Nov 29 14:11:38 So things we can do is down vote the original question Nov 29 14:12:00 or try to explain why the recipe is downvoted Nov 29 14:12:24 really need someone who understands the stack overflow process to help us shape it Nov 29 14:12:33 but at least we are learning what is posted there Nov 29 14:14:24 I'd suggest the bot to auto reply a comment to join #yocto :) Nov 29 14:15:47 heh Nov 29 14:15:53 not sure we want that either Nov 29 14:16:08 or even 'worse': join the yocto mailing list Nov 29 14:16:21 will be flooded with n00bz Nov 29 14:19:23 kanavin: but that has its flipside: One assurance to the survival of communities like this is, well, recrutement by n00bz. I'm working on another project which does not have a large community and that is even harder to work on than a community (such as rasberry pi) overwhelming with noise (i.e. no00bs) Nov 29 14:23:22 sveinse: I'm well aware, I actually do think that the best response to the above question is to invite the person to the yocto ML Nov 29 14:23:34 where his recipe and the upstream project can be better dissected Nov 29 14:24:05 yes, I don't disagree to that Nov 29 14:24:26 in other cases, it's possible to answer directly, if the question/answer is common and useful to many Nov 29 14:26:21 From my two years with Yocto, I've learned that even thou the ruleset for the bitbake recipe language is pretty easy, getting all the tricks and rules of how oe builds an image is a long and steep learning process. Nov 29 14:28:31 I have colleagues (and myself) who have been utterly frustrated with Yocto at times. Perhaps this stackoverflow post is just that: venting of built up frustration. -- Though vile is usually not the best way to get help thou Nov 29 14:28:37 sveinse: yeah, people keep saying that yocto is too complicated, but to me that's about as meaningful as saying that 'linux kernel is too complicated' Nov 29 14:29:15 sveinse: there's also buildroot, you know :) if it suits someone's goals, then that's just fine! Nov 29 14:29:20 we need competition :) Nov 29 14:30:06 kanavin: yes, competition is good. Nov 29 14:30:35 And I hope this community is open for hearing pain points and user stories as well Nov 29 14:33:40 We're using Yocto to build the linux system on a commercial product (where the customer does not interact with Linux other than via the GUI) and we're not going back Nov 29 14:34:20 sveinse: I find it hilarious that https://buildroot.org/ uses the word 'easy' at least 10 times on the front page :) clearly they're trying hard not to mention YP :) Nov 29 14:34:22 Just upgraded from krogoth to pyro to now very soon rocko, and for the first time ever, these migration has been utterly smooth Nov 29 14:35:31 actually, exactly five times, but still - major selling point Nov 29 14:36:12 if it fits your use case. BR is fine (just like ptxdist, or whatever comparable) Nov 29 14:36:38 we switched from ptxdist to OE in the last couple of years, and there's certainly no going back for us too. Nov 29 14:37:41 i bought a iot camera thing this week, openwrt based Nov 29 14:37:44 I've been using a lot of buildsystems across the years. One of the most innovative details of OE is the sstate scheme. Nov 29 14:37:52 turns out on first boot you can telnet in as root without a password Nov 29 14:38:00 rburton: ip plz Nov 29 14:38:35 i've since discovered its first boot only as i moved the power socket and can't telnet in anymore, which is a shame Nov 29 14:38:36 perhaps that safe, rburton. Haven't telnet become exotic these days? Nov 29 14:44:55 I wish yocto would have a unified configuration management system on top of oe. I know it is deliberately not included in the project, but the consequence of it is that when you're moving from BSP to BSP or system to system, the vendor's scheme for CM changes wildly Nov 29 14:45:44 We've ended up with a separate build system on top of yocto to handle these variations Nov 29 14:46:02 sveinse: it's not that it's deliberate, it's that there's only 24 hours a day Nov 29 14:46:24 kanavin: yup, granted Nov 29 14:46:54 sveinse: if you polish, publish, and commit to taking care of your solution, then we'll be happy to take it Nov 29 14:48:33 kanavin: yeah, maybe I should. An oppertunity to perhaps help shape this. Let me wing this to my managers Nov 29 14:48:53 New news from stackoverflow: How can I build Yocto image to using build script? Nov 29 14:49:16 maybe pick one vendor solution with its permission is easier ? Nov 29 14:50:35 ooi, what do you use to collect/manage the layer repos? google's repo? Nov 29 14:52:04 sveinse: i'm using freescale env. with google repo (don't know if question was for me) Nov 29 14:53:00 okay, this last one is best solved with a yocto ml invite too - my best guess is he's trying to write a recipe around some cmake-based upstream project and is having trouble doing that Nov 29 14:53:20 there's no detail there, or even a question Nov 29 14:53:49 "it's too complicate" hum ... Nov 29 14:54:10 nayfe: thanks (no it wasn't) -- We're also using freescale in the base system Nov 29 14:54:28 :) Nov 29 14:56:05 nayfe: I'm fine with bad grammar if the person is willing to be an active partner in finding a solution, which in this case doesn't quite look like that Nov 29 14:58:45 kanavin: same :) i can't comment yet on SO i'll not risk to answer and get a minus Nov 29 15:05:43 well let's try Nov 29 15:08:15 you need to build reputation on stack overflow to be useful :) Nov 29 15:09:12 Crofton|work> trying hard but it seems i'm bad company Nov 29 15:10:05 nayfe: cue https://www.youtube.com/watch?v=Wp6UBRv9rug Nov 29 15:10:11 When was the multiple configuration support added to yocto? Nov 29 15:10:20 rocko or pyro? Nov 29 15:10:57 earlier. we're using it on morty Nov 29 15:11:23 ok, thanks Nov 29 15:12:15 lol Nov 29 15:12:21 no porblem takes time and patience Nov 29 15:13:05 nayfe: ++ Nov 29 15:15:19 nayfe: albeit 5FDP being a bit too depressing for me, i particularly like jekyll and hyde :-) Nov 29 15:55:56 wow, bitbake --parse-only when using multiconfig is *extremely* slow. Like 15 minutes or so for 3 configurations Nov 29 15:59:25 I've also found multiconfig to be extremely slow to parse and initialize tasks. it seems to take more than n times longer than non-multiconfig but I haven't timed it to confirm Nov 29 16:00:29 sveinse: yikes Nov 29 16:00:51 ram usage issue? pushing into swap due to the memory usage of the parsing threads? Nov 29 16:00:54 * kergoth shrugs Nov 29 16:03:06 kergoth: no, doesn't look like it. I have plenty phy ram left Nov 29 16:03:58 kergoth: now it is stuck at parsing recipes: 0%. One Cooker process eating 100% CPU. The rest is idle Nov 29 16:04:58 odd Nov 29 16:09:20 At this point, I'm not really sure it saves times to use multiconfig vs running bitbake three times with different MACHINE settings. I have to benchmark it Nov 29 16:10:12 The beauty of multiconfig is that you get one progress to relate to, not three in a row Nov 29 16:10:17 agreed, i think the main advantage is being able to store the multiconfigs in source control in a declarative fashion rather than hacking on a shell script, for your automated builds Nov 29 16:10:20 that's a fair point Nov 29 16:13:06 kergoth: are you the maintainer for the multiconfig? Nov 29 16:13:41 nope. one of the folks with bitbake expertise, but only just starting to poke at multiconfig recently Nov 29 16:13:48 ok Nov 29 16:13:52 RP is the maintainer of it Nov 29 16:15:35 andycooper, sveinse: definitely worth filing a bug if you can make a minimal reproducer against oe-core. probably a bad algorithm doing far too much work. Nov 29 16:16:03 rburton: yes, I'll see if I can boil this down Nov 29 16:16:58 What is good generic MACHINE to use that does not rely on specific BSP or hardware? Nov 29 16:19:10 New news from stackoverflow: aarch64-poky-linux-gcc: error: : No such file or directory Nov 29 16:19:30 sveinse: qemu*? Nov 29 16:19:49 rburton: ok, thanks. I'll try to use them for my example Nov 29 16:26:41 hi guys, following https://stackoverflow.com/questions/36318491/how-to-build-qt-with-qtwebengine-support-using-meta-toolchain-qt5 I've added (above others) qtwebengine-plugins to my sdk (I'm on morty) and all goes fine. After a while I move to another machine with the same yocto configuration, pulled my layer (upstream commits consist mainly of the qtwebengine stuff added to the sdk), and rebuild the sdk. Surprisingly Nov 29 16:26:43 the do_populate_sdk task failed complaining about the missing qtwebengine-plugins package Nov 29 16:27:57 using oe-pkgdata-util list-pkgs | grep qtwebengine Nov 29 16:29:47 in the machine where the populate_sdk task failed, the qtwebengine-plugins is missed from grepped list Nov 29 16:30:07 sveinse: parsing shouldn't hang like that :( Nov 29 16:30:45 sveinse: multiconfig has pros and cons. I'm pleased we have it but I think it highlights there are some performance issues we need to look at if we want to scale builds like that Nov 29 16:31:51 RP: Yeah, I'll see if I can look into and see what I can help with Nov 29 16:32:29 while on the other machine it was not. Using devshell on qtwebengine package, I see that on the machine where the task failed the package-split/qtwebengine-plugins directory is empty. Any clues about that? thanks in advance Nov 29 16:33:56 armpit: your glibc CVE patches don't apply to khem's glibc upgrade (see ross/mut2), can you see if they've been upstreamed and/or rebase? Nov 29 16:35:48 rburton, I suspected that might happen. the fun part is going to ID what glib version.. Master and Rocko are on the same version but different source bases Nov 29 16:36:16 fun! Nov 29 16:36:25 hehe Nov 29 16:36:39 can we bump the PR for the master version? Nov 29 16:36:56 .1 or something. its going to confuse folks Nov 29 16:37:31 until 2.27 is adopted Nov 29 16:38:37 do you recall if the hash is part of the PV ? Nov 29 16:40:26 rburton, if I recall the commits are after the point Khem is referencing. Nov 29 16:40:38 ok. they don't apply to the source then Nov 29 16:40:47 patching file posix/glob.c Nov 29 16:40:47 Hunk #1 FAILED at 843. Nov 29 16:41:21 I will have to respin against mut2. Nov 29 16:41:44 just pushed a minor update to it Nov 29 16:41:48 Hello, I'm using the morty version of yocto and I'm trying to build an image for an x64 hardware on a x64 host (I'm using archlinux on the host computer). The build fails when installing glibc. Do you have any idea what could be wrong ? Nov 29 16:41:55 armpit: trying to consolidate all the toolchain changes so they all land at once Nov 29 16:42:13 It says something about registers not being defined (sorry, I don't have the logs right now) Nov 29 16:42:24 top22: its probaby that the fooflip has dangled on the left flangee. seriously, logs are essential. Nov 29 16:42:58 entirely possible that the problem is your arch has a compiler too new to build glibc from morty Nov 29 16:43:38 you can try using our buildtools tarball to use a supported compiler instead of your host Nov 29 16:44:17 rburton: :D I will provide the logs as soon as I get them, probably tomorrow; thanks for the hints, I will try them Nov 29 16:47:38 rburton, how soon where you trying to do that? Nov 29 16:48:00 * armpit is seeking away from work to eat German food and beer Nov 29 16:51:48 armpit: not right now, maybe monday? Nov 29 16:52:21 k. that gives me time. Nov 29 17:34:46 some nice people just sent me a proposed patch for the sticky bit getting lost, it looks reasonable to me. I'm still pondering whether there's a way to make it better, but I don't immediately see one. They'll likely send it to oe-core. Nov 29 17:35:00 (And I *still* don't have a clear ETA on "some free time to merge changes and fix a couple of things".) Nov 29 17:44:08 new to yocto. building a lib. do_compile worked. i can see all the files compiled. but i'm having issues with do_install. the error i'm getting is QA: Issue: -dev package contains non-symlink .so: mylib-dev path: /mylib.so. Did a lot of searching online but didn't find an answer. What is the problem? (obviously it is the .so file). How do I fix it? Nov 29 18:12:27 new to yocto. trying to build a library, but running into issues. getting an error, -dev package contains non-symlink .so: mylib-dev path: /mylib.so. searched online but didn't find an answer on how to fix it. can someone help me out? Nov 29 18:26:06 flashburn: you aren't setting the SONAME correctly to version the library. the convention is libfoo.so.1.2 which is symlinked to libfoo.so.1 (which is its soname), andt here's a libfoo.so symlink used to link when developing. which is why libfoo.so ends up in the -dev package. Nov 29 18:38:22 kergoth: thanks for the reply. given that i have never done this before, i feel like i'm missing a big chunk of information. when my library was built (i used a makefile that was given to me), I got the following output: libmylib.so.1.0.1 (actual file), libmylib.so -> libmylib.so.1.0.1 (link to the library) and libmylib.so.1 -> libmylib.so.1.0.1 (another link). I'm not quite sure what value to use for SONAME. would you mind helping out? Nov 29 18:47:01 if you're getting that error indicating the .so isn't a symlink, then clearly it's not a symlink. if it was after the make, but isn't after the make install, then you'll need to fix the makefile to install them properly without resolving the symlink Nov 29 18:49:41 New news from stackoverflow: Upgrade to yocto 2.4 vmdk is no longer a image type Nov 29 18:51:32 kergoth: I see. thanks. Nov 29 19:17:09 new to yocto. reading through http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-insane, about libdir. confused if it is a variable since is it used as ${libdir} or it is a name of a check used by QA. can someone help me out? Nov 29 19:26:02 flashburn: you can perhaps clear up the confusion by reading insane.bbclass itself? Nov 29 19:36:57 flashburn: the answer is yes. Nov 29 19:49:54 kergoth: do you mean it is both, a check and a variable? Nov 29 19:50:02 yes Nov 29 20:24:09 armpit: ping? Nov 29 20:24:59 are you using master-next for aggregating patches or something else for meta-openembedded Nov 29 20:25:43 armpit: usually, I test mastet-next which Martin was using for aggregation Nov 29 20:25:52 and will run bunch of builds myself Nov 29 20:26:19 its fine if you are using some other repo or branch I just need to know Nov 29 21:20:06 New news from stackoverflow: Unique ID of embedded system running Yocto Nov 29 21:23:08 seriously yocti, i need better questions! :D Nov 29 21:47:15 What would be a use case for the publish option when extracting the esdk? Nov 29 21:49:02 batman_: on the command line? it's internal, it's used by the oe-publish-sdk script which sets up the files for the server side for updating from the client Nov 29 21:53:52 bluelightning: yes, on the command line. I see that running the esdk script with -p will not do a bitbake build and produce tmp directory. If I look at the env setup script, $CC is set to gcc inside tmp directory. Nov 29 21:54:35 So I am not getting why we have a publish option and when should I use it? Nov 29 21:57:08 hmm, i'm trying to use the samba recipe in meta-networking, and for some reason the autostart configuration isn't created (using sysv) Nov 29 21:57:57 the recipe inherits update-rc.d and sets the initscript_name and initscript_params, but when i start the created image no links to samba.sh are in any rc*.d folder Nov 29 21:58:48 batman_: you would not use that option directly, the oe-publish-sdk script uses it so that it can get just the files in the archive extracted which is what is needed for update purposes Nov 29 22:02:56 bluelightning: Ah! ok. thanks! Nov 29 22:19:34 getting the error: on-symlink .so: mylib-dev path: /package-split/mylib-dev/usr/lib/mylib.so. Original suggestion was to fix the Makefile that generates the library to point to have correct SONAME. It was done and I verified it. Unfortunately the problem still persists. Did more digging and found out that it is happening during a do_package task. did more googling but didn't find out how to fix the problem. PS. I'm still learning Nov 29 22:19:34 Yocto. Nov 29 23:38:47 I'm running into an issue of a native dependency not being accessible to other recipes, how do I go about troubleshooting? Nov 29 23:39:46 this is in reference to protobuf recipe that has protobuf-compiler as a seperated package Nov 29 23:40:47 i've tried adding "protobuf", "protobuf-compiler", "protobuf-native", "protobuf-compiler-native" to DEPENDS in the recipe that is attempting to use 'protoc' but it keeps stating command not found Nov 29 23:42:10 if it needs to *run* a binary, then you have to depend on the -native recipe that builds that binary Nov 29 23:42:41 I have checked the build artifact directory for protobuf and i can see protoc in image/usr/bin and package/usr/bin and packages-split/protobuf-compiler/usr/bin Nov 29 23:45:26 from reading the mega-manual i thought I should be seeing a 'protobuf_someversion.bb" in addition to 'native-protobuf_someversion.bb" Nov 29 23:47:08 sum1: You'll have to differentiate recipe and package namespace. For example, protobuf-compiler is a package generated by the protobuf recipe. Packages will never show up in DEPENDS, only recipes will. Nov 29 23:48:03 sum1: Second, while you're correct in expecting native-protobuf_version.bb, bitbake allows you to emulate that separate recipe in most cases with some syntactic sugar by setting BBCLASSEXTEND = "native nativesdk" Nov 29 23:48:22 That's the case for the protobuf recipe, which is why you don't see a separate native-protobuf_verison.bb. Nov 29 23:48:27 okay but if i place the recipe name in DEPENDS the same issue happens. Nov 29 23:48:55 Adding DEPENDS = "protobuf-native" will at least provide the correct protoc. The question is whether the build system of whatever software you are building correctly finds that protoc binary. Nov 29 23:49:23 hmm k, i guess I'll have to go digging why this isn't working the way i thought Nov 29 23:49:42 because I assumed using DEPENDS="protobuf-native" was enough but it didn't work Nov 29 23:50:03 well, you'll also need protobuf itself in DEPENDS, because you're likely linking against protobuf libraries Nov 29 23:50:17 So if you don't have both, make sure to change that. Nov 29 23:50:29 and i'm new to yocto so i thought maybe my understanding was wrong Nov 29 23:51:00 i'm pretty sure i had every variation in at the same while trying to troubleshoot last night Nov 29 23:51:11 but i will attempt it again with protobuf&protobuf-native Nov 29 23:51:32 s/same/same time/ Nov 29 23:53:50 is there a default location that native packages are "installed" into to be usable by other recipes? or is $PATH just modified? Nov 29 23:54:19 They're on $PATH Nov 29 23:54:57 But there also is a location, you'll find a variable for it in poky/meta/conf/bitbake.conf (but I don't remember its name from the top of my head now) Nov 29 23:56:21 If you're using CMake for your software, check the value for CMAKE_FIND_ROOT_PATH_MODE_PROGRAM; you may have to set it to BOTH (although I think that's the default) Nov 29 23:59:10 hmm k, that should give me a starting point to figure it out Nov 29 23:59:13 thanks for your help Nov 30 00:04:00 yw Nov 30 00:10:32 How does one conditionally addtask or run a specific task based on the BBCLASS? E.g. I would like to run some task for cross-compile target but not for native. Nov 30 00:34:36 mtahmed: one way would be to make the task function only defined for the class you want it to run in, then have a default version which is a no-op Nov 30 00:35:15 i.e. do_something_class-native() { ... } do_something() { : } Nov 30 00:35:18 @bluelightnight Ohhh I see. add_task_class-native? Nov 30 00:35:21 Ahh I see! Nov 30 00:35:25 Thank you! Nov 30 00:35:49 alternatively you could do the addtask in anonymous python and make it fully conditional, but the first method is easier Nov 30 00:36:19 sorry, I should have said class-target there not class-native Nov 30 00:50:45 New news from stackoverflow: Unique ID of an embedded system running Yocto **** ENDING LOGGING AT Thu Nov 30 03:00:02 2017