**** BEGIN LOGGING AT Mon Oct 01 03:00:03 2018 Oct 01 03:17:23 New news from stackoverflow: Yocto build succeeds, but warning about missing RDEPENDS Oct 01 03:47:28 New news from stackoverflow: Aptina camera interface with gstreamer [on hold] Oct 01 07:01:24 gm, question: built a m68k kernel 4.18 by yocto, i get a 900 KB binary. Building the kernel by simple make in the mainline source tree with same defconfig i get 1,5 MB. How can yocto produce half of the size ? Oct 01 07:32:12 angelo_ts: which layer is providing your BSP ? Oct 01 07:45:28 i just created one, there is no m68k support in yocto, so i created the architecture too Oct 01 07:46:50 angelo_ts: are you using the same toolchain? Oct 01 07:47:58 mckoan, no, yocto uses a more recent 6.xx, in the other case i was using 5.1 . Also i was not stripping Oct 01 07:49:28 mckoan, ok, still cannot have the smaller yocto kernel running btw, trying to understand the reason. If i can get it running, then Yocto forever since it produces half size :) Oct 01 07:51:08 angelo_ts: so it looks like you have found the answer Oct 01 07:51:47 angelo_ts: what about trying to create a meta-toolchain and then use it instead of yours Oct 01 07:52:24 mckoan, yes, will try Oct 01 07:52:37 thanks Oct 01 07:54:12 angelo_ts: YW, let me know if it works Oct 01 07:54:39 ok Oct 01 12:17:20 RP: what about image-artifact-names.bbclass to be consistent with kernel-artifact-names.bbclass ? Oct 01 12:19:18 JaMa: I was actually thinking this could make more sense as a .conf file. Not something we've done much of but it would seem to make a lot of sense. In particular it enforces variables not code Oct 01 12:20:02 JaMa: we have too many bbclass files really and the structure is messy and unclear :( Oct 01 12:26:24 RP: ok, I've noticed the .conf just after sending my reply and wanted to confirm that it wasn't a typo Oct 01 12:28:33 I'll hardcode .rootfs in few more places to unblock 2.6 for us, then will add imagevars.conf for 2.7 together with #12937 Oct 01 12:32:49 JaMa: sounds good thanks. I like the .conf idea as I think it will scale better than what we've been doing so far Oct 01 14:14:35 I ran a cleansstate on my image recipe (uses wic) which now will no longer run since mkfs.ext4 isn't being installed into the native sysroot (but mkfs.vfat, for example, is). Has anyone seen that occur? Oct 01 14:15:39 tgoodwin: I usualy avoid carefully to run cleansstate on a whole image Oct 01 14:16:42 mckoan: this is hasn't caused issues for weeks...I basically walked through the door this morning and my build environment was broken. Do you have any other recommendations? Oct 01 14:19:32 tgoodwin: no clues, I'd rebuild the image deleting sstate and tmp Oct 01 14:24:22 mckoan: alright, thanks Oct 01 15:55:27 mkcoan: unfortunately a complete rebuild didn't fix it. Oct 01 16:02:34 Weird. I've been using "WKS_FILE_DEPENDS += ..." in this recipe for a while and it has worked fine. Now that line is overwriting the dependencies completely; that was the problem. Switching it to an _append resolved it. Oct 01 16:24:27 Is there a way to use something like "include ${@bb.utils.contains(..." in a machine definition against a variable post-expansion? Oct 01 16:30:08 tgoodwin: maybe did you update the layers? Oct 01 16:30:45 tgoodwin: however _append is the best practice instead of += Oct 01 16:31:07 mckoan: No, I don't think so. Oct 01 16:32:00 mckoan: it's funny. I ran one more build and booted it on the device before I left last week. I came in and ran the clean before heading into the next feature which was completely unrelated to that variable and the build broke. Oct 01 16:32:45 I'm now having the same problem where checking IMAGE_FEATURES from a machine is no longer being evaluated once it was expanded (or ...at least last week it appeared to behave that way; it must have been something else messed up in the environment). Oct 01 16:36:34 I feel like I've seen a way to do this before using one of the bb utilities like process, cooker, etc. that will allow you to re-evaluate a recipe after a variable is expanded. Oct 01 19:05:47 hi, need to call mkimage to generate kernel uImage, where is the proper place to invoke mkimage ? Oct 01 19:25:54 Is it not possible to specify systemd with PACKAGECONFIG set to include cryptsetup? It comes back with circular dependencies. Oct 01 19:36:44 angelo_ts: Are you interested in running mkimage outside of the Yocto build system, or would you like yocto to create the uimage for you? Oct 01 19:58:46 robbawebba, would like yocto to create it for me Oct 01 20:10:28 another curious thing is that linux.bin generated from yocto is a gzip compressed file Oct 01 20:27:49 Hi folks. Is there anybody using iwd - internet wireless deamon with yocto, together with connman? Oct 01 20:31:19 FrostEyes_P1: is it feature complete yet? Oct 01 20:32:31 there isn't a iwd recipe afaik Oct 01 20:32:40 writing the recipe will be trivial Oct 01 20:32:51 presumably connman can just use iwd instead of wpa_supplicant Oct 01 20:32:57 so theoretically, it should just work :) Oct 01 20:33:25 Was thinking on using iwd instead of wpa_supplicant. Though as you write - no recipy yet. Oct 01 20:34:32 rburton: :) it would be nice if some had tried it, and knows "you should not do it yet" Oct 01 20:49:04 angelo_ts: I haven't done this before, but I would recommend checking out the KERNEL_IMAGETYPE variable, which defaults to zImage Oct 01 20:49:44 https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-KERNEL_IMAGETYPE Oct 01 20:51:45 FrostEyes_P1: if you want to try iwd, https://pastebin.com/YqRGmd57 is the start of a recipe :) Oct 01 20:56:39 (it fetches at least) Oct 01 21:00:43 rburton: cool. Though seems to be an issue with Connman and iwd and scanning for network. So will go with wpa_supplicant untill iwd is more complete. **** ENDING LOGGING AT Tue Oct 02 03:00:01 2018