Re: [OE-core] [PATCH] xserver-xorg: upgrade 1.20.11 -> 21.0.99.1
This is a development snapshot, should not be used.
Alex
On Thu 8. Jul 2021 at 2.18, wangmy wrote:
> 0001-test-xtest-Initialize-array-with-braces.patch
> pkgconfig.patch
> sdksyms-no-build-path.patch
> removed since they're included in 21.0.99.1
>
> refresh 0001-Avoid-duplicate-definitions-of-IOPortBase.patch
>
> Signed-off-by: Wang Mingyu
> ---
> .../xorg-xserver/xserver-xorg.inc | 3 +-
> ...-duplicate-definitions-of-IOPortBase.patch | 16 +-
> ...t-xtest-Initialize-array-with-braces.patch | 36 -
> .../xorg-xserver/xserver-xorg/pkgconfig.patch | 34 -
> .../xserver-xorg/sdksyms-no-build-path.patch | 50 ---
> ...g_1.20.11.bb => xserver-xorg_21.0.99.1.bb} | 6 +--
> 6 files changed, 4 insertions(+), 141 deletions(-)
> delete mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
> delete mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/pkgconfig.patch
> delete mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/sdksyms-no-build-path.patch
> rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.20.11.bb =>
> xserver-xorg_21.0.99.1.bb} (77%)
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> index da025171db..7bbff0073b 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> @@ -65,6 +65,7 @@ PACKAGES =+ "${PN}-sdl \
> ${PN}-module-xaa \
> ${PN}-module-libxf1bpp \
> ${PN}-module-libxf4bpp \
> +${PN}-input-modules \
> xf86-video-modesetting"
>
> SUMMARY_xf86-video-modesetting = "X.Org X server -- modesetting display
> driver"
> @@ -101,6 +102,7 @@ FILES_${PN}-module-exa =
> "${libdir}/xorg/modules/libexa.so"
> FILES_${PN}-module-xaa = "${libdir}/xorg/modules/libxaa.so"
> FILES_${PN}-module-libxf1bpp = "${libdir}/xorg/modules/libxf1bpp.so"
> FILES_${PN}-module-libxf4bpp = "${libdir}/xorg/modules/libxf4bpp.so"
> +FILES_${PN}-input-modules = "${libdir}/xorg/modules/input/*drv*"
> FILES_xf86-video-modesetting =
> "${libdir}/xorg/modules/drivers/modesetting_drv.so"
>
> EXTRA_OECONF += "--with-fop=no \
> @@ -116,7 +118,6 @@ EXTRA_OECONF += "--with-fop=no \
> --sysconfdir=/etc/X11 \
> --localstatedir=/var \
> --with-xkb-output=/var/lib/xkb \
> - --with-os-name=Linux \
> "
>
> OPENGL_PKGCONFIGS = "dri glx glamor dri3 xshmfence"
> diff --git
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
> index 4737040675..d876958898 100644
> ---
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
> +++
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
> @@ -11,23 +11,9 @@ compiler.h:528: multiple definition of `IOPortBase';
> Upstream-Status: Pending
> Signed-off-by: Khem Raj
> ---
> - hw/xfree86/common/compiler.h| 2 +-
> hw/xfree86/os-support/linux/lnx_video.c | 1 +
> - 2 files changed, 2 insertions(+), 1 deletion(-)
> + 1 files changed, 1 insertions(+), 0 deletion(-)
>
> -diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
> -index 2b2008b..c7d617e 100644
> a/hw/xfree86/common/compiler.h
> -+++ b/hw/xfree86/common/compiler.h
> -@@ -525,7 +525,7 @@ xf86WriteMmio32Le(__volatile__ void *base, const
> unsigned long offset,
> - #define PORT_SIZE short
> - #endif
> -
> --_X_EXPORT unsigned int IOPortBase; /* Memory mapped I/O port area */
> -+extern _X_EXPORT unsigned int IOPortBase; /* Memory mapped I/O port
> area */
> -
> - static __inline__ void
> - outb(unsigned PORT_SIZE port, unsigned char val)
> diff --git a/hw/xfree86/os-support/linux/lnx_video.c
> b/hw/xfree86/os-support/linux/lnx_video.c
> index 04e4509..9dc7316 100644
> --- a/hw/xfree86/os-support/linux/lnx_video.c
> diff --git
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
> deleted file mode 100644
> index c0c242814b..00
> ---
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
> +++ /dev/null
> @@ -1,36 +0,0 @@
> -From 8a382c015cd3c69fcfc146ef03dcbf30c77ff207 Mon Sep 17 00:00:00 2001
> -From: Khem Raj
> -Date: Fri, 1 Mar 2019 09:47:57 -0800
> -Subject: [PATCH] test/xtest: Initialize array with braces
> -
> -Fixes an error when extra warnings are enabled, this is caught with clang
> -
> -test/xtest.c:64:23: error: suggest braces around initialization of
> subobject [-Werror,-Wmissing-braces]
>
[OE-core] [PATCH] boost-build-native: workaround one rarely hang problem on fedora34
From: Changqing Li
Reproduce scenes:
* On fedora34
* autofs.service is started
* test is nis user, which mounted at /nis by autofs
* under /nis/test, there are symlinks point to another nis mount point /nis/yan
Result:
task boost-build-native:do_install hang forever
NOTE: recipe ovmf-edk2-stable202102-r0: task do_package_write_rpm: Succeeded
NOTE: Running noexec task 8124 of 8152
(/layers/oe-core/meta/recipes-core/ovmf/ovmf_git.bb:do_build)
Bitbake still alive (5000s)
Bitbake still alive (1s)
Bitbake still alive (15000s)
Bitbake still alive (2s)
Bitbake still alive (25000s)
Bitbake still alive (3s)
Bitbake still alive (35000s)
Bitbake still alive (4s)
Bitbake still alive (45000s)
Bitbake still alive (5s)
$ps aux | grep b2
test 2773444 0.0 0.0 13532 2748 ? D Jul01 0:00 ./b2 install
--prefix=/build/tmp-glibc/work/x86_64-linux/boost-build-native/4.4.1-r0/recipe-sysroot-native/usr
staging-prefix=/build/tmp-glibc/work/x86_64-linux/boost-build-native/4.4.1-r0/image/build/tmp-glibc/work/x86_64-linux/boost-build-native/4.4.1-r0/recipe-sysroot-native/usr
$ sudo cat /proc/2773444/stack
[<0>] autofs_wait+0x257/0x720
[<0>] autofs_mount_wait+0x49/0xf0
[<0>] autofs_d_manage+0x76/0x1a0
[<0>] __traverse_mounts+0xd9/0x220
[<0>] step_into+0x3ad/0x6d0
[<0>] walk_component+0x62/0x190
[<0>] link_path_walk.part.0.constprop.0+0x20d/0x350
[<0>] path_lookupat+0x3a/0x1b0
[<0>] filename_lookup+0x9b/0x180
[<0>] vfs_statx+0x64/0x100
[<0>] __do_sys_newfstatat+0x1e/0x40
[<0>] do_syscall_64+0x33/0x40
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
$ dmesg
[1559743.424610] autofs4:pid:2773444:autofs_mount_wait: waiting for mount
name=yan
[1559743.424621] autofs4:pid:2773444:autofs_wait: existing wait id =
0x0056, name = yan, nfy=1
[1560001.400440] autofs4:pid:2774530:autofs_mount_wait: waiting for mount
name=yan
[1560001.400452] autofs4:pid:2774530:autofs_wait: existing wait id =
0x0056, name = yan, nfy=1
[1560022.493282] autofs4:pid:2774537:autofs_mount_wait: waiting for mount
name=yan
[1560022.493292] autofs4:pid:2774537:autofs_wait: existing wait id =
0x0056, name = yan, nfy=1
[1560122.076589] autofs4:pid:3979116:autofs_mount_wait: mount wait done
status=-4
[1560162.222374] autofs4:pid:2774530:autofs_mount_wait: mount wait done
status=-4
[1560167.116188] autofs4:pid:2774537:autofs_mount_wait: mount wait done
status=-4
[1560188.140532] autofs4:pid:2774671:autofs_mount_wait: waiting for mount
name=yan
[1560188.140540] autofs4:pid:2774671:autofs_wait: existing wait id =
0x0056, name = yan, nfy=1
[1560189.651905] autofs4:pid:2774671:autofs_mount_wait: mount wait done
status=-4
Analyzation:
b2 will walk the HOME dir, when access the symlink point to /nis/yan,
autofs hang at autofs_wait. the process stay at D stat forever. This
maybe caused by abnormal status of autofs.service. The problem cannot
reproduce after restart autofs.service. There should be an autofs bug.
and there is an autofs hang problem bug on fedora34 on it's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1953390
Workaround:
Since b2 don't actually write something to HOME dir, change HOME dir to
/var/run, a dir not mounted by autofs.
Signed-off-by: Changqing Li
---
meta/recipes-support/boost/boost-build-native_4.4.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/boost/boost-build-native_4.4.1.bb
b/meta/recipes-support/boost/boost-build-native_4.4.1.bb
index ad675ce731..d4df5b5cf1 100644
--- a/meta/recipes-support/boost/boost-build-native_4.4.1.bb
+++ b/meta/recipes-support/boost/boost-build-native_4.4.1.bb
@@ -20,7 +20,7 @@ do_compile() {
}
do_install() {
-./b2 install --prefix=${prefix} staging-prefix=${D}${prefix}
+HOME=/var/run ./b2 install --prefix=${prefix} staging-prefix=${D}${prefix}
}
# The build is either release mode (pre-stripped) or debug (-O0).
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153674):
https://lists.openembedded.org/g/openembedded-core/message/153674
Mute This Topic: https://lists.openembedded.org/mt/84061312/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] gnome-desktop-testing: upgrade 2018.1 -> 2021.1
fails to build on mips https://errors.yoctoproject.org/Errors/Details/587476/
On Wed, Jul 7, 2021 at 8:45 AM wangmy wrote:
>
> Signed-off-by: Wang Mingyu
> ---
> ...esktop-testing_2018.1.bb => gnome-desktop-testing_2021.1.bb} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename
> meta/recipes-support/gnome-desktop-testing/{gnome-desktop-testing_2018.1.bb
> => gnome-desktop-testing_2021.1.bb} (94%)
>
> diff --git
> a/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2018.1.bb
> b/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2021.1.bb
> similarity index 94%
> rename from
> meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2018.1.bb
> rename to
> meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2021.1.bb
> index e5c69c0c46..b82eb8af2e 100644
> ---
> a/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2018.1.bb
> +++
> b/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2021.1.bb
> @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7 \
>
> file://src/gnome-desktop-testing-runner.c;beginline=1;endline=20;md5=7ef3ad9da2ffcf7707dc11151fe007f4"
>
> SRC_URI =
> "git://gitlab.gnome.org/GNOME/gnome-desktop-testing.git;protocol=http"
> -SRCREV = "4decade67b29ad170fcf3de148e41695fc459f48"
> +SRCREV = "e346cd4ed2e2102c9b195b614f3c642d23f5f6e7"
>
> DEPENDS = "glib-2.0"
>
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153673):
https://lists.openembedded.org/g/openembedded-core/message/153673
Mute This Topic: https://lists.openembedded.org/mt/84047332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH][hardknott] curl: Fix CVE-2021-22897
From: Khairul Rohaizzat Jamaluddin
CVE:
CVE-2021-22897
Signed-off-by: Khairul Rohaizzat Jamaluddin
---
.../curl/curl/CVE-2021-22897.patch| 72 +++
meta/recipes-support/curl/curl_7.75.0.bb | 1 +
2 files changed, 73 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2021-22897.patch
diff --git a/meta/recipes-support/curl/curl/CVE-2021-22897.patch
b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
new file mode 100644
index 00..fcd11b7674
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2021-22897.patch
@@ -0,0 +1,72 @@
+From bbb71507b7bab52002f9b1e0880bed6a32834511 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg
+Date: Fri, 23 Apr 2021 10:54:10 +0200
+Subject: [PATCH] schannel: don't use static to store selected ciphers
+
+CVE-2021-22897
+
+Bug: https://curl.se/docs/CVE-2021-22897.html
+
+Upstream-Status: Backport
+[https://github.com/curl/curl/commit/bbb71507b7bab52002f9b1e0880bed6a32834511]
+
+CVE: CVE-2021-22897
+
+Signed-off-by: Daniel Stenberg
+Signed-off-by: Khairul Rohaizzat Jamaluddin
+---
+ lib/vtls/schannel.c | 9 +
+ lib/vtls/schannel.h | 3 +++
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
+index 8c25ac5dd5a5..dba7072273a9 100644
+--- a/lib/vtls/schannel.c
b/lib/vtls/schannel.c
+@@ -328,12 +328,12 @@ get_alg_id_by_name(char *name)
+ }
+
+ static CURLcode
+-set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers)
++set_ssl_ciphers(SCHANNEL_CRED *schannel_cred, char *ciphers,
++int *algIds)
+ {
+ char *startCur = ciphers;
+ int algCount = 0;
+- static ALG_ID algIds[45]; /*There are 45 listed in the MS headers*/
+- while(startCur && (0 != *startCur) && (algCount < 45)) {
++ while(startCur && (0 != *startCur) && (algCount < NUMOF_CIPHERS)) {
+ long alg = strtol(startCur, 0, 0);
+ if(!alg)
+ alg = get_alg_id_by_name(startCur);
+@@ -593,7 +593,8 @@ schannel_connect_step1(struct Curl_easy *data, struct
connectdata *conn,
+ }
+
+ if(SSL_CONN_CONFIG(cipher_list)) {
+- result = set_ssl_ciphers(_cred, SSL_CONN_CONFIG(cipher_list));
++ result = set_ssl_ciphers(_cred, SSL_CONN_CONFIG(cipher_list),
++ BACKEND->algIds);
+ if(CURLE_OK != result) {
+ failf(data, "Unable to set ciphers to passed via SSL_CONN_CONFIG");
+ return result;
+diff --git a/lib/vtls/schannel.h b/lib/vtls/schannel.h
+index 2952caa1a5a1..77853aa30f96 100644
+--- a/lib/vtls/schannel.h
b/lib/vtls/schannel.h
+@@ -71,6 +71,8 @@ CURLcode Curl_verify_certificate(struct Curl_easy *data,
+ #endif
+ #endif
+
++#define NUMOF_CIPHERS 45 /* There are 45 listed in the MS headers */
++
+ struct Curl_schannel_cred {
+ CredHandle cred_handle;
+ TimeStamp time_stamp;
+@@ -102,6 +104,7 @@ struct ssl_backend_data {
+ #ifdef HAS_MANUAL_VERIFY_API
+ bool use_manual_cred_validation; /* true if manual cred validation is used
*/
+ #endif
++ ALG_ID algIds[NUMOF_CIPHERS];
+ };
+ #endif /* EXPOSE_SCHANNEL_INTERNAL_STRUCTS */
+
diff --git a/meta/recipes-support/curl/curl_7.75.0.bb
b/meta/recipes-support/curl/curl_7.75.0.bb
index c905659967..10ef559281 100644
--- a/meta/recipes-support/curl/curl_7.75.0.bb
+++ b/meta/recipes-support/curl/curl_7.75.0.bb
@@ -14,6 +14,7 @@ SRC_URI = "https://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-vtls-add-isproxy-argument-to-Curl_ssl_get-addsession.patch \
file://0002-transfer-strip-credentials-from-the-auto-referer-hea.patch \
file://CVE-2021-22898.patch \
+ file://CVE-2021-22897.patch \
"
SRC_URI[sha256sum] =
"50552d4501c178e4cc68baaecc487f466a3d6d19bbf4e50a01869effb316d026"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153672):
https://lists.openembedded.org/g/openembedded-core/message/153672
Mute This Topic: https://lists.openembedded.org/mt/84061041/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH][hardknott] curl: Fix CVE-2021-22898
From: Khairul Rohaizzat Jamaluddin
CVE:
CVE-2021-22898
Signed-off-by: Khairul Rohaizzat Jamaluddin
---
.../curl/curl/CVE-2021-22898.patch| 33 +++
meta/recipes-support/curl/curl_7.75.0.bb | 1 +
2 files changed, 34 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2021-22898.patch
diff --git a/meta/recipes-support/curl/curl/CVE-2021-22898.patch
b/meta/recipes-support/curl/curl/CVE-2021-22898.patch
new file mode 100644
index 00..29a4f818f3
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2021-22898.patch
@@ -0,0 +1,33 @@
+From 39ce47f219b09c380b81f89fe54ac586c8db6bde Mon Sep 17 00:00:00 2001
+From: Harry Sintonen
+Date: Fri, 7 May 2021 13:09:57 +0200
+Subject: [PATCH] telnet: check sscanf() for correct number of matches
+
+CVE-2021-22898
+
+Bug: https://curl.se/docs/CVE-2021-22898.html
+
+Upstream-Status: Backport
+[https://github.com/curl/curl/commit/39ce47f219b09c380b81f89fe54ac586c8db6bde]
+
+CVE: CVE-2021-22898
+
+Signed-off-by: Harry Sintonen
+Signed-off-by: Khairul Rohaizzat Jamaluddin
+---
+ lib/telnet.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/telnet.c b/lib/telnet.c
+index 26e0658ba9cc..fdd137fb0c04 100644
+--- a/lib/telnet.c
b/lib/telnet.c
+@@ -922,7 +922,7 @@ static void suboption(struct Curl_easy *data)
+ size_t tmplen = (strlen(v->data) + 1);
+ /* Add the variable only if it fits */
+ if(len + tmplen < (int)sizeof(temp)-6) {
+- if(sscanf(v->data, "%127[^,],%127s", varname, varval)) {
++ if(sscanf(v->data, "%127[^,],%127s", varname, varval) == 2) {
+ msnprintf((char *)[len], sizeof(temp) - len,
+ "%c%s%c%s", CURL_NEW_ENV_VAR, varname,
+ CURL_NEW_ENV_VALUE, varval);
diff --git a/meta/recipes-support/curl/curl_7.75.0.bb
b/meta/recipes-support/curl/curl_7.75.0.bb
index 7c7b363ae3..c905659967 100644
--- a/meta/recipes-support/curl/curl_7.75.0.bb
+++ b/meta/recipes-support/curl/curl_7.75.0.bb
@@ -13,6 +13,7 @@ SRC_URI = "https://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
file://0001-vtls-add-isproxy-argument-to-Curl_ssl_get-addsession.patch \
file://0002-transfer-strip-credentials-from-the-auto-referer-hea.patch \
+ file://CVE-2021-22898.patch \
"
SRC_URI[sha256sum] =
"50552d4501c178e4cc68baaecc487f466a3d6d19bbf4e50a01869effb316d026"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153671):
https://lists.openembedded.org/g/openembedded-core/message/153671
Mute This Topic: https://lists.openembedded.org/mt/84060951/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott][PATCH] busybox: fix traceroute failure
From: Mingli Yu
Backport a patch to fix the below traceroute failure:
$ traceroute -f 64 -I -n -m 240 10.226.43.84 46
traceroute: NO OPT x!
Signed-off-by: Mingli Yu
---
.../0001-traceroute-fix-option-parsing.patch | 31 +++
meta/recipes-core/busybox/busybox_1.33.0.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644
meta/recipes-core/busybox/busybox/0001-traceroute-fix-option-parsing.patch
diff --git
a/meta/recipes-core/busybox/busybox/0001-traceroute-fix-option-parsing.patch
b/meta/recipes-core/busybox/busybox/0001-traceroute-fix-option-parsing.patch
new file mode 100644
index 00..1e03b7dbfb
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/0001-traceroute-fix-option-parsing.patch
@@ -0,0 +1,31 @@
+From 89358a7131d3e75c74af834bb117b4fad7914983 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko
+Date: Tue, 2 Feb 2021 13:48:21 +0100
+Subject: [PATCH] traceroute: fix option parsing
+
+Fix option parsing
+
+Upstream-Status: Backport
[https://git.busybox.net/busybox/commit/?h=1_33_stable=89358a7131d3e75c74af834bb117b4fad7914983]
+
+Signed-off-by: Denys Vlasenko
+Signed-off-by: Mingli Yu
+---
+ networking/traceroute.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/networking/traceroute.c b/networking/traceroute.c
+index 3f1a9ab46..29f5e480b 100644
+--- a/networking/traceroute.c
b/networking/traceroute.c
+@@ -896,7 +896,7 @@ traceroute_init(int op, char **argv)
+
+ op |= getopt32(argv, "^"
+ OPT_STRING
+- "\0" "-1:x-x" /* minimum 1 arg */
++ "\0" "-1" /* minimum 1 arg */
+ , _str, , _ttl_str, _str, _str
+ , , _str, _str, _ttl_str
+ );
+--
+2.31.1
+
diff --git a/meta/recipes-core/busybox/busybox_1.33.0.bb
b/meta/recipes-core/busybox/busybox_1.33.0.bb
index b2a30ba16f..2d18ec072c 100644
--- a/meta/recipes-core/busybox/busybox_1.33.0.bb
+++ b/meta/recipes-core/busybox/busybox_1.33.0.bb
@@ -48,6 +48,7 @@ SRC_URI =
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://pgrep.cfg \
file://0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch \
file://0001-gen_build_files-Use-C-locale-when-calling-sed-on-glo.patch \
+ file://0001-traceroute-fix-option-parsing.patch \
"
SRC_URI_append_libc-musl = " file://musl.cfg "
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153670):
https://lists.openembedded.org/g/openembedded-core/message/153670
Mute This Topic: https://lists.openembedded.org/mt/84060098/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] python3-pathlib2: upgrade 2.3.5 -> 2.3.6
License-Update: file format changed from "ASCII text" to
"ASCII text, with CRLF line terminators"
Version 2.3.6
^
- Fix minor unicode bugs in with_name and with_suffix. Many thanks to
ppentchev for reporting and for providing a fix.
- Fix a few minor bugs.
- Allow unicode file paths on systems that support it
(note: unicode file paths will not work on Windows
due a broken filesystem encoder on Windows on Python 2).
- Remove travis and add github actions for regression testing.
- Fix mypy warnings.
Signed-off-by: Zheng Ruoqin
---
.../{python3-pathlib2_2.3.5.bb => python3-pathlib2_2.3.6.bb} | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
rename meta/recipes-devtools/python/{python3-pathlib2_2.3.5.bb =>
python3-pathlib2_2.3.6.bb} (52%)
diff --git a/meta/recipes-devtools/python/python3-pathlib2_2.3.5.bb
b/meta/recipes-devtools/python/python3-pathlib2_2.3.6.bb
similarity index 52%
rename from meta/recipes-devtools/python/python3-pathlib2_2.3.5.bb
rename to meta/recipes-devtools/python/python3-pathlib2_2.3.6.bb
index a022701ad0..8516bbe4d4 100644
--- a/meta/recipes-devtools/python/python3-pathlib2_2.3.5.bb
+++ b/meta/recipes-devtools/python/python3-pathlib2_2.3.6.bb
@@ -1,10 +1,9 @@
DESCRIPTION = "Object-oriented filesystem paths"
HOMEPAGE = "https://github.com/mcmtroffaes/pathlib2;
LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE.rst;md5=042856c23a3e903b33bf361ea1cbe29a"
+LIC_FILES_CHKSUM = "file://LICENSE.rst;md5=2dc08586cce3ab91bfa091b655c0e440"
-SRC_URI[md5sum] = "f2bd0a363eb0f8fa0556f35c1d9e66fb"
-SRC_URI[sha256sum] =
"6cd9a47b597b37cc57de1c05e56fb1a1c9cc9fab04fe78c29acd090418529868"
+SRC_URI[sha256sum] =
"7d8bcb003cdf4a8d2872c538faa3a0f5d20630cb360e518ca3b981795e5f"
inherit pypi setuptools3
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153669):
https://lists.openembedded.org/g/openembedded-core/message/153669
Mute This Topic: https://lists.openembedded.org/mt/84059288/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 00/18] Pull request (cover letter only)
The following changes since commit 9423ad8f0f42d249c2fcb1b86ec9abb75854f011: python3-ptest: add newly discovered missing rdeps (2021-06-28 05:01:39 -1000) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next Alexander Kanavin (2): python3: apply test skipping patch unconditionally selftest: do not hardcode /tmp/sdk Bruce Ashfield (4): linux-yocto/5.4: update to v5.4.124 linux-yocto/5.4: update to v5.4.125 linux-yocto/5.4: update to v5.4.128 linux-yocto/5.4: update to v5.4.129 Florian Amstutz (1): devtool: deploy-target: Fix preserving attributes when using --strip Michael Ho (1): sstate.bbclass: fix errors about read-only sstate mirrors Minjae Kim (2): rpm: fix CVE-2021-3421 gstreamer-plugins-base: fix CVE-2021-3522 Richard Purdie (7): kernel: Fix interaction when packaging disabled kernel-devicetree: Fix interaction when packaging disabled perf: Use python3targetconfig to ensure we use target libraries package_pkgdata: Avoid task hash mismatches for generic task changes oeqa/selftest/runcmd: Tweal test timeouts sstate/staging: Handle directory creation race issue oeqa/selftest/archiver: Allow tests to ignore empty directories Tim Orling (1): python3: skip tests requiring tools-sdk meta/classes/kernel-devicetree.bbclass| 11 +- meta/classes/kernel.bbclass | 2 + meta/classes/package_pkgdata.bbclass | 2 +- meta/classes/sstate.bbclass | 16 +- meta/classes/staging.bbclass | 6 +- meta/lib/oeqa/selftest/cases/archiver.py | 16 +- meta/lib/oeqa/selftest/cases/runcmd.py| 4 +- meta/lib/oeqa/selftest/cases/runtime_test.py | 28 ++- ...pes.test_find-skip-without-tools-sdk.patch | 33 +++ .../recipes-devtools/python/python3_3.8.10.bb | 1 + .../rpm/files/CVE-2021-3421.patch | 197 ++ meta/recipes-devtools/rpm/rpm_4.14.2.1.bb | 1 + .../linux/linux-yocto-rt_5.4.bb | 6 +- .../linux/linux-yocto-tiny_5.4.bb | 8 +- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 +- meta/recipes-kernel/perf/perf.bb | 2 +- .../CVE-2021-3522.patch | 36 .../gstreamer1.0-plugins-base_1.16.3.bb | 1 + scripts/lib/devtool/deploy.py | 2 +- 19 files changed, 337 insertions(+), 57 deletions(-) create mode 100644 meta/recipes-devtools/python/python3/0001-test_ctypes.test_find-skip-without-tools-sdk.patch create mode 100644 meta/recipes-devtools/rpm/files/CVE-2021-3421.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/CVE-2021-3522.patch -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153668): https://lists.openembedded.org/g/openembedded-core/message/153668 Mute This Topic: https://lists.openembedded.org/mt/84058413/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] xserver-xorg: upgrade 1.20.11 -> 21.0.99.1
0001-test-xtest-Initialize-array-with-braces.patch
pkgconfig.patch
sdksyms-no-build-path.patch
removed since they're included in 21.0.99.1
refresh 0001-Avoid-duplicate-definitions-of-IOPortBase.patch
Signed-off-by: Wang Mingyu
---
.../xorg-xserver/xserver-xorg.inc | 3 +-
...-duplicate-definitions-of-IOPortBase.patch | 16 +-
...t-xtest-Initialize-array-with-braces.patch | 36 -
.../xorg-xserver/xserver-xorg/pkgconfig.patch | 34 -
.../xserver-xorg/sdksyms-no-build-path.patch | 50 ---
...g_1.20.11.bb => xserver-xorg_21.0.99.1.bb} | 6 +--
6 files changed, 4 insertions(+), 141 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/pkgconfig.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/sdksyms-no-build-path.patch
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.20.11.bb =>
xserver-xorg_21.0.99.1.bb} (77%)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index da025171db..7bbff0073b 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -65,6 +65,7 @@ PACKAGES =+ "${PN}-sdl \
${PN}-module-xaa \
${PN}-module-libxf1bpp \
${PN}-module-libxf4bpp \
+${PN}-input-modules \
xf86-video-modesetting"
SUMMARY_xf86-video-modesetting = "X.Org X server -- modesetting display driver"
@@ -101,6 +102,7 @@ FILES_${PN}-module-exa = "${libdir}/xorg/modules/libexa.so"
FILES_${PN}-module-xaa = "${libdir}/xorg/modules/libxaa.so"
FILES_${PN}-module-libxf1bpp = "${libdir}/xorg/modules/libxf1bpp.so"
FILES_${PN}-module-libxf4bpp = "${libdir}/xorg/modules/libxf4bpp.so"
+FILES_${PN}-input-modules = "${libdir}/xorg/modules/input/*drv*"
FILES_xf86-video-modesetting =
"${libdir}/xorg/modules/drivers/modesetting_drv.so"
EXTRA_OECONF += "--with-fop=no \
@@ -116,7 +118,6 @@ EXTRA_OECONF += "--with-fop=no \
--sysconfdir=/etc/X11 \
--localstatedir=/var \
--with-xkb-output=/var/lib/xkb \
- --with-os-name=Linux \
"
OPENGL_PKGCONFIGS = "dri glx glamor dri3 xshmfence"
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
index 4737040675..d876958898 100644
---
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
+++
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Avoid-duplicate-definitions-of-IOPortBase.patch
@@ -11,23 +11,9 @@ compiler.h:528: multiple definition of `IOPortBase';
Upstream-Status: Pending
Signed-off-by: Khem Raj
---
- hw/xfree86/common/compiler.h| 2 +-
hw/xfree86/os-support/linux/lnx_video.c | 1 +
- 2 files changed, 2 insertions(+), 1 deletion(-)
+ 1 files changed, 1 insertions(+), 0 deletion(-)
-diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
-index 2b2008b..c7d617e 100644
a/hw/xfree86/common/compiler.h
-+++ b/hw/xfree86/common/compiler.h
-@@ -525,7 +525,7 @@ xf86WriteMmio32Le(__volatile__ void *base, const unsigned
long offset,
- #define PORT_SIZE short
- #endif
-
--_X_EXPORT unsigned int IOPortBase; /* Memory mapped I/O port area */
-+extern _X_EXPORT unsigned int IOPortBase; /* Memory mapped I/O port area
*/
-
- static __inline__ void
- outb(unsigned PORT_SIZE port, unsigned char val)
diff --git a/hw/xfree86/os-support/linux/lnx_video.c
b/hw/xfree86/os-support/linux/lnx_video.c
index 04e4509..9dc7316 100644
--- a/hw/xfree86/os-support/linux/lnx_video.c
diff --git
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
deleted file mode 100644
index c0c242814b..00
---
a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 8a382c015cd3c69fcfc146ef03dcbf30c77ff207 Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Fri, 1 Mar 2019 09:47:57 -0800
-Subject: [PATCH] test/xtest: Initialize array with braces
-
-Fixes an error when extra warnings are enabled, this is caught with clang
-
-test/xtest.c:64:23: error: suggest braces around initialization of subobject
[-Werror,-Wmissing-braces]
-WindowRec root = {0};
- ^
- {}
-1 error generated.
-
-Upstream-Status: Pending
-
-Signed-off-by: Khem Raj
- test/xtest.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/test/xtest.c b/test/xtest.c
-index
[OE-core] [PATCH] util-linux: Disable chfn-chsh on non-target builds
They are also provided by shadow-native e.g. when building native
recipes and packages where they depend on both shadow-native and
util-linux-native, this can conflict
Fixes
ERROR: systemd-1_248.3-r0 do_prepare_recipe_sysroot: The file /usr/bin/chsh is
installed by both util-linux-native and shadow-native, aborting
Signed-off-by: Khem Raj
Cc: Ross Burton
---
meta/recipes-core/util-linux/util-linux_2.37.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/util-linux/util-linux_2.37.bb
b/meta/recipes-core/util-linux/util-linux_2.37.bb
index 399f66d6a0..285e182e0f 100644
--- a/meta/recipes-core/util-linux/util-linux_2.37.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.37.bb
@@ -91,7 +91,7 @@ EXTRA_OECONF_append = " --disable-hwclock-gplv3"
# build host versions during development
#
PACKAGECONFIG ?= "pcre2"
-PACKAGECONFIG_class-target ?= "${@bb.utils.filter('DISTRO_FEATURES', 'pam',
d)}"
+PACKAGECONFIG_class-target ?= "${@bb.utils.filter('DISTRO_FEATURES', 'pam',
d)} chfn-chsh"
PACKAGECONFIG[pam] = "--enable-su --enable-runuser,--disable-su
--disable-runuser, libpam,"
# Respect the systemd feature for uuidd
PACKAGECONFIG[systemd] = "--with-systemd
--with-systemdsystemunitdir=${systemd_system_unitdir}, --without-systemd
--without-systemdsystemunitdir,systemd"
@@ -102,6 +102,7 @@ PACKAGECONFIG[readline] =
"--with-readline,--without-readline,readline"
# PCRE support in hardlink
PACKAGECONFIG[pcre2] = ",,libpcre2"
PACKAGECONFIG[cryptsetup] = "--with-cryptsetup,--without-cryptsetup,cryptsetup"
+PACKAGECONFIG[chfn-chsh] = "--enable-chfn-chsh,--disable-chfn-chsh,"
EXTRA_OEMAKE = "ARCH=${TARGET_ARCH} CPU= CPUOPT= 'OPT=${CFLAGS}'"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153666):
https://lists.openembedded.org/g/openembedded-core/message/153666
Mute This Topic: https://lists.openembedded.org/mt/84055886/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] python3-setuptools: upgrade 57.0.0 -> 57.1.0
On Wed, 2021-07-07 at 17:49 +0200, Alexander Kanavin wrote: > Seems like reproducibility.patch can actually be removed, as it was accepted > upstream? Yes, upstream tweaked it slightly and we can drop that patch here. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153665): https://lists.openembedded.org/g/openembedded-core/message/153665 Mute This Topic: https://lists.openembedded.org/mt/84047336/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] license.bbclass does not add recommends to dynamic packages
On Wed, 2021-07-07 at 17:55 +0100, Mike Crowe wrote:
> On Wednesday 07 July 2021 at 17:48:20 +0100, Richard Purdie wrote:
> > On Wed, 2021-07-07 at 17:43 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Wed, 2021-07-07 at 14:05 +0100, Mike Crowe wrote:
> > > > On Wednesday 07 July 2021 at 13:25:17 +0100, Richard Purdie wrote:
> > > > > On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via
> > > > > lists.openembedded.org wrote:
> > > > > > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package
> > > > > > files and
> > > > > > relying on the automatically generated recommends to cause them to
> > > > > > be
> > > > > > installed in the image. This works well for most packages, but
> > > > > > fails for
> > > > > > packages where we only install package created using
> > > > > > PACKAGES_DYNAMIC.
> > > > > >
> > > > > > For example, liborc is being installed in our image but that
> > > > > > package lacks
> > > > > > a recommends for orc-lic, so the licences that apply to it are not
> > > > > > being
> > > > > > installed. This is because license.bbclass:add_package_and_files
> > > > > > iterates
> > > > > > only over the packages listed in PACKAGES.
> > > > > >
> > > > > > Steps to reproduce on current master:
> > > > > >
> > > > > > $ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
> > > > > > $ bitbake orc
> > > > > > $ dpkg-deb -I
> > > > > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > > > > Recommends
> > > > > > Recommends: orc-lic
> > > > > > $ dpkg-deb -I
> > > > > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > > > > Recommends
> > > > > > $
> > > > > >
> > > > > > (I would have expected the last command to produce the same output
> > > > > > as the
> > > > > > penultimate one.)
> > > > > >
> > > > > > Even if I could fathom out how to fix orc and any other recipes so
> > > > > > that they
> > > > > > did add the ${PN}-lic dependency, I'd be worried about not noticing
> > > > > > that
> > > > > > the problem affected other recipes in the future.
> > > > > >
> > > > > > Is there a way to teach license.bbclass:add_package_and_files to
> > > > > > add the
> > > > > > ${PN}-lic recommends for dynamic packages, or would it be necessary
> > > > > > to
> > > > > > teach package.bbclass to do so?
> > > > >
> > > > > That all sounds rather horrible :/.
> > > > >
> > > > > Would IMAGE_INSTALL_COMPLEMENTARY += "*-lic" work instead?
> > > >
> > > > That seems to have worked well.
> > > >
> > > > I wonder whether this means that it would be better to stop adding the
> > > > recommends automatically and tell users that need this to use
> > > > IMAGE_INSTALL_COMPLEMENTARY instead (either directly, or by teaching
> > > > license_image.bbclass to modify it based on another variable.)
> > >
> > > That would seem the better option to me at least...
> >
> > To be clear, I'd definitely support dropping that existing RRECOMMENDS code,
> > I think there are better ways to handle this now. I may even write that
> > patch :)
>
> I was thinking of something like the following untested patch:
>
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index f7978e266b..c87473cbb8 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -63,14 +63,6 @@ def add_package_and_files(d):
> # first in PACKAGES to be sure that nothing else gets
> LICENSE_FILES_DIRECTORY
> d.setVar('PACKAGES', "%s %s" % (pn_lic, packages))
> d.setVar('FILES_' + pn_lic, files)
> -for pn in packages.split():
> -if pn == pn_lic:
> -continue
> -rrecommends_pn = d.getVar('RRECOMMENDS_' + pn)
> -if rrecommends_pn:
> -d.setVar('RRECOMMENDS_' + pn, "%s %s" % (pn_lic, rrecommends_pn))
> -else:
> -d.setVar('RRECOMMENDS_' + pn, "%s" % (pn_lic))
>
> def copy_license_files(lic_files_paths, destdir):
> import shutil
The above looks like the patch I just sent out! :)
> diff --git a/meta/classes/license_image.bbclass
> b/meta/classes/license_image.bbclass
> index 73cebb4d55..293a033855 100644
> --- a/meta/classes/license_image.bbclass
> +++ b/meta/classes/license_image.bbclass
> @@ -279,3 +279,6 @@ python license_qa_dead_symlink() {
> bb.error("broken symlink: " + full_path)
> }
> IMAGE_QA_COMMANDS += "license_qa_dead_symlink"
> +
> +IMAGE_INSTALL_LICENSES ??= "${LICENSE_CREATE_PACKAGE}"
> +IMAGE_INSTALL_COMPLEMENTARY +=
> "${oe.utils.conditional("IMAGE_INSTALL_LICENSES", "0", "", "*-lic", d)}"
>
> I'm not sure whether it's safe to += an empty string onto the end of
> IMAGE_INSTALL_COMPLEMENTARY, but I'm trying to avoid adding yet more
> anonymous Python. :-)
>
> Is that the sort of thing you meant?
Yes, += to an empty string is fine. I'm torn on whether we should do this
"magically"
or whether users should opt in to it when needed on a
Re: [OE-core] [PATCH] texinfo: update 6.7 -> 6.8
This fails to build with master-next (+ glibc 2.34 perhaps)
https://errors.yoctoproject.org/Errors/Details/587462/
On Mon, Jul 5, 2021 at 11:35 AM Alexander Kanavin
wrote:
>
> Drop texinfo-4.12-zlib.patch as it completely lacks a description,
> was added together with the original recipe without an explanation in
> the commit message, and is difficult to rebase.
>
> Signed-off-by: Alexander Kanavin
> ---
> .../texinfo/texinfo/texinfo-4.12-zlib.patch | 254 --
> .../{texinfo_6.7.bb => texinfo_6.8.bb}| 4 +-
> 2 files changed, 1 insertion(+), 257 deletions(-)
> delete mode 100644
> meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> rename meta/recipes-extended/texinfo/{texinfo_6.7.bb => texinfo_6.8.bb} (94%)
>
> diff --git a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> deleted file mode 100644
> index f72097e639..00
> --- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> +++ /dev/null
> @@ -1,254 +0,0 @@
> -From 3d3b66cf398853c666e724c3dbcc37d53a2240d5 Mon Sep 17 00:00:00 2001
> -From: Edwin Plauchu
> -Date: Tue, 29 Nov 2016 12:27:17 -0600
> -Subject: [PATCH] texinfo-4.12-zlib
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Jussi Kukkonen
> -Signed-off-by: Edwin Plauchu
> -
>
> - install-info/Makefile.in| 2 +-
> - install-info/install-info.c | 79 ++---
> - 2 files changed, 48 insertions(+), 33 deletions(-)
> -
> -diff --git a/install-info/Makefile.in b/install-info/Makefile.in
> -index c924509..746df05 100644
> a/install-info/Makefile.in
> -+++ b/install-info/Makefile.in
> -@@ -218,7 +218,7 @@ am__installdirs = "$(DESTDIR)$(bindir)"
> "$(DESTDIR)$(bindir)"
> - PROGRAMS = $(bin_PROGRAMS)
> - am_ginstall_info_OBJECTS = install-info.$(OBJEXT)
> - ginstall_info_OBJECTS = $(am_ginstall_info_OBJECTS)
> --ginstall_info_LDADD = $(LDADD)
> -+ginstall_info_LDADD = $(LDADD) -lz
> - am__DEPENDENCIES_1 =
> - ginstall_info_DEPENDENCIES = $(top_builddir)/gnulib/lib/libgnu.a \
> - $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
> -diff --git a/install-info/install-info.c b/install-info/install-info.c
> -index 21f4fe3..a7aba82 100644
> a/install-info/install-info.c
> -+++ b/install-info/install-info.c
> -@@ -19,6 +19,7 @@
> - #include
> - #include
> - #include
> -+#include
> -
> - #define TAB_WIDTH 8
> -
> -@@ -681,15 +682,15 @@ The first time you invoke Info you start off looking
> at this node.\n\
> -
> -Return either stdin reading the file, or a non-stdin pipe reading
> -the output of the compression program. */
> --FILE *
> -+void *
> - open_possibly_compressed_file (char *filename,
> - void (*create_callback) (char *),
> --char **opened_filename, char **compression_program)
> -+char **opened_filename, char **compression_program, int *is_pipe)
> - {
> - char *local_opened_filename, *local_compression_program;
> - int nread;
> - char data[13];
> -- FILE *f;
> -+ gzFile *f;
> -
> - /* We let them pass NULL if they don't want this info, but it's easier
> - to always determine it. */
> -@@ -697,48 +698,48 @@ open_possibly_compressed_file (char *filename,
> - opened_filename = _opened_filename;
> -
> - *opened_filename = filename;
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - if (!f)
> - {
> - *opened_filename = concat (filename, ".gz", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - }
> - if (!f)
> - {
> - free (*opened_filename);
> - *opened_filename = concat (filename, ".xz", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - }
> - if (!f)
> - {
> - free (*opened_filename);
> - *opened_filename = concat (filename, ".bz2", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - }
> - if (!f)
> - {
> - free (*opened_filename);
> - *opened_filename = concat (filename, ".lz", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - }
> - if (!f)
> - {
> - free (*opened_filename);
> - *opened_filename = concat (filename, ".lzma", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - }
> - #ifdef __MSDOS__
> - if (!f)
> - {
> - free (*opened_filename);
> - *opened_filename = concat (filename, ".igz", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+ f = gzopen (*opened_filename, FOPEN_RBIN);
> - }
> - if (!f)
> - {
> - free (*opened_filename);
> - *opened_filename = concat (filename, ".inz", "");
> -- f = fopen (*opened_filename, FOPEN_RBIN);
> -+
Re: [OE-core] [PATCH] qemuarm64.conf: change the cpu model to max
On Wed, Jul 7, 2021 at 5:21 AM Alexander Kanavin wrote:
>
> 'max' implies that it's not stable and will change depending on qemu version
> and build settings. Can you set it to a specific model?
>
I don't see stability an issue here as max is stable, A potential
issue is that it will now depend on host cpu features which can then
have result variance
so perhaps you should be able to add it as cpu feature attribute via
-cpu ,feature1,feature2 etc. perhaps and also ensure that these
features are
commonly available on ARM build hosts.
> Alex
>
> On Wed, 7 Jul 2021 at 10:55, Yu, Mingli wrote:
>>
>> From: Mingli Yu
>>
>> After rng-tools upgraded to 6.13, the below logic introduced.
>> 9070a04 Add support for ARM v8.5A "rndr" instruction
>>
>> It means there is another entropy source rndr added for arm64,
>> so modify the cpu model to max [1] to make the rndr entropy source
>> function available and also used to silence the below failed message
>> when start rngd service on qemuarm64.
>> "[rndr ]: Initialization Failed"
>>
>> Before the patch:
>> $ systemctl status rngd
>> [snip]
>> Jul 05 07:15:47 qemuarm64 systemd[1]: Started Hardware RNG Entropy Gatherer
>> Daemon.
>> Jul 05 07:15:48 qemuarm64 rngd[152]: Initializing available sources
>> Jul 05 07:15:48 qemuarm64 rngd[152]: [hwrng ]: Initialized
>> Jul 05 07:15:48 qemuarm64 rngd[152]: [rndr ]: No HW SUPPORT
>> Jul 05 07:15:48 qemuarm64 rngd[152]: [rndr ]: Initialization Failed
>> Jul 05 07:15:48 qemuarm64 rngd[152]: [jitter]: Initializing AES buffer
>> Jul 05 07:16:14 qemuarm64 rngd[152]: [jitter]: Enabling JITTER rng support
>> Jul 05 07:16:14 qemuarm64 rngd[152]: [jitter]: Initialized
>>
>> After the patch:
>> $ systemctl status rngd
>> [snip]
>> Jul 07 08:48:30 qemuarm64 systemd[1]: Started Hardware RNG Entropy Gatherer
>> Daemon.
>> Jul 07 08:48:34 qemuarm64 rngd[164]: Initializing available sources
>> Jul 07 08:48:34 qemuarm64 rngd[164]: [hwrng ]: Initialized
>> Jul 07 08:48:34 qemuarm64 rngd[164]: [rndr ]: Enabling aarch64 RNDR rng
>> support
>> Jul 07 08:48:34 qemuarm64 rngd[164]: [rndr ]: Initialized
>> Jul 07 08:48:35 qemuarm64 rngd[164]: [jitter]: Initializing AES buffer
>>
>> [1] https://github.com/nhorman/rng-tools/pull/128
>>
>> Signed-off-by: Mingli Yu
>> ---
>> meta/conf/machine/qemuarm64.conf | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/conf/machine/qemuarm64.conf
>> b/meta/conf/machine/qemuarm64.conf
>> index 150a0744eb..a792dc32e6 100644
>> --- a/meta/conf/machine/qemuarm64.conf
>> +++ b/meta/conf/machine/qemuarm64.conf
>> @@ -15,7 +15,7 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
>> # For runqemu
>> QB_SYSTEM_NAME = "qemu-system-aarch64"
>> QB_MACHINE = "-machine virt"
>> -QB_CPU = "-cpu cortex-a57"
>> +QB_CPU = "-cpu max"
>> QB_SMP = "-smp 4"
>> QB_CPU_KVM = "-cpu host -machine gic-version=3"
>> # For graphics to work we need to define the VGA device as well as the
>> necessary USB devices
>> --
>> 2.17.1
>>
>>
>>
>>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153662):
https://lists.openembedded.org/g/openembedded-core/message/153662
Mute This Topic: https://lists.openembedded.org/mt/84040384/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] oeqa/selftest/recipetool: update socat version to fix failing download
On Wed, Jul 7, 2021 at 8:56 AM Ross Burton wrote:
>
> If the recipetool tests are run with an empty DL_DIR the fetch of
> socat 1.7.3.0 fails as that URL doesn't exist anymore.
>
> Update the version to 1.7.4.1 to fix the test.
>
this fixes master but I guess releases are still broken and perhaps
backporting it may not be a simple
as newer version of socat may not work with older versions of OE.
Perhaps we should use yp download
server to provide this tarball ?
> Signed-off-by: Ross Burton
> ---
> meta/lib/oeqa/selftest/cases/recipetool.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
> b/meta/lib/oeqa/selftest/cases/recipetool.py
> index 9d56e9e1e32..f0685d37182 100644
> --- a/meta/lib/oeqa/selftest/cases/recipetool.py
> +++ b/meta/lib/oeqa/selftest/cases/recipetool.py
> @@ -374,7 +374,7 @@ class RecipetoolTests(RecipetoolBase):
> # Try adding a recipe
> temprecipe = os.path.join(self.tempdir, 'recipe')
> os.makedirs(temprecipe)
> -pv = '1.7.3.0'
> +pv = '1.7.4.1'
> srcuri =
> 'http://www.dest-unreach.org/socat/download/socat-%s.tar.bz2' % pv
> result = runCmd('recipetool create %s -o %s' % (srcuri, temprecipe))
> dirlist = os.listdir(temprecipe)
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153661):
https://lists.openembedded.org/g/openembedded-core/message/153661
Mute This Topic: https://lists.openembedded.org/mt/84047634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] esdk: locked sig mismatch warnings when build from esdk env
ping On Thu, Jun 24, 2021 at 9:54 AM Khem Raj wrote: > > From: Mani Selvaraj > > A repo with multiple layers are placed under /layers/ and a repo > with single layer is placed under /layers/openembedded-core in esdk. > This tiggered locked sig mismatch warnings when building image from > esdk environment. > - > TOPDIR=/Code/build > corebase=/Code/openembedded-core > - > /Code/meta-java > /Code/meta-gplv2 > /Code/meta-openembedded/meta-webserver > /Code/meta-openembedded/meta-oe > /Code/openembedded-core/meta > Are moved to > /sdk_org/layers/openembedded-core/meta-gplv2 > /sdk_org/layers/openembedded-core/meta-java > /sdk_org/layers/meta-openembedded/meta-webserver > /sdk_org/layers/meta-openembedded/meta-oe > /sdk_org/layers/openembedded-core/meta > > here fix it to move all layers under /layers dir. > > to check this fix build image from esdk environment and > check for sig mismatch warnings. > > Signed-off-by: Mani Selvaraj > Signed-off-by: Khem Raj > --- > meta/lib/oe/copy_buildsystem.py | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py > index d97bf9d1b9..4998afa60f 100644 > --- a/meta/lib/oe/copy_buildsystem.py > +++ b/meta/lib/oe/copy_buildsystem.py > @@ -102,8 +102,6 @@ class BuildSystem(object): > layerdestpath += '/' + os.path.basename(corebase) > else: > layer_relative = os.path.relpath(layer, corebase) > -if os.path.dirname(layer_relative) == corebase_relative: > -layer_relative = os.path.dirname(corebase_relative) + > '/' + layernewname > layer_relative = os.path.basename(corebase) + '/' + > layer_relative > if os.path.dirname(layer_relative) != layernewname: > layerdestpath += '/' + os.path.dirname(layer_relative) > -- > 2.32.0 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153660): https://lists.openembedded.org/g/openembedded-core/message/153660 Mute This Topic: https://lists.openembedded.org/mt/83764918/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] libubootenv: Disable for ppc/ppc64 qemu machines
ping
On Sun, Jul 4, 2021 at 2:07 PM Khem Raj wrote:
>
> This recipe depends on u-boot and u-boot is not available for
> qemuppc/qemuppc64 and there is no defconfig available either
>
> Signed-off-by: Khem Raj
> ---
> meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
> b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
> index 306296922c..88a8397c3c 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
> @@ -25,6 +25,9 @@ RPROVIDES_${PN}-bin += "u-boot-fw-utils"
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> +COMPATIBLE_HOST_qemuppc64 = "null"
> +COMPATIBLE_HOST_qemuppc = "null"
> +
> RRECOMMENDS_${PN}-bin_append_class-target = " u-boot-default-env"
>
> BBCLASSEXTEND = "native"
> --
> 2.32.0
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153659):
https://lists.openembedded.org/g/openembedded-core/message/153659
Mute This Topic: https://lists.openembedded.org/mt/83986109/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] license: Drop adding RRECOMMENDS for license packages
This changes behaviour when LICENSE_CREATE_PACKAGE is in use. Packages
no longer have RRECOMMENDS adding to them.
It was highlighted that this doesn't apply to PACKAGES_DYNAMIC, nor can
it easily be made to do so. There is also a much easier way to handle this
which is:
IMAGE_INSTALL_COMPLEMENTARY += "*-lic"
which works on a per image basis and doesn't change the underlying
package dependencies. I propose we switch to this instead.
Signed-off-by: Richard Purdie
---
meta/classes/license.bbclass | 8
1 file changed, 8 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index f7978e266b6..c87473cbb85 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -63,14 +63,6 @@ def add_package_and_files(d):
# first in PACKAGES to be sure that nothing else gets
LICENSE_FILES_DIRECTORY
d.setVar('PACKAGES', "%s %s" % (pn_lic, packages))
d.setVar('FILES_' + pn_lic, files)
-for pn in packages.split():
-if pn == pn_lic:
-continue
-rrecommends_pn = d.getVar('RRECOMMENDS_' + pn)
-if rrecommends_pn:
-d.setVar('RRECOMMENDS_' + pn, "%s %s" % (pn_lic, rrecommends_pn))
-else:
-d.setVar('RRECOMMENDS_' + pn, "%s" % (pn_lic))
def copy_license_files(lic_files_paths, destdir):
import shutil
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153658):
https://lists.openembedded.org/g/openembedded-core/message/153658
Mute This Topic: https://lists.openembedded.org/mt/84049073/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] license.bbclass does not add recommends to dynamic packages
On Wednesday 07 July 2021 at 17:48:20 +0100, Richard Purdie wrote:
> On Wed, 2021-07-07 at 17:43 +0100, Richard Purdie via lists.openembedded.org
> wrote:
> > On Wed, 2021-07-07 at 14:05 +0100, Mike Crowe wrote:
> > > On Wednesday 07 July 2021 at 13:25:17 +0100, Richard Purdie wrote:
> > > > On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via
> > > > lists.openembedded.org wrote:
> > > > > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files
> > > > > and
> > > > > relying on the automatically generated recommends to cause them to be
> > > > > installed in the image. This works well for most packages, but fails
> > > > > for
> > > > > packages where we only install package created using PACKAGES_DYNAMIC.
> > > > >
> > > > > For example, liborc is being installed in our image but that package
> > > > > lacks
> > > > > a recommends for orc-lic, so the licences that apply to it are not
> > > > > being
> > > > > installed. This is because license.bbclass:add_package_and_files
> > > > > iterates
> > > > > only over the packages listed in PACKAGES.
> > > > >
> > > > > Steps to reproduce on current master:
> > > > >
> > > > > $ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
> > > > > $ bitbake orc
> > > > > $ dpkg-deb -I
> > > > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > > > Recommends
> > > > > Recommends: orc-lic
> > > > > $ dpkg-deb -I
> > > > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > > > Recommends
> > > > > $
> > > > >
> > > > > (I would have expected the last command to produce the same output as
> > > > > the
> > > > > penultimate one.)
> > > > >
> > > > > Even if I could fathom out how to fix orc and any other recipes so
> > > > > that they
> > > > > did add the ${PN}-lic dependency, I'd be worried about not noticing
> > > > > that
> > > > > the problem affected other recipes in the future.
> > > > >
> > > > > Is there a way to teach license.bbclass:add_package_and_files to add
> > > > > the
> > > > > ${PN}-lic recommends for dynamic packages, or would it be necessary to
> > > > > teach package.bbclass to do so?
> > > >
> > > > That all sounds rather horrible :/.
> > > >
> > > > Would IMAGE_INSTALL_COMPLEMENTARY += "*-lic" work instead?
> > >
> > > That seems to have worked well.
> > >
> > > I wonder whether this means that it would be better to stop adding the
> > > recommends automatically and tell users that need this to use
> > > IMAGE_INSTALL_COMPLEMENTARY instead (either directly, or by teaching
> > > license_image.bbclass to modify it based on another variable.)
> >
> > That would seem the better option to me at least...
>
> To be clear, I'd definitely support dropping that existing RRECOMMENDS code,
> I think there are better ways to handle this now. I may even write that patch
> :)
I was thinking of something like the following untested patch:
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index f7978e266b..c87473cbb8 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -63,14 +63,6 @@ def add_package_and_files(d):
# first in PACKAGES to be sure that nothing else gets
LICENSE_FILES_DIRECTORY
d.setVar('PACKAGES', "%s %s" % (pn_lic, packages))
d.setVar('FILES_' + pn_lic, files)
-for pn in packages.split():
-if pn == pn_lic:
-continue
-rrecommends_pn = d.getVar('RRECOMMENDS_' + pn)
-if rrecommends_pn:
-d.setVar('RRECOMMENDS_' + pn, "%s %s" % (pn_lic, rrecommends_pn))
-else:
-d.setVar('RRECOMMENDS_' + pn, "%s" % (pn_lic))
def copy_license_files(lic_files_paths, destdir):
import shutil
diff --git a/meta/classes/license_image.bbclass
b/meta/classes/license_image.bbclass
index 73cebb4d55..293a033855 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -279,3 +279,6 @@ python license_qa_dead_symlink() {
bb.error("broken symlink: " + full_path)
}
IMAGE_QA_COMMANDS += "license_qa_dead_symlink"
+
+IMAGE_INSTALL_LICENSES ??= "${LICENSE_CREATE_PACKAGE}"
+IMAGE_INSTALL_COMPLEMENTARY +=
"${oe.utils.conditional("IMAGE_INSTALL_LICENSES", "0", "", "*-lic", d)}"
I'm not sure whether it's safe to += an empty string onto the end of
IMAGE_INSTALL_COMPLEMENTARY, but I'm trying to avoid adding yet more
anonymous Python. :-)
Is that the sort of thing you meant?
Thanks.
Mike.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153657):
https://lists.openembedded.org/g/openembedded-core/message/153657
Mute This Topic: https://lists.openembedded.org/mt/84042415/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] license.bbclass does not add recommends to dynamic packages
On Wed, 2021-07-07 at 17:43 +0100, Richard Purdie via lists.openembedded.org
wrote:
> On Wed, 2021-07-07 at 14:05 +0100, Mike Crowe wrote:
> > On Wednesday 07 July 2021 at 13:25:17 +0100, Richard Purdie wrote:
> > > On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via lists.openembedded.org
> > > wrote:
> > > > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
> > > > relying on the automatically generated recommends to cause them to be
> > > > installed in the image. This works well for most packages, but fails for
> > > > packages where we only install package created using PACKAGES_DYNAMIC.
> > > >
> > > > For example, liborc is being installed in our image but that package
> > > > lacks
> > > > a recommends for orc-lic, so the licences that apply to it are not being
> > > > installed. This is because license.bbclass:add_package_and_files
> > > > iterates
> > > > only over the packages listed in PACKAGES.
> > > >
> > > > Steps to reproduce on current master:
> > > >
> > > > $ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
> > > > $ bitbake orc
> > > > $ dpkg-deb -I
> > > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > > Recommends
> > > > Recommends: orc-lic
> > > > $ dpkg-deb -I
> > > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > > Recommends
> > > > $
> > > >
> > > > (I would have expected the last command to produce the same output as
> > > > the
> > > > penultimate one.)
> > > >
> > > > Even if I could fathom out how to fix orc and any other recipes so that
> > > > they
> > > > did add the ${PN}-lic dependency, I'd be worried about not noticing that
> > > > the problem affected other recipes in the future.
> > > >
> > > > Is there a way to teach license.bbclass:add_package_and_files to add the
> > > > ${PN}-lic recommends for dynamic packages, or would it be necessary to
> > > > teach package.bbclass to do so?
> > >
> > > That all sounds rather horrible :/.
> > >
> > > Would IMAGE_INSTALL_COMPLEMENTARY += "*-lic" work instead?
> >
> > That seems to have worked well.
> >
> > I wonder whether this means that it would be better to stop adding the
> > recommends automatically and tell users that need this to use
> > IMAGE_INSTALL_COMPLEMENTARY instead (either directly, or by teaching
> > license_image.bbclass to modify it based on another variable.)
>
> That would seem the better option to me at least...
To be clear, I'd definitely support dropping that existing RRECOMMENDS code,
I think there are better ways to handle this now. I may even write that patch :)
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153656):
https://lists.openembedded.org/g/openembedded-core/message/153656
Mute This Topic: https://lists.openembedded.org/mt/84042415/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] license.bbclass does not add recommends to dynamic packages
On Wed, 2021-07-07 at 14:05 +0100, Mike Crowe wrote:
> On Wednesday 07 July 2021 at 13:25:17 +0100, Richard Purdie wrote:
> > On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via lists.openembedded.org
> > wrote:
> > > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
> > > relying on the automatically generated recommends to cause them to be
> > > installed in the image. This works well for most packages, but fails for
> > > packages where we only install package created using PACKAGES_DYNAMIC.
> > >
> > > For example, liborc is being installed in our image but that package lacks
> > > a recommends for orc-lic, so the licences that apply to it are not being
> > > installed. This is because license.bbclass:add_package_and_files iterates
> > > only over the packages listed in PACKAGES.
> > >
> > > Steps to reproduce on current master:
> > >
> > > $ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
> > > $ bitbake orc
> > > $ dpkg-deb -I
> > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > Recommends
> > > Recommends: orc-lic
> > > $ dpkg-deb -I
> > > tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > > Recommends
> > > $
> > >
> > > (I would have expected the last command to produce the same output as the
> > > penultimate one.)
> > >
> > > Even if I could fathom out how to fix orc and any other recipes so that
> > > they
> > > did add the ${PN}-lic dependency, I'd be worried about not noticing that
> > > the problem affected other recipes in the future.
> > >
> > > Is there a way to teach license.bbclass:add_package_and_files to add the
> > > ${PN}-lic recommends for dynamic packages, or would it be necessary to
> > > teach package.bbclass to do so?
> >
> > That all sounds rather horrible :/.
> >
> > Would IMAGE_INSTALL_COMPLEMENTARY += "*-lic" work instead?
>
> That seems to have worked well.
>
> I wonder whether this means that it would be better to stop adding the
> recommends automatically and tell users that need this to use
> IMAGE_INSTALL_COMPLEMENTARY instead (either directly, or by teaching
> license_image.bbclass to modify it based on another variable.)
That would seem the better option to me at least...
> Losing the recommends would also meaan I wouldn't need to add
> --no-recommends to the image recipes that don't need the licence files.
>
> Thanks for the speedy response!
No problem, glad it works/helps!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153655):
https://lists.openembedded.org/g/openembedded-core/message/153655
Mute This Topic: https://lists.openembedded.org/mt/84042415/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] oeqa/selftest/recipetool: update socat version to fix failing download
If the recipetool tests are run with an empty DL_DIR the fetch of
socat 1.7.3.0 fails as that URL doesn't exist anymore.
Update the version to 1.7.4.1 to fix the test.
Signed-off-by: Ross Burton
---
meta/lib/oeqa/selftest/cases/recipetool.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
b/meta/lib/oeqa/selftest/cases/recipetool.py
index 9d56e9e1e32..f0685d37182 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -374,7 +374,7 @@ class RecipetoolTests(RecipetoolBase):
# Try adding a recipe
temprecipe = os.path.join(self.tempdir, 'recipe')
os.makedirs(temprecipe)
-pv = '1.7.3.0'
+pv = '1.7.4.1'
srcuri = 'http://www.dest-unreach.org/socat/download/socat-%s.tar.bz2'
% pv
result = runCmd('recipetool create %s -o %s' % (srcuri, temprecipe))
dirlist = os.listdir(temprecipe)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153654):
https://lists.openembedded.org/g/openembedded-core/message/153654
Mute This Topic: https://lists.openembedded.org/mt/84047634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] python3-setuptools: upgrade 57.0.0 -> 57.1.0
Seems like reproducibility.patch can actually be removed, as it was
accepted upstream?
Alex
On Wed, 7 Jul 2021 at 17:45, wangmy wrote:
> refresh reproducibility.patch
>
> v57.1.0
> ---
>
> Changes
> ^^^
> * #2692: Globs are now sorted in 'license_files' restoring reproducibility
> by eliminating variance from disk order.
> * #2714: Update to distutils at pypa/distutils@e2627b7.
> * #2715: Removed reliance on deprecated ssl.match_hostname by removing the
> ssl support. Now any index operations rely on the native SSL implementation.
>
> Documentation changes
> ^
> * #2604: Revamped the backward/cross tool compatibility section to remove
> some confusion.
> Add some examples and the version since when ``entry_points`` are
> supported in declarative configuration.
> Tried to make the reading flow a bit leaner, gather some informations
> that were a bit dispersed.
>
> Signed-off-by: Wang Mingyu
> ---
> .../python3-setuptools/reproducibility.patch | 21 ---
> ...57.0.0.bb => python3-setuptools_57.1.0.bb} | 2 +-
> 2 files changed, 15 insertions(+), 8 deletions(-)
> rename meta/recipes-devtools/python/{python3-setuptools_57.0.0.bb =>
> python3-setuptools_57.1.0.bb} (94%)
>
> diff --git
> a/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
> b/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
> index 149d8ad5ce..fda520658e 100644
> --- a/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
> +++ b/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
> @@ -1,4 +1,4 @@
> -The License-File lines in PKG-INFO change ordering depending on the order
> on disk,
> +The License-File lines in PKG-INFO change ordering depending on the order
> on disk,
> for example for python-packaging, one build shows:
>
> License-File: LICENSE
> @@ -15,11 +15,15 @@ This is because glob uses os.listdir() which is
> unsorted. Sort the result to avo
>
> Upstream-Status: Submitted [
> https://github.com/pypa/setuptools/issues/2691]
> Signed-off-by: Richard Purdie
> +Signed-off-by: Wang Mingyu
> +---
> + setuptools/dist.py | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
>
> -Index: setuptools-57.0.0/setuptools/dist.py
> -===
> setuptools-57.0.0.orig/setuptools/dist.py
> -+++ setuptools-57.0.0/setuptools/dist.py
> +diff --git a/setuptools/dist.py b/setuptools/dist.py
> +index df071c1..fe3c5da 100644
> +--- a/setuptools/dist.py
> b/setuptools/dist.py
> @@ -15,7 +15,7 @@ import distutils.command
> from distutils.util import strtobool
> from distutils.debug import DEBUG
> @@ -29,12 +33,15 @@ Index: setuptools-57.0.0/setuptools/dist.py
> import itertools
> import textwrap
> from typing import List, Optional, TYPE_CHECKING
> -@@ -603,7 +603,7 @@ class Distribution(_Distribution):
> +@@ -609,7 +609,7 @@ class Distribution(_Distribution):
> return (
> path
> for pattern in patterns
> --for path in iglob(pattern)
> +-for path in sorted(iglob(pattern))
> +for path in sorted(glob(pattern))
> if not path.endswith('~')
> and os.path.isfile(path)
> )
> +--
> +2.25.1
> +
> diff --git a/meta/recipes-devtools/python/python3-setuptools_57.0.0.bb
> b/meta/recipes-devtools/python/python3-setuptools_57.1.0.bb
> similarity index 94%
> rename from meta/recipes-devtools/python/python3-setuptools_57.0.0.bb
> rename to meta/recipes-devtools/python/python3-setuptools_57.1.0.bb
> index a15b51e31c..3c7aa4c4c5 100644
> --- a/meta/recipes-devtools/python/python3-setuptools_57.0.0.bb
> +++ b/meta/recipes-devtools/python/python3-setuptools_57.1.0.bb
> @@ -11,7 +11,7 @@ SRC_URI_append_class-native = "
> file://0001-conditionally-do-not-fetch-code-by-e
> SRC_URI += "file://0001-change-shebang-to-python3.patch \
> file://reproducibility.patch"
>
> -SRC_URI[sha256sum] =
> "401cbf33a7bf817d08014d51560fc003b895c4cdc1a5b521ad2969e928a07535"
> +SRC_URI[sha256sum] =
> "cfca9c97e7eebbc8abe18d5e5e962a08dcad55bb63afddd82d681de4d22a597b"
>
> DEPENDS += "${PYTHON_PN}"
>
> --
> 2.25.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153653):
https://lists.openembedded.org/g/openembedded-core/message/153653
Mute This Topic: https://lists.openembedded.org/mt/84047336/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] vulkan-tools: upgrade 1.2.176 -> 1.2.182
build: Update to header 1.2.182
- Update known-good
- Add support for printing `int64_t` in `scripts/vulkaninfo_generator.py`
- Disable codegen for VK_HUAWEI_subpass_shading
KhronosGroup/Vulkan-Docs#1564
- Generate source
Signed-off-by: Wang Mingyu
---
.../{vulkan-tools_1.2.176.0.bb => vulkan-tools_1.2.182.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/vulkan/{vulkan-tools_1.2.176.0.bb =>
vulkan-tools_1.2.182.0.bb} (94%)
diff --git a/meta/recipes-graphics/vulkan/vulkan-tools_1.2.176.0.bb
b/meta/recipes-graphics/vulkan/vulkan-tools_1.2.182.0.bb
similarity index 94%
rename from meta/recipes-graphics/vulkan/vulkan-tools_1.2.176.0.bb
rename to meta/recipes-graphics/vulkan/vulkan-tools_1.2.182.0.bb
index 10fa0fdb3a..d0a298ecfc 100644
--- a/meta/recipes-graphics/vulkan/vulkan-tools_1.2.176.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-tools_1.2.182.0.bb
@@ -6,8 +6,8 @@ SECTION = "libs"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=3b83ef96387f14655fc854ddc3c6bd57"
-SRC_URI = "git://github.com/KhronosGroup/Vulkan-Tools.git;branch=sdk-1.2.176"
-SRCREV = "eb3d67bd17ee433e2b0a8e56a7249bd83908812e"
+SRC_URI = "git://github.com/KhronosGroup/Vulkan-Tools.git;branch=sdk-1.2.182"
+SRCREV = "9d3305731c3be8de05c9f223a79959d448506a37"
S = "${WORKDIR}/git"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153652):
https://lists.openembedded.org/g/openembedded-core/message/153652
Mute This Topic: https://lists.openembedded.org/mt/84047370/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] vulkan-headers: upgrade 1.2.176 -> 1.2.182
Add reference to multiple Hpp headers added to this repository
Signed-off-by: Wang Mingyu
---
...{vulkan-headers_1.2.176.0.bb => vulkan-headers_1.2.182.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/vulkan/{vulkan-headers_1.2.176.0.bb =>
vulkan-headers_1.2.182.0.bb} (93%)
diff --git a/meta/recipes-graphics/vulkan/vulkan-headers_1.2.176.0.bb
b/meta/recipes-graphics/vulkan/vulkan-headers_1.2.182.0.bb
similarity index 93%
rename from meta/recipes-graphics/vulkan/vulkan-headers_1.2.176.0.bb
rename to meta/recipes-graphics/vulkan/vulkan-headers_1.2.182.0.bb
index cff654a06c..736af7b9e7 100644
--- a/meta/recipes-graphics/vulkan/vulkan-headers_1.2.176.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-headers_1.2.182.0.bb
@@ -11,7 +11,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=3b83ef96387f14655fc854ddc3c6bd57"
SRC_URI = "git://github.com/KhronosGroup/Vulkan-Headers.git;branch=master"
-SRCREV = "074fa3055cfee530992bcbfa0fcb23106a82c1ab"
+SRCREV = "37164a5726f7e6113810f9557903a117498421cf"
S = "${WORKDIR}/git"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153650):
https://lists.openembedded.org/g/openembedded-core/message/153650
Mute This Topic: https://lists.openembedded.org/mt/84047367/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] vulkan-loader: upgrade 1.2.176 -> 1.2.182
build: Update to header 1.2.182
- Update known-good
- Disable codegen for VK_HUAWEI_subpass_shading
KhronosGroup/Vulkan-Docs#1564
- Generate source
Signed-off-by: Wang Mingyu
---
.../{vulkan-loader_1.2.176.0.bb => vulkan-loader_1.2.182.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/vulkan/{vulkan-loader_1.2.176.0.bb =>
vulkan-loader_1.2.182.0.bb} (96%)
diff --git a/meta/recipes-graphics/vulkan/vulkan-loader_1.2.176.0.bb
b/meta/recipes-graphics/vulkan/vulkan-loader_1.2.182.0.bb
similarity index 96%
rename from meta/recipes-graphics/vulkan/vulkan-loader_1.2.176.0.bb
rename to meta/recipes-graphics/vulkan/vulkan-loader_1.2.182.0.bb
index e241a2f156..ec09fd0f72 100644
--- a/meta/recipes-graphics/vulkan/vulkan-loader_1.2.176.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-loader_1.2.182.0.bb
@@ -11,7 +11,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=7dbefed23242760aa3475ee42801c5ac"
SRC_URI = "git://github.com/KhronosGroup/Vulkan-Loader.git \
"
-SRCREV = "eb6d6f95dff809d66e95b903105da6424e75862f"
+SRCREV = "1896143df69d439b0933c1bb485f5a4587bdf2dc"
S = "${WORKDIR}/git"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153651):
https://lists.openembedded.org/g/openembedded-core/message/153651
Mute This Topic: https://lists.openembedded.org/mt/84047368/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] gnome-desktop-testing: upgrade 2018.1 -> 2021.1
Signed-off-by: Wang Mingyu
---
...esktop-testing_2018.1.bb => gnome-desktop-testing_2021.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename
meta/recipes-support/gnome-desktop-testing/{gnome-desktop-testing_2018.1.bb =>
gnome-desktop-testing_2021.1.bb} (94%)
diff --git
a/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2018.1.bb
b/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2021.1.bb
similarity index 94%
rename from
meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2018.1.bb
rename to
meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2021.1.bb
index e5c69c0c46..b82eb8af2e 100644
--- a/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2018.1.bb
+++ b/meta/recipes-support/gnome-desktop-testing/gnome-desktop-testing_2021.1.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7 \
file://src/gnome-desktop-testing-runner.c;beginline=1;endline=20;md5=7ef3ad9da2ffcf7707dc11151fe007f4"
SRC_URI =
"git://gitlab.gnome.org/GNOME/gnome-desktop-testing.git;protocol=http"
-SRCREV = "4decade67b29ad170fcf3de148e41695fc459f48"
+SRCREV = "e346cd4ed2e2102c9b195b614f3c642d23f5f6e7"
DEPENDS = "glib-2.0"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153646):
https://lists.openembedded.org/g/openembedded-core/message/153646
Mute This Topic: https://lists.openembedded.org/mt/84047332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] python3-importlib-metadata: upgrade 4.6.0 -> 4.6.1
v4.6.1
==
* #327: Deprecation warnings now honor call stack variance
on PyPy.
Signed-off-by: Wang Mingyu
---
...ib-metadata_4.6.0.bb => python3-importlib-metadata_4.6.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-importlib-metadata_4.6.0.bb =>
python3-importlib-metadata_4.6.1.bb} (88%)
diff --git a/meta/recipes-devtools/python/python3-importlib-metadata_4.6.0.bb
b/meta/recipes-devtools/python/python3-importlib-metadata_4.6.1.bb
similarity index 88%
rename from meta/recipes-devtools/python/python3-importlib-metadata_4.6.0.bb
rename to meta/recipes-devtools/python/python3-importlib-metadata_4.6.1.bb
index b9fd2fe59e..7e9604aaf4 100644
--- a/meta/recipes-devtools/python/python3-importlib-metadata_4.6.0.bb
+++ b/meta/recipes-devtools/python/python3-importlib-metadata_4.6.1.bb
@@ -8,7 +8,7 @@ inherit pypi setuptools3
PYPI_PACKAGE = "importlib_metadata"
UPSTREAM_CHECK_REGEX = "/importlib-metadata/(?P(\d+[\.\-_]*)+)/"
-SRC_URI[sha256sum] =
"4a5611fea3768d3d967c447ab4e93f567d95db92225b43b7b238dbfb855d70bb"
+SRC_URI[sha256sum] =
"079ada16b7fc30dfbb5d13399a5113110dab1aa7c2bc62f66af75f0b717c8cac"
S = "${WORKDIR}/importlib_metadata-${PV}"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153647):
https://lists.openembedded.org/g/openembedded-core/message/153647
Mute This Topic: https://lists.openembedded.org/mt/84047334/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] u-boot: upgrade 2021.04 -> 2021.07
(Changes of v2021.07)
Processed 1730 csets from 187 developers
29 employers found
A total of 402449 lines added, 82710 removed (delta 319739)
Signed-off-by: Wang Mingyu
---
meta/recipes-bsp/u-boot/u-boot-common.inc | 2 +-
.../u-boot/{u-boot-tools_2021.04.bb => u-boot-tools_2021.07.bb} | 0
.../recipes-bsp/u-boot/{u-boot_2021.04.bb => u-boot_2021.07.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-bsp/u-boot/{u-boot-tools_2021.04.bb =>
u-boot-tools_2021.07.bb} (100%)
rename meta/recipes-bsp/u-boot/{u-boot_2021.04.bb => u-boot_2021.07.bb} (100%)
diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index dbbb9ff145..6b9253806f 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -12,7 +12,7 @@ PE = "1"
# We use the revision in order to avoid having to fetch it from the
# repo during parse
-SRCREV = "b46dd116ce03e235f2a7d4843c6278e1da44b5e1"
+SRCREV = "840658b093976390e9537724f802281c9c8439f5"
SRC_URI = "git://git.denx.de/u-boot.git \
"
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2021.04.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2021.07.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-tools_2021.04.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2021.07.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2021.04.bb
b/meta/recipes-bsp/u-boot/u-boot_2021.07.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2021.04.bb
rename to meta/recipes-bsp/u-boot/u-boot_2021.07.bb
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153649):
https://lists.openembedded.org/g/openembedded-core/message/153649
Mute This Topic: https://lists.openembedded.org/mt/84047337/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] python3-setuptools: upgrade 57.0.0 -> 57.1.0
refresh reproducibility.patch
v57.1.0
---
Changes
^^^
* #2692: Globs are now sorted in 'license_files' restoring reproducibility by
eliminating variance from disk order.
* #2714: Update to distutils at pypa/distutils@e2627b7.
* #2715: Removed reliance on deprecated ssl.match_hostname by removing the ssl
support. Now any index operations rely on the native SSL implementation.
Documentation changes
^
* #2604: Revamped the backward/cross tool compatibility section to remove
some confusion.
Add some examples and the version since when ``entry_points`` are
supported in declarative configuration.
Tried to make the reading flow a bit leaner, gather some informations
that were a bit dispersed.
Signed-off-by: Wang Mingyu
---
.../python3-setuptools/reproducibility.patch | 21 ---
...57.0.0.bb => python3-setuptools_57.1.0.bb} | 2 +-
2 files changed, 15 insertions(+), 8 deletions(-)
rename meta/recipes-devtools/python/{python3-setuptools_57.0.0.bb =>
python3-setuptools_57.1.0.bb} (94%)
diff --git
a/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
b/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
index 149d8ad5ce..fda520658e 100644
--- a/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
+++ b/meta/recipes-devtools/python/python3-setuptools/reproducibility.patch
@@ -1,4 +1,4 @@
-The License-File lines in PKG-INFO change ordering depending on the order on
disk,
+The License-File lines in PKG-INFO change ordering depending on the order on
disk,
for example for python-packaging, one build shows:
License-File: LICENSE
@@ -15,11 +15,15 @@ This is because glob uses os.listdir() which is unsorted.
Sort the result to avo
Upstream-Status: Submitted [https://github.com/pypa/setuptools/issues/2691]
Signed-off-by: Richard Purdie
+Signed-off-by: Wang Mingyu
+---
+ setuptools/dist.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
-Index: setuptools-57.0.0/setuptools/dist.py
-===
setuptools-57.0.0.orig/setuptools/dist.py
-+++ setuptools-57.0.0/setuptools/dist.py
+diff --git a/setuptools/dist.py b/setuptools/dist.py
+index df071c1..fe3c5da 100644
+--- a/setuptools/dist.py
b/setuptools/dist.py
@@ -15,7 +15,7 @@ import distutils.command
from distutils.util import strtobool
from distutils.debug import DEBUG
@@ -29,12 +33,15 @@ Index: setuptools-57.0.0/setuptools/dist.py
import itertools
import textwrap
from typing import List, Optional, TYPE_CHECKING
-@@ -603,7 +603,7 @@ class Distribution(_Distribution):
+@@ -609,7 +609,7 @@ class Distribution(_Distribution):
return (
path
for pattern in patterns
--for path in iglob(pattern)
+-for path in sorted(iglob(pattern))
+for path in sorted(glob(pattern))
if not path.endswith('~')
and os.path.isfile(path)
)
+--
+2.25.1
+
diff --git a/meta/recipes-devtools/python/python3-setuptools_57.0.0.bb
b/meta/recipes-devtools/python/python3-setuptools_57.1.0.bb
similarity index 94%
rename from meta/recipes-devtools/python/python3-setuptools_57.0.0.bb
rename to meta/recipes-devtools/python/python3-setuptools_57.1.0.bb
index a15b51e31c..3c7aa4c4c5 100644
--- a/meta/recipes-devtools/python/python3-setuptools_57.0.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_57.1.0.bb
@@ -11,7 +11,7 @@ SRC_URI_append_class-native = "
file://0001-conditionally-do-not-fetch-code-by-e
SRC_URI += "file://0001-change-shebang-to-python3.patch \
file://reproducibility.patch"
-SRC_URI[sha256sum] =
"401cbf33a7bf817d08014d51560fc003b895c4cdc1a5b521ad2969e928a07535"
+SRC_URI[sha256sum] =
"cfca9c97e7eebbc8abe18d5e5e962a08dcad55bb63afddd82d681de4d22a597b"
DEPENDS += "${PYTHON_PN}"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153648):
https://lists.openembedded.org/g/openembedded-core/message/153648
Mute This Topic: https://lists.openembedded.org/mt/84047336/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] xserver-xorg: exclude development snapshots from upstream version checks
Standalone X is still winding down; there's no commitment or plan for a proper
release.
https://lists.freedesktop.org/archives/xorg/2021-July/060726.html
Signed-off-by: Alexander Kanavin
---
meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index da025171db..e2fefd9db8 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -17,6 +17,8 @@ PE = "2"
XORG_PN = "xorg-server"
SRC_URI = "${XORG_MIRROR}/individual/xserver/${XORG_PN}-${PV}.tar.bz2"
+UPSTREAM_CHECK_REGEX = "xorg-server-(?P\d+(\.(?!99)\d+)+)\.tar"
+
CVE_PRODUCT = "xorg-server"
S = "${WORKDIR}/${XORG_PN}-${PV}"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153644):
https://lists.openembedded.org/g/openembedded-core/message/153644
Mute This Topic: https://lists.openembedded.org/mt/84046750/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] xwayland: exclude development snapshots from upstream version checks
Signed-off-by: Alexander Kanavin
---
meta/recipes-graphics/xwayland/xwayland_21.1.1.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-graphics/xwayland/xwayland_21.1.1.bb
b/meta/recipes-graphics/xwayland/xwayland_21.1.1.bb
index faf166f788..f5db7cc5db 100644
--- a/meta/recipes-graphics/xwayland/xwayland_21.1.1.bb
+++ b/meta/recipes-graphics/xwayland/xwayland_21.1.1.bb
@@ -12,6 +12,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=5df87950af51ac2c5822094553ea1880"
SRC_URI = "https://www.x.org/archive/individual/xserver/xwayland-${PV}.tar.xz;
SRC_URI[sha256sum] =
"31f261ce51bbee76a6ca3ec02aa367ffa2b5efa2b98412df57ccefd7a19003ce"
+UPSTREAM_CHECK_REGEX = "xwayland-(?P\d+(\.(?!90\d)\d+)+)\.tar"
+
inherit meson features_check
REQUIRED_DISTRO_FEATURES = "x11 opengl"
--
2.31.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153645):
https://lists.openembedded.org/g/openembedded-core/message/153645
Mute This Topic: https://lists.openembedded.org/mt/84046751/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] license.bbclass does not add recommends to dynamic packages
On Wednesday 07 July 2021 at 13:25:17 +0100, Richard Purdie wrote:
> On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via lists.openembedded.org
> wrote:
> > We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
> > relying on the automatically generated recommends to cause them to be
> > installed in the image. This works well for most packages, but fails for
> > packages where we only install package created using PACKAGES_DYNAMIC.
> >
> > For example, liborc is being installed in our image but that package lacks
> > a recommends for orc-lic, so the licences that apply to it are not being
> > installed. This is because license.bbclass:add_package_and_files iterates
> > only over the packages listed in PACKAGES.
> >
> > Steps to reproduce on current master:
> >
> > $ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
> > $ bitbake orc
> > $ dpkg-deb -I
> > tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > Recommends
> > Recommends: orc-lic
> > $ dpkg-deb -I
> > tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> > Recommends
> > $
> >
> > (I would have expected the last command to produce the same output as the
> > penultimate one.)
> >
> > Even if I could fathom out how to fix orc and any other recipes so that they
> > did add the ${PN}-lic dependency, I'd be worried about not noticing that
> > the problem affected other recipes in the future.
> >
> > Is there a way to teach license.bbclass:add_package_and_files to add the
> > ${PN}-lic recommends for dynamic packages, or would it be necessary to
> > teach package.bbclass to do so?
>
> That all sounds rather horrible :/.
>
> Would IMAGE_INSTALL_COMPLEMENTARY += "*-lic" work instead?
That seems to have worked well.
I wonder whether this means that it would be better to stop adding the
recommends automatically and tell users that need this to use
IMAGE_INSTALL_COMPLEMENTARY instead (either directly, or by teaching
license_image.bbclass to modify it based on another variable.)
Losing the recommends would also meaan I wouldn't need to add
--no-recommends to the image recipes that don't need the licence files.
Thanks for the speedy response!
Mike.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153643):
https://lists.openembedded.org/g/openembedded-core/message/153643
Mute This Topic: https://lists.openembedded.org/mt/84042415/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] license.bbclass does not add recommends to dynamic packages
On Wed, 2021-07-07 at 12:53 +0100, Mike Crowe via lists.openembedded.org wrote:
> We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
> relying on the automatically generated recommends to cause them to be
> installed in the image. This works well for most packages, but fails for
> packages where we only install package created using PACKAGES_DYNAMIC.
>
> For example, liborc is being installed in our image but that package lacks
> a recommends for orc-lic, so the licences that apply to it are not being
> installed. This is because license.bbclass:add_package_and_files iterates
> only over the packages listed in PACKAGES.
>
> Steps to reproduce on current master:
>
> $ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
> $ bitbake orc
> $ dpkg-deb -I
> tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> Recommends
> Recommends: orc-lic
> $ dpkg-deb -I
> tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
> Recommends
> $
>
> (I would have expected the last command to produce the same output as the
> penultimate one.)
>
> Even if I could fathom out how to fix orc and any other recipes so that they
> did add the ${PN}-lic dependency, I'd be worried about not noticing that
> the problem affected other recipes in the future.
>
> Is there a way to teach license.bbclass:add_package_and_files to add the
> ${PN}-lic recommends for dynamic packages, or would it be necessary to
> teach package.bbclass to do so?
That all sounds rather horrible :/.
Would IMAGE_INSTALL_COMPLEMENTARY += "*-lic" work instead?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153642):
https://lists.openembedded.org/g/openembedded-core/message/153642
Mute This Topic: https://lists.openembedded.org/mt/84042415/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] qemuarm64.conf: change the cpu model to max
'max' implies that it's not stable and will change depending on qemu
version and build settings. Can you set it to a specific model?
Alex
On Wed, 7 Jul 2021 at 10:55, Yu, Mingli wrote:
> From: Mingli Yu
>
> After rng-tools upgraded to 6.13, the below logic introduced.
> 9070a04 Add support for ARM v8.5A "rndr" instruction
>
> It means there is another entropy source rndr added for arm64,
> so modify the cpu model to max [1] to make the rndr entropy source
> function available and also used to silence the below failed message
> when start rngd service on qemuarm64.
> "[rndr ]: Initialization Failed"
>
> Before the patch:
> $ systemctl status rngd
> [snip]
> Jul 05 07:15:47 qemuarm64 systemd[1]: Started Hardware RNG Entropy
> Gatherer Daemon.
> Jul 05 07:15:48 qemuarm64 rngd[152]: Initializing available sources
> Jul 05 07:15:48 qemuarm64 rngd[152]: [hwrng ]: Initialized
> Jul 05 07:15:48 qemuarm64 rngd[152]: [rndr ]: No HW SUPPORT
> Jul 05 07:15:48 qemuarm64 rngd[152]: [rndr ]: Initialization Failed
> Jul 05 07:15:48 qemuarm64 rngd[152]: [jitter]: Initializing AES buffer
> Jul 05 07:16:14 qemuarm64 rngd[152]: [jitter]: Enabling JITTER rng support
> Jul 05 07:16:14 qemuarm64 rngd[152]: [jitter]: Initialized
>
> After the patch:
> $ systemctl status rngd
> [snip]
> Jul 07 08:48:30 qemuarm64 systemd[1]: Started Hardware RNG Entropy
> Gatherer Daemon.
> Jul 07 08:48:34 qemuarm64 rngd[164]: Initializing available sources
> Jul 07 08:48:34 qemuarm64 rngd[164]: [hwrng ]: Initialized
> Jul 07 08:48:34 qemuarm64 rngd[164]: [rndr ]: Enabling aarch64 RNDR rng
> support
> Jul 07 08:48:34 qemuarm64 rngd[164]: [rndr ]: Initialized
> Jul 07 08:48:35 qemuarm64 rngd[164]: [jitter]: Initializing AES buffer
>
> [1] https://github.com/nhorman/rng-tools/pull/128
>
> Signed-off-by: Mingli Yu
> ---
> meta/conf/machine/qemuarm64.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/machine/qemuarm64.conf
> b/meta/conf/machine/qemuarm64.conf
> index 150a0744eb..a792dc32e6 100644
> --- a/meta/conf/machine/qemuarm64.conf
> +++ b/meta/conf/machine/qemuarm64.conf
> @@ -15,7 +15,7 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
> # For runqemu
> QB_SYSTEM_NAME = "qemu-system-aarch64"
> QB_MACHINE = "-machine virt"
> -QB_CPU = "-cpu cortex-a57"
> +QB_CPU = "-cpu max"
> QB_SMP = "-smp 4"
> QB_CPU_KVM = "-cpu host -machine gic-version=3"
> # For graphics to work we need to define the VGA device as well as the
> necessary USB devices
> --
> 2.17.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153641):
https://lists.openembedded.org/g/openembedded-core/message/153641
Mute This Topic: https://lists.openembedded.org/mt/84040384/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] license.bbclass does not add recommends to dynamic packages
We're using LICENSE_CREATE_PACKAGE to create ${PN}-lic package files and
relying on the automatically generated recommends to cause them to be
installed in the image. This works well for most packages, but fails for
packages where we only install package created using PACKAGES_DYNAMIC.
For example, liborc is being installed in our image but that package lacks
a recommends for orc-lic, so the licences that apply to it are not being
installed. This is because license.bbclass:add_package_and_files iterates
only over the packages listed in PACKAGES.
Steps to reproduce on current master:
$ echo 'LICENSE_CREATE_PACKAGE = "1"' >> conf/local.conf
$ bitbake orc
$ dpkg-deb -I
tmp-glibc/deploy/ipk/armv7vet2hf-neon/orc_0.4.32-r0_armv7vet2hf-neon.ipk|grep
Recommends
Recommends: orc-lic
$ dpkg-deb -I
tmp-glibc/deploy/ipk/armv7vet2hf-neon/liborc-0.4-0_0.4.32-r0_armv7vet2hf-neon.ipk|grep
Recommends
$
(I would have expected the last command to produce the same output as the
penultimate one.)
Even if I could fathom out how to fix orc and any other recipes so that they
did add the ${PN}-lic dependency, I'd be worried about not noticing that
the problem affected other recipes in the future.
Is there a way to teach license.bbclass:add_package_and_files to add the
${PN}-lic recommends for dynamic packages, or would it be necessary to
teach package.bbclass to do so?
Thanks.
Mike.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153640):
https://lists.openembedded.org/g/openembedded-core/message/153640
Mute This Topic: https://lists.openembedded.org/mt/84042415/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"
Em qua., 7 de jul. de 2021 às 06:50, Ming Liu escreveu: > @Otavio Salvador > > libubootenv will fall back to read environment > from /etc/u-boot-initial-env if loading /etc/fw_env.config fails, so > attempt to say it's not too wrong. > > To avoid world build failures, maybe set EXCLUDE_FROM_WORLD = "1"? > If Richard accepts it, it is good enough for me. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153639): https://lists.openembedded.org/g/openembedded-core/message/153639 Mute This Topic: https://lists.openembedded.org/mt/83938334/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] glibc-package.inc: To fix build issue with glibc-testsuite.
On Sun, 2021-07-04 at 04:21 -0700, Vinay Kumar wrote:
> Added condition to check "$cleanupdir${datadir}" exists.
>
> Signed-off-by: Vinay Kumar
> ---
> meta/recipes-core/glibc/glibc-package.inc | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-core/glibc/glibc-package.inc
> b/meta/recipes-core/glibc/glibc-package.inc
> index 92e5dbac61..df3f612192 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -230,7 +230,9 @@ stash_locale_cleanup () {
> rm -rf $cleanupdir${libdir}/gconv
> rm -rf $cleanupdir${localedir}
> rm -rf $cleanupdir${datadir}/locale
> + if [ -d $cleanupdir${datadir} ]; then
> rmdir --ignore-fail-on-non-empty $cleanupdir${datadir}
> + fi;
>
>
>
>
> if [ "${libdir}" != "${exec_prefix}/lib" ] && [ "${root_prefix}/lib" !=
> "${exec_prefix}/lib" ]; then
> if [ -d "$cleanupdir${exec_prefix}/lib" ]; then
I had a look into this issue in more detail and you're right, if you
bitbake the recipe it does indeed fail. The reason it doesn't fail
everywhere in testing is that it is excluded from world builds.
Since there is no do_install task, the do_populate_sysroot task
is also pointless. I've sent a patch just to delete the task.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153638):
https://lists.openembedded.org/g/openembedded-core/message/153638
Mute This Topic: https://lists.openembedded.org/mt/83976017/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] runqemu: Remove potential lock races around tap device handling
The qemu tap device handling is potentially race ridden. We pass the
fd to the main qemu subprocess which is good as it means the lock is held
as long as the qemu process exists. This means we shouldn't unlock it
ourselves though, only close the file. We also can't delete the file
as we have no idea if qemu is still using it. We could try and obtain
an exclusive new lock, then the file would be safe to unlink but it
doesn't seem worth it.
Also fix the same issue in the port lock code.
Signed-off-by: Richard Purdie
---
scripts/runqemu | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 1f332ef5252..2914f15d06c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -233,9 +233,12 @@ class BaseConfig(object):
def release_taplock(self):
if self.taplock_descriptor:
logger.debug("Releasing lockfile for tap device '%s'" % self.tap)
-fcntl.flock(self.taplock_descriptor, fcntl.LOCK_UN)
+# We pass the fd to the qemu process and if we unlock here, it
would unlock for
+# that too. Therefore don't unlock, just close
+# fcntl.flock(self.taplock_descriptor, fcntl.LOCK_UN)
self.taplock_descriptor.close()
-os.remove(self.taplock)
+# Removing the file is a potential race, don't do that either
+# os.remove(self.taplock)
self.taplock_descriptor = None
def check_free_port(self, host, port, lockdir):
@@ -273,17 +276,23 @@ class BaseConfig(object):
def release_portlock(self, lockfile=None):
if lockfile != None:
- logger.debug("Releasing lockfile '%s'" % lockfile)
- fcntl.flock(self.portlocks[lockfile], fcntl.LOCK_UN)
- self.portlocks[lockfile].close()
- os.remove(lockfile)
- del self.portlocks[lockfile]
+logger.debug("Releasing lockfile '%s'" % lockfile)
+# We pass the fd to the qemu process and if we unlock here, it
would unlock for
+# that too. Therefore don't unlock, just close
+# fcntl.flock(self.portlocks[lockfile], fcntl.LOCK_UN)
+self.portlocks[lockfile].close()
+# Removing the file is a potential race, don't do that either
+# os.remove(lockfile)
+del self.portlocks[lockfile]
elif len(self.portlocks):
for lockfile, descriptor in self.portlocks.items():
logger.debug("Releasing lockfile '%s'" % lockfile)
-fcntl.flock(descriptor, fcntl.LOCK_UN)
+# We pass the fd to the qemu process and if we unlock here, it
would unlock for
+# that too. Therefore don't unlock, just close
+# fcntl.flock(descriptor, fcntl.LOCK_UN)
descriptor.close()
-os.remove(lockfile)
+# Removing the file is a potential race, don't do that either
+# os.remove(lockfile)
self.portlocks = {}
def get(self, key):
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153636):
https://lists.openembedded.org/g/openembedded-core/message/153636
Mute This Topic: https://lists.openembedded.org/mt/84041236/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] glibc-testsuite: Fix build failures when directly running recipe
If you try and run the glibc-testsuite's build task, you see failures as do_populate_sysroot can't work. We don't have a do_install, get rid of do_populate_sysroot as well. The recipe is not included in world builds by default which is why we don't see the issue more widely. Signed-off-by: Richard Purdie --- meta/recipes-core/glibc/glibc-testsuite_2.33.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/glibc/glibc-testsuite_2.33.bb b/meta/recipes-core/glibc/glibc-testsuite_2.33.bb index d887aeff79a..659d3132fa6 100644 --- a/meta/recipes-core/glibc/glibc-testsuite_2.33.bb +++ b/meta/recipes-core/glibc/glibc-testsuite_2.33.bb @@ -61,3 +61,4 @@ addtask do_check after do_compile inherit nopackages deltask do_stash_locale deltask do_install +deltask do_populate_sysroot -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153637): https://lists.openembedded.org/g/openembedded-core/message/153637 Mute This Topic: https://lists.openembedded.org/mt/84041237/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"
@Otavio Salvador libubootenv will fall back to read environment from /etc/u-boot-initial-env if loading /etc/fw_env.config fails, so attempt to say it's not too wrong. To avoid world build failures, maybe set EXCLUDE_FROM_WORLD = "1"? //Ming Liu Otavio Salvador 於 2021年7月6日 週二 下午6:56寫道： > > > Em ter., 6 de jul. de 2021 às 12:12, Peter Bergin > escreveu: > >> Then I can correct my earlier statement and a new wisdom that run-time >> dependecies are scanned already in the early phases. Apparently it is >> not possible to build libubootenv due to RRECOMMENDS to >> u-boot-default-env. The build for a 'non-u-boot config' will fail if we >> add 'inherit uboot-config' and it will fail without. What is the >> difference for a 'world' build? >> > > The dependency on the default-env seems too strong. It could be relaxed as > it works without it. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153635): https://lists.openembedded.org/g/openembedded-core/message/153635 Mute This Topic: https://lists.openembedded.org/mt/83938334/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [poky][dunfell][PATCH] busybox: fix CVE-2021-28831
From: Chen Qi
Backport patch to fix CVE-2021-28831.
(From OE-Core rev: e579dbd9a6b2472ca90f411c0b594da9e38c9aca)
Signed-off-by: Chen Qi
Signed-off-by: Richard Purdie
Signed-off-by: Akash Hadke
---
...ompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch | 51 ++
meta/recipes-core/busybox/busybox_1.31.1.bb| 3 +-
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-core/busybox/busybox/0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch
diff --git
a/meta/recipes-core/busybox/busybox/0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch
b/meta/recipes-core/busybox/busybox/0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch
new file mode 100644
index 000..b75f090
--- /dev/null
+++
b/meta/recipes-core/busybox/busybox/0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch
@@ -0,0 +1,51 @@
+From fe791386ebc270219ca00406c9fdadc5130b64ee Mon Sep 17 00:00:00 2001
+From: Samuel Sapalski
+Date: Wed, 3 Mar 2021 16:31:22 +0100
+Subject: [PATCH] decompress_gunzip: Fix DoS if gzip is corrupt
+
+On certain corrupt gzip files, huft_build will set the error bit on
+the result pointer. If afterwards abort_unzip is called huft_free
+might run into a segmentation fault or an invalid pointer to
+free(p).
+
+In order to mitigate this, we check in huft_free if the error bit
+is set and clear it before the linked list is freed.
+
+Signed-off-by: Samuel Sapalski
+Signed-off-by: Peter Kaestle
+Signed-off-by: Denys Vlasenko
+
+Upstream-Status: Backport
+CVE: CVE-2021-28831
+Comment: One hunk from this patch is removed as it was not relevant.
+Signed-off-by: Chen Qi
+Signed-off-by: Akash Hadke
+---
+ archival/libarchive/decompress_gunzip.c | 12 ++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/archival/libarchive/decompress_gunzip.c
b/archival/libarchive/decompress_gunzip.c
+index eb3b64930..e93cd5005 100644
+--- a/archival/libarchive/decompress_gunzip.c
b/archival/libarchive/decompress_gunzip.c
+@@ -220,10 +220,20 @@ static const uint8_t border[] ALIGN1 = {
+ * each table.
+ * t: table to free
+ */
++#define BAD_HUFT(p) ((uintptr_t)(p) & 1)
++#define ERR_RET ((huft_t*)(uintptr_t)1)
+ static void huft_free(huft_t *p)
+ {
+ huft_t *q;
+
++ /*
++ * If 'p' has the error bit set we have to clear it, otherwise we might
run
++ * into a segmentation fault or an invalid pointer to free(p)
++ */
++ if (BAD_HUFT(p)) {
++ p = (huft_t*)((uintptr_t)(p) ^ (uintptr_t)(ERR_RET));
++ }
++
+ /* Go through linked list, freeing from the malloced (t[-1]) address. */
+ while (p) {
+ q = (--p)->v.t;
diff --git a/meta/recipes-core/busybox/busybox_1.31.1.bb
b/meta/recipes-core/busybox/busybox_1.31.1.bb
index 7563368..f7808f4 100644
--- a/meta/recipes-core/busybox/busybox_1.31.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.31.1.bb
@@ -50,7 +50,8 @@ SRC_URI =
"https://busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://0001-sysctl-ignore-EIO-of-stable_secret-below-proc-sys-ne.patch \
file://busybox-CVE-2018-1000500.patch \
file://0001-hwclock-make-glibc-2.31-compatible.patch \
-"
+ file://0001-decompress_gunzip-Fix-DoS-if-gzip-is-corrupt.patch \
+ "
SRC_URI_append_libc-musl = " file://musl.cfg "
SRC_URI[tarball.md5sum] = "70913edaf2263a157393af07565c17f0"
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153634):
https://lists.openembedded.org/g/openembedded-core/message/153634
Mute This Topic: https://lists.openembedded.org/mt/84040535/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] glib-2.0: fix g-file-into modification time test
The GFileInfo modification time test assumed that the difference between
a modification timestamp in seconds and in microseconds must be greater
than 0.
Mathmatically, there's a one-in-a-million chance that it will be 0. It
turns out that one-in-a-million chances happen approximately once every
fortnight on the autobuilder.
[ YOCTO 14373 ]
Signed-off-by: Ross Burton
---
.../glib-2.0/glib-2.0/time-test.patch | 40 +++
meta/recipes-core/glib-2.0/glib-2.0_2.68.3.bb | 1 +
2 files changed, 41 insertions(+)
create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/time-test.patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/time-test.patch
b/meta/recipes-core/glib-2.0/glib-2.0/time-test.patch
new file mode 100644
index 000..4d7ef97bb56
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/time-test.patch
@@ -0,0 +1,40 @@
+Upstream-Status: Submitted
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2177]
+Signed-off-by: Ross Burton
+
+From 289f8be1b397a453cfcf35641455f3ae5fb4faeb Mon Sep 17 00:00:00 2001
+From: Ross Burton
+Date: Tue, 6 Jul 2021 19:26:03 +0100
+Subject: [PATCH] gio/tests/g-file-info: don't assume million-in-one events
+ don't happen
+
+The modification time test creates a file, gets the modification time in
+seconds, then gets the modification time in microseconds and assumes
+that the difference between the two has to be above 0.
+
+As rare as this may be, it can happen:
+
+$ stat g-file-info-test-50A450 -c %y
+2021-07-06 18:24:56.00767 +0100
+
+Change the test to simply assert that the difference not negative to
+handle this case.
+---
+ gio/tests/g-file-info.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gio/tests/g-file-info.c b/gio/tests/g-file-info.c
+index c11c50462..fd0c64b55 100644
+--- a/gio/tests/g-file-info.c
b/gio/tests/g-file-info.c
+@@ -178,7 +178,7 @@ test_g_file_info_modification_time (void)
+ g_assert_nonnull (dt_usecs);
+
+ ts = g_date_time_difference (dt_usecs, dt);
+- g_assert_cmpint (ts, >, 0);
++ g_assert_cmpint (ts, >=, 0);
+ g_assert_cmpint (ts, <, G_USEC_PER_SEC);
+
+ /* Try round-tripping the modification time. */
+--
+2.25.1
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.68.3.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.68.3.bb
index 2a3a00fadae..62c8d49464f 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.68.3.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.68.3.bb
@@ -17,6 +17,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz
\
file://0001-meson-Run-atomics-test-on-clang-as-well.patch \
file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \
file://0001-gio-tests-codegen.py-bump-timeout-to-100-seconds.patch \
+ file://time-test.patch \
"
SRC_URI_append_class-native = " file://relocate-modules.patch"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153633):
https://lists.openembedded.org/g/openembedded-core/message/153633
Mute This Topic: https://lists.openembedded.org/mt/84040480/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] qemuarm64.conf: change the cpu model to max
From: Mingli Yu
After rng-tools upgraded to 6.13, the below logic introduced.
9070a04 Add support for ARM v8.5A "rndr" instruction
It means there is another entropy source rndr added for arm64,
so modify the cpu model to max [1] to make the rndr entropy source
function available and also used to silence the below failed message
when start rngd service on qemuarm64.
"[rndr ]: Initialization Failed"
Before the patch:
$ systemctl status rngd
[snip]
Jul 05 07:15:47 qemuarm64 systemd[1]: Started Hardware RNG Entropy Gatherer
Daemon.
Jul 05 07:15:48 qemuarm64 rngd[152]: Initializing available sources
Jul 05 07:15:48 qemuarm64 rngd[152]: [hwrng ]: Initialized
Jul 05 07:15:48 qemuarm64 rngd[152]: [rndr ]: No HW SUPPORT
Jul 05 07:15:48 qemuarm64 rngd[152]: [rndr ]: Initialization Failed
Jul 05 07:15:48 qemuarm64 rngd[152]: [jitter]: Initializing AES buffer
Jul 05 07:16:14 qemuarm64 rngd[152]: [jitter]: Enabling JITTER rng support
Jul 05 07:16:14 qemuarm64 rngd[152]: [jitter]: Initialized
After the patch:
$ systemctl status rngd
[snip]
Jul 07 08:48:30 qemuarm64 systemd[1]: Started Hardware RNG Entropy Gatherer
Daemon.
Jul 07 08:48:34 qemuarm64 rngd[164]: Initializing available sources
Jul 07 08:48:34 qemuarm64 rngd[164]: [hwrng ]: Initialized
Jul 07 08:48:34 qemuarm64 rngd[164]: [rndr ]: Enabling aarch64 RNDR rng
support
Jul 07 08:48:34 qemuarm64 rngd[164]: [rndr ]: Initialized
Jul 07 08:48:35 qemuarm64 rngd[164]: [jitter]: Initializing AES buffer
[1] https://github.com/nhorman/rng-tools/pull/128
Signed-off-by: Mingli Yu
---
meta/conf/machine/qemuarm64.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 150a0744eb..a792dc32e6 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -15,7 +15,7 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
# For runqemu
QB_SYSTEM_NAME = "qemu-system-aarch64"
QB_MACHINE = "-machine virt"
-QB_CPU = "-cpu cortex-a57"
+QB_CPU = "-cpu max"
QB_SMP = "-smp 4"
QB_CPU_KVM = "-cpu host -machine gic-version=3"
# For graphics to work we need to define the VGA device as well as the
necessary USB devices
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153632):
https://lists.openembedded.org/g/openembedded-core/message/153632
Mute This Topic: https://lists.openembedded.org/mt/84040384/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
