**** BEGIN LOGGING AT Fri May 24 03:00:35 2019 May 24 07:16:46 LetoThe2nd, I made swupdate work with A/B copy + partitioning scheme to my liking :) May 24 07:16:58 also with systemd May 24 07:51:37 New news from stackoverflow: Increasing HugeTLB from 256MB to 512MB with Yocto SDK2.0 May 24 10:21:16 did somebody see a good example how to install additional (secondary) cross-gcc and use it to build a couple of recipes? I have two different CPUs and need to build two archs together into the same image May 24 10:45:57 Dvorkin, meta/lib/oeqa/selftest/cases/multiconfig.py May 24 11:54:23 New news from stackoverflow: Add same files to multiple PACKAGES May 24 12:10:05 kanavin_, good reference, thanks. as I can see, I can build several images using this technique. Or the one image from two parts of different archs? May 24 12:24:28 New news from stackoverflow: Linker cannot find boost::thread references May 24 13:18:08 Dvorkin, if you want several images, you can simply set up two build directories using two different MACHINE targets, multiconfig is more about combining different targets within one build May 24 14:22:46 hello everyone, I've a question related to licenses, is it the right place to ask or should I go to #oe ro any other chan? May 24 14:24:05 the question being related to the inner working of LICENSES and INCOMPATIBLE_LICENSES, nothing that needs to involve a lawyer :) May 24 14:37:32 Ask here, but depending on who's online you might not get an answer. If so you can try the mailing list May 24 14:38:21 OK, I didn't know which medium to favor May 24 14:39:27 Basically, qt5.6(<=) is GPLv2 compliant but qt5.7(>=) is a combination of licenses, among which basically you have GPLv3 | QT_Commercial. May 24 14:40:04 We don't want to build qt5.7(>=). We're using meta-qt5 at an old release which has qt5.6. May 24 14:40:46 It just happened that we mistakenly updated meta-qt5 with a qt5.11 which is GPLv3 | Commercial in development environment only, so nothing to worry about May 24 14:41:22 BUT. We had INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+" in place. May 24 14:41:31 qschulz, I hope you do realize that you are introducing a mountain of technical debt May 24 14:41:44 talk to your management about buying a commercial license May 24 14:42:07 I tried with the SPDX values as well (so INCOMPATIBLE_LICENSE = "GPL-3.0 GPL-3.0+ LGPL-3.0 LGPL-3.0+" May 24 14:43:02 kanavin_: we know. We use very little of Qt (like VERY little). We discussed purchasing, way too expensive (like WAY TOO MUCH). May 24 14:43:54 anyway. Qt5 license is this horrendous string: GFDL-1.3 & BSD & ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 | The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | The-Qt-Company-Commercial ) May 24 14:44:31 So, with my basic binary operator understanding, I'd say that also need to blacklist The-Qt-Company-Commercial. Tried it, didn't work. May 24 14:46:28 So, question. How to make sure we never have a qt >= 5.7? (And this most likely expand to why is INCOMPATIBLE_LICENSE not working ?) May 24 14:46:40 expand/extends? May 24 15:12:44 how did you accidentally upgraded to 5.11? do you change layer branches accidentally? As long as you stay on krogoth branch of meta-qt5 you will be fine at least for Qt May 24 15:13:55 qschulz: but be aware that Qt 5.6 won't get openssl-1.1 compatibility, so you need to replace openssl from oe-core with openssl10 and use that until you're ready to upgrade Qt (well maybe you use little enough to disable ssl support in qtbase and you're fine in this aspect) May 24 15:14:57 we offered to backport all changes in upstream Qt 5.6 (to prevent tainting the license) and it was rejected by upstream (I can give you ticket link if you need) May 24 15:35:01 JaMa: i'm interested in those patches as we're currently implementing it May 24 15:35:51 JaMa: we're upgrading our layers and we updated all the layers without looking much (still WIP so didn't think too much about it) May 24 15:36:05 qschulz: are you aware that you cannot backport them from newer Qt because of license? May 24 15:36:49 JaMa: wait, I thought you backported this to 5.6. Is it based on the 5.7+ implementation? May 24 15:37:08 well, "backported" I guess that answers it May 24 15:37:14 not interested obviously :) May 24 15:37:37 no, we offered to do that in upstream and they rejected our help (because they want people to upgrade to newer version instead) May 24 15:37:47 JaMa: which makes perfect sense May 24 15:40:00 we're not using much of qt for openssl so we're working on calling everything directly basically (i.e. without qt's wrapper, without knowing whtat qt's doing in this wrapper) . No worries on license compliance for this. May 24 15:40:23 https://lists.qt-project.org/pipermail/development/2018-November/034353.html https://lists.qt-project.org/pipermail/development/2018-November/034354.html https://lists.qt-project.org/pipermail/development/2018-November/034358.html https://bugreports.qt.io/browse/QTBUG-71623 May 24 15:41:00 thanks but as you said, those patches are most likely not gplv2 compliant so can't even send them to the integrator May 24 15:41:35 (we found some patches on the internet as well but licenses make everything tricky) May 24 15:42:07 anyway, I'm more interesting into knowing why INCOMPATIBLE_LICENSE is not working for qt (and other recipes?) or what I did so wrong it didn't work :) May 24 15:45:22 btw: openssl-1.1 support won't be in the next LTS Qt 5.9 as well (at least not from upstream, there are various patches which backport it, because it's no longer license issue), https://lists.qt-project.org/pipermail/releasing/2019-March/002601.html you need to upgrade all the way to 5.12 May 24 15:46:12 not sure why INCOMPATIBLE_LICENSE didn't work, we aren't using INCOMPATIBLE_LICENSE, because we need "mixed" env anyway, so we have other tools to prevent contamination with incompatible licenses May 24 16:06:11 we use incompatible license, but will use WHITELIST in certain cases, and then have a couple image sanity checks to freak out if anything ends up there that shouldn't be there. we allow a whitelisted gplv3 gdbserver in our development image for example, but not in our production image May 24 16:16:06 so the sanity checks then control only the explicitly whitelisted packages from being pulled into the image? May 24 16:18:00 I guess you have also static libs disabled to prevent someone accidentally pulling some v2 blob into production image binary? May 24 16:20:01 we also use do_packagedata[postfuncs] to check for the shlibs providers, where we need to prevent also GPLv2 libraries to be linked against from our code, with explicit whitelist for some of them May 24 17:05:10 is there way to get a list of all packages actually installed into an image, not just those in IMAGE_INSTALL everything that is installed implicitly (dependencies) too? May 24 17:08:23 From a running system I normally use 'opkg list'. I'm not sure how to do it with bitbake itself though. May 24 17:13:41 tmp/deploy/images/[machine]/[image]/[].rootfs.manifest ? May 24 17:14:46 tmp/deploy/images/[machine]/[image]-[machine].rootfs.manifest ? May 24 17:15:54 qschulz: thank you very much May 24 17:23:36 milloni: Please note the manifest doesn't include the packages that are deployed like the kernel or the bootloader May 24 17:25:26 justanotherboy: you meant are *not* deployed? May 24 17:27:53 milloni: you would need a kernel to run you system, but it is not installed in the rootfs so it won't be listed there May 24 17:28:03 milloni: Check bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10733 for more information May 24 17:28:03 Bug 10733: normal, Medium, Future, unassigned, NEW , image license not copied to rootfs May 24 20:56:14 RP:when using opkg backend I see opkg tests fail all the time. If I manually start a http server in ipk/ folder it works May 24 23:28:08 khem, can you open a bug.. RP is off this weekend **** ENDING LOGGING AT Sat May 25 02:59:58 2019