All tests are installed, but only what `make check`
runs is run, so currently that's 1 test named `check-all`
`libcheck` needs to be present for ./configure to generate
the check* tests.
An issue asking about upstream testing strategy is opened at
https://github.com/thom311/libnl/issues/270
Sign
We need some way to adjust it or check it automatically since it will be
not be the last time when the copyright year willl be upgraded
On Thu, Feb 18, 2021 at 7:34 PM Zheng, Ruoqin
wrote:
> Hi,
>
>
>
> The original patch named
> 0029-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch mod
Hi,
The original patch named
0029-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch modified the
copyright of arm from “2016-2021” to “2016-2020”.
-
diff --git a/sysdeps/aarch64/bits/wordsize.h b/sysdeps/arm/bits/wordsize.h
similarity index 80%
cop
I don’t understand this change why are copyright years different can you
explain
On Thu, Feb 18, 2021 at 5:37 PM zhengruoqin
wrote:
> "file /usr/include/bits/wordsize.h conflicts between attempted installs of
> lib32-libc6-dev-2.33-r0.armv7ahf_neon and libc6-dev-2.33-r0.aarch64"
>
> Signed-off-b
"file /usr/include/bits/wordsize.h conflicts between attempted installs of
lib32-libc6-dev-2.33-r0.armv7ahf_neon and libc6-dev-2.33-r0.aarch64"
Signed-off-by: Zheng Ruoqin
---
...29-wordsize.h-Unify-the-header-between-arm-and-aarch64.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
"file /usr/include/bits/struct_stat.h conflicts between attempted installs of
lib32-libc6-dev-2.33-r0.armv7ahf_neon and libc6-dev-2.33-r0.aarch64"
Signed-off-by: Zheng Ruoqin
---
meta/recipes-core/glibc/glibc-package.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/glib
Okay, I've addressed all comments but the test one.
I pushed it to a local fork of meta-oe here:
https://github.com/teknoraver/meta-openembedded/commit/679944b06ffc564b4b99eae5d934f742bb2a9c09
Which kind of test needs to be done here?
A selftest to be run with oe-selftest? A ptest? A tool copied
On Thu, 2021-02-18 at 20:58 +0100, Alexander Kanavin wrote:
> On Thu, 18 Feb 2021 at 20:22, Jate Sujjavanich wrote:
> > +-setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap',
> > required : false)
> > ++stagingdirnative = get_option('stagingdirnative')
> > ++setcap = find_program(s
exp-dhat:
commit 441bfc5f5 promoted exp-dhat to dhat
exp-sgcheck:
commit 40187fcd6 removed the exp-sgcheck tool.
Signed-off-by: Yi Fan Yu
---
meta/recipes-devtools/valgrind/valgrind/run-ptest | 2 +-
meta/recipes-devtools/valgrind/valgrind_3.16.1.bb | 2 --
2 files changed, 1 insertion(+), 3 de
From: Andrei Gherzan
`devtool` uses `copy_recipe_files` for the upgrade operation when
creating the new, workspace recipe. Before handling the copy operations,
the function checks the entry in `SRC_URI` against `FILE` while in turn
uses absolute paths. When BBLAYERS contains entries that are not
In Django 2.2 before 2.2.18, 3.0 before 3.0.12, and 3.1 before 3.1.6, the
django.utils.archive.extract method (used by startapp --template and
startproject --template) allows directory traversal via an archive with
absolute paths or relative paths with dot segments.
References:
https://nvd.nist.go
On 2/18/21 8:50 AM, Ross Burton wrote:
> Why is the file not found though?
its downloaded there for not in the WORKDIR
-armin
>
> Ross
>
> On Mon, 15 Feb 2021 at 22:41, akuster wrote:
>> This helps avoid these errors:
>> ERROR: lockdev-1_1.0.3-r0 do_cve_check: File Not found:
>> /home/build/
On Thu, 18 Feb 2021 at 20:22, Jate Sujjavanich wrote:
> +-setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap',
> required : false)
> ++stagingdirnative = get_option('stagingdirnative')
> ++setcap = find_program(stagingdirnative + '/usr/sbin/setcap',
> stagingdirnative + '/sbin/setc
if a cmake file uses export(PACKAGE) command it creates a
folder ~/.cmake/package/ in the current user's
home-dir.
fix this host contermination by setting CMAKE_EXPORT_NO_PACKAGE_REGISTRY
to ON by default, which makes the export() command do nothing
Signed-off-by: Konrad Weihmann
---
meta/classe
Search for setcap in STAGING_DIR_NATIVE to avoid host contamination. Add
DEPENDS for libcap-native to supply this if we select libcap for
PACKAGECONFIG.
The previous setting of NO_SETCAP_OR_SUID broke setuid or setcap of
/bin/ping and other executables.
Signed-off-by: Jate Sujjavanich
---
...or
This reverts commit d10da5f6e6d6d3600645dbe43ed412ff23b55095.
---
meta/recipes-extended/iputils/iputils_s20200821.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-extended/iputils/iputils_s20200821.bb
b/meta/recipes-extended/iputils/iputils_s20200821.bb
index
The iputils build will try to make the binaries callable by regular users
using setcap or setuid depending on what is available on the system. It
turns out that libcap provides this command. I figured that adding the
dependency on libcap-native and having meson search STAGING_DIR_NATIVE
would work.
> -Original Message-
> From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 18 februari 2021 17:57
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 03/11] licenses.conf: Add missing 'or-later'
> mappin
> -Original Message-
> From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 18 februari 2021 17:57
> To: openembedded-core@lists.openembedded.org
> Cc: Meh Mbeh Ida Delphine
> Subject: [OE-core] [PATCH 01/11] licenses: Update
From: Luca Boccassi
When polkit is not available, networkd will not have permissions
to call hostnamed's dbus methods, as it runs without privileges.
To solve this, when building without polkit, make a new PACKAGECONFIG
'polkit_hostnamed_fallback' available which changes hostnamed so that
it runs
With the separate of the "-only" and "-or-later" licenses, we need to
update the tests to match the messages now given in the output.
Also use a mix of canonicalised and non-canonlised names in the
reference recipes to help test those cases and ensure coverage.
Signed-off-by: Richard Purdie
---
Sometimes bison would regenerate source files and sometimes it would not
This is likely related to the patching of generated files by on of the
patches.
Drop those changes and force the files to regenerate in all cases since
we depend on bison-native anyway. This ensures the results are always
con
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/git/git.inc | 3 +-
meta/recipes-devtools/git/git/fixsort.patch | 31 +
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/git/git/fixsort.patch
diff --git a/meta/recipe
GPLv2 and GPLv2+ are two difference licenses with different meanings
and we can't just pretend they're the same thing. Change the code
to treat them separately.
Signed-off-by: Richard Purdie
---
meta/classes/license.bbclass | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff
My previous fix wasn't correct as the file timestamps do vary by git checkout
or modification time and aren't correct here. Instead use a specific
date/time for the files to be deterministic.
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb | 10 --
The function being uses here makes comparisions with the canonicalised
license name so we need to canonicalise it for the function else
the comparisions don't work and can give incorrect results.
Signed-off-by: Richard Purdie
---
meta/classes/license_image.bbclass | 2 +-
1 file changed, 1 inser
The licenses were renamed to match their SPDX names, fix the
references in LIC_FILES_CHKSUM in OE-Core.
Signed-off-by: Richard Purdie
---
meta/classes/devicetree.bbclass | 2 +-
meta/recipes-connectivity/connman/connman-conf.bb| 2 +-
meta/recipes-core/bu
Where a user adds "GPLv3" to INCOMPATIBLE_LICENSE they almost certainly
mean both GPLv3-only and GPLv3-or-later. Update the code to handle this
correctly.
Signed-off-by: Richard Purdie
---
meta/classes/license.bbclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/classes/license
The code internally correctly handles canonicalisation of these license
fields, we shouldn't call it manually. The issue is that the fields can
contain wildcards and GPLv3* means something quite different to GPLv3-only*.
Signed-off-by: Richard Purdie
---
meta/classes/license_image.bbclass | 1 -
If we handle the or-later licences separately (which we should),
we need to add in the missing name mappings for the code to
function correctly.
Signed-off-by: Richard Purdie
---
meta/conf/licenses.conf | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/meta/
On Mon, 15 Feb 2021 at 22:43, akuster wrote:
> I don't see the point in logging native, nativesdk etc.
> The bottom line is the BPN has the issue.
Unless the base recipe doesn't exist, for example it's nativesdk or
native specific.
Whilst native is build tool and so arguably not as relevant, nat
Why is the file not found though?
Ross
On Mon, 15 Feb 2021 at 22:41, akuster wrote:
>
> This helps avoid these errors:
> ERROR: lockdev-1_1.0.3-r0 do_cve_check: File Not found:
> /home/build/builds/master/tmp/work/core2-64-poky-linux/lockdev/1_1.0.3-r0/lockdev_1.0.3-1.6.diff
>
> We should conti
On Thu, 2021-02-18 at 00:11 +, Jate Sujjavanich wrote:
> Search for setcap in STAGING_DIR_NATIVE to avoid host contamination. Add
> DEPENDS for libcap-native to supply this if we select libcap for
> PACKAGECONFIG.
Why does it need setcap-native, isn't the target setcap enough? It seems
odd th
Test hangs after glibc 2.33 uprev.
Using gdb `p t[0]` to modify the timeout
argument no longer affects how long `select` wait.
https://bugs.kde.org/show_bug.cgi?id=432870
[YOCTO #14223]
Signed-off-by: Yi Fan Yu
---
...Disable-nlcontrolc.vgtest-for-x86-64.patch | 36 +++
.../val
0001-Add-support-for-setcap-in-STAGING_DIR_NATIVE.patch seems missing?
Alex
On Thu, 18 Feb 2021 at 01:11, Jate Sujjavanich wrote:
> Search for setcap in STAGING_DIR_NATIVE to avoid host contamination. Add
> DEPENDS for libcap-native to supply this if we select libcap for
> PACKAGECONFIG.
>
> Th
I don’t think it should be default since other options if implemented will
perform better so it’s a last resort solution so I would suggest to use it
only where it’s needed
On Thu, Feb 18, 2021 at 3:23 AM Konrad Weihmann
wrote:
> I think I saw something similar on x86 builds (or was it arm32, do
On Thu, 2021-02-18 at 14:13 +, Richard Purdie via lists.openembedded.org
wrote:
> On Thu, 2021-02-18 at 12:24 +0800, Anuj Mittal wrote:
> > Signed-off-by: Anuj Mittal
> > ---
> > .../webkit/{wpebackend-fdo_1.8.0.bb => wpebackend-fdo_1.9.1.bb} | 2 +-
> > 1 file changed, 1 insertion(+), 1 del
Signed-off-by: Oleksandr Kravchuk
---
...ython3-setuptools_52.0.0.bb => python3-setuptools_53.0.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-setuptools_52.0.0.bb =>
python3-setuptools_53.0.0.bb} (94%)
diff --git a/meta/recipes-devtool
From: Jan-Simon Möller
Adding --define 'use_source_date_epoch_as_buildtime 1' to rpmbuild
ensure that the rpm header does have a consistent BUILDTIME tag.
Signed-off-by: Jan-Simon Möller
---
meta/classes/package_rpm.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/packa
On Thu, 2021-02-18 at 12:24 +0800, Anuj Mittal wrote:
> Signed-off-by: Anuj Mittal
> ---
> .../webkit/{wpebackend-fdo_1.8.0.bb => wpebackend-fdo_1.9.1.bb} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-sato/webkit/{wpebackend-fdo_1.8.0.bb =>
> wpebackend-fdo_1.9.1
From: Florian Bezdeka
We are getting closer and closer to the year 2038 where the 32 bit
time_t overflow will happen. While products (= embedded systems) with an
expected life time of 15 years are still save the situation may change
if your system has to survive the next 20 years.
ext2 and ext3
From: Florian Bezdeka
The following patch is the summary of a nice journey through the file
system jungle regarding Y2038 problem. It all began with a warning which
is reported by kernels >= 5.4:
ext4 filesystem being mounted at (mountpoint) supports timestamps until
2038 (0x7fff)
When re
I'm using poky-contrib; checkout paule/rpurdie-license-experiments-osls
Cheers,
Ida
On Thu, Feb 18, 2021 at 12:17 PM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:
> None of the context for the second hunk in the first patch exists. E.g.,
> if I checkout master of poky and grep for “Li
I think I saw something similar on x86 builds (or was it arm32, don't
remember) - so it might be worth discussing to make this setting the
default and configurable to the user - thoughts?
On 18.02.21 04:52, Khem Raj wrote:
The coroutine implementation in ruby has either arch specific
implement
None of the context for the second hunk in the first patch exists. E.g., if I
checkout master of poky and grep for “License for package %s” (part of the line
that the first patch replaces), there is no match in any file.
//Peter
From: Ida Delphine
Sent: den 17 februari 2021 17:59
To: Peter Kje
Signed-off-by: Oleksandr Kravchuk
---
...{python3-pygments_2.7.4.bb => python3-pygments_2.8.0.bb} | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
rename meta/recipes-devtools/python/{python3-pygments_2.7.4.bb =>
python3-pygments_2.8.0.bb} (76%)
diff --git a/meta/recipes-devtools/py
>> Recipes using populate_sdk.bbclass are failing with pseudo abort due to
>> path mismatch on these paths.
>>
>> Signed-off-by: Tomasz Dziendzielski
>> ---
>> meta/conf/bitbake.conf | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>We build SDKs on the autobuilder and don't see this.
On Wed, 2021-02-17 at 23:49 +0100, Tomasz Dziendzielski wrote:
> Recipes using populate_sdk.bbclass are failing with pseudo abort due to
> path mismatch on these paths.
>
> Signed-off-by: Tomasz Dziendzielski
> ---
> meta/conf/bitbake.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Yongxin Liu
---
meta/recipes-graphics/mesa/mesa.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index cb075a8b89..72e22d654e 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-gra
Hi,
On Tue, Feb 16, 2021 at 08:23:31AM -1000, Steve Sakoman wrote:
> The weekly cve reports for master, gatesgarth, and dunfell currently
> omit linux-yocto since the CPE database for the kernel is notoriously
> incomplete in versioning information.
>
> This morning at the YP technical team meeti
50 matches
Mail list logo
