**** BEGIN LOGGING AT Fri May 11 03:00:04 2018 May 11 08:35:44 New news from stackoverflow: Creating Yocto Mender for Raspberrypi 3 May 11 09:30:56 I'm trying to add x86 mkfs.ubifs to our SDK, but can't seem to get it right. Trying various versions of TOOLCHAIN_HOST_TASK += "mtd-utils" May 11 12:14:47 hello, what is the most appropriate way to add the build time to /etc/issue in base-files (Yocto Rocko)? May 11 12:15:22 apparently writing DISTRO_VERSION = "0.2-Beta ${DATE}" in distro configuration is not enough May 11 12:15:54 something strange is being done in base-files recipe: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/base-files/base-files_3.0.14.bb?h=master May 11 12:16:05 distro_version_nodate=${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot').replace('${DATE}','')} May 11 12:16:15 why is DATE being removed? May 11 12:18:31 it is a conscious decision that when DISTRO_VERSION is set no DATE string will be used in /ect/issue ? May 11 12:18:33 eduardas_m: ROOTFS_POSTPROCESS_COMMAND I'd say May 11 12:20:18 ernstp: thank you for the reply... I kinda know I can do that, but what I really wanted is to do it via distro configuration related variables May 11 12:20:35 did something like that to get BUILD_ID in /etc/os-release May 11 12:23:49 eduardas_m: perhaps they're trying to get reproducible builds... ? May 11 12:27:15 when using kernel-yocto.bbclass, is it expected for the defconfig to be applied AFTER .scc and cfg fragments? May 11 12:29:54 is it a good or bad practice to inherit conf/distro/poky.conf in own distro description? May 11 12:33:24 I have a simple Makefile based recipe. It typically works, but from time to time it fails in do_configure with make complaining that there is no rule for target clean. That is correct, such rule was forgotten. Now I fixed the makefile and want to test that it works. However, I have not found a sequence that do_configure would call make clean May 11 12:34:12 eduardas_m: good question. I asked something similar on the mailing list some weeks ago, but I never got a response :( May 11 12:36:31 eduardas_m: if you notice almost every custom distro is inheriting from poky May 11 12:36:50 eduardas_m: IMHO is a best practice May 11 12:39:21 but if you do it, you need to set the DISTRO name in your own distro's config file. And yocto-check-layer script has a test that will fail when you do it. Not sure what is correct there May 11 12:49:36 ernstp: I ended up doing a bbappend to base-files recipe in my layer and modifying the do_install_basefilesissue to not exclude DATE May 11 12:49:55 that way the final issue file gets included in the .ipk package May 11 12:50:16 would not expect that to be the case for ROOTFS_POSTPROCESS_COMMAND May 11 12:50:40 because then .ipk would include the contents of the file before postprocessing is done May 11 12:51:04 at least that's what I expect... have not really checked May 11 12:51:29 won't you get an old .ipk even if you rebuild new software tomorrow? May 11 12:52:25 ernstp: good point, will check now May 11 12:52:43 eduardas_m: vardepsexclude, sstate bla bla :-) May 11 13:23:52 rburton: I sent a v2 for gdb should fix the musl/x86 case https://patchwork.openembedded.org/patch/150668/ May 11 13:24:03 please use that v2 May 11 13:42:52 [bump] when using kernel-yocto.bbclass, is it expected for the defconfig to be applied AFTER .scc and cfg fragments? May 11 13:51:52 khem: we're seeing ldconfig segfault on arm in poky-lsb (so security-flags) builds May 11 13:52:19 sigsegv in _dl_relocate_static_pie() May 11 13:55:35 khem: just forwarded a screenshot rp took of gdb, if you have any thoughts May 11 14:12:44 khem, hi there May 11 14:12:55 I'll test gcc8 later May 11 14:14:20 as for kexec-tools, the warnings are originated by bad sources, not klibc :) May 11 14:14:35 I'll send the patches to the ML May 11 14:32:04 hello, can I ask a quick question wrt licenses and yocto? May 11 14:33:53 go ahead and ask May 11 14:34:50 I found a bug in yocto, I'm trying to sort it out May 11 14:35:07 the license "blacklist" feature works only for source packages, not wrt binary packages May 11 14:35:47 I mean, if I blacklist GPLv3, and add into IMAGE_INSTALL_append="gnutls-openssl", it works May 11 14:36:05 this is because gnutls has a GPLv2+ license, but LICENSE_${PN}-openssl=GPLv3+ May 11 14:36:31 so, I would say that only licenses of source packages are taken in consideration May 11 14:37:29 yes, that is expected. If you blacklist a license, the source output (package) for that type shouldn't be generated.. May 11 14:37:41 so it sounds like a bug in gnutls-openssl to have generated that package to me May 11 14:37:45 a simple grep seems to indicate that gnutls is probably the only package were binaries have different licenses May 11 14:38:25 ya, but any package can.. It should be easy to add a QA check that the package being built does not have a stated license in the exclusion list.. May 11 14:38:34 then either warn or error based on standard QA semantics May 11 14:38:41 fray, so this is a bug? May 11 14:39:08 I think it is -- but exactly where it's a bug is, I'm not sure.. May 11 14:39:18 either the recipe author needs to know not to do that -- which is a big dubious.. May 11 14:39:32 or we need an package sanity check that tells the author -- builder 'don't do this' May 11 14:39:47 it's the insane.bbclass where this would go.. May 11 14:39:53 we got gnutls-extra.so installed into our target, and we have the GPL3 blacklisted, this can become a serious issue May 11 14:40:03 yes, and it's certainly not intended May 11 14:40:05 (legal issue, so even worse :o) May 11 14:40:17 maybe I'll open a bug later today May 11 14:40:29 at least we should warn people that binaries might have different licenses May 11 14:40:42 I looked at deploy/licenses, and only source licenses are collected there May 11 14:40:49 so it might be not even trivial to implement May 11 14:41:10 well the end user is already responsible for verying licenses.. the tooling can only help guide them -- but in this cause the guidance is wrong and should be corrected either by warning them/erroring on them.. or? May 11 14:41:20 implementation is trivial, I think May 11 14:42:06 yep :) better keep track May 11 14:43:05 the existing license check code is in base.bbclass. May 11 14:43:34 either it needs to be expanded to check the package licenses as well (which I don't think is the right way) or insane.bbclass needs a similar chunk of code to check what was just built May 11 14:44:40 I was just looking and there -is- code in base.bbclass that is checking the package licenses, or should be May 11 14:45:58 I'm using daisy at work (sigh) May 11 14:46:07 but I'm trying to reproduce with rocko right now May 11 14:46:40 I'm looking at master.. May 11 14:47:40 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/base.bbclass#n505 May 11 14:48:11 starts there.. gets the incompatible_license list.. then excludes cross-compilation and host tools.. then starts checking if the package being worked on has an incompatible license.. May 11 14:48:32 lines around 561 and beyond are when should be checking the individual packages as well.. May 11 14:48:51 sorry I mean 537 May 11 14:49:49 d.setVar('LICENSE_EXCLUSION-' + mlprefix + pkg, 1) May 11 14:49:55 I don't know where that bit of code is used though May 11 15:14:13 Is in-tree defconfig still relatively untested? May 11 16:15:24 fray, in case, can I quote the conversation in the bug report? May 11 16:17:11 there are a number of cases where only certain binary packages of a recipe use an incompmatible license, it's designed to allow those to build but not emit the incompatible packages May 11 16:17:20 RP, stable/morty-next passed ab May 11 16:17:23 as fray says, sounds l like a but in gnutls recipe May 11 16:21:55 armpit: rp is away today and all weekend, so if you want him to do something about that send a mail to him May 11 16:22:27 rburton_, thanks May 11 17:48:10 I have a strange issue on current sumo: x86-64 archs get an ARCH=x86 kernel build May 11 17:49:06 it seems linked to TUNE_ARCH -> TARGET_ARCH -> ARCH chain being broken by TARGET_ARCH unexport May 11 17:50:26 (hm, forget this hypothesis, commenting out unexport does not help) May 11 17:50:40 so I'm still very puzzled May 11 17:52:40 I may have missed something, ARCH=x86 may be normal May 11 18:03:21 for the kernel, yah, it is. May 11 19:43:07 My real problem is getting the kernel to use just x86_64_defconfig. If I just specify KCONFIG_DEFCONFIR="x86_64_defconfig" instead of a defconfig in SRC_URI it seems the recipe goes for kernel-metadata, which is not what I think I requested. If I copy x86_64_defconfig as a defconfig file shipped with my recipe, I still get an i386 kernel built (possibly because of lack of CONFIG_64BIT=y in that file, which surprises me but eh) May 11 19:44:00 I can add CONFIG_64BIT=y in a separate .cfg file, but unsurprisingly enough it does not have the same effect as "make x86_64_defconfig" has when run by hand May 11 19:44:06 what am I missing ? May 11 19:59:16 hi guys, i'm trying to build an image with IMAGE_FSTYPES = "tar.bz2", but image.bbclass creates by default ${PN}:do_image_ext4 dependency. So the tar.bz2 type does not creates ext4 task. There is a way to build tar.bz2 images without build ext4? May 11 20:22:38 Hi guys, i'm trying to build an image with IMAGE_FSTYPES = "tar.bz2" but image.bbclass depends by default on ${PN}:do_image_ext4 task May 11 20:23:43 but tar.bz2 does not creates this task and I do not want to build two types of image. There is a simple way to do this? May 11 22:24:35 khem, I was told to let you know gcc 8 build fails. you want bugz opened? May 12 00:48:36 armpit: I think Ross sent email too May 12 00:49:04 armpit: I will check what went wrong, it must be something common **** ENDING LOGGING AT Sat May 12 03:00:03 2018