**** BEGIN LOGGING AT Fri Jan 05 03:00:01 2018 Jan 05 03:03:29 New news from stackoverflow: How to add all files from a folder in src_uri in a bitbake file Jan 05 05:52:12 I have query regarding build of yocto project, I working on RDK emulator (https://rdkcentral.com/), which developed base on yocto. I making some changes in some file using bitbake I'm only compiling that package, but to include that into final image, is there any way?? Jan 05 05:52:25 I'm new to bitbake & yocto Jan 05 05:53:07 Currently I'm rebuilding my image after generating my altered package. but that is time consuming process Jan 05 05:56:41 I'm familiar with Makefile build system, there any file is changed make will take care of it and update your final image too. But after working with yocto for a while it seems like yocto doesn't work that way. Jan 05 06:04:04 New news from stackoverflow: dtc command not found in yocto || How to update newest yocto version Jan 05 06:36:08 Can anyone help me with this question: https://stackoverflow.com/questions/48108405/how-to-add-include-altered-package-into-final-image-yocto-project Jan 05 07:04:15 New news from stackoverflow: How to add/include altered package into final image? [Yocto Project] Jan 05 08:23:32 I want to keep up with the latest Yocto releases, but stay on Qt 5.6.3 because of licensing stuff. Is that in any way supported? Jan 05 08:23:37 (good morning) Jan 05 08:26:41 otavio, perhaps you can answer ^ Jan 05 09:41:55 tasslehoff: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PREFERRED_VERSION ? Jan 05 09:53:17 hi yocto guys, anyone here working on SELinux? Jan 05 10:04:41 nayfe: thanks, but my "issue" is that Qt 5.6.3 is not in the pyro layers. it is in krogoth, but that breaks some patching from freescale. I can make it work, but just wondered if I had overlooked something, since 5.6 is an LTS release and a change point licensewise Jan 05 10:29:30 When generating an image I am getting: "core-image-base-1.0-r0 do_rootfs: [log_check] core-image-base: found 2 warning messages in the logfile", warning: %post(init-ifupdown-1.0-r7.0.ccimx6sbc) scriptlet failed, exit status 1 Jan 05 10:29:35 where can I check those errors? Jan 05 10:34:53 New news from stackoverflow: populate_sdk error for meta-toolchain-qt5 Jan 05 10:35:50 hello there. I have a problem with adding meta-oe to a raspberry pi project. Can someone help me with some info and guidelines? Thank you! Jan 05 10:46:52 loxeen: do you just want to build an image for RPi, or doing something else? Jan 05 10:48:27 as a start, I just want to build an image. I managed to build it a rpi-basic-image without the meta-oe layer. but as soon as i put that one, i get this error: Could not inherit file classes/python3-dir.bbclass Jan 05 11:15:48 loxeen: sounds like you're mixing versions Jan 05 11:16:09 meta-oe master and an older oe-core version Jan 05 11:16:14 always match your versions Jan 05 11:16:37 how do i get them to the same version? Jan 05 11:16:53 did you get meta-oe using git? switch to the right branch Jan 05 11:17:03 yes, git it is. Jan 05 11:17:32 ok, let me see Jan 05 11:21:01 in docker I get "Sorry, you are not allowed to execute as root." when installing the sdk. does it use fakeroot or something like that? when installing on my computer it does not ask for a password. Jan 05 11:21:42 rburton: how what exacly should I change? because I have manster branch on both poky and master-oe Jan 05 11:22:10 python3-dir.bbclass is in poky master so i doubt that Jan 05 11:23:33 at Jan 05 11:23:33 $ git show-branch --list I get: Jan 05 11:23:33 [master] python-scons: upgrade to v3.0.1; use pypi.bbclass Jan 05 11:24:12 ah. nevermind. permission issues on the folder Jan 05 11:24:22 loxeen: you've broken bblayers.conf? Jan 05 11:24:35 i use hob, so i don Jan 05 11:24:41 don't think so* Jan 05 11:24:47 not with master you don't Jan 05 11:25:06 it was deleted in 2016 Jan 05 11:25:45 I have a checkout on header b8631416f12b8a904ce3deb036f9d5ce632937b0 Jan 05 11:26:24 kanavin: we nearly got a green build: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/727/steps/Running%20oe-selftest/logs/stdio - care to send a patch to fix that piece? Jan 05 11:26:28 loxeen: thats probably the problem if you're mixing two different oe-core checkouts Jan 05 11:27:04 yes, indeed. the thing is i need to use that checkout Jan 05 11:27:57 if you want to use oe-core master then you can't use hob. if you need to use hob then you need to use versions from when hob existed. Jan 05 11:28:30 (just don't use hob) Jan 05 11:28:47 ok, will try that now Jan 05 11:29:16 without using hob, and keep the headers and the meta-oe layer as it is now, righT? Jan 05 11:30:55 I get the same error if i do bitbake rpi-basic-image, without hob Jan 05 11:33:03 loxeen: then you're not using the master branch of poky Jan 05 11:33:12 i'd double-check your bblayers Jan 05 11:33:55 RP: any chance to get the OpenSSL fixes in rocko anytime soon? https://patchwork.openembedded.org/series/10260/ Jan 05 11:36:49 kanavin: g-i fixes \o/ \o/ Jan 05 11:37:24 sagner: armin has them queued, the builds failed though Jan 05 11:37:41 sagner: autobuilder issues, not your patches Jan 05 11:38:04 * RP is fighting the testing issues as fast as he can but alone, it takes a while Jan 05 11:39:29 RP: ok, I see. Jan 05 11:39:38 rburton: if i use the last version of poky i get this error at rpi-basic-image: fatal: reference is not a tree: 05aeafd053e56356ec8c62f4bb8f7b95bae192f3 Jan 05 11:40:03 $ git show 05aeafd053e56356ec8c62f4bb8f7b95bae192f3 Jan 05 11:40:03 fatal: bad object 05aeafd053e56356ec8c62f4bb8f7b95bae192f3 Jan 05 11:40:10 did you do a bad checkout? Jan 05 11:40:23 without more context i can't help at all Jan 05 11:44:09 So here is my build config, if it helps to create a context https://pastebin.com/ArFGwH1j Jan 05 12:11:48 loxeen: commit hashes look correct for master branches, could you share the full bitbake output? Jan 05 12:12:19 I wonder if the git error ("fatal: reference is not a tree") is happening during the fetch of some recipe Jan 05 13:17:32 paulbarker right away Jan 05 13:18:21 paulbarker: here is the output https://pastebin.com/Wtzarr97 Jan 05 13:19:04 ok, it's failing during checkout Jan 05 13:19:19 that does that mean? Jan 05 13:19:20 for prelink-native Jan 05 13:19:35 just thinking it through now Jan 05 13:19:43 you were using old branches before yes? Jan 05 13:20:08 then switched to master Jan 05 13:20:11 am I right there? Jan 05 13:20:13 this is a new copy of the poky, up to date Jan 05 13:20:20 ok Jan 05 13:20:36 so you didn't have an old tmp directory left behind? Jan 05 13:21:24 not really sure, but no. this is a new copy Jan 05 13:21:51 with commit 433ef0f8e9e63e4459934a06a42b56989c885e44 from 2th of Jan Jan 05 13:22:19 Did you completely delete the poky directory and start again? Or just do a `git checkout master` in each repo? Jan 05 13:22:34 completely deleted it and created a new one Jan 05 13:22:37 Ok Jan 05 13:22:51 So we don't have old data left in tmp. That rules out my first guess Jan 05 13:23:21 Try fully cleaning prelink-native by running `bitbake prelink-native -c cleanall`, then retry the build Jan 05 13:23:31 omw Jan 05 13:23:38 that may help if something got corrupted during the fetch Jan 05 13:25:07 yas! this worked Jan 05 13:25:16 Thank you, paulbarker! Jan 05 13:25:53 So my guess is that the git fetch someone went wrong. That should have been caught by bitbake but for some reason it wasn't Jan 05 13:26:02 s/someone/somehow/ Jan 05 13:27:05 i change networks a lot, so maybe thats why some packages got corrupted somehow Jan 05 14:13:11 Can anybody explain how bitbake decides how many tasks to parallelize over the course of a build? Jan 05 14:14:06 I started a bake on my spiffy new Ryzen machine this AM and it automajikly bounced out with 12 tasks at a time. Jan 05 14:15:07 Thought ... 'Kewl ...' but then later about half way through the task list it throttled that back to 6 Jan 05 14:15:37 Now it seems to only want to do 2 or 3 at a time. Jan 05 14:15:54 it depends on the bottleneck of dependencies Jan 05 14:16:18 after some time, everything will wait until kernel is complete, because it is impossible to build anything else when there's no kernel Jan 05 14:16:36 so it tries to do its best all the time, it is just nature of dependencies Jan 05 14:16:42 Aw ... that make total sense. Jan 05 14:16:43 xthunderheartx: what luneff said, plus it uses the number of cpu cores as a maximum Jan 05 14:17:14 Should have thought of that. Jan 05 14:19:57 Oh yeah baby! Back up to 12 at a go! Awesome ... Jan 05 14:54:41 exactly, dependency bottleneck Jan 05 14:55:10 once you have the big things built you won't see that as much on rebuilds Jan 05 14:56:30 I have a recipe where i created a do_install_append() method, but in total compile, install, deploy are never called. If I explicity call bitback plg -c compile then it gets executed, same for install and deploy. What am I missing ?? Jan 05 15:02:31 I have made a rudimentary performance checker, https://github.com/sveinse/yocto-benchmark, and when I run building poky from scratch on a 40 core machine, I only get average CPU usage of around 14,9 CPUs. So yeah, not everything in Yocto builds can be parallelized. Jan 05 15:06:34 Can someone explain what does this mean (from the Yocto 2.3 migration notes) alsa-conf-base: Merged into alsa-conf since libasound depended on both. Essentially, no way existed to install only one of these. Jan 05 15:09:06 ttllkk: migration notes are typically written as commit message summaries, so you should simply find the relevant commit Jan 05 15:10:22 @sveinse: Interesting. And here I was all excited about my puny 6 cores! 40 cores or 40 threads? Jan 05 15:12:42 xthunderheartx: Dual CPU 10 core Xeon, each core with 2x HT, so I've got 40 tuxes in bootup Jan 05 15:13:54 Zippy I bet. Jan 05 15:14:01 ..but it shows that its overkill for Yocto. Jan 05 15:15:04 Look at the URL, then you can see the results for a 16 CPU server as well. the 40 core clocks in at 19mins, while the 16 core is at 29mins (where the latter unfortunately runs on a VM) Jan 05 15:16:01 Its a part of an investigate here at our work to assess what kind of HW is needed for the various tasks Jan 05 15:18:42 xthunderheartx: If you want to, you can download and run the test. I would be happy to place the results up on the scoreboard if you want. In fact, I'd like that. Jan 05 15:23:19 Will do dood. I'll run it a little later this afternoon when I clear some of this junk from my inbox. Work always gets in the way of getting anything done. Jan 05 15:23:59 xthunderheartx: cool. no hurry. Jan 05 15:28:29 sveinse: it all depends what you're doing. I've done a lot of work trying to improve the parallelisation and optimise things in the past. Some bits of the build can take advantage of many cores (kernel, webkit, gcc to some extent) Jan 05 15:49:13 I see mmc-utils_git.bb .If I want to add the package, is the name mmc-utils or mmc-utils_git ? Jan 05 15:50:04 RP, yes. I'm being blunt and just measures oe/bb out of box. I've seen a wiki on Yocto about a measurement about number of tasks up against jobs. That was perhaps your work? Jan 05 15:51:42 My purpose is not initially to tweak oe, but to gauge machine performance. What better measure than to compare the thing its going to do? I'm building a funding request to IT for the team, you see Jan 05 15:53:13 hi Jan 05 15:53:38 bitbake's fetcher apparently does not find the `7za` executable, even though it's there :-/ Jan 05 15:58:25 also: shouldn't http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#packages mention 7z then? Jan 05 16:02:57 sveinse: that was Darren's :) Jan 05 16:03:17 sveinse: makes sense, was also just giving background Jan 05 16:05:02 Dood u gotta fudge up them results soes you can get the cash for a few of 'em dual 10 core Xeons ... daaaaaaang. Jan 05 17:10:59 armpit: I ran a rocko build based on your stable branch now the inode issue was fixed, its not looking bad Jan 05 17:14:15 cool. thanks. I have a few python3 change to backport still. Jan 05 17:15:45 armpit: right, was just hoping to clear the queue a bit Jan 05 17:16:04 armpit: I have a change pending for master to fix the runtime cpio fetch failure Jan 05 17:17:35 k Jan 05 17:22:13 Hi Jan 05 17:22:36 Anyone ever managed to get lvm2 into a initramfs? I'm getting dependency loops, not sure how to read them anyway Jan 05 17:23:29 This is what I get as log: https://bpaste.net/show/31f8f0b2f850 Jan 05 18:27:07 RP: armpit: rocko-next is missing my python[3]-setuptools patch from yesterday Jan 05 18:28:54 isn't http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/python?h=rocko-next&id=07256a142c2e9578f23b4d60a602a55ba03d328d Jan 05 18:28:58 it ? Jan 05 18:29:52 its not in my stagging, RP pulled it in Jan 05 18:30:00 to main line Jan 05 18:31:39 I'd like to implement a singleton in a module. I do this by having a global variable 'engine' in on of the files. Problem is that I see that its slightly risky to use this, as from singleton import engine can yield different results than import singleton and then later singleton.engine. What is a good way of going around that caveat? Jan 05 18:32:15 Wrong channel, sorry :( Jan 05 19:14:54 armpit: my bad, it was the first patch pulled in and on a different page on the web ui Jan 05 19:15:57 RP: ^^ Jan 05 19:16:15 sigh Jan 05 19:16:24 maybe I should just go back to bed Jan 05 19:37:42 Hi, How do I make a recipe produce statically linked elf binaries? Is there a flag or variable I need ot set in the recipe? Jan 05 19:40:08 it's not something we go out of our way to support, and how you do so precisely will vary depending on the buildsystem of the project.. you could try adding -static to LDFLAGS or so, unless the project itself provides a mechanism to do it, i.e. a configure script argument Jan 05 19:42:28 hmm.. Ok, Thanks. Jan 05 19:44:52 Hi, The logs for this year (2018) are not available in logs website. Is that normal? Jan 05 19:44:59 (IRC Logs) Jan 05 20:49:29 so who's working on the kpti patches? git.yoctoproject.org seems pretty quiet Jan 05 20:55:10 i see some activity on linux-yocto-contrib but nothing for linux-yocto-dev, or any of the linux-yocto-4.x repos Jan 05 22:02:09 sum1: the kernel maintainer is back from vacation on Monday Jan 05 22:10:23 oh... that's unfortunate. guess i'll have to go the linux-yocto-custom route. Jan 05 22:26:51 hmm, meson.bbclass incorrectly uses TARGET_CC_ARCH rather than HOST_CC_ARCH the way the CC definition does, inconsistent with default behavior for other buildsystems Jan 05 22:27:54 also inconsistent with its own usage of HOST_PREFIX Jan 05 22:27:58 * kergoth tests Jan 06 02:05:02 hello guys Jan 06 02:07:24 i get this error at btibake rpi-basic-image https://pastebin.com/QPFVnN5A . Any ideea why that might may be? thank you! **** ENDING LOGGING AT Sat Jan 06 03:00:02 2018