**** BEGIN LOGGING AT Wed Feb 07 03:00:02 2018 Feb 07 08:04:57 RP: fyi. the u-boot issues I asked about the other day was due to yocto building with V=1. that causes the log files to appear inline in do_compile instead of as files. Feb 07 08:49:15 tasslehoff: ah, interesting. I didn't know it did that! Feb 07 09:30:37 New news from stackoverflow: Yocto recipe python whl package Feb 07 09:33:44 I have written a new recipe for my source and I am able to compile it using bitbake. I also able to find the corresponding ipk's generated. But the binaries (bins, so's) are not included in the final rootfs image. How should I add this to final rootfs? Feb 07 09:34:13 Should I need to use "IMAGE_INSTALL_append" in local.conf? Feb 07 09:34:38 parthi: yes Feb 07 09:35:05 mckoan: Is adding to "local.conf" is the only way? Feb 07 09:36:49 mckoan: will RDEPENDS packages will be added automatically to rootfs or I need to specify them as well in "IMAGE_INSTALL_append"? Feb 07 09:40:02 parthi: you can add it in loacl.conf or into your 'image-recipe.bb' if you have it Feb 07 09:40:26 parthi: the RDEPENDS are added automatically to rootfs Feb 07 09:46:16 mckoan: Thanks. Feb 07 09:53:06 how can one pass in SSH_AUTH_SOCK variable to a task that calls scp in a recipe? Feb 07 09:53:59 when I try to pass in through local.conf - like so: export SSH_AUTH_SOCK - i get a lot of complaints about taskhash mismatch Feb 07 09:54:29 that's understandable, except SSH_AUTH_SOCK is listed under BB_HASHCONFIG_WHITELIST Feb 07 10:00:44 New news from stackoverflow: Cannot build C project by Eclipse when two c sources are in the project Feb 07 10:30:51 New news from stackoverflow: install qcharts module to yocto sdk Feb 07 12:53:32 how to check multiple conditions in a recipe like [ if DISTRO_FEATURE contain A and IMAGE_FEATURE contain B, perform TASK] Feb 07 12:54:55 you can't check image features from a non-image recipe Feb 07 12:55:16 well you can but won't do what you expect Feb 07 12:57:23 rburton: IMAGE_FEATURE is a variable, we can check does it contain some value or not, Feb 07 12:57:48 are you checking it inside an image recipe though? Feb 07 12:58:56 rburton: yes, this recipe will be included in image recipe Feb 07 12:59:02 so the answer is no Feb 07 12:59:19 a recipe that generates packages will be built *once* for use by *all* images Feb 07 13:00:48 if if i'm building image-big and image-small and they both contain busybox, i can't control how busybox is configured from image-big and image-small. Feb 07 13:01:01 busybox will be built once, and then the resulting packages used to build both image-big and image-small Feb 07 13:01:34 during the build of busybox, asking what the value of IMAGE_FEATURES makes no sense if i'm did "bitbake image-big image-small" Feb 07 13:01:39 but I can control image feature through image-bit and image-small Feb 07 13:01:44 and both image-big and image-small change IMAGE_FEATURES Feb 07 13:03:30 zeddii zeddii_home: does building out-of-tree modules really need the whole of kernel-devsrc? Feb 07 13:34:09 rburton. it need headers + minimal Kbuild infrastructure. Feb 07 13:34:54 in previous build system(s), it was a stripped down setup. if you can run 'make modules_prepare', it is enough to build Feb 07 14:06:15 zeddii: so can we have a recipe that builds that instead of kernel-devsrc? (or do we have one) Feb 07 14:06:25 zeddii: devsrc is 600m and slow/huge Feb 07 14:09:02 rburton. I think so, I'll poke at it a bit today to understand the options a bit more. Feb 07 14:09:27 I'll use that bugzilla in my inbox as the reminder/trigger, even though that isn't exactly what it is about. Feb 07 14:09:45 we pull devsrc into a couple of images to test out of tree module building but obviously thats 600mb in images which are constantly at the edge of the 4gb limit for hddimg files Feb 07 14:10:06 another option is to forcibly not build hddimg for those Feb 07 14:10:22 (or both) Feb 07 14:10:47 ahah. yah. not optimal. we can do something about that. I have some scripts around that hand craft out of tree builds, I'll rummage around a bit and find them. Feb 07 14:11:33 as a guy who built "core-image-kernel-dev" for 2 kernel versions, 6 architectures and 2 c-libraries. I watched kernel-devsrc package more than a few times ;) :D Feb 07 14:11:47 what a time to be alive Feb 07 14:12:50 we can put a tesla in orbit, but i/o still inflicts pain. Feb 07 14:16:08 what's shareable between mulitple parallel `bitbake` invocations on the same host? downloads? sstate? both? Feb 07 14:17:04 both Feb 07 14:17:13 even more? Feb 07 14:17:26 e.g. tmp? deploy? Feb 07 14:17:33 god no Feb 07 14:17:40 hi, is there a way to stop bitbake from generating packages which have zero files inside? using opkg and am seeing too many empty -dev, -dbg and -doc packages being built. Feb 07 14:17:53 mcfrisk: ALLOW_EMPTY. default to 1 for -dev Feb 07 14:18:01 you shouldn't have empty -doc packages Feb 07 14:18:21 $ grep ALLOW_EMPTY * Feb 07 14:18:21 bitbake.conf:ALLOW_EMPTY_${PN}-dev = "1" Feb 07 14:18:23 bitbake.conf:ALLOW_EMPTY_${PN}-dbg = "1" Feb 07 14:19:21 rburton: so setting that to 0 would stop empty packages from being built? on jethro so maybe empty -doc are not disabled there. and seeing -locale packages too. Feb 07 14:20:03 jethro wasn't different afaik. setting it to 0 for -dev packages will break dependency chains if you do it globally Feb 07 14:20:30 unless you're paying per package you'll never know Feb 07 14:20:55 zeddii: good news: only failure with your kernel changes was lsb-sdk tripping over the 4gb limit Feb 07 14:21:26 rburton: so I cannot build two images simultaneously via seperate bitbake invocations? Feb 07 14:21:49 T_UNIX: you can build two images simulataneously with a single bitbake invocation in the same tmp Feb 07 14:21:59 you can't share tmp between multiple concurrant bitbakes Feb 07 14:22:17 rburton, well, that's not too bad then. I did queue a lot of builds, so I was quietly hoping it would go pretty well. Feb 07 14:23:38 rburton: okay, thanks. unfortunate. More than 50GB per individual job then... Feb 07 14:23:52 rburton: thanks, will try to reduce the amount of empty packages we build Feb 07 14:50:45 hey, should a systemd service restart itself after the package it was contained in upgrades itself via smart update? Feb 07 14:50:59 I’m seeing this with b2qt-launcher Feb 07 14:51:25 HavoK__: presumably that's what the recipe does Feb 07 14:51:45 i’m looking at the recipe and can’t see what might be triggering that. I wanted to disable it Feb 07 14:51:56 systemd.bbclass has bits in there for that Feb 07 14:55:25 ah thanks looks like i need to set SYSTEMD_AUTO_ENABLE to disable Feb 07 14:56:12 to use posix message queue do i need to set POSIX_MQUEUE=y and POSIX_MQUEUE_SYSCTL=y? my system uses sysvinit Feb 07 16:09:35 hey, I'm having some issues with yocto. It seems to me that the CFLAGS env variable should have existed and had a --sysroot flag, but that doesn't seem to exist for me? Feb 07 16:10:16 My recipe inherits from module, and is a kernel module, but in 'module.bbclass', the 'module_do_compile' step includes 'unset CFLAGS' before running the makefile Feb 07 16:19:44 sysroot is passed via CC, generally speaking, not CFLAGS Feb 07 16:20:17 kergoth: my CC env variable is just aarch64-poky-linux-cc -fuse-ld=bfd, no mention of sysroot Feb 07 16:20:28 CXX on the other hand includes a --sysroot argument Feb 07 16:25:43 kergoth: any idea what could make the CC variable not contain a --sysroot? Feb 07 17:01:00 part / --ondisk mmcblk0 --label primary --fstype=squashfs --fixed-size 500M --source rootfs --align 4096 Feb 07 17:01:45 I have the above entry in my wks file. So the final image includes all the partition similar to this. Feb 07 17:03:20 I wanted to select/use a specific image (signed rootfs). I have the signed rootfs built in tmp/deploy/images. How can I select the specific file or some generic option to instruct the wic to use signed rootfs? Feb 07 17:06:22 rburton: do we have issues with glibc 2.27 that are pending ? Feb 07 17:06:58 khem: aarch64 was failing? or was that binutils. Feb 07 17:07:02 maybe i should fire both at the ab Feb 07 17:07:28 Just two actual problems: Feb 07 17:07:28 - The non-gplv3 build failed as the make fix needs to be backported to meta-gplv2 Feb 07 17:07:30 - The eSDK selftests all failed with en_US.UTF-8 problems, the new glibc shouldn't be causing a problem with uninative so this is interesting, maybe the new one is behaving slightly differently. Should be easy to replicate. The same problem caused selftest to fail. Feb 07 17:07:35 meta-gplv2 needs fixing still Feb 07 17:09:27 the make fix is gpl3 so backporting that can only be done if author agrees Feb 07 17:10:03 aarch64 is due to binutils upgrade with glibc 2.26 I think Feb 07 17:10:15 but I will try to to reproduce here Feb 07 17:10:53 can you post the UTF errors ? Feb 07 17:13:49 khem: try to setup the eSDK and it says it can't find en_US.UTF-8 Feb 07 17:14:03 i don't *think* we'd need to build a new uninative Feb 07 17:17:55 rburton: we will need to, question is whether that would help that problem Feb 07 17:18:18 rburton: note that if you can reproduce, you can hack in a url to a test uninative Feb 07 17:18:30 i'll fire a esdk build tonight Feb 07 17:32:17 New news from stackoverflow: Yocto with Jethro 2.0 and meta-altera Feb 07 18:07:24 Does anyone know what layer provides kernel-module-nf-nat? Feb 07 18:08:16 it won't be a layer, it will be built/provided if the right option is turned on in your kernel configuration. Feb 07 18:09:53 Awesome! Any guess as to the kernel option? Might I be able to find it under bitbake linux-yocto -c menuconfig? Feb 07 18:11:11 CONFIG_NF_NAT=m Feb 07 18:11:46 My thanks zeddi! Feb 07 18:11:58 it's one of the options we turn on for docker in meta-virt: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-kernel/linux/linux-yocto/docker.cfg Feb 07 18:12:08 so that's a bbappend reference on how to enable it if you need to do it that way. Feb 07 18:12:27 * zeddii becomes zeddii_home after transit in snow. Feb 07 18:13:51 Ok, I'm using the meta-virtualization layer, I must be missing something. Thanks, at least I know where to look! Feb 07 18:35:36 in a function I'm removing a value from a variable, but on getting environment [bitbake -e recipe-name] value is still there, I added this task to be execute before do_compile, is it should be visible in environment (some thing wrong with function) or will update before do_compile ? Feb 07 19:03:34 you might want to do it in a do_compile_prepend Feb 07 19:03:53 metadata may not be visible across functions Feb 07 20:37:05 can we perform bitbake expression in shell functions? Feb 07 20:42:16 xtron: yes but they'll be evaluated before the shell sees it Feb 07 20:42:31 ie bitbake expressions are expanded then passed to the shell Feb 07 20:43:22 in a shell function I'm trying to use IMAGE_FEATURES_remove, but bitbake says variable not found. so how to include it? Feb 07 20:44:03 _remove is an operator, not a variable name Feb 07 20:44:11 it removes something from IMAGE_FEATURES when it's expanded Feb 07 20:44:20 so there's no way to look at that Feb 07 20:45:58 yes, but this expression should be executed Feb 07 20:46:08 that doesn't really make sense Feb 07 20:46:40 the only way to use anything from bitbake in shell is ${@}, which is evaluated at expansion time, not run time, and it's python, not bitbake file format Feb 07 20:48:58 can we use _remove in python function? Feb 07 20:52:09 kergoth: ^ Feb 07 21:07:58 why would you want to? sounds pretty pointless. if you just want to remove something from a variable, you can do that programmatically any number of ways if your'e in python code, without using _remove Feb 07 22:26:02 Dear all, Feb 07 22:26:17 Is there any way to force wic to behave like dd ? Feb 07 22:26:38 I mean to just copy the binary data to proper offsets ? Feb 07 22:26:57 I do see that now only part and bootloader commands are supported Feb 08 01:22:08 When trying to build chromium, receive message: NOTE: Runtime target 'chromium' is unbuildable, removing... Feb 08 01:22:20 What is wrong? Feb 08 01:54:49 learningc: this means some distro policy or dependency not being met **** ENDING LOGGING AT Thu Feb 08 03:00:01 2018