**** BEGIN LOGGING AT Thu Apr 06 03:00:03 2017 Apr 06 07:28:31 otavio : Hi, i've sent you a message in PVT. Thanks. Apr 06 07:50:21 Hi ! I made a layer with one recipe and I set DEPENDS += "unzip" in my recipe. But when I execute bitbake core-image-minimal, I have one error which says : unzip not found. But I have unzip working on my machine, and this dependency works in others layers. Why is it not working in mine ? Any idea please ? Apr 06 07:53:06 yohboy: please pastebin the error with enough context Apr 06 07:54:07 I'm new also in yocto but I guess yohboy, your recipes should provides unzip. It don't care of what you can have on your computer, am I right ? Apr 06 07:57:26 jku: the error is much bigger, with a lot of debug/note Apr 06 07:57:34 the main error says : ERROR: zybo-gateway-linux-1.0-r0 do_install: Function failed: do_install (log file is located at /home/yohan/Smart_gateway/Linux_yocto/build/tmp/work/zybo_gateway-poky-linux-gnueabi/zybo-gateway-linux/1.0-r0/temp/log.do_install.4844) Apr 06 07:57:55 with debug line important I think : /home/yohan/Smart_gateway/Linux_yocto/build/tmp/work/zybo_gateway-poky-linux-gnueabi/zybo-gateway-linux/1.0-r0/temp/run.do_install.4844: unzip: not found Apr 06 07:58:23 yohboy : does unzip is provided by the recipes on your build project ? Apr 06 08:00:10 Chrys: I was thinking my recipe uses unzip to make the do_install Apr 06 08:01:11 yohboy: if it does then you would need unzip-native, not unzip Apr 06 08:01:20 yohboy: try to be exact. show the recipe, or precisely tell us what you want to do. because it seems you are missing up the environments. Apr 06 08:01:31 yohboy: (like jku just said, in short) Apr 06 08:02:36 ok, let me explain better so Apr 06 08:03:02 thinking about it, depends unzip hardly makes sense. it usually is either unzip-native or rdepends ;-) Apr 06 08:03:12 yep Apr 06 08:04:36 So i'm working also with meta-xilinx layers. I took example on a recipe from meta-xilinx, and try to make my own. The recipe take a zip file and need to unzip it to extract some usefull file, and deploy them Apr 06 08:05:02 The recipe is very very similar to the one from meta-xilinx Apr 06 08:05:13 but when I put this recipe in my layer Apr 06 08:05:23 it can't find the depencies Apr 06 08:05:42 yohboy : Maybe you should see documentation of what DEPENDS is. RDEPENDS = Dependencies in runtime while DEPENDS is more when a "recipe" need for " do_configure" another recipes which have already done "do_populate_sysroot" Apr 06 08:05:51 yohboy: see above then. Apr 06 08:05:53 LetoThe2nd : I'm I right ? Apr 06 08:06:05 Chrys: close. Apr 06 08:06:45 I will test it yes, but weird because the recipe from meta-xilinx works and uses DEPEND += "unzip" Apr 06 08:07:00 all the do_* steps are executed during compile time, not during run time. they are executed on the host, not an the target. hence if you need something there that is not included in the standard toolchain, then you have to add it as a -native dependency Apr 06 08:07:11 yohboy: well we don't know what else you messed up :-P Apr 06 08:07:28 yohboy : It's not because nutella work in a bread that nutella should work also in a shoe ! Apr 06 08:07:38 sure :p Apr 06 08:07:43 :p Apr 06 08:08:03 I'll test your solution and get back thanks Apr 06 08:08:25 Chrys: nope. its more like: does recipe tell you that you need to put nutella in what you cook, or do you need to put nutella into the chef in order to make him work properly. Apr 06 08:09:01 LetoThe2nd : You didn't get what I wanted to mean I guess ahah Apr 06 08:09:54 LetoThe2nd : It's not because a line in a file worked for a meta, that this same line should work in another meta. Apr 06 08:10:12 Chrys: nope. thats a completely wrong way to put it. Apr 06 08:11:07 seems to be worst with RDEPENDS Apr 06 08:11:11 QA Issue: /home/yohan/Smart_gateway/Linux_yocto/layers/meta-zybo-gateway/recipes-bsp/reference-design/zybo-gateway-linux.bb: Variable RDEPENDS is set as not being package specific, please fix this. [pkgvarcheck] Apr 06 08:11:14 LetoThe2nd : What you said is more like to explain differences between RDEPENDS and DEPEND =D Apr 06 08:11:24 yohboy: because you didn't listen. Apr 06 08:11:36 Chrys: exactly. and thats exactly his problem. Apr 06 08:11:49 It seems I miss something yes Apr 06 08:12:07 LetoThe2nd : Yeah but i was speaking because he said : weird because the recipe from meta-xilinx works and uses DEPEND += "unzip" Apr 06 08:12:12 yohboy: so please let me repeat: 10:07 < LetoThe2nd> all the do_* steps are executed during compile time, not during run time. they are executed on the host, not an the target. hence if you need something there that is not included in the standard toolchain, then you have to add it as a -native dependency Apr 06 08:12:56 Chrys: who says that the recipe that he claims to cite is even remotely comparable? that the line is not completely ripped out of context? Apr 06 08:13:17 LetoThe2nd : It doesn't matter now ahah. Apr 06 08:13:40 Chrys: its like saying: "I++;" works perfectly fine on this one project, it has to work EVERYWHERE hence Apr 06 08:14:06 lines of code are always subject to context. Apr 06 08:14:17 LetoThe2nd : That's why I said that. Apr 06 08:14:38 all is fine then. Apr 06 08:15:17 LetoThe2nd : Maybe my english isn't good enough but it was the meaning I wanted to say. Apr 06 08:16:40 it seems to work with -native, thank you Apr 06 08:29:06 hi folks Apr 06 08:29:09 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc#n6 Apr 06 08:29:23 why is it marked as commercial Apr 06 08:29:25 ? Apr 06 08:29:38 hah Apr 06 08:29:39 :D Apr 06 08:29:52 The current assumption is because it depends on bellagio Apr 06 08:30:08 Stumbled upon that last week. Apr 06 08:33:54 phako[m]: thanks but that's an assumption only, right? Apr 06 08:34:33 more or less Apr 06 08:35:00 I am going to make a image post-processor (a installer generator) and I need it to access the rootfs images for a set of machines. Can I from my own recipe access the image rootfs files (e.g. tmp/work/${MACHINE}/sp-core-image/1.0-r0/rootfs/) as root via pseudo/fakeroot, or do I have to use the .tar.bz2 files in deploy/ for that? Apr 06 08:36:07 phako[m]: then shouldn't the libomxil recipe be marked this way rather than gstreamer-omx? Apr 06 08:36:39 t is. Apr 06 08:36:44 it ts. Apr 06 08:36:50 oh damn Apr 06 08:36:51 it is. Apr 06 08:37:28 but since gstreamer-omx is pretty useless without it if you don't have a vendor il. But that's just my guesswork Apr 06 08:37:53 phako[m]: :) hmmm odd only libomxil should be marked that way in this case Apr 06 08:38:09 and are we sure libomxil is commercial? Apr 06 08:38:32 sveinse: you could add your own task to the images? Apr 06 08:40:08 abelal: it uses ffmpeg to implement all kind of license-encumbered codecs... Apr 06 08:40:40 RP: Its slightly more complicated that that: The installer shall combine the rootfs images from multiple MACHINEs into one, and our current Yocto (krogoth) don't support building multiple machines in one invocation, so it have to be a separate recipe that must be run last Apr 06 08:41:20 phako[m]: but the recipe does not depend on ffmpeg... :s Apr 06 08:41:37 sveinse: keep in mind we don't support cross workdir directory accesses Apr 06 08:41:54 sveinse: also, each workdir has its own pseudo context which is going to complicate things for you Apr 06 08:42:38 RP: I'm not crossing workdirs, they are all run in the same dir. Just three invocation of varying MACHINE. They are very similar, as they all have the same arch and tune Apr 06 08:43:08 sveinse: you build all three images in the same WORKDIR? Apr 06 08:43:14 yes Apr 06 08:43:18 (for each of the three machines) Apr 06 08:43:42 since even the path you posted earlier is tmp/work/${MACHINE}/sp-core-image, I very much doubt that Apr 06 08:43:55 that path is machine specific Apr 06 08:44:08 yes, I run MACHINE=a bitbake sp-core-image; MACHINE=b bitbake sp-core-imaage Apr 06 08:44:31 abelal: hm, true Apr 06 08:44:32 I'll reuse most packages, as they are built for tune, while the bsp-stuff is individual Apr 06 08:44:42 sveinse: and end up with three *different* directories each containing a rootfs. Each of those directories will have a WORKDIR/pseudo database for that directory Apr 06 08:44:50 ok Apr 06 08:45:18 yohboy: I've queued up a patch to fix it to use unzip-native in meta-xilinx aswell Apr 06 08:45:22 pseudo only works with one database so you can't load each of these images into the same context easily Apr 06 08:45:34 abelal: so, no idea then Apr 06 08:45:52 sveinse: even if you don't understand what I'm saying, trust me that tarballs are going to work better for you Apr 06 08:45:52 phako[m]: thanks a lot for your time :) Apr 06 08:46:53 nrossi: ok nice :) Apr 06 08:47:20 RP: yeah, I see there are multiple pseudo dbs in my build. I had hoped I could spare an extra untar-tar operation, but I'll use the tarballs. Thanks Apr 06 08:56:56 BTW, the operations of bundling multiple images into one artefacts can't be that exotic, but I'm sensing that we're constantly hitting on the boundaries of what Yocto can do. The use case for this is that we have a common updater that the end customer uses to upgrade the products and it must contain all images. Other companies must have similar use cases, yes? Apr 06 08:57:49 sveinse: its just a scenario that is rather new and not poured into a common procedure so far. Apr 06 08:58:02 basically, chain-building Apr 06 08:58:52 LetoThe2nd: right. yes, and we're not using that right now, because we're on krogoth. Looking forward to it Apr 06 09:00:04 sveinse: right, multiconfig was new in morty and is on the edge of development... Apr 06 09:00:24 sveinse: updaters isn't a solved problem at the moment, lots of different requirements Apr 06 09:00:31 I guess what I'm saying, it that in the long run, there should be support for manipulating multiple images. I assume it will come :D Apr 06 09:02:02 abelal: according to gstreamer ppl, bellagio isn't really useful anymore Apr 06 09:04:53 RP: Agreed. And I'm not sure Yocto should set out to make updaters. In a commercial setting, you probably need some corporate encapsulation anyways. Just the means to build them. Apr 06 09:05:15 And I'm confident that the means are there and that I'll get my recipe to work. Let's see Apr 06 09:07:31 sveinse: certainly you can use the tarballs and if you extract them within the same pseudo context you should be able to do what you need Apr 06 09:19:48 mappy : regarde en haut et clique sur chrys Apr 06 09:50:34 I'm doing my first recipes, and this recipes is for a first kernel module also. I took an exemple from the poky dist, but I would like to know how bitbake know what he have to do with the .c file and Makefile Apr 06 09:50:40 Does it's because of " inherit modules" ? Apr 06 09:53:29 and also, for meta-fsl-arm, I have this error :QA Issue: imx-vpu: LIC_FILES_CHKSUM points to an invalid file: /opt/PHYTEC_BSPs/phyBOARD-MIRA/build/tmp/work/phyboard_mira_imx6_4-phytec-linux-gnueabi/imx-vpu/1_5.4.33-r0/imx-vpu-5.4.33/COPYING Apr 06 09:53:35 What should I do. Apr 06 09:53:51 Thanks ! Apr 06 09:56:14 Chrys: 1) look at the recipe and find out where it is pointing 2) look at the sources and check what is actually there Apr 06 09:58:50 LetoThe2nd : When you have LIC_FILES_CHKSUM = " file://COPYING....blablabla " where should the COPYING be located ? Apr 06 09:59:37 Chrys: there where the sources are unpacked. seems to be /opt/PHYTEC_BSPs/phyBOARD-MIRA/build/tmp/work/phyboard_mira_imx6_4-phytec-linux-gnueabi/imx-vpu/1_5.4.33-r0/imx-vpu-5.4.33 in your case Apr 06 09:59:49 (and why are you building in /opt?) Apr 06 10:00:58 LetoThe2nd : Because commercial software i guess Apr 06 10:01:22 LetoThe2nd : Thec ompany who made it have done a script with prepare the yocto directory and go in /opt Apr 06 10:02:11 Chrys: then my first suggestion would be to get rid of that script and properly set up your layers yourself. Apr 06 10:02:43 Chrys: its also a strong suspect for the missing git revision and priority issues yesterday. Apr 06 10:03:24 LetoThe2nd : I don't think so, I download with git clone and I didn't get problem. I've maybe downloaded it directly from the website and copy the folder there. That's why I ugess. Apr 06 10:03:53 Chrys: well then. Apr 06 10:06:32 LetoThe2nd : and why not in /opt ? Because of permission right ? Apr 06 10:07:40 Chrys: counter question. users are meant to keep all their stuff in their home on unixoid platforms. why move to /opt? is there any benefit? Apr 06 10:08:22 Chrys: (read that as: why should i find reasons to justify adhering to common best practises, instead of you for violating them) Apr 06 10:08:51 LetoThe2nd : But if you consider that the work isn't user specific but computer specific and that the work is considered as commercial purpose, why not ? Apr 06 10:09:28 Chrys: if it is not user specific how do you deal with file ownership clashes if multiple users work on it? Apr 06 10:10:07 Chrys: and i really do not see how this relates to comemrcial or not. Apr 06 10:11:47 other than the total contrast. in a commercial environment, any sane admin will take care to backeup /home. about none will care about /opt, as users are not meant to tinker with that. Apr 06 10:12:53 LetoThe2nd : As i'm not in my own computer but in a computer dedictated 100% for that yocto project they put on opt Apr 06 10:13:19 it still makes no sense. Apr 06 10:13:22 LetoThe2nd : As atmel do the same Apr 06 10:13:30 it doesn't make sense for them too. Apr 06 10:13:51 tell me one(!) advantage of putting stuff into /opt. Apr 06 10:23:44 Hey there, I'm facing a RAMDISK error while building yocto custom image, the error is the next one Apr 06 10:23:46 RAMDISK: Couldn't find valid RAM disk image starting at 0. Apr 06 10:23:54 the error trace is here Apr 06 10:24:01 https://pastebin.com/E5E0QghE Apr 06 10:25:38 I have tried to change the kernel conf with menuconfig Apr 06 10:26:42 at General Setup -> Initramfs source files Apr 06 10:27:01 and adding there a value, but If i do that, does not compile Apr 06 10:27:45 printing a error: "gen_initramfs_list.sh: Cannot open 'b300'" Apr 06 10:28:00 So I'm not sure how to proceed Apr 06 10:28:09 thanks for the help Apr 06 11:00:55 ignatius, obvious problem: Kernel command line: Apr 06 11:02:03 ant_work: where can I find it at menuconfig? Apr 06 11:05:46 it is normnally set in the recipe Apr 06 11:07:46 Hi there, I don't want to use any system service manager neither systemd nor sysvinit, when I add line to my conf/local.conf DISTRO_FEATURES_remove = " systemd" I got this error: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (systemd) matches the entries enabled in DISTRO_FEATURES Apr 06 11:14:10 rubiccube: so like busybox init? Apr 06 11:15:39 LetoThe2nd: No, I will just boot the kernel Apr 06 11:15:59 rubiccube: ok, and what is it supposed to do after booting? Apr 06 11:17:02 rubiccube: I think the kernel needs to start "an" init ... might be just /bin/bash but still ... something needs to start Apr 06 11:17:37 mdnneo: if it never ever gets there, no Apr 06 11:17:53 mdnneo: yes I have modified the kernel line that runs my qt application like, init=/bin/myQtApplication Apr 06 11:17:59 rubiccube: have you tired setting VIRTUAL-RUNTIME_init_manager to some other value? Apr 06 11:18:29 LetoThe2nd: Can I do it like VIRTUAL-RUNTIME_init_manager=None ? Apr 06 11:18:30 I thought it expects some ... just like if you would kill init the kernel stops Apr 06 11:18:43 rubiccube: probably not None, but = "" Apr 06 11:19:33 mdnneo: technically you certainly could patch the kernel so that it just sits there and waits, never ever going into userspace. Apr 06 11:23:16 rubiccube, we do that in an initramfs, init is our binary and we only rely on devtmpfs Apr 06 11:23:34 EXTRA_IMAGEDEPENDS = "" IMAGE_FEATURES = "" Apr 06 11:23:44 but you must know what you're doing... Apr 06 11:24:10 ant_work: yeah, and especially anything Qt sounds... problematic :-P Apr 06 11:24:37 * ant_work still has to fix QT3 / opie touchscreen calibration, darn Apr 06 11:25:31 LetoThe2nd: when I append init=/bin/myQtApplication my application comes after the kernel boot. Is there any problem with that ? Apr 06 11:26:08 ehm.. what do you mean? Apr 06 11:26:29 rubiccube: not necessarily, if your application works. there just is not much it can depend on, then. Apr 06 11:26:38 it comes ofc after kernel boot Apr 06 11:27:03 ant_work: but i want it to come *before* kernel boot *nagnagnag* Apr 06 12:05:56 I want to add files after rootfs is generated, how to extend core-image-minimal for that Apr 06 12:09:16 mjaggi1: any specific reason why a standard recipe wouldn't do the trick and put the files in there that you need? Apr 06 12:11:06 I am working on mutlitib for aarch64 aarch64_ilp32 , Apr 06 12:12:02 bitbake generates two directories and keeps ld in lib and libilp32 directories Apr 06 12:12:28 for aarch64, both needs to be in same directory Apr 06 12:13:07 Till I find a way to do that, I am trying to create a link from lib to libilp32 Apr 06 12:13:39 is it possible to do in say do_deploy_append of core-image-minimal Apr 06 12:13:52 I am not sure how to do that Apr 06 12:14:51 what comes to my mind is either http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132815.html Apr 06 12:15:00 or adding a postprocess command. Apr 06 12:17:32 lib is populated I believe by populate_sysroot, can we do something like populate_sysroot_append Apr 06 12:20:02 i'm sure there are many ways, but the question is where to put it. either hack some internal function, or keep it external and reproductible. Apr 06 12:20:22 i personally would derive my own image class and do rootfs postprocessing there. Apr 06 12:21:09 thats a good idea Apr 06 12:22:18 if I have my-meta-layer/recipes-core/images/core-image-minimal.bbappend Apr 06 12:22:34 should I add do_rootfs_append Apr 06 12:22:37 would it work Apr 06 12:22:59 i'm not completely sure about the syntax. did you check the dev manual? Apr 06 12:30:31 do_rootfs is a python function so cant be appended Apr 06 12:40:57 Hello ! I'm trying to create a layer for a new board. Someone already did it with a previous version of yocto and a 3.14 kernel, I'm trying with Morty and a 4.1 kernel. I managed to compile the image, but whenever I try to boot, I only get a few lines from the serial port, then it just stops. Do you have any idea what is going on, and how I could g Apr 06 12:40:57 enerate logs or anything ? See https://pastebin.com/G4REDmAs Apr 06 12:44:00 nvld: looks like simply your dtb is broken/unfitting. Apr 06 12:49:47 The dtb is the exact same as the dtb we use with the 3.14 kernel. Should it be different ? Apr 06 12:50:47 nvld: yep. Apr 06 12:51:12 Oh. Apr 06 12:51:21 nvld: dtbs have not really been known for a stable binary api. at least not for non-mainlined things. Apr 06 12:52:20 Well, thank you :) Apr 06 12:54:28 good luck Apr 06 12:56:44 Thank's ! I think I'll need it ^^ Apr 06 13:27:09 I'm having problems compiling some Qt5 code outside yocto, but it works inside yocto (this way for once). It turns out yocto sets OE_QMAKE_STRIP=echo. Does this imply that yocto built apps never needs stripping? Apr 06 13:27:24 I.e. is yocto doing its own stripping as a part of the packaging? Apr 06 13:27:33 sveinse, they extarct the debug info, then strip Apr 06 13:27:41 exactly Apr 06 13:28:07 Right, thanks. Then it makes sense to bypass the Qt-world stripping Apr 06 13:28:12 right Apr 06 13:46:23 Hello, I have a CMAKELists.txt file which searches for packages, which I don't need for cross compile. I was thinking about an patch for the file to remove this package. But i didnt't found any documentation how I have to write a patch? Apr 06 13:47:26 For this patch I have to search all CMAKEfiles for a string and remove this string Apr 06 14:01:57 Hello, I have a CMAKELists.txt file which searches for packages, which I don't need for cross compile. I was thinking about an patch for the file to remove this package. But i didnt't found any documentation how I have to write a patch? Apr 06 15:02:04 hello everyone Apr 06 15:03:00 hello Apr 06 15:03:28 i have a problem with eclipse yocto plugin Apr 06 15:04:10 i followed this documents to develop application based eclipse Apr 06 15:04:11 https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage Apr 06 15:04:30 And: http://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-manual-intro Apr 06 15:05:05 I created and build my first application: hello world Apr 06 15:05:28 build successfully but Apr 06 15:05:52 in my source code Apr 06 15:05:57 #include Apr 06 15:05:58 #include Apr 06 15:06:47 stdlib.h and stdio.h, eclipse used to build my application from native directory: /usr/include Apr 06 15:07:03 because i am cross-compile Apr 06 15:07:48 i think eclipse must get two these files from [SYSTEM_ROOT]/usr/include Apr 06 15:08:04 i don't understand why? Apr 06 15:09:32 i am cross-compiling for target, not compile for host Apr 06 15:10:27 please show me why so Apr 06 15:24:33 ed2: I commented on that bug Apr 06 15:25:30 rocket42: gcc is probably invoked as arm-xxxx-gcc --sysroot=[path to sdk sysroot] Apr 06 15:25:55 rocket42: it will prefix search paths with the sysroot Apr 06 15:27:05 I know, but this is what in terminal: arm-poky-linux-gnueabi-gcc -march=armv5e -marm --sysroot=/home/hung/poky/2.2.1/sysroots/armv5e-poky-linux-gnueabi -DHAVE_CONFIG_H -I. -I.. --sysroot=/home/hung/core-mage-sato-sdk-qemuarm-rootfs Apr 06 15:27:38 path to sdk is home/hung/poky/2.2.1/sysroots/armv5e-poky-linux-gnueabi Apr 06 15:28:07 so i think that eclipse must get file from home/hung/poky/2.2.1/sysroots/armv5e-poky-linux-gnueabi/usr/include Apr 06 15:28:37 but actually it get from /usr/include Apr 06 15:41:38 I want to create an ext image in order to be mounted to have only kernel-modules inside. So only /lib/modules/... . Apr 06 15:41:46 I made a recipe, inherited core-image and set IMAGE_INSTALL = "kernel-modules" and PACKAGE_INSTALL = "${IMAGE_INSTALL}". Apr 06 15:42:04 But at final image I have also /boot with uImage and kernel along with /etc /usr /var with some minor staff inside. Apr 06 15:42:16 How can I remove everything else? Apr 06 15:43:40 you'd have to change the rdepends of the krne lmodule packages, which would affect all images, not just that one Apr 06 15:47:36 kergoth: ok I think I got it. This is only about the kernel part. Apr 06 15:48:10 kergoth: How I would delete all other folders? run for example is empty Apr 06 16:15:03 denix: is the upcoming processor sdk release (the 2017.00 tag presumably) going to be pyro or morty based? Apr 06 16:50:22 kergoth: 2017.00 tag is already applied to morty Apr 06 16:50:38 ah Apr 06 16:50:39 thanks Apr 06 16:52:18 kergoth: so, 2017.xx and processor sdk 4.x will be morty Apr 06 16:53:23 kergoth: I'll track pyro and master on my own, but official releases will stay on morty for now Apr 06 16:53:32 okay, cool, thanks Apr 06 16:53:41 thought that was the case, just wanted toc onfirm Apr 06 16:53:55 sure Apr 06 16:56:43 kergoth: we kind of align to kernel LTS, which is once a year. 4.1=fido, 4.4=krogoth, 4.9=morty Apr 06 17:08:00 kanavin, marquiz: any luck on the dnf stack? Apr 06 18:06:30 hello, I was following a guide to develope qt apps for yocto and I am getting an error when qt creator transfers the app to yocto Apr 06 18:06:53 the error I am getting is `No such file or directory` Apr 06 18:07:10 this is the guide I was following http://ftp1.digi.com/support/documentation/APN%20-%20Yocto%20QT%20Application%20Development_20140925.pdf Apr 06 18:07:18 can anybody help me? Apr 06 19:01:33 wesam: if you pastebin the error and the commands that entered, that would more useful Apr 06 19:07:52 I'm trying to add the meta-virtualization layer to poky and am running into this error when I try to bitbake docker. What am I missing? -> https://pastebin.com/ywHr6b92 Apr 06 19:18:08 lsandov: ok sure, one sec Apr 06 19:18:16 `sh: /opt/HVAC/bin/HVAC: No such file or directory` is the exact error Apr 06 19:18:54 and I used a kit to run my app Apr 06 19:19:02 * kergoth grumbles Apr 06 19:19:47 so page 11 on the guide i posted would be my kit since i used qt creator to build my app Apr 06 19:20:07 zeddii_home: ping Apr 06 20:37:03 hi, my app was on daisy and now I moved to krogoth and I get this error after I integrated my layer into krogoth The recipe expertcontroller is trying to install files into a shared area when those files already exist. Apr 06 20:37:28 I used to see this in daisy too but it was a warning. I read somewhere that this was changed i think in 2.0 to be an error. Apr 06 20:38:44 I’m not sure how to fix this. I added ${libdir}/* to FILES_${PN} but that doesn’t do anything. Apr 06 20:39:02 I read somewhere I should delete this files in do_install_append Apr 06 20:39:18 so should I just rm these files? Apr 06 20:39:32 these are shared libraries for that qt application Apr 06 20:40:02 thanks Apr 06 20:44:58 HavoK_: so you have two recipes trying to put the same files into the sysroot, that's not allowed Apr 06 20:45:23 HavoK_: the correct solution would be to delete them in do_install in one of the recipes, yes Apr 06 20:45:46 is there a way i can identify which two recipes they are Apr 06 20:45:58 the error should be telling you Apr 06 20:46:08 im guessing expertcontroller is one since thats the one with the error Apr 06 20:46:19 right, that's one yes Apr 06 20:47:32 hmm but that’s the qt app shouldn’t it be responsible for that? Apr 06 20:47:45 it doesn’t even have a do_install method in there Apr 06 20:48:00 do_install will be being defined by a class the recipe inherits Apr 06 20:48:17 you can do a do_install_append to append additional commands in the recipe Apr 06 20:48:32 if the error message doesn't report the other recipe(s) then that is probably because a corresponding manifest isn't present - the files may have been copied in manually at some point (should never be done!) or they were previously installed by a recipe that no longer exists Apr 06 20:49:54 there's no chance you have a recipe installing those files into the sysroot directly is there? Apr 06 20:49:57 so I deleted my tmp directory so copying manually or another recipe doesn’t sound like the problem Apr 06 20:50:20 I wonder if it’s the qt app Apr 06 20:50:51 it's possible its build script is installing files to a place it shouldn't, but that would be unusual Apr 06 20:51:35 you could run some tests by doing bitbake -c clean on the recipe, delete the files, then bitbake -c install on the recipe and see if the files are there again Apr 06 20:52:03 ok let me try that Apr 06 20:56:35 its doing the install now but i looked at the parts in qt and that seems to have it’s local path in opt/b2qt Apr 06 20:57:20 where as the yocto errors seem to be here var-som-mx6/tmp/sysroots/controltech-var-som-mx6/usr/lib/ Apr 06 20:57:27 so i’m guessing it’s some recipe Apr 06 20:57:55 There is actually another recipe that depends and Rdepends on the expert controller would that cause anything? Apr 06 21:04:07 so i just finished bitbake -c install and there are no errors but the files are present in sysroot Apr 06 21:21:44 so looks like install is putting it in sysroot and so is populate_sysroot Apr 06 21:22:35 is that how it’s supposed to work? Apr 06 21:50:26 HavoK_: install puts files in ${D}, thats all. Apr 06 21:50:39 the install task never touches a sysroot Apr 06 21:57:56 @kergoth well it seems like the files are in sysroot after i run bitbake -c install Apr 06 21:58:25 not sure why that is happening if I understand correct they should be in the work dir and populate_sysroot should move them there Apr 06 22:06:15 as i said, do_install writes to D. read the do_install task yourself to see what its doing Apr 06 22:27:58 ok so i see the problem now these libs are installed to ${libdir} by the app and populate_sysroot by default will also copy ${libdir} so they are getting duplicated. I will have to prevent them from going to ${libdir} some how on install or delete them in install_append Apr 06 22:30:58 i think this might be the solution https://lists.yoctoproject.org/pipermail/yocto/2015-March/024228.html Apr 06 23:39:54 HavoK_: the app *really* can't be putting stuff into the sysroot directly, that will end in other problems Apr 06 23:40:04 that directory is managed by sstate Apr 06 23:40:54 well install is installing it in sysroot and then populate_sysroot is trying to do the same Apr 06 23:51:57 i don’t have a do_install so i’m guessing it’s whoever i inherit from which is qmake5 Apr 06 23:55:57 HavoK_: as i said before, do_install installs everything under the ${D} directory. i.e libs to ${D}${libdir} Apr 06 23:56:06 if it does otherwise, it's broken **** ENDING LOGGING AT Fri Apr 07 03:00:00 2017