[OE-core] [PATCH] tcmode-default.inc: use ?= to set PREFERRED_VERSION_llvm/llvm-native/nativesdk-llvm
From: Changqing Li
use ?= to set following configs in order to allow user
to override the default settings:
PREFERRED_VERSION_llvm
PREFERRED_VERSION_llvm-native
PREFERRED_VERSION_nativesdk-llvm
Signed-off-by: Changqing Li
---
meta/conf/distro/include/tcmode-default.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 3720a4c5b8..0de858d3af 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -77,9 +77,9 @@ PREFERRED_VERSION_go-runtime ?= "${GOVERSION}"
PREFERRED_VERSION_nativesdk-go ?= "${GOVERSION}"
PREFERRED_VERSION_nativesdk-go-runtime ?= "${GOVERSION}"
-PREFERRED_VERSION_llvm = "${LLVMVERSION}"
-PREFERRED_VERSION_llvm-native = "${LLVMVERSION}"
-PREFERRED_VERSION_nativesdk-llvm = "${LLVMVERSION}"
+PREFERRED_VERSION_llvm ?= "${LLVMVERSION}"
+PREFERRED_VERSION_llvm-native ?= "${LLVMVERSION}"
+PREFERRED_VERSION_nativesdk-llvm ?= "${LLVMVERSION}"
# Rust toolchain preferred versions:
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194017):
https://lists.openembedded.org/g/openembedded-core/message/194017
Mute This Topic: https://lists.openembedded.org/mt/103826050/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] oeqa parselogs.py: load ignore files from sys.path
Hi,
I think this patch should be applied as it aligns oeqa .py and .text file
searches
across layers. Without this layers need to add "addpylib ${LAYERDIR}/lib oeqa"
in layer.conf which doesn't have any other uses and debugging this is really
hard.
There may be addition things wrong in bitbake python environment when oeqa
tests run
but this is already an improvement.
Ross, do you agree?
Cheers,
-Mikko
On Wed, Jan 10, 2024 at 04:23:22PM +0200, Mikko Rapeli via
lists.openembedded.org wrote:
> Hi,
>
> On Wed, Jan 10, 2024 at 02:01:36PM +, Ross Burton wrote:
> > On 10 Jan 2024, at 13:03, Mikko Rapeli via lists.openembedded.org
> > wrote:
> > > python import.resources open_text() loads files from the module paths
> > > but this requires layers to set "addpylib ${LAYERDIR}/lib oeqa"
> > > which is not needed to find the plain .py test files to run the tests.
> > > Also an empty __init__.py file in a layer will break the resource file
> > > loading completely as only that path with __init__.py file will
> > > be used to search the resource files. Then open_text() is marked
> > > as deprecated from python 3.11 onwards
> > > https://docs.python.org/3/library/importlib.resources.html
> >
> > Deprecated but replaceable with files(package).joinpath(resource).open()
> > (which is all open_text does internally).
>
> Yes, but that seems to break if __init__.py file is found from
> ${LAYERDIR}/lib/oeqa/runtime/cases.
>
> > > So replace open_text() by iterating over sys.path to find the ignore
> > > files. This works since paths like ${LAYERDIR}/lib/oeqa/runtime/cases are
> > > already in sys.path. Add debug prints for found and not found files
> > > while at it.
> >
> > I’m confused why lib/oeqa/runtime/cases is on sys.path directly, that
> > sounds… unusual. Do you have any idea where that comes from? I’m guessing
> > oeqa is throwing it on the path whilst searching for test cases, but that
> > sounds like bad behaviour that should be removed to me.
>
> No idea where this comes from, but it's there. addpylib is doing similar
> things,
> adding paths to sys.path and for this use case this not really necessary as
> ${LAYERDIR}/lib should not need to be, it only has oeqa directory. I presume
> test case loading via testimage.bbclass or OERuntim are adding it. These are
> kind
> of hard to debug since "bitbake -e" show any of this.
>
> It's a bit odd that layer.conf would need "addpylib ${LAYERDIR}/lib oeqa" for
> loading
> .txt files but that's not needed for finding and using the oeqa .py test
> files.
> With this change addpylib magic is not needed, at least for finding these
> .txt files.
>
> Cheers,
>
> -Mikko
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194016):
https://lists.openembedded.org/g/openembedded-core/message/194016
Mute This Topic: https://lists.openembedded.org/mt/103639917/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] [RFT][PATCH] glibc: Upgrade to 2.39
Hello Raj,
I will try to take a look on this today. Is the patch the same as here
https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut=c0594edef0d2108860421d0cfd460993264e18c3
? Means, if I can take it from there.
Thanks,
Andy
On 17.01.2024 08:20, Khem Raj wrote:
On Tue, Jan 16, 2024 at 11:10 PM Andrej Valek wrote:
Hello Raj,
Don't forget to change the glibc-version.inc too and try to make a
optimization/cleaning like I proposed here:
https://lists.openembedded.org/g/openembedded-core/message/193572 ;).
yeah CVEs list will need cleaning anyway as it will be verson bump. But if
you turn your suggestion into a patch I can include it in patchset.
Regards,
Andy
On 16.01.2024 20:53, Khem Raj wrote:
Upgrade localdef to get glibc 2.39 build fixes
Details of release [1]
[1] https://sourceware.org/glibc/wiki/Release/2.39
Signed-off-by: Khem Raj
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
...2.38.bb => cross-localedef-native_2.39.bb} | 0
meta/recipes-core/glibc/glibc-common.inc | 2 +-
...bc-locale_2.38.bb => glibc-locale_2.39.bb} | 0
...bc-mtrace_2.38.bb => glibc-mtrace_2.39.bb} | 0
...-scripts_2.38.bb => glibc-scripts_2.39.bb} | 0
...tsuite_2.38.bb => glibc-testsuite_2.39.bb} | 0
meta/recipes-core/glibc/glibc-version.inc | 8 ++--
...ests_2.38.bb => glibc-y2038-tests_2.39.bb} | 0
...dd-hardlink-resolver-from-util-linux.patch | 2 +-
...-fix-ups-hardlink-to-make-it-compile.patch | 2 +-
...Look-for-host-system-ld.so.cache-as-.patch | 8 ++--
...Fix-buffer-overrun-with-a-relocated-.patch | 4 +-
...Raise-the-size-of-arrays-containing-.patch | 22 -
...k-glibc-Allow-64-bit-atomics-for-x86.patch | 4 +-
...Make-relocatable-install-for-locales.patch | 10 ++--
...Fall-back-to-faccessat-on-faccess2-r.patch | 4 +-
...the-path-sets-wrong-config-variables.patch | 2 +-
...ss-building-and-testing-instructions.patch | 2 +-
...glibc-Help-bootstrap-cross-toolchain.patch | 4 +-
...eglibc-Resolve-__fpscr_values-on-SH4.patch | 4 +-
...port-cross-locale-generation-support.patch | 46 +--
...-archive-uses-a-hard-coded-locale-pa.patch | 4 +-
...Do-not-ask-compiler-for-finding-arch.patch | 2 +-
...y-the-header-between-arm-and-aarch64.patch | 4 +-
...h-printf-builtin-in-nscd-init-script.patch | 2 +-
...igure.ac-Set-libc_cv_rootsbindir-onl.patch | 2 +-
...ell-interpreter-overridable-in-tzsel.patch | 6 +--
...Use-bin-sh-default-shell-interpreter.patch | 2 +-
...d-failed-in-unprivileged-process-BZ-.patch | 6 +--
...build-time-paths-in-the-output-binar.patch | 6 +--
...e-Pass-mcpu-along-with-march-to-dete.patch | 5 +-
...Bump-__GLIBC_MINOR__-to-39-on-master.patch | 25 ++
.../glibc/{glibc_2.38.bb => glibc_2.39.bb}| 1 +
34 files changed, 106 insertions(+), 85 deletions(-)
rename meta/recipes-core/glibc/{cross-localedef-native_2.38.bb =>
cross-localedef-native_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-locale_2.38.bb =>
glibc-locale_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-mtrace_2.38.bb =>
glibc-mtrace_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-scripts_2.38.bb =>
glibc-scripts_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-testsuite_2.38.bb =>
glibc-testsuite_2.39.bb} (100%)
rename meta/recipes-core/glibc/{glibc-y2038-tests_2.38.bb =>
glibc-y2038-tests_2.39.bb} (100%)
create mode 100644
meta/recipes-core/glibc/glibc/0024-features.h-Bump-__GLIBC_MINOR__-to-39-on-master.patch
rename meta/recipes-core/glibc/{glibc_2.38.bb => glibc_2.39.bb} (98%)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 3720a4c5b86..977fb316107 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -20,7 +20,7 @@ GCCVERSION ?= "13.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.41%"
GDBVERSION ?= "14.%"
-GLIBCVERSION ?= "2.38%"
+GLIBCVERSION ?= "2.39%"
LINUXLIBCVERSION ?= "6.6%"
QEMUVERSION ?= "8.1%"
GOVERSION ?= "1.20%"
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.38.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/cross-localedef-native_2.38.bb
rename to meta/recipes-core/glibc/cross-localedef-native_2.39.bb
diff --git a/meta/recipes-core/glibc/glibc-common.inc
b/meta/recipes-core/glibc/glibc-common.inc
index be33c29857c..5b62884a017 100644
--- a/meta/recipes-core/glibc/glibc-common.inc
+++ b/meta/recipes-core/glibc/glibc-common.inc
@@ -22,4 +22,4 @@ ARM_INSTRUCTION_SET:armv6 = "arm"
#
COMPATIBLE_HOST:libc-musl:class-target = "null"
-PV = "2.38"
+PV = "2.39+git"
diff --git a/meta/recipes-core/glibc/glibc-locale_2.38.bb
b/meta/recipes-core/glibc/glibc-locale_2.39.bb
similarity index 100%
rename from meta/recipes-core/glibc/glibc-locale_2.38.bb
rename to
Re: [OE-core] [PATCH v1] uboot-sign: support to load optee-os and TFA images
>
> Hello,
>
> This doesn't apply on top of your previous patches. Can you send a proper
> series with what you want to be tested/applied?
>
> Thanks!
>
Hi Alexandre
I created a series patch here,
https://patchwork.yoctoproject.org/project/oe-core/list/?series=21444
Thanks-Jamin
> On 17/01/2024 10:10:51+0800, Jamin Lin via lists.openembedded.org wrote:
> > Currently, u-boot FIT image only support to load u-boot image.
> > To support optee-os and trusted-firmware-a, update ITS file generation
> > scripts, so users are able to use u-boot FIT image to load u-boot,
> > optee-os and treustred-firmware-a images
> >
> > Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A" to enable
> > trusted-firmware-a image and it is disable by default.
> >
> > Add a variable "UBOOT_FIT_OPTEE_OS" to enable optee-os image and it is
> > disable by default.
> >
> > The ITS file creation looks like as following.
> > 1. Both optee-os and trusted-firmware-a are disabled.
> > '''
> > /dts-v1/;
> >
> > / {
> > images {
> > uboot {
> >
> > };
> > fdt {
> > };
> > };
> >
> > configurations {
> > default = "conf";
> > conf {
> > loadables = "uboot";
> > fdt = "fdt";
> > };
> > };
> > };
> > '''
> >
> > 2. Only enable optee-os
> > '''
> > /dts-v1/;
> >
> > / {
> > images {
> > uboot {
> > };
> > fdt {
> > };
> > optee {
> > };
> > };
> >
> > configurations {
> > default = "conf";
> > conf {
> > firmware = "optee";
> > loadables = "uboot";
> > fdt = "fdt";
> > };
> > };
> > };
> > '''
> >
> > 3: Both optee-os and trusted-firmware-a are enabled '''
> > /dts-v1/;
> >
> > / {
> > images {
> > uboot {
> > };
> > fdt {
> > };
> > atf {
> > };
> > optee {
> > };
> > };
> >
> > configurations {
> > default = "conf";
> > conf {
> > firmware = "atf";
> > loadables = "uboot", "optee";
> > fdt = "fdt";
> > };
> > };
> > };
> > '''
> >
> > Signed-off-by: Jamin Lin
> > ---
> > meta/classes-recipe/uboot-sign.bbclass | 91
> > +-
> > 1 file changed, 90 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes-recipe/uboot-sign.bbclass
> > b/meta/classes-recipe/uboot-sign.bbclass
> > index ad04c82378..b874eb84db 100644
> > --- a/meta/classes-recipe/uboot-sign.bbclass
> > +++ b/meta/classes-recipe/uboot-sign.bbclass
> > @@ -88,6 +88,18 @@ UBOOT_FIT_ADDRESS_CELLS ?= "1"
> > # This is only necessary for determining the signing configuration
> > KERNEL_PN = "${PREFERRED_PROVIDER_virtual/kernel}"
> >
> > +# Trusted Firmware-A (TF-A) provides a reference implementation of #
> > +secure world software for Armv7-A and Armv8-A, # including a Secure
> > +Monitor executing at Exception Level 3 (EL3) # ATF is used as the
> > +initial start code on ARMv8-A cores for all K3 platforms
> > +UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A ?= "0"
> > +UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_IMAGE ?= "bl31.bin"
> > +
> > +# OP-TEE is a Trusted Execution Environment (TEE) designed as #
> > +companion to a non-secure Linux kernel running on Arm
> > +UBOOT_FIT_OPTEE_OS ?= "0"
> > +UBOOT_FIT_OPTEE_OS_IMAGE ?= "tee-raw.bin"
> > +
> > python() {
> > # We need u-boot-tools-native if we're creating a U-Boot fitImage
> > sign = d.getVar('UBOOT_SIGN_ENABLE') == '1'
> > @@ -230,6 +242,20 @@ addtask uboot_generate_rsa_keys before
> > do_uboot_assemble_fitimage after do_compi # Create a ITS file for the
> > U-boot FIT, for use when # we want to sign it so that the SPL can
> > verify it
> > uboot_fitimage_assemble() {
> > + conf_loadables="\"uboot\""
> > + conf_firmware=""
> > +
> > + if [ "${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A}" = "1" ]; then
> > + conf_firmware="\"atf\""
> > + if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ]; then
> > + conf_loadables="\"uboot\", \"optee\""
> > + fi
> > + else
> > + if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ]; then
> > + conf_firmware="\"optee\""
> > + fi
> > + fi
> > +
> > rm -f ${UBOOT_ITS} ${UBOOT_FITIMAGE_BINARY}
> >
> > # First we create the ITS script
> > @@ -282,13 +308,76 @@ EOF
> >
> > cat << EOF >> ${UBOOT_ITS}
> > };
> > +EOF
> > + if [ "${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A}" = "1" ] ; then
> > + cat << EOF >> ${UBOOT_ITS}
> > +atf {
> > +description = "ARM Trusted Firmware-A";
> > +data =
> /incbin/("${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_IMAGE}");
> > +type = "firmware";
> > +arch = "${UBOOT_ARCH}";
> > +os = "arm-trusted-firmware";
> > +load =
> <${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_LOADADDRESS}>;
> > +entry =
> <${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_ENTRYPOINT}>;
> > +
[OE-core] [PATCH v2 4/4] uboot-sign: support to load optee-os and TFA images
Currently, u-boot FIT image only support to load u-boot image.
To support optee-os and trusted-firmware-a, update ITS file generation
scripts, so users are able to use u-boot FIT image to load
u-boot, optee-os and treustred-firmware-a images
Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A" to
enable trusted-firmware-a image and it is disable by default.
Add a variable "UBOOT_FIT_OPTEE_OS" to enable optee-os image
and it is disable by default.
The ITS file creation looks like as following.
1. Both optee-os and trusted-firmware-a are disabled.
'''
/dts-v1/;
/ {
images {
uboot {
};
fdt {
};
};
configurations {
default = "conf";
conf {
loadables = "uboot";
fdt = "fdt";
};
};
};
'''
2. Only enable optee-os
'''
/dts-v1/;
/ {
images {
uboot {
};
fdt {
};
optee {
};
};
configurations {
default = "conf";
conf {
firmware = "optee";
loadables = "uboot";
fdt = "fdt";
};
};
};
'''
3. Both optee-os and trusted-firmware-a are enabled
'''
/dts-v1/;
/ {
images {
uboot {
};
fdt {
};
atf {
};
optee {
};
};
configurations {
default = "conf";
conf {
firmware = "atf";
loadables = "uboot", "optee";
fdt = "fdt";
};
};
};
'''
Signed-off-by: Jamin Lin
---
meta/classes-recipe/uboot-sign.bbclass | 91 +-
1 file changed, 90 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index 7a0b8047e4..d2b1013b93 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -91,6 +91,18 @@ KERNEL_PN = "${PREFERRED_PROVIDER_virtual/kernel}"
UBOOT_FIT_UBOOT_LOADADDRESS ?= "${UBOOT_LOADADDRESS}"
UBOOT_FIT_UBOOT_ENTRYPOINT ?= "${UBOOT_ENTRYPOINT}"
+# Trusted Firmware-A (TF-A) provides a reference implementation of
+# secure world software for Armv7-A and Armv8-A,
+# including a Secure Monitor executing at Exception Level 3 (EL3)
+# ATF is used as the initial start code on ARMv8-A cores for all K3 platforms
+UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A ?= "0"
+UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_IMAGE ?= "bl31.bin"
+
+# OP-TEE is a Trusted Execution Environment (TEE) designed as
+# companion to a non-secure Linux kernel running on Arm
+UBOOT_FIT_OPTEE_OS ?= "0"
+UBOOT_FIT_OPTEE_OS_IMAGE ?= "tee-raw.bin"
+
python() {
# We need u-boot-tools-native if we're creating a U-Boot fitImage
sign = d.getVar('UBOOT_SIGN_ENABLE') == '1'
@@ -237,6 +249,20 @@ addtask uboot_generate_rsa_keys before
do_uboot_assemble_fitimage after do_compi
# Create a ITS file for the U-boot FIT, for use when
# we want to sign it so that the SPL can verify it
uboot_fitimage_assemble() {
+ conf_loadables="\"uboot\""
+ conf_firmware=""
+
+ if [ "${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A}" = "1" ]; then
+ conf_firmware="\"atf\""
+ if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ]; then
+ conf_loadables="\"uboot\", \"optee\""
+ fi
+ else
+ if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ]; then
+ conf_firmware="\"optee\""
+ fi
+ fi
+
rm -f ${UBOOT_ITS} ${UBOOT_FITIMAGE_BINARY}
# First we create the ITS script
@@ -289,13 +315,76 @@ EOF
cat << EOF >> ${UBOOT_ITS}
};
+EOF
+ if [ "${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A}" = "1" ] ; then
+ cat << EOF >> ${UBOOT_ITS}
+atf {
+description = "ARM Trusted Firmware-A";
+data = /incbin/("${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_IMAGE}");
+type = "firmware";
+arch = "${UBOOT_ARCH}";
+os = "arm-trusted-firmware";
+load = <${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_LOADADDRESS}>;
+entry = <${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_ENTRYPOINT}>;
+compression = "none";
+EOF
+
+ if [ "${SPL_SIGN_ENABLE}" = "1" ] ; then
+ cat << EOF >> ${UBOOT_ITS}
+signature {
+algo = "${UBOOT_FIT_HASH_ALG},${UBOOT_FIT_SIGN_ALG}";
+key-name-hint = "${SPL_SIGN_KEYNAME}";
+};
+EOF
+ fi
+
+ cat << EOF >> ${UBOOT_ITS}
+};
+EOF
+ fi
+
+ if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ] ; then
+ cat << EOF >> ${UBOOT_ITS}
+optee {
+description = "OPTEE OS Image";
+data = /incbin/("${UBOOT_FIT_OPTEE_OS_IMAGE}");
+type = "tee";
+arch = "${UBOOT_ARCH}";
+os = "tee";
+load = <${UBOOT_FIT_OPTEE_OS_LOADADDRESS}>;
+entry = <${UBOOT_FIT_OPTEE_OS_ENTRYPOINT}>;
+compression = "none";
+EOF
+
+ if
[OE-core] [PATCH v2 2/4] uboot-sign: Fix to install nonexistent dtb file
Add to check dtb file exist, then install it.
Signed-off-by: Jamin Lin
---
meta/classes-recipe/uboot-sign.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index abde0bc61c..4b462698f9 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -318,7 +318,9 @@ EOF
${SPL_MKIMAGE_SIGN_ARGS}
fi
- cp ${SPL_DIR}/${SPL_DTB_BINARY} ${SPL_DIR}/${SPL_DTB_SIGNED}
+ if [ -e "${SPL_DIR}/${SPL_DTB_BINARY}" ]; then
+ cp ${SPL_DIR}/${SPL_DTB_BINARY} ${SPL_DIR}/${SPL_DTB_SIGNED}
+ fi
}
uboot_assemble_fitimage_helper() {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194011):
https://lists.openembedded.org/g/openembedded-core/message/194011
Mute This Topic: https://lists.openembedded.org/mt/103825448/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 3/4] u-boot-sign:uboot-config: support to verify signed FIT image
It does not verify the signed FIT image of kernel and uboot.
To catch the unexpected errors as far as possible at the build time,
add uboot-fit-check-sign tool which is provided by u-boot to
verify the signed FIT image.
Signed-off-by: Jamin Lin
---
meta/classes-recipe/uboot-config.bbclass | 3 +++
meta/classes-recipe/uboot-sign.bbclass | 10 ++
2 files changed, 13 insertions(+)
diff --git a/meta/classes-recipe/uboot-config.bbclass
b/meta/classes-recipe/uboot-config.bbclass
index 9be1d64d3e..0c579e8861 100644
--- a/meta/classes-recipe/uboot-config.bbclass
+++ b/meta/classes-recipe/uboot-config.bbclass
@@ -94,6 +94,9 @@ SPL_MKIMAGE_SIGN_ARGS ?= ""
UBOOT_DTB ?= ""
UBOOT_DTB_BINARY ??= ""
+# uboot-fit_check_sign command
+UBOOT_FIT_CHECK_SIGN ?= "uboot-fit_check_sign"
+
python () {
ubootmachine = d.getVar("UBOOT_MACHINE")
ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index 4b462698f9..7a0b8047e4 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -112,6 +112,10 @@ concat_dtb() {
-K "${UBOOT_DTB_BINARY}" \
-r ${B}/fitImage-linux \
${UBOOT_MKIMAGE_SIGN_ARGS}
+ # Verify the kernel image and u-boot dtb
+ ${UBOOT_FIT_CHECK_SIGN} \
+ -k "${UBOOT_DTB_BINARY}" \
+ -f ${B}/fitImage-linux
cp ${UBOOT_DTB_BINARY} ${UBOOT_DTB_SIGNED}
fi
@@ -316,6 +320,12 @@ EOF
-K "${SPL_DIR}/${SPL_DTB_BINARY}" \
-r ${UBOOT_FITIMAGE_BINARY} \
${SPL_MKIMAGE_SIGN_ARGS}
+ #
+ # Verify the U-boot FIT image and SPL dtb
+ #
+ ${UBOOT_FIT_CHECK_SIGN} \
+ -k "${SPL_DIR}/${SPL_DTB_BINARY}" \
+ -f ${UBOOT_FITIMAGE_BINARY}
fi
if [ -e "${SPL_DIR}/${SPL_DTB_BINARY}" ]; then
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194012):
https://lists.openembedded.org/g/openembedded-core/message/194012
Mute This Topic: https://lists.openembedded.org/mt/103825449/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/4] uboot-sign: set load address and entrypoint
According to the design of uboot-sign.bbclass and kernel-fitimage.bbclass,
both of them use an UBOOT_LOADADDRESS variable to set the load address of
kernel and u-boot image and use an UBOOT_ENTRYPOINT variable to set the entry
address of
kernel and u-boot image.
However, users may want to set the different load address of u-boot
and kernel image. Therefore, adds UBOOT_FIT_UBOOT_LOADADDRESS
and UBOOT_FIT_UBOOT_ENTRYPOINT variables to set the
load address and entry point of u-boot image, respectively.
The value of UBOOT_FIT_UBOOT_ENTRYPOINT is UBOOT_LOADADDRESS by default.
The value of UBOOT_FIT_UBOOT_ENTRYPOINT is UBOOT_ENTRYPOINT by default.
Signed-off-by: Jamin Lin
---
meta/classes-recipe/uboot-sign.bbclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index ad04c82378..abde0bc61c 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -88,6 +88,9 @@ UBOOT_FIT_ADDRESS_CELLS ?= "1"
# This is only necessary for determining the signing configuration
KERNEL_PN = "${PREFERRED_PROVIDER_virtual/kernel}"
+UBOOT_FIT_UBOOT_LOADADDRESS ?= "${UBOOT_LOADADDRESS}"
+UBOOT_FIT_UBOOT_ENTRYPOINT ?= "${UBOOT_ENTRYPOINT}"
+
python() {
# We need u-boot-tools-native if we're creating a U-Boot fitImage
sign = d.getVar('UBOOT_SIGN_ENABLE') == '1'
@@ -248,8 +251,8 @@ uboot_fitimage_assemble() {
os = "u-boot";
arch = "${UBOOT_ARCH}";
compression = "none";
-load = <${UBOOT_LOADADDRESS}>;
-entry = <${UBOOT_ENTRYPOINT}>;
+load = <${UBOOT_FIT_UBOOT_LOADADDRESS}>;
+entry = <${UBOOT_FIT_UBOOT_ENTRYPOINT}>;
EOF
if [ "${SPL_SIGN_ENABLE}" = "1" ] ; then
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194010):
https://lists.openembedded.org/g/openembedded-core/message/194010
Mute This Topic: https://lists.openembedded.org/mt/103825447/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] pam: fix CVE-2024-22365 pam_namespace misses
Upstream-Status: Backport from
https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb
Signed-off-by: Hitendra Prajapati
---
.../pam/libpam/CVE-2024-22365.patch | 62 +++
meta/recipes-extended/pam/libpam_1.5.2.bb | 1 +
2 files changed, 63 insertions(+)
create mode 100644 meta/recipes-extended/pam/libpam/CVE-2024-22365.patch
diff --git a/meta/recipes-extended/pam/libpam/CVE-2024-22365.patch
b/meta/recipes-extended/pam/libpam/CVE-2024-22365.patch
new file mode 100644
index 00..e9e3a078e0
--- /dev/null
+++ b/meta/recipes-extended/pam/libpam/CVE-2024-22365.patch
@@ -0,0 +1,62 @@
+From 031bb5a5d0d950253b68138b498dc93be69a64cb Mon Sep 17 00:00:00 2001
+From: Matthias Gerstner
+Date: Wed, 27 Dec 2023 14:01:59 +0100
+Subject: [PATCH] pam_namespace: protect_dir(): use O_DIRECTORY to prevent
+ local DoS situations
+
+Without O_DIRECTORY the path crawling logic is subject to e.g. FIFOs
+being placed in user controlled directories, causing the PAM module to
+block indefinitely during `openat()`.
+
+Pass O_DIRECTORY to cause the `openat()` to fail if the path does not
+refer to a directory.
+
+With this the check whether the final path element is a directory
+becomes unnecessary, drop it.
+
+Upstream-Status: Backport
[https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb]
+CVE: CVE-2024-22365
+Signed-off-by: Hitendra Prajapati
+---
+ modules/pam_namespace/pam_namespace.c | 18 +-
+ 1 file changed, 1 insertion(+), 17 deletions(-)
+
+diff --git a/modules/pam_namespace/pam_namespace.c
b/modules/pam_namespace/pam_namespace.c
+index 4d4188d..d6b1d3c 100644
+--- a/modules/pam_namespace/pam_namespace.c
b/modules/pam_namespace/pam_namespace.c
+@@ -1103,7 +1103,7 @@ static int protect_dir(const char *path, mode_t mode,
int do_mkdir,
+ int dfd = AT_FDCWD;
+ int dfd_next;
+ int save_errno;
+- int flags = O_RDONLY;
++ int flags = O_RDONLY | O_DIRECTORY;
+ int rv = -1;
+ struct stat st;
+
+@@ -1157,22 +1157,6 @@ static int protect_dir(const char *path, mode_t mode,
int do_mkdir,
+ rv = openat(dfd, dir, flags);
+ }
+
+- if (rv != -1) {
+- if (fstat(rv, ) != 0) {
+- save_errno = errno;
+- close(rv);
+- rv = -1;
+- errno = save_errno;
+- goto error;
+- }
+- if (!S_ISDIR(st.st_mode)) {
+- close(rv);
+- errno = ENOTDIR;
+- rv = -1;
+- goto error;
+- }
+- }
+-
+ if (flags & O_NOFOLLOW) {
+ /* we are inside user-owned dir - protect */
+ if (protect_mount(rv, p, idata) == -1) {
+--
+2.25.1
+
diff --git a/meta/recipes-extended/pam/libpam_1.5.2.bb
b/meta/recipes-extended/pam/libpam_1.5.2.bb
index 0799102f8e..20745aa837 100644
--- a/meta/recipes-extended/pam/libpam_1.5.2.bb
+++ b/meta/recipes-extended/pam/libpam_1.5.2.bb
@@ -26,6 +26,7 @@ SRC_URI =
"https://github.com/linux-pam/linux-pam/releases/download/v${PV}/Linux
file://pam-volatiles.conf \
file://CVE-2022-28321-0002.patch \
file://0001-pam_motd-do-not-rely-on-all-filesystems-providing-a-.patch \
+ file://CVE-2024-22365.patch \
"
SRC_URI[sha256sum] =
"e4ec7131a91da44512574268f493c6d8ca105c87091691b8e9b56ca685d4f94d"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194009):
https://lists.openembedded.org/g/openembedded-core/message/194009
Mute This Topic: https://lists.openembedded.org/mt/103825246/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] devtool/standard: avoid KeyError
ping
On 12/26/23 12:44, Chen Qi via lists.openembedded.org wrote:
From: Chen Qi
The initial_revs["."] does not have an initial value, resulting
in the following error:
KeyError: '.'
The problem could be reproduced by running:
devtool modify -n systemd
Signed-off-by: Chen Qi
---
scripts/lib/devtool/standard.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 559fd45676..5d9b86ed6a 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -905,6 +905,7 @@ def modify(args, config, basepath, workspace):
(stdout, _) = bb.process.run('git rev-list --reverse
devtool-base..HEAD', cwd=submodule_path)
commits[submodule] = stdout.split()
else:
+initial_revs["."] = None
if os.path.exists(os.path.join(srctree, '.git')):
# Check if it's a tree previously extracted by us. This is
done
# by ensuring that devtool-base and args.branch (devtool)
exist.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194008):
https://lists.openembedded.org/g/openembedded-core/message/194008
Mute This Topic: https://lists.openembedded.org/mt/10330/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/3] systemd: upgrade to 255.1
What's the status of this patch series?
Is there any issue or concern that I missed?
Regards,
Qi
On 12/27/23 12:20, Chen Qi via lists.openembedded.org wrote:
From: Chen Qi
1. Patch changes:
0004-Move-sysusers.d-sysctl.d-binfmt.d-modules-load.d-to-.patch
is removed because it has no real effect now. The /lib is now
/usr/lib because 'usrmerge' is a required distro feature for systemd.
0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch is
refreshed for the new version to avoid patch-fuzz issue.
2. root user's home directory now defaults to "/root":
The sysuers.d/basic.conf is still modified to respect the ROOT_HOME
value, so if users set ROOT_HOME to "/home/root", the behavior is the
same as before. However, this is only for backward compatibility. With
this patch, The ROOT_HOME value is set to "/root" in init-manager-systemd.inc.
This is because systemd's source codes are hardcoding "/root", and other
values are not officially supported. See the list below.
$ grep -rl '"/root"' src/ | grep -v 'src/test'
src/core/namespace.c
src/basic/user-util.c
src/nss-systemd/nss-systemd.c
src/nspawn/nspawn.c
src/firstboot/firstboot.c
src/shared/userdb.c
src/shared/user-record.c
$ grep -rl /root network/ factory/ sysctl.d/ sysusers.d/ rules.d/ tmpfiles.d/
units/ xorg/ tools/
sysusers.d/basic.conf.in
tmpfiles.d/provision.conf
units/emergency.service.in
units/rescue.service.in
tools/list-discoverable-partitions.py
Previously, the recipe was just substituting sysusers.d/basic.conf.in,
which is not enough to be treated as 'fully support'. I deliberately put
a warning message in do_install to warn users about non "/root" ROOT_HOME
value. Don't remove it until all above places are handled.
3. cgroupv2 is now the default.
cgroupv2 is the default for systemd for many years and it's the default
for distros such as ubuntu and fedora. Let's also use it as the default.
Signed-off-by: Chen Qi
---
.../distro/include/init-manager-systemd.inc | 2 +
meta/recipes-core/systemd/systemd.inc | 4 +-
...tall-dependency-links-at-install-tim.patch | 22 +++---
...sysctl.d-binfmt.d-modules-load.d-to-.patch | 73 ---
.../systemd/systemd/basic.conf.in | 40 --
.../{systemd_254.4.bb => systemd_255.1.bb}| 16 ++--
6 files changed, 25 insertions(+), 132 deletions(-)
delete mode 100644
meta/recipes-core/systemd/systemd/0004-Move-sysusers.d-sysctl.d-binfmt.d-modules-load.d-to-.patch
delete mode 100644 meta/recipes-core/systemd/systemd/basic.conf.in
rename meta/recipes-core/systemd/{systemd_254.4.bb => systemd_255.1.bb} (98%)
diff --git a/meta/conf/distro/include/init-manager-systemd.inc
b/meta/conf/distro/include/init-manager-systemd.inc
index 595d1f2644..0a76647459 100644
--- a/meta/conf/distro/include/init-manager-systemd.inc
+++ b/meta/conf/distro/include/init-manager-systemd.inc
@@ -5,3 +5,5 @@ VIRTUAL-RUNTIME_init_manager ??= "systemd"
VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units"
VIRTUAL-RUNTIME_login_manager ??= "shadow-base"
VIRTUAL-RUNTIME_dev_manager ??= "systemd"
+# systemd hardcodes /root in its source codes, other values are not offically
supported
+ROOT_HOME ?= "/root"
diff --git a/meta/recipes-core/systemd/systemd.inc
b/meta/recipes-core/systemd/systemd.inc
index ccc3236457..1417e0150f 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -15,8 +15,8 @@ LICENSE:libsystemd = "LGPL-2.1-or-later"
LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
-SRCREV = "2e7504449a51fb38db9cd2da391c6434f82def51"
-SRCBRANCH = "v254-stable"
+SRCREV = "2018ccef6645ce00c784369a22dc4e98f6d7061d"
+SRCBRANCH = "v255-stable"
SRC_URI =
"git://github.com/systemd/systemd-stable.git;protocol=https;branch=${SRCBRANCH}"
S = "${WORKDIR}/git"
diff --git
a/meta/recipes-core/systemd/systemd/0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch
b/meta/recipes-core/systemd/systemd/0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch
index 085f1e9052..be231cf6b2 100644
---
a/meta/recipes-core/systemd/systemd/0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch
+++
b/meta/recipes-core/systemd/systemd/0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch
@@ -1,8 +1,8 @@
-From ca7d9a8d9c81702af9c599bb79706f12b1a465cf Mon Sep 17 00:00:00 2001
+From 29a58009a172e369ad7166e16dab2f4945c6b0d2 Mon Sep 17 00:00:00 2001
From: Chen Qi
Date: Thu, 21 Feb 2019 16:23:24 +0800
-Subject: [PATCH] binfmt: Don't install dependency links at install time for
- the binfmt services
+Subject: [PATCH 1/2] binfmt: Don't install dependency links at install time
+ for the binfmt services
use [Install] blocks so that they get created when the service is enabled
like a traditional service.
@@ -25,10 +25,10 @@ Signed-off-by: Scott Murray
3 files changed, 7
Re: [OE-core] [PATCH v3 1/2] shadow: update 4.13 -> 4.14.2
I'm seeing build failures on Ubuntu 20.04.
GCC version: 9.4.0
1. error: parameter name omitted
The problem is that the active_sessions_count function's definition
lacks parameter. I did change like below:
-unsigned long active_sessions_count(const char *name, unsigned long unused)
+unsigned long active_sessions_count(const char *name, unsigned long
unused unused_parameter)
But then I observed another error, as shown below.
2. undefined reference to `dlsym'.
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
../lib/.libs/libshadow.a(libshadow_la-nss.o): in function `nss_exit':
| nss.c:(.text+0x32): undefined reference to `dlclose'
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
../lib/.libs/libshadow.a(libshadow_la-nss.o): in function `nss_init':
| nss.c:(.text+0x1dd): undefined reference to `dlopen'
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
nss.c:(.text+0x21c): undefined reference to `dlsym'
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
nss.c:(.text+0x237): undefined reference to `dlsym'
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
nss.c:(.text+0x253): undefined reference to `dlsym'
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
nss.c:(.text+0x365): undefined reference to `dlclose'
| /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/hosttools/ld:
nss.c:(.text+0x3b2): undefined reference to `dlerror'
| collect2: error: ld returned 1 exit status
| make[2]: *** [Makefile:1130: su] Error 1
On Ubuntu22.04, there's no such issue.
Regards,
Qi
On 1/11/24 21:15, Alexander Kanavin wrote:
License-Update: formatting, spdx conversion
Drop:
0001-Disable-use-of-syslog-for-sysroot.patch
(issue fixed upstream)
0001-Fix-can-not-print-full-login.patch
0001-Overhaul-valid_field.patch
CVE-2023-29383.patch
(backports)
libbsd is a new native dependency, as otherwise glibc >= 2.38
is needed.
A similar fix is added to musl in order to define non-standard
__BEGIN_DECLS/__END_DECLS.
Signed-off-by: Alexander Kanavin
---
...01-Disable-use-of-syslog-for-sysroot.patch | 52 ---
.../0001-Fix-can-not-print-full-login.patch | 41 -
.../files/0001-Overhaul-valid_field.patch | 65
.../shadow/files/CVE-2023-29383.patch | 53 ---
.../shadow/files/CVE-2023-4641.patch | 147 --
...nexpected-open-failure-in-chroot-env.patch | 16 +-
meta/recipes-extended/shadow/shadow.inc | 20 +--
.../{shadow_4.13.bb => shadow_4.14.2.bb} | 0
8 files changed, 16 insertions(+), 378 deletions(-)
delete mode 100644
meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
delete mode 100644
meta/recipes-extended/shadow/files/0001-Fix-can-not-print-full-login.patch
delete mode 100644
meta/recipes-extended/shadow/files/0001-Overhaul-valid_field.patch
delete mode 100644 meta/recipes-extended/shadow/files/CVE-2023-29383.patch
delete mode 100644 meta/recipes-extended/shadow/files/CVE-2023-4641.patch
rename meta/recipes-extended/shadow/{shadow_4.13.bb => shadow_4.14.2.bb}
(100%)
diff --git
a/meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
b/meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
deleted file mode 100644
index fa1532c8317..000
---
a/meta/recipes-extended/shadow/files/0001-Disable-use-of-syslog-for-sysroot.patch
+++ /dev/null
@@ -1,52 +0,0 @@
-From 85d0444229ee3d14fefcf10d093f49c862826f82 Mon Sep 17 00:00:00 2001
-From: Richard Purdie
-Date: Thu, 14 Apr 2022 23:11:53 +
-Subject: [PATCH] Disable use of syslog for shadow-native tools
-
-Disable use of syslog to prevent sysroot user and group additions from
-writing entries to the host's syslog. This patch should only be used
-with the shadow-native recipe.
-
-Upstream-Status: Inappropriate [OE specific configuration]
-Signed-off-by: Richard Purdie
-Signed-off-by: Peter Kjellerstedt
-
- configure.ac | 2 +-
- src/login_nopam.c | 3 ++-
- 2 files changed, 3 insertions(+), 2 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 924254a..603af81 100644
a/configure.ac
-+++ b/configure.ac
-@@ -191,7 +191,7 @@ AC_DEFINE_UNQUOTED(PASSWD_PROGRAM,
"$shadow_cv_passwd_dir/passwd",
- [Path to passwd program.])
-
- dnl XXX - quick hack, should disappear before anyone notices :).
--AC_DEFINE(USE_SYSLOG, 1, [Define to use syslog().])
-+#AC_DEFINE(USE_SYSLOG, 1, [Define to use syslog().])
- if test "$ac_cv_func_ruserok" = "yes"; then
- AC_DEFINE(RLOGIN, 1, [Define if login should support the -r flag for
rlogind.])
- AC_DEFINE(RUSEROK, 0, [Define to the ruserok() "success" return value
(0 or 1).])
-diff --git a/src/login_nopam.c b/src/login_nopam.c
-index df6ba88..fc24e13 100644
a/src/login_nopam.c
-+++ b/src/login_nopam.c
-@@ -29,7 +29,6 @@
- #ifndef USE_PAM
- #ident "$Id$"
-
--#include "prototypes.h"
- /*
- * This module
[OE-core][kirkstone][PATCH] gnutls: Fix for CVE-2024-0553 and CVE-2024-0567
From: Vijay Anusuri
CVE-2024-0553
A vulnerability was found in GnuTLS. The response times to malformed
ciphertexts in RSA-PSK ClientKeyExchange differ from response times of
ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote
attacker to perform a timing side-channel attack in the RSA-PSK key exchange,
potentially leading to the leakage of sensitive data. CVE-2024-0553 is
designated as an incomplete resolution for CVE-2023-5981.
CVE-2024-0567
A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS)
rejects a certificate chain with distributed trust. This issue occurs when
validating a certificate chain with cockpit-certificate-ensure. This flaw
allows an unauthenticated, remote client or attacker to initiate a denial of
service attack.
Upstream-Status: Backport
[https://gitlab.com/gnutls/gnutls/-/commit/40dbbd8de499668590e8af51a15799fbc430595e
&
https://gitlab.com/gnutls/gnutls/-/commit/9edbdaa84e38b1bfb53a7d72c1de44f8de373405]
Reference: https://ubuntu.com/security/CVE-2024-0553
https://ubuntu.com/security/CVE-2024-0567
Signed-off-by: Vijay Anusuri
---
.../gnutls/gnutls/CVE-2024-0553.patch | 125
.../gnutls/gnutls/CVE-2024-0567.patch | 184 ++
meta/recipes-support/gnutls/gnutls_3.7.4.bb | 2 +
3 files changed, 311 insertions(+)
create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2024-0553.patch
create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2024-0567.patch
diff --git a/meta/recipes-support/gnutls/gnutls/CVE-2024-0553.patch
b/meta/recipes-support/gnutls/gnutls/CVE-2024-0553.patch
new file mode 100644
index 00..f15c470879
--- /dev/null
+++ b/meta/recipes-support/gnutls/gnutls/CVE-2024-0553.patch
@@ -0,0 +1,125 @@
+From 40dbbd8de499668590e8af51a15799fbc430595e Mon Sep 17 00:00:00 2001
+From: Daiki Ueno
+Date: Wed, 10 Jan 2024 19:13:17 +0900
+Subject: [PATCH] rsa-psk: minimize branching after decryption
+
+This moves any non-trivial code between gnutls_privkey_decrypt_data2
+and the function return in _gnutls_proc_rsa_psk_client_kx up until the
+decryption. This also avoids an extra memcpy to session->key.key.
+
+Signed-off-by: Daiki Ueno
+
+Upstream-Status: Backport
[https://gitlab.com/gnutls/gnutls/-/commit/40dbbd8de499668590e8af51a15799fbc430595e]
+CVE: CVE-2024-0553
+Signed-off-by: Vijay Anusuri
+---
+ lib/auth/rsa_psk.c | 68 --
+ 1 file changed, 35 insertions(+), 33 deletions(-)
+
+diff --git a/lib/auth/rsa_psk.c b/lib/auth/rsa_psk.c
+index 93c2dc9..c6cfb92 100644
+--- a/lib/auth/rsa_psk.c
b/lib/auth/rsa_psk.c
+@@ -269,7 +269,6 @@ _gnutls_proc_rsa_psk_client_kx(gnutls_session_t session,
uint8_t * data,
+ int ret, dsize;
+ 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)
+@@ -329,24 +328,48 @@ _gnutls_proc_rsa_psk_client_kx(gnutls_session_t session,
uint8_t * data,
+ ver_maj = _gnutls_get_adv_version_major(session);
+ ver_min = _gnutls_get_adv_version_minor(session);
+
+- premaster_secret.data = gnutls_malloc(GNUTLS_MASTER_SIZE);
+- if (premaster_secret.data == NULL) {
++ /* Find the key of this username. A random value will be
++ * filled in if the key is not found.
++ */
++ ret = _gnutls_psk_pwd_find_entry(session, info->username,
++ strlen(info->username), _psk);
++ if (ret < 0)
++ return gnutls_assert_val(ret);
++
++ /* Allocate memory for premaster secret, and fill in the
++ * fields except the decryption result.
++ */
++ session->key.key.size = 2 + GNUTLS_MASTER_SIZE + 2 + pwd_psk.size;
++ session->key.key.data = gnutls_malloc(session->key.key.size);
++ if (session->key.key.data == NULL) {
+ gnutls_assert();
++ _gnutls_free_key_datum(_psk);
++ /* No need to zeroize, as the secret is not copied in yet */
++ _gnutls_free_datum(>key.key);
+ return GNUTLS_E_MEMORY_ERROR;
+ }
+- premaster_secret.size = GNUTLS_MASTER_SIZE;
+
+ /* Fallback value when decryption fails. Needs to be unpredictable. */
+- ret = gnutls_rnd(GNUTLS_RND_NONCE, premaster_secret.data,
+- premaster_secret.size);
++ ret = gnutls_rnd(GNUTLS_RND_NONCE, session->key.key.data + 2,
++ GNUTLS_MASTER_SIZE);
+ if (ret < 0) {
+ gnutls_assert();
+- goto cleanup;
++ _gnutls_free_key_datum(_psk);
++ /* No need to zeroize, as the secret is not copied in yet */
++ _gnutls_free_datum(>key.key);
++ return ret;
+ }
+
++ _gnutls_write_uint16(GNUTLS_MASTER_SIZE, session->key.key.data);
++
[OE-core][dunfell][PATCH] sqlite3: Backport fix for CVE-2023-7104
From: Vijay Anusuri
Backport https://sqlite.org/src/info/0e4e7a05c4204b47
Signed-off-by: Vijay Anusuri
---
.../sqlite/files/CVE-2023-7104.patch | 46 +++
meta/recipes-support/sqlite/sqlite3_3.31.1.bb | 1 +
2 files changed, 47 insertions(+)
create mode 100644 meta/recipes-support/sqlite/files/CVE-2023-7104.patch
diff --git a/meta/recipes-support/sqlite/files/CVE-2023-7104.patch
b/meta/recipes-support/sqlite/files/CVE-2023-7104.patch
new file mode 100644
index 00..01ff29ff5e
--- /dev/null
+++ b/meta/recipes-support/sqlite/files/CVE-2023-7104.patch
@@ -0,0 +1,46 @@
+From eab426c5fba69d2c77023939f72b4ad446834e3c Mon Sep 17 00:00:00 2001
+From: dan
+Date: Thu, 7 Sep 2023 13:53:09 +
+Subject: [PATCH] Fix a buffer overread in the sessions extension that could
occur when processing a corrupt changeset.
+
+Upstream-Status: Backport [https://sqlite.org/src/info/0e4e7a05c4204b47]
+CVE: CVE-2023-7104
+Signed-off-by: Vijay Anusuri
+---
+ sqlite3.c | 18 +++---
+ 1 file changed, 11 insertions(+), 7 deletions(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 972ef18..c645ac8 100644
+--- a/sqlite3.c
b/sqlite3.c
+@@ -203301,15 +203301,19 @@ static int sessionReadRecord(
+ }
+ }
+ if( eType==SQLITE_INTEGER || eType==SQLITE_FLOAT ){
+-sqlite3_int64 v = sessionGetI64(aVal);
+-if( eType==SQLITE_INTEGER ){
+- sqlite3VdbeMemSetInt64(apOut[i], v);
++ if( (pIn->nData-pIn->iNext)<8 ){
++rc = SQLITE_CORRUPT_BKPT;
+ }else{
+- double d;
+- memcpy(, , 8);
+- sqlite3VdbeMemSetDouble(apOut[i], d);
++sqlite3_int64 v = sessionGetI64(aVal);
++if( eType==SQLITE_INTEGER ){
++ sqlite3VdbeMemSetInt64(apOut[i], v);
++}else{
++ double d;
++ memcpy(, , 8);
++ sqlite3VdbeMemSetDouble(apOut[i], d);
++}
++pIn->iNext += 8;
+ }
+-pIn->iNext += 8;
+ }
+ }
+ }
+--
+2.25.1
+
diff --git a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
index ef12ef0db2..0e7bcfa5a7 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb
@@ -17,6 +17,7 @@ SRC_URI =
"http://www.sqlite.org/2020/sqlite-autoconf-${SQLITE_PV}.tar.gz \
file://CVE-2020-35525.patch \
file://CVE-2020-35527.patch \
file://CVE-2021-20223.patch \
+ file://CVE-2023-7104.patch \
"
SRC_URI[md5sum] = "2d0a553534c521504e3ac3ad3b90f125"
SRC_URI[sha256sum] =
"62284efebc05a76f909c580ffa5c008a7d22a1287285d68b7825a2b6b51949ae"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194004):
https://lists.openembedded.org/g/openembedded-core/message/194004
Mute This Topic: https://lists.openembedded.org/mt/103823315/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][PATCHv2] openssl: fix CVE-2023-6237 Excessive time spent checking invalid RSA public keys
On 2024-01-17 11:09 a.m., Steve Sakoman via lists.openembedded.org wrote:
On Wed, Jan 17, 2024 at 1:47 AM Hitendra Prajapati via
lists.openembedded.org
wrote:
Upstream-Status: Backport
fromhttps://github.com/openssl/openssl/commit/e09fc1d746a4fd15bb5c3d7bbbab950aadd005db
Signed-off-by: Hitendra Prajapati
---
.../openssl/openssl/CVE-2023-6237.patch | 127 ++
.../openssl/openssl_3.0.12.bb | 3 +-
2 files changed, 129 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-connectivity/openssl/openssl/CVE-2023-6237.patch
diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2023-6237.patch
b/meta/recipes-connectivity/openssl/openssl/CVE-2023-6237.patch
new file mode 100644
index 00..621dc6b0ab
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/CVE-2023-6237.patch
@@ -0,0 +1,127 @@
+rom e09fc1d746a4fd15bb5c3d7bbbab950aadd005db Mon Sep 17 00:00:00 2001
+From: Tomas Mraz
+Date: Fri, 22 Dec 2023 16:25:56 +0100
+Subject: [PATCH] Limit the execution time of RSA public key check
+
+Fixes CVE-2023-6237
+
+If a large and incorrect RSA public key is checked with
+EVP_PKEY_public_check() the computation could take very long time
+due to no limit being applied to the RSA public key size and
+unnecessarily high number of Miller-Rabin algorithm rounds
+used for non-primality check of the modulus.
+
+Now the keys larger than 16384 bits (OPENSSL_RSA_MAX_MODULUS_BITS)
+will fail the check with RSA_R_MODULUS_TOO_LARGE error reason.
+Also the number of Miller-Rabin rounds was set to 5.
+
+Reviewed-by: Neil Horman
+Reviewed-by: Matt Caswell
+(Merged fromhttps://github.com/openssl/openssl/pull/23243)
+
+Upstream-Status: Backport
[https://github.com/openssl/openssl/commit/e09fc1d746a4fd15bb5c3d7bbbab950aadd005db]
+CVE: CVE-2023-6237
+Signed-off-by: Hitendra Prajapati
+---
+ crypto/rsa/rsa_sp800_56b_check.c | 8 +++-
+ test/recipes/91-test_pkey_check.t | 2 +-
+ .../91-test_pkey_check_data/rsapub_17k.pem| 48 +++
+ 3 files changed, 56 insertions(+), 2 deletions(-)
+ create mode 100644 test/recipes/91-test_pkey_check_data/rsapub_17k.pem
+
+diff --git a/crypto/rsa/rsa_sp800_56b_check.c
b/crypto/rsa/rsa_sp800_56b_check.c
+index fc8f19b..bcbdd24 100644
+--- a/crypto/rsa/rsa_sp800_56b_check.c
b/crypto/rsa/rsa_sp800_56b_check.c
+@@ -289,6 +289,11 @@ int ossl_rsa_sp800_56b_check_public(const RSA *rsa)
+ return 0;
+
+ nbits = BN_num_bits(rsa->n);
++if (nbits > OPENSSL_RSA_MAX_MODULUS_BITS) {
++ERR_raise(ERR_LIB_RSA, RSA_R_MODULUS_TOO_LARGE);
++return 0;
++}
++
+ #ifdef FIPS_MODULE
+ /*
+ * (Step a): modulus must be 2048 or 3072 (caveat from SP800-56Br1)
+@@ -324,7 +329,8 @@ int ossl_rsa_sp800_56b_check_public(const RSA *rsa)
+ goto err;
+ }
+
+-ret = ossl_bn_miller_rabin_is_prime(rsa->n, 0, ctx, NULL, 1, );
++/* Highest number of MR rounds from FIPS 186-5 Section B.3 Table B.1 */
++ret = ossl_bn_miller_rabin_is_prime(rsa->n, 5, ctx, NULL, 1, );
+ #ifdef FIPS_MODULE
+ if (ret != 1 || status != BN_PRIMETEST_COMPOSITE_NOT_POWER_OF_PRIME) {
+ #else
+diff --git a/test/recipes/91-test_pkey_check.t
b/test/recipes/91-test_pkey_check.t
+index dc7cc64..f8088df 100644
+--- a/test/recipes/91-test_pkey_check.t
b/test/recipes/91-test_pkey_check.t
+@@ -70,7 +70,7 @@ push(@positive_tests, (
+ "dhpkey.pem"
+ )) unless disabled("dh");
+
+-my @negative_pubtests = ();
++my @negative_pubtests = ("rsapub_17k.pem"); # Too big RSA public key
+
+ push(@negative_pubtests, (
+ "dsapub_noparam.der"
+diff --git a/test/recipes/91-test_pkey_check_data/rsapub_17k.pem
b/test/recipes/91-test_pkey_check_data/rsapub_17k.pem
+new file mode 100644
+index 000..9a2eaed
+--- /dev/null
b/test/recipes/91-test_pkey_check_data/rsapub_17k.pem
+@@ -0,0 +1,48 @@
++-BEGIN PUBLIC KEY-
++MIIIbzANBgkqhkiG9w0BAQEFAAOCCFwAMIIIVwKCCE4Ang+cE5H+hg3RbapDAHqR
++B9lUnp2MlAwsZxQ/FhYepaR60bFQeumbu7817Eo5YLMObVI99hF1C4u/qcpD4Jph
++gZt87/JAYDbP+DIh/5gUXCL9m5Fp4u7mvZaZdnlcftBvR1uKUTCAwc9pZ/Cfr8W2
++GzrRODzsNYnk2DcZMfe2vRDuDZRopE+Y+I72rom2SZLxoN547N1daM/M/CL9KVQ/
++XMI/YOpJrBI0jI3brMRhLkvLckwies9joufydlGbJkeil9H7/grj3fQZtFkZ2Pkj
++b87XDzRVX7wsEpAgPJxskL3jApokCp1kQYKG+Uc3dKM9Ade6IAPK7VKcmbAQTYw2
++gZxsc28dtstazmfGz0ACCTSMrmbgWAM3oPL7RRzhrXDWgmYQ0jHefGh8SNTIgtPq
++TuHxPYkDMQNaf0LmDGCxqlnf4b5ld3YaU8zZ/RqIRx5v/+w0rJUvU53qY1bYSnL1
++vbqKSnN2mip0GYyQ4AUgkS1NBV4rGYU/VTvzEjLfkg02KOtHKandvEoUjmZPzCT0
++V2ZhGc8K1UJNGYlIiHqCdwCBoghvly/pYajTkDXyd6BsukzA5H3IkZB1xDgl035j
++/0Cr7QeZLEOdi9fPdSSaBT6OmD0WFuZfJF0wMr7ucRhWzPXvSensD9v7MBE7tNfH
++SLeTSx8tLt8UeWriiM+0CnkPR1IOqMOxubOyf1eV8NQqEWm5wEQG/0IskbOKnaHa
++PqLFJZn/bvyL3XK5OxVIJG3z6bnRDOMS9SzkjqgPdIO8tkySEHVSi/6iuGUltx3Y
++Fmq6ye/r34ekyHPbfn6UuTON7joM6SIXb5bHM64x4iMVWx4hMvDjfy0UqfywAUyu
++C1o7BExSMxxFG8GJcqR0K8akpPp7EM588PC+YuItoxzXgfUJnP3BQ1Beev2Ve7/J
++xeGZH0N4ntfr+cuaLAakAER9zDglwChWflw3NNFgIdAgSxXv3XXx5xDXpdP4lxUo
[OE-core] [PATCH] openssl: Fix build on riscv
Backport a typo fix RISCV_HAS_ZKND_ZKNE -> RISCV_HAS_ZKND_AND_ZKNE
Signed-off-by: Khem Raj
---
...x-mispelling-of-extension-test-macro.patch | 31 +++
.../openssl/openssl_3.2.0.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl/0001-riscv-Fix-mispelling-of-extension-test-macro.patch
diff --git
a/meta/recipes-connectivity/openssl/openssl/0001-riscv-Fix-mispelling-of-extension-test-macro.patch
b/meta/recipes-connectivity/openssl/openssl/0001-riscv-Fix-mispelling-of-extension-test-macro.patch
new file mode 100644
index 000..1d217bd8e31
--- /dev/null
+++
b/meta/recipes-connectivity/openssl/openssl/0001-riscv-Fix-mispelling-of-extension-test-macro.patch
@@ -0,0 +1,31 @@
+From b51031b05f72923ff1cf3b6a4767450dee89d7f4 Mon Sep 17 00:00:00 2001
+From: Grant Nichol
+Date: Fri, 22 Dec 2023 23:46:39 -0600
+Subject: [PATCH] riscv: Fix mispelling of extension test macro
+
+When refactoring the riscv extension test macros,
+RISCV_HAS_ZKND_AND_ZKNE was mispelled.
+
+CLA: trivial
+Upstream-Status: Backport [https://github.com/openssl/openssl/pull/23139]
+Signed-off-by: Khem Raj
+---
+ providers/implementations/ciphers/cipher_aes_xts_hw.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/providers/implementations/ciphers/cipher_aes_xts_hw.c
b/providers/implementations/ciphers/cipher_aes_xts_hw.c
+index 564d6d6..4cf1361 100644
+--- a/providers/implementations/ciphers/cipher_aes_xts_hw.c
b/providers/implementations/ciphers/cipher_aes_xts_hw.c
+@@ -225,7 +225,7 @@ static const PROV_CIPHER_HW aes_xts_rv32i_zbkb_zknd_zkne =
{ \
+ # define PROV_CIPHER_HW_select_xts()
\
+ if (RISCV_HAS_ZBKB_AND_ZKND_AND_ZKNE())
\
+ return _xts_rv32i_zbkb_zknd_zkne;
\
+-if (RISCV_HAS_ZKND_ZKNE())
\
++if (RISCV_HAS_ZKND_AND_ZKNE())
\
+ return _xts_rv32i_zknd_zkne;
+ # else
+ /* The generic case */
+--
+2.43.0
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.2.0.bb
b/meta/recipes-connectivity/openssl/openssl_3.2.0.bb
index 29680b84ee7..f3d0ac165a3 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.2.0.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.2.0.bb
@@ -13,6 +13,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz
\
file://0001-Configure-do-not-tweak-mips-cflags.patch \
file://0001-Added-handshake-history-reporting-when-test-fails.patch
\
file://aarch64-bti.patch \
+ file://0001-riscv-Fix-mispelling-of-extension-test-macro.patch \
"
SRC_URI:append:class-nativesdk = " \
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194002):
https://lists.openembedded.org/g/openembedded-core/message/194002
Mute This Topic: https://lists.openembedded.org/mt/103819617/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/4] oeqa/runtime/rpm: raise exception if test rpm file cannot be found
Hello,
This fails pkgman-non-rpm:
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/8412
On 18/01/2024 11:24:06+0100, Alexander Kanavin wrote:
> The tests rely on that, and so the discovery shouldn't simply
> fall through.
>
> Signed-off-by: Alexander Kanavin
> ---
> meta/lib/oeqa/runtime/cases/rpm.py | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oeqa/runtime/cases/rpm.py
> b/meta/lib/oeqa/runtime/cases/rpm.py
> index a4ba4e67698..bd9050a81b2 100644
> --- a/meta/lib/oeqa/runtime/cases/rpm.py
> +++ b/meta/lib/oeqa/runtime/cases/rpm.py
> @@ -88,9 +88,12 @@ class RpmInstallRemoveTest(OERuntimeTestCase):
> # and it will always be built for standard targets
> rpm_doc = 'base-passwd-doc-*.%s.rpm' % pkgarch
> if not os.path.exists(rpmdir):
> -return
> +raise Exception("Rpm directory {} does not
> exist".format(cls.tc.td['DEPLOY_DIR']))
> for f in fnmatch.filter(os.listdir(rpmdir), rpm_doc):
> cls.test_file = os.path.join(rpmdir, f)
> +break
> +else:
> +raise Exception("Couldn't find the test rpm file {} in
> {}".format(rpm_doc, rpmdir))
> cls.dst = '/tmp/base-passwd-doc.rpm'
>
> @OETestDepends(['rpm.RpmBasicTest.test_rpm_query'])
> --
> 2.39.2
>
>
>
>
--
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 (#194001):
https://lists.openembedded.org/g/openembedded-core/message/194001
Mute This Topic: https://lists.openembedded.org/mt/103805481/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: Patchtest results for [OE-core][kirkstone][PATCH 1/1] tiff: fix CVE-2023-6228
On Thu, Jan 18, 2024 at 12:21 PM Randy MacLeod wrote: > Yogita, > Pleae tell people if you will send a v2 or if you plan to fix the warning > in a follow-up commit. > > I don't see your commit in Steve's kirkstone-nut repo so I think he's > expecting a v2. > > > https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut > \ > I was expecting a response as to which approach would be taken. When there was no response I removed the patch under the theory that it is better not to merge a half right CVE fix. Steve > Forwarded Message > Subject: Patchtest results for [OE-core][kirkstone][PATCH 1/1] tiff: fix > CVE-2023-6228 > Date: Thu, 18 Jan 2024 11:03:04 + > From: Patchtest via lists.openembedded.org > > > Reply-To: patcht...@automation.yoctoproject.org > To: yurade > CC: openembedded-core@lists.openembedded.org > > Thank you for your submission. Patchtest identified one > or more issues with the patch. Please see the log below for > more information: > > --- > Testing patch > /home/patchtest/share/mboxes/kirkstone-1-1-tiff-fix-CVE-2023-6228.patch > > FAIL: test CVE check ignore: CVE_CHECK_IGNORE is deprecated and should be > replaced by CVE_STATUS (test_metadata.TestMetadata.test_cve_check_ignore) > > PASS: pretest src uri left files > (test_metadata.TestMetadata.pretest_src_uri_left_files) > PASS: test CVE tag format (test_patch.TestPatch.test_cve_tag_format) > PASS: test Signed-off-by presence > (test_mbox.TestMbox.test_signed_off_by_presence) > PASS: test Signed-off-by presence > (test_patch.TestPatch.test_signed_off_by_presence) > PASS: test Upstream-Status presence > (test_patch.TestPatch.test_upstream_status_presence_format) > PASS: test author valid (test_mbox.TestMbox.test_author_valid) > PASS: test commit message presence > (test_mbox.TestMbox.test_commit_message_presence) > PASS: test lic files chksum modified not mentioned > (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned) > PASS: test max line length > (test_metadata.TestMetadata.test_max_line_length) > PASS: test mbox format (test_mbox.TestMbox.test_mbox_format) > PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade) > PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format) > PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length) > PASS: test src uri left files > (test_metadata.TestMetadata.test_src_uri_left_files) > > SKIP: pretest pylint: No python related patches, skipping test > (test_python_pylint.PyLint.pretest_pylint) > SKIP: test bugzilla entry format: No bug ID found > (test_mbox.TestMbox.test_bugzilla_entry_format) > SKIP: test lic files chksum presence: No added recipes, skipping test > (test_metadata.TestMetadata.test_lic_files_chksum_presence) > SKIP: test license presence: No added recipes, skipping test > (test_metadata.TestMetadata.test_license_presence) > SKIP: test pylint: No python related patches, skipping test > (test_python_pylint.PyLint.test_pylint) > SKIP: test series merge on head: Merge test is disabled for now > (test_mbox.TestMbox.test_series_merge_on_head) > SKIP: test summary presence: No added recipes, skipping test > (test_metadata.TestMetadata.test_summary_presence) > SKIP: test target mailing list: Series merged, no reason to check other > mailing lists (test_mbox.TestMbox.test_target_mailing_list) > > --- > > Please address the issues identified and > submit a new revision of the patch, or alternatively, reply to this > email with an explanation of why the patch should be accepted. If you > believe these results are due to an error in patchtest, please submit a > bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category > under 'Yocto Project Subprojects'). For more information on specific > failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank > you! > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194000): https://lists.openembedded.org/g/openembedded-core/message/194000 Mute This Topic: https://lists.openembedded.org/mt/103805851/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Patchtest results for [OE-core][kirkstone][PATCH 1/1] tiff: fix CVE-2023-6228
Yogita, Pleae tell people if you will send a v2 or if you plan to fix the warning in a follow-up commit. I don't see your commit in Steve's kirkstone-nut repo so I think he's expecting a v2. https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut ../Randy Forwarded Message Subject: Patchtest results for [OE-core][kirkstone][PATCH 1/1] tiff: fix CVE-2023-6228 Date: Thu, 18 Jan 2024 11:03:04 + From: Patchtest via lists.openembedded.org Reply-To: patcht...@automation.yoctoproject.org To: yurade CC: openembedded-core@lists.openembedded.org Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/kirkstone-1-1-tiff-fix-CVE-2023-6228.patch FAIL: test CVE check ignore: CVE_CHECK_IGNORE is deprecated and should be replaced by CVE_STATUS (test_metadata.TestMetadata.test_cve_check_ignore) PASS: pretest src uri left files (test_metadata.TestMetadata.pretest_src_uri_left_files) PASS: test CVE tag format (test_patch.TestPatch.test_cve_tag_format) PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence) PASS: test Signed-off-by presence (test_patch.TestPatch.test_signed_off_by_presence) PASS: test Upstream-Status presence (test_patch.TestPatch.test_upstream_status_presence_format) PASS: test author valid (test_mbox.TestMbox.test_author_valid) PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence) PASS: test lic files chksum modified not mentioned (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned) PASS: test max line length (test_metadata.TestMetadata.test_max_line_length) PASS: test mbox format (test_mbox.TestMbox.test_mbox_format) PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade) PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format) PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length) PASS: test src uri left files (test_metadata.TestMetadata.test_src_uri_left_files) SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint) SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format) SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence) SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence) SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint) SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head) SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence) SKIP: test target mailing list: Series merged, no reason to check other mailing lists (test_mbox.TestMbox.test_target_mailing_list) --- Please address the issues identified and submit a new revision of the patch, or alternatively, reply to this email with an explanation of why the patch should be accepted. If you believe these results are due to an error in patchtest, please submit a bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category under 'Yocto Project Subprojects'). For more information on specific failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank you! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193975): https://lists.openembedded.org/g/openembedded-core/message/193975 Mute This Topic: https://lists.openembedded.org/mt/103805851/3616765 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [randy.macl...@windriver.com] -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193999): https://lists.openembedded.org/g/openembedded-core/message/193999 Mute This Topic: https://lists.openembedded.org/mt/103805851/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] rust: Enable rust oe-selftest
On 2024-01-18 5:57 a.m., yash.shi...@windriver.com wrote:
From: Yash Shinde
Enable rust oe-selftest for rust 1.74.1 version and
add target_cfg.patch to handle target configurations
for custom targets.
Hi Yashe,
Yay, getting the rust test suite working again great news!
We talked about this in today's YP bug review and decided NOT to merge this
until after the M2 build is taken care of over the next few days.
That gives me a chance to review the commit and ask some questions! ;-)
First, your commit log should be expanded to explain what has changed at
a high level
to someone who is just reading "git log".
What you have is a good start but I'd like more info on what changed in:
meta/lib/oeqa/selftest/cases/rust.py
There are lots of tests added to the exclude list and some seem to have
just moved.
Please explain why you did this and if there is any way to avoid the
"noise" of moved tests in future updates. Could you also report on the
number of newly disabled tests and try to summarize in the commit log
what these tests are doing and
Ah, I see what you have done: 1. sort the exclude list 2. add the newly
excluded tests. Please do that in separate commits so that it's easier
to understand. This will reduce the size of the "Enable rust
oe-selftest" diff for meta/lib/oeqa/selftest/cases/rust.py from: | 103
- to: | 37 +++-
and let people easily see that most of the newly excluded tests are in
tests/codegen .
That reminds me, do we really need to list directories in that exclude
list or only list .rs files?
If I save the list to /tmp/jj, you can see that we could reduce the list
by 34 lines:
❯ rg "\.rs" /tmp/jj | wc -l 203 ❯ rg -v "\.rs" /tmp/jj | wc -l 34
If we can do that, again do it as a separate commit since it should not
affect the outcome of the test.
Also this backport link:
https://github.com/rust-lang/rust/pull/119619/commits
is actually 3 separate commits so it might be better to apply those
individually
so that we can know when they can be dropped by running:
$ git tag --contains on each commit
Also in the patches, please add you Signed-Off-By line but keep the
upstream author's S-O-B line.
For anyone interested we did talk about the number of Rust tests that we
are excluding and of course our goal is to work with the upstream Rust
community to reduce the number of excluded tests over the coming months
but for now, it's just nice to see the test working again!
If you update these things convince yourself that the changes are
functionally identical, I don't think there's any need to re-do all the
testing that you have done.
Thanks Yash,
../Randy
The testing is done on arm32, arm64, mips64, x86 and x86_64 targets.
Signed-off-by: Yash Shinde
---
meta/lib/oeqa/selftest/cases/rust.py | 103 -
.../rust/files/target_cfg.patch | 144 ++
meta/recipes-devtools/rust/rust-source.inc| 1 +
3 files changed, 214 insertions(+), 34 deletions(-)
create mode 100644 meta/recipes-devtools/rust/files/target_cfg.patch
diff --git a/meta/lib/oeqa/selftest/cases/rust.py
b/meta/lib/oeqa/selftest/cases/rust.py
index 6dbc517006..216c73e5d1 100644
--- a/meta/lib/oeqa/selftest/cases/rust.py
+++ b/meta/lib/oeqa/selftest/cases/rust.py
@@ -40,7 +40,7 @@ def parse_results(filename):
class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
def test_rust(self, *args, **kwargs):
# Disable Rust Oe-selftest
-self.skipTest("The Rust Oe-selftest is disabled.")
+#self.skipTest("The Rust Oe-selftest is disabled.")
# build remote-test-server before image build
recipe = "rust"
@@ -73,38 +73,71 @@ class RustSelfTestSystemEmulated(OESelftestTestCase,
OEPTestResultTestCase):
'src/librustdoc',
'src/rustdoc-json-types',
'src/tools/compiletest/src/common.rs',
+'src/tools/jsondoclint',
'src/tools/lint-docs',
+'src/tools/replace-version-placeholder',
'src/tools/rust-analyzer',
'src/tools/rustdoc-themes',
'src/tools/tidy',
'tests/assembly/asm/aarch64-outline-atomics.rs',
+'tests/codegen/abi-efiapi.rs',
+'tests/codegen/abi-efiapi.rs',
'tests/codegen/abi-main-signature-32bit-c-int.rs',
'tests/codegen/abi-repr-ext.rs',
+'tests/codegen/abi-sysv64.rs',
'tests/codegen/abi-x86-interrupt.rs',
+'tests/codegen/align-byval.rs',
+'tests/codegen/align-fn.rs',
+'tests/codegen/asm-powerpc-clobbers.rs',
+
[v3][oe-core][PATCH 1/1] eudev: modify predictable network if name search
From: Joe Slater
Consider a name based on mac address in addition to
those based on slot or path.
Note that as of this commit predictable naming is
suppressed by eudev, but can be enabled by removing
/etc/udev/rules.d/80-net-name-slot.rules from the
root filesystem.
Signed-off-by: Joe Slater
---
meta/recipes-core/udev/eudev/netifnames.patch | 17 +
meta/recipes-core/udev/eudev_3.2.14.bb| 2 ++
2 files changed, 19 insertions(+)
create mode 100644 meta/recipes-core/udev/eudev/netifnames.patch
diff --git a/meta/recipes-core/udev/eudev/netifnames.patch
b/meta/recipes-core/udev/eudev/netifnames.patch
new file mode 100644
index 00..8f6e9a1538
--- /dev/null
+++ b/meta/recipes-core/udev/eudev/netifnames.patch
@@ -0,0 +1,17 @@
+eudev: consider ID_NET_NAME_MAC as an interface name
+
+eudev might not create names based on slot or path.
+
+Upstream-Status: Submitted [github.com/eudev-project/eudev/pull/274]
+
+Signed-off-by: Joe Slater
+
+--- a/rules/80-net-name-slot.rules
b/rules/80-net-name-slot.rules
+@@ -10,5 +10,6 @@ ENV{net.ifnames}=="0", GOTO="net_name_sl
+ NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
+ NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
+ NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
++NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}"
+
+ LABEL="net_name_slot_end"
diff --git a/meta/recipes-core/udev/eudev_3.2.14.bb
b/meta/recipes-core/udev/eudev_3.2.14.bb
index d0758691bd..ddb3c3340f 100644
--- a/meta/recipes-core/udev/eudev_3.2.14.bb
+++ b/meta/recipes-core/udev/eudev_3.2.14.bb
@@ -10,6 +10,7 @@ DEPENDS = "gperf-native"
PROVIDES = "udev"
SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/${BP}.tar.gz \
+ file://netifnames.patch \
file://init \
file://local.rules \
"
@@ -50,6 +51,7 @@ do_install:append() {
# Use classic network interface naming scheme
touch ${D}${sysconfdir}/udev/rules.d/80-net-name-slot.rules
+
}
do_install:prepend:class-target () {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193997):
https://lists.openembedded.org/g/openembedded-core/message/193997
Mute This Topic: https://lists.openembedded.org/mt/103813827/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] rng-tools: Revert "rng-tools: move to meta-oe"
Sorry for the noise and back and forth on rng-tools removal. I'll avoid hastily cleaning up things for a while! ;-) On 2024-01-18 11:59 a.m., Randy MacLeod via lists.openembedded.org wrote: From: Randy MacLeod This reverts commit d2b445384da3f3e6dab8577b6c56648b5244a788. Revert this commit since: - some systems using oe-core master may still be using kernels from before 5.6 pulled in the rng-tools algorithm, and - some hardware platforms may not have a hardware random number generator and could therefore need to run rngd to avoid long boot-time initialization due to a depleted entropy pool. The additional context that doesn't belong in the commit log is that we talked about this change in the YP bug review meeting and decided that we would keep rng-tools in oe-core for 5.0-M2 for the two reasons given above. If we end up adding a test, as described below, we may never move the recipe to meta-oe. It seems to me that we need a test that checks if the entropy pool size ever falls below a critical threshold for "too long" in the first N seconds of boot time. Getting that test written so that: - qemu VMs and - real HW with and without /dev/hwrng all pass without the test being too permissive may take some time. I've created a bug to track adding such a test: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15360 Scott, Do you have any info on the need for rngd on HW without /dev/hwrng but with a kernel >= 5.6 ? ../Randy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193996): https://lists.openembedded.org/g/openembedded-core/message/193996 Mute This Topic: https://lists.openembedded.org/mt/103812401/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] linux-firmware: fix mediatek MT76x empty license package
From: Timotheus Giuliani
Installing the linux-firmware-dev package fails because of the following
problem.
For each mediatek MT76x firmware a separate license package was declared.
In all these license packages the same file was referenced as the license file.
This meant that if several of these packages were used at the same time,
the license packages would be empty.
This commit defines a common license package for the mediatek MT76x packages,
which is then referenced by all of them.
Fixes: dfb7d2c426b4 ("linux-firmware: create separate packages")
Signed-off-by: Julian Haller
---
.../linux-firmware/linux-firmware_20231211.bb | 23 ++-
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
index 16cf8e241b..9347cde298 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
@@ -263,9 +263,7 @@ do_install() {
PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
${PN}-cw1200-license ${PN}-cw1200 \
${PN}-ralink-license ${PN}-ralink \
- ${PN}-mt7601u-license ${PN}-mt7601u \
- ${PN}-mt7650-license ${PN}-mt7650 \
- ${PN}-mt76x2-license ${PN}-mt76x2 \
+ ${PN}-mt76x-license ${PN}-mt7601u ${PN}-mt7650 ${PN}-mt76x2 \
${PN}-radeon-license ${PN}-radeon \
${PN}-amdgpu-license ${PN}-amdgpu \
${PN}-marvell-license ${PN}-pcie8897 ${PN}-pcie8997 \
@@ -507,43 +505,36 @@ FILES:${PN}-ralink = " \
RDEPENDS:${PN}-ralink += "${PN}-ralink-license"
# For mediatek MT7601U
+LICENSE:${PN}-mt76x-license = "Firmware-ralink_a_mediatek_company_firmware"
+FILES:${PN}-mt76x-license =
"${nonarch_base_libdir}/firmware/LICENCE.ralink_a_mediatek_company_firmware"
+
LICENSE:${PN}-mt7601u = "Firmware-ralink_a_mediatek_company_firmware"
-LICENSE:${PN}-mt7601u-license = "Firmware-ralink_a_mediatek_company_firmware"
-FILES:${PN}-mt7601u-license =
"${nonarch_base_libdir}/firmware/LICENCE.ralink_a_mediatek_company_firmware"
FILES:${PN}-mt7601u = " \
${nonarch_base_libdir}/firmware/mediatek/mt7601u.bin \
${nonarch_base_libdir}/firmware/mt7601u.bin \
"
-RDEPENDS:${PN}-mt7601u += "${PN}-mt7601u-license"
+RDEPENDS:${PN}-mt7601u += "${PN}-mt76x-license"
# For MediaTek Bluetooth USB driver 7650
LICENSE:${PN}-mt7650 = "Firmware-ralink_a_mediatek_company_firmware"
-LICENSE:${PN}-mt7650-license = "Firmware-ralink_a_mediatek_company_firmware"
-FILES:${PN}-mt7650-license = " \
- ${nonarch_base_libdir}/firmware/LICENCE.ralink_a_mediatek_company_firmware \
-"
FILES:${PN}-mt7650 = " \
${nonarch_base_libdir}/firmware/mediatek/mt7650.bin \
${nonarch_base_libdir}/firmware/mt7650.bin \
"
-RDEPENDS:${PN}-mt7650 += "${PN}-mt7650-license"
+RDEPENDS:${PN}-mt7650 += "${PN}-mt76x-license"
# For MediaTek MT76x2 Wireless MACs
LICENSE:${PN}-mt76x2 = "Firmware-ralink_a_mediatek_company_firmware"
-LICENSE:${PN}-mt76x2-license = "Firmware-ralink_a_mediatek_company_firmware"
-FILES:${PN}-mt76x2-license = " \
- ${nonarch_base_libdir}/firmware/LICENCE.ralink_a_mediatek_company_firmware \
-"
FILES:${PN}-mt76x2 = " \
${nonarch_base_libdir}/firmware/mediatek/mt7662.bin \
${nonarch_base_libdir}/firmware/mt7662.bin \
${nonarch_base_libdir}/firmware/mediatek/mt7662_rom_patch.bin \
${nonarch_base_libdir}/firmware/mt7662_rom_patch.bin \
"
-RDEPENDS:${PN}-mt76x2 += "${PN}-mt76x2-license"
+RDEPENDS:${PN}-mt76x2 += "${PN}-mt76x-license"
# For MediaTek
LICENSE:${PN}-mediatek = "Firmware-mediatek"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193995):
https://lists.openembedded.org/g/openembedded-core/message/193995
Mute This Topic: https://lists.openembedded.org/mt/103813302/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] rng-tools: Revert "rng-tools: move to meta-oe"
From: Randy MacLeod
This reverts commit d2b445384da3f3e6dab8577b6c56648b5244a788.
Revert this commit since:
- some systems using oe-core master may still be using kernels from
before 5.6 pulled in the rng-tools algorithm, and
- some hardware platforms may not have a hardware random number generator
and could therefore need to run rngd to avoid long boot-time initialization
due to a depleted entropy pool.
Signed-off-by: Randy MacLeod
---
meta/conf/distro/include/maintainers.inc | 1 +
.../rng-tools/rng-tools/default | 1 +
meta/recipes-support/rng-tools/rng-tools/init | 42 +++
.../rng-tools/rng-tools/rng-tools.service | 32 +
.../rng-tools/rng-tools_6.16.bb | 69 +++
5 files changed, 145 insertions(+)
create mode 100644 meta/recipes-support/rng-tools/rng-tools/default
create mode 100644 meta/recipes-support/rng-tools/rng-tools/init
create mode 100644 meta/recipes-support/rng-tools/rng-tools/rng-tools.service
create mode 100644 meta/recipes-support/rng-tools/rng-tools_6.16.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 31023021ac..8dc63b138e 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -739,6 +739,7 @@ RECIPE_MAINTAINER:pn-repo = "Unassigned
"
RECIPE_MAINTAINER:pn-resolvconf = "Chen Qi "
RECIPE_MAINTAINER:pn-rgb = "Unassigned "
RECIPE_MAINTAINER:pn-rpcbind = "Hongxu Jia "
+RECIPE_MAINTAINER:pn-rng-tools = "Anuj Mittal "
RECIPE_MAINTAINER:pn-rpcsvc-proto = "Khem Raj "
RECIPE_MAINTAINER:pn-rpm = "Unassigned "
RECIPE_MAINTAINER:pn-rsync = "Yi Zhao "
diff --git a/meta/recipes-support/rng-tools/rng-tools/default
b/meta/recipes-support/rng-tools/rng-tools/default
new file mode 100644
index 00..b9f8e03635
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools/default
@@ -0,0 +1 @@
+EXTRA_ARGS="-r /dev/hwrng"
diff --git a/meta/recipes-support/rng-tools/rng-tools/init
b/meta/recipes-support/rng-tools/rng-tools/init
new file mode 100644
index 00..13f0ecd37c
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools/init
@@ -0,0 +1,42 @@
+#!/bin/sh
+#
+# This is an init script for openembedded
+# Copy it to @SYSCONFDIR@/init.d/rng-tools and type
+# > update-rc.d rng-tools defaults 60
+#
+
+rngd=@SBINDIR@/rngd
+test -x "$rngd" || exit 1
+
+[ -r @SYSCONFDIR@/default/rng-tools ] && . "@SYSCONFDIR@/default/rng-tools"
+
+case "$1" in
+ start)
+echo -n "Starting random number generator daemon"
+start-stop-daemon -S -q -x $rngd -- $EXTRA_ARGS
+echo "."
+;;
+ stop)
+echo -n "Stopping random number generator daemon"
+start-stop-daemon -K -q -n rngd
+echo "."
+;;
+ reload|force-reload)
+echo -n "Signalling rng daemon restart"
+start-stop-daemon -K -q -s 1 -x $rngd
+start-stop-daemon -K -q -s 1 -x $rngd
+;;
+ restart)
+echo -n "Stopping random number generator daemon"
+start-stop-daemon -K -q -n rngd
+echo "."
+echo -n "Starting random number generator daemon"
+start-stop-daemon -S -q -x $rngd -- $EXTRA_ARGS
+echo "."
+;;
+ *)
+echo "Usage: @SYSCONFDIR@/init.d/rng-tools
{start|stop|reload|restart|force-reload}"
+exit 1
+esac
+
+exit 0
diff --git a/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
new file mode 100644
index 00..5ae2fba215
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
@@ -0,0 +1,32 @@
+[Unit]
+Description=Hardware RNG Entropy Gatherer Daemon
+DefaultDependencies=no
+Conflicts=shutdown.target
+Before=sysinit.target shutdown.target
+ConditionVirtualization=!container
+
+[Service]
+EnvironmentFile=-@SYSCONFDIR@/default/rng-tools
+ExecStart=@SBINDIR@/rngd -f $EXTRA_ARGS
+CapabilityBoundingSet=CAP_SYS_ADMIN
+IPAddressDeny=any
+LockPersonality=yes
+MemoryDenyWriteExecute=yes
+NoNewPrivileges=yes
+PrivateTmp=yes
+ProtectControlGroups=yes
+ProtectHome=yes
+ProtectHostname=yes
+ProtectKernelModules=yes
+ProtectKernelLogs=yes
+ProtectSystem=strict
+RestrictAddressFamilies=AF_UNIX
+RestrictNamespaces=yes
+RestrictRealtime=yes
+RestrictSUIDSGID=yes
+SystemCallArchitectures=native
+SystemCallErrorNumber=EPERM
+SystemCallFilter=@system-service
+
+[Install]
+WantedBy=sysinit.target
diff --git a/meta/recipes-support/rng-tools/rng-tools_6.16.bb
b/meta/recipes-support/rng-tools/rng-tools_6.16.bb
new file mode 100644
index 00..f0aa3ff93f
--- /dev/null
+++ b/meta/recipes-support/rng-tools/rng-tools_6.16.bb
@@ -0,0 +1,69 @@
+SUMMARY = "Random number generator daemon"
+DESCRIPTION = "Check and feed random data from hardware device to kernel"
+HOMEPAGE = "https://github.com/nhorman/rng-tools;
+BUGTRACKER = "https://github.com/nhorman/rng-tools/issues;
+LICENSE = "GPL-2.0-only"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+DEPENDS = "openssl libcap"
+
[OE-core] [PATCH] reproducible: Fix race with externalsrc/devtool over lockfile
We occasionally see races over the lockfile used by externalsrc/devtool when walking files for the source_date_epock calculation. Skip this file if present to avoid the issues and fix a real issue where SDE could be contaminated too. [YOCTO #14921] Signed-off-by: Richard Purdie --- meta/lib/oe/reproducible.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/lib/oe/reproducible.py b/meta/lib/oe/reproducible.py index 9ac75c02e38..448befce332 100644 --- a/meta/lib/oe/reproducible.py +++ b/meta/lib/oe/reproducible.py @@ -131,6 +131,9 @@ def get_source_date_epoch_from_youngest_file(d, sourcedir): files = [f for f in files if not f[0] == '.'] for fname in files: +if fname == "singletask.lock": + # Ignore externalsrc/devtool lockfile [YOCTO #14921] + continue filename = os.path.join(root, fname) try: mtime = int(os.lstat(filename).st_mtime) -- 2.40.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193993): https://lists.openembedded.org/g/openembedded-core/message/193993 Mute This Topic: https://lists.openembedded.org/mt/103810133/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 v3 2/2] shadow: link executables statically for -native variant
On Thu, 18 Jan 2024 at 15:51, Richard Purdie
wrote:
>
> On Thu, 2024-01-18 at 15:37 +0200, Dmitry Baryshkov wrote:
> > On Thu, 18 Jan 2024 at 11:59, Richard Purdie
> > wrote:
> > >
> > > On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > > > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > > > wrote:
> > > > >
> > > > > shadow 4.14.x adds a number of libraries it dynamically links with
> > > > > (md, bsd, attr). This causes troubles in setscene tasks where
> > > > > shadow executables are used (such as useradd), as pulling in
> > > > > the needed dynamic libraries needs unpleasant special-casing.
> > > > >
> > > > > Signed-off-by: Alexander Kanavin
> > > >
> > > > It seems, this is causing issues with the TuxOE builds. We have been
> > > > observing issues with the TuxOE build environment with the image
> > > > creation choking on the home dirs. Reverting this patch seems to fix
> > > > the problem. The build environment is Ubuntu 20.04 running in a
> > > > container on Ubuntu 22.04.
> > > >
> > > > ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> > > > ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> > > > 1, None, None)
> > > > ERROR: Logfile of failure stored in:
> > > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> > > > Log data follows:
> > > > > DEBUG: Executing python function set_image_size
> > > > > DEBUG: 1402908.00 = 1079160 * 1.30
> > > > > DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> > > > > DEBUG: 1402908.00 = int(1402908.00)
> > > > > DEBUG: 1404928 = aligned(1402908)
> > > > > DEBUG: returning 1404928
> > > > > DEBUG: Python function set_image_size finished
> > > > > DEBUG: Executing shell function do_image_tar
> > > > > tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> > > > > tar: ./home/linaro/.profile: Unknown file type; file ignored
> > > > > tar: Exiting with failure status due to previous errors
> > > > > WARNING:
> > > > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> > > > exit 1 from '[ $? -eq 1 ]'
> > > >
> > >
> > > The error is coming from tar during archive creation, "Unknown file
> > > type; file ignored". I'm a little confused/concerned about what it is
> > > seeing which it can't handle.
> > >
> > > It might also be good to work out if that is tar from the host or tar
> > > from tar-native. Is the host's tar unable to support something we're
> > > relying upon?
> > >
> > > If it were me, I'd probably have a look into the tar source code too,
> > > see what might trigger an error like that.
> >
> > I compared this to the ext4 creation error. The code for __populate_fs
> > is more easy to follow. Basically this error means that st.st_mode
> > doesn't match S_IFCHR, S_IFBLK, S_IFREG and S_IFDIR checks.
> > I assume the files in home dir are created by useradd in some way that
> > bypasses pseudo. Then when tar / mkfs are executed, pseudo doesn't
> > know about the file and returns bad st_mode through lstat().
>
> Files shouldn't be getting created in useradd that pseudo doesn't know
> about. If they are, we could be missing an intercept on some glibc
> function call for example.
>
> Is this in a multiple worker setup with a shared sstate? We need to
> track down which OS the escape is happening on. In theory it should be
> reproducible. Do you have anything with a bleeding edge glibc there
> (e.g. gentoo)?
We initially saw this on Ubuntu 20.04 inside the docker on top Ubuntu
22.04 host. Then Vishal was able to reproduce this on bare Ubuntu
22.04 host.
Bisection points to this particular patch, so I assume that static
linking causes some issue here. E.g. getting one of syscalls inlined
in one of these static libs, so that pseudo is no longer able to
override it.
--
With best wishes
Dmitry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193992):
https://lists.openembedded.org/g/openembedded-core/message/193992
Mute This Topic: https://lists.openembedded.org/mt/103661548/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] uboot-sign.bbclass: Break dependency loop in fitImage signing
This commit creates a dummy fitImage to feed to mkimage when adding the
public key to the U-Boot dtb. This instead of using the Linux fitImage.
The dependency on Linux fitImage availability from U-Boot recipes can
then be removed, breaking a dependecy loop created when trying to add
a boot script to a signed Linux fitImage.
Signed-off-by: David Wretman
---
meta/classes-recipe/uboot-sign.bbclass | 77 --
1 file changed, 61 insertions(+), 16 deletions(-)
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index ad04c82378..e08ebda232 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -90,26 +90,75 @@ KERNEL_PN = "${PREFERRED_PROVIDER_virtual/kernel}"
python() {
# We need u-boot-tools-native if we're creating a U-Boot fitImage
-sign = d.getVar('UBOOT_SIGN_ENABLE') == '1'
-if d.getVar('UBOOT_FITIMAGE_ENABLE') == '1' or sign:
+if d.getVar('UBOOT_FITIMAGE_ENABLE') == '1' or
d.getVar('UBOOT_SIGN_ENABLE') == '1':
d.appendVar('DEPENDS', " u-boot-tools-native dtc-native")
-if sign:
-d.appendVar('DEPENDS', " " + d.getVar('KERNEL_PN'))
}
+# Create a dummy U-boot FIT and use that as input to mkimage when we want to
+# add the public key used to sign the Linux FIT to the U-Boot dtb.
+uboot_dtb_add_keys() {
+ # First we create an ITS script
+ cat << EOF > dummy.its
+/dts-v1/;
+
+/ {
+description = "Dummy U-Boot its";
+
+images {
+uboot {
+description = "U-Boot image";
+data = /incbin/("${UBOOT_NODTB_BINARY}");
+type = "standalone";
+os = "u-boot";
+arch = "${UBOOT_ARCH}";
+compression = "none";
+load = <${UBOOT_LOADADDRESS}>;
+entry = <${UBOOT_ENTRYPOINT}>;
+signature {
+algo = "${FIT_HASH_ALG},${FIT_SIGN_ALG}";
+key-name-hint = "${UBOOT_SIGN_KEYNAME}";
+};
+};
+};
+
+configurations {
+default = "conf";
+conf {
+description = "Boot with signed U-Boot FIT";
+loadables = "uboot";
+};
+};
+};
+EOF
+
+ #
+ # Assemble the Dummy FIT image
+ #
+ ${UBOOT_MKIMAGE} \
+ ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+ -f dummy.its \
+ dummy-fitImage
+
+ #
+ # Sign the Dummy FIT image to add public key to the U-Boot dtb
+ #
+ ${UBOOT_MKIMAGE_SIGN} \
+ ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+ -F -k "${UBOOT_SIGN_KEYDIR}" \
+ -K "${UBOOT_DTB_BINARY}" \
+ -r ${B}/dummy-fitImage \
+ ${UBOOT_MKIMAGE_SIGN_ARGS}
+ cp ${UBOOT_DTB_BINARY} ${UBOOT_DTB_SIGNED}
+}
+
+
+
concat_dtb() {
type="$1"
binary="$2"
if [ -e "${UBOOT_DTB_BINARY}" ]; then
- # Re-sign the kernel in order to add the keys to our dtb
- ${UBOOT_MKIMAGE_SIGN} \
- ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
- -F -k "${UBOOT_SIGN_KEYDIR}" \
- -K "${UBOOT_DTB_BINARY}" \
- -r ${B}/fitImage-linux \
- ${UBOOT_MKIMAGE_SIGN_ARGS}
- cp ${UBOOT_DTB_BINARY} ${UBOOT_DTB_SIGNED}
+ uboot_dtb_add_keys
fi
# If we're not using a signed u-boot fit, concatenate SPL w/o DTB &
U-Boot DTB
@@ -336,10 +385,6 @@ uboot_assemble_fitimage_helper() {
}
do_uboot_assemble_fitimage() {
- if [ "${UBOOT_SIGN_ENABLE}" = "1" ] ; then
- cp "${STAGING_DIR_HOST}/sysroot-only/fitImage"
"${B}/fitImage-linux"
- fi
-
if [ -n "${UBOOT_CONFIG}" ]; then
unset i j k
for config in ${UBOOT_MACHINE}; do
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193991):
https://lists.openembedded.org/g/openembedded-core/message/193991
Mute This Topic: https://lists.openembedded.org/mt/103809812/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] uboot-sign: Break dependency loop in fitImage signing
When trying to sign a Linux fitImage including a U-Boot boot script we end up in a dependency loop. In this scenario adding the public key used to sign the fitImage to the U-Boot dtb depends on the availability of the Linux fitImage. The fitImage in turn can not be created before the boot script is made available by the U-Boot do_populate_sysroot task which can not run before the signing of U-Boot. To fix this, we create a dummy fitImage to feed to mkimage when adding the public keys instead of using the Linux fitImage. The dependency on Linux fitImage availability from U-Boot recipes can thus be removed. This approach was earlier suggested by Sean Anderson in commit d6858c9f45d25cfec6defec17f62139593ae87f3. David Wretman (1): uboot-sign.bbclass: Break dependency loop in fitImage signing meta/classes-recipe/uboot-sign.bbclass | 77 -- 1 file changed, 61 insertions(+), 16 deletions(-) -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193990): https://lists.openembedded.org/g/openembedded-core/message/193990 Mute This Topic: https://lists.openembedded.org/mt/103809810/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote: > On Thu, 18 Jan 2024 at 15:10, Robert P. J. Day wrote: > > ah, got it. that's still fine since as the content is almost > > exclusively binary (pre-built) content, redoing from scratch will take > > no time at all. thanks for clarifying that. > > Pre-built content is ok on its own, but if those items are in the > dependency tree of something that does take time to build, they will > subvert sstate and lengthen build times. i'm already going over the entire build to identify unnoticed dependencies that could cause problems. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193989): https://lists.openembedded.org/g/openembedded-core/message/193989 Mute This Topic: https://lists.openembedded.org/mt/103807270/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024 at 15:10, Robert P. J. Day wrote: > ah, got it. that's still fine since as the content is almost > exclusively binary (pre-built) content, redoing from scratch will take > no time at all. thanks for clarifying that. Pre-built content is ok on its own, but if those items are in the dependency tree of something that does take time to build, they will subvert sstate and lengthen build times. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193988): https://lists.openembedded.org/g/openembedded-core/message/193988 Mute This Topic: https://lists.openembedded.org/mt/103807270/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> On Thu, 18 Jan 2024 at 15:04, Robert P. J. Day wrote:
> > i just tested, and the recipe does *not* rebuild unless i change
> > something in the ("externalsrc") source directory, at which point,
> > yes, it rebuilds. which is exactly what i'm after.
>
> It only doesn't rebuild because you already have a build/tmp directory.
>
> But as no sstate objects are created, if you wipe tmp/ or make a new
> build directory, it will rebuild again even without any changes at
> all. Try that!
ah, got it. that's still fine since as the content is almost
exclusively binary (pre-built) content, redoing from scratch will take
no time at all. thanks for clarifying that.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193987):
https://lists.openembedded.org/g/openembedded-core/message/193987
Mute This Topic: https://lists.openembedded.org/mt/103807270/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
This is reusing an existing build directory (Wanted 96 Local 96). You need to make a new one first. Alex On Thu, 18 Jan 2024 at 15:06, Robert P. J. Day wrote: > > On Thu, 18 Jan 2024, Alexander Kanavin wrote: > > > Mono-repo seemed like a good idea at the time, I'm sure. > > > > I need to point out that externalsrc disables sstate and always > > rebuilds from scratch. Is that okay? > > just tested a bitbake on recipe after changing nothing: > > Sstate summary: Wanted 96 Local 96 Mirrors 0 Missed 0 Current 100 > (100% match, 100% complete) | ETA: 0:00:00 > Initialising tasks: 100% > |#| > Time: 0:00:01 > NOTE: Executing Tasks > NOTE: Tasks Summary: Attempted 637 tasks of which 637 didn't need to > be rerun and all succeeded. > > then i made a trivial change to a single file in the source > directory and bitbake'd again: > > Sstate summary: Wanted 103 Local 96 Mirrors 0 Missed 7 Current 93 (93% > match, 96% complete)| ETA: 0:00:00 > Removing 6 stale sstate objects for arch allarch: 100% > |###| Time: 0:00:00 > Removing 1 stale sstate objects for arch qemux86_64: 100% > || Time: 0:00:00 > NOTE: Executing Tasks > NOTE: Tasks Summary: Attempted 637 tasks of which 627 didn't need to > be rerun and all succeeded. > NOTE: Build completion summary: > NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_create_runtime_spdx: 0.0% sstate reuse(0 setscene, 1 > scratch) > NOTE: do_package_qa: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_package: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_packagedata: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_package_write_rpm: 0.0% sstate reuse(0 setscene, 1 scratch) > > seems to be honouring sstate-cache. > > rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193986): https://lists.openembedded.org/g/openembedded-core/message/193986 Mute This Topic: https://lists.openembedded.org/mt/103807270/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote: > Mono-repo seemed like a good idea at the time, I'm sure. > > I need to point out that externalsrc disables sstate and always > rebuilds from scratch. Is that okay? just tested a bitbake on recipe after changing nothing: Sstate summary: Wanted 96 Local 96 Mirrors 0 Missed 0 Current 100 (100% match, 100% complete) | ETA: 0:00:00 Initialising tasks: 100% |#| Time: 0:00:01 NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 637 tasks of which 637 didn't need to be rerun and all succeeded. then i made a trivial change to a single file in the source directory and bitbake'd again: Sstate summary: Wanted 103 Local 96 Mirrors 0 Missed 7 Current 93 (93% match, 96% complete)| ETA: 0:00:00 Removing 6 stale sstate objects for arch allarch: 100% |###| Time: 0:00:00 Removing 1 stale sstate objects for arch qemux86_64: 100% || Time: 0:00:00 NOTE: Executing Tasks NOTE: Tasks Summary: Attempted 637 tasks of which 627 didn't need to be rerun and all succeeded. NOTE: Build completion summary: NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_runtime_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_package_qa: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_package: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_packagedata: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_package_write_rpm: 0.0% sstate reuse(0 setscene, 1 scratch) seems to be honouring sstate-cache. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193985): https://lists.openembedded.org/g/openembedded-core/message/193985 Mute This Topic: https://lists.openembedded.org/mt/103807270/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024 at 15:04, Robert P. J. Day wrote:
> i just tested, and the recipe does *not* rebuild unless i change
> something in the ("externalsrc") source directory, at which point,
> yes, it rebuilds. which is exactly what i'm after.
It only doesn't rebuild because you already have a build/tmp directory.
But as no sstate objects are created, if you wipe tmp/ or make a new
build directory, it will rebuild again even without any changes at
all. Try that!
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193984):
https://lists.openembedded.org/g/openembedded-core/message/193984
Mute This Topic: https://lists.openembedded.org/mt/103807270/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> Mono-repo seemed like a good idea at the time, I'm sure.
>
> I need to point out that externalsrc disables sstate and always
> rebuilds from scratch. Is that okay?
i just tested, and the recipe does *not* rebuild unless i change
something in the ("externalsrc") source directory, at which point,
yes, it rebuilds. which is exactly what i'm after.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193983):
https://lists.openembedded.org/g/openembedded-core/message/193983
Mute This Topic: https://lists.openembedded.org/mt/103807270/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 v1] uboot-sign: support to load optee-os and TFA images
Hello,
This doesn't apply on top of your previous patches. Can you send a
proper series with what you want to be tested/applied?
Thanks!
On 17/01/2024 10:10:51+0800, Jamin Lin via lists.openembedded.org wrote:
> Currently, u-boot FIT image only support to load u-boot image.
> To support optee-os and trusted-firmware-a, update ITS file generation
> scripts, so users are able to use u-boot FIT image to load
> u-boot, optee-os and treustred-firmware-a images
>
> Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A" to
> enable trusted-firmware-a image and it is disable by default.
>
> Add a variable "UBOOT_FIT_OPTEE_OS" to enable optee-os image
> and it is disable by default.
>
> The ITS file creation looks like as following.
> 1. Both optee-os and trusted-firmware-a are disabled.
> '''
> /dts-v1/;
>
> / {
> images {
> uboot {
>
> };
> fdt {
> };
> };
>
> configurations {
> default = "conf";
> conf {
> loadables = "uboot";
> fdt = "fdt";
> };
> };
> };
> '''
>
> 2. Only enable optee-os
> '''
> /dts-v1/;
>
> / {
> images {
> uboot {
> };
> fdt {
> };
> optee {
> };
> };
>
> configurations {
> default = "conf";
> conf {
> firmware = "optee";
> loadables = "uboot";
> fdt = "fdt";
> };
> };
> };
> '''
>
> 3: Both optee-os and trusted-firmware-a are enabled
> '''
> /dts-v1/;
>
> / {
> images {
> uboot {
> };
> fdt {
> };
> atf {
> };
> optee {
> };
> };
>
> configurations {
> default = "conf";
> conf {
> firmware = "atf";
> loadables = "uboot", "optee";
> fdt = "fdt";
> };
> };
> };
> '''
>
> Signed-off-by: Jamin Lin
> ---
> meta/classes-recipe/uboot-sign.bbclass | 91 +-
> 1 file changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/uboot-sign.bbclass
> b/meta/classes-recipe/uboot-sign.bbclass
> index ad04c82378..b874eb84db 100644
> --- a/meta/classes-recipe/uboot-sign.bbclass
> +++ b/meta/classes-recipe/uboot-sign.bbclass
> @@ -88,6 +88,18 @@ UBOOT_FIT_ADDRESS_CELLS ?= "1"
> # This is only necessary for determining the signing configuration
> KERNEL_PN = "${PREFERRED_PROVIDER_virtual/kernel}"
>
> +# Trusted Firmware-A (TF-A) provides a reference implementation of
> +# secure world software for Armv7-A and Armv8-A,
> +# including a Secure Monitor executing at Exception Level 3 (EL3)
> +# ATF is used as the initial start code on ARMv8-A cores for all K3 platforms
> +UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A ?= "0"
> +UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_IMAGE ?= "bl31.bin"
> +
> +# OP-TEE is a Trusted Execution Environment (TEE) designed as
> +# companion to a non-secure Linux kernel running on Arm
> +UBOOT_FIT_OPTEE_OS ?= "0"
> +UBOOT_FIT_OPTEE_OS_IMAGE ?= "tee-raw.bin"
> +
> python() {
> # We need u-boot-tools-native if we're creating a U-Boot fitImage
> sign = d.getVar('UBOOT_SIGN_ENABLE') == '1'
> @@ -230,6 +242,20 @@ addtask uboot_generate_rsa_keys before
> do_uboot_assemble_fitimage after do_compi
> # Create a ITS file for the U-boot FIT, for use when
> # we want to sign it so that the SPL can verify it
> uboot_fitimage_assemble() {
> + conf_loadables="\"uboot\""
> + conf_firmware=""
> +
> + if [ "${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A}" = "1" ]; then
> + conf_firmware="\"atf\""
> + if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ]; then
> + conf_loadables="\"uboot\", \"optee\""
> + fi
> + else
> + if [ "${UBOOT_FIT_OPTEE_OS}" = "1" ]; then
> + conf_firmware="\"optee\""
> + fi
> + fi
> +
> rm -f ${UBOOT_ITS} ${UBOOT_FITIMAGE_BINARY}
>
> # First we create the ITS script
> @@ -282,13 +308,76 @@ EOF
>
> cat << EOF >> ${UBOOT_ITS}
> };
> +EOF
> + if [ "${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A}" = "1" ] ; then
> + cat << EOF >> ${UBOOT_ITS}
> +atf {
> +description = "ARM Trusted Firmware-A";
> +data = /incbin/("${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_IMAGE}");
> +type = "firmware";
> +arch = "${UBOOT_ARCH}";
> +os = "arm-trusted-firmware";
> +load = <${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_LOADADDRESS}>;
> +entry = <${UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A_ENTRYPOINT}>;
> +compression = "none";
> +EOF
> +
> + if [ "${SPL_SIGN_ENABLE}" = "1" ] ; then
> + cat << EOF >> ${UBOOT_ITS}
> +signature {
> +algo = "${UBOOT_FIT_HASH_ALG},${UBOOT_FIT_SIGN_ALG}";
> +key-name-hint = "${SPL_SIGN_KEYNAME}";
> +};
> +EOF
> + fi
> +
> + cat << EOF >> ${UBOOT_ITS}
> +};
>
Re: [OE-core] [PATCH v3 2/2] shadow: link executables statically for -native variant
On Thu, 2024-01-18 at 15:37 +0200, Dmitry Baryshkov wrote:
> On Thu, 18 Jan 2024 at 11:59, Richard Purdie
> wrote:
> >
> > On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > > wrote:
> > > >
> > > > shadow 4.14.x adds a number of libraries it dynamically links with
> > > > (md, bsd, attr). This causes troubles in setscene tasks where
> > > > shadow executables are used (such as useradd), as pulling in
> > > > the needed dynamic libraries needs unpleasant special-casing.
> > > >
> > > > Signed-off-by: Alexander Kanavin
> > >
> > > It seems, this is causing issues with the TuxOE builds. We have been
> > > observing issues with the TuxOE build environment with the image
> > > creation choking on the home dirs. Reverting this patch seems to fix
> > > the problem. The build environment is Ubuntu 20.04 running in a
> > > container on Ubuntu 22.04.
> > >
> > > ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> > > ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> > > 1, None, None)
> > > ERROR: Logfile of failure stored in:
> > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> > > Log data follows:
> > > > DEBUG: Executing python function set_image_size
> > > > DEBUG: 1402908.00 = 1079160 * 1.30
> > > > DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> > > > DEBUG: 1402908.00 = int(1402908.00)
> > > > DEBUG: 1404928 = aligned(1402908)
> > > > DEBUG: returning 1404928
> > > > DEBUG: Python function set_image_size finished
> > > > DEBUG: Executing shell function do_image_tar
> > > > tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> > > > tar: ./home/linaro/.profile: Unknown file type; file ignored
> > > > tar: Exiting with failure status due to previous errors
> > > > WARNING:
> > > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> > > exit 1 from '[ $? -eq 1 ]'
> > >
> >
> > The error is coming from tar during archive creation, "Unknown file
> > type; file ignored". I'm a little confused/concerned about what it is
> > seeing which it can't handle.
> >
> > It might also be good to work out if that is tar from the host or tar
> > from tar-native. Is the host's tar unable to support something we're
> > relying upon?
> >
> > If it were me, I'd probably have a look into the tar source code too,
> > see what might trigger an error like that.
>
> I compared this to the ext4 creation error. The code for __populate_fs
> is more easy to follow. Basically this error means that st.st_mode
> doesn't match S_IFCHR, S_IFBLK, S_IFREG and S_IFDIR checks.
> I assume the files in home dir are created by useradd in some way that
> bypasses pseudo. Then when tar / mkfs are executed, pseudo doesn't
> know about the file and returns bad st_mode through lstat().
Files shouldn't be getting created in useradd that pseudo doesn't know
about. If they are, we could be missing an intercept on some glibc
function call for example.
Is this in a multiple worker setup with a shared sstate? We need to
track down which OS the escape is happening on. In theory it should be
reproducible. Do you have anything with a bleeding edge glibc there
(e.g. gentoo)?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193981):
https://lists.openembedded.org/g/openembedded-core/message/193981
Mute This Topic: https://lists.openembedded.org/mt/103661548/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 v3 2/2] shadow: link executables statically for -native variant
On Thu, 18 Jan 2024 at 11:59, Richard Purdie
wrote:
>
> On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > wrote:
> > >
> > > shadow 4.14.x adds a number of libraries it dynamically links with
> > > (md, bsd, attr). This causes troubles in setscene tasks where
> > > shadow executables are used (such as useradd), as pulling in
> > > the needed dynamic libraries needs unpleasant special-casing.
> > >
> > > Signed-off-by: Alexander Kanavin
> >
> > It seems, this is causing issues with the TuxOE builds. We have been
> > observing issues with the TuxOE build environment with the image
> > creation choking on the home dirs. Reverting this patch seems to fix
> > the problem. The build environment is Ubuntu 20.04 running in a
> > container on Ubuntu 22.04.
> >
> > ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> > ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> > 1, None, None)
> > ERROR: Logfile of failure stored in:
> > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> > Log data follows:
> > > DEBUG: Executing python function set_image_size
> > > DEBUG: 1402908.00 = 1079160 * 1.30
> > > DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> > > DEBUG: 1402908.00 = int(1402908.00)
> > > DEBUG: 1404928 = aligned(1402908)
> > > DEBUG: returning 1404928
> > > DEBUG: Python function set_image_size finished
> > > DEBUG: Executing shell function do_image_tar
> > > tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> > > tar: ./home/linaro/.profile: Unknown file type; file ignored
> > > tar: Exiting with failure status due to previous errors
> > > WARNING:
> > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> > exit 1 from '[ $? -eq 1 ]'
> >
>
> The error is coming from tar during archive creation, "Unknown file
> type; file ignored". I'm a little confused/concerned about what it is
> seeing which it can't handle.
>
> It might also be good to work out if that is tar from the host or tar
> from tar-native. Is the host's tar unable to support something we're
> relying upon?
>
> If it were me, I'd probably have a look into the tar source code too,
> see what might trigger an error like that.
I compared this to the ext4 creation error. The code for __populate_fs
is more easy to follow. Basically this error means that st.st_mode
doesn't match S_IFCHR, S_IFBLK, S_IFREG and S_IFDIR checks.
I assume the files in home dir are created by useradd in some way that
bypasses pseudo. Then when tar / mkfs are executed, pseudo doesn't
know about the file and returns bad st_mode through lstat().
--
With best wishes
Dmitry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193980):
https://lists.openembedded.org/g/openembedded-core/message/193980
Mute This Topic: https://lists.openembedded.org/mt/103661548/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 v3 2/2] shadow: link executables statically for -native variant
On Thu, 18 Jan 2024 at 12:13, Alexander Kanavin wrote:
>
> I'd like to clarify the 'randomly' part: does the failure disappear if
> you re-run bitbake on the same build directory, or is it random only
> between different builds?
It is random between different builds. Rerunning the build frequently
(but not always) makes it go away.
> If it's deterministic in the same build
> directory, then you can narrow it down to the specific tar invocation
> directly from command line perhaps, and then try to see what is it in
> the tree that tar operates on, that triggers the error.
>
> Alex
>
> On Thu, 18 Jan 2024 at 10:59, Richard Purdie
> wrote:
> >
> > On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > > wrote:
> > > >
> > > > shadow 4.14.x adds a number of libraries it dynamically links with
> > > > (md, bsd, attr). This causes troubles in setscene tasks where
> > > > shadow executables are used (such as useradd), as pulling in
> > > > the needed dynamic libraries needs unpleasant special-casing.
> > > >
> > > > Signed-off-by: Alexander Kanavin
> > >
> > > It seems, this is causing issues with the TuxOE builds. We have been
> > > observing issues with the TuxOE build environment with the image
> > > creation choking on the home dirs. Reverting this patch seems to fix
> > > the problem. The build environment is Ubuntu 20.04 running in a
> > > container on Ubuntu 22.04.
> > >
> > > ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> > > ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> > > 1, None, None)
> > > ERROR: Logfile of failure stored in:
> > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> > > Log data follows:
> > > > DEBUG: Executing python function set_image_size
> > > > DEBUG: 1402908.00 = 1079160 * 1.30
> > > > DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> > > > DEBUG: 1402908.00 = int(1402908.00)
> > > > DEBUG: 1404928 = aligned(1402908)
> > > > DEBUG: returning 1404928
> > > > DEBUG: Python function set_image_size finished
> > > > DEBUG: Executing shell function do_image_tar
> > > > tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> > > > tar: ./home/linaro/.profile: Unknown file type; file ignored
> > > > tar: Exiting with failure status due to previous errors
> > > > WARNING:
> > > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> > > exit 1 from '[ $? -eq 1 ]'
> > >
> >
> > The error is coming from tar during archive creation, "Unknown file
> > type; file ignored". I'm a little confused/concerned about what it is
> > seeing which it can't handle.
> >
> > It might also be good to work out if that is tar from the host or tar
> > from tar-native. Is the host's tar unable to support something we're
> > relying upon?
> >
> > If it were me, I'd probably have a look into the tar source code too,
> > see what might trigger an error like that.
> >
> > Cheers,
> >
> > Richard
> >
> >
--
With best wishes
Dmitry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193979):
https://lists.openembedded.org/g/openembedded-core/message/193979
Mute This Topic: https://lists.openembedded.org/mt/103661548/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] want to confirm i'm using "externalsrc" and "bin_package" efficiently
Mono-repo seemed like a good idea at the time, I'm sure. I need to point out that externalsrc disables sstate and always rebuilds from scratch. Is that okay? Alex On Thu, 18 Jan 2024 at 13:58, Robert P. J. Day wrote: > > > i'm pretty sure i know how to do this, just want to know if there's > an even easier/more elegant way. > > in current project, there is a *pile* of local content that is > identified by various recipes. so since that content is local, the > obvious starting point is for such recipes to "inherit externalsrc" to > properly identify the local source directory. > > in addition, many of those recipes represent packaging binary data > (imagine firmware files), so that there is really no meaningful > configure or compile tasks, so that further suggests inheriting > "bin_package" as well. > > finally, in some cases, there is a teeny bit of tweaking that might > be needed for the final installed content, which suggests adding: > > do_install:append() > > to the mix to handle whatever little adjustments are needed. > > so given that scenario, can i reasonably summarize the right > approach as: > > inherit externalsrc > inherit bin_package > do_install:append() [as needed] > > finally, it doesn't seem like many of those recipes are required as > build-time dependencies, so i can just make them either RDEPENDS as > appropriate, or just IMAGE_INSTALL them for the final image. > > sound reasonable? am i overthinking this? seems fairly > straightforward. > > rday > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193978): https://lists.openembedded.org/g/openembedded-core/message/193978 Mute This Topic: https://lists.openembedded.org/mt/103807270/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] want to confirm i'm using "externalsrc" and "bin_package" efficiently
i'm pretty sure i know how to do this, just want to know if there's an even easier/more elegant way. in current project, there is a *pile* of local content that is identified by various recipes. so since that content is local, the obvious starting point is for such recipes to "inherit externalsrc" to properly identify the local source directory. in addition, many of those recipes represent packaging binary data (imagine firmware files), so that there is really no meaningful configure or compile tasks, so that further suggests inheriting "bin_package" as well. finally, in some cases, there is a teeny bit of tweaking that might be needed for the final installed content, which suggests adding: do_install:append() to the mix to handle whatever little adjustments are needed. so given that scenario, can i reasonably summarize the right approach as: inherit externalsrc inherit bin_package do_install:append() [as needed] finally, it doesn't seem like many of those recipes are required as build-time dependencies, so i can just make them either RDEPENDS as appropriate, or just IMAGE_INSTALL them for the final image. sound reasonable? am i overthinking this? seems fairly straightforward. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193977): https://lists.openembedded.org/g/openembedded-core/message/193977 Mute This Topic: https://lists.openembedded.org/mt/103807270/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] xserver-xorg: 21.1.9 -> 21.1.11
From: Kai Kang
Update xserver-xorg from 21.1.9 to 21.1.11.
Release Notes of 21.1.11 [1]:
This release contains fixes for the issues reported in today's security
advisory: https://lists.x.org/archives/xorg/2024-January/061525.html
* CVE-2023-6816
* CVE-2024-0229
* CVE-2024-21885
* CVE-2024-21886
* CVE-2024-0408
* CVE-2024-0409
Additionally, it also contains a fix for XRandR to allow for multiple virtual
monitors on a physical display.
Release Notes of 21.1.10 [2]:
This release contains fixes for CVE-2023-6377 and CVE-2023-6478 as
reported in today's security advisory:
https://lists.x.org/archives/xorg-announce/2023-December/003435.html
[1]: https://lists.x.org/archives/xorg/2024-January/061526.html
[2]: https://lists.x.org/archives/xorg/2023-December/061518.html
Signed-off-by: Kai Kang
---
.../{xserver-xorg_21.1.9.bb => xserver-xorg_21.1.11.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_21.1.9.bb =>
xserver-xorg_21.1.11.bb} (92%)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.9.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.11.bb
similarity index 92%
rename from meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.9.bb
rename to meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.11.bb
index 43c06181e3..6506d775ca 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.9.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.11.bb
@@ -3,7 +3,7 @@ require xserver-xorg.inc
SRC_URI +=
"file://0001-xf86pciBus.c-use-Intel-ddx-only-for-pre-gen4-hardwar.patch \
file://0001-Avoid-duplicate-definitions-of-IOPortBase.patch \
"
-SRC_URI[sha256sum] =
"ff697be2011b4c4966b7806929e51b7a08e9d33800d505305d26d9ccde4b533a"
+SRC_URI[sha256sum] =
"1d3dadbd57fb86b16a018e9f5f957aeeadf744f56c0553f55737628d06d326ef"
# These extensions are now integrated into the server, so declare the migration
# path for in-place upgrades.
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193976):
https://lists.openembedded.org/g/openembedded-core/message/193976
Mute This Topic: https://lists.openembedded.org/mt/103806876/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Patchtest results for [OE-core][kirkstone][PATCH 1/1] tiff: fix CVE-2023-6228
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/kirkstone-1-1-tiff-fix-CVE-2023-6228.patch FAIL: test CVE check ignore: CVE_CHECK_IGNORE is deprecated and should be replaced by CVE_STATUS (test_metadata.TestMetadata.test_cve_check_ignore) PASS: pretest src uri left files (test_metadata.TestMetadata.pretest_src_uri_left_files) PASS: test CVE tag format (test_patch.TestPatch.test_cve_tag_format) PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence) PASS: test Signed-off-by presence (test_patch.TestPatch.test_signed_off_by_presence) PASS: test Upstream-Status presence (test_patch.TestPatch.test_upstream_status_presence_format) PASS: test author valid (test_mbox.TestMbox.test_author_valid) PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence) PASS: test lic files chksum modified not mentioned (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned) PASS: test max line length (test_metadata.TestMetadata.test_max_line_length) PASS: test mbox format (test_mbox.TestMbox.test_mbox_format) PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade) PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format) PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length) PASS: test src uri left files (test_metadata.TestMetadata.test_src_uri_left_files) SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint) SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format) SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence) SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence) SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint) SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head) SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence) SKIP: test target mailing list: Series merged, no reason to check other mailing lists (test_mbox.TestMbox.test_target_mailing_list) --- Please address the issues identified and submit a new revision of the patch, or alternatively, reply to this email with an explanation of why the patch should be accepted. If you believe these results are due to an error in patchtest, please submit a bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category under 'Yocto Project Subprojects'). For more information on specific failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank you! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193975): https://lists.openembedded.org/g/openembedded-core/message/193975 Mute This Topic: https://lists.openembedded.org/mt/103805851/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] rust: Enable rust oe-selftest
From: Yash Shinde
Enable rust oe-selftest for rust 1.74.1 version and
add target_cfg.patch to handle target configurations
for custom targets.
The testing is done on arm32, arm64, mips64, x86 and x86_64 targets.
Signed-off-by: Yash Shinde
---
meta/lib/oeqa/selftest/cases/rust.py | 103 -
.../rust/files/target_cfg.patch | 144 ++
meta/recipes-devtools/rust/rust-source.inc| 1 +
3 files changed, 214 insertions(+), 34 deletions(-)
create mode 100644 meta/recipes-devtools/rust/files/target_cfg.patch
diff --git a/meta/lib/oeqa/selftest/cases/rust.py
b/meta/lib/oeqa/selftest/cases/rust.py
index 6dbc517006..216c73e5d1 100644
--- a/meta/lib/oeqa/selftest/cases/rust.py
+++ b/meta/lib/oeqa/selftest/cases/rust.py
@@ -40,7 +40,7 @@ def parse_results(filename):
class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
def test_rust(self, *args, **kwargs):
# Disable Rust Oe-selftest
-self.skipTest("The Rust Oe-selftest is disabled.")
+#self.skipTest("The Rust Oe-selftest is disabled.")
# build remote-test-server before image build
recipe = "rust"
@@ -73,38 +73,71 @@ class RustSelfTestSystemEmulated(OESelftestTestCase,
OEPTestResultTestCase):
'src/librustdoc',
'src/rustdoc-json-types',
'src/tools/compiletest/src/common.rs',
+'src/tools/jsondoclint',
'src/tools/lint-docs',
+'src/tools/replace-version-placeholder',
'src/tools/rust-analyzer',
'src/tools/rustdoc-themes',
'src/tools/tidy',
'tests/assembly/asm/aarch64-outline-atomics.rs',
+'tests/codegen/abi-efiapi.rs',
+'tests/codegen/abi-efiapi.rs',
'tests/codegen/abi-main-signature-32bit-c-int.rs',
'tests/codegen/abi-repr-ext.rs',
+'tests/codegen/abi-sysv64.rs',
'tests/codegen/abi-x86-interrupt.rs',
+'tests/codegen/align-byval.rs',
+'tests/codegen/align-fn.rs',
+'tests/codegen/asm-powerpc-clobbers.rs',
+'tests/codegen/async-fn-debug-awaitee-field.rs',
+
'tests/codegen/binary-search-index-no-bound-check.rs',
'tests/codegen/branch-protection.rs',
+'tests/codegen/call-metadata.rs',
'tests/codegen/catch-unwind.rs',
'tests/codegen/cf-protection.rs',
+'tests/codegen/debug-column.rs',
+'tests/codegen/debug-limited.rs',
+
'tests/codegen/debuginfo-generic-closure-env-names.rs',
+'tests/codegen/drop.rs',
+'tests/codegen/dst-vtable-align-nonzero.rs',
+'tests/codegen/enable-lto-unit-splitting.rs',
'tests/codegen/enum-bounds-check-derived-idx.rs',
+'tests/codegen/enum/enum-u128.rs',
+'tests/codegen/fn-impl-trait-self.rs',
'tests/codegen/force-unwind-tables.rs',
+'tests/codegen/inherit_overflow.rs',
+'tests/codegen/inherit_overflow.rs',
+'tests/codegen/inline-function-args-debug-info.rs',
'tests/codegen/intrinsic-no-unnamed-attr.rs',
+'tests/codegen/intrinsics/mask.rs',
+'tests/codegen/intrinsics/transmute-niched.rs',
'tests/codegen/issues/issue-103840.rs',
'tests/codegen/issues/issue-47278.rs',
+'tests/codegen/issues/issue-73258.rs',
'tests/codegen/issues/issue-73827-bounds-check-index-in-subexpr.rs',
+'tests/codegen/issues/issue-75546.rs',
+'tests/codegen/issues/issue-77812.rs',
+
'tests/codegen/issues/issue-98156-const-arg-temp-lifetime.rs',
'tests/codegen/lifetime_start_end.rs',
+'tests/codegen/llvm-ident.rs',
'tests/codegen/local-generics-in-exe-internalized.rs',
+'tests/codegen/mainsubprogram.rs',
'tests/codegen/match-unoptimized.rs',
+'tests/codegen/move-operands.rs',
[OE-core][kirkstone][PATCH 1/1] tiff: fix CVE-2023-6228
From: Yogita Urade
CVE-2023-6228:
An issue was found in the tiffcp utility distributed by the
libtiff package where a crafted TIFF file on processing may
cause a heap-based buffer overflow leads to an application
crash.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-6228
https://gitlab.com/libtiff/libtiff/-/issues/606
Signed-off-by: Yogita Urade
---
.../libtiff/tiff/CVE-2023-6228.patch | 31 +++
meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch
diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch
new file mode 100644
index 00..f15cc96e19
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch
@@ -0,0 +1,31 @@
+From 1e7d217a323eac701b134afc4ae39b6bdfdbc96a Mon Sep 17 00:00:00 2001
+From: Su_Laus
+Date: Wed, 17 Jan 2024 06:38:24 +
+Subject: [PATCH] codec of input image is available, independently from codec
+ check of output image and return with error if not.
+
+Fixes #606.
+
+CVE: CVE-2023-6228
+Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/1e7d217a323eac701b134afc4ae39b6bdfdbc96a]
+
+Signed-off-by: Yogita Urade
+---
+ tools/tiffcp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/tools/tiffcp.c b/tools/tiffcp.c
+index 34b6ef2..17c6524 100644
+--- a/tools/tiffcp.c
b/tools/tiffcp.c
+@@ -724,6 +724,8 @@ tiffcp(TIFF* in, TIFF* out)
+ else
+ CopyField(TIFFTAG_COMPRESSION, compression);
+ TIFFGetFieldDefaulted(in, TIFFTAG_COMPRESSION, _compression);
++ if (!TIFFIsCODECConfigured(input_compression))
++ return FALSE;
+ TIFFGetFieldDefaulted(in, TIFFTAG_PHOTOMETRIC, _photometric);
+ if (input_compression == COMPRESSION_JPEG) {
+ /* Force conversion to RGB */
+--
+2.40.0
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
index 11e3818c69..d284100ab2 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
@@ -47,6 +47,7 @@ SRC_URI =
"http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
file://CVE-2023-1916.patch \
file://CVE-2023-40745.patch \
file://CVE-2023-41175.patch \
+ file://CVE-2023-6228.patch \
"
SRC_URI[sha256sum] =
"0e46e5acb087ce7d1ac53cf4f56a09b221537fc86dfc5daaad1c2e89e1b37ac8"
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193973):
https://lists.openembedded.org/g/openembedded-core/message/193973
Mute This Topic: https://lists.openembedded.org/mt/103805749/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 4/4] rpm: update 4.18.1 -> 4.19.1
Upstream has replaced autoconf with cmake, which necessitates a rewrite of the
recipe and available options, and a rebase to cmake of
0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
Correct a mistake in 0001-Do-not-read-config-files-from-HOME.patch :
the patch was removing the NULL marker at the end of function arguments,
and 0002-Add-support-for-prefixing-etc-from-RPM_ETCCONFIGDIR-.patch
was restoring it (in addition to the actual change the patch was making).
Now both patches preserve the NULL terminator.
Signed-off-by: Alexander Kanavin
---
...olor-setting-for-mips64_n32-binaries.patch | 12 +--
...ook-for-lua-with-pkg-config-rather-t.patch | 28 +++
...estore-readline-support-as-an-explic.patch | 42 +++
...satisfiable-dependency-when-building.patch | 12 +--
...lib-rpm-as-the-installation-path-for.patch | 52 +
...1-Do-not-read-config-files-from-HOME.patch | 19 ++---
...-PATH-environment-variable-before-ru.patch | 12 +--
...lename-before-passing-it-to-basename.patch | 40 --
...ix-missing-basename-include-on-macOS.patch | 26 ---
...l-dependency-on-non-POSIX-GLOB_ONLYD.patch | 56 ++
...lling-execute-package-scriptlets-wit.patch | 24 ++
...not-insert-payloadflags-into-.rpm-me.patch | 13 ++--
...-linux-gnux32-variant-to-triplet-han.patch | 28 ---
c-fix-file-conflicts-for-MIPS64-N32.patch | 13 ++--
.../files/0001-perl-disable-auto-reqs.patch | 26 ---
...y_hash_t-instead-of-long-in-hdr_hash.patch | 35 -
...prefixing-etc-from-RPM_ETCCONFIGDIR-.patch | 31
...txt-do-not-install-non-existent-docs.patch | 26 +++
...avoid-using-GLOB_BRACE-if-undefined-.patch | 34 +
...ge-logging-level-around-scriptlets-t.patch | 19 ++---
...87cfcf9cac87e5bc5e7db79b0338da9e355e.patch | 51 -
.../rpm/files/fix-declaration.patch | 39 --
.../rpm/{rpm_4.18.1.bb => rpm_4.19.1.bb} | 73 ---
23 files changed, 328 insertions(+), 383 deletions(-)
create mode 100644
meta/recipes-devtools/rpm/files/0001-CMakeLists.txt-look-for-lua-with-pkg-config-rather-t.patch
create mode 100644
meta/recipes-devtools/rpm/files/0001-CMakeLists.txt-restore-readline-support-as-an-explic.patch
delete mode 100644
meta/recipes-devtools/rpm/files/0001-Duplicate-filename-before-passing-it-to-basename.patch
delete mode 100644
meta/recipes-devtools/rpm/files/0001-Fix-missing-basename-include-on-macOS.patch
create mode 100644
meta/recipes-devtools/rpm/files/0001-Fix-unconditional-dependency-on-non-POSIX-GLOB_ONLYD.patch
delete mode 100644
meta/recipes-devtools/rpm/files/0001-configure.ac-add-linux-gnux32-variant-to-triplet-han.patch
delete mode 100644
meta/recipes-devtools/rpm/files/0001-python-Use-Py_hash_t-instead-of-long-in-hdr_hash.patch
create mode 100644
meta/recipes-devtools/rpm/files/0002-docs-CMakeLists.txt-do-not-install-non-existent-docs.patch
create mode 100644
meta/recipes-devtools/rpm/files/0002-rpmio-rpmglob.c-avoid-using-GLOB_BRACE-if-undefined-.patch
delete mode 100644
meta/recipes-devtools/rpm/files/ea3187cfcf9cac87e5bc5e7db79b0338da9e355e.patch
delete mode 100644 meta/recipes-devtools/rpm/files/fix-declaration.patch
rename meta/recipes-devtools/rpm/{rpm_4.18.1.bb => rpm_4.19.1.bb} (72%)
diff --git
a/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
b/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
index 9fa486dfd3c..96fe57dfeb8 100644
---
a/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
+++
b/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch
@@ -1,4 +1,4 @@
-From 93f219df68f3741ff63a294a16bcbe8deba1112f Mon Sep 17 00:00:00 2001
+From ecc45e3ae837ab50603088dcc8fd2f8e67a7ece6 Mon Sep 17 00:00:00 2001
From: Alexander Kanavin
Date: Thu, 9 Mar 2017 18:54:02 +0200
Subject: [PATCH] Add a color setting for mips64_n32 binaries
@@ -12,10 +12,10 @@ Signed-off-by: Alexander Kanavin
2 files changed, 6 insertions(+)
diff --git a/build/rpmfc.c b/build/rpmfc.c
-index 26606378f..a16e3f4e9 100644
+index 4b67a9bae..ed7e4e623 100644
--- a/build/rpmfc.c
+++ b/build/rpmfc.c
-@@ -646,6 +646,7 @@ exit:
+@@ -660,6 +660,7 @@ exit:
static const struct rpmfcTokens_s rpmfcTokens[] = {
{ "directory", RPMFC_INCLUDE },
@@ -23,7 +23,7 @@ index 26606378f..a16e3f4e9 100644
{ "ELF 32-bit", RPMFC_ELF32|RPMFC_INCLUDE },
{ "ELF 64-bit", RPMFC_ELF64|RPMFC_INCLUDE },
-@@ -1151,6 +1152,9 @@ static uint32_t getElfColor(const char *fn)
+@@ -1158,6 +1159,9 @@ static uint32_t getElfColor(const char *fn)
color = RPMFC_ELF32;
break;
}
@@ -34,10 +34,10 @@ index 26606378f..a16e3f4e9 100644
if (elf)
elf_end(elf);
diff --git a/rpmrc.in b/rpmrc.in
-index 2975a3a0e..c7232b48b 100644
+index 8646a966b..7349fdfd3
[OE-core] [PATCH 3/4] classes/package_rpm: use weak user/group dependencies
rpm 4.19 automatically generates provides and depends for user and
groups:
https://github.com/rpm-software-management/rpm/blob/rpm-4.19.x/docs/manual/users_and_groups.md#dependencies
This mechanism relies on sysusers.d for the 'provides'
part, and thus is systemd-only at best. So we need to disable it for now,
otherwise image generation fails with unresolved dependencies.
Signed-off-by: Alexander Kanavin
---
meta/classes-global/package_rpm.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes-global/package_rpm.bbclass
b/meta/classes-global/package_rpm.bbclass
index 09cc7d62681..027e06ed877 100644
--- a/meta/classes-global/package_rpm.bbclass
+++ b/meta/classes-global/package_rpm.bbclass
@@ -711,6 +711,7 @@ python do_package_rpm () {
cmd = cmd + " --define '_unpackaged_files_terminate_build 0'"
cmd = cmd + " --define 'debug_package %{nil}'"
cmd = cmd + " --define '_tmppath " + workdir + "'"
+cmd = cmd + " --define '_use_weak_usergroup_deps 1'"
if d.getVarFlag('ARCHIVER_MODE', 'srpm') == '1' and
bb.data.inherits_class('archiver', d):
cmd = cmd + " --define '_sourcedir " + d.getVar('ARCHIVER_OUTDIR') +
"'"
cmdsrpm = cmd + " --define '_srcrpmdir " +
d.getVar('ARCHIVER_RPMOUTDIR') + "'"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193971):
https://lists.openembedded.org/g/openembedded-core/message/193971
Mute This Topic: https://lists.openembedded.org/mt/103805484/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 2/4] classes/package_rpm: write file permissions and ownership explicitly into .spec
Per
https://github.com/rpm-software-management/rpm/commit/77d3529c31ca090a40b8d3959a0bcdd721a556d6
rpm 4.19.1+ will not consider actual filesystem permissions and ownership, and
will quietly default
to root if not expictly set otherwise in .spec file.
Signed-off-by: Alexander Kanavin
---
meta/classes-global/package_rpm.bbclass | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/meta/classes-global/package_rpm.bbclass
b/meta/classes-global/package_rpm.bbclass
index 2fc18fe98c1..09cc7d62681 100644
--- a/meta/classes-global/package_rpm.bbclass
+++ b/meta/classes-global/package_rpm.bbclass
@@ -103,6 +103,7 @@ def write_rpm_perfiledata(srcname, d):
python write_specfile () {
import oe.packagedata
+import os,pwd,grp,stat
# append information for logs and patches to %prep
def add_prep(d, spec_files_bottom):
@@ -198,6 +199,13 @@ python write_specfile () {
# of the walk, the isdir() test would then fail and the walk code
would assume its a file
# hence we check for the names in files too.
for rootpath, dirs, files in os.walk(walkpath):
+def get_attr(path):
+stat_f = os.stat(rootpath + "/" + path, follow_symlinks=False)
+mode = stat.S_IMODE(stat_f.st_mode)
+owner = pwd.getpwuid(stat_f.st_uid).pw_name
+group = grp.getgrgid(stat_f.st_gid).gr_name
+return "%attr({:o},{},{}) ".format(mode, owner, group)
+
path = rootpath.replace(walkpath, "")
if path.endswith("DEBIAN") or path.endswith("CONTROL"):
continue
@@ -221,24 +229,28 @@ python write_specfile () {
if dir == "CONTROL" or dir == "DEBIAN":
continue
dir = dir.replace("%", "")
+p = path + '/' + dir
# All packages own the directories their files are in...
-target.append('%dir "' + path + '/' + dir + '"')
+target.append(get_attr(dir) + '%dir "' + p + '"')
else:
# packages own only empty directories or explict directory.
# This will prevent the overlapping of security permission.
+attr = get_attr(path)
if path and not files and not dirs:
-target.append('%dir "' + path + '"')
+target.append(attr + '%dir "' + path + '"')
elif path and path in dirfiles:
-target.append('%dir "' + path + '"')
+target.append(attr + '%dir "' + path + '"')
for file in files:
if file == "CONTROL" or file == "DEBIAN":
continue
file = file.replace("%", "")
-if conffiles.count(path + '/' + file):
-target.append('%config "' + path + '/' + file + '"')
+attr = get_attr(file)
+p = path + '/' + file
+if conffiles.count(p):
+target.append(attr + '%config "' + p + '"')
else:
-target.append('"' + path + '/' + file + '"')
+target.append(attr + '"' + p + '"')
# Prevent the prerm/postrm scripts from being run during an upgrade
def wrap_uninstall(scriptvar):
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193970):
https://lists.openembedded.org/g/openembedded-core/message/193970
Mute This Topic: https://lists.openembedded.org/mt/103805482/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/4] oeqa/runtime/rpm: raise exception if test rpm file cannot be found
The tests rely on that, and so the discovery shouldn't simply
fall through.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/runtime/cases/rpm.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/runtime/cases/rpm.py
b/meta/lib/oeqa/runtime/cases/rpm.py
index a4ba4e67698..bd9050a81b2 100644
--- a/meta/lib/oeqa/runtime/cases/rpm.py
+++ b/meta/lib/oeqa/runtime/cases/rpm.py
@@ -88,9 +88,12 @@ class RpmInstallRemoveTest(OERuntimeTestCase):
# and it will always be built for standard targets
rpm_doc = 'base-passwd-doc-*.%s.rpm' % pkgarch
if not os.path.exists(rpmdir):
-return
+raise Exception("Rpm directory {} does not
exist".format(cls.tc.td['DEPLOY_DIR']))
for f in fnmatch.filter(os.listdir(rpmdir), rpm_doc):
cls.test_file = os.path.join(rpmdir, f)
+break
+else:
+raise Exception("Couldn't find the test rpm file {} in
{}".format(rpm_doc, rpmdir))
cls.dst = '/tmp/base-passwd-doc.rpm'
@OETestDepends(['rpm.RpmBasicTest.test_rpm_query'])
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193969):
https://lists.openembedded.org/g/openembedded-core/message/193969
Mute This Topic: https://lists.openembedded.org/mt/103805481/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 v3 2/2] shadow: link executables statically for -native variant
I'd like to clarify the 'randomly' part: does the failure disappear if
you re-run bitbake on the same build directory, or is it random only
between different builds? If it's deterministic in the same build
directory, then you can narrow it down to the specific tar invocation
directly from command line perhaps, and then try to see what is it in
the tree that tar operates on, that triggers the error.
Alex
On Thu, 18 Jan 2024 at 10:59, Richard Purdie
wrote:
>
> On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > wrote:
> > >
> > > shadow 4.14.x adds a number of libraries it dynamically links with
> > > (md, bsd, attr). This causes troubles in setscene tasks where
> > > shadow executables are used (such as useradd), as pulling in
> > > the needed dynamic libraries needs unpleasant special-casing.
> > >
> > > Signed-off-by: Alexander Kanavin
> >
> > It seems, this is causing issues with the TuxOE builds. We have been
> > observing issues with the TuxOE build environment with the image
> > creation choking on the home dirs. Reverting this patch seems to fix
> > the problem. The build environment is Ubuntu 20.04 running in a
> > container on Ubuntu 22.04.
> >
> > ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> > ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> > 1, None, None)
> > ERROR: Logfile of failure stored in:
> > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> > Log data follows:
> > > DEBUG: Executing python function set_image_size
> > > DEBUG: 1402908.00 = 1079160 * 1.30
> > > DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> > > DEBUG: 1402908.00 = int(1402908.00)
> > > DEBUG: 1404928 = aligned(1402908)
> > > DEBUG: returning 1404928
> > > DEBUG: Python function set_image_size finished
> > > DEBUG: Executing shell function do_image_tar
> > > tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> > > tar: ./home/linaro/.profile: Unknown file type; file ignored
> > > tar: Exiting with failure status due to previous errors
> > > WARNING:
> > > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> > exit 1 from '[ $? -eq 1 ]'
> >
>
> The error is coming from tar during archive creation, "Unknown file
> type; file ignored". I'm a little confused/concerned about what it is
> seeing which it can't handle.
>
> It might also be good to work out if that is tar from the host or tar
> from tar-native. Is the host's tar unable to support something we're
> relying upon?
>
> If it were me, I'd probably have a look into the tar source code too,
> see what might trigger an error like that.
>
> Cheers,
>
> Richard
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193968):
https://lists.openembedded.org/g/openembedded-core/message/193968
Mute This Topic: https://lists.openembedded.org/mt/103661548/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 v3 2/2] shadow: link executables statically for -native variant
On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> wrote:
> >
> > shadow 4.14.x adds a number of libraries it dynamically links with
> > (md, bsd, attr). This causes troubles in setscene tasks where
> > shadow executables are used (such as useradd), as pulling in
> > the needed dynamic libraries needs unpleasant special-casing.
> >
> > Signed-off-by: Alexander Kanavin
>
> It seems, this is causing issues with the TuxOE builds. We have been
> observing issues with the TuxOE build environment with the image
> creation choking on the home dirs. Reverting this patch seems to fix
> the problem. The build environment is Ubuntu 20.04 running in a
> container on Ubuntu 22.04.
>
> ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> 1, None, None)
> ERROR: Logfile of failure stored in:
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> Log data follows:
> > DEBUG: Executing python function set_image_size
> > DEBUG: 1402908.00 = 1079160 * 1.30
> > DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> > DEBUG: 1402908.00 = int(1402908.00)
> > DEBUG: 1404928 = aligned(1402908)
> > DEBUG: returning 1404928
> > DEBUG: Python function set_image_size finished
> > DEBUG: Executing shell function do_image_tar
> > tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> > tar: ./home/linaro/.profile: Unknown file type; file ignored
> > tar: Exiting with failure status due to previous errors
> > WARNING:
> > /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> exit 1 from '[ $? -eq 1 ]'
>
The error is coming from tar during archive creation, "Unknown file
type; file ignored". I'm a little confused/concerned about what it is
seeing which it can't handle.
It might also be good to work out if that is tar from the host or tar
from tar-native. Is the host's tar unable to support something we're
relying upon?
If it were me, I'd probably have a look into the tar source code too,
see what might trigger an error like that.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193967):
https://lists.openembedded.org/g/openembedded-core/message/193967
Mute This Topic: https://lists.openembedded.org/mt/103661548/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 v3 2/2] shadow: link executables statically for -native variant
On Wed, 17 Jan 2024 at 14:46, Dmitry Baryshkov wrote:
>
> On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> wrote:
> >
> > shadow 4.14.x adds a number of libraries it dynamically links with
> > (md, bsd, attr). This causes troubles in setscene tasks where
> > shadow executables are used (such as useradd), as pulling in
> > the needed dynamic libraries needs unpleasant special-casing.
> >
> > Signed-off-by: Alexander Kanavin
>
> It seems, this is causing issues with the TuxOE builds. We have been
> observing issues with the TuxOE build environment with the image
> creation choking on the home dirs. Reverting this patch seems to fix
> the problem. The build environment is Ubuntu 20.04 running in a
> container on Ubuntu 22.04.
>
> ERROR: rpb-weston-image-1.0-r0 do_image_tar:
> ExecutionError('/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075',
> 1, None, None)
> ERROR: Logfile of failure stored in:
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/log.do_image_tar.160075
> Log data follows:
> | DEBUG: Executing python function set_image_size
> | DEBUG: 1402908.00 = 1079160 * 1.30
> | DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> | DEBUG: 1402908.00 = int(1402908.00)
> | DEBUG: 1404928 = aligned(1402908)
> | DEBUG: returning 1404928
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_tar
> | tar: ./home/linaro/.bashrc: Unknown file type; file ignored
> | tar: ./home/linaro/.profile: Unknown file type; file ignored
> | tar: Exiting with failure status due to previous errors
> | WARNING:
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075:146
> exit 1 from '[ $? -eq 1 ]'
> | WARNING: Backtrace (BB generated script):
> | #1: do_image_tar,
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075,
> line 146
> | #2: main,
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_tar.160075,
> line 152
> NOTE: recipe rpb-weston-image-1.0-r0: task do_image_tar: Failed
> ERROR: Task
> (/oe/build/conf/../../layers/meta-rpb/recipes-samples/images/rpb-weston-image.bb:do_image_tar)
> failed with exit code '1'
>
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing python function set_image_size
> | DEBUG: 1402908.00 = 1079160 * 1.30
> | DEBUG: 1402908.00 = max(1402908.00, 65536)[1402908.00] + 0
> | DEBUG: 1402908.00 = int(1402908.00)
> | DEBUG: 1404928 = aligned(1402908)
> | DEBUG: returning 1404928
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_ext4
> | DEBUG: Executing dd if=/dev/zero
> of=/oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/deploy-rpb-weston-image-image-complete/rpb-weston-image-qcom-armv8a.rootfs-20240117062023.ext4
> seek=1404928 count=0 bs=1024
> | 0+0 records in
> | 0+0 records out
> | 0 bytes copied, 9.0878e-05 s, 0.0 kB/s
> | DEBUG: Actual Rootfs size: 1075376
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/rootfs
> | DEBUG: Actual Partition size: 1438646272
> | DEBUG: Executing mkfs.ext4 -F -b 4096
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/deploy-rpb-weston-image-image-complete/rpb-weston-image-qcom-armv8a.rootfs-20240117062023.ext4
> -d
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/rootfs
> | mke2fs 1.47.0 (5-Feb-2023)
> | Discarding device blocks: 0/351232
> done
> | Creating filesystem with 351232 4k blocks and 87824 inodes
> | Filesystem UUID: 27cefb6f-e38e-44ed-ab0f-4b613d3594f2
> | Superblock backups stored on blocks:
> | 32768, 98304, 163840, 229376, 294912
> |
> | Allocating group tables: 0/11 done
> | Writing inode tables: 0/11 done
> | Creating journal (8192 blocks): done
> | Copying files into the device: __populate_fs: ignoring entry ".bashrc"
> | .bashrc: File not found by ext2_lookup while looking up ".bashrc"
> | mkfs.ext4: File not found by ext2_lookup while populating file system
> | WARNING:
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_ext4.160095:176
> exit 1 from 'mkfs.$fstype -F $extra_imagecmd
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/deploy-rpb-weston-image-image-complete/rpb-weston-image-qcom-armv8a.rootfs-20240117062023.$fstype
> -d
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/rootfs'
> | WARNING: Backtrace (BB generated script):
> | #1: oe_mkext234fs,
> /oe/build/tmp-rpb_wayland-glibc/work/qcom_armv8a-linaro-linux/rpb-weston-image/1.0/temp/run.do_image_ext4.160095,
> line 176
> |
