Re: [OE-core] [master] [PATCH] cve-update-nvd2-native: increase the delay between subsequent request failures
Hi, On 2023/12/11 19:28, Dhairya Nagodra via lists.openembedded.org wrote: >>> I have observed the do_fetch logs and found that HTTP 403 errors are >>> returned if the request is blocked, probably due to rate limitation. > > As per my knowledge, HTTP 403 is related to a permission issue rather than a > rate limitation. > I have not seen an HTTP 403 error, anytime. Can you please help clarify how > was it generated? Is it reproducible? > I tried removing both sleep delays altogether (and without API keys) to try > and generate an error. In that, I couldn't generate any errors instead, got > the response with a 15-20 sec delay. So, I guess it stayed within the rate > limit. > Yesterday I also tried to fetch with sleep removed, the result was the same, no error of any kind occurred. Perhaps someone has not read the documentation about rate limiting, so the server is putting a delay before returning a response. That is, I think a single bitbake will not cause the issue. The HTTP 403 error should be reproducible by running multiple cve-update-nvd2-native:do_fetch at the same time on a single PC. Here, I noticed that yesterday I could reproduce the error by executing two tasks in parallel, but today I had to execute three tasks in parallel to reproduce the error. Somehow, the delay that may have been provided by the server may have become longer. I think you are right that HTTP 403 does not look like reaching the rate limit (As Yoann noted, 429 would feel right). The HTTP 403 error returned may be because the request is being sent from a single PC, so I will try cve-update-nvd2-native:do_fetch on three different PCs. This would be closer to the actual use case I have indicated. >>> As a specific example, multiple cve-update-nvd2-native:do_fetch runs >>> in parallel can easily reach the rate limit. It can be assumed that >>> this situation will occur if several people run bitbake in one office. >>> (often unaware of each >>> other...) Regards, Yuta Hayama -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192188): https://lists.openembedded.org/g/openembedded-core/message/192188 Mute This Topic: https://lists.openembedded.org/mt/103049968/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 v3] elfutils: upgrade 0.189 -> 0.190
From: Zang Ruochen
The following patches have been fixed:
0001-libasm-may-link-with-libbz2-if-found.patch
Refresh the following patch:
0001-dso-link-change.patch
Add srcfiles to TESTFILES because ptest needs it.
NEWS:
libelf: Add RELR support.
libdw: Recognize .debug_[ct]u_index sections
readelf: Support readelf -Ds, --use-dynamic --symbol.
Support .gdb_index version 9
scrlines: New tool that compiles a list of source files associated
with a specified dwarf/elf file.
debuginfod: Schema change (reindexing required, sorry!) for a 60%
compression in filename representation, which was a large
part of the sqlite index; also, more deliberate sqlite
-wal management during scanning using the
--scan-checkpoint option.
backends: Various LoongArch updates.
Signed-off-by: Zang Ruochen
---
.../{elfutils_0.189.bb => elfutils_0.190.bb} | 5 ++-
.../elfutils/files/0001-dso-link-change.patch | 14
...libasm-may-link-with-libbz2-if-found.patch | 36 ---
3 files changed, 10 insertions(+), 45 deletions(-)
rename meta/recipes-devtools/elfutils/{elfutils_0.189.bb => elfutils_0.190.bb}
(97%)
delete mode 100644
meta/recipes-devtools/elfutils/files/0001-libasm-may-link-with-libbz2-if-found.patch
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.189.bb
b/meta/recipes-devtools/elfutils/elfutils_0.190.bb
similarity index 97%
rename from meta/recipes-devtools/elfutils/elfutils_0.189.bb
rename to meta/recipes-devtools/elfutils/elfutils_0.190.bb
index d69828131e..0bd96c1e0f 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.189.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.190.bb
@@ -16,7 +16,6 @@ SRC_URI =
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://0002-Fix-elf_cvt_gunhash-if-dest-and-src-are-same.patch \
file://0003-fixheadercheck.patch \
file://0006-Fix-build-on-aarch64-musl.patch \
- file://0001-libasm-may-link-with-libbz2-if-found.patch \
file://0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch \
file://0001-skip-the-test-when-gcc-not-deployed.patch \
file://ptest.patch \
@@ -25,7 +24,7 @@ SRC_URI =
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
SRC_URI:append:libc-musl = " \
file://0003-musl-utils.patch \
"
-SRC_URI[sha256sum] =
"39bd8f1a338e2b7cd4abc3ff11a0eddc6e690f69578a57478d8179b4148708c8"
+SRC_URI[sha256sum] =
"8e00a3a9b5f04bc1dc273ae86281d2d26ed412020b391ffcc23198f10231d692"
inherit autotools gettext ptest pkgconfig
@@ -67,7 +66,7 @@ PTEST_PARALLEL_MAKE = ""
do_install_ptest() {
if [ ${PTEST_ENABLED} = "1" ]; then
# copy the files which needed by the cases
- TEST_FILES="strip strip.o addr2line elfcmp objdump readelf
size.o nm.o nm elflint elfcompress elfclassify stack unstrip"
+ TEST_FILES="strip strip.o addr2line elfcmp objdump readelf
size.o nm.o nm elflint elfcompress elfclassify stack unstrip srcfiles"
install -d -m 755 ${D}${PTEST_PATH}/src
install -d -m 755 ${D}${PTEST_PATH}/lib
install -d -m 755 ${D}${PTEST_PATH}/libelf
diff --git a/meta/recipes-devtools/elfutils/files/0001-dso-link-change.patch
b/meta/recipes-devtools/elfutils/files/0001-dso-link-change.patch
index 6acc036406..8ccfcb7bd5 100644
--- a/meta/recipes-devtools/elfutils/files/0001-dso-link-change.patch
+++ b/meta/recipes-devtools/elfutils/files/0001-dso-link-change.patch
@@ -16,18 +16,18 @@ more details.
Rebase to 0.170
Signed-off-by: Hongxu Jia
-
+Signed-off-by: Zang Ruochen
---
src/Makefile.am | 2 +-
tests/Makefile.am | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
-index 88d0ac8..c28d81f 100644
+index d3d9d40..ea61616 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -45,7 +45,7 @@ libdw = ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) -ldl
-lpthread
- libelf = ../libelf/libelf.a -lz
+ libelf = ../libelf/libelf.a -lz $(zstd_LIBS)
else
libasm = ../libasm/libasm.so
-libdw = ../libdw/libdw.so
@@ -36,11 +36,11 @@ index 88d0ac8..c28d81f 100644
endif
libebl = ../libebl/libebl.a ../backends/libebl_backends.a ../libcpu/libcpu.a
diff --git a/tests/Makefile.am b/tests/Makefile.am
-index c145720..72afd0e 100644
+index 7fb8efb..71c1a61 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
-@@ -554,7 +554,7 @@ libdw = ../libdw/libdw.a -lz $(zip_LIBS) $(libelf)
$(libebl) -ldl -lpthread
- libelf = ../libelf/libelf.a -lz
+@@ -680,7 +680,7 @@ libdw = ../libdw/libdw.a -lz $(zip_LIBS) $(libelf)
$(libebl) -ldl -lpthread
+ libelf = ../libelf/libelf.a -lz $(zstd_LIBS)
libasm = ../libasm/libasm.a
else
-libdw = ../libdw/libdw.so
@@ -48,3 +48,5 @@ index c145720..72afd0e 100644
libelf = ../libelf/libelf.so
libasm =
Re: [OE-core] [PATCH RFC] bitbake.conf/pseudo: Switch from exclusion list to inclusion list
On Mon, 2023-12-11 at 20:35 +, Ross Burton wrote: > On 11 Dec 2023, at 17:35, Richard Purdie via lists.openembedded.org > wrote: > > > > Currently, pseudo tracks all files referenced within it's presence unless > > they're listed in an exclusion list. The exclusion list has grown to be > > fairly unwieldy. > > > > This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in > > theory should be easier and more explicit to maintain. > > I’ve never understood the rationale behind exclude over include (then again > there’s lots I don’t understand), so I’m very much for this in principle. If you create a file and then move it into pseudo's "sight", problematic things can happen. That sounds like an odd thing to do until you see tmp files created in /tmp, or a "cp /dev/null newfile" or the fun games you can play with /proc. Another example would be create something in cwd (not included), then move it so becomes something which is included and the permissions are lost. The argument was that exclusions were therefore safer than inclusions and in some ways that is true. The question is which is going to work the best and be the most maintainable too. This patch at least allows us to experiment with the other choice. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192186): https://lists.openembedded.org/g/openembedded-core/message/192186 Mute This Topic: https://lists.openembedded.org/mt/103113368/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 RFC] bitbake.conf/pseudo: Switch from exclusion list to inclusion list
On 11 Dec 2023, at 17:35, Richard Purdie via lists.openembedded.org wrote: > > Currently, pseudo tracks all files referenced within it's presence unless > they're listed in an exclusion list. The exclusion list has grown to be > fairly unwieldy. > > This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in > theory should be easier and more explicit to maintain. I’ve never understood the rationale behind exclude over include (then again there’s lots I don’t understand), so I’m very much for this in principle. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192185): https://lists.openembedded.org/g/openembedded-core/message/192185 Mute This Topic: https://lists.openembedded.org/mt/103113368/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] pseudo_client: Add support for PSEUDO_INCLUDE_PATHS
We've often wondered if things would be better with a path include
list instead of an exclusion list. Add support for this so we can
test that theory
If set the include path takes precedence over the ignore path list.
Signed-off-by: Richard Purdie
---
pseudo_client.c | 22 ++
pseudo_util.c | 1 +
2 files changed, 23 insertions(+)
diff --git a/pseudo_client.c b/pseudo_client.c
index a03d6b1..c55ab9d 100644
--- a/pseudo_client.c
+++ b/pseudo_client.c
@@ -1577,6 +1577,28 @@ int pseudo_client_ignore_path_chroot(const char *path,
int ignore_chroot) {
if (ignore_chroot && pseudo_chroot && strncmp(path, pseudo_chroot,
pseudo_chroot_len) == 0)
return 0;
+ env = pseudo_get_value("PSEUDO_INCLUDE_PATHS");
+ if (env) {
+ char *p = env;
+ if (*path == '\0') {
+ free(env);
+ return 0;
+ }
+ while (p) {
+ char *next = strchr(p, ',');
+ if (next)
+ *next++ = '\0';
+ if (*p && !strncmp(path, p, strlen(p))) {
+ free(env);
+ return 0;
+ }
+ p = next;
+ }
+ pseudo_debug(PDBGF_PATH | PDBGF_VERBOSE, "ignoring path:
'%s'\n", path);
+ free(env);
+ return 1;
+}
+
env = pseudo_get_value("PSEUDO_IGNORE_PATHS");
if (!env)
return 0;
diff --git a/pseudo_util.c b/pseudo_util.c
index b58036f..77edb9d 100644
--- a/pseudo_util.c
+++ b/pseudo_util.c
@@ -43,6 +43,7 @@ static struct pseudo_variables pseudo_env[] = {
{ "PSEUDO_BINDIR", 13, NULL },
{ "PSEUDO_LIBDIR", 13, NULL },
{ "PSEUDO_LOCALSTATEDIR", 20, NULL },
+ { "PSEUDO_INCLUDE_PATHS", 20, NULL },
{ "PSEUDO_IGNORE_PATHS", 19, NULL },
{ "PSEUDO_PASSWD", 13, NULL },
{ "PSEUDO_CHROOT", 13, NULL },
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192184):
https://lists.openembedded.org/g/openembedded-core/message/192184
Mute This Topic: https://lists.openembedded.org/mt/103113384/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 RFC] bitbake.conf/pseudo: Switch from exclusion list to inclusion list
Currently, pseudo tracks all files referenced within it's presence unless
they're listed in an exclusion list. The exclusion list has grown to be
fairly unwieldy.
This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in
theory should be easier and more explicit to maintain.
Signed-off-by: Richard Purdie
---
meta/conf/bitbake.conf | 11 ---
meta/recipes-core/glibc/glibc-locale.inc | 2 ++
meta/recipes-devtools/pseudo/pseudo_git.bb | 4 ++--
3 files changed, 8 insertions(+), 9 deletions(-)
For now I'm sharing this as an experiment to see if this is a change we want to
make. I'd be interested if anyone wanted to compare performance in particular.
We
do need to run it through oe-selftest as I suspect there are issues to be
identified
and tracked down. This patch was tested with basic image generation.
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e7826e7af96..bf639fe4f2a 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -745,18 +745,15 @@ SRC_URI = ""
PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
-PSEUDO_IGNORE_PATHS =
"/usr/,/etc/,/lib,/dev/,/run/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR}"
-PSEUDO_IGNORE_PATHS .=
",${TMPDIR}/sstate-control,${TMPDIR}/buildstats,${TMPDIR}/sysroots-components,${TMPDIR}/pkgdata"
-PSEUDO_IGNORE_PATHS .=
",${WORKDIR}/deploy-,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/pkgdata-sysroot"
-PSEUDO_IGNORE_PATHS .=
",${DEPLOY_DIR},${BUILDHISTORY_DIR},${TOPDIR}/cache,${COREBASE}/scripts,${CCACHE_DIR}"
+PSEUDO_INCLUDE_PATHS =
"/tmp,/proc,/dev,${WORKDIR}/image,${WORKDIR}/package,${WORKDIR}/rootfs,${WORKDIR}/sstate-build-package/,${WORKDIR}/sstate-install-package/,${WORKDIR}/pkgdata,${WORKDIR}/minidebuginfo"
export PSEUDO_DISABLED = "1"
#export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
#export PSEUDO_BINDIR = "${STAGING_DIR_NATIVE}${bindir_native}"
#export PSEUDO_LIBDIR = "${STAGING_DIR_NATIVE}$PSEUDOBINDIR/../lib/pseudo/lib
-FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native}
PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib
PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
PSEUDO_IGNORE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_IGNORE_PATHS'))}
PSEUDO_DISABLED=1 PYTHONDONTWRITEBYTECODE=1"
+FAKEROOTBASEENV = "PSEUDO_BINDIR=${PSEUDO_SYSROOT}${bindir_native}
PSEUDO_LIBDIR=${PSEUDO_SYSROOT}${prefix_native}/lib/pseudo/lib
PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
PSEUDO_INCLUDE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_INCLUDE_PATHS'))}
PSEUDO_DISABLED=1 PYTHONDONTWRITEBYTECODE=1"
FAKEROOTCMD = "${PSEUDO_SYSROOT}${bindir_native}/pseudo"
-FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD}
PSEUDO_NOSYMLINKEXP=1
PSEUDO_IGNORE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_IGNORE_PATHS'))}
PSEUDO_DISABLED=0"
+FAKEROOTENV = "PSEUDO_PREFIX=${PSEUDO_SYSROOT}${prefix_native}
PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD}
PSEUDO_NOSYMLINKEXP=1
PSEUDO_INCLUDE_PATHS=${@oe.path.canonicalize(d.getVar('PSEUDO_INCLUDE_PATHS'))}
PSEUDO_DISABLED=0"
FAKEROOTNOENV = "PSEUDO_UNLOAD=1"
FAKEROOTDIRS = "${PSEUDO_LOCALSTATEDIR}"
FAKEROOTLOGS = "${WORKDIR}/pseudo/pseudo.log"
@@ -951,7 +948,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH
BBPATH BBSERVER DL_DI
SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_REPORT_TASKDATA \
SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES
\
OMP_NUM_THREADS BB_CURRENTTASK"
-BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_IGNORE_PATHS
BUILDHISTORY_DIR \
+BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS
BUILDHISTORY_DIR \
SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID
\
SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS
DISABLE_SANITY_CHECKS \
diff --git a/meta/recipes-core/glibc/glibc-locale.inc
b/meta/recipes-core/glibc/glibc-locale.inc
index 289f58d4df9..d946b939ec3 100644
--- a/meta/recipes-core/glibc/glibc-locale.inc
+++ b/meta/recipes-core/glibc/glibc-locale.inc
@@ -64,6 +64,8 @@ FILES:localedef = "${bindir}/localedef"
LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale"
+PSEUDO_INCLUDE_PATHS .= ",${WORKDIR}/locale-tree"
+
copy_locale_files() {
local dir=$1 mode=$2
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 699cab11c66..daecb1554f5 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,6 +1,6 @@
require pseudo.inc
-SRC_URI =
[OE-core][PATCH] oeqa/selftest/recipetool: fix metadata corruption on meta layer
[YOCTO #15314]
test_recipetool_appendsrcfile_update_recipe_basic is using base-files as
test recipe but modifies it directly which can corrupt metadata for other
tests relying on this recipe.
So use mtd-utils-selftest as test recipe from meta-selftest to avoid
this kind of issues
Signed-off-by: Julien Stephan
---
depends on https://lists.openembedded.org/g/openembedded-core/message/192176
---
meta/lib/oeqa/selftest/cases/recipetool.py | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
b/meta/lib/oeqa/selftest/cases/recipetool.py
index c7f7a066f3a..d7719da70e3 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -1260,23 +1260,16 @@ class RecipetoolAppendsrcTests(RecipetoolAppendsrcBase):
self.test_recipetool_appendsrcfile_existing_in_src_uri_diff_params(machine='mymachine')
def test_recipetool_appendsrcfile_update_recipe_basic(self):
-testrecipe = "base-files"
+testrecipe = "mtd-utils-selftest"
recipefile = get_bb_var('FILE', testrecipe)
-result = runCmd('bitbake-layers show-layers')
-layerrecipe = None
-for line in result.output.splitlines()[3:]:
-layer = line.split()[1]
-if layer in recipefile:
-layerrecipe = layer
-break
-self.assertTrue(layerrecipe, 'Unable to find the layer containing %s'
% testrecipe)
-cmd = 'recipetool appendsrcfile -u %s %s %s' % (layerrecipe,
testrecipe, self.testfile)
+self.assertIn('meta-selftest', recipefile, 'This test expect %s recipe
to be in meta-selftest')
+cmd = 'recipetool appendsrcfile -W -u meta-selftest %s %s' %
(testrecipe, self.testfile)
result = runCmd(cmd)
self.assertNotIn('Traceback', result.output)
self.add_command_to_tearDown('cd %s; rm -f %s/%s; git checkout .' %
(os.path.dirname(recipefile), testrecipe, os.path.basename(self.testfile)))
expected_status = [(' M', '.*/%s$' % os.path.basename(recipefile)),
- ('??', '.*/%s/%s/%s$' % (testrecipe, testrecipe,
os.path.basename(self.testfile)))]
+ ('??', '.*/%s/%s$' % (testrecipe,
os.path.basename(self.testfile)))]
self._check_repo_status(os.path.dirname(recipefile), expected_status)
result = runCmd('git diff %s' % os.path.basename(recipefile),
cwd=os.path.dirname(recipefile))
removelines = []
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192182):
https://lists.openembedded.org/g/openembedded-core/message/192182
Mute This Topic: https://lists.openembedded.org/mt/103112620/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] patchtest: Add test for deprecated CVE_CHECK_IGNORE
From: Simone Weiß
If a recipes was modified recommand the use of `CVE_STATUS` instead if
`CVE_CHECK_IGNORE` is used. This is a depreacted variable and will
result in a warning from the cve-check.class and should hence not be
used anymore. [YOCTO #15311]
Signed-off-by: Simone Weiß
---
meta/lib/patchtest/tests/test_metadata.py | 15 +++
1 file changed, 15 insertions(+)
diff --git a/meta/lib/patchtest/tests/test_metadata.py
b/meta/lib/patchtest/tests/test_metadata.py
index b6f4456ad2..174dfc31c6 100644
--- a/meta/lib/patchtest/tests/test_metadata.py
+++ b/meta/lib/patchtest/tests/test_metadata.py
@@ -25,6 +25,8 @@ class TestMetadata(base.Metadata):
sha256sum = 'sha256sum'
git_regex = pyparsing.Regex('^git\:\/\/.*')
metadata_summary = 'SUMMARY'
+cve_check_ignore_var = 'CVE_CHECK_IGNORE'
+cve_status_var = 'CVE_STATUS'
def test_license_presence(self):
if not self.added:
@@ -178,3 +180,16 @@ class TestMetadata(base.Metadata):
# "${PN} version ${PN}-${PR}" is the default, so fail if default
if summary.startswith('%s version' % pn):
self.fail('%s is missing in newly added recipe' %
self.metadata_summary)
+
+def test_cve_check_ignore(self):
+if not self.modified:
+self.skip('No modified recipes, skipping test')
+for pn in self.modified:
+# we are not interested in images
+if 'core-image' in pn:
+continue
+rd = self.tinfoil.parse_recipe(pn)
+cve_check_ignore = rd.getVar(self.cve_check_ignore_var)
+
+if cve_check_ignore is not None:
+self.fail('%s is deprecated and should be replaced by %s' %
(self.cve_check_ignore_var, self.cve_status_var))
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192181):
https://lists.openembedded.org/g/openembedded-core/message/192181
Mute This Topic: https://lists.openembedded.org/mt/103112424/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 3/7] rust: Upgrade 1.71.0 -> 1.71.1
On Sun, Dec 10, 2023 at 7:39 PM Richard Purdie
wrote:
>
> On Fri, 2023-12-08 at 14:03 +, Alex Kiernan wrote:
> > https://blog.rust-lang.org/2023/08/03/Rust-1.71.1.html
> >
> > Signed-off-by: Alex Kiernan
> > ---
> >
> > meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb} | 0
> > .../rust/{libstd-rs_1.71.0.bb => libstd-rs_1.71.1.bb} | 0
> > ...t-cross-canadian_1.71.0.bb => rust-cross-canadian_1.71.1.bb} | 0
> > .../rust/{rust-llvm_1.71.0.bb => rust-llvm_1.71.1.bb} | 0
> > meta/recipes-devtools/rust/rust-source.inc | 2 +-
> > meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb} | 0
> > 6 files changed, 1 insertion(+), 1 deletion(-)
> > rename meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb}
> > (100%)
> > rename meta/recipes-devtools/rust/{libstd-rs_1.71.0.bb =>
> > libstd-rs_1.71.1.bb} (100%)
> > rename meta/recipes-devtools/rust/{rust-cross-canadian_1.71.0.bb =>
> > rust-cross-canadian_1.71.1.bb} (100%)
> > rename meta/recipes-devtools/rust/{rust-llvm_1.71.0.bb =>
> > rust-llvm_1.71.1.bb} (100%)
> > rename meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb} (100%)
> >
> > diff --git a/meta/recipes-devtools/rust/cargo_1.71.0.bb
> > b/meta/recipes-devtools/rust/cargo_1.71.1.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/rust/cargo_1.71.0.bb
> > rename to meta/recipes-devtools/rust/cargo_1.71.1.bb
> > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
> > b/meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
> > rename to meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
> > diff --git a/meta/recipes-devtools/rust/rust-cross-canadian_1.71.0.bb
> > b/meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/rust/rust-cross-canadian_1.71.0.bb
> > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
> > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
> > b/meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
> > rename to meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
> > diff --git a/meta/recipes-devtools/rust/rust-source.inc
> > b/meta/recipes-devtools/rust/rust-source.inc
> > index 3a192e42db7d..0729db6f0b45 100644
> > --- a/meta/recipes-devtools/rust/rust-source.inc
> > +++ b/meta/recipes-devtools/rust/rust-source.inc
> > @@ -7,7 +7,7 @@ SRC_URI +=
> > "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> > file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
> >
> > file://0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch;patchdir=${RUSTSRC}
> > \
> > "
> > -SRC_URI[rust.sha256sum] =
> > "5814699031aafdcc2e2f71fc9b389678cd7042350d1583da061463d8e88681c7"
> > +SRC_URI[rust.sha256sum] =
> > "371af0fbe04051e20a74dbea6d4e4e548f10f15309c49cae2688afb882b6c7f1"
> >
> > RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
> >
> > diff --git a/meta/recipes-devtools/rust/rust_1.71.0.bb
> > b/meta/recipes-devtools/rust/rust_1.71.1.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/rust/rust_1.71.0.bb
> > rename to meta/recipes-devtools/rust/rust_1.71.1.bb
>
> I ran some testing and it looks like we could merge up to 1.71.1
> without autobuilder failures in this series. Beyond that we have the
> reproducibility and zvariant issues.
>
https://github.com/rust-lang/cargo/issues/8140 looks possibly
relevant. I wonder if we're just getting lucky somehow.
--
Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192180):
https://lists.openembedded.org/g/openembedded-core/message/192180
Mute This Topic: https://lists.openembedded.org/mt/103055164/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 1/2] cargo-update-recipe-crates: Use CARGO_LOCK_PATH
On Mon, Dec 11, 2023 at 10:52 AM Alex Kiernan via
lists.openembedded.org
wrote:
>
> On Mon, Dec 11, 2023 at 9:43 AM Alex Kiernan wrote:
> >
> > On Mon, Dec 11, 2023 at 9:28 AM Alexander Kanavin
> > wrote:
> > >
> > > On Mon, 11 Dec 2023 at 10:09, Alex Kiernan wrote:
> > > > In a single project there are (potentially) multiple Cargo.toml, but
> > > > just one Cargo.lock. If there's multiple Cargo.lock files in a repo,
> > > > that implies multiple projects which I don't think we've any way of
> > > > building from a single recipe.
> > >
> > > I'm thinking of projects like librsvg, python3-bcrypt or
> > > python3-cryptography where the build is orchestrated by meson,
> > > autoconf or setuptools, and where we don't run cargo directly and
> > > leave it to those tools. They may have single Cargo.lock now, but will
> > > that hold? Also, that Cargo.lock is not necessarily in the root of
> > > ${S}, so you'd have to set the location manually, instead of not
> > > having to worry about it. Is CARGO_LOCK_PATH or its parent variables
> > > already set correctly for all of them? I see this is not done from
> > > python3-cryptography; shouldn't the build error out, if
> > > cargo_common_do_patch_paths requires the location? Something doesn't
> > > compute fully here.
> > >
> >
> > That's exactly the one I was going to look at next, as I agree
> > something doesn't add up there.
> >
>
> cargo_common_do_patch_paths isn't in the call graph for
> python3-cryptography, it gets patched in like this:
>
> do_configure[postfuncs] += "cargo_common_do_patch_paths"
>
> I'm unclear why that doesn't execute, I'm wondering if its related to
> the autogenerated do_configure and this is a usage that just doesn't
> work?
>
> # line: 1, file: autogenerated
> do_configure() {
> setup_target_config
> python_setuptools3_rust_do_configure
> }
>
> However even if it was in the call graph, we wouldn't have errored in
> it as there's no patches to apply to the cargo config as the crates
> are all satisfied from the vendored sources we deliver.
>
> It does feel like we're missing a piece in our python/rust integration
> since if you did have a crate delivered from git then we wouldn't
> patch up the cargo config correctly and I guess end up erroring out.
>
Okay, I'm wrong. The pieces are all there, just we have no git crates
to patch in for python3-cryptography so the existence check for
Cargo.lock never runs. Maybe that should be hoisted earlier in the
function so you see the failure if Cargo.lock isn't where it would be
expected to be.
--
Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192179):
https://lists.openembedded.org/g/openembedded-core/message/192179
Mute This Topic: https://lists.openembedded.org/mt/103094777/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][kirkstone][PATCH] nghttp2: fix CVE-2023-44487
On Sat, Dec 9, 2023 at 1:57 AM aszh07 wrote:
>
> From: Zahir Hussain
>
> The HTTP/2 protocol allows a denial of service (server resource consumption)
> because request cancellation can reset many streams quickly, as exploited in
> the wild in August through October 2023.
>
> References:
> https://nvd.nist.gov/vuln/detail/CVE-2023-44487
>
> Upstream patches:
> https://snapshot.debian.org/archive/debian-security/20231016T131513Z/pool/updates/main/n/nghttp2/nghttp2_1.36.0-2%2Bdeb10u2.debian.tar.xz
>
> Signed-off-by: aszh07
> Signed-off-by: Zahir Hussain
> ---
> .../nghttp2/nghttp2/CVE-2023-44487.patch | 906 ++
> .../recipes-support/nghttp2/nghttp2_1.47.0.bb | 1 +
> 2 files changed, 907 insertions(+)
> create mode 100644 meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch
>
> diff --git a/meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch
> b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch
> new file mode 100644
> index 00..b313525817
> --- /dev/null
> +++ b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-44487.patch
> @@ -0,0 +1,906 @@
> +Origin:
> https://github.com/nghttp2/nghttp2/commit/72b4af6143681f528f1d237b21a9a7aee1738832
> +From: Tatsuhiro Tsujikawa
> +Date: Sun, 1 Oct 2023 00:05:01 +0900
> +Subject: Rework session management
> +
> +CVE: CVE-2023-44487
> +
> +Upstream-Status: Backport
> [https://snapshot.debian.org/archive/debian-security/20231016T131513Z/pool/updates/main/n/nghttp2/nghttp2_1.36.0-2%2Bdeb10u2.debian.tar.xz]
Debian is not the upstream for nghttp2! Please send a V2 that
references the actual upstream commit that fixes this issue.
Steve
> +
> +Signed-off-by: Zahir Hussain zahir.ba...@kpit.com
> +Signed-off-by: aszh07
> +--- a/CMakeLists.txt
> b/CMakeLists.txt
> +@@ -262,6 +262,7 @@ check_include_file("netinet/in.h" HAVE
> + check_include_file("pwd.h" HAVE_PWD_H)
> + check_include_file("sys/socket.h" HAVE_SYS_SOCKET_H)
> + check_include_file("sys/time.h" HAVE_SYS_TIME_H)
> ++check_include_file("sysinfoapi.h" HAVE_SYSINFOAPI_H)
> + check_include_file("syslog.h" HAVE_SYSLOG_H)
> + check_include_file("time.h" HAVE_TIME_H)
> + check_include_file("unistd.h" HAVE_UNISTD_H)
> +@@ -302,8 +303,11 @@ check_type_size("time_t" SIZEOF_TIME_T)
> + include(CheckFunctionExists)
> + check_function_exists(_Exit HAVE__EXIT)
> + check_function_exists(accept4 HAVE_ACCEPT4)
> ++check_function_exists(clock_gettime HAVE_CLOCK_GETTIME)
> + check_function_exists(mkostemp HAVE_MKOSTEMP)
> +
> ++check_symbol_exists(GetTickCount64 sysinfoapi.h HAVE_GETTICKCOUNT64)
> ++
> + include(CheckSymbolExists)
> + # XXX does this correctly detect initgroups (un)availability on cygwin?
> + check_symbol_exists(initgroups grp.h HAVE_DECL_INITGROUPS)
> +--- a/cmakeconfig.h.in
> b/cmakeconfig.h.in
> +@@ -34,9 +34,15 @@
> + /* Define to 1 if you have the `accept4` function. */
> + #cmakedefine HAVE_ACCEPT4 1
> +
> ++/* Define to 1 if you have the `clock_gettime` function. */
> ++#cmakedefine HAVE_CLOCK_GETTIME 1
> ++
> + /* Define to 1 if you have the `mkostemp` function. */
> + #cmakedefine HAVE_MKOSTEMP 1
> +
> ++/* Define to 1 if you have the `GetTickCount64` function. */
> ++#cmakedefine HAVE_GETTICKCOUNT64 1
> ++
> + /* Define to 1 if you have the `initgroups` function. */
> + #cmakedefine01 HAVE_DECL_INITGROUPS
> +
> +@@ -73,6 +79,9 @@
> + /* Define to 1 if you have the header file. */
> + #cmakedefine HAVE_SYS_TIME_H 1
> +
> ++/* Define to 1 if you have the header file. */
> ++#cmakedefine HAVE_SYSINFOAPI_H 1
> ++
> + /* Define to 1 if you have the header file. */
> + #cmakedefine HAVE_SYSLOG_H 1
> +
> +--- a/configure.ac
> b/configure.ac
> +@@ -607,6 +607,7 @@ AC_CHECK_HEADERS([ \
> + string.h \
> + sys/socket.h \
> + sys/time.h \
> ++ sysinfoapi.h \
> + syslog.h \
> + time.h \
> + unistd.h \
> +@@ -681,6 +682,7 @@ AC_FUNC_STRNLEN
> + AC_CHECK_FUNCS([ \
> + _Exit \
> + accept4 \
> ++ clock_gettime \
> + dup2 \
> + getcwd \
> + getpwnam \
> +@@ -706,6 +708,25 @@ AC_CHECK_FUNCS([ \
> + AC_CHECK_FUNC([timerfd_create],
> + [have_timerfd_create=yes], [have_timerfd_create=no])
> +
> ++AC_MSG_CHECKING([checking for GetTickCount64])
> ++AC_LINK_IFELSE([AC_LANG_PROGRAM(
> ++[[
> ++#include
> ++]],
> ++[[
> ++GetTickCount64();
> ++]])],
> ++[have_gettickcount64=yes],
> ++[have_gettickcount64=no])
> ++
> ++if test "x${have_gettickcount64}" = "xyes"; then
> ++ AC_MSG_RESULT([yes])
> ++ AC_DEFINE([HAVE_GETTICKCOUNT64], [1],
> ++[Define to 1 if you have `GetTickCount64` function.])
> ++else
> ++ AC_MSG_RESULT([no])
> ++fi
> ++
> + # For cygwin: we can link initgroups, so AC_CHECK_FUNCS succeeds, but
> + # cygwin disables initgroups due to feature test macro magic with our
> + # configuration. FreeBSD declares initgroups() in unistd.h.
> +--- a/doc/Makefile.am
> b/doc/Makefile.am
> +@@ -69,6 +69,7 @@ APIDOCS= \
> +
[OE-core] [RFC PATCH v2] qemurunner.py: continue to drain stdout after login:
If qemurunner doesn't continuously drain stdout we will eventually
cause QEMU to block while trying to write to the pipe. This can
manifest itself if the guest has for example configured its serial
ports to output via stdio even if the test itself is using a TCP
console or SSH to run things.
To do this:
- always create a logging thread regardless of serial_ports
- use a semaphore between main and logging threads
- move the login detection into the logging thread
- wait until the second acquire before continuing
This doesn't address a potential overflow of stderr although generally
stderr from QEMU will be a lot less likely to block due to the volume
of data.
Signed-off-by: Alex Bennée
Cc: Mikko Rapeli
---
meta/lib/oeqa/utils/qemurunner.py | 128 ++
1 file changed, 78 insertions(+), 50 deletions(-)
diff --git a/meta/lib/oeqa/utils/qemurunner.py
b/meta/lib/oeqa/utils/qemurunner.py
index 29fe271976..b768c08f04 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -207,8 +207,7 @@ class QemuRunner:
self.logger.info("QMP Available for connection at %s" % (qmp_port2))
try:
-if self.serial_ports >= 2:
-self.threadsock, threadport = self.create_socket()
+self.threadsock, threadport = self.create_socket()
self.server_socket, self.serverport = self.create_socket()
except socket.error as msg:
self.logger.error("Failed to create listening socket: %s" % msg[1])
@@ -243,6 +242,7 @@ class QemuRunner:
# to be a proper fix but this will suffice for now.
self.runqemu = subprocess.Popen(launch_cmd, shell=True,
stdout=subprocess.PIPE, stderr=subprocess.STDOUT, stdin=subprocess.PIPE,
preexec_fn=os.setpgrp, env=env, cwd=self.tmpdir)
output = self.runqemu.stdout
+output_drain = output
launch_time = time.time()
#
@@ -431,21 +431,30 @@ class QemuRunner:
self.logger.debug("Target IP: %s" % self.ip)
self.logger.debug("Server IP: %s" % self.server_ip)
-if self.serial_ports >= 2:
-self.thread = LoggingThread(self.log, self.threadsock, self.logger)
-self.thread.start()
-if not self.thread.connection_established.wait(self.boottime):
-self.logger.error("Didn't receive a console connection from
qemu. "
- "Here is the qemu command line used:\n%s\nand "
- "output from runqemu:\n%s" % (cmdline, out))
-self.stop_thread()
-return False
+# Create and hold onto the login semaphore, this will block
+# the LoggingThread until we are ready
+login_semaphore = threading.Semaphore()
+login_semaphore.acquire()
+
+self.thread = LoggingThread(self.log, self.threadsock,
+self.runqemu.stdout,
self.boot_patterns['search_reached_prompt'],
+self.logger, login_semaphore)
+
+self.thread.start()
+login_semaphore.release()
+
+# if not self.thread.connection_established.wait(self.boottime):
+# self.logger.error("Didn't receive a console connection from
qemu. "
+# "Here is the qemu command line used:\n%s\nand "
+# "output from runqemu:\n%s" % (cmdline, out))
+# self.stop_thread()
+# return False
self.logger.debug("Output from runqemu:\n%s", out)
self.logger.debug("Waiting at most %d seconds for login banner (%s)" %
(self.boottime, time.strftime("%D %H:%M:%S")))
endtime = time.time() + self.boottime
-filelist = [self.server_socket, self.runqemu.stdout]
+filelist = [self.server_socket]
reachedlogin = False
stopread = False
qemusock = None
@@ -464,46 +473,19 @@ class QemuRunner:
filelist.remove(self.server_socket)
self.logger.debug("Connection from %s:%s" % addr)
else:
-# try to avoid reading only a single character at a time
-time.sleep(0.1)
-if hasattr(file, 'read'):
-read = file.read(1024)
-elif hasattr(file, 'recv'):
-read = file.recv(1024)
-else:
-self.logger.error('Invalid file type: %s\n%s' % (file))
-read = b''
-
-self.logger.debug2('Partial boot log:\n%s' %
(read.decode('utf-8', errors='backslashreplace')))
-data = data + read
-if data:
-bootlog += data
-self.log(data, extension = ".2")
-data = b''
-
-if
[OE-core][PATCH] oeqa/selftest/recipetool: remove left over from development
Remove leftover code needed for development that was unintentionally
committed
Signed-off-by: Julien Stephan
---
meta/lib/oeqa/selftest/cases/recipetool.py | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
b/meta/lib/oeqa/selftest/cases/recipetool.py
index d10d61bc5b0..c7f7a066f3a 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -1265,12 +1265,10 @@ class RecipetoolAppendsrcTests(RecipetoolAppendsrcBase):
result = runCmd('bitbake-layers show-layers')
layerrecipe = None
for line in result.output.splitlines()[3:]:
-with open("/tmp/juju.txt", "a") as file:
-layer = line.split()[1]
-print(layer, file=file)
-if layer in recipefile:
-layerrecipe = layer
-break
+layer = line.split()[1]
+if layer in recipefile:
+layerrecipe = layer
+break
self.assertTrue(layerrecipe, 'Unable to find the layer containing %s'
% testrecipe)
cmd = 'recipetool appendsrcfile -u %s %s %s' % (layerrecipe,
testrecipe, self.testfile)
result = runCmd(cmd)
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192176):
https://lists.openembedded.org/g/openembedded-core/message/192176
Mute This Topic: https://lists.openembedded.org/mt/103110965/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] [kirkstone][PATCH] nativesdk-sdk-provides-dummy.bb: Update host tools for rust-cross-canadian
On 2023-12-11 7:26 a.m., deepthi.hem...@windriver.com wrote: From: Deepthi Hemraj [YOCTO #15082] Packagegroup-rust-cross-canadian package requires rust-cross-canadian, but the necessary libstdc++.so.6(GLIBCXX_3.4.30)(64bit) library is missing. The fix adds the libstdc++.so.6(GLIBCXX_3.4.30)(64bit) library requirement to the SDK dummy package, resolving the dependency conflict. Signed-off-by: Deepthi Hemraj --- meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb index 1d71f373a4..dc3ae1edaf 100644 --- a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb +++ b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb @@ -10,7 +10,8 @@ DUMMYPROVIDES = "\ /usr/bin/env \ libGL.so()(64bit) \ libGL.so \ -" +libstdc++.so.6(GLIBCXX_3.4.30)(64bit) \ +" require dummy-sdk-package.inc This doesn't seem right to me... Does the problem happen on master? I haven't tried it but I suspect we want to add something like: nativesdk-libstdc++ to: DEPENDS:append:class-nativesdk = " nativesdk-rust-llvm" in the rust bb file. -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192175): https://lists.openembedded.org/g/openembedded-core/message/192175 Mute This Topic: https://lists.openembedded.org/mt/103107487/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/1] archiver.bbclass: Improve work-shared checking
From: Robert Yang
There are other recipes except the listed ones which use work-shared, improve
the checking to make other recipes such as llvm-project-source work with
do_ar_patched.
Signed-off-by: Robert Yang
---
meta/classes/archiver.bbclass | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 0eee1abefab..80a69cf31db 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -468,10 +468,8 @@ def create_diff_gz(d, src_orig, src, ar_outdir):
os.chdir(cwd)
def is_work_shared(d):
-pn = d.getVar('PN')
-return pn.startswith('gcc-source') or \
-bb.data.inherits_class('kernel', d) or \
-(bb.data.inherits_class('kernelsrc', d) and
d.expand("${TMPDIR}/work-shared") in d.getVar('S'))
+sharedworkdir = os.path.join(d.getVar('TMPDIR'), 'work-shared')
+return d.getVar('S').startswith(sharedworkdir)
# Run do_unpack and do_patch
python do_unpack_and_patch() {
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192173):
https://lists.openembedded.org/g/openembedded-core/message/192173
Mute This Topic: https://lists.openembedded.org/mt/103110276/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/1] archiver.bbclass: Improve work-shared checking
From: Robert Yang The following changes since commit 564339afb73fc52a66c1a08437587cad1c4d46e7: useradd: Fix useradd do_populate_sysroot dependency bug (2023-12-10 09:23:58 +) are available in the Git repository at: https://github.com/robertlinux/yocto rbt/archiver https://github.com/robertlinux/yocto/tree/rbt/archiver Robert Yang (1): archiver.bbclass: Improve work-shared checking meta/classes/archiver.bbclass | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.42.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192174): https://lists.openembedded.org/g/openembedded-core/message/192174 Mute This Topic: https://lists.openembedded.org/mt/103110277/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 v3 0/1] nfs-utils: Upgrade 2.6.3 -> 2.6.4
From: Robert Yang
* V3:
Add the lost patch 0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch
* V2:
Fix build error with musl
* V1:
Initial version
The following changes since commit 564339afb73fc52a66c1a08437587cad1c4d46e7:
useradd: Fix useradd do_populate_sysroot dependency bug (2023-12-10 09:23:58
+)
are available in the Git repository at:
https://github.com/robertlinux/yocto rbt/upgrade
https://github.com/robertlinux/yocto/tree/rbt/upgrade
Robert Yang (1):
nfs-utils: Upgrade 2.6.3 -> 2.6.4
...event-and-libsqlite3-checked-when-nf.patch | 80 ---
...nclude-unistd.h-to-compile-with-musl.patch | 34
...{nfs-utils_2.6.3.bb => nfs-utils_2.6.4.bb} | 8 +-
3 files changed, 38 insertions(+), 84 deletions(-)
delete mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
create mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.3.bb =>
nfs-utils_2.6.4.bb} (94%)
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192171):
https://lists.openembedded.org/g/openembedded-core/message/192171
Mute This Topic: https://lists.openembedded.org/mt/103109786/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 v3 1/1] nfs-utils: Upgrade 2.6.3 -> 2.6.4
From: Robert Yang
* Remove backported patch
0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch.
* Add 0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch to fix build
with musl
Signed-off-by: Robert Yang
---
...event-and-libsqlite3-checked-when-nf.patch | 80 ---
...nclude-unistd.h-to-compile-with-musl.patch | 34
...{nfs-utils_2.6.3.bb => nfs-utils_2.6.4.bb} | 8 +-
3 files changed, 38 insertions(+), 84 deletions(-)
delete mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
create mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.3.bb =>
nfs-utils_2.6.4.bb} (94%)
diff --git
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
deleted file mode 100644
index 5afc714f190..000
---
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
+++ /dev/null
@@ -1,80 +0,0 @@
-From b62a3fe424026b73ec6b1934483b16863c7dff23 Mon Sep 17 00:00:00 2001
-From: Wiktor Jaskulski
-Date: Thu, 11 May 2023 15:28:23 -0400
-Subject: [PATCH] configure.ac: libevent and libsqlite3 checked when nfsv4 is
- disabled
-
-Upstream-Status: Backport
-(http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=bc4a5deef9f820c55fdac3c0070364c17cd91cca)
-
-Signed-off-by: Steve Dickson
-Signed-off-by: Trevor Gamblin
- configure.ac | 38 +++---
- 1 file changed, 15 insertions(+), 23 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 4ade528d..519cacbf 100644
a/configure.ac
-+++ b/configure.ac
-@@ -335,42 +335,34 @@ AC_CHECK_HEADER(rpc/rpc.h, ,
- AC_MSG_ERROR([Header file rpc/rpc.h not found - maybe try
building with --enable-tirpc]))
- CPPFLAGS="${nfsutils_save_CPPFLAGS}"
-
-+dnl check for libevent libraries and headers
-+AC_LIBEVENT
-+
-+dnl Check for sqlite3
-+AC_SQLITE3_VERS
-+
-+case $libsqlite3_cv_is_recent in
-+yes) ;;
-+unknown)
-+ dnl do not fail when cross-compiling
-+ AC_MSG_WARN([assuming sqlite is at least v3.3]) ;;
-+*)
-+ AC_MSG_ERROR([nfsdcld requires sqlite-devel]) ;;
-+esac
-+
- if test "$enable_nfsv4" = yes; then
-- dnl check for libevent libraries and headers
-- AC_LIBEVENT
-
- dnl check for the keyutils libraries and headers
- AC_KEYUTILS
-
-- dnl Check for sqlite3
-- AC_SQLITE3_VERS
--
- if test "$enable_nfsdcld" = "yes"; then
- AC_CHECK_HEADERS([libgen.h sys/inotify.h], ,
- AC_MSG_ERROR([Cannot find header needed for nfsdcld]))
--
--case $libsqlite3_cv_is_recent in
--yes) ;;
--unknown)
-- dnl do not fail when cross-compiling
-- AC_MSG_WARN([assuming sqlite is at least v3.3]) ;;
--*)
-- AC_MSG_ERROR([nfsdcld requires sqlite-devel]) ;;
--esac
- fi
-
- if test "$enable_nfsdcltrack" = "yes"; then
- AC_CHECK_HEADERS([libgen.h sys/inotify.h], ,
- AC_MSG_ERROR([Cannot find header needed for nfsdcltrack]))
--
--case $libsqlite3_cv_is_recent in
--yes) ;;
--unknown)
-- dnl do not fail when cross-compiling
-- AC_MSG_WARN([assuming sqlite is at least v3.3]) ;;
--*)
-- AC_MSG_ERROR([nfsdcltrack requires sqlite-devel]) ;;
--esac
- fi
-
- else
---
-2.41.0
-
diff --git
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch
new file mode 100644
index 000..8607b64cb1f
--- /dev/null
+++
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch
@@ -0,0 +1,34 @@
+From 45597a58e98f351b18db8444292b1cf6dd0cd810 Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Sat, 9 Dec 2023 23:34:08 -0800
+Subject: [PATCH] reexport.h: Include unistd.h to compile with musl
+
+Fixed error when compile with musl
+reexport.c: In function 'reexpdb_init':
+reexport.c:62:17: error: implicit declaration of function 'sleep'
[-Werror=implicit-function-declaration]
+ 62 | sleep(1);
+
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang
+---
+ support/reexport/reexport.h | 1 +
+ 1 files changed, 1 insertions(+)
+
+diff --git a/support/reexport/reexport.h b/support/reexport/reexport.h
+index 85fd59c..02f8684 100644
+--- a/support/reexport/reexport.h
b/support/reexport/reexport.h
+@@ -1,6 +1,8 @@
+ #ifndef REEXPORT_H
+ #define REEXPORT_H
+
++#include
++
+ #include "nfslib.h"
+
+ enum {
+--
+2.42.0
+
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.3.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.4.bb
Re: [OE-core] [PATCH v2 0/1] nfs-utils: Upgrade 2.6.3 -> 2.6.4
On 12/11/23 18:41, Robert Yang via lists.openembedded.org wrote:
From: Robert Yang
* V2:
Fix build error with musl
Sorry, please ignore V2, a patch was lost.
// Robert
* V1:
Initial version
The following changes since commit 564339afb73fc52a66c1a08437587cad1c4d46e7:
useradd: Fix useradd do_populate_sysroot dependency bug (2023-12-10 09:23:58
+)
are available in the Git repository at:
https://github.com/robertlinux/yocto rbt/upgrade
https://github.com/robertlinux/yocto/tree/rbt/upgrade
Robert Yang (1):
nfs-utils: Upgrade 2.6.3 -> 2.6.4
...event-and-libsqlite3-checked-when-nf.patch | 80 ---
...{nfs-utils_2.6.3.bb => nfs-utils_2.6.4.bb} | 3 +-
2 files changed, 1 insertion(+), 82 deletions(-)
delete mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.3.bb =>
nfs-utils_2.6.4.bb} (97%)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192170):
https://lists.openembedded.org/g/openembedded-core/message/192170
Mute This Topic: https://lists.openembedded.org/mt/103106403/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 1/1] linux-yocto-rt/5.4: fix buld failure
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/5.4:
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfi...@gmail.com
Subject: rt: drop -stable migrate_disable
Date: Mon, 11 Dec 2023 08:50:52 -0500
The -rt branches already have a migrate disable mechanism, we
drop the -stable version to fix build issues.
Signed-off-by: Bruce Ashfield
]
Signed-off-by: Bruce Ashfield
---
.../linux/linux-yocto-rt_5.4.bb | 4 ++--
.../linux/linux-yocto-tiny_5.4.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto_5.4.bb | 20 +--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
index 396d218afd9..58e10be524a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
@@ -11,8 +11,8 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "9ef07d0d41fa14bf7366dfe5ef657d9f24b35349"
-SRCREV_meta ?= "9f1a56eeea58f7d9b597f0ea33e43e35b8288762"
+SRCREV_machine ?= "43d5f7eb85acc21ec87ec45b2cae127dad8bf7a4"
+SRCREV_meta ?= "34f54c16ac6ef29441f95dd3b932729f01008999"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
index 1048af2f790..01894be10cf 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
@@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine_qemuarm ?= "73dbd7ea55670218b017d9719868e7d61d0b1011"
-SRCREV_machine ?= "0b41bdd8d544c72af97c34e9c464b7534fd18c7a"
-SRCREV_meta ?= "9f1a56eeea58f7d9b597f0ea33e43e35b8288762"
+SRCREV_machine_qemuarm ?= "7c33fa232f43e9059395bd30e23ef3c16359ba11"
+SRCREV_machine ?= "42abef1facd8bc8d1f51470493f08d87d0862f8e"
+SRCREV_meta ?= "34f54c16ac6ef29441f95dd3b932729f01008999"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.4.bb
b/meta/recipes-kernel/linux/linux-yocto_5.4.bb
index e932394c90c..e8d935edea8 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.4.bb
@@ -13,16 +13,16 @@ KBRANCH_qemux86 ?= "v5.4/standard/base"
KBRANCH_qemux86-64 ?= "v5.4/standard/base"
KBRANCH_qemumips64 ?= "v5.4/standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "62367606f47fb5832c10c3d5ea370f9d162504a0"
-SRCREV_machine_qemuarm64 ?= "dbcb9a6b795e82a7869f213ce4a7d30779cc0b5c"
-SRCREV_machine_qemumips ?= "0386462f3785de758d8c333ddfa9b3a7ce26e048"
-SRCREV_machine_qemuppc ?= "4bc83a0d08c8ca1fba167dff9dc652055626837c"
-SRCREV_machine_qemuriscv64 ?= "4d141be8fd148e0ea68d8f957f527ad5f22015ab"
-SRCREV_machine_qemux86 ?= "4d141be8fd148e0ea68d8f957f527ad5f22015ab"
-SRCREV_machine_qemux86-64 ?= "4d141be8fd148e0ea68d8f957f527ad5f22015ab"
-SRCREV_machine_qemumips64 ?= "c60dba46dca65775a5d5bfe0e41b0eb5f55a3ba7"
-SRCREV_machine ?= "4d141be8fd148e0ea68d8f957f527ad5f22015ab"
-SRCREV_meta ?= "9f1a56eeea58f7d9b597f0ea33e43e35b8288762"
+SRCREV_machine_qemuarm ?= "76b8ef2c7ecb7cf484e0eff4d509ec57c310d06e"
+SRCREV_machine_qemuarm64 ?= "23b9912a979d98708f3adc8312af42eb9049c1d6"
+SRCREV_machine_qemumips ?= "2e266704c46066c80821a491ad6f42c930e00d5d"
+SRCREV_machine_qemuppc ?= "2343a888a77678d4440032d22327f753d1a90cdb"
+SRCREV_machine_qemuriscv64 ?= "dbf9e2bf8e764643b8ec4c236fbab73228413a33"
+SRCREV_machine_qemux86 ?= "dbf9e2bf8e764643b8ec4c236fbab73228413a33"
+SRCREV_machine_qemux86-64 ?= "dbf9e2bf8e764643b8ec4c236fbab73228413a33"
+SRCREV_machine_qemumips64 ?= "73d9e7eaf1161e5deb6d3fbfdefb07fc5fd87d3f"
+SRCREV_machine ?= "dbf9e2bf8e764643b8ec4c236fbab73228413a33"
+SRCREV_meta ?= "34f54c16ac6ef29441f95dd3b932729f01008999"
# remap qemuarm to qemuarma15 for the 5.4 kernel
# KMACHINE_qemuarm ?= "qemuarma15"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192169):
https://lists.openembedded.org/g/openembedded-core/message/192169
Mute This Topic: https://lists.openembedded.org/mt/103109346/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [qa-build-notification] [yocto] QA notification for completed autobuilder build (yocto-3.1.30.rc1)
On Sun, Dec 10, 2023 at 11:43 PM Jing Hui Tham wrote: > > Hi all, > > Intel and WR YP QA is planning for QA execution for YP build > yocto-3.1.30.rc1. We are planning to execute following tests for this cycle: > > OEQA-manual tests for following module: > 1. OE-Core > 2. BSP-hw > > Runtime auto test for following platforms: > 1. MinnowBoard Turbot - 32bit > 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) > 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) > 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) > 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) > 6. Edgerouter > 7. Beaglebone > > > ETA for completion Friday, December 15. Unfortunately an issue has been reported with linux-yocto-rt: https://lists.openembedded.org/g/openembedded-core/message/191857 So it will be necessary to do a 3.1.30-rc2 build to fix this issue. Sorry for the false start! Steve > > -Original Message- > > From: yo...@lists.yoctoproject.org On Behalf > > Of Pokybuild User > > Sent: Monday, December 11, 2023 1:24 PM > > To: yo...@lists.yoctoproject.org > > Cc: qa-build-notificat...@lists.yoctoproject.org > > Subject: [yocto] QA notification for completed autobuilder build (yocto- > > 3.1.30.rc1) > > > > > > A build flagged for QA (yocto-3.1.30.rc1) was completed on the autobuilder > > and is available at: > > > > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.30.rc1 > > > > > > Build URL: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6316 > > > > Build hash information: > > > > bitbake: c0d60794a32e3f8bbfbbd6800d87ef2782aacf2c > > meta-agl: 512d244d48ba0d33f609f425a6e8a907b178cdac > > meta-arm: b75b8ce1ac10dc3521c0f710a4cf79bc7e985cfd > > meta-aws: f3ba81625dac2e5c009e73ad78fec23b1261bd02 > > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > > meta-intel: e482213f37828216c7a7df68ff353652cc865ec1 > > meta-mingw: 7bdc58e6c5d1054b1b6ad5c4e480a95e995ccbae > > meta-openembedded: 9135c7ea7350d5d241f4afc3b28087122ebe2d19 > > meta-virtualization: 35c723774ee06b3c1831f00a2cbf25cbeae132e1 > > oecore: 7e65b351fa8eda4ee7b9f1f2a8dbfe14e0ef697a > > poky: bf9eabafc257a7d3c39e3b4a46cabf7e6fb8270e > > > > > > > > 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 (#61855): https://lists.yoctoproject.org/g/yocto/message/61855 Mute This Topic: https://lists.yoctoproject.org/mt/103108913/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] go: set vendor in CVE_PRODUCT
From: Ross Burton
It's not uncommon for specific third party modules to use "go" as the
product[1]. However, the canonical CPE for the official Go
language/runtime is always golang:go[2], so use that explicitly.
[1] e.g. https://nvd.nist.gov/vuln/detail/CVE-2023-49292
[2] e.g. https://nvd.nist.gov/vuln/detail/CVE-2023-39320
Signed-off-by: Ross Burton
---
meta/recipes-devtools/go/go-binary-native_1.20.12.bb | 2 +-
meta/recipes-devtools/go/go-common.inc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/go/go-binary-native_1.20.12.bb
b/meta/recipes-devtools/go/go-binary-native_1.20.12.bb
index e555412a19c..41db2ada808 100644
--- a/meta/recipes-devtools/go/go-binary-native_1.20.12.bb
+++ b/meta/recipes-devtools/go/go-binary-native_1.20.12.bb
@@ -16,7 +16,7 @@ SRC_URI[go_linux_ppc64le.sha256sum] =
"2ae0ec3736216dfbd7b01ff679842dc1bed365e53
UPSTREAM_CHECK_URI = "https://golang.org/dl/;
UPSTREAM_CHECK_REGEX = "go(?P\d+(\.\d+)+)\.linux"
-CVE_PRODUCT = "go"
+CVE_PRODUCT = "golang:go"
S = "${WORKDIR}/go"
diff --git a/meta/recipes-devtools/go/go-common.inc
b/meta/recipes-devtools/go/go-common.inc
index 96e32eeb978..db165792dcb 100644
--- a/meta/recipes-devtools/go/go-common.inc
+++ b/meta/recipes-devtools/go/go-common.inc
@@ -20,7 +20,7 @@ B = "${S}"
UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)\.src\.tar"
# all recipe variants are created from the same product
-CVE_PRODUCT = "go"
+CVE_PRODUCT = "golang:go"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
SSTATE_SCAN_CMD = "true"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192167):
https://lists.openembedded.org/g/openembedded-core/message/192167
Mute This Topic: https://lists.openembedded.org/mt/103108623/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] oeqa/selftest/recipetool: add back checksum checks on pypi tests
recipetool pypi plugin was originally clobbering SRC_URI checksums.
Now it doesn't do this anymore:
78ef0313ee6 - recipetool: pypi: do not clobber SRC_URI checksums
so add back the checksum checks on pypi tests.
Also this commit restrict the checksums:
45d2f8d4bc2 - recipetool: create: Only include the expected SRC_URI checksums
so add only the needed ones.
Signed-off-by: Julien Stephan
---
meta/lib/oeqa/selftest/cases/recipetool.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py
b/meta/lib/oeqa/selftest/cases/recipetool.py
index d10d61bc5b0..233912b4c4d 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -487,6 +487,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars = {}
checkvars['LICENSE'] = set(['MIT'])
checkvars['LIC_FILES_CHKSUM'] =
'file://LICENSE;md5=16a934f165e8c3245f241e77d401bb88'
+checkvars['SRC_URI[sha256sum]'] =
'f3765c0f582d2dfc72c15f3b5a82aecfae9498bd29ca840d72f37d7bd38bfcd5'
checkvars['PYPI_PACKAGE'] = pn
inherits = ['setuptools3', 'pypi']
self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -508,6 +509,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars = {}
checkvars['LICENSE'] = set(['MIT'])
checkvars['LIC_FILES_CHKSUM'] =
'file://LICENSE;md5=16a934f165e8c3245f241e77d401bb88'
+checkvars['SRC_URI[sha256sum]'] =
'f3765c0f582d2dfc72c15f3b5a82aecfae9498bd29ca840d72f37d7bd38bfcd5'
checkvars['PYPI_PACKAGE'] = pn
inherits = ['setuptools3', "pypi"]
self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -521,6 +523,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars = {}
checkvars['LICENSE'] = set(['MIT'])
checkvars['LIC_FILES_CHKSUM'] =
'file://LICENSE;md5=16a934f165e8c3245f241e77d401bb88'
+checkvars['SRC_URI[sha256sum]'] =
'f3765c0f582d2dfc72c15f3b5a82aecfae9498bd29ca840d72f37d7bd38bfcd5'
checkvars['PYPI_PACKAGE'] = pn
inherits = ['setuptools3', "pypi"]
self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -543,7 +546,7 @@ class RecipetoolCreateTests(RecipetoolBase):
latest_pv = match.group(1)
self.assertTrue(latest_pv != pv)
recipefile = os.path.join(temprecipe, '%s_%s.bb' % (pn, latest_pv))
-# Do not check LIC_FILES_CHKSUM here to avoid having updating the test
on each release
+# Do not check LIC_FILES_CHKSUM and SRC_URI checksum here to avoid
having updating the test on each release
checkvars = {}
checkvars['LICENSE'] = set(['MIT'])
checkvars['PYPI_PACKAGE'] = pn
@@ -574,6 +577,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars['SUMMARY'] = 'A library for working with the color formats
defined by HTML and CSS.'
checkvars['LICENSE'] = set(['BSD-3-Clause'])
checkvars['LIC_FILES_CHKSUM'] =
'file://LICENSE;md5=702b1ef12cf66832a88f24c8f2ee9c19'
+checkvars['SRC_URI[sha256sum]'] =
'c225b674c83fa923be93d235330ce0300373d02885cef23238813b0d5668304a'
inherits = ['python_setuptools_build_meta', 'pypi']
self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -602,6 +606,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars['SUMMARY'] = 'Simple module to parse ISO 8601 dates'
checkvars['LICENSE'] = set(['MIT'])
checkvars['LIC_FILES_CHKSUM'] =
'file://LICENSE;md5=aab31f2ef7ba214a5a341eaa47a7f367'
+checkvars['SRC_URI[sha256sum]'] =
'6b1d3829ee8921c4301998c909f7829fa9ed3cbdac0d3b16af2d743aed1ba8df'
inherits = ['python_poetry_core', 'pypi']
self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -630,6 +635,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars['SUMMARY'] = 'Backported and Experimental Type Hints for
Python 3.8+'
checkvars['LICENSE'] = set(['PSF-2.0'])
checkvars['LIC_FILES_CHKSUM'] =
'file://LICENSE;md5=fcf6b249c2641540219a727f35d8d2c2'
+checkvars['SRC_URI[sha256sum]'] =
'df8e4339e9cb77357558cbdbceca33c303714cf861d1eef15e1070055ae8b7ef'
inherits = ['python_flit_core', 'pypi']
self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -659,6 +665,7 @@ class RecipetoolCreateTests(RecipetoolBase):
checkvars['HOMEPAGE'] =
'https://github.com/python-jsonschema/jsonschema'
checkvars['LICENSE'] = set(['MIT'])
checkvars['LIC_FILES_CHKSUM'] =
'file://COPYING;md5=7a60a81c146ec25599a3e1dabb8610a8
file://json/LICENSE;md5=9d4de43111d33570c8fe49b4cb0e01af'
+checkvars['SRC_URI[sha256sum]'] =
'ec84cc37cfa703ef7cd4928db24f9cb31428a5d0fa77747b8b51a847458e0bbf'
inherits = ['python_hatchling', 'pypi']
self._test_recipe_contents(recipefile, checkvars, inherits)
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links:
Re: [OE-Core][PATCH 3/7] rust: Upgrade 1.71.0 -> 1.71.1
On Mon, 11 Dec 2023 at 12:44, Alex Kiernan wrote:
> On Mon, Dec 11, 2023 at 10:01 AM Frédéric Martinsons
> wrote:
> >
> >
> >
> > On Mon, 11 Dec 2023 at 10:17, Alex Kiernan
> wrote:
> >>
> >> On Mon, Dec 11, 2023 at 7:15 AM Frédéric Martinsons
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Sun, 10 Dec 2023 at 21:28, Alex Kiernan
> wrote:
> >> >>
> >> >> On Sun, Dec 10, 2023 at 7:39 PM Richard Purdie
> >> >> wrote:
> >> >> >
> >> >> > On Fri, 2023-12-08 at 14:03 +, Alex Kiernan wrote:
> >> >> > > https://blog.rust-lang.org/2023/08/03/Rust-1.71.1.html
> >> >> > >
> >> >> > > Signed-off-by: Alex Kiernan
> >> >> > > ---
> >> >> > >
> >> >> > > meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb}
> | 0
> >> >> > > .../rust/{libstd-rs_1.71.0.bb => libstd-rs_1.71.1.bb}
> | 0
> >> >> > > ...t-cross-canadian_1.71.0.bb => rust-cross-canadian_1.71.1.bb}
> | 0
> >> >> > > .../rust/{rust-llvm_1.71.0.bb => rust-llvm_1.71.1.bb}
> | 0
> >> >> > > meta/recipes-devtools/rust/rust-source.inc
> | 2 +-
> >> >> > > meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb}
> | 0
> >> >> > > 6 files changed, 1 insertion(+), 1 deletion(-)
> >> >> > > rename meta/recipes-devtools/rust/{cargo_1.71.0.bb =>
> cargo_1.71.1.bb} (100%)
> >> >> > > rename meta/recipes-devtools/rust/{libstd-rs_1.71.0.bb =>
> libstd-rs_1.71.1.bb} (100%)
> >> >> > > rename meta/recipes-devtools/rust/{
> rust-cross-canadian_1.71.0.bb => rust-cross-canadian_1.71.1.bb} (100%)
> >> >> > > rename meta/recipes-devtools/rust/{rust-llvm_1.71.0.bb =>
> rust-llvm_1.71.1.bb} (100%)
> >> >> > > rename meta/recipes-devtools/rust/{rust_1.71.0.bb =>
> rust_1.71.1.bb} (100%)
> >> >> > >
> >> >> > > diff --git a/meta/recipes-devtools/rust/cargo_1.71.0.bb
> b/meta/recipes-devtools/rust/cargo_1.71.1.bb
> >> >> > > similarity index 100%
> >> >> > > rename from meta/recipes-devtools/rust/cargo_1.71.0.bb
> >> >> > > rename to meta/recipes-devtools/rust/cargo_1.71.1.bb
> >> >> > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
> b/meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
> >> >> > > similarity index 100%
> >> >> > > rename from meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
> >> >> > > rename to meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
> >> >> > > diff --git a/meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.0.bb b/meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.1.bb
> >> >> > > similarity index 100%
> >> >> > > rename from meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.0.bb
> >> >> > > rename to meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.1.bb
> >> >> > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
> b/meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
> >> >> > > similarity index 100%
> >> >> > > rename from meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
> >> >> > > rename to meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
> >> >> > > diff --git a/meta/recipes-devtools/rust/rust-source.inc
> b/meta/recipes-devtools/rust/rust-source.inc
> >> >> > > index 3a192e42db7d..0729db6f0b45 100644
> >> >> > > --- a/meta/recipes-devtools/rust/rust-source.inc
> >> >> > > +++ b/meta/recipes-devtools/rust/rust-source.inc
> >> >> > > @@ -7,7 +7,7 @@ SRC_URI += "
> https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> >> >> > > file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
> >> >> > >
> file://0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch;patchdir=${RUSTSRC}
> \
> >> >> > > "
> >> >> > > -SRC_URI[rust.sha256sum] =
> "5814699031aafdcc2e2f71fc9b389678cd7042350d1583da061463d8e88681c7"
> >> >> > > +SRC_URI[rust.sha256sum] =
> "371af0fbe04051e20a74dbea6d4e4e548f10f15309c49cae2688afb882b6c7f1"
> >> >> > >
> >> >> > > RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
> >> >> > >
> >> >> > > diff --git a/meta/recipes-devtools/rust/rust_1.71.0.bb
> b/meta/recipes-devtools/rust/rust_1.71.1.bb
> >> >> > > similarity index 100%
> >> >> > > rename from meta/recipes-devtools/rust/rust_1.71.0.bb
> >> >> > > rename to meta/recipes-devtools/rust/rust_1.71.1.bb
> >> >> >
> >> >> > I ran some testing and it looks like we could merge up to 1.71.1
> >> >> > without autobuilder failures in this series. Beyond that we have
> the
> >> >> > reproducibility and zvariant issues.
> >> >> >
> >> >>
> >> >> Thanks.
> >> >>
> >> >> Was the failure at that point reproducibility or the zvariant trait
> >> >> failure? I just posted an update for zvariant which doesn't see the
> >> >> trait recursion failure, but at the same time it no longer exercises
> >> >> crates pulled from git which looked like it was the main purpose it
> >> >> was fulfilling for testing.
> >> >>
> >> > I didn't follow issues about this upgrade, but yes, the zvariant
> recipe
> >> > was a demonstration on how to handle crates dependencies that come
> from git.
> >> > (there is a specific crate fetcher url parameter: 'git-dependency')
> >> >
> >>
> >> 3.12 (which was what we had) exploded with unbounded
[OE-core] [kirkstone][PATCH] nativesdk-sdk-provides-dummy.bb: Update host tools for rust-cross-canadian
From: Deepthi Hemraj [YOCTO #15082] Packagegroup-rust-cross-canadian package requires rust-cross-canadian, but the necessary libstdc++.so.6(GLIBCXX_3.4.30)(64bit) library is missing. The fix adds the libstdc++.so.6(GLIBCXX_3.4.30)(64bit) library requirement to the SDK dummy package, resolving the dependency conflict. Signed-off-by: Deepthi Hemraj --- meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb index 1d71f373a4..dc3ae1edaf 100644 --- a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb +++ b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb @@ -10,7 +10,8 @@ DUMMYPROVIDES = "\ /usr/bin/env \ libGL.so()(64bit) \ libGL.so \ -" +libstdc++.so.6(GLIBCXX_3.4.30)(64bit) \ +" require dummy-sdk-package.inc -- 2.42.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192164): https://lists.openembedded.org/g/openembedded-core/message/192164 Mute This Topic: https://lists.openembedded.org/mt/103107487/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 3/7] rust: Upgrade 1.71.0 -> 1.71.1
On Mon, Dec 11, 2023 at 10:01 AM Frédéric Martinsons
wrote:
>
>
>
> On Mon, 11 Dec 2023 at 10:17, Alex Kiernan wrote:
>>
>> On Mon, Dec 11, 2023 at 7:15 AM Frédéric Martinsons
>> wrote:
>> >
>> >
>> >
>> > On Sun, 10 Dec 2023 at 21:28, Alex Kiernan wrote:
>> >>
>> >> On Sun, Dec 10, 2023 at 7:39 PM Richard Purdie
>> >> wrote:
>> >> >
>> >> > On Fri, 2023-12-08 at 14:03 +, Alex Kiernan wrote:
>> >> > > https://blog.rust-lang.org/2023/08/03/Rust-1.71.1.html
>> >> > >
>> >> > > Signed-off-by: Alex Kiernan
>> >> > > ---
>> >> > >
>> >> > > meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb} | 0
>> >> > > .../rust/{libstd-rs_1.71.0.bb => libstd-rs_1.71.1.bb} | 0
>> >> > > ...t-cross-canadian_1.71.0.bb => rust-cross-canadian_1.71.1.bb} | 0
>> >> > > .../rust/{rust-llvm_1.71.0.bb => rust-llvm_1.71.1.bb} | 0
>> >> > > meta/recipes-devtools/rust/rust-source.inc | 2
>> >> > > +-
>> >> > > meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb} | 0
>> >> > > 6 files changed, 1 insertion(+), 1 deletion(-)
>> >> > > rename meta/recipes-devtools/rust/{cargo_1.71.0.bb =>
>> >> > > cargo_1.71.1.bb} (100%)
>> >> > > rename meta/recipes-devtools/rust/{libstd-rs_1.71.0.bb =>
>> >> > > libstd-rs_1.71.1.bb} (100%)
>> >> > > rename meta/recipes-devtools/rust/{rust-cross-canadian_1.71.0.bb =>
>> >> > > rust-cross-canadian_1.71.1.bb} (100%)
>> >> > > rename meta/recipes-devtools/rust/{rust-llvm_1.71.0.bb =>
>> >> > > rust-llvm_1.71.1.bb} (100%)
>> >> > > rename meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb}
>> >> > > (100%)
>> >> > >
>> >> > > diff --git a/meta/recipes-devtools/rust/cargo_1.71.0.bb
>> >> > > b/meta/recipes-devtools/rust/cargo_1.71.1.bb
>> >> > > similarity index 100%
>> >> > > rename from meta/recipes-devtools/rust/cargo_1.71.0.bb
>> >> > > rename to meta/recipes-devtools/rust/cargo_1.71.1.bb
>> >> > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
>> >> > > b/meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
>> >> > > similarity index 100%
>> >> > > rename from meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
>> >> > > rename to meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
>> >> > > diff --git a/meta/recipes-devtools/rust/rust-cross-canadian_1.71.0.bb
>> >> > > b/meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
>> >> > > similarity index 100%
>> >> > > rename from meta/recipes-devtools/rust/rust-cross-canadian_1.71.0.bb
>> >> > > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
>> >> > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
>> >> > > b/meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
>> >> > > similarity index 100%
>> >> > > rename from meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
>> >> > > rename to meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
>> >> > > diff --git a/meta/recipes-devtools/rust/rust-source.inc
>> >> > > b/meta/recipes-devtools/rust/rust-source.inc
>> >> > > index 3a192e42db7d..0729db6f0b45 100644
>> >> > > --- a/meta/recipes-devtools/rust/rust-source.inc
>> >> > > +++ b/meta/recipes-devtools/rust/rust-source.inc
>> >> > > @@ -7,7 +7,7 @@ SRC_URI +=
>> >> > > "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
>> >> > > file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
>> >> > >
>> >> > > file://0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch;patchdir=${RUSTSRC}
>> >> > > \
>> >> > > "
>> >> > > -SRC_URI[rust.sha256sum] =
>> >> > > "5814699031aafdcc2e2f71fc9b389678cd7042350d1583da061463d8e88681c7"
>> >> > > +SRC_URI[rust.sha256sum] =
>> >> > > "371af0fbe04051e20a74dbea6d4e4e548f10f15309c49cae2688afb882b6c7f1"
>> >> > >
>> >> > > RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
>> >> > >
>> >> > > diff --git a/meta/recipes-devtools/rust/rust_1.71.0.bb
>> >> > > b/meta/recipes-devtools/rust/rust_1.71.1.bb
>> >> > > similarity index 100%
>> >> > > rename from meta/recipes-devtools/rust/rust_1.71.0.bb
>> >> > > rename to meta/recipes-devtools/rust/rust_1.71.1.bb
>> >> >
>> >> > I ran some testing and it looks like we could merge up to 1.71.1
>> >> > without autobuilder failures in this series. Beyond that we have the
>> >> > reproducibility and zvariant issues.
>> >> >
>> >>
>> >> Thanks.
>> >>
>> >> Was the failure at that point reproducibility or the zvariant trait
>> >> failure? I just posted an update for zvariant which doesn't see the
>> >> trait recursion failure, but at the same time it no longer exercises
>> >> crates pulled from git which looked like it was the main purpose it
>> >> was fulfilling for testing.
>> >>
>> > I didn't follow issues about this upgrade, but yes, the zvariant recipe
>> > was a demonstration on how to handle crates dependencies that come from
>> > git.
>> > (there is a specific crate fetcher url parameter: 'git-dependency')
>> >
>>
>> 3.12 (which was what we had) exploded with unbounded recursion inside
>> a trait on later compilers, upgrading
Re: [PATCH] [OE-Core] tzdata: only the timezone subpackage tzdata-core is retained
Please follow
https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#fixing-your-from-identity
On 11/12/2023 11:39:27+0800, Xu, Lizhi via lists.openembedded.org wrote:
> To reduce the size of rootfs, the subpackages contained in tzdata.bb will now
> default to only retaining tzdata-core.
>
> tzdata.bb by default pulls in all possible timezone data packages which
> increases
> size of the final root filesystem considerably.
> The customer would like to have extra timezones configurable so that only
> tzdata-core is chosen by default and rest of the zones are optional.
>
> Signed-off-by: Lizhi Xu
> ---
> meta/recipes-extended/timezone/tzdata.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/timezone/tzdata.bb
> b/meta/recipes-extended/timezone/tzdata.bb
> index dd1960ffa7..7b1d4fd460 100644
> --- a/meta/recipes-extended/timezone/tzdata.bb
> +++ b/meta/recipes-extended/timezone/tzdata.bb
> @@ -201,4 +201,4 @@ CONFFILES:tzdata-core = "${sysconfdir}/localtime
> ${sysconfdir}/timezone"
>
> ALLOW_EMPTY:${PN} = "1"
>
> -RDEPENDS:${PN} = "${TZ_PACKAGES}"
> +RDEPENDS:${PN} = "tzdata-core"
> --
> 2.43.0
>
>
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192162):
https://lists.openembedded.org/g/openembedded-core/message/192162
Mute This Topic: https://lists.openembedded.org/mt/103102817/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 1/2] cargo-update-recipe-crates: Use CARGO_LOCK_PATH
On Mon, Dec 11, 2023 at 9:43 AM Alex Kiernan wrote:
>
> On Mon, Dec 11, 2023 at 9:28 AM Alexander Kanavin
> wrote:
> >
> > On Mon, 11 Dec 2023 at 10:09, Alex Kiernan wrote:
> > > In a single project there are (potentially) multiple Cargo.toml, but
> > > just one Cargo.lock. If there's multiple Cargo.lock files in a repo,
> > > that implies multiple projects which I don't think we've any way of
> > > building from a single recipe.
> >
> > I'm thinking of projects like librsvg, python3-bcrypt or
> > python3-cryptography where the build is orchestrated by meson,
> > autoconf or setuptools, and where we don't run cargo directly and
> > leave it to those tools. They may have single Cargo.lock now, but will
> > that hold? Also, that Cargo.lock is not necessarily in the root of
> > ${S}, so you'd have to set the location manually, instead of not
> > having to worry about it. Is CARGO_LOCK_PATH or its parent variables
> > already set correctly for all of them? I see this is not done from
> > python3-cryptography; shouldn't the build error out, if
> > cargo_common_do_patch_paths requires the location? Something doesn't
> > compute fully here.
> >
>
> That's exactly the one I was going to look at next, as I agree
> something doesn't add up there.
>
cargo_common_do_patch_paths isn't in the call graph for
python3-cryptography, it gets patched in like this:
do_configure[postfuncs] += "cargo_common_do_patch_paths"
I'm unclear why that doesn't execute, I'm wondering if its related to
the autogenerated do_configure and this is a usage that just doesn't
work?
# line: 1, file: autogenerated
do_configure() {
setup_target_config
python_setuptools3_rust_do_configure
}
However even if it was in the call graph, we wouldn't have errored in
it as there's no patches to apply to the cargo config as the crates
are all satisfied from the vendored sources we deliver.
It does feel like we're missing a piece in our python/rust integration
since if you did have a crate delivered from git then we wouldn't
patch up the cargo config correctly and I guess end up erroring out.
--
Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192161):
https://lists.openembedded.org/g/openembedded-core/message/192161
Mute This Topic: https://lists.openembedded.org/mt/103094777/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 v2 1/1] nfs-utils: Upgrade 2.6.3 -> 2.6.4
From: Robert Yang
Remove backported patch
0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch.
Signed-off-by: Robert Yang
---
...event-and-libsqlite3-checked-when-nf.patch | 80 ---
...{nfs-utils_2.6.3.bb => nfs-utils_2.6.4.bb} | 3 +-
2 files changed, 1 insertion(+), 82 deletions(-)
delete mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.3.bb =>
nfs-utils_2.6.4.bb} (97%)
diff --git
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
deleted file mode 100644
index 5afc714f190..000
---
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
+++ /dev/null
@@ -1,80 +0,0 @@
-From b62a3fe424026b73ec6b1934483b16863c7dff23 Mon Sep 17 00:00:00 2001
-From: Wiktor Jaskulski
-Date: Thu, 11 May 2023 15:28:23 -0400
-Subject: [PATCH] configure.ac: libevent and libsqlite3 checked when nfsv4 is
- disabled
-
-Upstream-Status: Backport
-(http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=bc4a5deef9f820c55fdac3c0070364c17cd91cca)
-
-Signed-off-by: Steve Dickson
-Signed-off-by: Trevor Gamblin
- configure.ac | 38 +++---
- 1 file changed, 15 insertions(+), 23 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 4ade528d..519cacbf 100644
a/configure.ac
-+++ b/configure.ac
-@@ -335,42 +335,34 @@ AC_CHECK_HEADER(rpc/rpc.h, ,
- AC_MSG_ERROR([Header file rpc/rpc.h not found - maybe try
building with --enable-tirpc]))
- CPPFLAGS="${nfsutils_save_CPPFLAGS}"
-
-+dnl check for libevent libraries and headers
-+AC_LIBEVENT
-+
-+dnl Check for sqlite3
-+AC_SQLITE3_VERS
-+
-+case $libsqlite3_cv_is_recent in
-+yes) ;;
-+unknown)
-+ dnl do not fail when cross-compiling
-+ AC_MSG_WARN([assuming sqlite is at least v3.3]) ;;
-+*)
-+ AC_MSG_ERROR([nfsdcld requires sqlite-devel]) ;;
-+esac
-+
- if test "$enable_nfsv4" = yes; then
-- dnl check for libevent libraries and headers
-- AC_LIBEVENT
-
- dnl check for the keyutils libraries and headers
- AC_KEYUTILS
-
-- dnl Check for sqlite3
-- AC_SQLITE3_VERS
--
- if test "$enable_nfsdcld" = "yes"; then
- AC_CHECK_HEADERS([libgen.h sys/inotify.h], ,
- AC_MSG_ERROR([Cannot find header needed for nfsdcld]))
--
--case $libsqlite3_cv_is_recent in
--yes) ;;
--unknown)
-- dnl do not fail when cross-compiling
-- AC_MSG_WARN([assuming sqlite is at least v3.3]) ;;
--*)
-- AC_MSG_ERROR([nfsdcld requires sqlite-devel]) ;;
--esac
- fi
-
- if test "$enable_nfsdcltrack" = "yes"; then
- AC_CHECK_HEADERS([libgen.h sys/inotify.h], ,
- AC_MSG_ERROR([Cannot find header needed for nfsdcltrack]))
--
--case $libsqlite3_cv_is_recent in
--yes) ;;
--unknown)
-- dnl do not fail when cross-compiling
-- AC_MSG_WARN([assuming sqlite is at least v3.3]) ;;
--*)
-- AC_MSG_ERROR([nfsdcltrack requires sqlite-devel]) ;;
--esac
- fi
-
- else
---
-2.41.0
-
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.3.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.4.bb
similarity index 97%
rename from meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.3.bb
rename to meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.4.bb
index 35cf6af6d46..31290f6d44c 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.3.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.4.bb
@@ -30,11 +30,10 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://bugfix-adjust-statd-service-name.patch \
file://0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch \
file://clang-warnings.patch \
-
file://0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch \
file://0001-locktest-Makefile.am-Do-not-use-build-flags.patch \
file://0001-tools-locktest-Use-intmax_t-to-print-off_t.patch \
"
-SRC_URI[sha256sum] =
"38d89e853a71d3c560ff026af3d969d75e24f782ff68324e76261fe0344459e1"
+SRC_URI[sha256sum] =
"01b3b0fb9c7d0bbabf5114c736542030748c788ec2fd9734744201e9b0a1119d"
# Only kernel-module-nfsd is required here (but can be built-in) - the nfsd
module will
# pull in the remainder of the dependencies.
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192160):
https://lists.openembedded.org/g/openembedded-core/message/192160
Mute This Topic: https://lists.openembedded.org/mt/103106404/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[OE-core] [PATCH v2 0/1] nfs-utils: Upgrade 2.6.3 -> 2.6.4
From: Robert Yang
* V2:
Fix build error with musl
* V1:
Initial version
The following changes since commit 564339afb73fc52a66c1a08437587cad1c4d46e7:
useradd: Fix useradd do_populate_sysroot dependency bug (2023-12-10 09:23:58
+)
are available in the Git repository at:
https://github.com/robertlinux/yocto rbt/upgrade
https://github.com/robertlinux/yocto/tree/rbt/upgrade
Robert Yang (1):
nfs-utils: Upgrade 2.6.3 -> 2.6.4
...event-and-libsqlite3-checked-when-nf.patch | 80 ---
...{nfs-utils_2.6.3.bb => nfs-utils_2.6.4.bb} | 3 +-
2 files changed, 1 insertion(+), 82 deletions(-)
delete mode 100644
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.3.bb =>
nfs-utils_2.6.4.bb} (97%)
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192159):
https://lists.openembedded.org/g/openembedded-core/message/192159
Mute This Topic: https://lists.openembedded.org/mt/103106403/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 v2 1/1] go: ignore CVE-2023-45283 and CVE-2023-45284
Hi Alexandre, I see that current go version is 1.20.12 which is not vulnerable to these CVEs. Kindly ignore this patch. Regards, Soumya From: Alexandre Belloni Sent: Saturday, December 9, 2023 5:55 PM To: Sambu, Soumya Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core][PATCH v2 1/1] go: ignore CVE-2023-45283 and CVE-2023-45284 CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, We had go upgrades in between, can you rebase (and check if this is still needed)? On 08/12/2023 10:42:15+, Soumya via lists.openembedded.org wrote: > From: Soumya Sambu > > These CVEs affect path handling on Windows. > > References: > https://nvd.nist.gov/vuln/detail/CVE-2023-45283 > https://nvd.nist.gov/vuln/detail/CVE-2023-45284 > > Signed-off-by: Soumya Sambu > --- > meta/recipes-devtools/go/go-1.20.10.inc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/meta/recipes-devtools/go/go-1.20.10.inc > b/meta/recipes-devtools/go/go-1.20.10.inc > index 39509ed986..0c0a736084 100644 > --- a/meta/recipes-devtools/go/go-1.20.10.inc > +++ b/meta/recipes-devtools/go/go-1.20.10.inc > @@ -16,3 +16,6 @@ SRC_URI += "\ > file://0009-go-Filter-build-paths-on-staticly-linked-arches.patch \ > " > SRC_URI[main.sha256sum] = > "72d2f51805c47150066c103754c75fddb2c19d48c9219fa33d1e46696c841dbb" > + > +CVE_STATUS[CVE-2023-45283] = "not-applicable-platform: Issue only applies on > Windows" > +CVE_STATUS[CVE-2023-45284] = "not-applicable-platform: Issue only applies on > Windows" > -- > 2.40.0 > > > > -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192158): https://lists.openembedded.org/g/openembedded-core/message/192158 Mute This Topic: https://lists.openembedded.org/mt/103052741/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] [master] [PATCH] cve-update-nvd2-native: increase the delay between subsequent request failures
Hi, On 2023/12/11 10:02, Yoann Congal wrote: >Hello, > >Le 11/12/2023 à 08:51, Yuta Hayama a écrit : >> Hi, >> >> On 2023/12/08 14:04, Dhairya Nagodra via lists.openembedded.org wrote: >>> Sometimes NVD servers are unstable and return too many errors. >>> There is an option to have higher fetch attempts to increase the >>> chances of successfully fetching the CVE data. >>> >>> Additionally, it also makes sense to progressively increase the delay >>> after a failed request to an already unstable or busy server. >>> The increase in delay is reset after every successful request and the >>> maximum delay is limited to 30 seconds. >>> >>> Also, the logs are improved to give more clarity. >>> >>> Signed-off-by: Dhairya Nagodra >> >> I was just working on a similar issue. >> As a specific example, multiple cve-update-nvd2-native:do_fetch runs >> in parallel can easily reach the rate limit. It can be assumed that >> this situation will occur if several people run bitbake in one office. >> (often unaware of each >> other...) >> >> I have observed the do_fetch logs and found that HTTP 403 errors are >> returned if the request is blocked, probably due to rate limitation. As per my knowledge, HTTP 403 is related to a permission issue rather than a rate limitation. I have not seen an HTTP 403 error, anytime. Can you please help clarify how was it generated? Is it reproducible? I tried removing both sleep delays altogether (and without API keys) to try and generate an error. In that, I couldn't generate any errors instead, got the response with a 15-20 sec delay. So, I guess it stayed within the rate limit. > >Shouldn't we ask the NVD to return "429 Too Many Requests" instead? >https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 > >> NOTE: Requesting >> https://services.nvd.nist.gov/rest/json/cves/2.0?startIndex=6000 >> NOTE: CVE database: received error (HTTP Error 403: Forbidden), >> retrying >> NOTE: CVE database: received error (HTTP Error 403: Forbidden), >> retrying >> NOTE: CVE database: received error (HTTP Error 403: Forbidden), >> retrying >> NOTE: CVE database: received error (HTTP Error 403: Forbidden), >> retrying >> NOTE: CVE database: received error (HTTP Error 403: Forbidden), >> retrying >> WARNING: CVE database update failed >> DEBUG: Python function do_fetch finished >> >> Other times a request may fail with IncompleteRead, but this is >> clearly distinguishable from an HTTP error. >> >> Here, we can think of the following ideas. >> If an HTTP error occurs, assume that the rate limit has already been >> reached and wait 30 seconds to ensure that the next window starts. The >> patch will be something like this. >> >> --- >> meta/recipes-core/meta/cve-update-nvd2-native.bb | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) > >Regards, > >-- >Yoann Congal >Smile ECS - Tech Expert Regards, Dhairya -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192157): https://lists.openembedded.org/g/openembedded-core/message/192157 Mute This Topic: https://lists.openembedded.org/mt/103049968/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 v2 2/2] cve-update-nvd2-native: increase the delay between subsequent request failures
From: Dhairya Nagodra
Sometimes NVD servers are unstable and return too many errors.
There is an option to have higher fetch attempts to increase the chances
of successfully fetching the CVE data.
Additionally, it also makes sense to progressively increase the delay
after a failed request to an already unstable or busy server.
The increase in delay is reset after every successful request and
the maximum delay is limited to 30 seconds.
Also, the logs are improved to give more clarity.
Signed-off-by: Dhairya Nagodra
---
meta/recipes-core/meta/cve-update-nvd2-native.bb | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 941fca34c6..bfe48b27e7 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -114,7 +114,10 @@ def cleanup_db_download(db_file, db_tmp_file):
if os.path.exists(db_tmp_file):
os.remove(db_tmp_file)
-def nvd_request_next(url, attempts, api_key, args):
+def nvd_request_wait(attempt, min_wait):
+return min ( ( (2 * attempt) + min_wait ) , 30)
+
+def nvd_request_next(url, attempts, api_key, args, min_wait):
"""
Request next part of the NVD dabase
"""
@@ -143,8 +146,10 @@ def nvd_request_next(url, attempts, api_key, args):
r.close()
except Exception as e:
-bb.note("CVE database: received error (%s), retrying" % (e))
-time.sleep(6)
+wait_time = nvd_request_wait(attempt, min_wait)
+bb.note("CVE database: received error (%s)" % (e))
+bb.note("CVE database: retrying download after %d seconds.
attempted (%d/%d)" % (wait_time, attempt+1, attempts))
+time.sleep(wait_time)
pass
else:
return raw_data
@@ -195,7 +200,7 @@ def update_db_file(db_tmp_file, d, database_time):
while True:
req_args['startIndex'] = index
-raw_data = nvd_request_next(url, attempts, api_key, req_args)
+raw_data = nvd_request_next(url, attempts, api_key, req_args,
wait_time)
if raw_data is None:
# We haven't managed to download data
return False
--
2.35.6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192156):
https://lists.openembedded.org/g/openembedded-core/message/192156
Mute This Topic: https://lists.openembedded.org/mt/103106024/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 v2 1/2] cve-update-nvd2-native: faster requests with API keys
From: Dhairya Nagodra
As per NVD, the public rate limit is 5 requests in 30s (6s delay).
Using an API key increases the limit to 50 requests in 30s (0.6s delay).
However, NVD still recommends sleeping for several seconds so that the
other legitimate requests are serviced without denial or interruption.
Keeping the default sleep at 6 seconds and 2 seconds with an API key.
For failures, the wait time is unchanged (6 seconds).
Reference: https://nvd.nist.gov/developers/start-here#RateLimits
Signed-off-by: Dhairya Nagodra
---
meta/recipes-core/meta/cve-update-nvd2-native.bb | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 9ab8dc6050..941fca34c6 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -188,6 +188,11 @@ def update_db_file(db_tmp_file, d, database_time):
api_key = d.getVar("NVDCVE_API_KEY") or None
attempts = int(d.getVar("CVE_DB_UPDATE_ATTEMPTS"))
+# Recommended by NVD
+wait_time = 6
+if api_key:
+wait_time = 2
+
while True:
req_args['startIndex'] = index
raw_data = nvd_request_next(url, attempts, api_key, req_args)
@@ -210,7 +215,7 @@ def update_db_file(db_tmp_file, d, database_time):
break
# Recommended by NVD
-time.sleep(6)
+time.sleep(wait_time)
# Update success, set the date to cve_check file.
cve_f.write('CVE database update : %s\n\n' % datetime.date.today())
--
2.35.6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192155):
https://lists.openembedded.org/g/openembedded-core/message/192155
Mute This Topic: https://lists.openembedded.org/mt/103106023/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 3/7] rust: Upgrade 1.71.0 -> 1.71.1
On Mon, 11 Dec 2023 at 10:17, Alex Kiernan wrote:
> On Mon, Dec 11, 2023 at 7:15 AM Frédéric Martinsons
> wrote:
> >
> >
> >
> > On Sun, 10 Dec 2023 at 21:28, Alex Kiernan
> wrote:
> >>
> >> On Sun, Dec 10, 2023 at 7:39 PM Richard Purdie
> >> wrote:
> >> >
> >> > On Fri, 2023-12-08 at 14:03 +, Alex Kiernan wrote:
> >> > > https://blog.rust-lang.org/2023/08/03/Rust-1.71.1.html
> >> > >
> >> > > Signed-off-by: Alex Kiernan
> >> > > ---
> >> > >
> >> > > meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb} |
> 0
> >> > > .../rust/{libstd-rs_1.71.0.bb => libstd-rs_1.71.1.bb} |
> 0
> >> > > ...t-cross-canadian_1.71.0.bb => rust-cross-canadian_1.71.1.bb} |
> 0
> >> > > .../rust/{rust-llvm_1.71.0.bb => rust-llvm_1.71.1.bb} |
> 0
> >> > > meta/recipes-devtools/rust/rust-source.inc |
> 2 +-
> >> > > meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb} |
> 0
> >> > > 6 files changed, 1 insertion(+), 1 deletion(-)
> >> > > rename meta/recipes-devtools/rust/{cargo_1.71.0.bb =>
> cargo_1.71.1.bb} (100%)
> >> > > rename meta/recipes-devtools/rust/{libstd-rs_1.71.0.bb =>
> libstd-rs_1.71.1.bb} (100%)
> >> > > rename meta/recipes-devtools/rust/{rust-cross-canadian_1.71.0.bb
> => rust-cross-canadian_1.71.1.bb} (100%)
> >> > > rename meta/recipes-devtools/rust/{rust-llvm_1.71.0.bb =>
> rust-llvm_1.71.1.bb} (100%)
> >> > > rename meta/recipes-devtools/rust/{rust_1.71.0.bb =>
> rust_1.71.1.bb} (100%)
> >> > >
> >> > > diff --git a/meta/recipes-devtools/rust/cargo_1.71.0.bb
> b/meta/recipes-devtools/rust/cargo_1.71.1.bb
> >> > > similarity index 100%
> >> > > rename from meta/recipes-devtools/rust/cargo_1.71.0.bb
> >> > > rename to meta/recipes-devtools/rust/cargo_1.71.1.bb
> >> > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
> b/meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
> >> > > similarity index 100%
> >> > > rename from meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
> >> > > rename to meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
> >> > > diff --git a/meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.0.bb b/meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.1.bb
> >> > > similarity index 100%
> >> > > rename from meta/recipes-devtools/rust/
> rust-cross-canadian_1.71.0.bb
> >> > > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
> >> > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
> b/meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
> >> > > similarity index 100%
> >> > > rename from meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
> >> > > rename to meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
> >> > > diff --git a/meta/recipes-devtools/rust/rust-source.inc
> b/meta/recipes-devtools/rust/rust-source.inc
> >> > > index 3a192e42db7d..0729db6f0b45 100644
> >> > > --- a/meta/recipes-devtools/rust/rust-source.inc
> >> > > +++ b/meta/recipes-devtools/rust/rust-source.inc
> >> > > @@ -7,7 +7,7 @@ SRC_URI += "
> https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> >> > > file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
> >> > >
> file://0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch;patchdir=${RUSTSRC}
> \
> >> > > "
> >> > > -SRC_URI[rust.sha256sum] =
> "5814699031aafdcc2e2f71fc9b389678cd7042350d1583da061463d8e88681c7"
> >> > > +SRC_URI[rust.sha256sum] =
> "371af0fbe04051e20a74dbea6d4e4e548f10f15309c49cae2688afb882b6c7f1"
> >> > >
> >> > > RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
> >> > >
> >> > > diff --git a/meta/recipes-devtools/rust/rust_1.71.0.bb
> b/meta/recipes-devtools/rust/rust_1.71.1.bb
> >> > > similarity index 100%
> >> > > rename from meta/recipes-devtools/rust/rust_1.71.0.bb
> >> > > rename to meta/recipes-devtools/rust/rust_1.71.1.bb
> >> >
> >> > I ran some testing and it looks like we could merge up to 1.71.1
> >> > without autobuilder failures in this series. Beyond that we have the
> >> > reproducibility and zvariant issues.
> >> >
> >>
> >> Thanks.
> >>
> >> Was the failure at that point reproducibility or the zvariant trait
> >> failure? I just posted an update for zvariant which doesn't see the
> >> trait recursion failure, but at the same time it no longer exercises
> >> crates pulled from git which looked like it was the main purpose it
> >> was fulfilling for testing.
> >>
> > I didn't follow issues about this upgrade, but yes, the zvariant recipe
> > was a demonstration on how to handle crates dependencies that come from
> git.
> > (there is a specific crate fetcher url parameter: 'git-dependency')
> >
>
> 3.12 (which was what we had) exploded with unbounded recursion inside
> a trait on later compilers, upgrading to 3.15 fixes it, but they've
> dropped the git dependency crate and just used upstream crates:
>
> commit 9e34dd510bf1a50f5168d5164578ebe8958928e3
> Author: Zeeshan Ali Khan
> Date: Wed May 10 20:45:26 2023 +0200
>
> zv: Swtich glib from git to latest released version
>
> We don't need the
Re: [OE-Core][PATCH 1/2] cargo-update-recipe-crates: Use CARGO_LOCK_PATH
On Mon, Dec 11, 2023 at 9:28 AM Alexander Kanavin
wrote:
>
> On Mon, 11 Dec 2023 at 10:09, Alex Kiernan wrote:
> > In a single project there are (potentially) multiple Cargo.toml, but
> > just one Cargo.lock. If there's multiple Cargo.lock files in a repo,
> > that implies multiple projects which I don't think we've any way of
> > building from a single recipe.
>
> I'm thinking of projects like librsvg, python3-bcrypt or
> python3-cryptography where the build is orchestrated by meson,
> autoconf or setuptools, and where we don't run cargo directly and
> leave it to those tools. They may have single Cargo.lock now, but will
> that hold? Also, that Cargo.lock is not necessarily in the root of
> ${S}, so you'd have to set the location manually, instead of not
> having to worry about it. Is CARGO_LOCK_PATH or its parent variables
> already set correctly for all of them? I see this is not done from
> python3-cryptography; shouldn't the build error out, if
> cargo_common_do_patch_paths requires the location? Something doesn't
> compute fully here.
>
That's exactly the one I was going to look at next, as I agree
something doesn't add up there.
--
Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192152):
https://lists.openembedded.org/g/openembedded-core/message/192152
Mute This Topic: https://lists.openembedded.org/mt/103094777/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] [yocto] QA notification for completed autobuilder build (yocto-3.1.30.rc1)
Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.30.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowBoard Turbot - 32bit 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) 6. Edgerouter 7. Beaglebone ETA for completion Friday, December 15. Best regards, Jing Hui > -Original Message- > From: yo...@lists.yoctoproject.org On Behalf > Of Pokybuild User > Sent: Monday, December 11, 2023 1:24 PM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [yocto] QA notification for completed autobuilder build (yocto- > 3.1.30.rc1) > > > A build flagged for QA (yocto-3.1.30.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.30.rc1 > > > Build URL: > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6316 > > Build hash information: > > bitbake: c0d60794a32e3f8bbfbbd6800d87ef2782aacf2c > meta-agl: 512d244d48ba0d33f609f425a6e8a907b178cdac > meta-arm: b75b8ce1ac10dc3521c0f710a4cf79bc7e985cfd > meta-aws: f3ba81625dac2e5c009e73ad78fec23b1261bd02 > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > meta-intel: e482213f37828216c7a7df68ff353652cc865ec1 > meta-mingw: 7bdc58e6c5d1054b1b6ad5c4e480a95e995ccbae > meta-openembedded: 9135c7ea7350d5d241f4afc3b28087122ebe2d19 > meta-virtualization: 35c723774ee06b3c1831f00a2cbf25cbeae132e1 > oecore: 7e65b351fa8eda4ee7b9f1f2a8dbfe14e0ef697a > poky: bf9eabafc257a7d3c39e3b4a46cabf7e6fb8270e > > > > 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 (#192151): https://lists.openembedded.org/g/openembedded-core/message/192151 Mute This Topic: https://lists.openembedded.org/mt/103105848/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 1/2] cargo-update-recipe-crates: Use CARGO_LOCK_PATH
On Mon, 11 Dec 2023 at 10:09, Alex Kiernan wrote:
> In a single project there are (potentially) multiple Cargo.toml, but
> just one Cargo.lock. If there's multiple Cargo.lock files in a repo,
> that implies multiple projects which I don't think we've any way of
> building from a single recipe.
I'm thinking of projects like librsvg, python3-bcrypt or
python3-cryptography where the build is orchestrated by meson,
autoconf or setuptools, and where we don't run cargo directly and
leave it to those tools. They may have single Cargo.lock now, but will
that hold? Also, that Cargo.lock is not necessarily in the root of
${S}, so you'd have to set the location manually, instead of not
having to worry about it. Is CARGO_LOCK_PATH or its parent variables
already set correctly for all of them? I see this is not done from
python3-cryptography; shouldn't the build error out, if
cargo_common_do_patch_paths requires the location? Something doesn't
compute fully here.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192150):
https://lists.openembedded.org/g/openembedded-core/message/192150
Mute This Topic: https://lists.openembedded.org/mt/103094777/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 3/7] rust: Upgrade 1.71.0 -> 1.71.1
On Mon, Dec 11, 2023 at 7:15 AM Frédéric Martinsons
wrote:
>
>
>
> On Sun, 10 Dec 2023 at 21:28, Alex Kiernan wrote:
>>
>> On Sun, Dec 10, 2023 at 7:39 PM Richard Purdie
>> wrote:
>> >
>> > On Fri, 2023-12-08 at 14:03 +, Alex Kiernan wrote:
>> > > https://blog.rust-lang.org/2023/08/03/Rust-1.71.1.html
>> > >
>> > > Signed-off-by: Alex Kiernan
>> > > ---
>> > >
>> > > meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb} | 0
>> > > .../rust/{libstd-rs_1.71.0.bb => libstd-rs_1.71.1.bb} | 0
>> > > ...t-cross-canadian_1.71.0.bb => rust-cross-canadian_1.71.1.bb} | 0
>> > > .../rust/{rust-llvm_1.71.0.bb => rust-llvm_1.71.1.bb} | 0
>> > > meta/recipes-devtools/rust/rust-source.inc | 2 +-
>> > > meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb} | 0
>> > > 6 files changed, 1 insertion(+), 1 deletion(-)
>> > > rename meta/recipes-devtools/rust/{cargo_1.71.0.bb => cargo_1.71.1.bb}
>> > > (100%)
>> > > rename meta/recipes-devtools/rust/{libstd-rs_1.71.0.bb =>
>> > > libstd-rs_1.71.1.bb} (100%)
>> > > rename meta/recipes-devtools/rust/{rust-cross-canadian_1.71.0.bb =>
>> > > rust-cross-canadian_1.71.1.bb} (100%)
>> > > rename meta/recipes-devtools/rust/{rust-llvm_1.71.0.bb =>
>> > > rust-llvm_1.71.1.bb} (100%)
>> > > rename meta/recipes-devtools/rust/{rust_1.71.0.bb => rust_1.71.1.bb}
>> > > (100%)
>> > >
>> > > diff --git a/meta/recipes-devtools/rust/cargo_1.71.0.bb
>> > > b/meta/recipes-devtools/rust/cargo_1.71.1.bb
>> > > similarity index 100%
>> > > rename from meta/recipes-devtools/rust/cargo_1.71.0.bb
>> > > rename to meta/recipes-devtools/rust/cargo_1.71.1.bb
>> > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
>> > > b/meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
>> > > similarity index 100%
>> > > rename from meta/recipes-devtools/rust/libstd-rs_1.71.0.bb
>> > > rename to meta/recipes-devtools/rust/libstd-rs_1.71.1.bb
>> > > diff --git a/meta/recipes-devtools/rust/rust-cross-canadian_1.71.0.bb
>> > > b/meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
>> > > similarity index 100%
>> > > rename from meta/recipes-devtools/rust/rust-cross-canadian_1.71.0.bb
>> > > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.71.1.bb
>> > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
>> > > b/meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
>> > > similarity index 100%
>> > > rename from meta/recipes-devtools/rust/rust-llvm_1.71.0.bb
>> > > rename to meta/recipes-devtools/rust/rust-llvm_1.71.1.bb
>> > > diff --git a/meta/recipes-devtools/rust/rust-source.inc
>> > > b/meta/recipes-devtools/rust/rust-source.inc
>> > > index 3a192e42db7d..0729db6f0b45 100644
>> > > --- a/meta/recipes-devtools/rust/rust-source.inc
>> > > +++ b/meta/recipes-devtools/rust/rust-source.inc
>> > > @@ -7,7 +7,7 @@ SRC_URI +=
>> > > "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
>> > > file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
>> > >
>> > > file://0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch;patchdir=${RUSTSRC}
>> > > \
>> > > "
>> > > -SRC_URI[rust.sha256sum] =
>> > > "5814699031aafdcc2e2f71fc9b389678cd7042350d1583da061463d8e88681c7"
>> > > +SRC_URI[rust.sha256sum] =
>> > > "371af0fbe04051e20a74dbea6d4e4e548f10f15309c49cae2688afb882b6c7f1"
>> > >
>> > > RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
>> > >
>> > > diff --git a/meta/recipes-devtools/rust/rust_1.71.0.bb
>> > > b/meta/recipes-devtools/rust/rust_1.71.1.bb
>> > > similarity index 100%
>> > > rename from meta/recipes-devtools/rust/rust_1.71.0.bb
>> > > rename to meta/recipes-devtools/rust/rust_1.71.1.bb
>> >
>> > I ran some testing and it looks like we could merge up to 1.71.1
>> > without autobuilder failures in this series. Beyond that we have the
>> > reproducibility and zvariant issues.
>> >
>>
>> Thanks.
>>
>> Was the failure at that point reproducibility or the zvariant trait
>> failure? I just posted an update for zvariant which doesn't see the
>> trait recursion failure, but at the same time it no longer exercises
>> crates pulled from git which looked like it was the main purpose it
>> was fulfilling for testing.
>>
> I didn't follow issues about this upgrade, but yes, the zvariant recipe
> was a demonstration on how to handle crates dependencies that come from git.
> (there is a specific crate fetcher url parameter: 'git-dependency')
>
3.12 (which was what we had) exploded with unbounded recursion inside
a trait on later compilers, upgrading to 3.15 fixes it, but they've
dropped the git dependency crate and just used upstream crates:
commit 9e34dd510bf1a50f5168d5164578ebe8958928e3
Author: Zeeshan Ali Khan
Date: Wed May 10 20:45:26 2023 +0200
zv: Swtich glib from git to latest released version
We don't need the git version and cargo caching action doesn't help with
cloning of git repos so the build takes longer in the CI than it needs
to.
> If, for
Re: [OE-Core][PATCH 1/2] cargo-update-recipe-crates: Use CARGO_LOCK_PATH
On Sun, Dec 10, 2023 at 8:35 PM Alexander Kanavin wrote: > > I have to say, I struggle to see this as an improvement, and I want > to object to it. > I have to admit I kinda thought this might be controversial. > Why set the path manually, if the code to find where Cargo.lock is > just works, and handles the situations where upstreams move it around > in source trees? > We have to know where Cargo.lock is else cargo_common_do_patch_paths fails. Searching for it one class and requiring to know where it is another seems odd to me - my first pass on this change was to just set CARGO_LOCK_SRC_DIR based on the directory name of CARGO_LOCK_PATH; I'll resurrect that patch. > Also, is the assumption that there's only one Cargo.lock valid? I'm > not so sure. Note that the code was specifically written to pull in > items from multiple files. > In a single project there are (potentially) multiple Cargo.toml, but just one Cargo.lock. If there's multiple Cargo.lock files in a repo, that implies multiple projects which I don't think we've any way of building from a single recipe. -- Alex Kiernan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192148): https://lists.openembedded.org/g/openembedded-core/message/192148 Mute This Topic: https://lists.openembedded.org/mt/103094777/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] gnutls: Backport fix for CVE-2023-5981
From: Vijay Anusuri
Upstream-Status: Backport [import from debian
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/gnutls28/3.7.3-4ubuntu1.3/gnutls28_3.7.3-4ubuntu1.3.debian.tar.xz
Upstream-Commit:
https://gitlab.com/gnutls/gnutls/-/commit/29d6298d0b04cfff970b993915db71ba3f580b6d]
References:
https://ubuntu.com/security/CVE-2023-5981
Signed-off-by: Vijay Anusuri
---
.../gnutls/gnutls/CVE-2023-5981.patch | 206 ++
meta/recipes-support/gnutls/gnutls_3.7.4.bb | 1 +
2 files changed, 207 insertions(+)
create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2023-5981.patch
diff --git a/meta/recipes-support/gnutls/gnutls/CVE-2023-5981.patch
b/meta/recipes-support/gnutls/gnutls/CVE-2023-5981.patch
new file mode 100644
index 00..33e498b8e5
--- /dev/null
+++ b/meta/recipes-support/gnutls/gnutls/CVE-2023-5981.patch
@@ -0,0 +1,206 @@
+Backport of:
+
+From 29d6298d0b04cfff970b993915db71ba3f580b6d Mon Sep 17 00:00:00 2001
+From: Daiki Ueno
+Date: Mon, 23 Oct 2023 09:26:57 +0900
+Subject: [PATCH] auth/rsa_psk: side-step potential side-channel
+
+This removes branching that depends on secret data, porting changes
+for regular RSA key exchange from
+4804febddc2ed958e5ae774de2a8f85edeeff538 and
+80a6ce8ddb02477cd724cd5b2944791aaddb702a. This also removes the
+allow_wrong_pms as it was used sorely to control debug output
+depending on the branching.
+
+Signed-off-by: Daiki Ueno
+
+Upstream-Status: Backport [import from debian
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/gnutls28/3.7.3-4ubuntu1.3/gnutls28_3.7.3-4ubuntu1.3.debian.tar.xz
+Upstream-Commit:
https://gitlab.com/gnutls/gnutls/-/commit/29d6298d0b04cfff970b993915db71ba3f580b6d]
+CVE: CVE-2023-5981
+Signed-off-by: Vijay Anusuri
+---
+ lib/auth/rsa.c | 2 +-
+ lib/auth/rsa_psk.c | 90 ++
+ lib/gnutls_int.h | 4 ---
+ lib/priority.c | 1 -
+ 4 files changed, 35 insertions(+), 62 deletions(-)
+
+--- a/lib/auth/rsa.c
b/lib/auth/rsa.c
+@@ -207,7 +207,7 @@ proc_rsa_client_kx(gnutls_session_t sess
+session->key.key.size);
+ /* After this point, any conditional on failure that cause differences
+* in execution may create a timing or cache access pattern side
+- * channel that can be used as an oracle, so treat very carefully */
++ * channel that can be used as an oracle, so tread carefully */
+
+ /* Error handling logic:
+* In case decryption fails then don't inform the peer. Just use the
+--- a/lib/auth/rsa_psk.c
b/lib/auth/rsa_psk.c
+@@ -264,14 +264,13 @@ _gnutls_proc_rsa_psk_client_kx(gnutls_se
+ {
+ gnutls_datum_t username;
+ psk_auth_info_t info;
+- gnutls_datum_t plaintext;
+ gnutls_datum_t ciphertext;
+ gnutls_datum_t pwd_psk = { NULL, 0 };
+ int ret, dsize;
+- int randomize_key = 0;
+ ssize_t data_size = _data_size;
+ gnutls_psk_server_credentials_t cred;
+ gnutls_datum_t premaster_secret = { NULL, 0 };
++ volatile uint8_t ver_maj, ver_min;
+
+ cred = (gnutls_psk_server_credentials_t)
+ _gnutls_get_cred(session, GNUTLS_CRD_PSK);
+@@ -327,71 +326,47 @@ _gnutls_proc_rsa_psk_client_kx(gnutls_se
+ }
+ ciphertext.size = dsize;
+
+- ret =
+- gnutls_privkey_decrypt_data(session->internals.selected_key, 0,
+- , );
+- if (ret < 0 || plaintext.size != GNUTLS_MASTER_SIZE) {
+- /* In case decryption fails then don't inform
+- * the peer. Just use a random key. (in order to avoid
+- * attack against pkcs-1 formatting).
+- */
+- gnutls_assert();
+- _gnutls_debug_log
+- ("auth_rsa_psk: Possible PKCS #1 format attack\n");
+- if (ret >= 0) {
+- gnutls_free(plaintext.data);
+- }
+- randomize_key = 1;
+- } else {
+- /* If the secret was properly formatted, then
+- * check the version number.
+- */
+- if (_gnutls_get_adv_version_major(session) !=
+- plaintext.data[0]
+- || (session->internals.allow_wrong_pms == 0
+- && _gnutls_get_adv_version_minor(session) !=
+- plaintext.data[1])) {
+- /* No error is returned here, if the version number
check
+- * fails. We proceed normally.
+- * That is to defend against the attack described in
the paper
+- * "Attacking RSA-based sessions in SSL/TLS" by
Vlastimil Klima,
+- * Ondej Pokorny and Tomas Rosa.
+- */
+- gnutls_assert();
+- _gnutls_debug_log
+- ("auth_rsa: Possible PKCS #1 version check format
Re: [OE-core] [master] [PATCH] cve-update-nvd2-native: increase the delay between subsequent request failures
Hello, Le 11/12/2023 à 08:51, Yuta Hayama a écrit : > Hi, > > On 2023/12/08 14:04, Dhairya Nagodra via lists.openembedded.org wrote: >> Sometimes NVD servers are unstable and return too many errors. >> There is an option to have higher fetch attempts to increase the chances >> of successfully fetching the CVE data. >> >> Additionally, it also makes sense to progressively increase the delay >> after a failed request to an already unstable or busy server. >> The increase in delay is reset after every successful request and >> the maximum delay is limited to 30 seconds. >> >> Also, the logs are improved to give more clarity. >> >> Signed-off-by: Dhairya Nagodra > > I was just working on a similar issue. > As a specific example, multiple cve-update-nvd2-native:do_fetch runs in > parallel can easily reach the rate limit. It can be assumed that this > situation > will occur if several people run bitbake in one office. (often unaware of each > other...) > > I have observed the do_fetch logs and found that HTTP 403 errors are returned > if the request is blocked, probably due to rate limitation. Shouldn't we ask the NVD to return "429 Too Many Requests" instead? https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 > NOTE: Requesting > https://services.nvd.nist.gov/rest/json/cves/2.0?startIndex=6000 > NOTE: CVE database: received error (HTTP Error 403: Forbidden), retrying > NOTE: CVE database: received error (HTTP Error 403: Forbidden), retrying > NOTE: CVE database: received error (HTTP Error 403: Forbidden), retrying > NOTE: CVE database: received error (HTTP Error 403: Forbidden), retrying > NOTE: CVE database: received error (HTTP Error 403: Forbidden), retrying > WARNING: CVE database update failed > DEBUG: Python function do_fetch finished > > Other times a request may fail with IncompleteRead, but this is clearly > distinguishable from an HTTP error. > > Here, we can think of the following ideas. > If an HTTP error occurs, assume that the rate limit has already been reached > and wait 30 seconds to ensure that the next window starts. The patch will be > something like this. > > --- > meta/recipes-core/meta/cve-update-nvd2-native.bb | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Regards, -- Yoann Congal Smile ECS - Tech Expert -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192146): https://lists.openembedded.org/g/openembedded-core/message/192146 Mute This Topic: https://lists.openembedded.org/mt/103049968/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
