**** BEGIN LOGGING AT Mon Aug 27 03:00:00 2018 Aug 27 06:11:08 hello Aug 27 07:52:38 Hey, I'm trying to make a bitbake recipe for libwebrtc (from webrtc.org). WebRTC doesn't ship releases as tarballs, and don't just use regular git repos; downloading their code involves first checking out their "depot_tools", then using binaries in that to download the actual webrtc source. Aug 27 07:53:25 Making my own do_fetch and do_unpack targets is easy enough, but how do I make sure bitbake knows that the fetch or unpacks have already been executed such that it doesn't try to do it again every time I compile? Aug 27 09:09:26 Hello! Has anyone got a good reference for shrinking down rootfs? Aug 27 09:16:59 sbrkic: did you look https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-a-tiny-system ? Aug 27 11:23:14 RP: luxoft wants to bring 'yocto devday' to berlin (all expenses paid etc.), is that feasible? who is actually the instructor(s)? Aug 27 12:03:13 Hi guys! Does anyone know how I can boot into initramfs from an efi shell? Aug 27 12:03:39 I get the cpio.gz and the bzimage but I think that I pass the parameters wrong into the efi shell Aug 27 12:04:55 kanavin: some are LF trainers with the addition of people like David Reyna Aug 27 12:41:02 Can yocto produce let's say a core-image-minimal-initramfs.img file ?? Aug 27 12:46:10 RP: how can I get in touch with them? is info@yoctoproject.org the right channel? Aug 27 12:47:00 RP: the question is arranging this kind of thing here in berlin https://www.yoctoproject.org/yocto-project-dev-day-europe-2018/ Aug 27 13:22:45 RP: nevermind, I'll ask David and Andrea :) Aug 27 13:42:59 kanavin: right, they're the right people to talk to Aug 27 14:30:44 armpit: Would you mind picking up 409c8a326: "swig: Remove superfluous python dependency" for sumo please? Aug 27 14:34:45 RP: Well, I've made progress on the BBserver error with persist_data. It appears that occassionally, the updateConfig command takes a long time (~40 seconds) Aug 27 14:38:47 JPEW, done Aug 27 14:38:58 armpit: Thank you Aug 27 15:03:36 Hi all, I have some trouble deploying opencv on a ZCU102 board ( Xilinx aarch64) and I would like to know if someone here has already done that ? Everything seems ok on Yocto (.bbappend on 3.1 opencv recipe and enable some modules , core, imgproc, ...) but I can't deploy features2d module ... any advice ? :) Aug 27 15:08:25 RP did you see the selftest failures on master ? Aug 27 15:11:10 armpit: its a holiday here today so I've not really been working Aug 27 15:11:33 JPEW: progress is good. config updating should never be that slow :( Aug 27 15:11:42 sounds like something is blocking :( Aug 27 15:12:55 RP, apologies.. talk to you tomorrow Aug 27 15:18:50 armpit: its ok, I am setting up a build server in the background... Aug 27 15:59:56 Is there a variable like THISDIR that would point to a bbclass file's parent directory? Aug 27 16:01:12 generally 'FILE' points to whatever file is currently being parsed. using := to immediately evaluate it will ensure it points to this file rather than the recipe. but i'm not sure if it's set for bbclasses specifically Aug 27 16:01:27 worth a check, though. TESTFILE := "${FILE}" in the bbclass, check bitbake -e Aug 27 16:05:23 kergoth: nice. That's a good starting point. Aug 27 16:05:43 (it worked; I need to get the basedir of ${FILE}) Aug 27 16:06:55 ${@os.path.dirname(d.getVar('TESTFILE'))} Aug 27 16:07:26 that's actually what THISDIR and FILE_DIRNAME *are*, so you can probably just force an immediate expansion on THISDIR or FILE_DIRNAME Aug 27 16:07:28 right Aug 27 16:07:29 rather than FILE directly Aug 27 16:07:32 now that we know it's set right Aug 27 16:09:33 I misread the output. It pulled the bbappend file where the class was inherited, which is close enough (same for FILE_DIRNAME) Aug 27 16:09:43 ahh Aug 27 16:09:51 absolute worst case you could just re-find the bbclass in BBPATH Aug 27 16:10:05 i.e. ${@bb.utils.which('classes/foo.bbclass', d.getVar('BBPATH'))} or whatever Aug 27 16:10:10 * kergoth shrugs Aug 27 16:10:30 i swear we had a variable for the current class.. hmm Aug 27 16:11:37 oh that's right, FILE is only set for the main recipe and appends, but not for anything included or inherited Aug 27 16:11:39 hrmph Aug 27 16:12:12 and looks like the class only gets added to __inherit_cache, which is internal and shouldn't be used elsewhere Aug 27 16:16:14 Going along with one of your other suggestions, this resolves correctly as long as the layer's layout is /recipes-/recipe/recipe.bb: CLASS_LAYERDIR := "${@os.path.normpath('${FILE_DIRNAME}/../..')}" Aug 27 16:16:19 Thanks for the suggestions :) Aug 27 16:16:27 np Aug 27 17:58:45 Does anyone have experience having both an initramfs and wic partitions? I'm ending up with a dependency loop when I attempt to build an image if INITRAMFS_IMAGE is also set. Aug 27 18:01:07 Perhaps related to this is trying to use the kernel-fitimage class _without_ the INITRAMFS_IMAGE variable being set. I end up with "Wrong Image Format for bootm command" from the u-boot SPL when loading the "fitImage" file. Aug 27 18:13:10 New news from stackoverflow: Bitbake - layer version? Aug 27 18:19:12 Taking a SWAG at it, I probably need a way to limit which image type wic operates against since that seems to be what is causing the circular dependency; wic doesn't need to execute against the RAM FS. Aug 27 20:20:51 Been searching for a while on this one... Is there a way to prevent IMAGE_FSTYPES from applying to the image specified in INITRAMFS_IMAGE? Aug 27 20:22:25 For example if you make an image definition that extends core-image by specifying INITRAMFS_IMAGE of core-image-minimal and IMAGE_FSTYPES of "wic wic.xz", you end up with a circular dependency since wic's rules are also being applied to core-image-minimal. Aug 27 20:22:26 tgoodwin: set it in your image recipe and not local.conf/distro config ;) Aug 27 20:24:24 bluelightning: I have it set in my machine def. Aug 27 20:24:27 same problem? Aug 27 20:24:37 well yeah because that's still global Aug 27 20:25:31 FYI though some of our example initramfs recipes set IMAGE_FSTYPES to "${INITRAMFS_FSTYPES}" to avoid this situation Aug 27 20:25:46 you could also do that Aug 27 20:26:30 my strong advice though is don't extend image recipes, have your own that are fully defined - by all means copy and modify an existing recipe, but you need not refer to the original Aug 27 20:26:50 I had IMAGE_FSTYPES set to "wic wic.xz ${INITRAMFS_FSTYPES}" earlier thinking that was the right way to go since I need an initrd that hands off to the real file system. Aug 27 20:27:31 That's when I started running into the circular dep. problem. Aug 27 20:27:36 why build your initramfs image using wic though? it should be a trivial image Aug 27 20:27:46 I'm not trying to build the initramfs with wic. Aug 27 20:28:12 That's the problem I'm trying to solve -- get the wic image class to stop adding do_image_wic to the INITRAMFS_IMAGE Aug 27 20:29:03 ok perhaps I am not following exactly what you have set... ultimately your initramfs image needs to not have those in its IMAGE_FSTYPES - either you don't set it globally, or you ensure your initramfs image overrides the value to something reasonable Aug 27 20:30:26 Ah, I think I understand what you're saying now. I was mistakenly putting my image fstypes as part of the machine definition since from a logical perspective, the hardware is defining the partition scheme it needs. Aug 27 20:31:07 Tomorrow I'll try flipping this around. Glad you were on :) Aug 27 20:31:09 Thanks! Aug 27 20:36:51 tgoodwin: no problem Aug 27 21:09:40 khem: Hey Khem did you know that compiler-rt-native isnt working on your clang layer? Aug 27 21:09:58 khem: I noticed that yesterday, and I was in the process of trying to see what the issue was but then my computer died Aug 27 21:10:30 khem: but I did see that you dont have the rt packageconfig enabled for native so I thought you may already know this and disabled it on purpose Aug 27 23:39:40 Hello, I added meta-openembedded to poky, and got this error: Could not include required file recipes-devtools/python/python-pbr.inc, did find any solution through google, does anyone here knows? thanks Aug 28 00:08:21 derek007: you need to be updating poky layer Aug 28 00:08:57 there has been handskake between meta-openembedded and oe-core w.r.t this file it move to oe-core few weeks back Aug 28 00:16:48 khem, thanks, yes, I do see that file in oe-core, do you mean update poky to latest version? Aug 28 00:17:48 yes poky in your case Aug 28 00:22:44 khem, got it, Thanks! **** ENDING LOGGING AT Tue Aug 28 03:00:02 2018