I suggest you use =+ instead of _prepend to maintain expansion order. I.e., if
someone does:
inherit pypi
SRC_URI = "http://some_url ${PYPI_SRC_URI}"
However, any way you change it, you risk breaking someone’s use case, but I
believe using =+ instead of += should be the least invasive change
The Linux team plan to removed references to racially-charged jargon from
their code for more neutral and inclusive language.
So replace use of "whitelist" with "allowlist" in cve-check.
First, we add CVE_CHECK_ALLOWLIST and it is considered patched as well as
CVE_CHECK_WHITELIST.
We plan to
That doesn't look completely right to me.
You're absolutely right about devtool expecting the tarball in as the 1st item,
but this patch here breaks existing recipes like
SRC_URI += "file://some.patch"
inherit pypi
as the patch will now be dropped.
I would suggest to go for SRC_URI_prepend =
This did not cause problems in builds, but broke some devtool
workflows such as version upgrades or checking the latest version
from upstream. Tarballs should come first, not the patches.
Signed-off-by: Alexander Kanavin
---
meta/classes/pypi.bbclass | 2 +-
1 file changed, 1 insertion(+), 1
Right, I sent an updated patch.
Alex
On Wed, 23 Jun 2021 at 09:01, Konrad Weihmann wrote:
> That doesn't look completely right to me.
>
> You're absolutely right about devtool expecting the tarball in as the 1st
> item, but this patch here breaks existing recipes like
>
> SRC_URI +=
> -Original Message-
> From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Andrea Adami
> Sent: den 23 juni 2021 00:18
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree
> only if
Signed-off-by: Wang Mingyu
---
.../libva/{libva-initial_2.11.0.bb => libva-initial_2.12.0.bb} | 0
.../libva/{libva-utils_2.11.1.bb => libva-utils_2.12.0.bb} | 0
meta/recipes-graphics/libva/libva.inc | 2 +-
.../recipes-graphics/libva/{libva_2.11.0.bb =>
Signed-off-by: Wang Mingyu
---
.../{libxcrypt-compat_4.4.22.bb => libxcrypt-compat_4.4.23.bb} | 0
meta/recipes-core/libxcrypt/libxcrypt.inc | 2 +-
.../libxcrypt/{libxcrypt_4.4.22.bb => libxcrypt_4.4.23.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename
refresh 0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
License-Updage: Copyright year updated to 2021
Signed-off-by: Wang Mingyu
---
...-and-so-on-for-libraries-by-default-.patch | 19 +--
...umpy_1.20.3.bb => python3-numpy_1.21.0.bb} | 4 ++--
2 files
Hello Andrea,
On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami wrote:
>
> On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
> wrote:
> >
> > > -Original Message-
> > > From: openembedded-core@lists.openembedded.org > > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > > Sent:
On Wed, Jun 23, 2021 at 3:51 PM Andrey Zhizhikin wrote:
>
> Hello Andrea,
>
> On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami wrote:
> >
> > On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
> > wrote:
> > >
> > > > -Original Message-
> > > > From:
On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > Sent: den 23 juni 2021 00:18
> > To: openembedded-core@lists.openembedded.org
> > Subject:
long story short -- was having trouble figuring out why basic
settings i was adding to my build directory's conf/local.conf were
being ignored, and traced it back to the internal layer i was using
having its own "local.conf" file (in its conf directory, sitting
quietly next to the layer's
Hello, I would like to add a link to a yocto mail where I expose my
problematic that led to this patch series:
https://lists.yoctoproject.org/g/yocto/topic/83622035?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,83622035
After further research, I think these patch can be simplified by modified
Simple question: How can I make an external kernel module depend on its
firmware?
Suppose I have a recipe "kernel-module-something.bb"
Now this module needs firmware to work so the recipe basically contains
this:
inherit module
SRC_URI = "..."
RRECOMMENDS_${PN} += "something-firmware"
Frankly guys, I think maybe we should just break stuff in this case, and
have it fixed up properly, then try to guess what workaround might work.
>From that perspective the original patch is the most clear.
Alex
On Wed, 23 Jun 2021 at 11:26, Peter Kjellerstedt <
peter.kjellerst...@axis.com>
Signed-off-by: Frederic Martinsons
---
meta/classes/package.bbclass | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cf30f33f3d..38e9065f25 100644
--- a/meta/classes/package.bbclass
+++
When using external source manager (devtool), the debug symbol generated
by the compilation doesn't point to the right directory.
This is normally handled by gcc options that are defined
in DEBUG_PREFIX_MAP in conf/bitbake.conf.
But the path in it are hardcoded and point to WORKDIR which is
not
On 6/23/21 3:48 AM, Robert P. J. Day wrote:
long story short -- was having trouble figuring out why basic
settings i was adding to my build directory's conf/local.conf were
being ignored, and traced it back to the internal layer i was using
having its own "local.conf" file (in its conf
On Wed, Jun 23, 2021 at 05:22:21PM +0200, Andrea Adami wrote:
> On Wed, Jun 23, 2021 at 3:51 PM Andrey Zhizhikin wrote:
> >
> > Hello Andrea,
> >
> > On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami wrote:
> > >
> > > On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
> > > wrote:
> > > >
> > > >
This allows users running their own mirrors to store uninative tarballs
under versioned paths just like the default UNINATIVE_URL without having
to completely override UNINATIVE_URL in their distro configuration and
manually update the versioned URL on each upgrade.
The hashed subpath is left for
Thank you, I'll send v2.
I am waiting RP comments about the other patch of the series for
kernel.bbclass which exposed this one issue.
Martin, I tried to remove the patch from patchwork but all stops end 2020.
Am I missing something? New links?
Thanks all
A.A.
On Wed, Jun 23, 2021 at 6:02 PM
On Tue, 2021-06-22 at 17:50 -0400, Scott Weaver wrote:
> I didn't see that this patch was picked up (but maybe I'm looking in the
> wrong place) and I received the email
> from Stephen that the issue should be moved to 3.4 M2.
> Did I send this to the wrong mailing list or is it not the solution
Thanks, Richard.
The issue noted that the distro specific update wasn't working but it's
because they tried SRC_URI_append_poky (which correctly failed) so I didn't
even think to try anything else.
My mistake. I'll make the changes you suggested.
Thanks again for your time!
Scott
On Wed, Jun
On 6/21/21 4:48 PM, Richard Purdie wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Fri, 2021-06-18 at 10:30 +0800, Yu, Mingli wrote:
From: Mingli Yu
After the commit(60dcb230f6 perl: split perl-cross into its own recipe)
introduced, the source files mainly come from
25 matches
Mail list logo
