On Wed, 2021-09-01 at 09:44 +0100, Richard Purdie via lists.openembedded.org
wrote:
> Hi Esteban,
>
> On Fri, 2021-08-27 at 15:18 +, Kuber, Esteban wrote:
> > On 2021/8/27, 2:03 AM, "Richard Purdie"
> > wrote:
> > > and:
> > >
> > > 2. a reproducible build failure on CentOS-7:
>
colleague asked me yesterday about the fundamental difference
between using SRC_URI to point at a local source tree to build, versus
inheriting externalsrc, and when to use each.
from what i read, there's no serious difference as, by default, both
techniques copy the source tree under
Fixes [YOCTO #14538]
Recipes shouldn't use the "virtual/" string in RPROVIDES and RDEPENDS.
That's confusing because "virtual/" has no special meaning in
RPROVIDES and RDEPENDS (unlike in PROVIDES and DEPENDS).
Instead, using "virtual-" instead of "virtual/"
as already done in the glibc recipe.
Please merge these changes.
Thanks,
Anuj
The following changes since commit 9ba6c42c1cc0ffb690126aa93ccb529405473af5:
glibc: Fix CVE-2021-38604 (2021-08-25 10:44:50 +0800)
are available in the Git repository at:
git://push.openembedded.org/openembedded-core-contrib stable/hardknott-next
Hi Paul,
On Mon, 2021-08-30 at 09:33 +0100, Paul Barker wrote:
> Hi Anuj,
>
> Please could you consider backporting the following commit to
> hardknott:
>
> af2a9c92d449 ("kernel-yocto: Simplify no git repo case in
> do_kernel_checkout")
>
> This has already been backport to dunfell. The
On Fri, 2021-08-27 at 13:04 +0100, Richard Purdie via lists.openembedded.org
wrote:
> On Fri, 2021-08-27 at 10:03 +0100, Richard Purdie via lists.openembedded.org
> wrote:
> > On Fri, 2021-08-27 at 00:05 -0400, Randy MacLeod wrote:
> > > 2. a reproducible build failure on CentOS-7:
> > >
> > >
Hi Esteban,
On Fri, 2021-08-27 at 15:18 +, Kuber, Esteban wrote:
> On 2021/8/27, 2:03 AM, "Richard Purdie"
> wrote:
> > and:
> >
> > 2. a reproducible build failure on CentOS-7:
> >
> >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/115/builds/597
> >
systemd-repart[1] is useful for partitioning the disk:
"systemd-repart grows and adds partitions to a partition table, based on
the configuration files described in repart.d(5)."[1]
openssl is required by repart, so it can be enabled like so:
PACKAGECONFIG += "openssl repart"
[1]
From: Stefan Herbrechtsmeier
Make the SPL suffix configurable via SPL_SUFFIX variable to support SPL
binaries with suffix. The suffix is optional and empty per default. The
delimiter in front of the suffix is added automatically if the suffix
is not empty. A new variable SPL_BINARYFILE contains
From: Stefan Herbrechtsmeier
Make the u-boot binary name configurable. Use the existing variable
UBOOT_BINARYNAME which is evaluated from the UBOOT_BINARY.
Signed-off-by: Stefan Herbrechtsmeier
---
meta/classes/uboot-config.bbclass | 4 ++--
meta/recipes-bsp/u-boot/u-boot.inc | 18
From: Stefan Herbrechtsmeier
Remove redundant parts from the deployed and installed SPL artifact
names of multi config configurations to match the other U-Boot artifact
names.
Signed-off-by: Stefan Herbrechtsmeier
---
meta/recipes-bsp/u-boot/u-boot.inc | 16
1 file changed,
From: Stefan Herbrechtsmeier
Signed-off-by: Stefan Herbrechtsmeier
---
meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index 71febb6f43..a8ebcc9ea0 100644
---
Since 80923e8d ("util/format: Add some NEON intrinsics-based
u_format_unpack.") upstream the build fails on Arm platforms which use
the soft-float ABI, such as qemuarmv5:
arm_neon.h:31:2: error: #error "NEON intrinsics not available with the
soft-float ABI. Please use -mfloat-abi=softfp or
systemd-repart[1] is useful for partitioning the disk:
"systemd-repart grows and adds partitions to a partition table, based on
the configuration files described in repart.d(5)."[1]
openssl is required by repart, so it can be enabled like so:
PACKAGECONFIG += "openssl repart"
[1]
ptest.bbclass has a sanity check that all recipes in oe-core which
inherit ptest are also listed in the ptest-packagelists.inc file, and
the build fails if this is not the case.
Whilst this is a laudable goal, it is over-zealous as if the recipe has
a bbappend in another layer which inherits
Hi Bruce
On 9/1/21 3:23 PM, Bruce Ashfield wrote:
> On Wed, Sep 1, 2021 at 5:20 AM Michael Opdenacker
> wrote:
>> Fixes [YOCTO #14538]
>>
>> Recipes shouldn't use the "virtual/" string in RPROVIDES and RDEPENDS.
>>
>> That's confusing because "virtual/" has no special meaning in
>> RPROVIDES and
Native recipes do not produce packages and should not process them,
otherwise it can trigger an error in read_subpackage_metadata
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 263 ---
1 file changed, 134 insertions(+), 129 deletions(-)
diff
We don't want this warning causing problems on the AB, so leave it
comment out for now
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index
The FreeType license maps to the FTL SPDX identifier
Signed-off-by: Joshua Watt
---
meta/conf/licenses.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 1fe5fc6ec1..e2bd58f84a 100644
--- a/meta/conf/licenses.conf
+++
The code in question is licensed under the BSD-3-Clause license, so
including the generic "BSD" license is unnecessary.
Signed-off-by: Joshua Watt
---
meta/recipes-extended/timezone/timezone.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-core/glib-2.0/glib.inc | 2 +-
1 file changed, 1 insertion(+),
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-extended/shadow/shadow.inc | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-devtools/e2fsprogs/e2fsprogs.inc | 2 +-
1 file changed, 1
Add the index to DEPLOYDIR in addition to adding it to the SPDX archive
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index
If a debug source cannot be found, mark it as NOASSERTION so that other
tools at least know we were unable to locate it.
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 36 ++--
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 179 ++-
meta/lib/oe/sbom.py | 5 +-
2 files changed, 181 insertions(+), 3 deletions(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index
Fixes another creator that was missed earlier
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index 3f635045a6..aa3e977b02 100644
---
From: Saul Wold
This will create a more uniq DocumentRef, which will allow
the individual spdx files to be merged into a single SBOM
file reflecting the image. Do the same with the runtime dependencies
also
Signed-off-by: Saul Wold
Signed-off-by: Joshua Watt
---
Licenses reported in the SPDX documents should be either:
A) A valid SPDX identifier cross referenced from the SPDX license
database
B) A "LicenseRef" to a license described in the SPDX document
The licensing code will now add a placeholder extracted license with
corresponding "LicenseRef"
Use the bb.utils.sha* utilities to hash files since they are much faster
than the loops we were rolling ourselves
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 49 +++-
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git
file:// URIs should not be included as the downloadLocation. Instead,
loop until a non-file:// URI is found, or set the location to
NOASSERTION if none is found
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
The Public Domain license (PD) needs a special exception in the license
processing since there is no common license text to be extracted for
these licenses.
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 33
1 file changed, 21 insertions(+),
Stop filtering the runtime dependencies based on do_create_sdpx (makes
it only pick up things in DEPENDS) and instead include all task
dependencies that are not the current PN. This allows other dependency
methods to be picked up correctly, for example the dependency on the
kernel used by kernel
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-extended/sudo/sudo.inc | 2 +-
1 file changed, 1 insertion(+),
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-support/libcap/libcap_2.51.bb | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-extended/pam/libpam_1.5.1.bb | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-support/libjitterentropy/libjitterentropy_3.1.0.bb | 2 +-
1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-graphics/xorg-lib/libxfont2_2.0.5.bb | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-graphics/xorg-lib/libx11_1.7.2.bb | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-graphics/xorg-font/font-util_1.3.2.bb | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-multimedia/flac/flac_1.3.3.bb | 2 +-
1 file changed, 1
Make the license more accurate by specifying the specific variant of BSD
license instead of the generic one. This helps with SPDX license
attribution as "BSD" is not a valid SPDX license.
Signed-off-by: Joshua Watt
---
meta/recipes-devtools/swig/swig.inc | 2 +-
1 file changed, 1 insertion(+),
> -Original Message-
> From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> Sent: den 1 september 2021 15:24
> To: Michael Opdenacker
> Cc: Patches and discussions about the oe-core layer c...@lists.openembedded.org>
> Subject: Re:
When building cargo-native on centos7 with buildtools tarball installed,
we see failures:
/bin/sh: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by
From: Michael Halstead
This adds a patch to glibc which allows it to work with Docker and
clone3 syscall issues cased by EPERM vs ENOSYS.
Signed-off-by: Michael Halstead
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/yocto-uninative.inc | 8
1 file changed, 4
On Wed, Sep 1, 2021 at 5:20 AM Michael Opdenacker
wrote:
>
> Fixes [YOCTO #14538]
>
> Recipes shouldn't use the "virtual/" string in RPROVIDES and RDEPENDS.
>
> That's confusing because "virtual/" has no special meaning in
> RPROVIDES and RDEPENDS (unlike in PROVIDES and DEPENDS).
>
> Instead,
Adds extended package data which is encoded as JSON which allows it to
encode more structure than the "flat" package data files. The extended
data might be much larger than the standard package data, so it is not
read by default and instead requires
oe.packagedata.read_subpkgdata_extended() to be
Adds initial support for generating SBoMs in SPDX json format. SBoM
generation can be enabled by adding:
INHERIT += "create-spdx"
to local.conf
Joshua Watt (30):
classes/package: Add extended packaged data
classes/create-spdx: Add class
classes/create-spdx: Change creator
Adds a class as a first attempt to create SPDX SBoM documents during the
build. This initial work was influenced by [meta-doubleopen][1],
although almost completely rewritten.
[1]: https://github.com/doubleopen-project/meta-doubleopen
Signed-off-by: Joshua Watt
---
Update the creator name since this no longer lives in meta-doubleopen
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx.bbclass | 3 ++-
meta/lib/oe/sbom.py | 16 +---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index e49d4d7e3c..5adad59065
The following changes since commit eea71d274fe4d5f23ba0ab35d14be4fff2e64e2b:
sdk: Enable do_populate_sdk with multilibs (2021-08-19 05:30:01 -1000)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
On Wed, Sep 1, 2021 at 10:46 AM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org > c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> > Sent: den 1 september 2021 15:24
> > To: Michael Opdenacker
> > Cc: Patches and
On Wed, 2021-09-01 at 10:52 -0400, Bruce Ashfield wrote:
> On Wed, Sep 1, 2021 at 10:46 AM Peter Kjellerstedt
> wrote:
> >
> > > -Original Message-
> > > From: openembedded-core@lists.openembedded.org > > c...@lists.openembedded.org> On Behalf Of Bruce Ashfield
> > > Sent: den 1
Since 80923e8d ("util/format: Add some NEON intrinsics-based
u_format_unpack.") upstream the build fails on Arm platforms which use
the soft-float ABI, such as qemuarmv5:
arm_neon.h:31:2: error: #error "NEON intrinsics not available with the
soft-float ABI. Please use -mfloat-abi=softfp or
Hey Steve,
I'd like to request that this commit be cherry-picked to dunfell:
2e753a12cf layer.conf: fix syntax error in PATH setting
This issue is generating syntax warnings/errors from python which can be
concerning to customers.
Thanks!
--
Christopher Larson
kergoth at gmail dot com
On Wed, Sep 1, 2021 at 12:19 PM Christopher Larson wrote:
>
> Hey Steve,
>
> I'd like to request that this commit be cherry-picked to dunfell:
>
> 2e753a12cf layer.conf: fix syntax error in PATH setting
OK, will add to my testing queue.
Steve
>
> This issue is generating syntax
On Wed, 2021-09-01 at 21:09 +0100, Ross Burton wrote:
> As part of the work to converge our license support with SPDX, ensure
> that we have all of the licenses that SPDX supports.
>
> Signed-off-by: Ross Burton
> ---
> meta/files/common-licenses/0BSD | 5 +
>
Backporting upstream fix since the uprev from 5.60 -> 5.61 does include
some minor functionality changes.
Signed-off-by: Trevor Gamblin
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
...ter-Fix-storing-discoverable-setting.patch | 100 ++
2 files changed, 101
On Wed, Sep 1, 2021 at 9:33 AM grygorii tertychnyi wrote:
>
> This reverts commit a155c4d4ca841ef492213a5f0b9121703c62e2b4.
>
> Otherwise, SDK installing fails with:
>
> Extracting SDK...done
> Setting it up...sed: -e expression #1, char 0:
On Wed, Sep 1, 2021 at 9:33 AM grygorii tertychnyi wrote:
>
> This reverts commit a155c4d4ca841ef492213a5f0b9121703c62e2b4.
>
> Otherwise, SDK installing fails with:
>
> Extracting SDK...done
> Setting it up...sed: -e expression #1, char 0:
This reverts commit a155c4d4ca841ef492213a5f0b9121703c62e2b4.
Otherwise, SDK installing fails with:
Extracting SDK...done
Setting it up...sed: -e expression #1, char 0: no previous regular expression
sed: -e expression #1, char 0: no
readline uses ncurses for terminal capabilities database, but it fails to
specify it correctly in the pkg-config .pc file, resulting in:
Requires.private: termcap
As ncurses by default provides newer terminfo instead of termcap, there's
no termcap.pc in the system and pkg-config fails when
Can license cleanups in patches 19-31 be submitted as a separate patchset,
independent from SBoM changes?
On Wed, Sep 01, 2021 at 08:44:58AM -0500, Joshua Watt wrote:
> The code in question is licensed under the BSD-3-Clause license, so
> including the generic "BSD" license is unnecessary.
>
>
On Wed, Sep 1, 2021 at 9:04 AM Andrej Valek wrote:
>
> Hello Steve,
>
> Could you please cherry-pick this patch into dunfell branch too?
OK, will add this to my test queue.
Steve
>
> Thank you,
> Andrej
>
> On Thu, 2021-08-26 at 15:15 +0200, Andrej Valek wrote:
> > - Some distributions with
Hello Steve,
Could you please cherry-pick this patch into dunfell branch too?
Thank you,
Andrej
On Thu, 2021-08-26 at 15:15 +0200, Andrej Valek wrote:
> - Some distributions with UTF-8 locale have problem when National
> Language
> Support is enabled. Add there an option to disable it.
>
>
Hi Steve,
I observe the same sed messages in hardknott, would you please
consider applying it there as well?
On Wed, Sep 1, 2021 at 9:33 PM grygorii tertychnyi wrote:
>
> This reverts commit a155c4d4ca841ef492213a5f0b9121703c62e2b4.
>
> Otherwise, SDK installing fails with:
>
> Extracting
67 matches
Mail list logo
