Re: [linux-yocto][yocto-kernel-cache][master yocto-5.4][PATCH] arm64/perf: fix backtrace for AAPCS with FP enabled

On Tue, May 5, 2020 at 10:43 PM Xu, Yanfei wrote: > > No, you didn't miss any things. I just know that the patches are > generated from your scripts. And I will resend the patch against > linux-yocto. > ok! Thanks for the follow up. It is ok to send things this way if required .. I just was

Re: [linux-yocto] v5.2.x - stable updates comprising v5.2.39

On Mon, May 4, 2020 at 7:19 PM Paul Gortmaker wrote: > > Bruce, Yocto kernel folks: > > Here is the next 5.2.x stable update "extension" primarily created for > the Yocto project, as the next v5.2.x post-EOL release. > > The content is from an audit of what went into the v5.4.19 to v5.4.21 >

Re: [linux-yocto][yocto-kernel-cache][master yocto-5.4][PATCH] arm64/perf: fix backtrace for AAPCS with FP enabled

No, you didn't miss any things. I just know that the patches are generated from your scripts. And I will resend the patch against linux-yocto. Yanfei On 5/2/20 11:19 PM, Bruce Ashfield wrote: Did I miss applying this to the kernel-cache previously ? or did I miss a patch against the

Re: [linux-yocto] [PATCH] rt: merge fixup for v5.4.37 and printk issues

In message: [PATCH] rt: merge fixup for v5.4.37 and printk issues on 05/05/2020 Paul Gortmaker wrote: > In v5.4.37, upstream ab6f762f0f5 ("printk: queue wake_up_klogd > irq_work only if per-CPU areas are ready") was backported. > > However, in preempt-rt content we have: > >

[yocto][yocto-autobuilder2][PATCH] README-Guide: fix typos, add hashserv setup

Added some instructions on setting up the hash equivalency server for an autobuilder instance that operates independently of the Yocto one. This all still assumes that the user is planning on running the controller, worker, and janitor on the same build host, although the hash equivalency server

[linux-yocto] [PATCH] rt: merge fixup for v5.4.37 and printk issues

In v5.4.37, upstream ab6f762f0f5 ("printk: queue wake_up_klogd irq_work only if per-CPU areas are ready") was backported. However, in preempt-rt content we have: 0011-printk_safe-remove-printk-safe-code.patch 0025-printk-remove-unused-code.patch The v5.6-rt already has a backport of

Re: [yocto] Regarding gnutls package in meta-gplv2 layer

Hi Prashanth, On Tue, May 05, 2020 at 08:22:07PM +0530, Prashanth wrote: > Hi Team, > I am trying to avoid GPLv3 package of gnutls from default Thud release. > > So I was checking the gnutls package from meta-gplv2 layer: >

[yocto] Regarding gnutls package in meta-gplv2 layer

Hi Team, I am trying to avoid GPLv3 package of gnutls from default Thud release. So I was checking the gnutls package from meta-gplv2 layer: http://git.yoctoproject.org/cgit/cgit.cgi/meta-gplv2/tree/recipes-support/gnutls/gnutls.inc?h=thud But here as well I see that, this package is with GPLv3

[yocto] Yocto Project Status WW18'20

Current Dev Position: YP 3.2 M1 Next Deadline: YP 3.2 M1 build date 2020/6/16 Next Team Meetings: * Bug Triage meeting Thursday May 7th at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday May 5th at 8am PDT (

Re: [yocto] Building cython based module with numpy dependency in SDK

Ok, so I think I found the solution to my problem. In distutils3.bbclass, last line, LDSHARED is set to "${CCLD} -shared". That environment variable is not set after sourcing the env-setup script from my SDK. My workaround is to check for some environment vars that is set and manually set it in

Re: [yocto] oddities(?) when appending to an override

On Tue, 5 May 2020, Richard Purdie wrote: > On Mon, 2020-05-04 at 16:28 -0400, Robert P. J. Day wrote: > > i bring this up because i've run across occasional examples of that > > in the code base -- here's > > meta-gnome/recipes-connectivity/libnma/libnma_1.8.28.bb: > > > >

Re: [yocto] oddities(?) when appending to an override

On Mon, 2020-05-04 at 16:28 -0400, Robert P. J. Day wrote: > i bring this up because i've run across occasional examples of that > in the code base -- here's > meta-gnome/recipes-connectivity/libnma/libnma_1.8.28.bb: > > EXTRA_OEMESON_mipsarchn32_append = " -Dvapi=false" > > is that

Re: [yocto] [meta-gplv2] [PATCH 3/3] README: Document how to configure repo for sending patches

On Tue, 2020-05-05 at 12:01 +0100, Richard Purdie via lists.yoctoproject.org wrote: > Signed-off-by: Richard Purdie > --- > README | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/README b/README > index 4558a99..6a61331 100644 > --- a/README > +++ b/README > @@ -27,3 +27,8 @@

[yocto] [meta-gplv2] [PATCH 3/3] README: Document how to configure repo for sending patches

Signed-off-by: Richard Purdie --- README | 5 + 1 file changed, 5 insertions(+) diff --git a/README b/README index 4558a99..6a61331 100644 --- a/README +++ b/README @@ -27,3 +27,8 @@ intended target branch of the Git repository. Git repository:

[yocto] [meta-gplv2] [PATCH 2/3] disable-gplv3.inc: Disable glib-2.0 ptest python3-dbusmock dependency

The newly added dependency on python3-dbusmock in OE-Core is GPLv3 and would fail to work with this layer. Remove it in the config for enabling the layer. Signed-off-by: Richard Purdie --- conf/distro/include/disable-gplv3.inc | 1 + 1 file changed, 1 insertion(+) diff --git

[yocto] [PATCH 1/2] conf/distro: Add disable-gplv3.inc

We're finding this layer needs configuration to work as intended. Rather than teaching this to things like the project autobuilder, collect the configuration inside an include file in the layer itself which everyone can either use directly or refer to. Initial population from the autobuilder

[yocto] [PATCH 2/2] disable-gplv3.inc: Disable glib-2.0 ptest python3-dbusmock dependency

The newly added dependency on python3-dbusmock in OE-Core is GPLv3 and would fail to work with this layer. Remove it in the config for enabling the layer. Signed-off-by: Richard Purdie --- conf/distro/include/disable-gplv3.inc | 1 + 1 file changed, 1 insertion(+) diff --git