**** BEGIN LOGGING AT Wed Aug 16 03:00:01 2017 Aug 16 07:52:37 Hello, I am new here. Have a question to Eclipse plugin: Just created the autotools hello world - BUT why the include pathes are point to x86 host pc? This is not what I would expect. Thanks for any hints! Aug 16 09:01:36 Hi everyone! Aug 16 09:01:50 I'm just starting with yocto and I'm having some problems when building the test image core-image-sato Aug 16 09:02:18 Summary: 1 task failed: /yocto/poky/meta/recipes-graphics/mesa/mesa_10.4.4.bb, do_compile Aug 16 09:02:35 Looking at the log file I was able to identify the error: Aug 16 09:02:46 In file included from /yocto/poky/build/tmp/work/i586-poky-linux/mesa/2_10.4.4-r0/Mesa-10.4.4/src/egl/drivers/dri2/egl_dri2.c:49:0: Aug 16 09:03:00 ../../../../src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h: In function 'wl_drm_get_version': Aug 16 09:03:12 ../../../../src/egl/wayland/wayland-drm/wayland-drm-client-protocol.h:241:2: error: implicit declaration of function 'wl_proxy_get_version' [-Werror=implicit-function-declaration] Aug 16 09:03:39 raziel: for which target are you building, and on which branch? Aug 16 09:04:27 I believe the target is qemu Aug 16 09:04:54 are you following the yocto quick start? Aug 16 09:05:05 I just followed an introductory course to embedded linux with yacto Aug 16 09:05:38 it's called raspberry-pi-with-embedded-linux-made-by-yocto Aug 16 09:05:55 can you provide a link please? Aug 16 09:06:50 sure, just that the course is on udemy Aug 16 09:06:52 https://www.udemy.com/raspberry-pi-with-embedded-linux-made-by-yocto/learn/v4/overview Aug 16 09:07:24 well then its hard to look up what you did. Aug 16 09:08:18 have you treid following the yocto quick start first? because that pretty sure build successfully for qemu Aug 16 09:09:53 the instructions were: git clone http://git.yoctoproject.org/git/poky; cd poky; git checkout -b fido origin/fido; source oe-init-build-env; bitbake -k core-image-sato Aug 16 09:10:15 fido?!? Aug 16 09:10:23 and previously I installed the prereq for Ubuntu Aug 16 09:11:01 yes, fido. I don't know what's with that Aug 16 09:11:16 https://wiki.yoctoproject.org/wiki/Releases Aug 16 09:11:23 lets call it "outdated" Aug 16 09:12:37 Someone here working with eclipse and yocto plugin? Aug 16 09:12:56 hm.. maybe that could be the problem? Aug 16 09:13:02 raziel: and there really were *NO* other instructions? you did not leave *ANYTHING* out? Aug 16 09:13:38 LetoThe2nd: yes, I did not leave anything out Aug 16 09:13:49 raziel: it technically should still build. let me give it a try here. Aug 16 09:13:57 I am wondering about the shown includes: They all point to my x86 host pc. That couldn't be right, or? Aug 16 09:15:31 The compiled binary seems to be ok (so arm code) Aug 16 09:16:08 Arnp: if nobody answers, probably nobody knows. just as a thought, it might be some incorrect path resolution or such by the eclipse gui Aug 16 09:16:22 (if the build is fine, that is) Aug 16 09:18:15 LetoThe2nd: previous to that I installed the following packages(Ubuntu 16.04): gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev xterm Aug 16 09:19:17 raziel: i see. i just kicked off a build to test it, but that will take some time. Aug 16 09:21:21 @LetoThe2nd: Yepp maybe you are right. But do that right is what I would expect from the plugin. It gets pathes for sysroot and toolchain. Haven't found a community for this plugin yet. Aug 16 09:21:21 LetoThe2nd: thanks! I will remain in the channel Aug 16 09:21:52 Arnp: the sad truth is that the plugin is maintained half-heartedly at best Aug 16 09:23:43 What a pity, as idea for this plugin is good. Aug 16 09:24:42 Arnp: there's just nobody having enough interest (equals time and/or money) to actively maintain it, AFACS Aug 16 09:27:17 Arnp: there is some work going on on the plugin FYI, I'm not intimately familiar with the details but don't lose hope :) Aug 16 09:31:16 bluelightning: yeah i know its not abandoned completely, but ever since i've started looking at it, it was never like a first class effort thing Aug 16 09:37:28 LetoThe2nd: that's a fair assessment Aug 16 09:37:53 :-) Aug 16 09:37:53 the current effort AFAIK is to do something more in line with upstream and therefore make it easier to maintain Aug 16 09:38:33 to be fair, IMHO the eclipse cdt is less then optimal to use too. Aug 16 09:39:11 some day i gotta give the qtcreator stuff a try Aug 16 09:39:40 I'm trying to use a symlink as tmp-glibc/deploy/ipk and bitbake keeps overwriting it and putting a directory instead while building random recipes, I've been searching for the codepath which deletes the $DEPLOY_DIR_IPK symlink with no success, any pointers? Aug 16 09:50:40 @bluelightning: do you have an email, mailing list ... whatever? Aug 16 09:50:47 regarding the plugin? Aug 16 09:51:52 Arnp: it doesn't have its own dedicated mailing list that I'm aware of, discussion would go on the main yocto list Aug 16 09:52:24 I can poke someone tomorrow to send something out about what's going on Aug 16 09:53:59 Until now I did use a plugin, bit have difficulties to resolve the includes properly. I added the pathes manually, but it seems in deeper levels of includes it doesn't work anymore. (there are a lot of things to set, like _arm_ or _gnu_ .. I am not familiar with this stuff.) Aug 16 09:55:55 @bluelightning: good idea. I'll try a post to the mailing list too. Aug 16 10:23:48 so I think I found my problem with bitbake overwriting my tmp-glibc/deploy/ipk symlink: there's a tar invocation in copyhardlinktree in oe-core's meta/lib/oe/path.py Aug 16 10:24:27 starting with tar 1.26 the extraction behaviour has changed to overwriting symlinks by default according to: https://stackoverflow.com/questions/29239081/how-to-prevent-symbolic-links-overwritten-from-tar-file-extract-command Aug 16 10:56:23 raziel: the build did successfully complete here. Aug 16 12:09:05 Hi, I have created a bitbake recepi for my program but i get a segfault when i start it ( its a QT application when i build the application using qt and use the sdk i created it wil run Aug 16 12:09:53 hmwel: run it within gdb to find out what actually segfaults Aug 16 12:22:54 hi all, anyone aware of scipy yocto recipe? Any version is fine. Aug 16 12:23:30 rshanmu: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=scipy Aug 16 12:23:34 rshanmu: so, no. Aug 16 12:24:16 marquiz_: btw, DNF accepts a list of GPG keys for gpgkey= in repo files Aug 16 12:24:27 so you can have more than one GPG key to potentially accept Aug 16 12:24:33 in re: https://github.com/openembedded/openembedded-core/commit/f7716f1de0791dfe778bb70f1769a7e1e83c7a54 Aug 16 12:25:07 LetoThe2nd: Yes, I tried that and wanted to check if there is any unofficial hacks around. Thanks Aug 16 12:50:09 Son_Goku: yes, but we only support one signing key, currently Aug 16 12:50:50 defined by PACKAGE_FEED_GPG_NAME Aug 16 12:52:06 ah Aug 16 12:52:31 btw, with rpm packages, does Yocto stuff follow normal package conventions? Aug 16 12:52:43 that is: -devel, -debuginfo, -debugsource, etc.? Aug 16 12:53:19 and are the dependency generators activated in Yocto rpm? Aug 16 12:56:49 Son_Goku: more or less, yes, there are -dev and -dbg packages Aug 16 12:57:00 :/ Aug 16 12:57:12 -dbg has includes both debuginfo and debugsource Aug 16 12:57:15 ah Aug 16 12:57:26 you don't have the split debuginfo and debugsource stuff then Aug 16 12:57:40 no Aug 16 13:00:51 Son_Goku: iirc, dependencies are taken from bitbake Aug 16 13:01:12 so that means that package naming is debian style across the entire thing, isn't it? Aug 16 13:04:29 Son_Goku: what do you mean by debian style? Aug 16 13:05:33 libfoo1, libfoo-dev, libnet-arp-perl, etc. Aug 16 13:05:53 createrepo-c, etc. Aug 16 13:09:31 Son_Goku: no, i don't think there's a strict policy like that Aug 16 13:11:46 Son_Goku: but probably i'm not the best person to answer that Aug 16 13:11:56 * Son_Goku shrugs Aug 16 13:12:45 i guess the package names mostly follow the debian way, but i don't know how strictly Aug 16 13:18:52 Son_Goku: YP supports opkg and dpkg in addition to rpm, and historically opkg was first Aug 16 13:19:42 Son_Goku: then people wanted rpm (for lsb certification etc.) and so it was added, and it's now about 50/50 split with opkg in popularity, I believe Aug 16 13:20:13 what makes opkg equally popular to rpm? Aug 16 13:20:24 is it historical things or are there some technical things? Aug 16 13:20:34 Son_Goku: it could be possible to make rpm packages follow whatever 'normal' rpm conventions are set by Fedora, but it would just cause confusion I think Aug 16 13:21:13 kanavin, I'm considering using Yocto to bootstrap a regular rpm-based distribution, which is why I'm asking :) Aug 16 13:22:06 Son_Goku: it's a lot more lightweight Aug 16 13:22:15 just "lightness"? Aug 16 13:22:31 Son_Goku: you need to ask someone who is using opkg, I am not such a person Aug 16 13:22:37 :) Aug 16 13:23:11 Son_Goku: all I know is people want it, and we're not forcing rpm on them (actually YP's whole point is that it is not forcing anything on its users :) Aug 16 13:23:27 yeah, I know Aug 16 13:23:37 I'm just wondering what makes someone pick opkg over rpm Aug 16 13:23:45 and if it's something actually addressable Aug 16 13:23:54 LetoThe2nd: sorry, I got disconnected, any update with the build? Aug 16 13:24:10 raziel: completed successfully Aug 16 13:25:12 LetoThe2nd: you did the build with "git checkout -b fido origin/fido" ? Aug 16 13:25:25 raziel: yes. Aug 16 13:26:53 anyone here knows who's working on rock64 yocto support ? Aug 16 13:26:55 LetoThe2nd: ok, so it's something on my system. but probably I should try with the latest stable like pyro Aug 16 13:32:12 yann|work: maybe ask the meta-rockchip maintainers?: https://layers.openembedded.org/layerindex/branch/master/layer/meta-rockchip/ Aug 16 13:35:16 smurray: thx for the hint Aug 16 13:46:21 LetoThe2nd:thanks for your help Aug 16 15:34:25 alimon, On auh, it appears that builds are happening outside of the /home/auh/build filesystem and have filled the / filesystem. I'm removing ~auh/build2/tmp for now. Aug 16 15:34:54 alimon, I need to install updates and reboot. Can you make it use the dedicated build filesystem again? Aug 16 16:18:19 If kernel modules are configured to be built as modules, how do you package those kernel modules in the image rootfs? Aug 16 16:22:21 meinhere: add the "kernel-module-" package to your image Aug 16 17:06:24 Thanks nrossi! Are those "kernel-module-*" packages auto-generated or do I need to make sure a recipe exists for each kernel module I intend to include in my image? Aug 16 17:07:26 meinhere: should be autogenerated, as long as your kernel recipe uses kernel.bbclass Aug 16 17:20:24 Hi, Im trying to optimize bitbake run times and ran a few sample cases with 24,32,48 threads and I not seeing much increase in performance after 24. I'm guessing this is due to dependencies but what would be the best way to see exactly why? Aug 16 17:36:32 i'm having an issue with a packagegroup recipe reporting that it cannot satisfy some deps during a target image rootfs task despite those deps definitely being built. i've tried running cleansstate on each individual package, the packagegroup, and the image target, and rebuilding to no success Aug 16 17:36:40 what else should i try? Aug 16 17:41:42 @pyllip use bitbake -g -u depexp Aug 16 17:42:28 it would provide the entire graphical dependency chain for the packagegroup, so that you can resolve your issue Aug 16 17:44:06 isn't a devtool "workspace" by default the subdirectory "workspace" under the build directory? Aug 16 17:44:32 phyllip: that could happen if no packages were generated from your recipe, for instance if it doesn't install any files for some reason. you can look around in your recipe's ${WORKDIR} Aug 16 17:45:12 (or rather, the rdepended package wasn't generated...) Aug 16 17:45:44 if so, then why, with an empty build directory (except for the conf subdir), does "devtool modify -x recipe-kernel" report a "ERROR: recipe recipe-kernel is already in your workspace"? Aug 16 17:46:23 zbr: that's the odd thing: i believe i found the generated packages for each dependency. these packages were previously excluded so i think it's a cache issue somewhere along the chain but no luck with the obvious cleanup targets Aug 16 17:47:09 and i don't want to wipe the build directory and start from scratch since the full build takes ~18h Aug 16 17:47:53 phyllip: do the packages exist in tmp/deploy/rpms (or whatever package format you use)? Aug 16 17:48:14 zbr: IPKs and yes Aug 16 17:48:26 that's why this is driving me nuts :) Aug 16 17:48:44 is the rootfs rebuilt from scratch? Aug 16 17:48:51 for the image recipe Aug 16 17:49:42 or am i confusing the error your having? is it from the ipk package manager or from bitbake? Aug 16 17:50:22 zbr: bitbake. the failure occurs at do_rootfs for the image target stating that a packagegroup cannot resolve deps Aug 16 17:50:54 it should be rebuilding from scratch as i've run cleansstate task for the image target, the packagegroup, and each package that is reportedly missing Aug 16 17:52:00 ah, yes, do_rootfs for the image recipe. i think that's what i meant by the ipk package manager. havne't worked with ipk based images though Aug 16 17:54:42 oh, then yes it's failing there, sorry Aug 16 17:55:18 you could have a look through the log.do_rootfs and see if it mentions something about ignoring your package or similar Aug 16 17:55:37 other than that, i got nothing, sorry : Aug 16 17:55:39 :( Aug 16 17:57:28 that's helpful, tbh Aug 16 17:57:43 i found that these packages are still being ignored for some reason Aug 16 17:59:12 even after i modified the machine target conf that was the source of them being excluded Aug 16 18:00:06 so there's a cache outside of the image target, packagegroup, and individual packages that is holding onto these settings Aug 16 18:02:17 why am i now getting this in a fresh build (oe-init-build-env fresh-dir) following by conf configruation in that build (just like other builds), followed by "fdevtool modify -x recipe-kernel workspace" ERROR: externalsrc is currently enabled for the linux-variscite recipe. This prevents the normal do_patch task from working. You will need to disable this first Aug 16 18:02:53 i haven't non-build sources files since this was working Aug 16 18:03:02 haven't changed any... Aug 16 18:08:36 yates: are you using same workspace for externalsrc ? Aug 16 18:08:57 usually that kind of creates this issue Aug 16 18:10:10 this return nothing in my sources directory: "find . -name "*.bb" -type f -exec grep -Hn externalsrc {} \;" Aug 16 18:10:37 it sets a workspace where it will do all externalsrc stuff Aug 16 18:10:40 is that dir same ? Aug 16 18:10:56 khem: i don't know how, where, or even if, externalsrc is defined Aug 16 18:11:19 when you use devtool modify it will create one for you in current builddir Aug 16 18:11:24 a dir called workspace Aug 16 18:11:39 everything externalsrc will be under it Aug 16 18:11:46 khem: i did the grep from the /sources directory Aug 16 18:12:21 it will be in build area not source Aug 16 18:13:28 khem: when i ". oe-init-build-env build-name", it creates a build directory /sources/poky/build-name Aug 16 18:14:53 yes Aug 16 18:15:07 do you see a workspace/ dir under it Aug 16 18:15:29 yes Aug 16 18:16:40 but i get that error Aug 16 18:18:03 that is, in a new xterm, cding into /sources/poky, then running ". oe-init-build-env build-error-test", then running "devtool modify -x recipe-kernel", i get "ERROR: recipe recipe-kernel is already in your workspace"? Aug 16 18:18:24 sorry, correction.. Aug 16 18:18:51 ... then running "devtool modify -x recipe-kernel workspace", i get "ERROR: recipe recipe-kernel is already in your workspace"? Aug 16 18:19:47 isn't the "workspace" argument to devtool modify telling devtool where to create the workspace? Aug 16 18:20:43 oh wait. Aug 16 18:21:05 i forgot the MACHINE=... environment defs... Aug 16 18:25:54 khem: but do i have it right concerning the workspace argument to devtool modify? Aug 16 18:26:43 that is where devtool will (for one thing) put the intermediate (patched) linux source, right? Aug 16 18:31:05 i lied Aug 16 18:31:45 after running oe-init, i copy a "standard" set of local.conf and bblayers.conf files into my build's conf dir, THEN i run devtool modify ... Aug 16 18:31:56 so i don't need the env. variables. Aug 16 18:32:33 i'm not even sure the standard oe-init uses those, i think it was a custom init variscite provided that did taht Aug 16 20:03:07 Will there be a Yocto Developer Day in Europe at this years ELCE? I didn't find any information. Only for NA (https://www.yoctoproject.org/yocto-project-dev-day-north-america-2017) Aug 16 20:13:01 Im trying to optimize bitbake run times and ran a few sample cases with 24,32,48 threads and I not seeing much increase in performance after 24. I'm guessing this is due to dependencies but what would be the best way to see exactly why? Aug 16 20:17:42 Anyone well versed with bitbake dependencies? I have a project X that depends on virtual/Y. I've specified that virtual/Y is provided with Y1 for my machine. When I build Y1, then X by hand, everything works. When I do a bitbake -c clean Y1 X and then do bitbake -C configure X, Y1 never gets rebuilt, and X fails. I have DEPENDS = 'virtual/Y' and do_compile[depend] = 'virtual/Y:do_compile' in my X.bb file, but Aug 16 20:17:44 still can't figure out why Y1 doesn't get built. Aug 16 20:23:38 jaewon: you can produce a bootchart-style chart that shows the bottlenecks Aug 16 20:26:25 jaewon: https://wiki.yoctoproject.org/wiki/Profiling#Using_pybootchart Aug 16 20:27:44 sachit: try bitbake -g X and see if the dependency relationship is shown there Aug 16 20:28:55 that do_compile dependency line is probably incorrect.. if you used [depend] that's the wrong varflag, and in any case do_compile wouldn't be the task to depend upon, it would be do_populate_sysroot - but even that is probably unnecessary Aug 16 20:29:37 if an item is in DEPENDS it effectively translates to the do_configure task of your recipe depending on the item's do_populate_sysroot task Aug 16 20:29:55 (there is some nuance especially with recipe-specific sysroots, but that is the simple version) Aug 16 20:31:33 @bluelightning: I just tried that :) I do see Y1 listed there in the output files, so it seems to be picked up correctly. At first I tried with just DEPENDS = but that didn't seem to do it, so I added the second line. I'll play around with do_populate_sysroot instead of do_compile to see if that helps, thanks. Aug 16 20:46:28 do_compile[depend] = 'virtual/Y:do_compile' Aug 16 20:46:50 thats not needed, you can simply do DEPENDS += "virtual/Y" Aug 16 20:47:01 in X Aug 16 20:56:44 bachp: I think there should be one Aug 16 20:56:55 ping jefro about it Aug 16 20:57:38 jaewon: what was your system dram and storage **** ENDING LOGGING AT Thu Aug 17 03:00:00 2017