**** BEGIN LOGGING AT Fri Jun 08 03:00:18 2018 Jun 08 06:44:33 New news from stackoverflow: Issue when integrating different bsp-layers on a single bblayers.conf [on hold] Jun 08 07:16:54 Hi everyone! I'm rather new to yocto and try to build a vendor BSP for Intel based platforms. Currently I'm desperately trying to understand why my kernel configuration fragment is correctly applied to the standard kernel but not to the RT variant. I'm using two different machines for that purpose but have identical .conf and .scc files but for RT aspects (same KMACHINE/KARCH/conf fragment). Jun 08 07:17:20 khem: sorry for the late answer, I was away for the night... Jun 08 07:17:54 I had a package with do_fetch[depends] = core-image-minimal:do_build and apparently Yocto doesn't like that. Jun 08 07:17:55 Enabling verbose bitbake build didn't give me a clue nor did examining the .meta-kernel contents; I only see that for one machine my fragment is processed and not for the other Jun 08 07:18:02 expressing that differently solved the problem Jun 08 07:18:36 Has anyone some ideas for me how to find out the problem? Jun 08 07:18:58 bugsbunny: is the fragment in the SRC_URI of the failing one ? Jun 08 07:19:57 boucman_work: the linux-yocto and linux-yocto-rt recipes are also identical but for the different .scc file, so yes, it is there Jun 08 07:21:39 i don't know, then... Jun 08 07:21:54 boucman_work: that is exactly what drives me crazy that there are nearly no differences between the tow machines regarding kernel build but build is working only for one ... Jun 08 07:22:27 boucman_work: thanks for your help Jun 08 07:23:48 bugsbunny: you might want at the output of "bitbake -e virtual/kernel" (warning, it's huge) Jun 08 07:24:02 bugsbunny: are you using your own .scc files or from yocto-kernel-cache? Jun 08 07:24:06 that will tell you all bitbake variables and how they reached their current value Jun 08 07:24:46 boucman_work: I will try that, thanks Jun 08 07:25:03 anujm: I have own .scc files Jun 08 07:25:17 and the KTYPE is same for rt and non-rt? Jun 08 07:25:32 yes Jun 08 07:25:39 is that a problem? Jun 08 07:26:20 hmm, sorry, currently I tried to have separate machines Jun 08 07:28:47 sorry again, I'm not completely awake obviously ... same KMACHINE, KTYPE is standard for the non-rt machein, preempt-rt for the rt machine, and the respective .scc file is included (ktypes/standard/standard.scc or ktypes/preempt-rt/preempt-rt.scc) Jun 08 07:29:34 rest of .scc files is identical for the two machines Jun 08 07:31:08 also the .conf files for the two machines have only one difference: PREFERRED_PROVIDER_virtual/kernel Jun 08 07:33:56 boucman_work: the output would be the same as that of "bitbake -e linux-yocto" / "bitbake -e linux-yocto-rt", wouldn't it? Jun 08 07:34:57 boucman_work: I ask because I already had a look at that and tried to spot the difference between the two by comparing them, but I didn't find any hint about kernel configuration stuff Jun 08 07:43:12 boucman_work: in both environments appear the right files for the machine (SRC_URI contents of linux-yocto bbappend) and variable sccs in function do_kernel_metadata() also contains my scc files and the configuration fragment Jun 08 07:48:41 and still my fragment pops up only in merge_config_build.log of non-rt machine, it's a complete mystery to me ... Jun 08 07:55:20 bugsbunny: yes, same outpout... Jun 08 07:55:38 but that was a generic suggestion, if you have already looked into that, wouldn't help. Jun 08 07:56:13 boucman_work: thanks for the answer, I meanwwhile checked that, too :-) Jun 08 07:57:35 Has anyone else an idea why a kernel configuration fragment listed in SRC_URI wouldn't be considered for building complete kernel config? Jun 08 08:00:32 I'm out of ideas what else to check atm, it seems I need to dig deeper into the involved tools to get more information, but don't know how :-/ Jun 08 08:14:39 the next step would be to check what's happening in $WORKDIR Jun 08 08:14:58 but kernel compilation is kind of a mistery to me, so I can't really help you with that... Jun 08 08:23:45 boucman_work: ok, thanks for your help anyway :-) Jun 08 08:26:04 bugsbunny: do you have FILESEXTRAPATHS in your .bbappend ? Jun 08 08:26:26 boucman_work: I already tried to turn into the bumpy road of finding out what exactly do_kernel_metadata() does, but apparently it isn't as easy as adding a "set -vx" to dp_kernel_metadata() in the linux-kernel.bbclass Jun 08 08:27:14 mckoan: yep, it's the same for both .bbappend recipes (rt & non-rt) Jun 08 08:51:15 Hi, Jun 08 08:51:36 I have a question about the licenses stuff of Yocto. I hope this is the correct place to ask. Jun 08 08:52:18 I followed the instructions of the mega manual (chapter 7.32.3.1 Providing the Source Code). Jun 08 08:52:51 Added in my local.conf: Jun 08 08:53:00 INHERIT += "archiver" Jun 08 08:53:13 ARCHIVER_MODE[src] = "original" Jun 08 08:53:19 COPYLEFT_LICENSE_EXCLUDE="CLOSED Proprietary" Jun 08 08:53:45 I have a recipe called x.bb, with 'LICENSE = "Proprietary"' Jun 08 08:54:34 After a build of the image, there is the file 'build/deploy/licenses/x/recipeinfo' which holds the correct license 'LICENSE: Proprietary' Jun 08 08:54:56 However, I still see the archive of the source code in 'build/deploy/source' Jun 08 08:55:07 What do I do wrong? Jun 08 09:10:46 vermaete: I've never seen any source directory under deploy Jun 08 09:11:45 True, it's something in my local.conf to have it there. It's not the default. Jun 08 09:22:48 I6 is the same without the 'DEPLOY_DIR = "${TOPDIR}/deploy" in my local.conf Jun 08 10:13:10 rburton: I've updated -next with the best patchset we have, still waiting on the mips/ppc/arm bsp updates for gcc8 though Jun 08 10:22:40 RP: there are 2 more gcc8 related changes which I currently don't see in master-next https://patchwork.openembedded.org/patch/151236/ https://patchwork.openembedded.org/patch/151342/ Jun 08 10:46:09 JaMa: hmm, I'd assumed systemd was building since the regression tests passed. I've queued both, thanks Jun 08 10:48:11 RP: systemd one is triggered only with DEBUG_BUILD enabled which probably isn't in any build on AB, same with thumb on armv5 which isn't enabled on AB Jun 08 11:15:28 New news from stackoverflow: Add more packages before build Jun 08 11:59:09 There's a thing I need to learn better, but I have no idea what it's called. There's for example COMPATIBLE_MACHINE = "...", but then there's also CMOPATIBLE_MACHINE_foo = "..." Jun 08 11:59:53 s/CMOPATIBLE_MACHINE_foo/COMPATIBLE_MACHINE_foo/ Jun 08 12:00:29 What is the extra _foo qualifier called? Jun 08 12:00:46 jof: guess you are confused as you think of "foo" as a machine, right? Jun 08 12:01:42 Well.. Yes.. Jun 08 12:02:45 jof: foo can be a distro, a machine, an arch, or any of those: https://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Jun 08 12:02:47 But this kind of extra-thing is used in more places.. But I can't search for this thing because I don't know what it's called Jun 08 12:03:04 Aha! Jun 08 12:03:35 well, that's also a thing that keeps puzzling me Jun 08 12:03:38 Because I also have PREFERRED_PROVIDER_virtual/bootloader = "u-boot", using the same sort of syntax, but I just didn't know what this was called Jun 08 12:04:28 I already read the documentation, but I still don't know how to find out what gets targeted by thet suffixes in the different places Jun 08 12:04:30 jof: thats something completely differnt Jun 08 12:05:25 jof: PREFERRED_PROVIDER_${PN} is the structure behind your second question. Jun 08 12:05:28 sometimes it is machine, sometimes an operation (like append/prepend/delete), sometimes another target Jun 08 12:05:42 i mean, technically its always a variable with a specific name Jun 08 12:06:03 bugsbunny: and thats yet another one, the third possibility. thats just a simple operation Jun 08 12:06:29 bugsbunny: Those are actually explained in the section LetoThe2nd linked to Jun 08 12:07:18 see also https://docs.google.com/presentation/d/1uZ-4Df8tVGyJ_UHiFHUmdnxJy99H21mKMROUxt40SeY/edit?usp=sharing Jun 08 12:07:21 page 34 ff Jun 08 12:07:53 hmm, I have here something a predecessor of mine write, which is still challanging for me: "SRCREV_machine_pn-linux-yocto_men-intel ?= ..." Jun 08 12:08:50 LetoThe2nd: thanks for the link, I'll have a look Jun 08 12:12:28 LetoThe2nd: does the "SRCREV_machine_pn-linux-yocto_men-intel = ..." even make sense? Jun 08 12:12:59 bugsbunny: i guess it can, but depends heavily on the context Jun 08 12:13:05 to me it seems that there are a lot more implicit things one must know in order to understand such constructs Jun 08 12:14:17 LetoThe2nd: men-intel is a KMACHINE, linux-yocto is clear, also SRCREV, but how is that "_machine_pn" thing handled? is this something generic? Jun 08 12:15:40 LetoThe2nd: and also how dos yocto know how to interpret men-intel for an appropriated overwrite (what all of this stuff is in the end, as far as I understand) Jun 08 12:17:25 bugsbunny: i'm sorry i can't explain it too, RP or rburton probably can Jun 08 12:19:07 LetoThe2nd: ok, thanks for your help anyway :-) Jun 08 12:19:25 * bugsbunny would love to understand the philosophy behind that, because it seems like one key to the yocto world Jun 08 12:19:43 bugsbunny: actually, to the bitbake world to be precise :) Jun 08 12:20:01 but i can guarantee, that just knowing the 4 or 5 standard use cases is enough Jun 08 12:21:25 LetoThe2nd: right, bitbake rather than yocto, I definitely should read some more of its documentation ... Jun 08 12:22:38 LetoThe2nd: I'm pretty sure you're right with the few cases, otoh knowing the others too might open up new perspectives sometimes I'm into yocto deep enough Jun 08 12:23:30 of course, knowing more is always better. just wanted to make clear that this specific feature should not scare you away if you're not totally understanding it by heart. Jun 08 12:24:20 understood, and I'm not easily scared away ;-) Jun 08 13:34:32 LetoThe2nd, jof: ok, reading the bitbake manual helps a lot, but the most enlightening information was the section "### Config file processing" of meta/conf/bitbake.conf; that was the jigsaw piece I was missing, I'm a lot nearer to understand what's going on now :-) Jun 08 13:35:14 Hi Jun 08 13:35:36 I upgraded to rocko (from morty) and I'm getting a wierd error at do_rootfs: nothing provides /usr/bin/env needed by python-core-2.7.13-r1.cortexa7hf_neon (and several similar) Jun 08 13:36:26 I didn't patched python, busybox or such.. Looking in the busybox recipe nothing does provide /usr/bin/env. What am I doing wrong? Jun 08 13:37:58 https://thepasteb.in/p/8qhOADwqlKkf0 Jun 08 14:12:25 it seems that if I include coreutils in my image, it's fine, but this looks like a bug, I shouldn't need coreutils, busybox should provide env.. Jun 08 14:53:21 My application is using Linux network namespace. Is there a way I can give RDEPENDS to "CONFIG_NAMESPACE" of linux kernel Kconfig? For modules I can use kernel-module-xyz. But this build in feature of Linux kernel. Jun 08 14:54:17 parthi: no, rdepends is on packages Jun 08 14:55:06 rburton: Thanks. So it's not possible to enforce this? Jun 08 14:55:11 no Jun 08 14:55:15 * armpit does the "r" ind rdepend stand for "ross" ? Jun 08 14:55:24 armpit: yes Jun 08 16:24:12 Hi Everyone. I'm attempting to build QtWebEngine and make it use system OpenSSL instead of it's bundled BoringSSL. I have added a dependency to "nss", but the QtWebEngine configure log still says that it can't locate System NSS. Anyone have any ideas? Jun 08 16:24:30 nss is not OpenSSL Jun 08 16:25:20 did you adjust the Qt option to use OpenSSL? Jun 08 16:27:28 Which Qt Option is that? I already saw that QtWebEngine has a dependency on openssl Jun 08 16:29:16 I added a dependency on NSS because of this line in the Qt configure output: "System NSS not found, BoringSSL will be used." Jun 08 16:46:41 New news from stackoverflow: "Static declaration of ‘memfd_create’ follows non-static declaration" Error while building Linux image using Yocto Jun 08 16:47:31 just for the record jof, LetoThe2nd: I found the problem ... finally, and there was a difference in the configuration files ... of course ;-/ Jun 08 16:48:51 just for the record jof, LetoThe2nd: now I know for sure that the machine's kconf line better appears first, or otherwise other settings might get priority Jun 08 16:49:54 what a struggle, and for (nearly) nothing, guess that's called learning the hard way ... but otoh this knowledge I won't forget soon *bg* Jun 08 16:50:21 time for weekend for me, cu @all Jun 08 16:58:19 fray: I've added PACKAGECONFIG += openssl to an append file for qtbase, so we will see if the configuration finds it correctly now Jun 08 16:59:42 Hi all - I have a question about getting npm into my image. I have used the https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM (Non-Registry Workaround). Are some of you familiar with this option? Jun 08 17:44:13 Hi all - I have a question about getting npm into my image. I have used the https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM (Non-Registry Workaround). Are some of you familiar with this option? Jun 08 17:46:00 It is throwing this error, and wondering the best solution. ERROR: npm-1.0-r0 do_populate_sysroot: The recipe npm is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/user/Desktop/PIU_bb-layers.new/bb-layers/poky-krogoth-build/build/tmp/sysroots/piu/usr/lib/node_modules/npm/LICENSE Matched in manifest-piu-nodejs.populate_sysroot /home/user/Desktop/PIU_bb-l Jun 08 17:46:46 rogoth-build/build/tmp/sysroots/piu/usr/lib/node_modules/npm/package.json Matched in manifest-piu-nodejs.populate_sysroot Jun 08 17:48:13 mrk377: you might want to delete the license file or move it to different location Jun 08 17:48:57 you can achieve it with do_install_append () { rm -rf ${D}/location/of/LICENSE" Jun 08 17:56:56 Khem: I will try. Do you think I should delete the LICENSE and package.json from nodejs or npm? Jun 08 17:57:49 I should diff the package.json and examine the difference to be safe. Jun 08 19:27:26 nodejs I thing Jun 08 22:17:45 New news from stackoverflow: How to make /var/log symlink to a persistent storage in Yocto Rocko Jun 08 22:30:43 I need some help trying to see why "iw" package does not install on my RPI3 build. I see the package being built in ./tmp-glibc/work/raspberrypi3-oe-linux-gnueabi/rpi-basic-image/1.0-r0/rootfs/usr/sbin/ but when I flash the image I don't see iw. This is what I have to install iw IMAGE_INSTALL_append = " kernel-image kernel-devicetree kernel-modules linux-firmware-bcm43430 wpa-supplicant iw hostapd dnsmasq iptables fcgi php php-cl Jun 08 22:32:38 ikkysleepy: if its in the rootfs folder but isn't in the image then i suggest that you're not running the right image Jun 08 22:50:33 Thanks, looks like the build didn't generate a new image. Trying to see how I can rebuild the image Jun 09 01:27:18 ikkysleepy: you can add iw to IMAGE_INSTALL and then bitbake **** ENDING LOGGING AT Sat Jun 09 03:00:06 2018