Re: [OE-core] [PATCH] python3: add a tr-tr locale for test_locale ptest
On Thu, 2019-04-11 at 19:12 -0700, Khem Raj wrote:
> On Thu, Apr 11, 2019 at 9:00 AM Alexander Kanavin <
> alex.kana...@gmail.com> wrote:
> > With this change, the ptests do not fail anymore,
> > except for the three failures caused by the 5.0 kernel regression:
> >
> > - test_ssl and test_httplib lock up, and are skipped
> > (there is a separate patch for it)
> >
> > - test_asyncio fails but does not lock up
> >
> > Signed-off-by: Alexander Kanavin
> > ---
> > meta/recipes-devtools/python/python3_3.7.2.bb | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/python/python3_3.7.2.bb
> > b/meta/recipes-devtools/python/python3_3.7.2.bb
> > index 28f128d488b..71a6c103166 100644
> > --- a/meta/recipes-devtools/python/python3_3.7.2.bb
> > +++ b/meta/recipes-devtools/python/python3_3.7.2.bb
> > @@ -284,7 +284,7 @@ FILES_${PN}-misc =
> > "${libdir}/python${PYTHON_MAJMIN} ${libdir}/python${PYTHON_MA
> > PACKAGES += "${PN}-man"
> > FILES_${PN}-man = "${datadir}/man"
> >
> > -RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2
> > libgcc tzdata-europe coreutils sed"
> > +RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2
> > libgcc tzdata-europe coreutils sed locale-base-tr-tr.iso-8859-9"
>
> While this is a test package i must mention that locale packaged are
> specific to Glibc so it would be better to append it with libc
> override
We had build failures and I queued a fixup in warrior-next to do just
that!
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-fitimage: support RISC-V
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..2820ff9689 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -10,6 +10,8 @@ python __anonymous () {
uarch = d.getVar("UBOOT_ARCH")
if uarch == "arm64":
replacementtype = "Image"
+elif uarch == "riscv":
+replacementtype = "Image"
elif uarch == "mips":
replacementtype = "vmlinuz.bin"
elif uarch == "x86":
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] nettle: fix ptest failure
From: Mingli Yu
Remove dlopen-test.patch which originally used
to fix the test dlopen-test, but autually the
patch didn't resolve the issue as dlopen-test.patch
supposes the file /usr/lib/libnettle.so exists.
Instead deploy ${D}${PTEST_PATH}/libnettle.so to
fix the dlopen-test failure.
Update the initialization for the salt to fix
below Segmentation fault and also nettle-pbkdf2-test
failure.
# echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt
[65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip 7f3332256998 sp
7fff60d44410 error 4 in libnettle.so.6.5[7f3332244000+1d00]
[65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d 41 5c 41 5d
41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9 68 ff f
Segmentation fault
Signed-off-by: Mingli Yu
---
...kdf2.c-change-the-initialization-for-salt.patch | 39 ++
.../nettle/nettle-3.4.1/dlopen-test.patch | 20 ---
meta/recipes-support/nettle/nettle_3.4.1.bb| 9 ++---
3 files changed, 44 insertions(+), 24 deletions(-)
create mode 100644
meta/recipes-support/nettle/nettle-3.4.1/0001-nettle-pbkdf2.c-change-the-initialization-for-salt.patch
delete mode 100644 meta/recipes-support/nettle/nettle-3.4.1/dlopen-test.patch
diff --git
a/meta/recipes-support/nettle/nettle-3.4.1/0001-nettle-pbkdf2.c-change-the-initialization-for-salt.patch
b/meta/recipes-support/nettle/nettle-3.4.1/0001-nettle-pbkdf2.c-change-the-initialization-for-salt.patch
new file mode 100644
index 000..713823e
--- /dev/null
+++
b/meta/recipes-support/nettle/nettle-3.4.1/0001-nettle-pbkdf2.c-change-the-initialization-for-salt.patch
@@ -0,0 +1,39 @@
+From 7510ee2877368464ecce7de515ce056e08c75245 Mon Sep 17 00:00:00 2001
+From: Mingli Yu
+Date: Fri, 12 Apr 2019 10:30:14 +0800
+Subject: [PATCH] nettle-pbkdf2.c: change the initialization for salt
+
+use malloc and strncpy altogether to replace
+strdup for salt initialization to fix below
+Segmentation fault:
+ # echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt
+ [65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip 7f3332256998
sp 7fff60d44410 error 4 in libnettle.so.6.5[7f3332244000+1d00]
+ [65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d 41 5c 41 5d
41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9 68 ff f
+ Segmentation fault
+
+Upstream-Status:
Submitted[http://lists.lysator.liu.se/pipermail/nettle-bugs/2019/007467.html]
+
+Signed-off-by: Mingli Yu
+---
+ tools/nettle-pbkdf2.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/tools/nettle-pbkdf2.c b/tools/nettle-pbkdf2.c
+index 1f0a301..000acd3 100644
+--- a/tools/nettle-pbkdf2.c
b/tools/nettle-pbkdf2.c
+@@ -141,7 +141,10 @@ main (int argc, char **argv)
+ return EXIT_FAILURE;
+ }
+
+- salt = strdup (argv[0]);
++ salt = malloc (strlen(argv[0]) + 1);
++ if (! salt)
++ die ("Failed to allocate memory for salt\n");
++ strncpy(salt, argv[0], sizeof(salt) - 1);
+ salt_length = strlen(argv[0]);
+
+ if (hex_salt)
+--
+2.7.4
+
diff --git a/meta/recipes-support/nettle/nettle-3.4.1/dlopen-test.patch
b/meta/recipes-support/nettle/nettle-3.4.1/dlopen-test.patch
deleted file mode 100644
index c4f0b7e..000
--- a/meta/recipes-support/nettle/nettle-3.4.1/dlopen-test.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Replace relative path of libnettle.so with absolute path so the test
-program can find it.
-Relative paths are not suitable, as the folder strucure for ptest
-is different from the one expected by the nettle testsuite.
-
-Upstream-Status: Inappropriate [embedded specific]
-
-Signed-off-by: Juro Bystricky
-
a/testsuite/dlopen-test.c 2016-10-01 00:28:38.0 -0700
-+++ b/testsuite/dlopen-test.c 2017-10-13 11:08:57.227572860 -0700
-@@ -9,7 +9,7 @@
- main (int argc UNUSED, char **argv UNUSED)
- {
- #if HAVE_LIBDL
-- void *handle = dlopen ("../libnettle.so", RTLD_NOW);
-+ void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
- int (*get_version)(void);
- if (!handle)
- {
diff --git a/meta/recipes-support/nettle/nettle_3.4.1.bb
b/meta/recipes-support/nettle/nettle_3.4.1.bb
index dd49c30..612e058 100644
--- a/meta/recipes-support/nettle/nettle_3.4.1.bb
+++ b/meta/recipes-support/nettle/nettle_3.4.1.bb
@@ -14,12 +14,9 @@ SRC_URI = "${GNU_MIRROR}/${BPN}/${BP}.tar.gz \
file://Add-target-to-only-build-tests-not-run-them.patch \
file://run-ptest \
file://check-header-files-of-openssl-only-if-enable_.patch \
+
file://0001-nettle-pbkdf2.c-change-the-initialization-for-salt.patch \
"
-SRC_URI_append_class-target = "\
-file://dlopen-test.patch \
-"
-
SRC_URI[md5sum] = "9bdebb0e2f638d3b9d91f7fc264b70c1"
SRC_URI[sha256sum] =
"f941cf1535cd5d1819be5ccae5babef01f6db611f9b5a777bae9c7604b8a92ad"
@@ -47,6 +44,10 @@ do_install_ptest() {
# tools can be found in PATH, not in ../tools/
sed -i -e 's|../tools/||' ${D}${PTEST_PATH}/
Re: [OE-core] [PATCH] python3: add a tr-tr locale for test_locale ptest
On Thu, Apr 11, 2019 at 9:00 AM Alexander Kanavin
wrote:
> With this change, the ptests do not fail anymore,
> except for the three failures caused by the 5.0 kernel regression:
>
> - test_ssl and test_httplib lock up, and are skipped
> (there is a separate patch for it)
>
> - test_asyncio fails but does not lock up
>
> Signed-off-by: Alexander Kanavin
> ---
> meta/recipes-devtools/python/python3_3.7.2.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/python/python3_3.7.2.bb
> b/meta/recipes-devtools/python/python3_3.7.2.bb
> index 28f128d488b..71a6c103166 100644
> --- a/meta/recipes-devtools/python/python3_3.7.2.bb
> +++ b/meta/recipes-devtools/python/python3_3.7.2.bb
> @@ -284,7 +284,7 @@ FILES_${PN}-misc = "${libdir}/python${PYTHON_MAJMIN}
> ${libdir}/python${PYTHON_MA
> PACKAGES += "${PN}-man"
> FILES_${PN}-man = "${datadir}/man"
>
> -RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2 libgcc
> tzdata-europe coreutils sed"
> +RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2 libgcc
> tzdata-europe coreutils sed locale-base-tr-tr.iso-8859-9"
While this is a test package i must mention that locale packaged are
specific to Glibc so it would be better to append it with libc override
>
> RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk',
> 'tk', '', d)}"
> RDEPENDS_${PN}-dev = ""
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/1] runqemu: do not check return code of tput
The subprocess.run was replaced by subprocess.check_call because
of compatibility support down to python 3.4. But we really don't
care about whether that command succeeds. Some user reports that
in some tmux environment, this command fails and gives some
unpleasant traceback output. So we use 'call' instead of 'check_call'
to avoid such problem.
Signed-off-by: Chen Qi
---
scripts/runqemu | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index c0e569c..a4fc606 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1329,7 +1329,8 @@ def main():
logger.info("SIGTERM received")
os.kill(config.qemupid, signal.SIGTERM)
config.cleanup()
-subprocess.check_call(["tput", "smam"])
+# Deliberately ignore the return code of 'tput smam'.
+subprocess.call(["tput", "smam"])
signal.signal(signal.SIGTERM, sigterm_handler)
config.check_args()
@@ -1351,7 +1352,8 @@ def main():
return 1
finally:
config.cleanup()
-subprocess.check_call(["tput", "smam"])
+# Deliberately ignore the return code of 'tput smam'.
+subprocess.call(["tput", "smam"])
if __name__ == "__main__":
sys.exit(main())
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/1] runqemu: do not check return code of tput
Changes in V2: * Add comments in runqemu script to make clear that we are deliberately ignoring the return code. The following changes since commit 9f7092416c40a96d9567bde99475de15a30e4989: insane.bbclass: Trigger unrecognzed configure option for meson (2019-04-11 21:15:57 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/qemu-tput http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/qemu-tput Chen Qi (1): runqemu: do not check return code of tput scripts/runqemu | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] gcc-cross-canadian: Make baremetal specific code generic
baremetal override is not valid for cross-canadian anymore
therefore use the TARGET_OS overrides
Fixes
e.g. https://github.com/riscv/meta-riscv/issues/117
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index e7c08d3a61..807e47e0ee 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -159,10 +159,9 @@ SYSTEMLIBS = "${target_base_libdir}/"
SYSTEMLIBS1 = "${target_libdir}/"
EXTRA_OECONF += "--enable-poison-system-directories"
-
-EXTRA_OECONF_append_libc-baremetal = " --without-headers"
-EXTRA_OECONF_remove_libc-baremetal = "--with-sysroot=/not/exist"
-EXTRA_OECONF_remove_libc-baremetal =
"--with-build-sysroot=${STAGING_DIR_TARGET}"
-
+EXTRA_OECONF_remove_elf = "--with-sysroot=/not/exist"
+EXTRA_OECONF_remove_eabi = "--with-sysroot=/not/exist"
+EXTRA_OECONF_append_elf = "--without-headers --with-newlib"
+EXTRA_OECONF_append_eabi = "--without-headers --with-newlib"
# gcc 4.7 needs -isystem
export ARCH_FLAGS_FOR_TARGET = "--sysroot=${STAGING_DIR_TARGET}
-isystem=${target_includedir}"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e2fsprogs: Skip slow ptest tests
The slow tests run unreliably with our current setup/infrsstructure/timeouts. There are only five slow ones and having the other ~250 run reliably without timeouts is the priority right now. We can revisit the slow tests at some later date if wanted. Signed-off-by: Richard Purdie --- meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest b/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest index ef10b08bc86..c97c0377e9c 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/run-ptest @@ -1,7 +1,7 @@ #!/bin/sh cd ./test -./test_script | sed -u -e '/:[[:space:]]ok/s/^/PASS: /' -e '/:[[:space:]]failed/s/^/FAIL: /' -e '/:[[:space:]]skipped/s/^/SKIP: /' +SKIP_SLOW_TESTS=yes ./test_script | sed -u -e '/:[[:space:]]ok/s/^/PASS: /' -e '/:[[:space:]]failed/s/^/FAIL: /' -e '/:[[:space:]]skipped/s/^/SKIP: /' rm -rf /var/volatile/tmp/*e2fsprogs* rm -f tmp-* rm -f *.tmp -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] iproute2: upgrade 4.19.0 -> 5.0.0
Signed-off-by: Changhyeok Bae
---
.../iproute2/iproute2/configure-cross.patch| 39 --
.../{iproute2_4.19.0.bb => iproute2_5.0.0.bb} | 4 +--
2 files changed, 24 insertions(+), 19 deletions(-)
rename meta/recipes-connectivity/iproute2/{iproute2_4.19.0.bb =>
iproute2_5.0.0.bb} (72%)
diff --git a/meta/recipes-connectivity/iproute2/iproute2/configure-cross.patch
b/meta/recipes-connectivity/iproute2/iproute2/configure-cross.patch
index 8b75a2a..102fdd6 100644
--- a/meta/recipes-connectivity/iproute2/iproute2/configure-cross.patch
+++ b/meta/recipes-connectivity/iproute2/iproute2/configure-cross.patch
@@ -1,6 +1,6 @@
-From 85b0589b4843c03e8e6fd9416d71ea449a73c5c0 Mon Sep 17 00:00:00 2001
+From 1313a4045a552942e90cf02f5cd5f648a583a6ab Mon Sep 17 00:00:00 2001
From: Koen Kooi
-Date: Thu, 3 Nov 2011 10:46:16 +0100
+Date: Thu, 11 Apr 2019 23:14:00 +0200
Subject: [PATCH] make configure cross compile safe
According to Kevin Tian:
@@ -8,25 +8,30 @@ Upstream-Status: Pending
Signed-off-by: Koen Kooi
Signed-off-by: Shane Wang
+---
+ configure | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
-Index: iproute2-4.14.1/configure
-===
iproute2-4.14.1.orig/configure
-+++ iproute2-4.14.1/configure
-@@ -2,6 +2,7 @@
+diff --git a/configure b/configure
+index 45fcffb6..0c5c9146 100755
+--- a/configure
b/configure
+@@ -3,6 +3,7 @@
# This is not an autoconf generated configure
#
INCLUDE=${1:-"$PWD/include"}
+SYSROOT=$1
-
+
# Output file which is input to Makefile
CONFIG=config.mk
-@@ -195,7 +196,7 @@ check_ipt_lib_dir()
- return
- fi
-
-- for dir in /lib /usr/lib /usr/local/lib
-+ for dir in $SYSROOT/lib $SYSROOT/usr/lib $SYSROOT/usr/local/lib
- do
- for file in $dir/{xtables,iptables}/lib*t_*so ; do
- if [ -f $file ]; then
+@@ -162,7 +163,7 @@ check_ipt_lib_dir()
+ return
+ fi
+
+- for dir in /lib /usr/lib /usr/local/lib; do
++ for dir in $SYSROOT/lib $SYSROOT/usr/lib $SYSROOT/usr/local/lib; do
+ for file in "xtables" "iptables"; do
+ file="$dir/$file/lib*t_*so"
+ if [ -f $file ]; then
+--
+2.20.1 (Apple Git-117)
diff --git a/meta/recipes-connectivity/iproute2/iproute2_4.19.0.bb
b/meta/recipes-connectivity/iproute2/iproute2_5.0.0.bb
similarity index 72%
rename from meta/recipes-connectivity/iproute2/iproute2_4.19.0.bb
rename to meta/recipes-connectivity/iproute2/iproute2_5.0.0.bb
index 6db4062..c5ac987 100644
--- a/meta/recipes-connectivity/iproute2/iproute2_4.19.0.bb
+++ b/meta/recipes-connectivity/iproute2/iproute2_5.0.0.bb
@@ -6,8 +6,8 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BP}.tar.xz \
file://0001-ip-Remove-unneed-header.patch \
"
-SRC_URI[md5sum] = "67eeebacaac4515cab73dfd2fc796af3"
-SRC_URI[sha256sum] =
"d9ec5ca1f47d8a85416fa26e7dc1cbf5d067640eb60e90bdc1c7e5bdc6a29984"
+SRC_URI[md5sum] = "d22107b4d7cfb999eeb8ad8a0aec1124"
+SRC_URI[sha256sum] =
"df047302a39650ef832c07e8dab5df7a23218cd398bd310c8628e386161d20ba"
# CFLAGS are computed in Makefile and reference CCOPTS
#
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] ethtool: upgrade 4.19 -> 5.0
Signed-off-by: Changhyeok Bae
---
meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch | 2 +-
meta/recipes-extended/ethtool/{ethtool_4.19.bb => ethtool_5.0.bb} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/ethtool/{ethtool_4.19.bb => ethtool_5.0.bb} (88%)
diff --git a/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
b/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
index beae5f9..b145188 100644
--- a/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
+++ b/meta/recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch
@@ -19,7 +19,7 @@ index e891d91..600f8a8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl Process this file with autoconf to produce a configure
script.
- AC_INIT(ethtool, 4.19, net...@vger.kernel.org)
+ AC_INIT(ethtool, 5.0, net...@vger.kernel.org)
AC_PREREQ(2.52)
AC_CONFIG_SRCDIR([ethtool.c])
-AM_INIT_AUTOMAKE([gnu])
diff --git a/meta/recipes-extended/ethtool/ethtool_4.19.bb
b/meta/recipes-extended/ethtool/ethtool_5.0.bb
similarity index 88%
rename from meta/recipes-extended/ethtool/ethtool_4.19.bb
rename to meta/recipes-extended/ethtool/ethtool_5.0.bb
index 74e255c..76cdf9c 100644
--- a/meta/recipes-extended/ethtool/ethtool_4.19.bb
+++ b/meta/recipes-extended/ethtool/ethtool_5.0.bb
@@ -11,8 +11,8 @@ SRC_URI =
"${KERNELORG_MIRROR}/software/network/ethtool/ethtool-${PV}.tar.gz \
file://avoid_parallel_tests.patch \
"
-SRC_URI[md5sum] = "a533db1d202724822c4ef297643fac12"
-SRC_URI[sha256sum] =
"e8e88f5a79c78e542cd84fee60b67dbf29cee63e4760e8d61544fea74c761ad1"
+SRC_URI[md5sum] = "8998c9eb7e491b0aec420a807ce52ba6"
+SRC_URI[sha256sum] =
"cc53a6d4d5643f8993ef20d6b638f88d9035529a9e777e222073c3a5b9237178"
inherit autotools ptest
RDEPENDS_${PN}-ptest += "make"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] iw: upgrade 4.14 -> 5.0.1
Signed-off-by: Changhyeok Bae
---
.../iw/0001-connect-fix-parsing-of-WEP-keys.patch | 194 -
.../iw/iw/separate-objdir.patch| 27 +--
.../iw/{iw_4.14.bb => iw_5.0.1.bb} | 5 +-
3 files changed, 19 insertions(+), 207 deletions(-)
delete mode 100644
meta/recipes-connectivity/iw/iw/0001-connect-fix-parsing-of-WEP-keys.patch
rename meta/recipes-connectivity/iw/{iw_4.14.bb => iw_5.0.1.bb} (80%)
diff --git
a/meta/recipes-connectivity/iw/iw/0001-connect-fix-parsing-of-WEP-keys.patch
b/meta/recipes-connectivity/iw/iw/0001-connect-fix-parsing-of-WEP-keys.patch
deleted file mode 100644
index 8cf8f7a..000
--- a/meta/recipes-connectivity/iw/iw/0001-connect-fix-parsing-of-WEP-keys.patch
+++ /dev/null
@@ -1,194 +0,0 @@
-From 2a6be4166fd718be0694fe8a6e3f1013c125dee2 Mon Sep 17 00:00:00 2001
-From: Emmanuel Grumbach
-Date: Tue, 12 Jun 2018 09:01:56 +0300
-Subject: [PATCH] connect: fix parsing of WEP keys
-
-The introduction of MFP options added a bug that causes a
-segmentation fault when parsing WEP keys.
-Fix that.
-
-Signed-off-by: Emmanuel Grumbach
-Signed-off-by: Johannes Berg
-
-Upstream-Status: Backport
-[https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/commit/?id=0e39f109c4b8155697a12ef090b59cdb304c8c44]
-Signed-off-by: Liu Haitao
- ap.c | 2 +-
- connect.c | 7 ++-
- ibss.c| 2 +-
- iw.h | 3 ++-
- util.c| 36 ++--
- 5 files changed, 24 insertions(+), 26 deletions(-)
-
-diff --git a/ap.c b/ap.c
-index 4bab5b9..dcce402 100644
a/ap.c
-+++ b/ap.c
-@@ -116,7 +116,7 @@ static int handle_start_ap(struct nl80211_state *state,
- argv++;
- argc--;
-
-- return parse_keys(msg, argv, argc);
-+ return parse_keys(msg, &argv, &argc);
- nla_put_failure:
- return -ENOSPC;
- }
-diff --git a/connect.c b/connect.c
-index 339fc73..4a847a1 100644
a/connect.c
-+++ b/connect.c
-@@ -54,13 +54,10 @@ static int iw_conn(struct nl80211_state *state,
- argv++;
- argc--;
-
-- ret = parse_keys(msg, argv, argc);
-+ ret = parse_keys(msg, &argv, &argc);
- if (ret)
- return ret;
-
-- argc -= 4;
-- argv += 4;
--
- if (!argc)
- return 0;
-
-@@ -228,7 +225,7 @@ static int iw_auth(struct nl80211_state *state,
- argv++;
- argc--;
-
-- return parse_keys(msg, argv, argc);
-+ return parse_keys(msg, &argv, &argc);
- nla_put_failure:
- return -ENOSPC;
- }
-diff --git a/ibss.c b/ibss.c
-index 84f1e95..d77fc92 100644
a/ibss.c
-+++ b/ibss.c
-@@ -115,7 +115,7 @@ static int join_ibss(struct nl80211_state *state,
- argv++;
- argc--;
-
-- return parse_keys(msg, argv, argc);
-+ return parse_keys(msg, &argv, &argc);
- nla_put_failure:
- return -ENOSPC;
- }
-diff --git a/iw.h b/iw.h
-index ee7ca20..8767ed3 100644
a/iw.h
-+++ b/iw.h
-@@ -180,7 +180,8 @@ int parse_hex_mask(char *hexmask, unsigned char **result,
size_t *result_len,
- unsigned char **mask);
- unsigned char *parse_hex(char *hex, size_t *outlen);
-
--int parse_keys(struct nl_msg *msg, char **argv, int argc);
-+
-+int parse_keys(struct nl_msg *msg, char **argv[], int *argc);
- int parse_freqchan(struct chandef *chandef, bool chan, int argc, char **argv,
int *parsed);
- enum nl80211_chan_width str_to_bw(const char *str);
- int put_chandef(struct nl_msg *msg, struct chandef *chandef);
-diff --git a/util.c b/util.c
-index 6e0ddff..122c019 100644
a/util.c
-+++ b/util.c
-@@ -417,23 +417,23 @@ static int parse_cipher_suite(const char *cipher_str)
- return -EINVAL;
- }
-
--int parse_keys(struct nl_msg *msg, char **argv, int argc)
-+int parse_keys(struct nl_msg *msg, char **argv[], int *argc)
- {
- struct nlattr *keys;
- int i = 0;
- bool have_default = false;
-- char *arg = *argv;
-+ char *arg = **argv;
- char keybuf[13];
- int pos = 0;
-
-- if (!argc)
-+ if (!*argc)
- return 1;
-
- if (!memcmp(&arg[pos], "psk", 3)) {
- char psk_keybuf[32];
- int cipher_suite, akm_suite;
-
-- if (argc < 4)
-+ if (*argc < 4)
- goto explain;
-
- pos+=3;
-@@ -451,9 +451,9 @@ int parse_keys(struct nl_msg *msg, char **argv, int argc)
- NLA_PUT(msg, NL80211_ATTR_PMK, 32, psk_keybuf);
- NLA_PUT_U32(msg, NL80211_ATTR_AUTH_TYPE,
NL80211_AUTHTYPE_OPEN_SYSTEM);
-
-- argv++;
-- argc--;
-- arg = *argv;
-+ *argv += 1;
-+ *argc -= 1;
-+ arg = **argv;
-
- akm_suite = parse_akm_suite(arg);
- if (akm_suite < 0)
-@@ -461,9 +461,9 @@ int parse_keys(struct nl_msg *msg, char **argv, int argc)
-
- NLA_PUT_U32(msg, NL80211_ATTR_AKM_SUITES, akm_suite);
-
-- argv++;
--
Re: [OE-core] [PATCH 1/1] runqemu: do not check return code of tput
On Fri, 2019-01-25 at 11:18 +0800, Chen Qi wrote:
> The subprocess.run was replaced by subprocess.check_call because
> of compatibility support down to python 3.4. But we really don't
> care about whether that command succeeds. Some user reports that
> in some tmux environment, this command fails and gives some
> unpleasant traceback output. So we use 'call' instead of 'check_call'
> to avoid such problem.
>
> Signed-off-by: Chen Qi
> ---
> scripts/runqemu | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index c4a0ca8..d3239ee 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -1318,7 +1318,7 @@ def main():
> logger.info("SIGTERM received")
> os.kill(config.qemupid, signal.SIGTERM)
> config.cleanup()
> -subprocess.check_call(["tput", "smam"])
> +subprocess.call(["tput", "smam"])
> signal.signal(signal.SIGTERM, sigterm_handler)
>
> config.check_args()
> @@ -1340,7 +1340,7 @@ def main():
> return 1
> finally:
> config.cleanup()
> -subprocess.check_call(["tput", "smam"])
> +subprocess.call(["tput", "smam"])
Can you send a v2 with a comment saying we're ignoring errors
deliberately please? Otherwise someone will just "fix" this again.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [[PATCH v2] kernel-devsrc: check for localversion files in the kernel source tree
On Thu, 2019-04-11 at 08:38 -0400, Bruce Ashfield wrote: > Looks good to me. > > Acked-by: Bruce Ashfield > > Richard, I assume you'll pick this up directly and don't want to wait > for me to queue and send it along with my next pull request. Correct, I've picked it up. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
On Thu, 2019-04-11 at 15:11 -0500, Jason Wessel wrote: > On 4/11/19 3:01 PM, Alexander Kanavin wrote: > > Yes, I agree. > > > > Alex > > > > > On 11 Apr 2019, at 21.59, Richard Purdie < > > > richard.pur...@linuxfoundation.org> wrote: > > > > > > > On Thu, 2019-04-11 at 11:36 -0500, Jason Wessel wrote: > > > > > > > > It all appears to work fine without the need to patch anything > > > > in > > > > master-next. > > > > > > > > Thank you for the explanation. > > > > > > This is starting to look like something we probably want to pull > > > into > > > the warrior release given the problems with meson converted > > > recipes > > > otherwise? > > > > > I concur, with Alex. I talked to Mark Hatle about this earlier > today. If it is not fixed prior to the release of the warrior branch > we were going to submit it as a back port, due to the fact this > causes build stability problems. Agreed. Good news is it was already tested on master-next and its had time for review so I just merged it. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
On 4/11/19 3:01 PM, Alexander Kanavin wrote: > Yes, I agree. > > Alex > >> On 11 Apr 2019, at 21.59, Richard Purdie >> wrote: >> >>> On Thu, 2019-04-11 at 11:36 -0500, Jason Wessel wrote: >>> >>> It all appears to work fine without the need to patch anything in >>> master-next. >>> >>> Thank you for the explanation. >> >> This is starting to look like something we probably want to pull into >> the warrior release given the problems with meson converted recipes >> otherwise? >> I concur, with Alex. I talked to Mark Hatle about this earlier today. If it is not fixed prior to the release of the warrior branch we were going to submit it as a back port, due to the fact this causes build stability problems. Jason. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 2/4] ptest.bbclass: Add feature to populate a binary directory
On Tue, 2019-04-09 at 00:44 -0500, Mariano Lopez wrote:
> This adds the functionality to create a binary directory within
> PTEST_PATH directory. This directory will be populated with
> symlinks pointing to the binaries installed by the package and
> then renamed by update-alternatives. This way the ptest only needs
> to source this binary directory in order to use the expected
> binaries.
>
> To enable this feature just add PTEST_BINDIR = "1" to the recipe.
>
> [YOCTO #12597]
> [YOCTO #13238]
>
> Signed-off-by: Mariano Lopez
> ---
> meta/classes/ptest.bbclass | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
> index 97865c9338..e87a9659cb 100644
> --- a/meta/classes/ptest.bbclass
> +++ b/meta/classes/ptest.bbclass
> @@ -65,6 +65,38 @@ do_install_ptest_base() {
> done
> }
>
> +PTEST_BINDIR_PKGD_PATH = "${PKGD}${PTEST_PATH}/bin"
> +
> +# This function needs to run after apply_update_alternative_renames
> because the
> +# aforementioned function will update the ALTERNATIVE_LINK_NAME
> flag. Append is
> +# used here to make this function to run as late as possible.
> +PACKAGE_PREPROCESS_FUNCS_append = "${@bb.utils.contains('PTEST_BINDI
> R', '1', \
> +bb.utils.contains('PTEST_ENABLED
> ', '1', ' ptest_update_alternatives', '', d), '', d)}"
> +
> +python ptest_update_alternatives() {
> +"""
> +This function will generate the symlinks in the
> PTEST_BINDIR_PKGD_PATH
> +to match the renamed binaries by update-alternatives.
> +"""
> +
> +if not bb.data.inherits_class('update-alternatives', d) \
> + or not update_alternatives_enabled(d):
> +return
> +
> +bb.note("Generating symlinks for ptest")
> +bin_paths = { os.environ["bindir"], os.environ["base_bindir"],
I'm going to merge this but is there a good reason you're using
os.environ[] here? If not we should merge a small fixup to use
d.getVar() since ultimately we don't really want these things in the
environment if we can help it.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
Yes, I agree.
Alex
> On 11 Apr 2019, at 21.59, Richard Purdie
> wrote:
>
>> On Thu, 2019-04-11 at 11:36 -0500, Jason Wessel wrote:
>>> On 4/11/19 10:35 AM, Alexander Kanavin wrote:
>>> On Thu, 11 Apr 2019 at 17:25, Jason Wessel <
>>> jason.wes...@windriver.com> wrote:
> Generally because generating introspection data is disabled for
> native
> packages, as a matter of policy (do not build something which
> is
> unused and untested).
>
> If you could add
> EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
>
> to the gdk-pixbuf recipe, and re-test (without your fix, to be
> extra
> sure) that g-ir-scanner is not invoked and nothing shows up in
> its
> cache, I would appreciate.
Thank you for the explanation. I think the problem is more
widespread than just gdk-pixbuf, now that I have a slightly
better idea about what we are looking for. My build is not even
complete and I can see there are three additional places the g-
ir-scanner is creating .cache entries.
/poky/build% grep -r /usr/bin/g-ir-scanner tmp/work/*/*/*/temp
|awk -F/ '{print $4}' |sort -u
atk-native
at-spi2-core-native
pango-native
Is it the case the bbclass file should be altered to set this
variable for the -native, or does each package need to be
modified individually?
>>>
>>> I think Andreas's patchset that was recently posted (and is
>>> currently
>>> in master-next) takes care of this in a general way, where you
>>> don't
>>> have to go and fix every recipe. The unfortunate bit is that meson
>>> does not have a standard flag for enabling/disabling introspection,
>>> but we found a way to deal with this that is as generic as
>>> possible.
>>>
>>> If you try with master-next, would be good to know.
>>>
>>
>> It all appears to work fine without the need to patch anything in
>> master-next.
>>
>> Thank you for the explanation.
>
> This is starting to look like something we probably want to pull into
> the warrior release given the problems with meson converted recipes
> otherwise?
>
> Cheers,
>
> Richard
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
On Thu, 2019-04-11 at 11:36 -0500, Jason Wessel wrote:
> On 4/11/19 10:35 AM, Alexander Kanavin wrote:
> > On Thu, 11 Apr 2019 at 17:25, Jason Wessel <
> > jason.wes...@windriver.com> wrote:
> > > > Generally because generating introspection data is disabled for
> > > > native
> > > > packages, as a matter of policy (do not build something which
> > > > is
> > > > unused and untested).
> > > >
> > > > If you could add
> > > > EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
> > > >
> > > > to the gdk-pixbuf recipe, and re-test (without your fix, to be
> > > > extra
> > > > sure) that g-ir-scanner is not invoked and nothing shows up in
> > > > its
> > > > cache, I would appreciate.
> > >
> > > Thank you for the explanation. I think the problem is more
> > > widespread than just gdk-pixbuf, now that I have a slightly
> > > better idea about what we are looking for. My build is not even
> > > complete and I can see there are three additional places the g-
> > > ir-scanner is creating .cache entries.
> > >
> > > /poky/build% grep -r /usr/bin/g-ir-scanner tmp/work/*/*/*/temp
> > > |awk -F/ '{print $4}' |sort -u
> > > atk-native
> > > at-spi2-core-native
> > > pango-native
> > >
> > >
> > > Is it the case the bbclass file should be altered to set this
> > > variable for the -native, or does each package need to be
> > > modified individually?
> >
> > I think Andreas's patchset that was recently posted (and is
> > currently
> > in master-next) takes care of this in a general way, where you
> > don't
> > have to go and fix every recipe. The unfortunate bit is that meson
> > does not have a standard flag for enabling/disabling introspection,
> > but we found a way to deal with this that is as generic as
> > possible.
> >
> > If you try with master-next, would be good to know.
> >
>
> It all appears to work fine without the need to patch anything in
> master-next.
>
> Thank you for the explanation.
This is starting to look like something we probably want to pull into
the warrior release given the problems with meson converted recipes
otherwise?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Upgrade from 2019.01 to 2019.04
On Thu, Apr 11, 2019 at 11:11 AM Denys Dmytriyenko wrote:
>
> On Thu, Apr 11, 2019 at 10:32:12AM -0700, Alistair Francis wrote:
> > On Thu, Apr 11, 2019 at 10:27 AM Denys Dmytriyenko wrote:
> > >
> > > On Thu, Apr 11, 2019 at 09:27:32AM +0100, Richard Purdie wrote:
> > > > On Wed, 2019-04-10 at 17:23 +, Alistair Francis wrote:
> > > > > Signed-off-by: Alistair Francis
> > > > > ---
> > > > > meta/recipes-bsp/u-boot/u-boot-common.inc | 2
> > > > > +-
> > > > > .../{u-boot-fw-utils_2019.01.bb => u-boot-fw-utils_2019.04.bb} | 0
> > > > > .../u-boot/{u-boot-tools_2019.01.bb => u-boot-tools_2019.04.bb} | 0
> > > > > .../recipes-bsp/u-boot/{u-boot_2019.01.bb => u-boot_2019.04.bb} | 0
> > > > > 4 files changed, 1 insertion(+), 1 deletion(-)
> > > > > rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2019.01.bb => u-
> > > > > boot-fw-utils_2019.04.bb} (100%)
> > > > > rename meta/recipes-bsp/u-boot/{u-boot-tools_2019.01.bb => u-boot-
> > > > > tools_2019.04.bb} (100%)
> > > > > rename meta/recipes-bsp/u-boot/{u-boot_2019.01.bb => u-
> > > > > boot_2019.04.bb} (100%)
> > > >
> > > > Breaks beaglebone-yocto:
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/490
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/489
> > >
> > > Richard,
> > >
> > > This is quite interesting and surprisingly timely for me! Let me explain.
> > >
> > > Both of the above errors are not really specific to beaglebone or even
> > > u-boot.
> > > In both cases, the failure is this:
> > >
> > > | ERROR: _exec_cmd: install -m 0644 -D
> > > /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img
> > >
> > > /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/deploy-core-image-sato-sdk-ptest-image-complete/core-image-sato-sdk-ptest-beaglebone-yocto-20190410232147/tmp.wic.4xf3vi9f/boot.1/u-boot.img
> > > returned '1' instead of 0
> > > | output: install: cannot stat
> > > '/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img':
> > > No such file or directory
> > > | ERROR: Function failed: do_image_wic (log file is located at
> > > /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/temp/log.do_image_wic.41960)
> > >
> > > I recently received exactly the same error report internally and have been
> > > investigating it. Though it is against Thud, for a different platform and
> > > with
> > > our own u-boot from meta-ti.
> > >
> > > It seems to be a race condition - wic is trying to assemble an image when
> > > u-boot binary is not yet ready. Usually on subsequent rebuilds when u-boot
> > > needs to be rebuilt, but everything else is already available.
> > >
> > > Packaging for wic is set with IMAGE_BOOT_FILES = "u-boot.img", but the
> > > build
> > > dependency is special, as u-boot is not part of rootfs and is being set by
> > > EXTRA_IMAGEDEPENDS = "u-boot":
> > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> > >
> > > Since wic jumps right into packaging u-boot.img and doesn't wait for it to
> > > finish building/installing/deploying, it seems EXTRA_IMAGEDEPENDS is
> > > broken.
> > > But it used to work prior to Thud. It appears it may have been broken
> > > here:
> > > https://git.openembedded.org/openembedded-core/commit/?id=b54cdaea7844ee3bf0c39eb97cc7c4c17ed5818c
> > >
> > > While the above commit deals with licenses and manifests, removal of these
> > > lines is not clear:
> > >
> > > -extra_depends = d.getVar("EXTRA_IMAGEDEPENDS")
> > > -boot_depends = get_boot_dependencies(d)
> > > -depends.extend(extra_depends.split())
> > > -depends.extend(boot_depends)
> > > -depends = list(set(depends))
> > >
> > > Could it have affected boot dependencies and EXTRA_IMAGEDEPENDS behavior?
> > > Please let me know if you need any more details. Thanks.
> >
> > Interesting. I just managed to reproduce a build failure for the
> > beaglebone based on this patch. My build fail wasn't because of the
> > missing u-boot.img file like in the buildbot error but instead due to
> > an incorrect config file.
> >
> > I have sent a patch with you both in CC that fixes the missing config
> > "beaglebone-yocto: Update u-boot config to match u-boot 19.04".
> > Without that patch u-boot 19.04 doesn't even compile, so I'm not sure
> > how the buildbot got far enough to complain about a missing .img file.
> >
> > After reading your email it makes more sense. It does seem like wic is
> > trying to package the u-boot.img file too early.
> >
> > Either way the "beaglebone-yocto: Update u-boot config to match u-boot
> > 19.04" patch should be applied at the same time as this patch.
>
> Yeah, I just acked your config patch. I was going to do the same my
Re: [OE-core] [Openembedded-architecture] [yocto] Eclipse support dropped with immediate effect
On Thu, Apr 11, 2019 at 9:29 AM Scott Rifenbark wrote: > Richard and Armin, > > I am going to start pulling Eclipse from the docs today. The changes > won't make the frozen rc build but the website docs will reflect reality. > Thank you, Scott. > > Scott > > On Thu, Apr 11, 2019 at 12:20 AM > wrote: > >> On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote: >> > >> > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote: >> > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote: >> > > > On 4/9/19 8:52 PM, Richard Purdie wrote: >> > > > > I'm sorry to have to say this but the project is terminating >> > > > > its >> > > > > official eclipse plugin support with immediate effect. >> > > > Does this affect the stable branches as well? >> > > Yes, I think we'll just be removing the target from the autobuilder >> > > entirely. >> > >> > Have we every removed a feature from a release? Do we need to doc >> > this ? >> >> Its not so much remove as not release. No, we haven't and yes, we do >> need to document it in the release notes. >> >> Cheers, >> >> Richard >> >> ___ >> Openembedded-architecture mailing list >> openembedded-architect...@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture >> > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Upgrade from 2019.01 to 2019.04
On Thu, Apr 11, 2019 at 10:32:12AM -0700, Alistair Francis wrote:
> On Thu, Apr 11, 2019 at 10:27 AM Denys Dmytriyenko wrote:
> >
> > On Thu, Apr 11, 2019 at 09:27:32AM +0100, Richard Purdie wrote:
> > > On Wed, 2019-04-10 at 17:23 +, Alistair Francis wrote:
> > > > Signed-off-by: Alistair Francis
> > > > ---
> > > > meta/recipes-bsp/u-boot/u-boot-common.inc | 2
> > > > +-
> > > > .../{u-boot-fw-utils_2019.01.bb => u-boot-fw-utils_2019.04.bb} | 0
> > > > .../u-boot/{u-boot-tools_2019.01.bb => u-boot-tools_2019.04.bb} | 0
> > > > .../recipes-bsp/u-boot/{u-boot_2019.01.bb => u-boot_2019.04.bb} | 0
> > > > 4 files changed, 1 insertion(+), 1 deletion(-)
> > > > rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2019.01.bb => u-
> > > > boot-fw-utils_2019.04.bb} (100%)
> > > > rename meta/recipes-bsp/u-boot/{u-boot-tools_2019.01.bb => u-boot-
> > > > tools_2019.04.bb} (100%)
> > > > rename meta/recipes-bsp/u-boot/{u-boot_2019.01.bb => u-
> > > > boot_2019.04.bb} (100%)
> > >
> > > Breaks beaglebone-yocto:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/490
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/489
> >
> > Richard,
> >
> > This is quite interesting and surprisingly timely for me! Let me explain.
> >
> > Both of the above errors are not really specific to beaglebone or even
> > u-boot.
> > In both cases, the failure is this:
> >
> > | ERROR: _exec_cmd: install -m 0644 -D
> > /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img
> >
> > /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/deploy-core-image-sato-sdk-ptest-image-complete/core-image-sato-sdk-ptest-beaglebone-yocto-20190410232147/tmp.wic.4xf3vi9f/boot.1/u-boot.img
> > returned '1' instead of 0
> > | output: install: cannot stat
> > '/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img':
> > No such file or directory
> > | ERROR: Function failed: do_image_wic (log file is located at
> > /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/temp/log.do_image_wic.41960)
> >
> > I recently received exactly the same error report internally and have been
> > investigating it. Though it is against Thud, for a different platform and
> > with
> > our own u-boot from meta-ti.
> >
> > It seems to be a race condition - wic is trying to assemble an image when
> > u-boot binary is not yet ready. Usually on subsequent rebuilds when u-boot
> > needs to be rebuilt, but everything else is already available.
> >
> > Packaging for wic is set with IMAGE_BOOT_FILES = "u-boot.img", but the build
> > dependency is special, as u-boot is not part of rootfs and is being set by
> > EXTRA_IMAGEDEPENDS = "u-boot":
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> >
> > Since wic jumps right into packaging u-boot.img and doesn't wait for it to
> > finish building/installing/deploying, it seems EXTRA_IMAGEDEPENDS is broken.
> > But it used to work prior to Thud. It appears it may have been broken here:
> > https://git.openembedded.org/openembedded-core/commit/?id=b54cdaea7844ee3bf0c39eb97cc7c4c17ed5818c
> >
> > While the above commit deals with licenses and manifests, removal of these
> > lines is not clear:
> >
> > -extra_depends = d.getVar("EXTRA_IMAGEDEPENDS")
> > -boot_depends = get_boot_dependencies(d)
> > -depends.extend(extra_depends.split())
> > -depends.extend(boot_depends)
> > -depends = list(set(depends))
> >
> > Could it have affected boot dependencies and EXTRA_IMAGEDEPENDS behavior?
> > Please let me know if you need any more details. Thanks.
>
> Interesting. I just managed to reproduce a build failure for the
> beaglebone based on this patch. My build fail wasn't because of the
> missing u-boot.img file like in the buildbot error but instead due to
> an incorrect config file.
>
> I have sent a patch with you both in CC that fixes the missing config
> "beaglebone-yocto: Update u-boot config to match u-boot 19.04".
> Without that patch u-boot 19.04 doesn't even compile, so I'm not sure
> how the buildbot got far enough to complain about a missing .img file.
>
> After reading your email it makes more sense. It does seem like wic is
> trying to package the u-boot.img file too early.
>
> Either way the "beaglebone-yocto: Update u-boot config to match u-boot
> 19.04" patch should be applied at the same time as this patch.
Yeah, I just acked your config patch. I was going to do the same myself. I
provided some details in the reply and also referenced bug #13145 from the
bugzilla. I wonder if v2 would be possible to include all that in the commit
log? Thanks.
Anyway, that's separate from the wic issue we started discussing above :)
--
Denys
Re: [OE-core] [PATCH] u-boot: Upgrade from 2019.01 to 2019.04
On Thu, Apr 11, 2019 at 10:27 AM Denys Dmytriyenko wrote:
>
> On Thu, Apr 11, 2019 at 09:27:32AM +0100, Richard Purdie wrote:
> > On Wed, 2019-04-10 at 17:23 +, Alistair Francis wrote:
> > > Signed-off-by: Alistair Francis
> > > ---
> > > meta/recipes-bsp/u-boot/u-boot-common.inc | 2
> > > +-
> > > .../{u-boot-fw-utils_2019.01.bb => u-boot-fw-utils_2019.04.bb} | 0
> > > .../u-boot/{u-boot-tools_2019.01.bb => u-boot-tools_2019.04.bb} | 0
> > > .../recipes-bsp/u-boot/{u-boot_2019.01.bb => u-boot_2019.04.bb} | 0
> > > 4 files changed, 1 insertion(+), 1 deletion(-)
> > > rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2019.01.bb => u-
> > > boot-fw-utils_2019.04.bb} (100%)
> > > rename meta/recipes-bsp/u-boot/{u-boot-tools_2019.01.bb => u-boot-
> > > tools_2019.04.bb} (100%)
> > > rename meta/recipes-bsp/u-boot/{u-boot_2019.01.bb => u-
> > > boot_2019.04.bb} (100%)
> >
> > Breaks beaglebone-yocto:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/490
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/489
>
> Richard,
>
> This is quite interesting and surprisingly timely for me! Let me explain.
>
> Both of the above errors are not really specific to beaglebone or even u-boot.
> In both cases, the failure is this:
>
> | ERROR: _exec_cmd: install -m 0644 -D
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img
>
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/deploy-core-image-sato-sdk-ptest-image-complete/core-image-sato-sdk-ptest-beaglebone-yocto-20190410232147/tmp.wic.4xf3vi9f/boot.1/u-boot.img
> returned '1' instead of 0
> | output: install: cannot stat
> '/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img':
> No such file or directory
> | ERROR: Function failed: do_image_wic (log file is located at
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/temp/log.do_image_wic.41960)
>
> I recently received exactly the same error report internally and have been
> investigating it. Though it is against Thud, for a different platform and with
> our own u-boot from meta-ti.
>
> It seems to be a race condition - wic is trying to assemble an image when
> u-boot binary is not yet ready. Usually on subsequent rebuilds when u-boot
> needs to be rebuilt, but everything else is already available.
>
> Packaging for wic is set with IMAGE_BOOT_FILES = "u-boot.img", but the build
> dependency is special, as u-boot is not part of rootfs and is being set by
> EXTRA_IMAGEDEPENDS = "u-boot":
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
>
> Since wic jumps right into packaging u-boot.img and doesn't wait for it to
> finish building/installing/deploying, it seems EXTRA_IMAGEDEPENDS is broken.
> But it used to work prior to Thud. It appears it may have been broken here:
> https://git.openembedded.org/openembedded-core/commit/?id=b54cdaea7844ee3bf0c39eb97cc7c4c17ed5818c
>
> While the above commit deals with licenses and manifests, removal of these
> lines is not clear:
>
> -extra_depends = d.getVar("EXTRA_IMAGEDEPENDS")
> -boot_depends = get_boot_dependencies(d)
> -depends.extend(extra_depends.split())
> -depends.extend(boot_depends)
> -depends = list(set(depends))
>
> Could it have affected boot dependencies and EXTRA_IMAGEDEPENDS behavior?
> Please let me know if you need any more details. Thanks.
Interesting. I just managed to reproduce a build failure for the
beaglebone based on this patch. My build fail wasn't because of the
missing u-boot.img file like in the buildbot error but instead due to
an incorrect config file.
I have sent a patch with you both in CC that fixes the missing config
"beaglebone-yocto: Update u-boot config to match u-boot 19.04".
Without that patch u-boot 19.04 doesn't even compile, so I'm not sure
how the buildbot got far enough to complain about a missing .img file.
After reading your email it makes more sense. It does seem like wic is
trying to package the u-boot.img file too early.
Either way the "beaglebone-yocto: Update u-boot config to match u-boot
19.04" patch should be applied at the same time as this patch.
Alistair
>
> --
> Denys
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Upgrade from 2019.01 to 2019.04
On Thu, Apr 11, 2019 at 09:27:32AM +0100, Richard Purdie wrote:
> On Wed, 2019-04-10 at 17:23 +, Alistair Francis wrote:
> > Signed-off-by: Alistair Francis
> > ---
> > meta/recipes-bsp/u-boot/u-boot-common.inc | 2
> > +-
> > .../{u-boot-fw-utils_2019.01.bb => u-boot-fw-utils_2019.04.bb} | 0
> > .../u-boot/{u-boot-tools_2019.01.bb => u-boot-tools_2019.04.bb} | 0
> > .../recipes-bsp/u-boot/{u-boot_2019.01.bb => u-boot_2019.04.bb} | 0
> > 4 files changed, 1 insertion(+), 1 deletion(-)
> > rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2019.01.bb => u-
> > boot-fw-utils_2019.04.bb} (100%)
> > rename meta/recipes-bsp/u-boot/{u-boot-tools_2019.01.bb => u-boot-
> > tools_2019.04.bb} (100%)
> > rename meta/recipes-bsp/u-boot/{u-boot_2019.01.bb => u-
> > boot_2019.04.bb} (100%)
>
> Breaks beaglebone-yocto:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/490
> https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/489
Richard,
This is quite interesting and surprisingly timely for me! Let me explain.
Both of the above errors are not really specific to beaglebone or even u-boot.
In both cases, the failure is this:
| ERROR: _exec_cmd: install -m 0644 -D
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/deploy-core-image-sato-sdk-ptest-image-complete/core-image-sato-sdk-ptest-beaglebone-yocto-20190410232147/tmp.wic.4xf3vi9f/boot.1/u-boot.img
returned '1' instead of 0
| output: install: cannot stat
'/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/deploy/images/beaglebone-yocto/u-boot.img':
No such file or directory
| ERROR: Function failed: do_image_wic (log file is located at
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-sato-sdk-ptest/1.0-r0/temp/log.do_image_wic.41960)
I recently received exactly the same error report internally and have been
investigating it. Though it is against Thud, for a different platform and with
our own u-boot from meta-ti.
It seems to be a race condition - wic is trying to assemble an image when
u-boot binary is not yet ready. Usually on subsequent rebuilds when u-boot
needs to be rebuilt, but everything else is already available.
Packaging for wic is set with IMAGE_BOOT_FILES = "u-boot.img", but the build
dependency is special, as u-boot is not part of rootfs and is being set by
EXTRA_IMAGEDEPENDS = "u-boot":
http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
Since wic jumps right into packaging u-boot.img and doesn't wait for it to
finish building/installing/deploying, it seems EXTRA_IMAGEDEPENDS is broken.
But it used to work prior to Thud. It appears it may have been broken here:
https://git.openembedded.org/openembedded-core/commit/?id=b54cdaea7844ee3bf0c39eb97cc7c4c17ed5818c
While the above commit deals with licenses and manifests, removal of these
lines is not clear:
-extra_depends = d.getVar("EXTRA_IMAGEDEPENDS")
-boot_depends = get_boot_dependencies(d)
-depends.extend(extra_depends.split())
-depends.extend(boot_depends)
-depends = list(set(depends))
Could it have affected boot dependencies and EXTRA_IMAGEDEPENDS behavior?
Please let me know if you need any more details. Thanks.
--
Denys
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
On 4/11/19 10:35 AM, Alexander Kanavin wrote:
> On Thu, 11 Apr 2019 at 17:25, Jason Wessel wrote:
>>> Generally because generating introspection data is disabled for native
>>> packages, as a matter of policy (do not build something which is
>>> unused and untested).
>>>
>>> If you could add
>>> EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
>>>
>>> to the gdk-pixbuf recipe, and re-test (without your fix, to be extra
>>> sure) that g-ir-scanner is not invoked and nothing shows up in its
>>> cache, I would appreciate.
>>
>>
>> Thank you for the explanation. I think the problem is more widespread than
>> just gdk-pixbuf, now that I have a slightly better idea about what we are
>> looking for. My build is not even complete and I can see there are three
>> additional places the g-ir-scanner is creating .cache entries.
>>
>> /poky/build% grep -r /usr/bin/g-ir-scanner tmp/work/*/*/*/temp |awk -F/
>> '{print $4}' |sort -u
>> atk-native
>> at-spi2-core-native
>> pango-native
>>
>>
>> Is it the case the bbclass file should be altered to set this variable for
>> the -native, or does each package need to be modified individually?
>
> I think Andreas's patchset that was recently posted (and is currently
> in master-next) takes care of this in a general way, where you don't
> have to go and fix every recipe. The unfortunate bit is that meson
> does not have a standard flag for enabling/disabling introspection,
> but we found a way to deal with this that is as generic as possible.
>
> If you try with master-next, would be good to know.
>
It all appears to work fine without the need to patch anything in master-next.
Thank you for the explanation.
Jason.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Openembedded-architecture] [yocto] Eclipse support dropped with immediate effect
Richard and Armin, I am going to start pulling Eclipse from the docs today. The changes won't make the frozen rc build but the website docs will reflect reality. Scott On Thu, Apr 11, 2019 at 12:20 AM wrote: > On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote: > > > > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote: > > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote: > > > > On 4/9/19 8:52 PM, Richard Purdie wrote: > > > > > I'm sorry to have to say this but the project is terminating > > > > > its > > > > > official eclipse plugin support with immediate effect. > > > > Does this affect the stable branches as well? > > > Yes, I think we'll just be removing the target from the autobuilder > > > entirely. > > > > Have we every removed a feature from a release? Do we need to doc > > this ? > > Its not so much remove as not release. No, we haven't and yes, we do > need to document it in the release notes. > > Cheers, > > Richard > > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
Elfutils-Exception no longer exists after upstream release 0.154
and commit:
commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
Author: Mark Wielaard
Date: Tue Jun 5 17:15:16 2012 +0200
NEWS file in the sources says this about switch from GPLv2 to
GPLv3 license:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
363 programs. There is now also a formal CONTRIBUTING document describing how
to
364 submit patches.
libasm, libdw and libelf are thus covered optionally by GPLv2 license.
See also Debian copyright summary for elfutils:
https://tracker.debian.org/media/packages/e/elfutils/copyright-0.176-1
Signed-off-by: Mikko Rapeli
---
meta/conf/licenses.conf | 2 +-
meta/files/common-licenses/Elfutils-Exception| 12
meta/recipes-devtools/elfutils/elfutils_0.176.bb | 14 +-
3 files changed, 14 insertions(+), 14 deletions(-)
delete mode 100644 meta/files/common-licenses/Elfutils-Exception
v1:
http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281124.html
v2:
http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281127.html
* removed Elfutils-Exception
v3:
http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281137.html
* rebase to latest master branch with elfutils 0.176
v4:
* fixed typo in comment; GPLv3+ -> LGPLv3+
* update commit message Debian copyright URL to same 0.176 version
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 1058084..7b01c57 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0
CC-BY-SA-2.5 CC-BY-SA-3.0
SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B CECILL-C"
SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 EFL-2.0"
-SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0
ErlPL-1.1"
+SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair Frameworx-1.0"
SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
diff --git a/meta/files/common-licenses/Elfutils-Exception
b/meta/files/common-licenses/Elfutils-Exception
deleted file mode 100644
index 627d769..000
--- a/meta/files/common-licenses/Elfutils-Exception
+++ /dev/null
@@ -1,12 +0,0 @@
- This file describes the limits of the Exception under which you are allowed
- to distribute Non-GPL Code in linked combination with Red Hat elfutils.
- For the full text of the license, please see one of the header files
- included with the source distribution or the file COPYING found in the
- top level directory of the source.
-
- The Approved Interfaces are the functions declared in the files:
-
- libelf.h
- libdw.h
- libdwfl.h
-
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
index fd901c9..4602544 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
@@ -1,7 +1,7 @@
SUMMARY = "Utilities and libraries for handling compiled object files"
HOMEPAGE = "https://sourceware.org/elfutils";
SECTION = "base"
-LICENSE = "(GPLv3 & Elfutils-Exception)"
+LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
DEPENDS = "libtool bzip2 zlib virtual/libintl"
DEPENDS_append_libc-musl = " argp-standalone fts "
@@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
# Package utilities separately
PACKAGES =+ "${PN}-binutils libelf libasm libdw"
+
+# shared libraries are licensed GPLv2 or LGPLv3+, binaries GPLv3+
+# according to NEWS file:
+# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
+# programs. There is now also a formal CONTRIBUTING document describing how to
+# submit patches."
+LICENSE_${PN}-binutils = "GPLv3+"
+LICENSE_${PN} = "GPLv3+"
+LICENSE_libelf = "GPLv2 | LGPLv3+"
+LICENSE_libasm = "GPLv2 | LGPLv3+"
+LICENSE_libdw = "GPLv2 | LGPLv3+"
+
FILES_${PN}-binutils = "\
${bindir}/eu-addr2line \
${bindir}/eu-ld \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3: add a tr-tr locale for test_locale ptest
With this change, the ptests do not fail anymore,
except for the three failures caused by the 5.0 kernel regression:
- test_ssl and test_httplib lock up, and are skipped
(there is a separate patch for it)
- test_asyncio fails but does not lock up
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/python/python3_3.7.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3_3.7.2.bb
b/meta/recipes-devtools/python/python3_3.7.2.bb
index 28f128d488b..71a6c103166 100644
--- a/meta/recipes-devtools/python/python3_3.7.2.bb
+++ b/meta/recipes-devtools/python/python3_3.7.2.bb
@@ -284,7 +284,7 @@ FILES_${PN}-misc = "${libdir}/python${PYTHON_MAJMIN}
${libdir}/python${PYTHON_MA
PACKAGES += "${PN}-man"
FILES_${PN}-man = "${datadir}/man"
-RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2 libgcc
tzdata-europe coreutils sed"
+RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2 libgcc
tzdata-europe coreutils sed locale-base-tr-tr.iso-8859-9"
RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk',
'', d)}"
RDEPENDS_${PN}-dev = ""
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
On Thu, Apr 11, 2019 at 10:45:21AM -0500, Mark Hatle wrote: > On 4/11/19 8:41 AM, Mikko Rapeli wrote: > > Elfutils-Exception no longer exists after upstream release 0.154 > > and commit: > > > > commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2 > > Author: Mark Wielaard > > Date: Tue Jun 5 17:15:16 2012 +0200 > > > > NEWS file in the sources says this about switch from GPLv2 to > > GPLv3 license: > > > > https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362 > > > > 362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for > > stand-alone > > 363 programs. There is now also a formal CONTRIBUTING document describing > > how to > > 364 submit patches. > > > > libasm, libdw and libelf are thus covered optionally by GPLv2 license. > > > > See also Debian copyright summary for elfutils: > > > > https://tracker.debian.org/media/packages/e/elfutils/copyright-0.175-1 > > > > Signed-off-by: Mikko Rapeli > > --- > > meta/conf/licenses.conf | 2 +- > > meta/files/common-licenses/Elfutils-Exception| 12 > > meta/recipes-devtools/elfutils/elfutils_0.176.bb | 14 +- > > 3 files changed, 14 insertions(+), 14 deletions(-) > > delete mode 100644 meta/files/common-licenses/Elfutils-Exception > > > > v1: > > http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281124.html > > > > v2: > > http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281127.html > > * removed Elfutils-Exception > > > > v3: > > * rebase to latest master branch with elfutils 0.176 > > > > diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf > > index 1058084..7b01c57 100644 > > --- a/meta/conf/licenses.conf > > +++ b/meta/conf/licenses.conf > > @@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0 > > CC-BY-SA-2.5 CC-BY-SA-3.0 > > SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B > > CECILL-C" > > SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL" > > SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 > > EFL-2.0" > > -SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0 > > ErlPL-1.1" > > +SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1" > > SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair > > Frameworx-1.0" > > SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0" > > SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception" > > diff --git a/meta/files/common-licenses/Elfutils-Exception > > b/meta/files/common-licenses/Elfutils-Exception > > deleted file mode 100644 > > index 627d769..000 > > --- a/meta/files/common-licenses/Elfutils-Exception > > +++ /dev/null > > @@ -1,12 +0,0 @@ > > - This file describes the limits of the Exception under which you are > > allowed > > - to distribute Non-GPL Code in linked combination with Red Hat elfutils. > > - For the full text of the license, please see one of the header files > > - included with the source distribution or the file COPYING found in the > > - top level directory of the source. > > - > > - The Approved Interfaces are the functions declared in the files: > > - > > - libelf.h > > - libdw.h > > - libdwfl.h > > - > > diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb > > b/meta/recipes-devtools/elfutils/elfutils_0.176.bb > > index fd901c9..cd824e2 100644 > > --- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb > > +++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb > > @@ -1,7 +1,7 @@ > > SUMMARY = "Utilities and libraries for handling compiled object files" > > HOMEPAGE = "https://sourceware.org/elfutils"; > > SECTION = "base" > > -LICENSE = "(GPLv3 & Elfutils-Exception)" > > +LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"' > > I realize we don't have a choice but to conform to the licensing when we > rebase... but has anyone looked at what links to elfutils to see if this could > end up introducing any licensing issues? > > The previous exception specifically allowed Non-GPL code to use interfaces, > I'm > not sure if there is actually any non-GPL code using these interfaces without > OE, but it may be worth a quick look. At least poky and meta-openembedded users have GPLv2 licenses: $ grep LICENSE $( egrep -l "DEPENDS.*elfutils" poky/meta* meta-openembedded -rn ) poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:LICENSE = "GPLv2+" poky/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb:LICENSE = "GPL-2.0" poky/meta/recipes-devtools/prelink/prelink_git.bb:LICENSE = "GPLv2" poky/meta/recipes-connectivity/iproute2/iproute2.inc:LICENSE = "GPLv2+" poky/meta/recipes-kernel/perf/perf.bb:LICENSE = "GPLv2" poky/meta/recipes-kernel/linux/kernel-devsrc.bb:LICENSE = "GPLv2" meta-openembedded/meta-oe/recipes-devtools/ltrace/ltrace_git.bb:LICENSE = "GPLv2" meta-openembedded/meta-oe/recipes-devtools/uftrace/uftrace_0.9.2.bb:L
Re: [OE-core] [PATCH v3] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
On 4/11/19 8:41 AM, Mikko Rapeli wrote:
> Elfutils-Exception no longer exists after upstream release 0.154
> and commit:
>
> commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
> Author: Mark Wielaard
> Date: Tue Jun 5 17:15:16 2012 +0200
>
> NEWS file in the sources says this about switch from GPLv2 to
> GPLv3 license:
>
> https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
>
> 362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> stand-alone
> 363 programs. There is now also a formal CONTRIBUTING document describing
> how to
> 364 submit patches.
>
> libasm, libdw and libelf are thus covered optionally by GPLv2 license.
>
> See also Debian copyright summary for elfutils:
>
> https://tracker.debian.org/media/packages/e/elfutils/copyright-0.175-1
>
> Signed-off-by: Mikko Rapeli
> ---
> meta/conf/licenses.conf | 2 +-
> meta/files/common-licenses/Elfutils-Exception| 12
> meta/recipes-devtools/elfutils/elfutils_0.176.bb | 14 +-
> 3 files changed, 14 insertions(+), 14 deletions(-)
> delete mode 100644 meta/files/common-licenses/Elfutils-Exception
>
> v1:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281124.html
>
> v2:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281127.html
> * removed Elfutils-Exception
>
> v3:
> * rebase to latest master branch with elfutils 0.176
>
> diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
> index 1058084..7b01c57 100644
> --- a/meta/conf/licenses.conf
> +++ b/meta/conf/licenses.conf
> @@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0
> CC-BY-SA-2.5 CC-BY-SA-3.0
> SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B CECILL-C"
> SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
> SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 EFL-2.0"
> -SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0
> ErlPL-1.1"
> +SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
> SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair Frameworx-1.0"
> SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
> SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
> diff --git a/meta/files/common-licenses/Elfutils-Exception
> b/meta/files/common-licenses/Elfutils-Exception
> deleted file mode 100644
> index 627d769..000
> --- a/meta/files/common-licenses/Elfutils-Exception
> +++ /dev/null
> @@ -1,12 +0,0 @@
> - This file describes the limits of the Exception under which you are
> allowed
> - to distribute Non-GPL Code in linked combination with Red Hat elfutils.
> - For the full text of the license, please see one of the header files
> - included with the source distribution or the file COPYING found in the
> - top level directory of the source.
> -
> - The Approved Interfaces are the functions declared in the files:
> -
> - libelf.h
> - libdw.h
> - libdwfl.h
> -
> diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> index fd901c9..cd824e2 100644
> --- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> +++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> @@ -1,7 +1,7 @@
> SUMMARY = "Utilities and libraries for handling compiled object files"
> HOMEPAGE = "https://sourceware.org/elfutils";
> SECTION = "base"
> -LICENSE = "(GPLv3 & Elfutils-Exception)"
> +LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"'
I realize we don't have a choice but to conform to the licensing when we
rebase... but has anyone looked at what links to elfutils to see if this could
end up introducing any licensing issues?
The previous exception specifically allowed Non-GPL code to use interfaces, I'm
not sure if there is actually any non-GPL code using these interfaces without
OE, but it may be worth a quick look.
> LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> DEPENDS = "libtool bzip2 zlib virtual/libintl"
> DEPENDS_append_libc-musl = " argp-standalone fts "
> @@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
>
> # Package utilities separately
> PACKAGES =+ "${PN}-binutils libelf libasm libdw"
> +
> +# shared libraries are licensed GPLv2 or GPLv3+, binaries GPLv3+
Don't you mean LGPLv3+ above for the shared libraries?
> +# according to NEWS file:
> +# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> stand-alone
> +# programs. There is now also a formal CONTRIBUTING document describing how
> to
> +# submit patches."
> +LICENSE_${PN}-binutils = "GPLv3+"
> +LICENSE_${PN} = "GPLv3+"
> +LICENSE_libelf = "GPLv2 | LGPLv3+"
> +LICENSE_libasm = "GPLv2 | LGPLv3+"
> +LICENSE_libdw = "GPLv2 | LGPLv3+"
> +
> FILES_${PN}-binutils = "\
> ${bindir}/eu-addr2line \
> ${bindir}/eu-ld \
>
--
___
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
On Thu, 11 Apr 2019 at 17:25, Jason Wessel wrote:
> > Generally because generating introspection data is disabled for native
> > packages, as a matter of policy (do not build something which is
> > unused and untested).
> >
> > If you could add
> > EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
> >
> > to the gdk-pixbuf recipe, and re-test (without your fix, to be extra
> > sure) that g-ir-scanner is not invoked and nothing shows up in its
> > cache, I would appreciate.
>
>
> Thank you for the explanation. I think the problem is more widespread than
> just gdk-pixbuf, now that I have a slightly better idea about what we are
> looking for. My build is not even complete and I can see there are three
> additional places the g-ir-scanner is creating .cache entries.
>
> /poky/build% grep -r /usr/bin/g-ir-scanner tmp/work/*/*/*/temp |awk -F/
> '{print $4}' |sort -u
> atk-native
> at-spi2-core-native
> pango-native
>
>
> Is it the case the bbclass file should be altered to set this variable for
> the -native, or does each package need to be modified individually?
I think Andreas's patchset that was recently posted (and is currently
in master-next) takes care of this in a general way, where you don't
have to go and fix every recipe. The unfortunate bit is that meson
does not have a standard flag for enabling/disabling introspection,
but we found a way to deal with this that is as generic as possible.
If you try with master-next, would be good to know.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] volatile-binds: VOLATILE_LIB_DIR
Hi all, I'm wondering if it makes sense to add a VOLATILE_LIB_DIR option same way as VOLATILE_LOG_DIR but for /var/lib folder? I'm asking because I can't append VOLATILE_BINDS with folders inside /var/lib as it fails on ConditionPathIsReadWrite (/var/lib is writable after bindmounting to /var/volatile/lib) and also goes into trouble with inner overlays. One way to fix it in my case is to redefines entirely VOLATILE_BINDS variable, so maybe it's not worth the effort? Regards, Vincent -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
On 4/11/19 9:44 AM, Alexander Kanavin wrote:
> Generally because generating introspection data is disabled for native
> packages, as a matter of policy (do not build something which is
> unused and untested).
>
> If you could add
> EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
>
> to the gdk-pixbuf recipe, and re-test (without your fix, to be extra
> sure) that g-ir-scanner is not invoked and nothing shows up in its
> cache, I would appreciate.
Thank you for the explanation. I think the problem is more widespread than
just gdk-pixbuf, now that I have a slightly better idea about what we are
looking for. My build is not even complete and I can see there are three
additional places the g-ir-scanner is creating .cache entries.
/poky/build% grep -r /usr/bin/g-ir-scanner tmp/work/*/*/*/temp |awk -F/ '{print
$4}' |sort -u
atk-native
at-spi2-core-native
pango-native
Is it the case the bbclass file should be altered to set this variable for the
-native, or does each package need to be modified individually?
Jason.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
Generally because generating introspection data is disabled for native
packages, as a matter of policy (do not build something which is
unused and untested).
If you could add
EXTRA_OEMESON_append_class-native = " ${GI_DISABLE_FLAG}"
to the gdk-pixbuf recipe, and re-test (without your fix, to be extra
sure) that g-ir-scanner is not invoked and nothing shows up in its
cache, I would appreciate.
Alex
On Thu, 11 Apr 2019 at 15:10, Jason Wessel wrote:
>
>
> Please understand I have no idea how gdk-pixbuf-native is supposed to
> compile. Perhaps you can elaborate further as to why g-ir-scanner cannot be
> called in this case. I did not observe any obvious way that the g-ir-scanner
> was explicitly disabled for the build of the -native package with in the
> do_configure stage.
>
> Looking at the log files from the compilation phase it appears to use meson
> as the build tool. The compile log file indicates that it is using the
> pkg-config tool to find g-ir-scanner and subsequently use it.
>
>
> Log file:
> x86_64-linux/gdk-pixbuf-native/2.38.0-r0/build/meson-logs/meson-log.txt
> ===
> Called
> `/poky/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/recipe-sysroot-native/usr/bin/pkg-config-native
> --variable=g_ir_scanner gobject-introspection-1.0` -> 0
> /poky/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner
> Got pkgconfig variable g_ir_scanner :
> /poky/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner
>
> ===
>
>
> Jason.
>
> On 4/11/19 6:14 AM, Alexander Kanavin wrote:
> > gdk-pixbuf-native should not be running g-ir-scanner at all, as we
> > explicitly disable this for native builds. Can you please look into
> > why it is happening, because the patch is really treating the symptom
> > rather than the problem.
> >
> > Alex
> >
> > On Wed, 10 Apr 2019 at 23:54, Jason Wessel
> > wrote:
> >>
> >> Investigation of an end user going over their quota in the user's home
> >> directory showed that the gobject-instrospection is writing files into
> >> the ~/.cache/g-ir-scanner when building -native packages. The test
> >> package in this case was gdk-pixbuf-native.
> >>
> >> Setting the GI_SCANNER_DISABLE_CACHE in the bbclass should be all that
> >> is needed. The qemu wrapper was already setting this properly, but we
> >> also need it for the -native builds.
> >>
> >> meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:131:
> >> export GI_SCANNER_DISABLE_CACHE=1
> >>
> >> Signed-off-by: Jason Wessel
> >> ---
> >> meta/classes/gobject-introspection.bbclass | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/meta/classes/gobject-introspection.bbclass
> >> b/meta/classes/gobject-introspection.bbclass
> >> index 4ceb0c68b1..359620fba7 100644
> >> --- a/meta/classes/gobject-introspection.bbclass
> >> +++ b/meta/classes/gobject-introspection.bbclass
> >> @@ -27,6 +27,9 @@ DEPENDS_append_class-nativesdk = "
> >> gobject-introspection-native"
> >> # This is used by introspection tools to find .gir includes
> >> export XDG_DATA_DIRS = "${STAGING_DATADIR}:${STAGING_LIBDIR}"
> >>
> >> +# Disable writing to $HOME/.cache/g-ir-scanner
> >> +export GI_SCANNER_DISABLE_CACHE = "1"
> >> +
> >> do_configure_prepend_class-target () {
> >> # introspection.m4 pre-packaged with upstream tarballs does not yet
> >> # have our fixes
> >> --
> >> 2.17.1
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dnf: Enable nativesdk
On Thu, 2019-04-11 at 14:16 +0200, Alexander Kanavin wrote: > Presumably to be able to put dnf into SDKs? nativesdk-dnf would depend on nativesdk-python3-core, not python3-core though? nativesdk-dnf doesn't run target packages? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
Elfutils-Exception no longer exists after upstream release 0.154
and commit:
commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
Author: Mark Wielaard
Date: Tue Jun 5 17:15:16 2012 +0200
NEWS file in the sources says this about switch from GPLv2 to
GPLv3 license:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
363 programs. There is now also a formal CONTRIBUTING document describing how
to
364 submit patches.
libasm, libdw and libelf are thus covered optionally by GPLv2 license.
See also Debian copyright summary for elfutils:
https://tracker.debian.org/media/packages/e/elfutils/copyright-0.175-1
Signed-off-by: Mikko Rapeli
---
meta/conf/licenses.conf | 2 +-
meta/files/common-licenses/Elfutils-Exception| 12
meta/recipes-devtools/elfutils/elfutils_0.176.bb | 14 +-
3 files changed, 14 insertions(+), 14 deletions(-)
delete mode 100644 meta/files/common-licenses/Elfutils-Exception
v1:
http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281124.html
v2:
http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281127.html
* removed Elfutils-Exception
v3:
* rebase to latest master branch with elfutils 0.176
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 1058084..7b01c57 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0
CC-BY-SA-2.5 CC-BY-SA-3.0
SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B CECILL-C"
SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 EFL-2.0"
-SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0
ErlPL-1.1"
+SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair Frameworx-1.0"
SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
diff --git a/meta/files/common-licenses/Elfutils-Exception
b/meta/files/common-licenses/Elfutils-Exception
deleted file mode 100644
index 627d769..000
--- a/meta/files/common-licenses/Elfutils-Exception
+++ /dev/null
@@ -1,12 +0,0 @@
- This file describes the limits of the Exception under which you are allowed
- to distribute Non-GPL Code in linked combination with Red Hat elfutils.
- For the full text of the license, please see one of the header files
- included with the source distribution or the file COPYING found in the
- top level directory of the source.
-
- The Approved Interfaces are the functions declared in the files:
-
- libelf.h
- libdw.h
- libdwfl.h
-
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
index fd901c9..cd824e2 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
@@ -1,7 +1,7 @@
SUMMARY = "Utilities and libraries for handling compiled object files"
HOMEPAGE = "https://sourceware.org/elfutils";
SECTION = "base"
-LICENSE = "(GPLv3 & Elfutils-Exception)"
+LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
DEPENDS = "libtool bzip2 zlib virtual/libintl"
DEPENDS_append_libc-musl = " argp-standalone fts "
@@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
# Package utilities separately
PACKAGES =+ "${PN}-binutils libelf libasm libdw"
+
+# shared libraries are licensed GPLv2 or GPLv3+, binaries GPLv3+
+# according to NEWS file:
+# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
+# programs. There is now also a formal CONTRIBUTING document describing how to
+# submit patches."
+LICENSE_${PN}-binutils = "GPLv3+"
+LICENSE_${PN} = "GPLv3+"
+LICENSE_libelf = "GPLv2 | LGPLv3+"
+LICENSE_libasm = "GPLv2 | LGPLv3+"
+LICENSE_libdw = "GPLv2 | LGPLv3+"
+
FILES_${PN}-binutils = "\
${bindir}/eu-addr2line \
${bindir}/eu-ld \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
Sorry, this wasn't rebased to latest master with elfutils 0.176. I'll rebase and resend. -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
Please understand I have no idea how gdk-pixbuf-native is supposed to compile.
Perhaps you can elaborate further as to why g-ir-scanner cannot be called in
this case. I did not observe any obvious way that the g-ir-scanner was
explicitly disabled for the build of the -native package with in the
do_configure stage.
Looking at the log files from the compilation phase it appears to use meson as
the build tool. The compile log file indicates that it is using the pkg-config
tool to find g-ir-scanner and subsequently use it.
Log file:
x86_64-linux/gdk-pixbuf-native/2.38.0-r0/build/meson-logs/meson-log.txt
===
Called
`/poky/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/recipe-sysroot-native/usr/bin/pkg-config-native
--variable=g_ir_scanner gobject-introspection-1.0` -> 0
/poky/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner
Got pkgconfig variable g_ir_scanner :
/poky/build/tmp/work/x86_64-linux/gdk-pixbuf-native/2.38.0-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/bin/g-ir-scanner
===
Jason.
On 4/11/19 6:14 AM, Alexander Kanavin wrote:
> gdk-pixbuf-native should not be running g-ir-scanner at all, as we
> explicitly disable this for native builds. Can you please look into
> why it is happening, because the patch is really treating the symptom
> rather than the problem.
>
> Alex
>
> On Wed, 10 Apr 2019 at 23:54, Jason Wessel wrote:
>>
>> Investigation of an end user going over their quota in the user's home
>> directory showed that the gobject-instrospection is writing files into
>> the ~/.cache/g-ir-scanner when building -native packages. The test
>> package in this case was gdk-pixbuf-native.
>>
>> Setting the GI_SCANNER_DISABLE_CACHE in the bbclass should be all that
>> is needed. The qemu wrapper was already setting this properly, but we
>> also need it for the -native builds.
>>
>> meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:131:
>> export GI_SCANNER_DISABLE_CACHE=1
>>
>> Signed-off-by: Jason Wessel
>> ---
>> meta/classes/gobject-introspection.bbclass | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/classes/gobject-introspection.bbclass
>> b/meta/classes/gobject-introspection.bbclass
>> index 4ceb0c68b1..359620fba7 100644
>> --- a/meta/classes/gobject-introspection.bbclass
>> +++ b/meta/classes/gobject-introspection.bbclass
>> @@ -27,6 +27,9 @@ DEPENDS_append_class-nativesdk = "
>> gobject-introspection-native"
>> # This is used by introspection tools to find .gir includes
>> export XDG_DATA_DIRS = "${STAGING_DATADIR}:${STAGING_LIBDIR}"
>>
>> +# Disable writing to $HOME/.cache/g-ir-scanner
>> +export GI_SCANNER_DISABLE_CACHE = "1"
>> +
>> do_configure_prepend_class-target () {
>> # introspection.m4 pre-packaged with upstream tarballs does not yet
>> # have our fixes
>> --
>> 2.17.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v1] weston: introduce meson build on v5.0.94
Signed-off-by: Jean-Francois Dagenais
---
Changes in v1:
- v5.0.94 is a pre-release, so this is preliminary work. I wanted to
submit this imperfect recipe now because I have to put aside working
on weston for a while. Since I put a reasonable amount of work into
this, I thought it may be useful for others to get the ball rolling
quicker. Enjoy!
meta/recipes-graphics/wayland/weston_git.bb | 102
1 file changed, 102 insertions(+)
create mode 100644 meta/recipes-graphics/wayland/weston_git.bb
diff --git a/meta/recipes-graphics/wayland/weston_git.bb
b/meta/recipes-graphics/wayland/weston_git.bb
new file mode 100644
index 00..f591550f9a
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston_git.bb
@@ -0,0 +1,102 @@
+SUMMARY = "Weston, a Wayland compositor"
+DESCRIPTION = "Weston is the reference implementation of a Wayland compositor"
+HOMEPAGE = "http://wayland.freedesktop.org";
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d79ee9e66bb0f95d3386a7acae780b70 \
+
file://libweston/compositor.c;endline=27;md5=6c53bbbd99273f4f7c4affa855c33c0a"
+
+SRC_URI = "git://github.com/wayland-project/weston \
+ file://weston.png \
+ file://weston.desktop \
+ file://xwayland.weston-start \
+"
+
+S = "${WORKDIR}/git"
+SRCREV = "cc64cc3717ab39882df37bc244d1ac6cf8526f93"
+PV = "5.0.94+git${SRCPV}"
+# from meson.build:libweston_major
+WESTON_MAJOR_VERSION = "6"
+
+UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html";
+
+inherit meson useradd distro_features_check
+# depends on virtual/egl
+REQUIRED_DISTRO_FEATURES = "opengl"
+
+DEPENDS = "libxkbcommon pixman cairo glib-2.0 jpeg"
+DEPENDS += "wayland wayland-protocols libinput virtual/egl pango
wayland-native"
+
+EXTRA_OEMESON = " \
+-Dbackend-default=auto \
+-Dimage-jpeg=true \
+ -Dsimple-dmabuf-drm= \
+"
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'drm
fbdev egl', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland',
'xwayland', '', d)} \
+ ${@bb.utils.filter('DISTRO_FEATURES', 'systemd x11', d)} \
+ launch tools shell-desktop demo-clients simple-clients"
+
+WESTON_TOOLS ?= "calibrator,debug,info,terminal,touch-calibrator"
+
+#
+# see https://github.com/wayland-project/weston/raw/master/meson_options.txt
+#
+PACKAGECONFIG[drm] = "-Ddrm-compositor=true,-Ddrm-compositor=false,drm udev
virtual/mesa virtual/libgbm mtdev"
+PACKAGECONFIG[vaapi] =
"-Dbackend-drm-screencast-vaapir=true,-Dbackend-drm-screencast-vaapi=false,libva
drm"
+PACKAGECONFIG[headless] = "-Dbackend-headless=true,-Dbackend-headless=false,"
+PACKAGECONFIG[rdp] = "-Dbackend-rdp=true,-Dbackend-rdp=false,freerdp"
+PACKAGECONFIG[screenshare] = "-Dscreenshare=true
-Dshell-fullscreen=true,-Dscreenshare=false"
+PACKAGECONFIG[wayland] =
"-Dbackend-wayland=true,-Dbackend-wayland=false,virtual/mesa"
+PACKAGECONFIG[x11] = "-Dbackend-x11=true,-Dbackend-x11=false,libxcb"
+PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb libxcursor"
+PACKAGECONFIG[systemd] =
"-Dlauncher-logind=true,-Dlauncher-logind=false,systemd dbus"
+PACKAGECONFIG[remote] = "-Dremoting=true,-Dremoting=false, gstreamer"
+PACKAGECONFIG[shell-desktop] = "-Dshell-desktop=true,-Dshell-desktop=false"
+PACKAGECONFIG[shell-fullscreen] =
"-Dshell-fullscreen=true,-Dshell-fullscreen=false"
+PACKAGECONFIG[shell-ivi] = "-Dshell-ivi=true,-Dshell-ivi=false"
+PACKAGECONFIG[fbdev] = "-Dbackend-fbdev=true,-Dbackend-fbdev=false,libinput
mtdev udev (>=136)"
+PACKAGECONFIG[egl] = "-Drender-gl=true,-Drender-gl=false"
+PACKAGECONFIG[lcms] =
"-Dcolor-management-lcms=true,-Dcolor-management-lcms=false,lcms"
+PACKAGECONFIG[colord] =
"-Dcolor-management-colord=true,-Dcolor-management-colord=false,lcms"
+PACKAGECONFIG[launch] = "-Dweston-launch=true,-Dweston-launch=false,drm libpam
systemd"
+PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp"
+PACKAGECONFIG[tools] = "-Dtools=${WESTON_TOOLS},-Dtools=,"
+PACKAGECONFIG[demo-clients] = "-Ddemo-clients=true,-Ddemo-clients=false"
+PACKAGECONFIG[simple-clients] = "-Dsimple-clients=all,-Dsimple-clients="
+PACKAGECONFIG[wcap-decode] = "-Dwcap-decode=true,-Dwcap-decode=false"
+PACKAGECONFIG[test-junit-xml] =
"-Dtest-junit-xml=true,-Dtest-junit-xml=false,libxml"
+
+do_install_append() {
+ # If X11, ship a desktop file to launch it
+ if [ "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}" ]; then
+ install -d ${D}${datadir}/applications
+ install ${WORKDIR}/weston.desktop ${D}${datadir}/applications
+
+ install -d ${D}${datadir}/icons/hicolor/48x48/apps
+ install ${WORKDIR}/weston.png
${D}${datadir}/icons/hicolor/48x48/apps
+ fi
+
+ if [ "${@bb.utils.contains('PACKAGECONFIG', 'xwayland', 'yes', 'no',
d)
Re: [OE-core] [[PATCH v2] kernel-devsrc: check for localversion files in the kernel source tree
On Thu, Apr 11, 2019 at 3:29 AM Beniamin Sandu wrote:
>
> The kernel-devsrc rework doesn't take into account localversion
> files in the kernel source tree. This might result in modules with an
> incomplete version magic when building out-of-tree using the SDK.
>
> Before:
> root@qemux86:~# insmod hello.ko
> [ 42.000212] hello: version magic '5.0.3-yocto-standard SMP preempt
> mod_unload PENTIUMM ' should be '5.0.3-my-custom-release-yocto-standard
> SMP preempt mod_unload PENTIUMM '
> [ 42.008200] hello: version magic '5.0.3-yocto-standard SMP preempt
> mod_unload PENTIUMM ' should be '5.0.3-my-custom-release-yocto-standard
> SMP preempt mod_unload PENTIUMM '
> insmod: can't insert 'hello.ko': invalid module format
>
> After:
> root@qemux86:~# insmod hello.ko
> [ 39.094288] hello: loading out-of-tree module taints kernel.
> [ 39.108044] Hello World!
>
> Signed-off-by: Beniamin Sandu
Looks good to me.
Acked-by: Bruce Ashfield
Richard, I assume you'll pick this up directly and don't want to wait
for me to queue and send it along with my next pull request.
Bruce
> ---
> meta/recipes-kernel/linux/kernel-devsrc.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 69a8eaef81..5ec5929735 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -228,6 +228,9 @@ do_install() {
>
> # required to build scripts/selinux/genheaders/genheaders
> cp -a --parents security/selinux/include/* $kerneldir/build/
> +
> + # copy any localversion files
> + cp -a localversion* $kerneldir/build/ 2>/dev/null || :
> )
>
> # Make sure the Makefile and version.h have a matching timestamp so that
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH] uboot-sign: add support for different u-boot configurations
This is done by concatenating the DTB with the kernels public key
to all built u-boot binaries. Furthermore the installation of all
the binaries is required.
Signed-off-by: Andreas Obergschwandtner
---
meta/classes/uboot-sign.bbclass | 85 +
1 file changed, 54 insertions(+), 31 deletions(-)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 9e3d1d6fc1..2da43655aa 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -45,49 +45,72 @@ UBOOT_NODTB_SYMLINK ?=
"u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
# Functions in this bbclass is for u-boot only
UBOOT_PN = "${@d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'}"
+concat_dtb_helper() {
+ if [ -e ${UBOOT_DTB_BINARY} ]; then
+ ln -sf ${UBOOT_DTB_IMAGE} ${DEPLOYDIR}/${UBOOT_DTB_BINARY}
+ ln -sf ${UBOOT_DTB_IMAGE} ${DEPLOYDIR}/${UBOOT_DTB_SYMLINK}
+ fi
+
+ if [ -f ${UBOOT_NODTB_BINARY} ]; then
+ install ${UBOOT_NODTB_BINARY} ${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
+ ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_SYMLINK}
+ ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_BINARY}
+ fi
+
+ # Concatenate U-Boot w/o DTB & DTB with public key
+ # (cf. kernel-fitimage.bbclass for more details)
+ deployed_uboot_dtb_binary='${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_IMAGE}'
+ if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom" ] && \
+ [ -e "$deployed_uboot_dtb_binary" ]; then
+ oe_runmake EXT_DTB=$deployed_uboot_dtb_binary
+ install ${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
+ elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e
"$deployed_uboot_dtb_binary" ]; then
+ cd ${DEPLOYDIR}
+ cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary | tee
${UBOOT_BINARY} > ${UBOOT_IMAGE}
+ elif [ -n "${UBOOT_DTB_BINARY}" ]; then
+ bbwarn "Failure while adding public key to u-boot binary.
Verified boot won't be available."
+ fi
+}
+
concat_dtb() {
if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" ]; then
mkdir -p ${DEPLOYDIR}
- if [ -e ${B}/${UBOOT_DTB_BINARY} ]; then
- ln -sf ${UBOOT_DTB_IMAGE}
${DEPLOYDIR}/${UBOOT_DTB_BINARY}
- ln -sf ${UBOOT_DTB_IMAGE}
${DEPLOYDIR}/${UBOOT_DTB_SYMLINK}
- fi
-
- if [ -f ${B}/${UBOOT_NODTB_BINARY} ]; then
-install ${B}/${UBOOT_NODTB_BINARY}
${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
-ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_SYMLINK}
-ln -sf ${UBOOT_NODTB_IMAGE} ${UBOOT_NODTB_BINARY}
- fi
-
- # Concatenate U-Boot w/o DTB & DTB with public key
- # (cf. kernel-fitimage.bbclass for more details)
-
deployed_uboot_dtb_binary='${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_IMAGE}'
- if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom"
] && \
- [ -e "$deployed_uboot_dtb_binary" ]; then
+ if [ -n "${UBOOT_CONFIG}" ]; then
+ for config in ${UBOOT_MACHINE}; do
+ cd ${B}/${config}
+ concat_dtb_helper
+ done
+ else
cd ${B}
- oe_runmake EXT_DTB=$deployed_uboot_dtb_binary
- install ${B}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
- elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e
"$deployed_uboot_dtb_binary" ]; then
- cd ${DEPLOYDIR}
- cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary |
tee ${B}/${UBOOT_BINARY} > ${UBOOT_IMAGE}
- elif [ -n "${UBOOT_DTB_BINARY}" ]; then
- bbwarn "Failure while adding public key to u-boot
binary. Verified boot won't be available."
+ concat_dtb_helper
fi
fi
}
# Install UBOOT_DTB_BINARY to datadir, so that kernel can use it for
# signing, and kernel will deploy UBOOT_DTB_BINARY after signs it.
+install_helper() {
+ if [ -f ${UBOOT_DTB_BINARY} ]; then
+ install -d ${D}${datadir}
+ # UBOOT_DTB_BINARY is a symlink to UBOOT_DTB_IMAGE, so we
+ # need both of them.
+ install ${UBOOT_DTB_BINARY} ${D}${datadir}/${UBOOT_DTB_IMAGE}
+ ln -sf ${UBOOT_DTB_IMAGE} ${D}${datadir}/${UBOOT_DTB_BINARY}
+ elif [ -n "${UBOOT_DTB_BINARY}" ]; then
+ bbwarn "${UBOOT_DTB_BINARY} not found"
+ fi
+}
+
do_install_append() {
if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" ]; then
- if [ -f ${B}/${UBOOT_DTB_BINARY} ]; then
- install -d ${D}${datadir}
- # UBOOT_DTB_BINARY is a symlink to UBOOT_DTB_
Re: [OE-core] [PATCH] dnf: Enable nativesdk
Presumably to be able to put dnf into SDKs?
Alex
On Thu, 11 Apr 2019 at 14:05, Richard Purdie
wrote:
>
> On Thu, 2019-04-11 at 13:19 +0200, Alexander Kanavin wrote:
> > On Thu, 11 Apr 2019 at 08:13, Zheng Ruoqin <
> > zhengrq.f...@cn.fujitsu.com> wrote:
> >
> > > +RDEPENDS_${PN}_class-nativesdk += " \
> > > + python3-core \
> > > + python3-codecs \
> > > + python3-netclient \
> > > + python3-email \
> > > + python3-threading \
> > > + python3-distutils \
> > > + python3-logging \
> > > + python3-fcntl \
> > > + librepo \
> > > + python3-shell \
> > > + libcomps \
> > > + libdnf \
> > > + python3-sqlite3 \
> > > + python3-compression \
> > > + python3-rpm \
> > > + python3-iniparse \
> > > + python3-json \
> > > + python3-curses \
> > > + python3-misc \
> > > + python3-gpg \
> > > + "
> > > +
> > > RRECOMMENDS_${PN}_class-target += "gnupg"
> >
> > Do not copy-paste large chunks like this please. Assign the
> > dependencies to a variable, and use it where needed.
>
> Its worse than that, those are target dependencies, why would nativesdk
> need them?
>
> Cheers,
>
> Richard
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dnf: Enable nativesdk
On Thu, 2019-04-11 at 13:19 +0200, Alexander Kanavin wrote:
> On Thu, 11 Apr 2019 at 08:13, Zheng Ruoqin <
> zhengrq.f...@cn.fujitsu.com> wrote:
>
> > +RDEPENDS_${PN}_class-nativesdk += " \
> > + python3-core \
> > + python3-codecs \
> > + python3-netclient \
> > + python3-email \
> > + python3-threading \
> > + python3-distutils \
> > + python3-logging \
> > + python3-fcntl \
> > + librepo \
> > + python3-shell \
> > + libcomps \
> > + libdnf \
> > + python3-sqlite3 \
> > + python3-compression \
> > + python3-rpm \
> > + python3-iniparse \
> > + python3-json \
> > + python3-curses \
> > + python3-misc \
> > + python3-gpg \
> > + "
> > +
> > RRECOMMENDS_${PN}_class-target += "gnupg"
>
> Do not copy-paste large chunks like this please. Assign the
> dependencies to a variable, and use it where needed.
Its worse than that, those are target dependencies, why would nativesdk
need them?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dnf: Enable nativesdk
On Thu, 11 Apr 2019 at 08:13, Zheng Ruoqin wrote:
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -101,6 +101,7 @@ toolchain_shared_env_script () {
> echo 'export CPPFLAGS="${TARGET_CPPFLAGS}"' >> $script
> echo 'export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"' >> $script
> echo 'export OECORE_DISTRO_VERSION="${DISTRO_VERSION}"' >> $script
> + echo 'export MACHINE_ARCH=${MACHINE_ARCH}' >> $script
Please explain why this change in the commit.
> +RDEPENDS_${PN}_class-nativesdk += " \
> + python3-core \
> + python3-codecs \
> + python3-netclient \
> + python3-email \
> + python3-threading \
> + python3-distutils \
> + python3-logging \
> + python3-fcntl \
> + librepo \
> + python3-shell \
> + libcomps \
> + libdnf \
> + python3-sqlite3 \
> + python3-compression \
> + python3-rpm \
> + python3-iniparse \
> + python3-json \
> + python3-curses \
> + python3-misc \
> + python3-gpg \
> + "
> +
> RRECOMMENDS_${PN}_class-target += "gnupg"
Do not copy-paste large chunks like this please. Assign the
dependencies to a variable, and use it where needed.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gobject-introspection.bbclass: Disable writing to $HOME/.cache/g-ir-scanner
gdk-pixbuf-native should not be running g-ir-scanner at all, as we
explicitly disable this for native builds. Can you please look into
why it is happening, because the patch is really treating the symptom
rather than the problem.
Alex
On Wed, 10 Apr 2019 at 23:54, Jason Wessel wrote:
>
> Investigation of an end user going over their quota in the user's home
> directory showed that the gobject-instrospection is writing files into
> the ~/.cache/g-ir-scanner when building -native packages. The test
> package in this case was gdk-pixbuf-native.
>
> Setting the GI_SCANNER_DISABLE_CACHE in the bbclass should be all that
> is needed. The qemu wrapper was already setting this properly, but we
> also need it for the -native builds.
>
> meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:131:
> export GI_SCANNER_DISABLE_CACHE=1
>
> Signed-off-by: Jason Wessel
> ---
> meta/classes/gobject-introspection.bbclass | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/classes/gobject-introspection.bbclass
> b/meta/classes/gobject-introspection.bbclass
> index 4ceb0c68b1..359620fba7 100644
> --- a/meta/classes/gobject-introspection.bbclass
> +++ b/meta/classes/gobject-introspection.bbclass
> @@ -27,6 +27,9 @@ DEPENDS_append_class-nativesdk = "
> gobject-introspection-native"
> # This is used by introspection tools to find .gir includes
> export XDG_DATA_DIRS = "${STAGING_DATADIR}:${STAGING_LIBDIR}"
>
> +# Disable writing to $HOME/.cache/g-ir-scanner
> +export GI_SCANNER_DISABLE_CACHE = "1"
> +
> do_configure_prepend_class-target () {
> # introspection.m4 pre-packaged with upstream tarballs does not yet
> # have our fixes
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
Elfutils-Exception no longer exists after upstream release 0.154
and commit:
commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
Author: Mark Wielaard
Date: Tue Jun 5 17:15:16 2012 +0200
NEWS file in the sources says this about switch from GPLv2 to
GPLv3 license:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
363 programs. There is now also a formal CONTRIBUTING document describing how
to
364 submit patches.
libasm, libdw and libelf are thus covered optionally by GPLv2 license.
See also Debian copyright summary for elfutils:
https://tracker.debian.org/media/packages/e/elfutils/copyright-0.175-1
Signed-off-by: Mikko Rapeli
---
meta/conf/licenses.conf | 2 +-
meta/files/common-licenses/Elfutils-Exception| 12
meta/recipes-devtools/elfutils/elfutils_0.175.bb | 14 +-
3 files changed, 14 insertions(+), 14 deletions(-)
delete mode 100644 meta/files/common-licenses/Elfutils-Exception
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 1058084..7b01c57 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0
CC-BY-SA-2.5 CC-BY-SA-3.0
SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B CECILL-C"
SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 EFL-2.0"
-SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0
ErlPL-1.1"
+SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair Frameworx-1.0"
SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
diff --git a/meta/files/common-licenses/Elfutils-Exception
b/meta/files/common-licenses/Elfutils-Exception
deleted file mode 100644
index 627d769..000
--- a/meta/files/common-licenses/Elfutils-Exception
+++ /dev/null
@@ -1,12 +0,0 @@
- This file describes the limits of the Exception under which you are allowed
- to distribute Non-GPL Code in linked combination with Red Hat elfutils.
- For the full text of the license, please see one of the header files
- included with the source distribution or the file COPYING found in the
- top level directory of the source.
-
- The Approved Interfaces are the functions declared in the files:
-
- libelf.h
- libdw.h
- libdwfl.h
-
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.175.bb
b/meta/recipes-devtools/elfutils/elfutils_0.175.bb
index b0b9ddc..111fa1c 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.175.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.175.bb
@@ -1,7 +1,7 @@
SUMMARY = "Utilities and libraries for handling compiled object files"
HOMEPAGE = "https://sourceware.org/elfutils";
SECTION = "base"
-LICENSE = "(GPLv3 & Elfutils-Exception)"
+LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
DEPENDS = "libtool bzip2 zlib virtual/libintl"
DEPENDS_append_libc-musl = " argp-standalone fts "
@@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
# Package utilities separately
PACKAGES =+ "${PN}-binutils libelf libasm libdw"
+
+# shared libraries are licensed GPLv2 or GPLv3+, binaries GPLv3+
+# according to NEWS file:
+# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
+# programs. There is now also a formal CONTRIBUTING document describing how to
+# submit patches."
+LICENSE_${PN}-binutils = "GPLv3+"
+LICENSE_${PN} = "GPLv3+"
+LICENSE_libelf = "GPLv2 | LGPLv3+"
+LICENSE_libasm = "GPLv2 | LGPLv3+"
+LICENSE_libdw = "GPLv2 | LGPLv3+"
+
FILES_${PN}-binutils = "\
${bindir}/eu-addr2line \
${bindir}/eu-ld \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] elfutils: update LICENSE to include GPLv2 for shared libraries
On Thu, Apr 11, 2019 at 10:40:43AM +, openembedded-core-boun...@lists.openembedded.org wrote: > On Thu, Apr 11, 2019 at 12:48:40PM +0300, Mikko Rapeli wrote: > > NEWS file in the sources says this about switch from GPLv2 to > > GPLv3 license: > > > > https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362 > > > > 362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for > > stand-alone > > 363 programs. There is now also a formal CONTRIBUTING document describing > > how to > > 364 submit patches. > > > > libasm, libdw and libelf are thus covered optionally by GPLv2 license. > > > > Signed-off-by: Mikko Rapeli > > --- > > meta/recipes-devtools/elfutils/elfutils_0.175.bb | 14 +- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/meta/recipes-devtools/elfutils/elfutils_0.175.bb > > b/meta/recipes-devtools/elfutils/elfutils_0.175.bb > > index b0b9ddc..6d1279a 100644 > > --- a/meta/recipes-devtools/elfutils/elfutils_0.175.bb > > +++ b/meta/recipes-devtools/elfutils/elfutils_0.175.bb > > @@ -1,7 +1,7 @@ > > SUMMARY = "Utilities and libraries for handling compiled object files" > > HOMEPAGE = "https://sourceware.org/elfutils"; > > SECTION = "base" > > -LICENSE = "(GPLv3 & Elfutils-Exception)" > > +LICENSE = "(GPLv2 & LGPLv3+ & GPLv3+ & Elfutils-Exception)" > > Can anyone find the Elfutils-Exception in current 0.175 or sumo 0.170 sources? > > Debian is also listing libraries with GPLv2+ | LGPLv3+ and executables > with GPLv3+ in > > https://tracker.debian.org/media/packages/e/elfutils/copyright-0.176-1 > > Should I also drop the Elfutils-Exception? I will send a new version which drops Elfutils-Exception since it no longer exists after tag elfutils-0.154 and commit: commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2 Author: Mark Wielaard Date: Tue Jun 5 17:15:16 2012 +0200 Update name, license and contributor policy. * Change name from "Red Hat elfutils" to "elfutils". * Update license of standalone tools and test from GPLv2 to GPLv3+. * Change license of libraries from GPLv2+exception to GPLv2/LGPLv3+. * Add Developer Certificate of Origin based contributor policy. top-level: - COPYING: Upgraded from GPLv2 to GPLv3. - CONTRIBUTING, COPYING-GPLv2, COPYING-LGPLv3: New files. - NEWS: Added note about new contribution and license policy. - Makefile.am: Updated to GPLv3, added new files to EXTRA_DIST. - configure.ac: Update to GPLv3, changed AC_INIT name to 'elfutils'. backends, lib, libasm, libcpu, libdw, libdwfl, libebl, libelf: - All files updated to GPLv2/LGPLv3+. Except some very small files (<5 lines) which didn't have any headers at all before, the linker .maps files and the libcpu/defs files which only contain data and libelf/elf.h which comes from glibc and is under LGPLv2+. config: - elfutils.spec.in: Add new License: headers and new %doc files. - Update all license headers to GPLv2/LGPLv3+ for files used by libs. src, tests: - All files updated to GPLv3+. Except for the test bz2 data files, the linker maps and script files and some very small files (<5 lines) that don't have any headers. Signed-off-by: Richard Fontana Signed-off-by: Mark Wielaard -Mikko -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] elfutils: update LICENSE to include GPLv2 for shared libraries
On Thu, Apr 11, 2019 at 12:48:40PM +0300, Mikko Rapeli wrote:
> NEWS file in the sources says this about switch from GPLv2 to
> GPLv3 license:
>
> https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
>
> 362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> stand-alone
> 363 programs. There is now also a formal CONTRIBUTING document describing
> how to
> 364 submit patches.
>
> libasm, libdw and libelf are thus covered optionally by GPLv2 license.
>
> Signed-off-by: Mikko Rapeli
> ---
> meta/recipes-devtools/elfutils/elfutils_0.175.bb | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/elfutils/elfutils_0.175.bb
> b/meta/recipes-devtools/elfutils/elfutils_0.175.bb
> index b0b9ddc..6d1279a 100644
> --- a/meta/recipes-devtools/elfutils/elfutils_0.175.bb
> +++ b/meta/recipes-devtools/elfutils/elfutils_0.175.bb
> @@ -1,7 +1,7 @@
> SUMMARY = "Utilities and libraries for handling compiled object files"
> HOMEPAGE = "https://sourceware.org/elfutils";
> SECTION = "base"
> -LICENSE = "(GPLv3 & Elfutils-Exception)"
> +LICENSE = "(GPLv2 & LGPLv3+ & GPLv3+ & Elfutils-Exception)"
Can anyone find the Elfutils-Exception in current 0.175 or sumo 0.170 sources?
Debian is also listing libraries with GPLv2+ | LGPLv3+ and executables
with GPLv3+ in
https://tracker.debian.org/media/packages/e/elfutils/copyright-0.176-1
Should I also drop the Elfutils-Exception?
-Mikko
> LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> DEPENDS = "libtool bzip2 zlib virtual/libintl"
> DEPENDS_append_libc-musl = " argp-standalone fts "
> @@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
>
> # Package utilities separately
> PACKAGES =+ "${PN}-binutils libelf libasm libdw"
> +
> +# shared libraries are licensed GPLv2 or GPLv3+, binaries GPLv3+
> +# according to NEWS file:
> +# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> stand-alone
> +# programs. There is now also a formal CONTRIBUTING document describing how
> to
> +# submit patches."
> +LICENSE_${PN}-binutils = "GPLv3+"
> +LICENSE_${PN} = "GPLv3+"
> +LICENSE_libelf = "GPLv2 | LGPLv3+"
> +LICENSE_libasm = "GPLv2 | LGPLv3+"
> +LICENSE_libdw = "GPLv2 | LGPLv3+"
> +
> FILES_${PN}-binutils = "\
> ${bindir}/eu-addr2line \
> ${bindir}/eu-ld \
> --
> 1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] elfutils: update LICENSE to include GPLv2 for shared libraries
NEWS file in the sources says this about switch from GPLv2 to
GPLv3 license:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
363 programs. There is now also a formal CONTRIBUTING document describing how
to
364 submit patches.
libasm, libdw and libelf are thus covered optionally by GPLv2 license.
Signed-off-by: Mikko Rapeli
---
meta/recipes-devtools/elfutils/elfutils_0.175.bb | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.175.bb
b/meta/recipes-devtools/elfutils/elfutils_0.175.bb
index b0b9ddc..6d1279a 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.175.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.175.bb
@@ -1,7 +1,7 @@
SUMMARY = "Utilities and libraries for handling compiled object files"
HOMEPAGE = "https://sourceware.org/elfutils";
SECTION = "base"
-LICENSE = "(GPLv3 & Elfutils-Exception)"
+LICENSE = "(GPLv2 & LGPLv3+ & GPLv3+ & Elfutils-Exception)"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
DEPENDS = "libtool bzip2 zlib virtual/libintl"
DEPENDS_append_libc-musl = " argp-standalone fts "
@@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
# Package utilities separately
PACKAGES =+ "${PN}-binutils libelf libasm libdw"
+
+# shared libraries are licensed GPLv2 or GPLv3+, binaries GPLv3+
+# according to NEWS file:
+# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
stand-alone
+# programs. There is now also a formal CONTRIBUTING document describing how to
+# submit patches."
+LICENSE_${PN}-binutils = "GPLv3+"
+LICENSE_${PN} = "GPLv3+"
+LICENSE_libelf = "GPLv2 | LGPLv3+"
+LICENSE_libasm = "GPLv2 | LGPLv3+"
+LICENSE_libdw = "GPLv2 | LGPLv3+"
+
FILES_${PN}-binutils = "\
${bindir}/eu-addr2line \
${bindir}/eu-ld \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Upgrade from 2019.01 to 2019.04
On Wed, 2019-04-10 at 17:23 +, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> meta/recipes-bsp/u-boot/u-boot-common.inc | 2
> +-
> .../{u-boot-fw-utils_2019.01.bb => u-boot-fw-utils_2019.04.bb} | 0
> .../u-boot/{u-boot-tools_2019.01.bb => u-boot-tools_2019.04.bb} | 0
> .../recipes-bsp/u-boot/{u-boot_2019.01.bb => u-boot_2019.04.bb} | 0
> 4 files changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2019.01.bb => u-
> boot-fw-utils_2019.04.bb} (100%)
> rename meta/recipes-bsp/u-boot/{u-boot-tools_2019.01.bb => u-boot-
> tools_2019.04.bb} (100%)
> rename meta/recipes-bsp/u-boot/{u-boot_2019.01.bb => u-
> boot_2019.04.bb} (100%)
Breaks beaglebone-yocto:
https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/490
https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/489
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cogl: fix compile error caused by -Werror=maybe-uninitialized
From: Changqing Li
When enable DEBUG_BUILD, cogl compile failed with error:
| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error:
'gltype' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
| *out_gltype = gltype;
| ^~~~
| ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error:
'glintformat' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
| *out_glintformat = glintformat;
| ~^
Source:
https://gitlab.gnome.org/GNOME/cogl/blob/master/cogl/driver/gl/gles/cogl-driver-gles.c
it can handle correctly, so fix with -Wnoerror
Signed-off-by: Changqing Li
---
meta/recipes-graphics/cogl/cogl-1.0.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc
b/meta/recipes-graphics/cogl/cogl-1.0.inc
index 7a79aa7..3e392fa 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -31,6 +31,7 @@ EXTRA_OECONF += "--enable-examples-install\
--disable-gles1\
--disable-cairo\
"
+DEBUG_OPTIMIZATION_append = " -Wno-error=maybe-uninitialized"
# OpenGL/GLX
PACKAGECONFIG[glx] = "--enable-gl --enable-glx,--disable-gl
--disable-glx,${EDEPENDS_GL} ${EDEPENDS_X11},${ERDEPENDS_GL}"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [[PATCH v2] kernel-devsrc: check for localversion files in the kernel source tree
The kernel-devsrc rework doesn't take into account localversion
files in the kernel source tree. This might result in modules with an
incomplete version magic when building out-of-tree using the SDK.
Before:
root@qemux86:~# insmod hello.ko
[ 42.000212] hello: version magic '5.0.3-yocto-standard SMP preempt
mod_unload PENTIUMM ' should be '5.0.3-my-custom-release-yocto-standard
SMP preempt mod_unload PENTIUMM '
[ 42.008200] hello: version magic '5.0.3-yocto-standard SMP preempt
mod_unload PENTIUMM ' should be '5.0.3-my-custom-release-yocto-standard
SMP preempt mod_unload PENTIUMM '
insmod: can't insert 'hello.ko': invalid module format
After:
root@qemux86:~# insmod hello.ko
[ 39.094288] hello: loading out-of-tree module taints kernel.
[ 39.108044] Hello World!
Signed-off-by: Beniamin Sandu
---
meta/recipes-kernel/linux/kernel-devsrc.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 69a8eaef81..5ec5929735 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -228,6 +228,9 @@ do_install() {
# required to build scripts/selinux/genheaders/genheaders
cp -a --parents security/selinux/include/* $kerneldir/build/
+
+ # copy any localversion files
+ cp -a localversion* $kerneldir/build/ 2>/dev/null || :
)
# Make sure the Makefile and version.h have a matching timestamp so that
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Eclipse support dropped with immediate effect
On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote: > > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote: > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote: > > > On 4/9/19 8:52 PM, Richard Purdie wrote: > > > > I'm sorry to have to say this but the project is terminating > > > > its > > > > official eclipse plugin support with immediate effect. > > > Does this affect the stable branches as well? > > Yes, I think we'll just be removing the target from the autobuilder > > entirely. > > Have we every removed a feature from a release? Do we need to doc > this ? Its not so much remove as not release. No, we haven't and yes, we do need to document it in the release notes. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] ruby: add ptest
From: Changqing Li
Signed-off-by: Changqing Li
---
meta/recipes-devtools/ruby/ruby.inc | 2 +-
meta/recipes-devtools/ruby/ruby/run-ptest | 13 +
meta/recipes-devtools/ruby/ruby_2.5.3.bb | 10 ++
3 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/ruby/ruby/run-ptest
diff --git a/meta/recipes-devtools/ruby/ruby.inc
b/meta/recipes-devtools/ruby/ruby.inc
index 28e21fe..1ecd087 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -24,7 +24,7 @@ SRC_URI =
"http://cache.ruby-lang.org/pub/ruby/${SHRT_VER}/ruby-${PV}.tar.gz \
"
UPSTREAM_CHECK_URI = "https://www.ruby-lang.org/en/downloads/";
-inherit autotools
+inherit autotools ptest
# This snippet lets compiled extensions which rely on external libraries,
diff --git a/meta/recipes-devtools/ruby/ruby/run-ptest
b/meta/recipes-devtools/ruby/ruby/run-ptest
new file mode 100644
index 000..de7c415
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/run-ptest
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+test_fullname=`find test -name test_*.rb`
+
+for i in ${test_fullname}; do
+ ruby ./test/runner.rb ${i} 2>&1 > /dev/null
+ ret=$?
+ if [ $ret != 0 ]; then
+ echo "FAIL: ${i}"
+ else
+ echo "PASS: ${i}"
+ fi
+done
diff --git a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
b/meta/recipes-devtools/ruby/ruby_2.5.3.bb
index 173b44b..519daf2 100644
--- a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.5.3.bb
@@ -3,6 +3,7 @@ require ruby.inc
SRC_URI += " \
file://ruby-CVE-2017-9226.patch \
file://ruby-CVE-2017-9228.patch \
+ file://run-ptest \
"
SRC_URI[md5sum] = "20c85b67846d49622ef3b24230803fef"
@@ -55,6 +56,13 @@ do_install_append_class-target () {
}
+do_install_ptest () {
+cp -rf ${S}/test ${D}${PTEST_PATH}/
+cp -r ${S}/include ${D}/${libdir}/ruby/
+test_case_rb=`grep rubygems/test_case.rb ${B}/.installed.list`
+sed -i -e 's:../../../test/:../../../ptest/test/:g' ${D}/$test_case_rb
+}
+
PACKAGES =+ "${PN}-ri-docs ${PN}-rdoc"
SUMMARY_${PN}-ri-docs = "ri (Ruby Interactive) documentation for the Ruby
standard library"
@@ -67,4 +75,6 @@ FILES_${PN}-rdoc += "${libdir}/ruby/*/rdoc ${bindir}/rdoc"
FILES_${PN} += "${datadir}/rubygems"
+FILES_${PN}-ptest_append_class-target += "${libdir}/ruby/include"
+
BBCLASSEXTEND = "native"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] ruby: make ext module fiddle can compile success
From: Changqing Li
ext module fiddle depend on libffi, in ruby source tree,
there is in internal libffi in case target platfrom don't
install libffi, but autotools.bbclass delete configure
under libffi and not run autoreconf to regenerate one.so
we met this error:
ruby-2.5.3/ext/fiddle/libffi-3.2.1/configure: No such file or directory
the fix is add depend and extra_oeconf to use libffi in the system
Signed-off-by: Changqing Li
---
meta/recipes-devtools/ruby/ruby.inc | 2 +-
meta/recipes-devtools/ruby/ruby_2.5.3.bb | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/ruby/ruby.inc
b/meta/recipes-devtools/ruby/ruby.inc
index eaf5d13..28e21fe 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = "\
file://LEGAL;md5=23a79bb4c1a40f6cc9bcb6f4e7c39799 \
"
-DEPENDS = "ruby-native zlib openssl tcl libyaml gdbm readline"
+DEPENDS = "ruby-native zlib openssl tcl libyaml gdbm readline libffi"
DEPENDS_class-native = "openssl-native libyaml-native readline-native"
SHRT_VER = "${@oe.utils.trim_version("${PV}", 2)}"
diff --git a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
b/meta/recipes-devtools/ruby/ruby_2.5.3.bb
index 3fb427e..173b44b 100644
--- a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.5.3.bb
@@ -28,6 +28,7 @@ EXTRA_OECONF = "\
--disable-dtrace \
--enable-shared \
--enable-load-relative \
+--with-pkg-config=pkg-config \
"
do_install() {
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
