Re: [yocto] [warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8
Hi Mike, On Wed, Nov 20, 2019 at 09:06:08PM +1300, Paul Eggleton wrote: > Hi Mike > > On Wednesday, 20 November 2019 9:00:10 PM NZDT Mike Looijmans wrote: > > I ran into this issue yesterday, and this patch solves the compilation on > > warrior. However, it's a patch for Qt itself, and not for OE. > > > > Is there already a warrior patch in the making, or should I submit one? > > Quentin sent one yesterday (with the same subject). If you could give it a > try > and confirm it fixes the failure that would be great. > Yes, I was too excited to send the patch and forgot I needed to send a patch for meta-qt4 containing the patch for the qt4 sources. *facepalm* You should be able to get the patch for meta-qt4 from: https://lists.yoctoproject.org/pipermail/yocto/2019-November/047405.html Let us know if the patch applies nicely and fixes your issue (it should), Thanks, Quentin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [warrior] [meta-qt4] recipes-qt4: qt4-embedded: fix build on GCC v8
At least since gcc v8, source code with asm volatile won't compile
anymore.
The volatile qualifier anyway is a no-op since asm blocks are implicitly
volatile as written in the documentation[1].
Let's get rid of this redundant qualifier so we can build with newer
GCCs.
The resulting error message when building for warrior is the following
(note that there is a bunch of them):
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error:
expected '(' before 'volatile'
asm volatile (
^~~~
(
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error:
expected unqualified-id before string constant
".text\n"
^
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error:
expected ')' before string constant
asm volatile (
~^
)
".text\n"
~
[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
Signed-off-by: Quentin Schulz
---
Please ignore previous mail, I only sent a patch for the sources of qt4-embedded
and not a patch for meta-qt4.
...iptcore-JITStubs.cpp-allow-builds-of.patch | 262 ++
recipes-qt4/qt4/qt4-embedded.inc | 1 +
2 files changed, 263 insertions(+)
create mode 100644
recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch
diff --git
a/recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch
b/recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch
new file mode 100644
index 000..12f955f
--- /dev/null
+++
b/recipes-qt4/qt4/qt4-4.8.7/0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch
@@ -0,0 +1,262 @@
+From 6318ac5a0771fdf074bdfb929903c660fa1fa672 Mon Sep 17 00:00:00 2001
+From: Quentin Schulz
+Date: Fri, 15 Nov 2019 13:57:12 +0100
+Subject: [PATCH] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of
+ JavaScriptCore with gcc v8
+
+At least since gcc v8, source code with asm volatile won't compile
+anymore.
+
+The volatile qualifier anyway is a no-op since asm blocks are implicitly
+volatile as written in the documentation[1].
+
+Let's get rid of this redundant qualifier so we can build with newer
+GCCs.
+
+The resulting error message is the following (note that there is a
+bunch of them):
+../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error:
expected '(' before 'volatile'
+asm volatile (
+ ^~~~
+ (
+../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error:
expected unqualified-id before string constant
+".text\n"
+^
+../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error:
expected ')' before string constant
+asm volatile (
+ ~^
+ )
+".text\n"
+~
+
+[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
+
+Upstream-Status: Inappropriate
+Signed-off-by: Quentin Schulz
+---
+ .../JavaScriptCore/jit/JITStubs.cpp | 48 +--
+ 1 file changed, 24 insertions(+), 24 deletions(-)
+
+diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
+index d8027ff2..dcead6d0 100644
+--- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
+@@ -116,7 +116,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) ==
0x3c, JITStackFrame_s
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58,
JITStackFrame_callFrame_offset_matches_ctiTrampoline);
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50,
JITStackFrame_code_offset_matches_ctiTrampoline);
+
+-asm volatile (
++asm (
+ ".text\n"
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBOL(ctiTrampoline) "\n"
+@@ -138,7 +138,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
+ HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
+ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+@@ -154,7 +154,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
+ "ret" "\n"
+ );
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
+ HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
+ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
+@@ -179,7 +179,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) ==
0x48, JITStackFrame_s
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90,
JITStackFrame_callFrame_offset_matches_ctiTrampoline);
+ COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80,
JITStackFrame_code_offset_matches_ctiTrampoline);
+
+-asm volatile (
++asm (
+ ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
+ HIDE_SYMBO
[yocto] [meta-qt4] [BUG] qt4-embedded broken on warrior for qemux86-64
Hi all, Just to let you know that qt4-embedded on qemux86-64 in warrior is broken with the following message during the do_compile task: | make[1]: Leaving directory '/tmp/poky/build/workspace/sources/qt4-embedded/tools' | cd translations/ && make -e -f Makefile | make[1]: Entering directory '/tmp/poky/build/workspace/sources/qt4-embedded/translations' | lrelease assistant_cs.ts | /bin/sh: 1: /tmp/poky/build/tmp/work/i586-poky-linux/qt4-embedded/4.8.7-r0/recipe-sysroot-native/usr/bin/lrelease4: not found | lrelease assistant_da.ts | /bin/sh: 1: /tmp/poky/build/tmp/work/i586-poky-linux/qt4-embedded/4.8.7-r0/recipe-sysroot-native/usr/bin/lrelease4: not found | Makefile:582: recipe for target 'assistant_cs.qm' failed | make[1]: *** [assistant_cs.qm] Error 127 | make[1]: *** Waiting for unfinished jobs | Makefile:585: recipe for target 'assistant_da.qm' failed | make[1]: *** [assistant_da.qm] Error 127 | lrelease assistant_de.ts | /bin/sh: 1: /tmp/poky/build/tmp/work/i586-poky-linux/qt4-embedded/4.8.7-r0/recipe-sysroot-native/usr/bin/lrelease4: not found | Makefile:588: recipe for target 'assistant_de.qm' failed | make[1]: *** [assistant_de.qm] Error 127 | make[1]: Leaving directory '/tmp/poky/build/workspace/sources/qt4-embedded/translations' | Makefile:892: recipe for target 'sub-translations-make_default-ordered' failed | make: *** [sub-translations-make_default-ordered] Error 2 meta-qt4: 144ae1b3892ad38d212c69186e429c874357af4a poky: d0f73121551dc98f6924cd77952bf9ebf5ef3dd7 Building on Ubuntu 18.04.3. Only those two layers, source oe-init-buil-denv and change MACHINE to qemux86-64 in conf/local.conf. I doubt it has any impact but I also have INHERIT += "rm_work" in conf/local.conf. usr/bin/lrelease4 is in recipe-sysroot-native for other machines and it is provided by qt4-native. There is no qt4-native WORKDIR available in BUILDDIR for qemux86-64 AFAICT. This is kind of a bug report, I am not working with this machine or any x86-64 machine. I was just trying to see if basic different architectures for another bug (asm volatile, patch sent earlier today) were impacted and would build with the fix I was working on. Thanks for maintaining meta-qt4, much appreciated that we still can use it with warrior. Best regards, Quentin -- StreamUnlimited Engineering GmbH High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria Fax: +43 1 667 20 02 4401 quentin.sch...@streamunlimited.com, www.streamunlimited.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8
At least since gcc v8, source code with asm volatile won't compile
anymore.
The volatile qualifier anyway is a no-op since asm blocks are implicitly
volatile as written in the documentation[1].
Let's get rid of this redundant qualifier so we can build with newer
GCCs.
The resulting error message is the following (note that there is a
bunch of them):
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error:
expected '(' before 'volatile'
asm volatile (
^~~~
(
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error:
expected unqualified-id before string constant
".text\n"
^
../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error:
expected ')' before string constant
asm volatile (
~^
)
".text\n"
~
[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
Upstream-Status: Inappropriate
Signed-off-by: Quentin Schulz
---
.../JavaScriptCore/jit/JITStubs.cpp | 48 +--
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
index d8027ff2..dcead6d0 100644
--- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
+++ b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
@@ -116,7 +116,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX) ==
0x3c, JITStackFrame_s
COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58,
JITStackFrame_callFrame_offset_matches_ctiTrampoline);
COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50,
JITStackFrame_code_offset_matches_ctiTrampoline);
-asm volatile (
+asm (
".text\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
@@ -138,7 +138,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"ret" "\n"
);
-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -154,7 +154,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"ret" "\n"
);
-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
@@ -179,7 +179,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX) ==
0x48, JITStackFrame_s
COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90,
JITStackFrame_callFrame_offset_matches_ctiTrampoline);
COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80,
JITStackFrame_code_offset_matches_ctiTrampoline);
-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
SYMBOL_STRING(ctiTrampoline) ":" "\n"
@@ -206,7 +206,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"ret" "\n"
);
-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
@@ -222,7 +222,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"ret" "\n"
);
-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
@@ -242,7 +242,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
#error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
#endif
-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
@@ -269,7 +269,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
"bx lr" "\n"
);
-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
@@ -287,7 +287,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
"bx lr" "\n"
);
-asm volatile (
+asm (
".text" "\n"
".align 2" "\n"
".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
@@ -305,7 +305,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
#elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)
-asm volatile (
+asm (
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
HIDE_SYMBOL(ctiTrampoline) "\n"
SYMBOL_STRING(ctiTrampoline) ":" "\n"
@@ -323,7 +323,7
Re: [yocto] Conditional include in image recipe.
Hi Mauro, On Sat, Aug 24, 2019 at 12:19:08PM +0200, Mauro Ziliani wrote: > Hi all > > I working on a image recipe. > > If I include the layer meta-raspberrypi layer I'd like to include > recipes-code/images/rpi-basic-image-bb. > > While if i not include meta-raspberrypi layer I don't include > rpi-basic-image. > Or you can just safely ignore if the file does not exist (for Yocto, which most likely means that the layer is not included). You have two "include" mechanisms for non-class files: * require * include "Require" requires the file to be there and fails otherwise while "include" tries to include the file, if it's not there, it continues. https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#include-directive https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#require-inclusion Quentin -- StreamUnlimited Engineering GmbH High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria quentin.sch...@streamunlimited.com, www.streamunlimited.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Issue with INCOMPATIBLE_LICENSE
FYI,
On Fri, May 31, 2019 at 11:31:43AM +0200, Quentin Schulz wrote:
> Hi all,
>
> We're in the middle of an upgrade to Thud 2.6.2. While doing so, we
> blindly updated all upstream layers we use and we found out (during
> integration phase, no need to send lawyers :) ) that even though we have
> GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built.
>
> conf/local.conf
> INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
>
> https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb
> LICENSE = "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 )"
>
> My understanding of the above LICENSE is that even though I have GPLv3
> blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the
> package got built. I'm not really happy with Qt doing that (no warning,
> no LICENSE_FLAGS). Quick question unrelated to the actual important
> question:
>
> Would it be possible (theoritically, I know you've nothing to do with
> maintenance of meta-qt5; also not tested, just "pseudo-code") to have
> something like:
> python() {
> if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'):
> d.setVar("LICENSE_FLAGS", "commercial")
> }
>
> so if we are blacklisting GPLv3, we have to add commercial_qtbase to
> LICENSE_FLAGS_WHITELIST to be able to build it.
>
+ LICENSE_FLAGS = "${@ "commercial" if
(incompatible_license_contains('GPL-3.0', True, False, d) or \
+ incompatible_license_contains('The-Qt-Company-GPL-Exception-1.0',
True, False, d) or \
+ (incompatible_license_contains('GPL-2.0+', True, False, d) and \
+ incompatible_license_contains('LGPL-3.0', True, False, d))) \
+ else ''}"
For qtbase_git.bb seems to work fine.
LICENSE is 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
)
So it is commercial if
GPL-3.0 | The-Qt-Company-GPL-Exception-1.0 | (GPL-2.0+ & LGPL-3.0) is
False.
> So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as
> well and qtbase is still building. How so?
>
> For me, it results in the following:
> LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 |
> not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which in the end looks like:
> LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which is basically:
> LICENSE = "not-compat"
>
> Is there an error in this simplification?
> Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto?
> Have I missed something?
> Is there something actually buggy in the INCOMPATIBLE_LICENSE
> implementation?
>
> Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as
> I wanted to exclude license "aliases" not being supported by
> INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what
> is said in the mega-manual).
>
> I want to be sure to not be able to build qt >= 5.7, we're never too far
> from an unfortunate upgrade or people in the company not knowing we
> cannot use qt >= 5.7.
>
FYI, a patch was sent regarding this issue:
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283266.html
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Issue with INCOMPATIBLE_LICENSE
Hi all,
On Fri, May 31, 2019 at 11:31:43AM +0200, Quentin Schulz wrote:
> Hi all,
>
> We're in the middle of an upgrade to Thud 2.6.2. While doing so, we
> blindly updated all upstream layers we use and we found out (during
> integration phase, no need to send lawyers :) ) that even though we have
> GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built.
>
> conf/local.conf
> INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
>
> https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb
> LICENSE = "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 )"
>
> My understanding of the above LICENSE is that even though I have GPLv3
> blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the
> package got built. I'm not really happy with Qt doing that (no warning,
> no LICENSE_FLAGS). Quick question unrelated to the actual important
> question:
>
> Would it be possible (theoritically, I know you've nothing to do with
> maintenance of meta-qt5; also not tested, just "pseudo-code") to have
> something like:
> python() {
> if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'):
> d.setVar("LICENSE_FLAGS", "commercial")
> }
>
> so if we are blacklisting GPLv3, we have to add commercial_qtbase to
> LICENSE_FLAGS_WHITELIST to be able to build it.
>
> So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as
> well and qtbase is still building. How so?
>
> For me, it results in the following:
> LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 |
> not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which in the end looks like:
> LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which is basically:
> LICENSE = "not-compat"
>
> Is there an error in this simplification?
> Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto?
> Have I missed something?
> Is there something actually buggy in the INCOMPATIBLE_LICENSE
> implementation?
>
> Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as
> I wanted to exclude license "aliases" not being supported by
> INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what
> is said in the mega-manual).
>
> I want to be sure to not be able to build qt >= 5.7, we're never too far
> from an unfortunate upgrade or people in the company not knowing we
> cannot use qt >= 5.7.
>
It's actually a bit worse than I expected.
If I create a simple baz recipe with LICENSE = "FooLicense" and have
INCOMPATIBLE_LICENSE = "FooLicense" in conf/local.conf, `bitbake baz`
will NOT complain, and will be built.
Now, my understanding is that INCOMPATIBLE_LICENSE is passed[1] as an
argument to expand_wildcard_licenses[2] which returns a list of licenses
which have to be part of either SPDXLICENSEMAP or
SRC_DISTRIBUTE_LICENSES.
However, in the case of qtbase, The-Qt-Company-Commercial is nowhere to
be found in those variables.
Why do we filter INCOMPATIBLE_LICENSE to have only SPDX licenses or
their aliases (my understanding of respectively SRC_DISTRIBUTE_LICENSES
and SPDXLICENSEMAP)?
Is this actually expected?
If it is, can we please actually document it?
Also, how should one add a custom license? I could find this[3]
discussion on the ML but nothing "official". Can we document it? I
wouldn't know today what to do without having to read the source code
and the licensing is critical to most companies.
Let me know how and if I can help,
Thanks,
Quentin
[1]
https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/base.bbclass#n524
[2]
https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/license.bbclass#n265
[3] https://lists.yoctoproject.org/pipermail/yocto/2013-June/014366.html
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issue with INCOMPATIBLE_LICENSE
Hi all,
We're in the middle of an upgrade to Thud 2.6.2. While doing so, we
blindly updated all upstream layers we use and we found out (during
integration phase, no need to send lawyers :) ) that even though we have
GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built.
conf/local.conf
INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb
LICENSE = "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
)"
My understanding of the above LICENSE is that even though I have GPLv3
blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the
package got built. I'm not really happy with Qt doing that (no warning,
no LICENSE_FLAGS). Quick question unrelated to the actual important
question:
Would it be possible (theoritically, I know you've nothing to do with
maintenance of meta-qt5; also not tested, just "pseudo-code") to have
something like:
python() {
if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'):
d.setVar("LICENSE_FLAGS", "commercial")
}
so if we are blacklisting GPLv3, we have to add commercial_qtbase to
LICENSE_FLAGS_WHITELIST to be able to build it.
So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as
well and qtbase is still building. How so?
For me, it results in the following:
LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 |
not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
which in the end looks like:
LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
which is basically:
LICENSE = "not-compat"
Is there an error in this simplification?
Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto?
Have I missed something?
Is there something actually buggy in the INCOMPATIBLE_LICENSE
implementation?
Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as
I wanted to exclude license "aliases" not being supported by
INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what
is said in the mega-manual).
I want to be sure to not be able to build qt >= 5.7, we're never too far
from an unfortunate upgrade or people in the company not knowing we
cannot use qt >= 5.7.
Thanks,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
