**** BEGIN LOGGING AT Wed Oct 18 03:00:01 2017 **** BEGIN LOGGING AT Wed Oct 18 07:36:31 2017 Oct 18 10:25:01 for ROOTFS_SIZE calculation, shouldn't "du -ks" be "du --apparent-size -ks"? otherwise on compressed btrfs filesystem it would give total size after compression... Oct 18 11:32:48 hi, luajit is injecting -m32 ... how can I prevent it from doing that when building luajit-native ? it breaks efl-native :( tmp/sysroots/x86_64-linux/usr/lib/libluajit-5.1.a(lj_err.o): relocation R_X86_64_32S against `.rodata' can ... Oct 18 11:46:51 merging `[oe] [meta-oe][PATCH] luajit: create developer symlinks` seems to have fixed it Oct 18 11:46:55 Hey everyone. I would like to use a bbappend file depending on which image i am buildung, is it possible to somehow make an if else? Oct 18 11:47:47 styler2go: you could control that using "FEATURES" I suppose Oct 18 11:48:07 Can you elaborate a little more? Oct 18 11:49:10 one image requesting one feature, the other image requesting another... and then the bbappend doing one thing or the other if this or that DISTRO_FEATURE are eanbled Oct 18 11:49:18 but I'm a noob Oct 18 11:50:59 i don't believe the build of a given package has any knowledge about what image you intentend to build at the end Oct 18 11:51:27 and thinking about that, the DISTRO_FEATURE approach wouldn't work either Oct 18 11:52:58 that can only work having different conf/local.conf Oct 18 11:53:12 and making the image require it. not setting it Oct 18 11:53:59 because the package you are extending doesn't have a way of distinguishing how do you want it built Oct 18 11:55:16 you CAN otoh declare a new package ${PN}-thatway on your ${PN}_%.bbappend and make one image RDEPEND on ${PN} and the other on ${PN}-thatway Oct 18 11:55:33 mnemoc: we've just had relatively similar topic in #yocto. the classic way would be to refactor the recipe into an inc, and then use two different names that the imges can select Oct 18 11:56:08 you basically have to do it through the dependency mechanism, as there is no way to pass information from a recipe to the outside. Oct 18 11:56:20 that makes sense Oct 18 11:57:42 I think i found a way.. kind of like if [ -n "${@bb.utils.contains() ]; Oct 18 11:57:48 inside the do_install_append() Oct 18 13:13:39 How can i do a python function call inside do_install_append in a bb file? Oct 18 13:28:15 good afternoon Oct 18 13:41:43 https://github.com/openembedded/bitbake/blob/master/lib/bb/utils.py#L967 I am trying to find out where this function is being declared, any idea? searching for "def getVar(" results in functions with many more vars Oct 18 16:20:21 rburton, I see you are to blame for waf.bbclass Oct 18 16:20:33 Crofton|work: you're welcome to it Oct 18 16:20:37 any idea why it might deice to install stuff in lib64 insteas of lib? Oct 18 16:20:39 lol Oct 18 16:20:43 god no Oct 18 16:20:51 damn Oct 18 16:21:05 last time i saw that it was because the build system was looking at the host distro type and changing the libdir Oct 18 16:21:13 yeah Oct 18 16:21:15 "oh, fedora, i'll use $prefix/lib64 Oct 18 16:21:16 I fear this Oct 18 16:21:25 my waf skills are poor Oct 18 16:21:43 I fear this detection is in waf itself Oct 18 16:21:51 i suspect not Oct 18 16:21:59 grep upstream project for lib64 Oct 18 16:23:36 had this problem a few weeks ago, can't recall what project it was though Oct 18 16:23:42 iirc it was cmake so can't be the same one Oct 18 16:23:50 if multilib.conf is included ti will use lib64 -- unless it's a packaging bug Oct 18 16:36:24 hi, I'm trying to re-add EFL ... Oct 18 16:36:41 but I need to call ./tmp/sysroots-components/x86_64/wayland-native/usr/bin/wayland-scanner Oct 18 16:37:09 what magic variable should I use to construct that path? Oct 18 16:56:44 adding the dependecy on wayland-native added it to my PATH :) Oct 18 19:15:10 mnemoc: you need a patch like meta/recipes-graphics/xorg-xserver/xserver-xorg/0002-configure.ac-Fix-wayland-scanner-and-protocols-locat.patch Oct 18 19:15:20 mnemoc: then you need to depend on wayland-native Oct 18 20:49:13 Does anyone have ideas on how to debug this? Dependency loop #6 found Oct 18 20:50:00 * cbrake tries bitbake -D Oct 18 20:52:12 cbrake: it should dump the cycles at the end Oct 18 20:52:35 cbrake: I have seen this generally when doing initramfs bundles Oct 18 20:52:50 khem: yeah, exactly -- trying to bundle initramfs with kernel Oct 18 20:53:23 khem: it dumped the cycles, but not obvious yet what is going on Oct 18 20:53:44 * khem cleans his magic glass Oct 18 20:54:29 cbrake: whats your INITRAMFS_IMAGE Oct 18 20:55:01 usually it should be different image then the one you are building finally Oct 18 20:56:49 khem: yeah, I tried an initramfs-image from another project where it works, and it still fails Oct 18 20:57:26 khem: I think stripped the IMAGE_INSTALL down to nothing, still fails Oct 18 20:57:37 bitbake virtual/kernel Oct 18 20:57:39 does that work ? Oct 18 20:57:40 khem: so thinking it must be something with the kernel Oct 18 20:57:45 khem: no, that is what is failing Oct 18 20:57:52 OK Oct 18 20:59:03 cbrake: you need IMAGE_FSTYPES = " ${INITRAMFS_FSTYPES}" in the image recipe Oct 18 20:59:36 khem: thanks, trying ... Oct 18 21:06:44 khem, hi, I am now playing with kernel Makefile, adding -fno-store-merging after the -OS but still no luck :/ Oct 18 21:07:59 ant_home: ok, the discussion you forwarded seems to indicate that it should have helped in avoiding gcc bug Oct 18 21:08:06 if you had same issue Oct 18 21:09:03 khem: still fails -- the initramfs-image recipe had IMAGE_FSTYPES = " ${INITRAMFS_FSTYPES}". Trying to understand the loop log stuff next ... Oct 18 21:09:44 well, the STRD instruction is not used afais Oct 18 21:10:18 wait, silly me... Oct 18 21:10:34 strd lowercase is used :) Oct 18 21:11:06 khem: ahh, its still trying to build ext4 and sdcard images -- that may be the issue Oct 18 21:11:20 cbrake: check your local.conf Oct 18 21:11:35 you might have it added via some other conf metadata Oct 18 21:11:46 bitbake -e might help as well Oct 18 21:19:55 khem: this got it going: IMAGE_FSTYPES_var-som-mx6 = "${INITRAMFS_FSTYPES}" Oct 18 21:20:05 khem: thanks for the help Oct 18 22:23:58 cbrake: yeah ok **** ENDING LOGGING AT Thu Oct 19 03:00:01 2017