[OE-core] [dunfell][PATCH] inetutils: fix CVE-2021-40491
The ftp client in GNU Inetutils before 2.2 does not validate addresses
returned by PASV/LSPV responses to make sure they match the server
address. This is similar to CVE-2020-8284 for curl.
References:
https://nvd.nist.gov/vuln/detail/CVE-2021-40491
Patch from:
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=58cb043b190fd04effdaea7c9403416b436e50dd
Signed-off-by: Minjae Kim
---
.../inetutils/inetutils/CVE-2021-40491.patch | 67 +++
.../inetutils/inetutils_1.9.4.bb | 1 +
2 files changed, 68 insertions(+)
create mode 100644
meta/recipes-connectivity/inetutils/inetutils/CVE-2021-40491.patch
diff --git a/meta/recipes-connectivity/inetutils/inetutils/CVE-2021-40491.patch
b/meta/recipes-connectivity/inetutils/inetutils/CVE-2021-40491.patch
new file mode 100644
index 00..54252d6bc7
--- /dev/null
+++ b/meta/recipes-connectivity/inetutils/inetutils/CVE-2021-40491.patch
@@ -0,0 +1,67 @@
+From 4e355804d57d5686defc363c70f81e6f58cd08f0 Mon Sep 17 00:00:00 2001
+From: Simon Josefsson
+Date: Fri, 17 Dec 2021 21:52:18 -0800
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* NEWS: Mention change.
+* ftp/ftp.c (initconn): Validate returned addresses.
+
+CVE: CVE-2021-40491
+
+Upstream-Status: Backport
+[https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=58cb043b190fd04effdaea7c9403416b436e50dd]
+
+Signed-off-by: Minjae Kim
+---
+ ftp/ftp.c | 21 +
+ 1 file changed, 21 insertions(+)
+
+diff --git a/ftp/ftp.c b/ftp/ftp.c
+index 9813586..7c72cb2 100644
+--- a/ftp/ftp.c
b/ftp/ftp.c
+@@ -1344,6 +1344,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) |
h[3]);
+ }
++ if (data_addr_sa4->sin_addr.s_addr
++ != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++ printf ("Passive mode address mismatch.\n");
++ (void) command ("ABOR");/* Cancel any open connection.
*/
++ goto bad;
++}
+ } /* LPSV IPv4 */
+ else /* IPv6 */
+ {
+@@ -1374,6 +1381,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8)
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] <<
8) | h[15]);
+ }
++ if (data_addr_sa6->sin6_addr.s6_addr
++ != ((struct sockaddr_in6 *) )->sin6_addr.s6_addr)
++{
++ printf ("Passive mode address mismatch.\n");
++ (void) command ("ABOR");/* Cancel any open connection.
*/
++ goto bad;
++}
+ } /* LPSV IPv6 */
+ }
+ else /* !EPSV && !LPSV */
+@@ -1394,6 +1408,13 @@ initconn (void)
+| ((a2 & 0xff) << 8) | (a3 & 0xff) );
+ data_addr_sa4->sin_port =
+ htons (((p0 & 0xff) << 8) | (p1 & 0xff));
++if (data_addr_sa4->sin_addr.s_addr
++!= ((struct sockaddr_in *) )->sin_addr.s_addr)
++ {
++printf ("Passive mode address mismatch.\n");
++(void) command ("ABOR"); /* Cancel any open connection.
*/
++goto bad;
++ }
+ } /* PASV */
+ else
+ {
+--
+2.25.1
+
diff --git a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
index cc9410b94e..f4450e19f4 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
@@ -23,6 +23,7 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.gz \
file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \
file://0001-rcp-fix-to-work-with-large-files.patch \
file://fix-buffer-fortify-tfpt.patch \
+ file://CVE-2021-40491.patch \
"
SRC_URI[md5sum] = "04852c26c47cc8c6b825f2b74f191f52"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159841):
https://lists.openembedded.org/g/openembedded-core/message/159841
Mute This Topic: https://lists.openembedded.org/mt/87813621/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][PATCH v2] vim: fix CVE-2021-4069
Use After Free in vim/vim
Upstream-Status: Backport
[https://github.com/vim/vim/commit/e031fe90cf2e375ce861ff5e5e281e4ad229ebb9]
CVE: CVE-2021-4069
---
.../vim/files/CVE-2021-4069.patch | 43 +++
meta/recipes-support/vim/vim.inc | 1 +
2 files changed, 44 insertions(+)
create mode 100644 meta/recipes-support/vim/files/CVE-2021-4069.patch
diff --git a/meta/recipes-support/vim/files/CVE-2021-4069.patch
b/meta/recipes-support/vim/files/CVE-2021-4069.patch
new file mode 100644
index 00..6a67281907
--- /dev/null
+++ b/meta/recipes-support/vim/files/CVE-2021-4069.patch
@@ -0,0 +1,43 @@
+From cd2422ee2dab3f33b2dbd1271e17cdaf8762b6d1 Mon Sep 17 00:00:00 2001
+From: Minjae Kim
+Date: Fri, 17 Dec 2021 20:32:02 -0800
+Subject: [PATCH] using freed memory in open command
+
+Problem:Using freed memory in open command.
+Solution: Make a copy of the current line.
+
+Upstream-Status: Backported
[https://github.com/vim/vim/commit/e031fe90cf2e375ce861ff5e5e281e4ad229ebb9]
+CVE: CVE-2021-4069
+Signed-off-by: Minjae Kim
+---
+ src/ex_docmd.c | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/src/ex_docmd.c b/src/ex_docmd.c
+index 59e245bee..ccd9e8bed 100644
+--- a/src/ex_docmd.c
b/src/ex_docmd.c
+@@ -6029,13 +6029,17 @@ ex_open(exarg_T *eap)
+ regmatch.regprog = vim_regcomp(eap->arg, p_magic ? RE_MAGIC : 0);
+ if (regmatch.regprog != NULL)
+ {
++// make a copy of the line, when searching for a mark it might be
++ // flushed
++ char_u *line = vim_strsave(ml_get_curline());
++
+ regmatch.rm_ic = p_ic;
+- p = ml_get_curline();
+- if (vim_regexec(, p, (colnr_T)0))
+- curwin->w_cursor.col = (colnr_T)(regmatch.startp[0] - p);
++ if (vim_regexec(, line, (colnr_T)0))
++ curwin->w_cursor.col = (colnr_T)(regmatch.startp[0] - line);
+ else
+ emsg(_(e_nomatch));
+ vim_regfree(regmatch.regprog);
++ vim_free(line);
+ }
+ // Move to the NUL, ignore any other arguments.
+ eap->arg += STRLEN(eap->arg);
+--
+2.25.1
+
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 11fed67527..51a6861325 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -26,6 +26,7 @@ SRC_URI =
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://0001-patch-8.2.3581-reading-character-past-end-of-line.patch
\
file://0002-patch-8.2.3582-reading-uninitialized-memory-when-giv.patch \
file://0002-patch-8.2.3611-crash-when-using-CTRL-W-f-without-fin.patch \
+ file://CVE-2021-4069.patch \
"
SRCREV = "98056533b96b6b5d8849641de93185dd7bcadc44"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159840):
https://lists.openembedded.org/g/openembedded-core/message/159840
Mute This Topic: https://lists.openembedded.org/mt/87813043/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][PATCH] git: fix CVE-2021-4069
Use After Free in vim/vim
Upstream-Status: Backport
[https://github.com/vim/vim/commit/e031fe90cf2e375ce861ff5e5e281e4ad229ebb9]
CVE: CVE-2021-4069
---
.../vim/files/CVE-2021-4069.patch | 43 +++
meta/recipes-support/vim/vim.inc | 1 +
2 files changed, 44 insertions(+)
create mode 100644 meta/recipes-support/vim/files/CVE-2021-4069.patch
diff --git a/meta/recipes-support/vim/files/CVE-2021-4069.patch
b/meta/recipes-support/vim/files/CVE-2021-4069.patch
new file mode 100644
index 00..6a67281907
--- /dev/null
+++ b/meta/recipes-support/vim/files/CVE-2021-4069.patch
@@ -0,0 +1,43 @@
+From cd2422ee2dab3f33b2dbd1271e17cdaf8762b6d1 Mon Sep 17 00:00:00 2001
+From: Minjae Kim
+Date: Fri, 17 Dec 2021 20:32:02 -0800
+Subject: [PATCH] using freed memory in open command
+
+Problem:Using freed memory in open command.
+Solution: Make a copy of the current line.
+
+Upstream-Status: Backported
[https://github.com/vim/vim/commit/e031fe90cf2e375ce861ff5e5e281e4ad229ebb9]
+CVE: CVE-2021-4069
+Signed-off-by: Minjae Kim
+---
+ src/ex_docmd.c | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/src/ex_docmd.c b/src/ex_docmd.c
+index 59e245bee..ccd9e8bed 100644
+--- a/src/ex_docmd.c
b/src/ex_docmd.c
+@@ -6029,13 +6029,17 @@ ex_open(exarg_T *eap)
+ regmatch.regprog = vim_regcomp(eap->arg, p_magic ? RE_MAGIC : 0);
+ if (regmatch.regprog != NULL)
+ {
++// make a copy of the line, when searching for a mark it might be
++ // flushed
++ char_u *line = vim_strsave(ml_get_curline());
++
+ regmatch.rm_ic = p_ic;
+- p = ml_get_curline();
+- if (vim_regexec(, p, (colnr_T)0))
+- curwin->w_cursor.col = (colnr_T)(regmatch.startp[0] - p);
++ if (vim_regexec(, line, (colnr_T)0))
++ curwin->w_cursor.col = (colnr_T)(regmatch.startp[0] - line);
+ else
+ emsg(_(e_nomatch));
+ vim_regfree(regmatch.regprog);
++ vim_free(line);
+ }
+ // Move to the NUL, ignore any other arguments.
+ eap->arg += STRLEN(eap->arg);
+--
+2.25.1
+
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 11fed67527..51a6861325 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -26,6 +26,7 @@ SRC_URI =
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://0001-patch-8.2.3581-reading-character-past-end-of-line.patch
\
file://0002-patch-8.2.3582-reading-uninitialized-memory-when-giv.patch \
file://0002-patch-8.2.3611-crash-when-using-CTRL-W-f-without-fin.patch \
+ file://CVE-2021-4069.patch \
"
SRCREV = "98056533b96b6b5d8849641de93185dd7bcadc44"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159839):
https://lists.openembedded.org/g/openembedded-core/message/159839
Mute This Topic: https://lists.openembedded.org/mt/87813029/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] [dunfell 16/42] libpcre/libpcre2: correct SRC_URI
I’d suggest we host the tarball somewhere on yoctoproject.org actually. Alex On Sat 18. Dec 2021 at 2.16, Steve Sakoman wrote: > On Fri, Dec 17, 2021 at 9:33 AM wrote: > > > > Dunfell uses 10.34 pcre2. This SRC_URI does not work with 10.34, as that > version is not available there. > > Urghh . . .you are correct. > > It does look like sourceforge is still carrying this (as do a few > other random mirrors): > > https://downloads.sourceforge.net/pcre/pcre2-10.34.tar.bz2 > > Any thoughts on which to use Alex? > > > > > Does Dunfell need to be updated to pcre2 > 10.36? > > No, I think we should stick with the current version since this is a > stable release. > > Steve > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159838): https://lists.openembedded.org/g/openembedded-core/message/159838 Mute This Topic: https://lists.openembedded.org/mt/87365168/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] [dunfell 16/42] libpcre/libpcre2: correct SRC_URI
On Fri, Dec 17, 2021 at 9:33 AM wrote: > > Dunfell uses 10.34 pcre2. This SRC_URI does not work with 10.34, as that > version is not available there. Urghh . . .you are correct. It does look like sourceforge is still carrying this (as do a few other random mirrors): https://downloads.sourceforge.net/pcre/pcre2-10.34.tar.bz2 Any thoughts on which to use Alex? > > Does Dunfell need to be updated to pcre2 > 10.36? No, I think we should stick with the current version since this is a stable release. Steve > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159837): https://lists.openembedded.org/g/openembedded-core/message/159837 Mute This Topic: https://lists.openembedded.org/mt/87365168/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] [dunfell 16/42] libpcre/libpcre2: correct SRC_URI
Dunfell uses 10.34 pcre2. This SRC_URI does not work with 10.34, as that version is not available there. Does Dunfell need to be updated to pcre2 > 10.36? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159836): https://lists.openembedded.org/g/openembedded-core/message/159836 Mute This Topic: https://lists.openembedded.org/mt/87365168/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] [meta][dunfell][PATCH] boost: Add a NULL check for the pointer which causes a crash
On Fri, Dec 17, 2021 at 6:47 AM Steve Sakoman wrote: > > On Fri, Dec 17, 2021 at 1:37 AM Ranjitsinh Rathod > wrote: > > > > From: Ranjitsinh Rathod > > > > Issues seen in boost asio call when used within shared libraries > > particularly in aarch64. > > The discussion with boost maintainers is on going at > > github.com/chriskohlhoff/asio/issues/588 originally reported at > > github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent > > with no solution in sight at present. > > As a workaround this simple patch that checks the nullness of the > > call stack seems to avoid the crash. > > Not sure I feel good about "seems to" ! > > Especially when the comments in the linked pull request include: > > "Please don't merge this just yet. While I no longer get SIGSEGVs with > this patch, my event loop (io.run()) now just quits. There is a deeper > underlying issue here." > > and > > "Closing. As noted elsewhere, this change is not correct. The > compensating_work_started function is only called from inside the > scheduler where we must have a valid, non-null call stack. That it's > null may indicate that something is seriously wrong with the way the > program is built. (A build issue with shared libraries perhaps?) > Suppressing it like this will instead introduce a subtle, > hard-to-debug work counting problem." > > So I'd like to see a little more discussion before we decide to take this > patch. Good call Steve, I also think its just hiding the issue a null return might result in other symptoms which might be entirely differrent. > > Steve > > > > > Typical Crash backtrace: > > Thread 1 (LWP 907): > > 0 boost::asio::detail::scheduler::compensating_work_started > > (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 > > 1 > > boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit > > (this=0x7f861ab348, __in_chrg=) > > at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 > > 2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io > > (events=, this=0x7f800023d0) at > > /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 > > 3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete > > (owner=0x559e174230, base=0x7f800023d0, ec=..., > > bytes_transferred=) > > at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 > > 4 0x007f894a4398 in boost::asio::detail::scheduler_operation::complete > > (bytes_transferred=17, ec=..., owner=0x559e174230, this=0x7f800023d0) > > at /usr/include/boost/asio/detail/scheduler_operation.hpp:40 > > 5 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., > > lock=..., this=0x559e174230) at > > /usr/include/boost/asio/detail/impl/scheduler.ipp:447 > > 6 boost::asio::detail::scheduler::run (this=0x559e174230, ec=...) at > > /usr/include/boost/asio/detail/impl/scheduler.ipp:200 > > 7 0x007f895e444c in boost::asio::io_context::run (this=0x559e174b70) > > at /usr/include/boost/asio/impl/io_context.ipp:63 > > > > Signed-off-by: Ranjitsinh Rathod > > Signed-off-by: Ranjitsinh Rathod > > --- > > ...L-check-for-the-pointer-which-causes.patch | 54 +++ > > meta/recipes-support/boost/boost_1.72.0.bb| 1 + > > 2 files changed, 55 insertions(+) > > create mode 100644 > > meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > > > > diff --git > > a/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > > > > b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > > new file mode 100644 > > index 00..5ffea59e29 > > --- /dev/null > > +++ > > b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > > @@ -0,0 +1,54 @@ > > +From d5efa47962b0101d9ec305b38a1520e9c13f118e Mon Sep 17 00:00:00 2001 > > +From: Ranjitsinh Rathod > > +Date: Mon, 31 May 2021 14:40:12 +0100 > > +Subject: [PATCH] boost: Add a NULL check for the pointer which causes a > > crash > > + > > +Issues seen in boost asio call when used within shared libraries > > +particularly in aarch64. > > +The discussion with boost maintainers is on going at > > +github.com/chriskohlhoff/asio/issues/588 originally reported at > > +github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent > > +with no solution in sight at present. > > +As a workaround this simple patch that checks the nullness of the > > +call stack seems to avoid the crash. > > + > > +Typical Crash backtrace: > > +Thread 1 (LWP 907): > > +0 boost::asio::detail::scheduler::compensating_work_started > > (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 > > +1 > > boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit > > (this=0x7f861ab348, __in_chrg=) > > +at
Re: [OE-core][PATCH 2/4] base.bbclass: add crate to OE_IMPORTS
Should this be named oe.crate for consistency and avoiding potential
clashes?
Alex
On Fri, 17 Dec 2021 at 18:37, Matt Madison wrote:
> to install the crate:// fetch handler.
>
> Signed-off-by: Matt Madison
> ---
> meta/classes/base.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index b709777f24..ee9950f207 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -12,7 +12,7 @@ inherit logging
>
> OE_EXTRA_IMPORTS ?= ""
>
> -OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package
> oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.qa
> oe.reproducible ${OE_EXTRA_IMPORTS}"
> +OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package
> oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.qa
> oe.reproducible crate ${OE_EXTRA_IMPORTS}"
> OE_IMPORTS[type] = "list"
>
> PACKAGECONFIG_CONFARGS ??= ""
> --
> 2.32.0
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159834):
https://lists.openembedded.org/g/openembedded-core/message/159834
Mute This Topic: https://lists.openembedded.org/mt/87791269/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] cargo fetcher, SRCPV, and setscene issues
On Thu, Dec 16, 2021 at 9:09 AM Matt Madison via
lists.openembedded.org
wrote:
>
> On Thu, Dec 16, 2021 at 7:53 AM Matt Madison via
> lists.openembedded.org
> wrote:
> >
> > On Thu, Dec 16, 2021 at 6:47 AM Joshua Watt wrote:
> > >
> > > On Wed, Dec 15, 2021 at 8:16 AM Matt Madison wrote:
> > > >
> > > > I'm finding that none of the Rust recipes are getting setscened in my
> > > > builds off
> > > > master due to the the SRCPV hack that was added to make the cargo
> > > > fetcher
> > > > visible during parsing. There's no error reported about it, but by
> > > > adding an
> > > > exception handler into the sstate code I tracked it down to
> > > > pstaging_fetch()'s
> > > > using d.getVar('SRCPV'). Since the cargo fetcher doesn't advertise
> > > > srcrev support,
> > > > the base fetcher class raises an exception on this, causing the
> > > > mostly-silent failure.
> > >
> > > Hmm, this is strange. I have this recipe:
> > > https://github.com/JPEWdev/meta-phosh/blob/master/recipes-graphics/squeekboard/squeekboard_git.bb
> > > that is using the cargo fetcher and it is definitely using sstate like
> > > I would expect; perhaps there is some other strange interaction with
> > > another class?
> >
> > I'm just talking about the rust toolchain, libstd-rs, cargo, etc.
> > It's simple enough for me to reproduce with a bare-bones setup:
> >
> > 1. clone openembedded-core and bitbake
> > 2. init build environment
> > 3. set MACHINE="qemuarm64" in local.conf
> > 4. bitbake librsvg
> > 5. Copy sstate-cache contents to a web server
> > 6. Wipe build workspace, re-init, and set SSTATE_MIRRORS to point to
> > the web server
> > 7. bitbake --setscene-only librsvg
> >
> > I've attached the cooker log of a sample build. You'll see from the
> > sstate summary that everything was found, but there will be warnings
> > when executing the setscenes.
>
> And if I apply the following patch:
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 0326d27c74..ffc3b08b7d 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -761,7 +761,12 @@ def pstaging_fetch(sstatefetch, d):
> localdata.setVar('FILESPATH', dldir)
> localdata.setVar('DL_DIR', dldir)
> localdata.setVar('PREMIRRORS', mirrors)
> -localdata.setVar('SRCPV', d.getVar('SRCPV'))
> +try:
> +curpv = d.getVar('SRCPV')
> +except Exception as e:
> +bb.warn("Failed to get SRCPV: %s" % e)
> +curpv = ''
> +localdata.setVar('SRCPV', curpv)
>
> the setscenes work, and the warning is:
>
> WARNING: libstd-rs-1.57.0-r0 do_packagedata_setscene: Failed to get
> SRCPV: Failure expanding variable SRCPV, expression was
> ${@crate_get_srcrev(d)} which triggered exception FetchError: Fetcher
> failure: SRCREV was used yet no valid SCM was found in SRC_URI
> The variable dependency chain for the failure is: SRCPV
>
> I'm just not sure whether that's the right place to fix this.
I think I've figured out a clean way to solve the problem, and have
sent patches for review.
-M
>
> -M
>
>
> >
> > -Matt
> >
> > >
> > > >
> > > > There's no issue if the sstate package is already in the local cache;
> > > > it only affects
> > > > builds where I need to fetch from my sstate mirror.
> > > >
> > > > I'd submit a patch, but I'm not sure what the right solution would be.
> > > >
> > > > Regards,
> > > > -Matt
> > > >
> > > >
> > > >
> >
> >
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159833):
https://lists.openembedded.org/g/openembedded-core/message/159833
Mute This Topic: https://lists.openembedded.org/mt/87744591/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 4/4] classes: remove crate-fetch.bbclass
No longer required now that the crate fetcher
gets installed via OE_IMPORTS.
Signed-off-by: Matt Madison
---
meta/classes/crate-fetch.bbclass | 28
1 file changed, 28 deletions(-)
delete mode 100644 meta/classes/crate-fetch.bbclass
diff --git a/meta/classes/crate-fetch.bbclass b/meta/classes/crate-fetch.bbclass
deleted file mode 100644
index a7fa22b2a0..00
--- a/meta/classes/crate-fetch.bbclass
+++ /dev/null
@@ -1,28 +0,0 @@
-#
-# crate-fetch class
-#
-# Registers 'crate' method for Bitbake fetch2.
-#
-# Adds support for following format in recipe SRC_URI:
-# crate:///
-#
-
-def import_crate(d):
-import crate
-if not getattr(crate, 'imported', False):
-bb.fetch2.methods.append(crate.Crate())
-crate.imported = True
-
-python crate_import_handler() {
-import_crate(d)
-}
-
-addhandler crate_import_handler
-crate_import_handler[eventmask] = "bb.event.RecipePreFinalise"
-
-def crate_get_srcrev(d):
-import_crate(d)
-return bb.fetch2.get_srcrev(d)
-
-# Override SRCPV to make sure it imports the fetcher first
-SRCPV = "${@crate_get_srcrev(d)}"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159832):
https://lists.openembedded.org/g/openembedded-core/message/159832
Mute This Topic: https://lists.openembedded.org/mt/87791272/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/4] base.bbclass: add crate to OE_IMPORTS
to install the crate:// fetch handler.
Signed-off-by: Matt Madison
---
meta/classes/base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index b709777f24..ee9950f207 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -12,7 +12,7 @@ inherit logging
OE_EXTRA_IMPORTS ?= ""
-OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.qa
oe.reproducible ${OE_EXTRA_IMPORTS}"
+OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license oe.qa
oe.reproducible crate ${OE_EXTRA_IMPORTS}"
OE_IMPORTS[type] = "list"
PACKAGECONFIG_CONFARGS ??= ""
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159830):
https://lists.openembedded.org/g/openembedded-core/message/159830
Mute This Topic: https://lists.openembedded.org/mt/87791269/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/4] cargo_common.bbclass: remove inherit of crate-fetch
No longer needed now that the crate fetcher is installed via OE_IMPORTS. Signed-off-by: Matt Madison --- meta/classes/cargo_common.bbclass | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/classes/cargo_common.bbclass b/meta/classes/cargo_common.bbclass index 23d82aa6ab..c403591434 100644 --- a/meta/classes/cargo_common.bbclass +++ b/meta/classes/cargo_common.bbclass @@ -8,8 +8,6 @@ ## is used by cargo.bbclass and Rust ## -# add crate fetch support -inherit crate-fetch inherit rust-common # Where we download our registry and dependencies to -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159831): https://lists.openembedded.org/g/openembedded-core/message/159831 Mute This Topic: https://lists.openembedded.org/mt/87791271/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 0/4] Move crate fetcher to OE_IMPORTS
This patch series switches to using the OE_IMPORTS mechanism for installing the crate fetcher. This simplifies the addition and clears up issues with interactions between SRCPV and the shared-state fetching logic. Matt Madison (4): lib/crate.py: install crate fetcher on import base.bbclass: add crate to OE_IMPORTS cargo_common.bbclass: remove inherit of crate-fetch classes: remove crate-fetch.bbclass meta/classes/base.bbclass | 2 +- meta/classes/cargo_common.bbclass | 2 -- meta/classes/crate-fetch.bbclass | 28 meta/lib/crate.py | 2 ++ 4 files changed, 3 insertions(+), 31 deletions(-) delete mode 100644 meta/classes/crate-fetch.bbclass -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159828): https://lists.openembedded.org/g/openembedded-core/message/159828 Mute This Topic: https://lists.openembedded.org/mt/87791267/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/4] lib/crate.py: install crate fetcher on import
to enable the move to using OE_IMPORTS for adding this fetcher. Signed-off-by: Matt Madison --- meta/lib/crate.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/lib/crate.py b/meta/lib/crate.py index d10f441875..f9db7c28cd 100644 --- a/meta/lib/crate.py +++ b/meta/lib/crate.py @@ -147,3 +147,5 @@ class Crate(Wget): mdpath = os.path.join(bbpath, cratepath, mdfile) with open(mdpath, "w") as f: json.dump(metadata, f) + +bb.fetch2.methods.append(Crate()) -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159829): https://lists.openembedded.org/g/openembedded-core/message/159829 Mute This Topic: https://lists.openembedded.org/mt/87791268/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] [meta][dunfell][PATCH] boost: Add a NULL check for the pointer which causes a crash
On Fri, Dec 17, 2021 at 1:37 AM Ranjitsinh Rathod wrote: > > From: Ranjitsinh Rathod > > Issues seen in boost asio call when used within shared libraries > particularly in aarch64. > The discussion with boost maintainers is on going at > github.com/chriskohlhoff/asio/issues/588 originally reported at > github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent > with no solution in sight at present. > As a workaround this simple patch that checks the nullness of the > call stack seems to avoid the crash. Not sure I feel good about "seems to" ! Especially when the comments in the linked pull request include: "Please don't merge this just yet. While I no longer get SIGSEGVs with this patch, my event loop (io.run()) now just quits. There is a deeper underlying issue here." and "Closing. As noted elsewhere, this change is not correct. The compensating_work_started function is only called from inside the scheduler where we must have a valid, non-null call stack. That it's null may indicate that something is seriously wrong with the way the program is built. (A build issue with shared libraries perhaps?) Suppressing it like this will instead introduce a subtle, hard-to-debug work counting problem." So I'd like to see a little more discussion before we decide to take this patch. Steve > > Typical Crash backtrace: > Thread 1 (LWP 907): > 0 boost::asio::detail::scheduler::compensating_work_started > (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 > 1 > boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit > (this=0x7f861ab348, __in_chrg=) > at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 > 2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io > (events=, this=0x7f800023d0) at > /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 > 3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete > (owner=0x559e174230, base=0x7f800023d0, ec=..., bytes_transferred= out>) > at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 > 4 0x007f894a4398 in boost::asio::detail::scheduler_operation::complete > (bytes_transferred=17, ec=..., owner=0x559e174230, this=0x7f800023d0) > at /usr/include/boost/asio/detail/scheduler_operation.hpp:40 > 5 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., > lock=..., this=0x559e174230) at > /usr/include/boost/asio/detail/impl/scheduler.ipp:447 > 6 boost::asio::detail::scheduler::run (this=0x559e174230, ec=...) at > /usr/include/boost/asio/detail/impl/scheduler.ipp:200 > 7 0x007f895e444c in boost::asio::io_context::run (this=0x559e174b70) at > /usr/include/boost/asio/impl/io_context.ipp:63 > > Signed-off-by: Ranjitsinh Rathod > Signed-off-by: Ranjitsinh Rathod > --- > ...L-check-for-the-pointer-which-causes.patch | 54 +++ > meta/recipes-support/boost/boost_1.72.0.bb| 1 + > 2 files changed, 55 insertions(+) > create mode 100644 > meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > > diff --git > a/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > > b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > new file mode 100644 > index 00..5ffea59e29 > --- /dev/null > +++ > b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch > @@ -0,0 +1,54 @@ > +From d5efa47962b0101d9ec305b38a1520e9c13f118e Mon Sep 17 00:00:00 2001 > +From: Ranjitsinh Rathod > +Date: Mon, 31 May 2021 14:40:12 +0100 > +Subject: [PATCH] boost: Add a NULL check for the pointer which causes a crash > + > +Issues seen in boost asio call when used within shared libraries > +particularly in aarch64. > +The discussion with boost maintainers is on going at > +github.com/chriskohlhoff/asio/issues/588 originally reported at > +github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent > +with no solution in sight at present. > +As a workaround this simple patch that checks the nullness of the > +call stack seems to avoid the crash. > + > +Typical Crash backtrace: > +Thread 1 (LWP 907): > +0 boost::asio::detail::scheduler::compensating_work_started > (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 > +1 > boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit > (this=0x7f861ab348, __in_chrg=) > +at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 > +2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io > (events=, this=0x7f800023d0) at > +/usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 > +3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete > (owner=0x559e174230, base=0x7f800023d0, ec=..., bytes_transferred= out>) > +at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 > +4
[OE-core] [meta-oe][PATCH 2/2] libqmi: build with qrtr support
QRTR is a virtual bus for talking to Qualcomm based modems,
either integrated or PCIe.
Signed-off-by: Loic Poulain
---
meta-oe/recipes-connectivity/libqmi/libqmi_1.30.2.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.2.bb
b/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.2.bb
index c337abde3..1f1179865 100644
--- a/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.2.bb
+++ b/meta-oe/recipes-connectivity/libqmi/libqmi_1.30.2.bb
@@ -16,6 +16,7 @@ SRC_URI =
"http://www.freedesktop.org/software/${BPN}/${BPN}-${PV}.tar.xz;
SRC_URI[sha256sum] =
"be01ece0ea2c2194cbea5744bf5aaf06c04ba5fb7ec7887a13116c76d114fedd"
-PACKAGECONFIG ??= "udev mbim"
+PACKAGECONFIG ??= "udev mbim qrtr"
PACKAGECONFIG[udev] = ",--without-udev,libgudev"
+PACKAGECONFIG[qrtr] = "--enable-qrtr,--disable-qrtr,libqrtr-glib"
PACKAGECONFIG[mbim] = "--enable-mbim-qmux,--disable-mbim-qmux,libmbim"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159826):
https://lists.openembedded.org/g/openembedded-core/message/159826
Mute This Topic: https://lists.openembedded.org/mt/87788963/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH 1/2] libqrtr-glib: Initial recipe for libqrtr-glib 1.0.0
libqrtr-glib is a glib-based library to use and manage the
QRTR (Qualcomm IPC Router) bus. This bus is in turn a way
to reach remote services via QMI messages. It is especially
used by libqmi, for talking to integrated or PCIe Qualcomm
WWAN modems.
Signed-off-by: Loic Poulain
---
.../libqrtr-glib/libqrtr-glib_1.0.0.bb | 13 +
1 file changed, 13 insertions(+)
create mode 100644
meta-oe/recipes-connectivity/libqrtr-glib/libqrtr-glib_1.0.0.bb
diff --git a/meta-oe/recipes-connectivity/libqrtr-glib/libqrtr-glib_1.0.0.bb
b/meta-oe/recipes-connectivity/libqrtr-glib/libqrtr-glib_1.0.0.bb
new file mode 100644
index 0..29f0e2214
--- /dev/null
+++ b/meta-oe/recipes-connectivity/libqrtr-glib/libqrtr-glib_1.0.0.bb
@@ -0,0 +1,13 @@
+SUMMARY = "libqrtr-glib is a glib-based library to use and manage the QRTR
bus."
+HOMEPAGE = "https://gitlab.freedesktop.org/mobile-broadband/libqrtr-glib;
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = " \
+file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c \
+"
+DEPENDS = "glib-2.0 glib-2.0-native"
+
+inherit autotools pkgconfig bash-completion gobject-introspection
+
+SRC_URI = "http://www.freedesktop.org/software/libqmi/${BPN}-${PV}.tar.xz;
+
+SRC_URI[sha256sum] =
"30d879b2ade6f8f461def3a677755db5c0238babf688d5c83c03b3e6abe35cee"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159825):
https://lists.openembedded.org/g/openembedded-core/message/159825
Mute This Topic: https://lists.openembedded.org/mt/87788961/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)
Hello everyone, This is the full report for yocto-3.5_M1.rc2: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. one issue found Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure === Bugs https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622 Thanks, Jay >-Original Message- >From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Richard Purdie >Sent: Sunday, 12 December, 2021 6:49 PM >To: >Cc: qa-build-notification >Subject: [qa-build-notification] QA notification for completed autobuilder >build >(yocto-3.5_M1.rc2) > >A build flagged for QA (yocto-3.5_M1.rc2) was completed on the autobuilder and >is available at: > > >https://autobuilder.yocto.io/pub/releases/yocto-3.5_M1.rc2 > > >Build hash information: > >bitbake: 1ecc1d9424877df89fcda2f23c306998998a65ff >meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559 >meta-arm: d446f7f80bf61e9cf05843e8ef4bc5473f936118 >meta-aws: 8893e0cd4c0981eeda941eaa9ad2eb9359670502 >meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400 >meta-intel: aa8482af7b286f8fe8f7aae648938d4ebf0283c5 >meta-mingw: 992fb40bdbfe9fe60f815aac46e04c58963918b5 >meta-openembedded: ba6a16cdca661b2d5251df243dc19bda0e8db651 >oecore: 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b >poky: 65c94ca3196e5ef3344a469fea8e30444f2e967a > > > >This is an automated message from the Yocto Project Autobuilder >Git: git://git.yoctoproject.org/yocto-autobuilder2 >Email: richard.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159824): https://lists.openembedded.org/g/openembedded-core/message/159824 Mute This Topic: https://lists.openembedded.org/mt/87719482/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] rust: fix arm64 link failures when building rust apps
We're stuck on thud (vendor related), I ended up backporting these two
commits from upstream, to address this issue:
https://github.com/zuma-array/meta-rust/commit/5631d561f16d88acf9cd6a014dd292cf20668501
But I don't think the issue appears in master because of the newer gcc.
On Thu, Dec 16, 2021 at 11:04 PM S. Lockwood-Childs wrote:
>
> Patch withdrawn: turns out meta-tegra was pulling in an old toolchain
> for CUDA reasons, and that just got fixed. Probably there isn't another
> aarch64 platform still using a non-fixed toolchain, and if there happens
> to be one maybe they will run across this patch to carry it in their own
> layer.
>
> Note: apologies for not CC-ing Alexander Kanavin, but I couldn't figure
> out how to directly reply to his question from this list's web UI & I don't
> have a copy of his email in my inbox.
> https://lists.openembedded.org/g/openembedded-core/message/159775
>
> On Thu, Dec 16, 2021 at 01:19:45AM -0800, S. Lockwood-Childs wrote:
> > Typical error when trying to build a rust app (for example, librsvg)
> > for aarch64 targets looks like:
> > undefined references to `__aarch64_ldadd8_rel'
> >
> > The upstream rust commit
> > "add target feature outline-atomics"
> > 0f9f241aac21bc77fb9e757da18207abefdc841d
> > has caused a number of such link failure regressions on platforms with
> > aarch64
> > toolchains that are not able to cope with -moutline-atomics flag. This
> > includes
> > musl toolchains [1] but some glibc toolchains also are not able to handle
> > this
> > flag [2,3]
> >
> > OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able
> > to
> > handle outline-atomics this patch should go away, to take advantage of the
> > reported performance benefit.
> >
> > [1] https://github.com/rust-lang/git2-rs/issues/706
> > [2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
> >
> > Signed-off-by: S. Lockwood-Childs
> > ---
> > meta/recipes-devtools/rust/rust-target.inc| 2 +
> > .../rust/rust-disable-outline-atomics.patch | 50 +++
> > 2 files changed, 52 insertions(+)
> > create mode 100644
> > meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> >
> > diff --git a/meta/recipes-devtools/rust/rust-target.inc
> > b/meta/recipes-devtools/rust/rust-target.inc
> > index 3f637b3ba5..bac743f66d 100644
> > --- a/meta/recipes-devtools/rust/rust-target.inc
> > +++ b/meta/recipes-devtools/rust/rust-target.inc
> > @@ -2,6 +2,8 @@ require rust.inc
> >
> > DEPENDS += "rust-llvm (=${PV})"
> >
> > +SRC_URI += "file://rust-disable-outline-atomics.patch"
> > +
> > # Otherwise we'll depend on what we provide
> > INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
> > # We don't need to depend on gcc-native because yocto assumes it exists
> > diff --git
> > a/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> > b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> > new file mode 100644
> > index 00..fc99a06a6a
> > --- /dev/null
> > +++ b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> > @@ -0,0 +1,50 @@
> > +rust: fix arm64 link failures when building rust apps
> > +
> > +Typical error when trying to build a rust app looks like:
> > + undefined references to `__aarch64_ldadd8_rel'
> > +
> > +The upstream rust commit
> > +"add target feature outline-atomics"
> > 0f9f241aac21bc77fb9e757da18207abefdc841d
> > +has caused a number of such link failure regressions on platforms with
> > aarch64
> > +toolchains that are not able to cope with -moutline-atomics flag. This
> > includes
> > +musl toolchains [1] but some glibc toolchains also are not able to handle
> > this
> > +flag [2,3]
> > +
> > +OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able
> > to
> > +handle outline-atomics this patch should go away, to take advantage of the
> > +reported performance benefit.
> > +
> > +[1] https://github.com/rust-lang/git2-rs/issues/706
> > +[2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
> > +[3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
> > +
> > +Upstream-Status: Inappropriate [other]
> > +
> > +Signed-off-by: S. Lockwood-Childs
> > +
> > +diff --git a/compiler/rustc_codegen_llvm/src/llvm_util.rs
> > b/compiler/rustc_codegen_llvm/src/llvm_util.rs
> > +index c2136f161..ca221eb4a 100644
> > +--- a/compiler/rustc_codegen_llvm/src/llvm_util.rs
> > b/compiler/rustc_codegen_llvm/src/llvm_util.rs
> > +@@ -416,13 +416,14 @@ pub fn llvm_global_features(sess: ) ->
> > Vec {
> > + // -Ctarget-features
> > +
> > features.extend(sess.opts.cg.target_feature.split(',').flat_map());
> > +
> > +-// FIXME: Move outline-atomics to target definition when earliest
> > supported LLVM is 12.
> > +-if get_version() >= (12, 0, 0)
> > +-&& sess.target.llvm_target.contains("aarch64-unknown-linux")
> > +-&&
[OE-core] [meta][PATCH] boost: Add a NULL check for the pointer which causes a crash
From: Ranjitsinh Rathod Issues seen in boost asio call when used within shared libraries particularly in aarch64. The discussion with boost maintainers is on going at github.com/chriskohlhoff/asio/issues/588 originally reported at github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent with no solution in sight at present. As a workaround this simple patch that checks the nullness of the call stack seems to avoid the crash. Typical Crash backtrace: Thread 1 (LWP 907): 0 boost::asio::detail::scheduler::compensating_work_started (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 1 boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit (this=0x7f861ab348, __in_chrg=) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io (events=, this=0x7f800023d0) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete (owner=0x559e174230, base=0x7f800023d0, ec=..., bytes_transferred=) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 4 0x007f894a4398 in boost::asio::detail::scheduler_operation::complete (bytes_transferred=17, ec=..., owner=0x559e174230, this=0x7f800023d0) at /usr/include/boost/asio/detail/scheduler_operation.hpp:40 5 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., lock=..., this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:447 6 boost::asio::detail::scheduler::run (this=0x559e174230, ec=...) at /usr/include/boost/asio/detail/impl/scheduler.ipp:200 7 0x007f895e444c in boost::asio::io_context::run (this=0x559e174b70) at /usr/include/boost/asio/impl/io_context.ipp:63 Signed-off-by: Ranjitsinh Rathod Signed-off-by: Ranjitsinh Rathod --- ...L-check-for-the-pointer-which-causes.patch | 54 +++ meta/recipes-support/boost/boost_1.78.0.bb| 1 + 2 files changed, 55 insertions(+) create mode 100644 meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch diff --git a/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch new file mode 100644 index 00..273b6b5e6d --- /dev/null +++ b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch @@ -0,0 +1,54 @@ +From d5efa47962b0101d9ec305b38a1520e9c13f118e Mon Sep 17 00:00:00 2001 +From: Ranjitsinh Rathod +Date: Mon, 31 May 2021 14:40:12 +0100 +Subject: [PATCH] boost: Add a NULL check for the pointer which causes a crash + +Issues seen in boost asio call when used within shared libraries +particularly in aarch64. +The discussion with boost maintainers is on going at +github.com/chriskohlhoff/asio/issues/588 originally reported at +github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent +with no solution in sight at present. +As a workaround this simple patch that checks the nullness of the +call stack seems to avoid the crash. + +Typical Crash backtrace: +Thread 1 (LWP 907): +0 boost::asio::detail::scheduler::compensating_work_started (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 +1 boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit (this=0x7f861ab348, __in_chrg=) +at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 +2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io (events=, this=0x7f800023d0) at +/usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 +3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete (owner=0x559e174230, base=0x7f800023d0, ec=..., bytes_transferred=) +at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 +4 0x007f894a4398 in boost::asio::detail::scheduler_operation::complete (bytes_transferred=17, ec=..., owner=0x559e174230, this=0x7f800023d0) +at /usr/include/boost/asio/detail/scheduler_operation.hpp:40 +5 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., lock=..., this=0x559e174230) at +/usr/include/boost/asio/detail/impl/scheduler.ipp:447 +6 boost::asio::detail::scheduler::run (this=0x559e174230, ec=...) at /usr/include/boost/asio/detail/impl/scheduler.ipp:200 +7 0x007f895e444c in boost::asio::io_context::run (this=0x559e174b70) at /usr/include/boost/asio/impl/io_context.ipp:63 + +Upstream-Status: Submitted [https://github.com/chriskohlhoff/asio/pull/330] + +Signed-off-by: Mikko Rapeli +Signed-off-by: Ranjitsinh Rathod + +--- + boost/asio/detail/impl/scheduler.ipp | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/boost/asio/detail/impl/scheduler.ipp b/boost/asio/detail/impl/scheduler.ipp +index 089e36e8e..017c3d497 100644 +--- a/boost/asio/detail/impl/scheduler.ipp
[OE-core] [meta][dunfell][PATCH] boost: Add a NULL check for the pointer which causes a crash
From: Ranjitsinh Rathod Issues seen in boost asio call when used within shared libraries particularly in aarch64. The discussion with boost maintainers is on going at github.com/chriskohlhoff/asio/issues/588 originally reported at github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent with no solution in sight at present. As a workaround this simple patch that checks the nullness of the call stack seems to avoid the crash. Typical Crash backtrace: Thread 1 (LWP 907): 0 boost::asio::detail::scheduler::compensating_work_started (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 1 boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit (this=0x7f861ab348, __in_chrg=) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io (events=, this=0x7f800023d0) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete (owner=0x559e174230, base=0x7f800023d0, ec=..., bytes_transferred=) at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 4 0x007f894a4398 in boost::asio::detail::scheduler_operation::complete (bytes_transferred=17, ec=..., owner=0x559e174230, this=0x7f800023d0) at /usr/include/boost/asio/detail/scheduler_operation.hpp:40 5 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., lock=..., this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:447 6 boost::asio::detail::scheduler::run (this=0x559e174230, ec=...) at /usr/include/boost/asio/detail/impl/scheduler.ipp:200 7 0x007f895e444c in boost::asio::io_context::run (this=0x559e174b70) at /usr/include/boost/asio/impl/io_context.ipp:63 Signed-off-by: Ranjitsinh Rathod Signed-off-by: Ranjitsinh Rathod --- ...L-check-for-the-pointer-which-causes.patch | 54 +++ meta/recipes-support/boost/boost_1.72.0.bb| 1 + 2 files changed, 55 insertions(+) create mode 100644 meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch diff --git a/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch new file mode 100644 index 00..5ffea59e29 --- /dev/null +++ b/meta/recipes-support/boost/boost/0001-boost-Add-a-NULL-check-for-the-pointer-which-causes.patch @@ -0,0 +1,54 @@ +From d5efa47962b0101d9ec305b38a1520e9c13f118e Mon Sep 17 00:00:00 2001 +From: Ranjitsinh Rathod +Date: Mon, 31 May 2021 14:40:12 +0100 +Subject: [PATCH] boost: Add a NULL check for the pointer which causes a crash + +Issues seen in boost asio call when used within shared libraries +particularly in aarch64. +The discussion with boost maintainers is on going at +github.com/chriskohlhoff/asio/issues/588 originally reported at +github.com/chriskohlhoff/asio/issues/642. The crash is quite frequent +with no solution in sight at present. +As a workaround this simple patch that checks the nullness of the +call stack seems to avoid the crash. + +Typical Crash backtrace: +Thread 1 (LWP 907): +0 boost::asio::detail::scheduler::compensating_work_started (this=0x559e174230) at /usr/include/boost/asio/detail/impl/scheduler.ipp:321 +1 boost::asio::detail::epoll_reactor::perform_io_cleanup_on_block_exit::~perform_io_cleanup_on_block_exit (this=0x7f861ab348, __in_chrg=) +at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:712 +2 boost::asio::detail::epoll_reactor::descriptor_state::perform_io (events=, this=0x7f800023d0) at +/usr/include/boost/asio/detail/impl/epoll_reactor.ipp:730 +3 boost::asio::detail::epoll_reactor::descriptor_state::do_complete (owner=0x559e174230, base=0x7f800023d0, ec=..., bytes_transferred=) +at /usr/include/boost/asio/detail/impl/epoll_reactor.ipp:774 +4 0x007f894a4398 in boost::asio::detail::scheduler_operation::complete (bytes_transferred=17, ec=..., owner=0x559e174230, this=0x7f800023d0) +at /usr/include/boost/asio/detail/scheduler_operation.hpp:40 +5 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., lock=..., this=0x559e174230) at +/usr/include/boost/asio/detail/impl/scheduler.ipp:447 +6 boost::asio::detail::scheduler::run (this=0x559e174230, ec=...) at /usr/include/boost/asio/detail/impl/scheduler.ipp:200 +7 0x007f895e444c in boost::asio::io_context::run (this=0x559e174b70) at /usr/include/boost/asio/impl/io_context.ipp:63 + +Upstream-Status: Submitted [https://github.com/chriskohlhoff/asio/pull/330] + +Signed-off-by: Mikko Rapeli +Signed-off-by: Ranjitsinh Rathod + +--- + boost/asio/detail/impl/scheduler.ipp | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/boost/asio/detail/impl/scheduler.ipp b/boost/asio/detail/impl/scheduler.ipp +index 4ef5c8668..02fc0d2e5 100644 +--- a/boost/asio/detail/impl/scheduler.ipp
[OE-core] [PATCH 00/32] Add Inappropriate reasoining
Add reasoning to Inappropriate to all patches that are missing missing that entirely To all maintainers please double check my proposals The following changes since commit 31bc9cab25692fd0b07dbd994afd93802e93d6bf: bitbake: fetch: npm: Use temporary file for empty user config (2021-12-14 22:47:04 +) are available in the Git repository at: git://github.com/priv-kweihmann/poky inapp-add-min https://github.com/priv-kweihmann/poky/tree/inapp-add-min Konrad Weihmann (32): connman: fix patch Inappropriate glib: fix patch Inappropriate ldconfig: fix patch Inappropriate readline: fix patch Inappropriate util-linux: fix patch Inappropriate autoconf: fix patch Inappropriate automake: fix patch Inappropriate binutils: fix patch Inappropriate e2fsprogs: fix patch Inappropriate flex: fix patch Inappropriate gcc: fix patch Inappropriate gdb: fix patch Inappropriate libtool: fix patch Inappropriate rsync: fix patch Inappropriate strace: fix patch Inappropriate tcf-agent: fix patch Inappropriate valgrind: fix patch Inappropriate xmlto: fix patch Inappropriate bc: fix patch Inappropriate ethtool: fix patch Inappropriate gawk: fix patch Inappropriate textinfo: fix patch Inappropriate gobject-intro: fix patch Inappropriate gtk-doc: fix patch Inappropriate libxcb: fix patch Inappropriate pcmanfm: fix patch Inappropriate boost: fix patch Inappropriate ca-certifactes: fix patch Inappropriate gmp: fix patch Inappropriate libtasn1: fix patch Inappropriate libffi: fix patch Inappropriate serf: fix patch Inappropriate .../connman/connman/no-version-scripts.patch| 2 +- ...1-Remove-the-warning-about-deprecated-paths-in-schemas.patch | 2 +- meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch | 2 +- .../glibc/ldconfig-native-2.12.1/no-aux-cache.patch | 2 +- meta/recipes-core/readline/readline-8.1/norpath.patch | 2 +- .../util-linux/util-linux/avoid_parallel_tests.patch| 2 +- meta/recipes-devtools/autoconf/autoconf/man-host-perl.patch | 2 +- meta/recipes-devtools/autoconf/autoconf/no-man.patch| 2 +- meta/recipes-devtools/automake/automake/performance.patch | 2 +- ...2-binutils-cross-Do-not-generate-linker-script-directo.patch | 2 +- .../binutils/binutils/0015-sync-with-OE-libtool-changes.patch | 2 +- meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch | 2 +- meta/recipes-devtools/e2fsprogs/e2fsprogs/quiet-debugfs.patch | 2 +- meta/recipes-devtools/flex/flex/disable-tests.patch | 2 +- .../gcc/gcc/0024-handle-sysroot-support-for-nativesdk-gcc.patch | 2 +- meta/recipes-devtools/gdb/gdb/0007-Change-order-of-CFLAGS.patch | 2 +- .../libtool/libtool/dont-depend-on-help2man.patch | 2 +- meta/recipes-devtools/libtool/libtool/multilib.patch| 2 +- meta/recipes-devtools/libtool/libtool/nohardcodepaths.patch | 2 +- meta/recipes-devtools/rsync/files/makefile-no-rebuild.patch | 2 +- meta/recipes-devtools/strace/strace/Makefile-ptest.patch| 2 +- meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch | 2 +- .../valgrind-make-ld-XXX.so-strlen-intercept-optional.patch | 2 +- .../configure.in-drop-the-test-of-xmllint-and-xsltproc.patch| 2 +- meta/recipes-extended/bc/bc/no-gen-libmath.patch| 2 +- .../recipes-extended/ethtool/ethtool/avoid_parallel_tests.patch | 2 +- meta/recipes-extended/gawk/gawk/test-time.patch | 2 +- .../texinfo/texinfo/dont-depend-on-help2man.patch | 2 +- ...01-Relocate-the-repository-directory-for-native-builds.patch | 2 +- meta/recipes-gnome/gtk-doc/files/pkg-config-native.patch| 2 +- meta/recipes-graphics/xorg-lib/libxcb/disable-check.patch | 2 +- meta/recipes-sato/pcmanfm/files/no-desktop.patch| 2 +- ...1-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch | 2 +- ...1-update-ca-certificates-don-t-use-Debianisms-in-run-p.patch | 2 +- ...1-Append-the-user-provided-flags-to-the-auto-detected-.patch | 2 +- .../gnutls/libtasn1/dont-depend-on-help2man.patch | 2 +- meta/recipes-support/libffi/libffi/not-win32.patch | 2 +- meta/recipes-support/serf/serf/env.patch| 2 +- meta/recipes-support/serf/serf/norpath.patch| 2 +- 39 files changed, 39 insertions(+), 39 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159820): https://lists.openembedded.org/g/openembedded-core/message/159820 Mute This Topic: https://lists.openembedded.org/mt/87786835/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] What does OEBasic do?
Greetings, I'm trying to update the documentation in https://docs.yoctoproject.org/overview-manual/concepts.html#checksums-signatures. With OEEquivHash, meta/lib/oe/sstatesig.py now implements 3 signature handlers instead of 2. However, I find parts of this document difficult to understand. In particular, what's OEBasic supposed to do? I could clarify its description if I could understand it better. We just know that it doesn't store the task hash into the task stamp, but what else? Sorry, I looked at the code, but it is not explicit enough (at least for me) to find the answers by myself. By the way, this "Checksums (Signatures)" chapter looks like an exact duplicate of what is found in BitBake's manual (https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-execution.html). This is bad because future changes could introduce discrepancies between both copies and confuse readers. Shouldn't we have a summary in the Yocto docs instead and refer to BitBake's manual instead? Or the opposite, as OEBasic, OEBasicHash and OEEquivHash are implemented by OE-Core and are a nice illustration of what BitBake allows to do? Thanks in advance for your help and advice. Cheers Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159819): https://lists.openembedded.org/g/openembedded-core/message/159819 Mute This Topic: https://lists.openembedded.org/mt/87786709/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
