[OE-core] bitbake fetchall & populate_sdk
G'day All, How can I run fetchall so that it will also fetch all package sources related to the sdk as well as the image. ie: "bitbake -c fetchall myimage" gets all the sources to build myimage, allowing a build to proceed without network access later. Out sdk however includes a few extra total for development purposes, so additional recipes need to download stuff when I run: bitbake -c populate_sdk myimage Done some googling and found one other person asking this, and the solution was to run bitbake -c fetchall universe Which seems a bit of overkill for the couple of extra packages I'm after. -- Regards Phil Reid -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169902): https://lists.openembedded.org/g/openembedded-core/message/169902 Mute This Topic: https://lists.openembedded.org/mt/93264443/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] python3-pygments: upgrade 2.12.0 -> 2.13.0
Signed-off-by: Wang Mingyu
---
.../{python3-pygments_2.12.0.bb => python3-pygments_2.13.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-pygments_2.12.0.bb =>
python3-pygments_2.13.0.bb} (83%)
diff --git a/meta/recipes-devtools/python/python3-pygments_2.12.0.bb
b/meta/recipes-devtools/python/python3-pygments_2.13.0.bb
similarity index 83%
rename from meta/recipes-devtools/python/python3-pygments_2.12.0.bb
rename to meta/recipes-devtools/python/python3-pygments_2.13.0.bb
index b47e0aff67..59706cc200 100644
--- a/meta/recipes-devtools/python/python3-pygments_2.12.0.bb
+++ b/meta/recipes-devtools/python/python3-pygments_2.13.0.bb
@@ -5,7 +5,7 @@ LICENSE = "BSD-2-Clause"
LIC_FILES_CHKSUM = "file://LICENSE;md5=36a13c90514e2899f1eba7f41c3ee592"
inherit setuptools3
-SRC_URI[sha256sum] =
"5eb116118f9612ff1ee89ac96437bb6b49e8f04d8a13b514ba26f620208e26eb"
+SRC_URI[sha256sum] =
"56a8508ae95f98e2b9bdf93a6be5ae3f7d8af858b43e02c5a2ff083726be40c1"
DEPENDS += "\
${PYTHON_PN} \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169901):
https://lists.openembedded.org/g/openembedded-core/message/169901
Mute This Topic: https://lists.openembedded.org/mt/93263098/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 00/28] Pull request (cover letter only)
The following changes since commit 10891d4d955f347c328cf8c099031f05f5c855a2:
lttng-modules: replace mips compaction fix with upstream change (2022-08-17
04:55:49 -1000)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/kirkstone-next
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-next
Alexander Kanavin (9):
bluez5: update 5.64 -> 5.65
libwpe: upgrade 1.12.0 -> 1.12.2
ell: upgrade 0.49 -> 0.50
iso-codes: upgrade 4.10.0 -> 4.11.0
libcap: upgrade 2.64 -> 2.65
libwebp: upgrade 1.2.2 -> 1.2.3
mobile-broadband-provider-info: upgrade 20220511 -> 20220725
webkitgtk: upgrade 2.36.4 -> 2.36.5
weston: upgrade 10.0.1 -> 10.0.2
Beniamin Sandu (1):
libpam: use /run instead of /var/run in systemd tmpfiles
Changqing Li (1):
apt: fix nativesdk-apt build failure during the second time build
Daiane Angolini (1):
python3-pip: Fix RDEPENDS after the update
Ernst Sjöstrand (1):
cve-check: Don't use f-strings
Hitendra Prajapati (1):
libtiff: CVE-2022-34526 A stack overflow was discovered
Jose Quaresma (2):
archiver.bbclass: some recipes that uses the kernelsrc bbclass uses
the shared source
linux-yocto: prepend the the value with a space when append to
KERNEL_EXTRA_ARGS
Kai Kang (1):
packagegroup-self-hosted: update for strace
Khem Raj (4):
libxml2: Ignore CVE-2016-3709
connman: Backports for security fixes
cracklib: Drop using register keyword
tcp-wrappers: Fix implicit-function-declaration warnings
Peter Marko (1):
create-spdx: handle links to inaccessible locations
Richard Purdie (1):
perf: Fix reproducibility issues with 5.19 onwards
Sakib Sajal (3):
u-boot: fix CVE-2022-30552
u-boot: fix CVE-2022-33967
go: update v1.17.12 -> v1.17.13
Yongxin Liu (1):
grub2: fix several CVEs
wangmy (1):
libcap: upgrade 2.63 -> 2.64
meta/classes/archiver.bbclass | 4 +-
meta/classes/create-spdx.bbclass | 2 +-
meta/lib/oe/cve_check.py | 2 +-
...g-Drop-greyscale-support-to-fix-heap.patch | 179 +
...ng-Avoid-heap-OOB-R-W-inserting-huff.patch | 50 ++
...peg-Block-int-underflow-wild-pointer.patch | 84 +++
...3-net-ip-Do-IP-fragment-maths-safely.patch | 63 ++
...or-out-on-headers-with-LF-without-CR.patch | 58 ++
...Fix-OOB-write-for-split-http-headers.patch | 56 ++
...ct-non-kernel-files-in-the-shim_lock.patch | 111 +++
.../video-Remove-trailing-whitespaces.patch | 693 ++
...eg-Abort-sooner-if-a-read-operation-.patch | 264 +++
...eg-Refuse-to-handle-multiple-start-o.patch | 53 ++
meta/recipes-bsp/grub/grub2.inc | 10 +
...s-squashfs-Use-kcalloc-when-relevant.patch | 64 ++
...e-minimum-IP-fragmented-datagram-siz.patch | 207 ++
meta/recipes-bsp/u-boot/u-boot_2022.01.bb | 2 +
meta/recipes-connectivity/bluez5/bluez5.inc | 1 -
.../bluez5/bluez5/fix_service.patch | 30 -
.../bluez5/{bluez5_5.64.bb => bluez5_5.65.bb} | 2 +-
.../connman/connman/CVE-2022-32292.patch | 37 +
.../connman/connman/CVE-2022-32293_p1.patch | 141
.../connman/connman/CVE-2022-32293_p2.patch | 174 +
.../connman/connman_1.41.bb | 3 +
.../mobile-broadband-provider-info_git.bb | 4 +-
.../ell/{ell_0.49.bb => ell_0.50.bb} | 2 +-
meta/recipes-core/libxml/libxml2_2.9.14.bb| 4 +
.../packagegroups/packagegroup-self-hosted.bb | 5 +-
meta/recipes-devtools/apt/apt_2.4.5.bb| 2 +-
.../go/{go-1.17.12.inc => go-1.17.13.inc} | 2 +-
...1.17.12.bb => go-binary-native_1.17.13.bb} | 4 +-
17.12.bb => go-cross-canadian_1.17.13.bb} | 0
...o-cross_1.17.12.bb => go-cross_1.17.13.bb} | 0
...ssdk_1.17.12.bb => go-crosssdk_1.17.13.bb} | 0
...native_1.17.12.bb => go-native_1.17.13.bb} | 0
...ntime_1.17.12.bb => go-runtime_1.17.13.bb} | 0
.../go/{go_1.17.12.bb => go_1.17.13.bb} | 0
.../python/python3-pip_22.0.3.bb | 2 +
...01-rules-Drop-using-register-keyword.patch | 278 +++
...rrect-parameter-types-to-Debug-calls.patch | 40 +
.../cracklib/cracklib_2.9.7.bb| 5 +-
meta/recipes-extended/pam/libpam/99_pam | 2 +-
...plicit-function-declaration-warnings.patch | 109 +++
.../tcp-wrappers/tcp-wrappers_7.6.bb | 1 +
.../weston/dont-use-plane-add-prop.patch | 32 -
.../{weston_10.0.1.bb => weston_10.0.2.bb}| 4 +-
meta/recipes-kernel/linux/linux-yocto.inc | 2 +-
meta/recipes-kernel/perf/perf.bb | 2 +-
.../libtiff/tiff/CVE-2022-34526.patch | 29 +
meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 1 +
.../{libwebp_1.2.2.bb => libwebp_1.2.3.bb}| 2 +-
...ure-due-to-libc-using-libc-functions.patch | 42 ++
.../{libwpe_1.12.0.bb => libwpe_1.12.2.bb}| 6 +-
...ebkitgtk_2.36.4.bb => webkitgtk_2.36.5.bb} | 2 +-
...so-codes_4.10.0.bb => iso-codes_4.11.0.bb} | 2 +-
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
On 2022-08-25 19:24, Khem Raj wrote: On Thu, Aug 25, 2022 at 12:11 PM Randy MacLeod wrote: On 2022-08-25 07:53, Richard Purdie wrote: On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: On Thu, 25 Aug 2022 at 12:59, Richard Purdie wrote: The usptreamable version of the patch would probably be something which splits the target names in no_atomics up into components and matched on subsections of it rather than the whole string. My rust isn't really up to doing that though. I didn't really want us to maintain a separate list of targets which have atomics issues given it and the list in no_atomics would get out of sync very easily too. But then the same patch needs to be applied to (and maintained separately in) librsvg - and everything else that includes a copy of crossbeam. Perhaps it's worth to at least make the above suggestion about making it upstreamable in the patch commit message? Yes, I can improve the patch header. I do understand the patch isn't ideal. The alternatives are: * we take my patch * we break powerpc, mips, armv5, riscv32 and others * we drop the rust upgrades (the latent problem still exists) * we rewrite the patch For me to rewrite the patch, I'll need to learn more rust. I'm sure I can do that but it will take time and that time is time I can't use for other things. I'm hoping that by explaining the issue and documenting it, *someone* would step up and work out the upstreamable patch. This hasn't worked well for the rust recipes so far as I've had to do a lot of work to get them more into shape. I'm hoping the problem was just the shear scale and now issues are in easier smaller pieces others can/will help. It will certainly be time before someone else can schedule that in, we don't have anyone who can do it now. Yes, with the range of things I have had going on, re-writing the rust classes/recipes was too big a task to consider. However, I can and will work to get this patch into a form that is upstreamable. I've created a bug to track that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 and at least started to look at some of the code! Also opening an issue upstream at https://github.com/crossbeam-rs/crossbeam would be a good thing. crossbeam is vendored by many rust packages and we will end up spewing the all such recipes with the tweak in addition to regenerating the checksums in toml files with every upgrade. Agreed and noted in the YP bug. ../Randy ../Randy I will say that I'm really really tired. I have a ton of autobuilder failures and in order to resolve them I'm rewriting patches many times over, first to get them to work, then taking review feedback and people complaining they're not perfect or don't fix other issues. I have a pile of other problems like this. I appreciate the desire not to have patches, particularly when they're as painful as the rust ones are. I appreciate the patch can be improved and should go upstream. I was hoping to take some time off tomorrow but it looks like I have other things to do (in reality probably on the weekend, I need to rework the llvm patches too and both sets take hours in rebuild time even to test). Cheers, Richard -- # Randy MacLeod # Wind River Linux -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169899): https://lists.openembedded.org/g/openembedded-core/message/169899 Mute This Topic: https://lists.openembedded.org/mt/93245408/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] ltp: Remove -mfpmath=sse on x86-64 too
Fixes build errors seen with clang/musl like on x86 error: the 'sse' unit is not supported with this instruction set Signed-off-by: Khem Raj --- meta/recipes-extended/ltp/ltp_20220527.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-extended/ltp/ltp_20220527.bb b/meta/recipes-extended/ltp/ltp_20220527.bb index 09c7250608..00ff906ded 100644 --- a/meta/recipes-extended/ltp/ltp_20220527.bb +++ b/meta/recipes-extended/ltp/ltp_20220527.bb @@ -20,6 +20,7 @@ EXTRA_OECONF:append:libc-musl = " LIBS=-lfts " # earlier in CFLAGS, etc. CFLAGS:append:x86-64 = " -fomit-frame-pointer" TUNE_CCARGS:remove:x86 = "-mfpmath=sse" +TUNE_CCARGS:remove:x86-64 = "-mfpmath=sse" CFLAGS:append:powerpc64 = " -D__SANE_USERSPACE_TYPES__" CFLAGS:append:mipsarchn64 = " -D__SANE_USERSPACE_TYPES__" -- 2.37.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169898): https://lists.openembedded.org/g/openembedded-core/message/169898 Mute This Topic: https://lists.openembedded.org/mt/93260803/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] rust: Fix crossbeam-utils for arches without atomics
On Thu, Aug 25, 2022 at 12:11 PM Randy MacLeod wrote: > > On 2022-08-25 07:53, Richard Purdie wrote: > > On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: > >> On Thu, 25 Aug 2022 at 12:59, Richard Purdie > >> wrote: > >>> The usptreamable version of the patch would probably be something which > >>> splits the target names in no_atomics up into components and matched on > >>> subsections of it rather than the whole string. My rust isn't really up > >>> to doing that though. > >>> > >>> I didn't really want us to maintain a separate list of targets which > >>> have atomics issues given it and the list in no_atomics would get out > >>> of sync very easily too. > >> But then the same patch needs to be applied to (and maintained > >> separately in) librsvg - and everything else that includes a copy of > >> crossbeam. Perhaps it's worth to at least make the above suggestion > >> about making it upstreamable in the patch commit message? > > Yes, I can improve the patch header. I do understand the patch isn't > > ideal. > > > > The alternatives are: > > > > * we take my patch > > * we break powerpc, mips, armv5, riscv32 and others > > * we drop the rust upgrades (the latent problem still exists) > > * we rewrite the patch > > > > For me to rewrite the patch, I'll need to learn more rust. I'm sure I > > can do that but it will take time and that time is time I can't use for > > other things. > > > > I'm hoping that by explaining the issue and documenting it, *someone* > > would step up and work out the upstreamable patch. This hasn't worked > > well for the rust recipes so far as I've had to do a lot of work to get > > them more into shape. I'm hoping the problem was just the shear scale > > and now issues are in easier smaller pieces others can/will help. It > > will certainly be time before someone else can schedule that in, we > > don't have anyone who can do it now. > > Yes, with the range of things I have had going on, re-writing the > rust classes/recipes was too big a task to consider. However, I can > and will work to get this patch into a form that is upstreamable. > > I've created a bug to track that: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 > > and at least started to look at some of the code! > Also opening an issue upstream at https://github.com/crossbeam-rs/crossbeam would be a good thing. crossbeam is vendored by many rust packages and we will end up spewing the all such recipes with the tweak in addition to regenerating the checksums in toml files with every upgrade. > ../Randy > > > > > > I will say that I'm really really tired. > > > > I have a ton of autobuilder failures and in order to resolve them I'm > > rewriting patches many times over, first to get them to work, then > > taking review feedback and people complaining they're not perfect or > > don't fix other issues. I have a pile of other problems like this. > > > > I appreciate the desire not to have patches, particularly when they're > > as painful as the rust ones are. I appreciate the patch can be improved > > and should go upstream. I was hoping to take some time off tomorrow but > > it looks like I have other things to do (in reality probably on the > > weekend, I need to rework the llvm patches too and both sets take hours > > in rebuild time even to test). > > > > Cheers, > > > > Richard > > > > > > > > -- > # Randy MacLeod > # Wind River Linux > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169897): https://lists.openembedded.org/g/openembedded-core/message/169897 Mute This Topic: https://lists.openembedded.org/mt/93245408/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/3] rust-target-config: Fix qemuppc target cpu option
On Thu, Aug 25, 2022 at 3:49 AM Richard Purdie wrote: > > We see a lot of warnings about incorrect processor types on qemuppc, drowning > out anything else. Fix the option. > > Signed-off-by: Richard Purdie > --- > meta/classes-recipe/rust-target-config.bbclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/classes-recipe/rust-target-config.bbclass > b/meta/classes-recipe/rust-target-config.bbclass > index e30eaa1da30..259cba7bbd0 100644 > --- a/meta/classes-recipe/rust-target-config.bbclass > +++ b/meta/classes-recipe/rust-target-config.bbclass > @@ -272,7 +272,7 @@ def llvm_cpu(d): > trans['x86-64'] = "x86-64" > trans['i686'] = "i686" > trans['i586'] = "i586" > -trans['powerpc'] = "powerpc" > +trans['powerpc'] = "7400" that seems to be dependent on what tune we select I guess. So it might not work on other ppc tunes. > trans['mips64'] = "mips64" > trans['mips64el'] = "mips64" > trans['riscv64'] = "generic-rv64" > -- > 2.34.1 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169896): https://lists.openembedded.org/g/openembedded-core/message/169896 Mute This Topic: https://lists.openembedded.org/mt/93245410/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] apr: Cache configure tests which use AC_TRY_RUN
On Thu, Aug 25, 2022 at 1:35 PM Luca Ceresoli wrote: > > Hi Khem, > > On Thu, 25 Aug 2022 00:21:03 -0700 > "Khem Raj" wrote: > > > AC_TRY_RUN macro means the test needs to run to find the result and we > > are cross compiling so this will always get wrong results, this results > > in miscompiling apache2 on musl because it disables rlimit > > (ac_cv_struct_rlimit) wrongly. > > > > All these variables are determined with AC_TRY_RUN checks > > > > Signed-off-by: Khem Raj > > There are several failures with this patch applied: > > | locks/unix/proc_mutex.c: In function 'proc_mutex_choose_method': > | locks/unix/proc_mutex.c:1494:28: error: 'mutex_proc_pthread_methods' > undeclared (first use in this function); did you mean > 'mutex_posixsem_methods'? > | 1494 | new_mutex->meth = _proc_pthread_methods; > | |^~ > | |mutex_posixsem_methods > > and other undeclared mutex-related symbols. > > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/1446/steps/12/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/3720/steps/11/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5767/steps/11/logs/stdio > Yeah, I will take a look and perhaps trim the list to minimum what we need for apache2 > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169895): https://lists.openembedded.org/g/openembedded-core/message/169895 Mute This Topic: https://lists.openembedded.org/mt/93243812/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [poky][PATCH] Fix npm to use https rather than http
Hit this error while building nlf-native recently:
{
"error": {
"summary": "URI malformed",
"detail": ""
}
}
Some poking about led me to discover that:
1) The npm.py tool replaces npm:// with http://, not https://
2) Some versions of the npm tool don't handle 301 redirects properly,
choosing to display the above error instead when using the default
nodejs registry
It would be good to go fix npm to handle the redirect properly, but it
seems like it would also be good to assume secure http when contacting a
registry, hence, this patch
Signed-off-by: Neil Horman
---
bitbake/lib/bb/fetch2/npm.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bitbake/lib/bb/fetch2/npm.py b/bitbake/lib/bb/fetch2/npm.py
index 8f7c10ac9b..8a179a339a 100644
--- a/bitbake/lib/bb/fetch2/npm.py
+++ b/bitbake/lib/bb/fetch2/npm.py
@@ -156,7 +156,7 @@ class Npm(FetchMethod):
raise ParameterError("Invalid 'version' parameter", ud.url)
# Extract the 'registry' part of the url
-ud.registry = re.sub(r"^npm://", "http://;, ud.url.split(";")[0])
+ud.registry = re.sub(r"^npm://", "https://;, ud.url.split(";")[0])
# Using the 'downloadfilename' parameter as local filename
# or the npm package name.
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169894):
https://lists.openembedded.org/g/openembedded-core/message/169894
Mute This Topic: https://lists.openembedded.org/mt/93257181/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] apr: Cache configure tests which use AC_TRY_RUN
Hi Khem, On Thu, 25 Aug 2022 00:21:03 -0700 "Khem Raj" wrote: > AC_TRY_RUN macro means the test needs to run to find the result and we > are cross compiling so this will always get wrong results, this results > in miscompiling apache2 on musl because it disables rlimit > (ac_cv_struct_rlimit) wrongly. > > All these variables are determined with AC_TRY_RUN checks > > Signed-off-by: Khem Raj There are several failures with this patch applied: | locks/unix/proc_mutex.c: In function 'proc_mutex_choose_method': | locks/unix/proc_mutex.c:1494:28: error: 'mutex_proc_pthread_methods' undeclared (first use in this function); did you mean 'mutex_posixsem_methods'? | 1494 | new_mutex->meth = _proc_pthread_methods; | |^~ | |mutex_posixsem_methods and other undeclared mutex-related symbols. https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/1446/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/3720/steps/11/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5767/steps/11/logs/stdio -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169893): https://lists.openembedded.org/g/openembedded-core/message/169893 Mute This Topic: https://lists.openembedded.org/mt/93243812/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/5] scripts/oe-setup-layers: add a script that restores the layer configuration from a json file
This script can be used directly from poky or oe-core, or can be copied directly
into alayer or any other repository - it is self-suffucient and requires only
python3
and git on the host where it will run. It is also copied by the bitbake-layers
layers-setup plugin together with the json, unless requested otherwise.
1. How to restore the layers from the saved configuration:
a) Clone the bootstrap layer or some other repository to obtain the json config
and the setup script that can use it.
(use 'bitbake-layers create-layer-setup' from the previous commit to create
them)
b) Running with default options:
(note: this will work to update an existing checkout as well)
alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers
Note: not checking out source meta-alex, use --force-bootstraplayer-checkout to
override.
Setting up source meta-intel, revision 15.0-hardknott-3.3-310-g0a96edae, branch
master
Running 'git init -q /srv/work/alex/my-build/meta-intel'
Running 'git remote remove origin > /dev/null 2>&1; git remote add origin
git://git.yoctoproject.org/meta-intel' in /srv/work/alex/my-build/meta-intel
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/meta-intel
Running 'git checkout -q 0a96edae609a3f48befac36af82cf1eed6786b4a' in
/srv/work/alex/my-build/meta-intel
Setting up source poky, revision 4.1_M1-372-g55483d28f2, branch
akanavin/setup-layers
Running 'git init -q /srv/work/alex/my-build/poky'
Running 'git remote remove origin > /dev/null 2>&1; git remote add origin
git://git.yoctoproject.org/poky' in /srv/work/alex/my-build/poky
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/poky
Running 'git remote remove poky-contrib > /dev/null 2>&1; git remote add
poky-contrib ssh://g...@push.yoctoproject.org/poky-contrib' in
/srv/work/alex/my-build/poky
Running 'git fetch -q poky-contrib || true' in /srv/work/alex/my-build/poky
Running 'git checkout -q 11db0390b02acac1324e0f827beb0e2e3d0d1d63' in
/srv/work/alex/my-build/poky
2. Command line options:
alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers -h
usage: setup-layers [-h] [--force-bootstraplayer-checkout] [--destdir DESTDIR]
[--jsondata JSONDATA]
A self contained python script that fetches all the needed layers and sets them
to correct revisions
optional arguments:
-h, --helpshow this help message and exit
--force-bootstraplayer-checkout
Force the checkout of the layer containing this file
(by default it is presumed that as this script is in it, the layer is already
in place).
--destdir DESTDIR Where to check out the layers (default is
/srv/work/alex/my-build).
--jsondata JSONDATA File containing the layer data in json format (default
is /srv/work/alex/my-build/meta-alex/setup-layers.json).
Signed-off-by: Alexander Kanavin
---
scripts/oe-setup-layers | 88 +
1 file changed, 88 insertions(+)
create mode 100755 scripts/oe-setup-layers
diff --git a/scripts/oe-setup-layers b/scripts/oe-setup-layers
new file mode 100755
index 00..cbd2efb5c7
--- /dev/null
+++ b/scripts/oe-setup-layers
@@ -0,0 +1,88 @@
+#!/usr/bin/env python3
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+# This file was copied from poky(or oe-core)/scripts/oe-setup-layers by running
+#
+# bitbake-layers create-layers-setup destdir
+#
+# It is recommended that you do not modify this file directly, but rather
re-run the above command to get the freshest upstream copy.
+
+import argparse
+import json
+import os
+import subprocess
+
+def _do_checkout(args, json):
+layers = json['sources']
+buildconfs = []
+oecorepath = ""
+for l_name in layers:
+l_data = layers[l_name]
+layerdir = os.path.abspath(os.path.join(args['destdir'],
l_data['path']))
+
+for ll_name in l_data['layers']:
+if ll_name == 'meta':
+oecorepath = layerdir
+ll_data = l_data['layers'][ll_name]
+if 'buildconfigs' in ll_data:
+for c in ll_data['buildconfigs']:
+buildconfs.append(os.path.join(layerdir,
ll_data['subpath'], c))
+
+if 'contains_this_file' in l_data.keys():
+force_arg = 'force_bootstraplayer_checkout'
+if not args[force_arg]:
+print('Note: not checking out source {layer}, use {layerflag}
to override.'.format(layer=l_name, layerflag='--force-bootstraplayer-checkout'))
+continue
+l_remote = l_data['git-remote']
+rev = l_remote['rev']
+desc = l_remote['describe']
+if not desc:
+desc = rev[:10]
+branch = l_remote['branch']
+remotes = l_remote['remotes']
+
+print('\nSetting up source {}, revision {}, branch {}'.format(l_name,
desc, branch))
+cmd = 'git init -q {}'.format(layerdir)
+print("Running '{}'".format(cmd))
+subprocess.check_output(cmd,
[OE-core] [PATCH 5/5] selftest/bblayers: add a test for creating a layer setup and using it to restore the layers
This does a basic run-through of the bitbake-layers plugin, and the resulting
json layer config
and the layer setup script that uses it. Only poky is actually fetched by the
script.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/bblayers.py | 22 ++
1 file changed, 22 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/bblayers.py
b/meta/lib/oeqa/selftest/cases/bblayers.py
index c753a7b795..18007764b3 100644
--- a/meta/lib/oeqa/selftest/cases/bblayers.py
+++ b/meta/lib/oeqa/selftest/cases/bblayers.py
@@ -142,3 +142,25 @@ class BitbakeLayers(OESelftestTestCase):
def test_validate_examplelayersjson(self):
json = os.path.join(get_bb_var('COREBASE'),
"meta/files/layers.example.json")
self.validate_layersjson(json)
+
+def test_bitbakelayers_setup(self):
+result = runCmd('bitbake-layers create-layers-setup
{}'.format(self.testlayer_path))
+jsonfile = os.path.join(self.testlayer_path, "setup-layers.json")
+self.validate_layersjson(jsonfile)
+
+# The revision-under-test may not necessarily be available on the
remote server,
+# so replace it with a stable release tag.
+import json
+with open(jsonfile) as f:
+data = json.load(f)
+for s in data['sources']:
+data['sources'][s]['git-remote']['rev'] = 'yocto-4.0'
+with open(jsonfile, 'w') as f:
+json.dump(data, f)
+
+testcheckoutdir = os.path.join(self.builddir, 'test-layer-checkout')
+result = runCmd('{}/setup-layers --destdir
{}'.format(self.testlayer_path, testcheckoutdir))
+# May not necessarily be named 'poky' or 'openembedded-core'
+oecoredir = os.listdir(testcheckoutdir)[0]
+testcheckoutfile = os.path.join(testcheckoutdir, oecoredir,
"oe-init-build-env")
+self.assertTrue(os.path.exists(testcheckoutfile), "File {} not found
in test layer checkout".format(testcheckoutfile))
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169892):
https://lists.openembedded.org/g/openembedded-core/message/169892
Mute This Topic: https://lists.openembedded.org/mt/93257026/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/5] meta/files: add layer setup JSON schema and example
From: Joshua Watt
Defines a common schema for layer setup that can be consumed by tools to
know how to fetch and assemble layers for end users. Also includes an
example of the layer setup that constructs poky/meta-intel/imaginary product
layer
for reference.
The schema can be used to validate a layer setup file with the commands:
$ python3 -m pip install jsonschema
$ jsonschema -i meta/files/layers.example.json meta/files/layers.schema.json
Signed-off-by: Joshua Watt
Alex: I made the following modifications to Joshua's original commit:
- moved the files from meta/lib to meta/files
- the example json showcases a multi-repo, multi-layer setup
instead of just poky - closer to a typical product
- added oe-selftest that validates the example json against the schema using
python3-jsonschema-native
- the schema is modified so that:
-- all lists (sources, layers, remotes) are replaced by objects keyed by 'name'
properties of the list items.
This allows using them as dicts inside Python, and makes the json more compact
and readable.
-- added 'contains_this_file' property to source object
-- replaced 'remote' property with a 'oneOf' definition for git with a specific
'git-remote' property. 'oneOf' is problematic when schema validation fails:
the diagnostic is only that none of oneOf variants matched, which is too
non-specific.
-- added 'describe' property to 'git-remote' object.
-- removed description property for a layer source: it is not clear how to add
that
when auto-generating the json
Signed-off-by: Alexander Kanavin
---
meta/files/layers.example.json | 72 +++
meta/files/layers.schema.json| 91
meta/lib/oeqa/selftest/cases/bblayers.py | 16 -
3 files changed, 178 insertions(+), 1 deletion(-)
create mode 100644 meta/files/layers.example.json
create mode 100644 meta/files/layers.schema.json
diff --git a/meta/files/layers.example.json b/meta/files/layers.example.json
new file mode 100644
index 00..3772404ec9
--- /dev/null
+++ b/meta/files/layers.example.json
@@ -0,0 +1,72 @@
+{
+"sources": {
+"meta-alex": {
+"contains_this_file": true,
+"git-remote": {
+"branch": "master",
+"describe": "",
+"remotes": {
+"remote-alex": {
+"uri": "https://github.com/kanavin/meta-alex;
+}
+},
+"rev": "05b25605fb8b2399e4706d7323828676bf0da0b5"
+},
+"layers": {
+"meta-alex": {
+"subpath": ""
+}
+},
+"path": "meta-alex"
+},
+"meta-intel": {
+"git-remote": {
+"branch": "master",
+"describe": "15.0-hardknott-3.3-310-g0a96edae",
+"remotes": {
+"origin": {
+"uri": "git://git.yoctoproject.org/meta-intel"
+}
+},
+"rev": "0a96edae609a3f48befac36af82cf1eed6786b4a"
+},
+"layers": {
+"meta-intel": {
+"subpath": ""
+}
+},
+"path": "meta-intel"
+},
+"poky": {
+"git-remote": {
+"branch": "akanavin/setup-layers",
+"describe": "4.1_M1-374-g9dda719b2a",
+"remotes": {
+"origin": {
+"uri": "git://git.yoctoproject.org/poky"
+},
+"poky-contrib": {
+"uri": "ssh://g...@push.yoctoproject.org/poky-contrib"
+}
+},
+"rev": "9dda719b2a4727a4d43a6ab8d9e23f8ca68790ec"
+},
+"layers": {
+"meta": {
+"subpath": "meta"
+},
+"meta-poky": {
+"subpath": "meta-poky"
+},
+"meta-selftest": {
+"subpath": "meta-selftest"
+},
+"meta-yocto-bsp": {
+"subpath": "meta-yocto-bsp"
+}
+},
+"path": "poky"
+}
+},
+"version": "1.0"
+}
diff --git a/meta/files/layers.schema.json b/meta/files/layers.schema.json
new file mode 100644
index 00..cd4ddd3dcd
--- /dev/null
+++ b/meta/files/layers.schema.json
@@ -0,0 +1,91 @@
+{
+"description": "OpenEmbedder Layer Setup Manifest",
+"type": "object",
+"additionalProperties": false,
+"required": [
+"version"
+],
+"properties": {
+"version": {
+"description": "The version of this document; currently '1.0'",
+"enum": ["1.0"]
+},
+"sources": {
+"description": "The dict of layer sources",
+"type":
[OE-core] [PATCH 3/5] bitbake-layers: add ability to save current layer repository configuration into a file
This addresses a long standing gap in the core offering:
there is no tooling to capture the currently configured layers
with their revisions, or restore the layers from a configuration
file (without using external tools, some of which aren't particularly
suitable for the task). This plugin addresses the 'capture' part.
Note that the actual writing is performed by a sub-plugin; one such
sub-plugin is provided (for the json + python script format), but
more can be added (e.g. kas, repo, etc.).
How to save a layer configuration:
a) Running with default choices:
$ bitbake-layers create-layers-setup /srv/work/alex/meta-alex/
NOTE: Starting bitbake server...
NOTE: Created /srv/work/alex/meta-alex/setup-layers.json
NOTE: Created /srv/work/alex/meta-alex/setup-layers
b) Command line options:
NOTE: Starting bitbake server...
usage: bitbake-layers create-layers-setup [-h] [--output-prefix OUTPUT_PREFIX]
[--writer {oe-setup-layers}] [--json-only] destdir
Writes out a configuration file and/or a script that replicate the directory
structure and revisions of the layers in a current build.
positional arguments:
destdir Directory where to write the output
(if it is inside one of the layers, the layer becomes a
bootstrap repository and thus will be excluded from fetching).
optional arguments:
-h, --helpshow this help message and exit
--output-prefix OUTPUT_PREFIX, -o OUTPUT_PREFIX
File name prefix for the output files, if the default
(setup-layers) is undesirable.
--writer {oe-setup-layers}, -w {oe-setup-layers}
Choose the output format (defaults to oe-setup-layers).
Currently supported options are:
oe-setup-layers - a self-contained python script and a
json config for it.
--json-only When using the oe-setup-layers writer, write only the
layer configuruation in json format. Otherwise, also a copy of
scripts/oe-setup-layers (from oe-core or poky) is provided, which is a self
contained python script that fetches all the needed layers and sets them to
correct revisions using the data from the json.
Signed-off-by: Alexander Kanavin
---
meta/lib/bblayers/makesetup.py| 108 ++
.../bblayers/setupwriters/oe-setup-layers.py | 50
2 files changed, 158 insertions(+)
create mode 100644 meta/lib/bblayers/makesetup.py
create mode 100644 meta/lib/bblayers/setupwriters/oe-setup-layers.py
diff --git a/meta/lib/bblayers/makesetup.py b/meta/lib/bblayers/makesetup.py
new file mode 100644
index 00..bef6da0ea8
--- /dev/null
+++ b/meta/lib/bblayers/makesetup.py
@@ -0,0 +1,108 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import logging
+import os
+import stat
+import sys
+import shutil
+
+import bb.utils
+import bb.process
+
+from bblayers.common import LayerPlugin
+
+logger = logging.getLogger('bitbake-layers')
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(__file__)))
+
+import oe.buildcfg
+
+def plugin_init(plugins):
+return MakeSetupPlugin()
+
+class MakeSetupPlugin(LayerPlugin):
+
+def _get_repo_path(self, layer_path):
+repo_path, _ = bb.process.run('git rev-parse --show-toplevel',
cwd=layer_path)
+return repo_path.strip()
+
+def _get_remotes(self, repo_path):
+remotes = {}
+remotes_list,_ = bb.process.run('git remote', cwd=repo_path)
+for r in remotes_list.split():
+uri,_ = bb.process.run('git remote get-url {r}'.format(r=r),
cwd=repo_path)
+remotes[r] = {'uri':uri.strip()}
+return remotes
+
+def _get_describe(self, repo_path):
+try:
+describe,_ = bb.process.run('git describe --tags', cwd=repo_path)
+except bb.process.ExecutionError:
+return ""
+return describe.strip()
+
+def make_repo_config(self, destdir):
+""" This is a helper function for the writer plugins that discovers
currently confugured layers.
+The writers do not have to use it, but it can save a bit of work and
avoid duplicated code, hence it is
+available here. """
+repos = {}
+layers = oe.buildcfg.get_layer_revisions(self.tinfoil.config_data)
+try:
+destdir_repo = self._get_repo_path(destdir)
+except bb.process.ExecutionError:
+destdir_repo = None
+
+for (l_path, l_name, l_branch, l_rev, l_ismodified) in layers:
+if l_name == 'workspace':
+continue
+if l_ismodified:
+logger.error("Layer {name} in {path} has uncommitted
modifications or is not in a git repository.".format(name=l_name,path=l_path))
+return
+repo_path = self._get_repo_path(l_path)
+if repo_path not in repos.keys():
+repos[repo_path] =
[OE-core] [PATCH 1/5] bitbake-layers: add a command to save the active build configuration as a template into a layer
This is the reverse of setting up a build by pointing TEMPLATECONF to a
directory
with a template and running '. oe-init-build-env': this takes the config files
from build/conf,
replaces site-specific paths in bblayers.conf with ##OECORE##-relative paths,
and copies
the config files into a specified layer under a specified template name.
In many or perhaps most cases such static prefabricated configurations (that
require no
further editing) are just enough, and I believe they should be offered by the
official configuration management. On the other hand, generating build
configurations with a
sufficiently versatile tool is a far more complex problem, and one we should
try to tackle
once we see where and how static configs fall short.
Tooling to discover and select these templates when setting up a build will be
provided later on.
How to use:
alex@Zen2:/srv/work/alex/poky/build-layersetup$ bitbake-layers save-build-conf
../../meta-alex/ test-1
NOTE: Starting bitbake server...
NOTE: Configuration template placed into
/srv/work/alex/meta-alex/conf/templates/test-1
Please review the files in there, and particularly provide a configuration
description in /srv/work/alex/meta-alex/conf/templates/test-1/conf-notes.txt
You can try out the configuration with
TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/test-1 .
/srv/work/alex/poky/oe-init-build-env build-try-test-1
alex@Zen2:/srv/work/alex/poky/build-layersetup$
Signed-off-by: Alexander Kanavin
---
meta/lib/bblayers/buildconf.py | 85
meta/lib/oeqa/selftest/cases/bblayers.py | 5 ++
2 files changed, 90 insertions(+)
create mode 100644 meta/lib/bblayers/buildconf.py
diff --git a/meta/lib/bblayers/buildconf.py b/meta/lib/bblayers/buildconf.py
new file mode 100644
index 00..e07fc534e1
--- /dev/null
+++ b/meta/lib/bblayers/buildconf.py
@@ -0,0 +1,85 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import logging
+import os
+import stat
+import sys
+import shutil
+import json
+
+import bb.utils
+import bb.process
+
+from bblayers.common import LayerPlugin
+
+logger = logging.getLogger('bitbake-layers')
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(__file__)))
+
+import oe.buildcfg
+
+def plugin_init(plugins):
+return BuildConfPlugin()
+
+class BuildConfPlugin(LayerPlugin):
+notes_fixme = """FIXME: Please place here the description of this build
configuration.
+It will be shown to the users when they set up their builds via TEMPLATECONF.
+"""
+
+def _save_conf(self, templatename, templatepath, oecorepath,
relpaths_to_oecore):
+confdir = os.path.join(os.environ["BBPATH"], "conf")
+destdir = os.path.join(templatepath, "conf", "templates", templatename)
+os.makedirs(destdir, exist_ok=True)
+
+with open(os.path.join(confdir, "local.conf")) as src:
+with open(os.path.join(destdir, "local.conf.sample"), 'w') as dest:
+dest.write(src.read())
+
+with open(os.path.join(confdir, "bblayers.conf")) as src:
+with open(os.path.join(destdir, "bblayers.conf.sample"), 'w') as
dest:
+bblayers_data = src.read()
+
+for (abspath, relpath) in relpaths_to_oecore:
+bblayers_data = bblayers_data.replace(abspath,
"##OEROOT##/" + relpath)
+dest.write(bblayers_data)
+
+with open(os.path.join(destdir, "conf-notes.txt"), 'w') as dest:
+dest.write(self.notes_fixme)
+
+logger.info("""Configuration template placed into {}
+Please review the files in there, and particularly provide a configuration
description in {}
+You can try out the configuration with
+TEMPLATECONF={} . {}/oe-init-build-env build-try-{}"""
+.format(destdir, os.path.join(destdir, "conf-notes.txt"), destdir, oecorepath,
templatename))
+
+def do_save_build_conf(self, args):
+""" Save the currently active build configuration (conf/local.conf,
conf/bblayers.conf) as a template into a layer.\n This template can later be
used for setting up builds via TEMPLATECONF. """
+repos = {}
+layers = oe.buildcfg.get_layer_revisions(self.tinfoil.config_data)
+targetlayer = None
+oecore = None
+
+for l in layers:
+if l[0] == os.path.abspath(args.layerpath):
+targetlayer = l[0]
+if l[1] == 'meta':
+oecore = os.path.dirname(l[0])
+
+if not targetlayer:
+logger.error("Layer {} not in one of the currently enabled
layers:\n{}".format(args.layerpath, "\n".join([l[0] for l in layers])))
+elif not oecore:
+logger.error("Openembedded-core not in one of the currently
enabled layers:\n{}".format("\n".join([l[0] for l in layers])))
+else:
+relpaths_to_oecore = [(l[0], os.path.relpath(l[0], start=oecore))
for l in layers]
+self._save_conf(args.templatename, targetlayer,
[OE-core] [master][PATCH] image_types: add 7-Zip support in conversion types and commands
I added to support 7-Zip in conversion types/commands. It is fully configurable
in compression level, method and file extension.
From: "Benjamin Szőke"
Date: Thu, 25 Aug 2022 21:45:55 +0200
Subject: [PATCH] image_types: add 7-Zip support in conversion types and commands
---
meta/classes-recipe/image_types.bbclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/image_types.bbclass
b/meta/classes-recipe/image_types.bbclass
index a731e585b2..94aa1d9510 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -59,6 +59,10 @@ XZ_INTEGRITY_CHECK ?= "crc32"
ZIP_COMPRESSION_LEVEL ?= "-9"
+7ZIP_COMPRESSION_LEVEL ?= "9"
+7ZIP_COMPRESSION_METHOD ?= "BZip2"
+7ZIP_EXTENSION ?= "zip"
+
ZSTD_COMPRESSION_LEVEL ?= "-3"
JFFS2_SUM_EXTRA_ARGS ?= ""
@@ -296,7 +300,7 @@ IMAGE_TYPES:append:x86-64 = " hddimg iso"
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync
zsync ${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip 7zip zst sum md5sum sha1sum
sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2
base64 gzsync zsync ${COMPRESSIONTYPES}"
CONVERSION_CMD:lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:gz = "gzip -f -9 -n -c --rsyncable
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD:bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -304,6 +308,7 @@ CONVERSION_CMD:xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL}
${XZ_DEFAULTS} --check=
CONVERSION_CMD:lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD:7zip = "7za a -mx=${7ZIP_COMPRESSION_LEVEL}
-mm=${7ZIP_COMPRESSION_METHOD}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.${7ZIP_EXTENSION}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD:zst = "zstd -f -k -T0 -c ${ZSTD_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
CONVERSION_CMD:sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD:md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
@@ -329,6 +334,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_7zip = "p7zip-native"
CONVERSION_DEPENDS_zst = "zstd-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
--
2.35.1.windows.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169887):
https://lists.openembedded.org/g/openembedded-core/message/169887
Mute This Topic: https://lists.openembedded.org/mt/93256288/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 2/2] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid
> -Original Message- > From: Alexander Kanavin > Sent: den 25 augusti 2022 11:19 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org; Alexander Kanavin > ; Richard Purdie > Subject: Re: [OE-core] [PATCH 2/2] scripts/oe-setup-builddir: add a check > that TEMPLATECONF is valid > > On Thu, 25 Aug 2022 at 09:19, Peter Kjellerstedt > wrote: > > > > > We are trying to move towards standardizing build configuration > > > management. One step towards that goal is that config templates must > > > live in meta-some-layer/conf/templates, and aren't scattered around, > > > or generated on the fly. This rule only makes sense if there is some > > > way to enforce it, which is what this change does. > > > > Well, we gave up on the static templates almost immediately after we > > started using Yocto when we realized that they did not fit into our > > idea of being able to mix layers in different combinations in different > > builds. We rely on repo fetching the layers that are supposed to be part > > of the build, and then we generate a bblayers.conf.sample that matches > > the fetched layers. > > The static templates is only a starting point. The next step would be > to support prefabricated 'configuration fragments' stored inside > layers that can be dynamically added/removed into local.conf and/or a > distro definition, so ideas for the design and UI would be welcome. Well, the way we have solved that is to allow a layer to contain conf/local.conf.sample.XX files (and also conf/conf-notes.txt.XX files) where XX is any number between 00 and 99. We also assume the sample files from meta-poky have XX == 50. Then when we generate our templateconf directory, we concatenate all these files ordered by XX (regardless of which layer they come from). > > Alex //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169886): https://lists.openembedded.org/g/openembedded-core/message/169886 Mute This Topic: https://lists.openembedded.org/mt/93225500/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] rust: Fix crossbeam-utils for arches without atomics
On 2022-08-25 07:53, Richard Purdie wrote: On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: On Thu, 25 Aug 2022 at 12:59, Richard Purdie wrote: The usptreamable version of the patch would probably be something which splits the target names in no_atomics up into components and matched on subsections of it rather than the whole string. My rust isn't really up to doing that though. I didn't really want us to maintain a separate list of targets which have atomics issues given it and the list in no_atomics would get out of sync very easily too. But then the same patch needs to be applied to (and maintained separately in) librsvg - and everything else that includes a copy of crossbeam. Perhaps it's worth to at least make the above suggestion about making it upstreamable in the patch commit message? Yes, I can improve the patch header. I do understand the patch isn't ideal. The alternatives are: * we take my patch * we break powerpc, mips, armv5, riscv32 and others * we drop the rust upgrades (the latent problem still exists) * we rewrite the patch For me to rewrite the patch, I'll need to learn more rust. I'm sure I can do that but it will take time and that time is time I can't use for other things. I'm hoping that by explaining the issue and documenting it, *someone* would step up and work out the upstreamable patch. This hasn't worked well for the rust recipes so far as I've had to do a lot of work to get them more into shape. I'm hoping the problem was just the shear scale and now issues are in easier smaller pieces others can/will help. It will certainly be time before someone else can schedule that in, we don't have anyone who can do it now. Yes, with the range of things I have had going on, re-writing the rust classes/recipes was too big a task to consider. However, I can and will work to get this patch into a form that is upstreamable. I've created a bug to track that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14904 and at least started to look at some of the code! ../Randy I will say that I'm really really tired. I have a ton of autobuilder failures and in order to resolve them I'm rewriting patches many times over, first to get them to work, then taking review feedback and people complaining they're not perfect or don't fix other issues. I have a pile of other problems like this. I appreciate the desire not to have patches, particularly when they're as painful as the rust ones are. I appreciate the patch can be improved and should go upstream. I was hoping to take some time off tomorrow but it looks like I have other things to do (in reality probably on the weekend, I need to rework the llvm patches too and both sets take hours in rebuild time even to test). Cheers, Richard -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169885): https://lists.openembedded.org/g/openembedded-core/message/169885 Mute This Topic: https://lists.openembedded.org/mt/93245408/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][PATCHv2] connman: add PACKAGECONFIG to support iwd
Am Do, 25. Aug 2022 um 12:17:06 + schrieb Ross Burton : Note that if wpa_supplicant and iwd are mutually exclusive, you can express that in the PACKAGECONFIG: I didn't want to make the decision whether wpa_supplicant and iwd should be mutually exclusive. Although I think mixed operation is nonsensical, it will probably be possible with the appropriate configuration. Just let me know if you want me to add it as rconflict in PACKAGECONFIG -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169884): https://lists.openembedded.org/g/openembedded-core/message/169884 Mute This Topic: https://lists.openembedded.org/mt/93225636/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-yocto: Fix COMPATIBLE_MACHINE regex match
From: Andrei Gherzan
With the current regex expression, a machine that is not part of the
compatible could match the regex expression.
For example, consider the following COMPATIBLE_MACHINE:
COMPATIBLE_MACHINE = "qemuarm|qemuarm64"
A machine definition bringing in "qemuarm-foo" would match against the
COMPATIBLE_MACHINE pattern above (see base.bbclass for implementation
details).
Fix this by matching the start and the end of the string.
Signed-off-by: Andrei Gherzan
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_5.15.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_5.19.bb | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 5a420b7fb2..b1b57beac3 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -50,7 +50,7 @@ PACKAGECONFIG[dt-validation] = ",,python3-dtschema-native"
# we need the wrappers if validation isn't in the packageconfig
DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'dt-validation', '',
'python3-dtschema-wrapper-native', d)}"
-COMPATIBLE_MACHINE =
"(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)"
+COMPATIBLE_MACHINE =
"^(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)$"
KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index f374fb593f..9e37494a4b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
LINUX_KERNEL_TYPE = "preempt-rt"
-COMPATIBLE_MACHINE =
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE =
"^(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)$"
KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
index 60ca638bdd..c12bec3e4e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.19.bb
@@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
LINUX_KERNEL_TYPE = "preempt-rt"
-COMPATIBLE_MACHINE =
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+COMPATIBLE_MACHINE =
"^(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)$"
KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index f1b6f98c77..2de32ffecd 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -22,7 +22,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5"
+COMPATIBLE_MACHINE = "^(qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5)$"
# Functionality flags
KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
index c1638f5cc2..339f7f69a6 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.19.bb
@@ -22,7 +22,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.19;destsuffix=${KMETA}"
-COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5"
+COMPATIBLE_MACHINE = "^(qemux86|qemux86-64|qemuarm64|qemuarm|qemuarmv5)$"
# Functionality flags
KERNEL_FEATURES = ""
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 26cdfb744a..40c430aee3 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -51,7 +51,7 @@ KCONF_BSP_AUDIT_LEVEL = "1"
KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
-COMPATIBLE_MACHINE =
"qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemuppc64|qemumips|qemumips64|qemux86-64|qemuriscv64|qemuriscv32"
+COMPATIBLE_MACHINE =
"^(qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemuppc64|qemumips|qemumips64|qemux86-64|qemuriscv64|qemuriscv32)$"
# Functionality flags
KERNEL_EXTRA_FEATURES
[OE-core] [kirkstone][PATCH 3/3] shadow: Avoid nss warning/error with musl
From: Andrei Gherzan
The libnss configuration file is only installed when glibc is used. The
inexistence of it on a musl-based rootfs, will make shadow complain
about it:
Failed opening /etc/nsswitch.conf
This is because shadow will try to use nsswich when dealing with
subordinate IDs and the message is just a warning as the tool will still
generate them correctly in subuid/subgid files.
We drop this log message for class native to avoid an error when rootfs
logs are checked ('Failed' will match the regex bitbake is using to
check for rootfs generation errors).
Signed-off-by: Andrei Gherzan
---
...f-message-when-not-in-place-eg.-musl.patch | 27 +++
meta/recipes-extended/shadow/shadow.inc | 2 ++
2 files changed, 29 insertions(+)
create mode 100644
meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
diff --git
a/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
new file mode 100644
index 00..6c04769713
--- /dev/null
+++
b/meta/recipes-extended/shadow/files/0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch
@@ -0,0 +1,27 @@
+From aed5a184401fbbe901cb825be4004ced885b6f9a Mon Sep 17 00:00:00 2001
+From: Andrei Gherzan
+Date: Wed, 24 Aug 2022 00:54:47 +0200
+Subject: [PATCH] Drop nsswitch.conf message when not in place - eg. musl
+
+Upstream-Status: Inappropriate [issue reported at
https://github.com/shadow-maint/shadow/issues/557]
+Signed-off-by: Andrei Gherzan
+---
+ lib/nss.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/nss.c b/lib/nss.c
+index af3e95a..74e0e16 100644
+--- a/lib/nss.c
b/lib/nss.c
+@@ -57,7 +57,7 @@ void nss_init(char *nsswitch_path) {
+ // subid: files
+ nssfp = fopen(nsswitch_path, "r");
+ if (!nssfp) {
+- fprintf(shadow_logfd, "Failed opening %s: %m", nsswitch_path);
++ //fprintf(shadow_logfd, "Failed opening %s: %m", nsswitch_path);
+ atomic_store(_init_completed, true);
+ return;
+ }
+--
+2.25.1
+
diff --git a/meta/recipes-extended/shadow/shadow.inc
b/meta/recipes-extended/shadow/shadow.inc
index b3ae2b4874..5106b95571 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -26,6 +26,7 @@ SRC_URI:append:class-target = " \
SRC_URI:append:class-native = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
file://commonio.c-fix-unexpected-open-failure-in-chroot-env.patch \
+
file://0001-Drop-nsswitch.conf-message-when-not-in-place-eg.-musl.patch \
"
SRC_URI:append:class-nativesdk = " \
file://0001-Disable-use-of-syslog-for-sysroot.patch \
@@ -33,6 +34,7 @@ SRC_URI:append:class-nativesdk = " \
SRC_URI[sha256sum] =
"f262089be6a1011d50ec7849e14571b7b2e788334368f3dccb718513f17935ed"
+
# Additional Policy files for PAM
PAM_SRC_URI = "file://pam.d/chfn \
file://pam.d/chpasswd \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169882):
https://lists.openembedded.org/g/openembedded-core/message/169882
Mute This Topic: https://lists.openembedded.org/mt/93252114/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 2/3] rootfspostcommands.py: Cleanup subid backup files generated by shadow-utils
From: Andrei Gherzan When creating users, shadow-utils might create backup files for subordinate ID files (subid, subgid). Make sure we clean them up similarly to the other backup files shadow-utils creates. This is a backport from master that brings in only the cleanup of the subid backup files without the code restructure. Signed-off-by: Andrei Gherzan --- meta/lib/rootfspostcommands.py | 7 +++ 1 file changed, 7 insertions(+) diff --git a/meta/lib/rootfspostcommands.py b/meta/lib/rootfspostcommands.py index fdb9f5b850..12f66d2ce2 100644 --- a/meta/lib/rootfspostcommands.py +++ b/meta/lib/rootfspostcommands.py @@ -58,3 +58,10 @@ def sort_passwd(sysconfdir): remove_backup(filename) if os.path.exists(filename): sort_file(filename, mapping) +# Drop other known backup shadow-utils. +for filename in ( +'subgid', +'subuid', +): +filepath = os.path.join(sysconfdir, filename) +remove_backup(filepath) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169881): https://lists.openembedded.org/g/openembedded-core/message/169881 Mute This Topic: https://lists.openembedded.org/mt/93252113/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 1/3] shadow: Enable subid support
From: Andrei Gherzan
shadow utils are used when creating users at image creation time. The
useradd/usermod tools will only try to add a default configuration for
subid files if they exist.
Signed-off-by: Andrei Gherzan
---
meta/recipes-extended/shadow/shadow.inc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/recipes-extended/shadow/shadow.inc
b/meta/recipes-extended/shadow/shadow.inc
index f5fdf436f7..b3ae2b4874 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -149,6 +149,13 @@ do_install:append() {
# Handle link properly after rename, otherwise missing files would
# lead rpm failed dependencies.
ln -sf newgrp.${BPN} ${D}${bindir}/sg
+
+ # usermod requires the subuid/subgid files to be in place before being
+ # able to use the -v/-V flags otherwise it fails:
+ # usermod: /etc/subuid does not exist, you cannot use the flags -v or -V
+ install -d ${D}${sysconfdir}
+ touch ${D}${sysconfdir}/subuid
+ touch ${D}${sysconfdir}/subgid
}
PACKAGES =+ "${PN}-base"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169880):
https://lists.openembedded.org/g/openembedded-core/message/169880
Mute This Topic: https://lists.openembedded.org/mt/93252112/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][PATCHv2] connman: add PACKAGECONFIG to support iwd
Am Do, 25. Aug 2022 um 16:59:58 +0200 schrieb Quentin Schulz : From the comment " For smooth operation it would be best to start only one wireless daemon at a time." I gathered that both can be enabled at once. Correct. Connman doesn't really care if both wpa_supplicant and iwd are running. It's just that it then defaults to using wpa_supplicant. So to have a working out-of-box experience for iwd, you would either have to make them mutually exclusive, or change the Connman default configuration for iwd during installation. I made this additional configure option to try to make it more visible that a decision should be made here. Additionally, the wireless daemon could be selected in a nicer way from a bbappend or e.g. local.conf. If wpa_supplicant is preset in PACKAGECONFIG, we would always have to do a PACKAGECONFIG:remove for it. For example, if we override this option in local.conf or distro.conf, we can make this decision visible to other recipes that might depend on this setting. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169879): https://lists.openembedded.org/g/openembedded-core/message/169879 Mute This Topic: https://lists.openembedded.org/mt/93225636/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 2/2] oeqa/sdk: extend rust test to also use a build script
On Thu, 2022-08-25 at 14:03 +0200, Peter Bergin wrote: > Hi Richard, > > On 2022-08-25 10:21, Richard Purdie wrote: > > > > > I've tried locally to reproduce something. I've built and tested > > > genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the > > > target for the autobuilder. Both tests passes. The failure I see in the > > > autobuilder logs is that the build script can not be executed. On my > > > machine I have that file and it can clearly be executed: > > > > > > $ find > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/ > > > -name build-script-build > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > > > $ > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > > > $ file > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build: > > > ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically > > > linked, interpreter > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2, > > > BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux > > > 3.2.0, with debug_info, not stripped > > > > > > Found one interesting link here > > > https://github.com/rust-lang/cargo/issues/3553. Unfortunately without > > > answer. But also checked the interpreter in my build which looks correct? > > > > > > $ readelf -a > > > tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build > > > > grep interpreter > > > [Requesting program interpreter: > > > /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2] > > > > > > > > > So there are some differences between my machine and the autobuilder > > > setup that I can't get. I would need help here as I'm not that familiar > > > with the autobuilder setup. Can it still be some host dependency? I'm > > > running on Ubuntu 22.04. Is it possible to check in a autobuilder setup > > > if the file 'build-script-build' is present and possible to execute? > > After staring at this for an hour, I think the pattern is that is it > > failing on builds with: > > > > SDKMACHINE = "i686" > > > > which probably means the linker isn't linking against the libc and > > loader in the SDK properly. > > > > (i686 SDK binaries should run on x86_64 hosts since we provide our own > > loader and libc) > > Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I > was able to reproduce. I want to share some weird stuff and see if > someone can get a clue for a solution. > > Did same analyze on the build-script-build file as I did on a working one: As I suspected, the dynamic loader on binaries built using the toolchain in the SDK isn't working correctly. "/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk- linux/lib/ld-linux.so.2" is the value used at build time. This is supposed to be relocated into the SDK's install location at runtime. The question is therefore where is rust getting this value from? You can specify it to the linker at compile time along the lines of: -Wl,--dynamic-linker=/path/to/ld-linux.so.2 or it can be the default that comes from toolchain. It is important it points at the one in the SDK, not on the host system. The bit I don't understand is whether: a) the compiler in the SDK is generating the wrong loader (in which case buildtools-extended-tarball would break which it doesn't) b) rust is hardcoding some dynamic-linker option somewhere it shouldn't c) whether the toolchain is relocating paths correctly or some path isn't relocating and is being used here. I'd suggest first checking that a binary generated by nativesdk-gcc in the SDK has the right loader. If that is the case, see what compiler options are being used to create the build tool and go from there. FWIW you can see/change the interpreter with patchelf. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169878): https://lists.openembedded.org/g/openembedded-core/message/169878 Mute This Topic: https://lists.openembedded.org/mt/93200332/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][PATCHv2] connman: add PACKAGECONFIG to support iwd
Hi Ross,
On 8/25/22 14:17, Ross Burton wrote:
On 24 Aug 2022, at 13:50, Markus Volk via lists.openembedded.org
wrote:
+# For smooth operation it would be best to start only one wireless daemon at a
time.
+# If wpa_supplicant is running, connman will use it preferentially.
+# Select either wpa_supplicant or iwd
+WIRELESS_DAEMON ??= "wpa_supplicant"
PACKAGECONFIG ??= "wispr iptables client\
- ${@bb.utils.filter('DISTRO_FEATURES', '3g systemd wifi',
d)} \
+ ${@bb.utils.filter('DISTRO_FEATURES', '3g systemd', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
'bluez', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'wifi
${WIRELESS_DAEMON}', '', d)} \
"
This is over-complicating things. Why is the wifi daemon a special
configuration option? Just have wpa_supplicant in the default PACKAGECONFIG,
and people who want to use iwd can set PACKAGECONFIG.
+PACKAGECONFIG[wpa_supplicant] = ",,wpa-supplicant,wpa-supplicant"
+# iwd would be required as a runtime dependency. it is nevertheless given as a
recommendation because the recipe for it
+# is not included in oe-core.
+PACKAGECONFIG[iwd] = "--enable-iwd,--disable-iwd,,,iwd"
This definitely should be RDEPENDS.
Note that if wpa_supplicant and iwd are mutually exclusive, you can express
that in the PACKAGECONFIG:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_ref-2Dmanual_variables.html-3F-23term-2DPACKAGECONFIG=DwIFAg=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=8HjNGWSBnokVx86ZXb1HGtJWTl97isWyKhlw05xayeDV2PeizRV-8Et7M2oILR6A=SRukmgE6s_F_GQ3lRKUJZhJHBYIoHdF3lYfYPaNoS8E=
From the comment " For smooth operation it would be best to start only
one wireless daemon at a time." I gathered that both can be enabled at once.
If we had --disable-wifi in PACKAGECONFIG[iwd] or
PACKAGECONFIG[wpa_supplicant], we would be forced to have both or none
since it would be part of the PACKAGECONFIG_CONFARGS if one is disabled.
If support for both at once is not supported by connman, then the wifi
PACKAGECONFIG is unnecessary indeed.
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169877):
https://lists.openembedded.org/g/openembedded-core/message/169877
Mute This Topic: https://lists.openembedded.org/mt/93225636/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/3] ccache: Upgrade to 4.6.2
On Thu, Aug 25, 2022 at 3:02 AM Luca Ceresoli wrote: > > Hi Khem, > > On Wed, 24 Aug 2022 09:57:13 -0700 > "Khem Raj" wrote: > > > On Wed, Aug 24, 2022 at 9:52 AM Luca Ceresoli > > wrote: > > > > > > Hi Khem, > > > > > > On Tue, 23 Aug 2022 11:01:51 -0700 > > > "Khem Raj" wrote: > > > > > > > Fix build with musl > > > > > > > > Signed-off-by: Khem Raj > > > > > > AB testing with these 3 patches I got an error in test_ccache_tool. Not > > > sure these patches are guilty, but they are the only ones > > > ccache-related. > > > > > > Maybe you can have a look? > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/4037/steps/15/logs/stdio > > > > > > > drop the upgrade patch > > > > [3/3] ccache: Upgrade to 4.6.2 > > > > and see if that helps. We dont really need that for gcc 12 issue. > > My build with the first two patches + the gcc 12.2.0 upgrade succeeded. yeah thats good, I did the patches that way, recipe upgrade was optional for the gcc issue. > Thanks! > > Luca > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169876): https://lists.openembedded.org/g/openembedded-core/message/169876 Mute This Topic: https://lists.openembedded.org/mt/93210245/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: Fix crossbeam-utils for arches without atomics
crossbeam-utils tries to use the triplet to look up whether the target
supports various forms of atomics. We use TARGET_VENDOR and not "-unknown"
in the target case which means this fails and breaks platforms like mips
and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/rust/rust-source.inc| 1 +
.../rust/rust/crossbeam_atomic.patch | 50 +++
meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++
3 files changed, 54 insertions(+)
create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
diff --git a/meta/recipes-devtools/rust/rust-source.inc
b/meta/recipes-devtools/rust/rust-source.inc
index d8be2701367..ce6c983fc0b 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] =
"8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e
SRC_URI:append:class-target:pn-rust = " \
file://hardcodepaths.patch \
+file://crossbeam_atomic.patch \
file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch"
SRC_URI:append:class-nativesdk:pn-nativesdk-rust = "
file://hardcodepaths.patch"
diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
new file mode 100644
index 000..7097bb9087a
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
@@ -0,0 +1,50 @@
+crossbeam-utils is taking the target triplet and comparing it against a
+known list of platforms that have issues either with any atomics or with
+64 bit atomics. Since OE encodes TARGET_VENDOR into the rust triplet (to
+differentiate host vs. target) this means that platforms that should match,
+don't.
+
+We could make a list of platforms and pass in configuration values but
+having one list in rust and another in our recipes is likely to cause
+problems in the future. We do already have this issue in the librsvg recipe.
+Instead, switch out the value of TARGET_VENDOR for "-unknown" which
+them makes the list in no_atomics.rs work correctly.
+
+Someone with more rust knowledge could split up the triplets in no_atmoics.rs
+and compare against the architecture/processor, or replace -unknown with a glob
+to create a patch that upstream might accept.
+
+Upstream-Status: Inappropriate [OE Specific tweak but could be rewritten]
+Signed-off-by: Richard Purdie
+
+Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
+===
+--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs
rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
+@@ -29,7 +29,7 @@ use std::env;
+ include!("no_atomic.rs");
+
+ fn main() {
+-let target = match env::var("TARGET") {
++let mut target = match env::var("TARGET") {
+ Ok(target) => target,
+ Err(e) => {
+ println!(
+@@ -40,6 +40,8 @@ fn main() {
+ return;
+ }
+ };
++let vendor = env::var("TARGET_VENDOR").unwrap();
++target = target.replace(, "-unknown");
+
+ // Note that this is `no_*`, not `has_*`. This allows treating
+ // `cfg(target_has_atomic = "ptr")` as true when the build script doesn't
+Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
+===
+--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json
rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
+@@ -1 +1 @@
Re: [OE-core] [kirkstone] [PATCH] sqlite: Increase the size of loop variables in the printf() implementation to avoid harmless compiler warnings.
On Wed, Aug 24, 2022 at 9:34 PM Marta Rybczynska wrote: > > > > On Thu, Aug 25, 2022 at 9:25 AM ghassaneben wrote: >> >> From: ghassaneben >> >> Increase the size of loop variables in the printf() implementation to avoid >> integer overflow on multi-gigabyte string arguments. CVE-2022-35737. This >> bug fix refers to: CVE-2022-35737 and it's a backport of a fix added in >> sqlite 3.39.2 (2022-07-21). >> Original commit: https://www.sqlite.org/src/info/aab790a16e1bdff7. >> > > Steve, > I'm adding it to your watch list. This is a CVE fix contrary to the "harmless > warnings" one of the commit messages is telling us. Thanks! I'll update the short message to reflect this. Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169874): https://lists.openembedded.org/g/openembedded-core/message/169874 Mute This Topic: https://lists.openembedded.org/mt/93243836/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] meta/conf: move default configuration templates into meta/conf/templates/default
I've sent a separate patch for meta-yocto to poky@ list, does that help? Alex On Thu, 25 Aug 2022 at 15:37, Luca Ceresoli wrote: > > Hello Alex, > > On Wed, 24 Aug 2022 14:42:33 +0200 > "Alexander Kanavin" wrote: > > > This sets the ground for standardizing (and enforcing) the location of > > configuration templates: let's start with the default one. > > > > Signed-off-by: Alexander Kanavin > > I have been trying to apply this patch, and it applies on oe-core, but > then combo-layer fails in picking it because poky has a different > .templateconf file. I'm not sure how this should be fixed, maybe the > patch should be done against meta-yocto (which has a .templateconf > identical to the one in poky)? > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169873): https://lists.openembedded.org/g/openembedded-core/message/169873 Mute This Topic: https://lists.openembedded.org/mt/93225499/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/6] oeqa/selftest: rename git.py to intercept.py
Forgot the branch prefix, resending.
Ross
> On 25 Aug 2022, at 14:36, Ross Burton via lists.openembedded.org
> wrote:
>
> By naming this test class git.py, any attempt to import GitPython (as
> needed by oelib.buildhistory) failed.
>
> As this class exercises the intercepts, rename it to intercept.py.
>
> (From OE-Core rev: d557cbbf86767bc2ebf2beb3d70af3b3ca5e0529)
>
> Signed-off-by: Ross Burton
> Signed-off-by: Richard Purdie
> ---
> meta/lib/oeqa/selftest/cases/{git.py => intercept.py} | 0
> meta/lib/oeqa/selftest/cases/oelib/buildhistory.py| 6 +++---
> 2 files changed, 3 insertions(+), 3 deletions(-)
> rename meta/lib/oeqa/selftest/cases/{git.py => intercept.py} (100%)
>
> diff --git a/meta/lib/oeqa/selftest/cases/git.py
> b/meta/lib/oeqa/selftest/cases/intercept.py
> similarity index 100%
> rename from meta/lib/oeqa/selftest/cases/git.py
> rename to meta/lib/oeqa/selftest/cases/intercept.py
> diff --git a/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
> b/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
> index 802a91a4886..33bd6df2f3f 100644
> --- a/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
> +++ b/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
> @@ -3,6 +3,7 @@
> #
>
> import os
> +import sys
> from oeqa.selftest.case import OESelftestTestCase
> import tempfile
> import operator
> @@ -11,15 +12,14 @@ from oeqa.utils.commands import get_bb_var
> class TestBlobParsing(OESelftestTestCase):
>
> def setUp(self):
> -import time
> self.repo_path = tempfile.mkdtemp(prefix='selftest-buildhistory',
> dir=get_bb_var('TOPDIR'))
>
> try:
> from git import Repo
> self.repo = Repo.init(self.repo_path)
> -except ImportError:
> -self.skipTest('Python module GitPython is not present')
> +except ImportError as e:
> +self.skipTest('Python module GitPython is not present (%s)
> (%s)' % (e, sys.path))
>
> self.test_file = "test"
> self.var_map = {}
> --
> 2.34.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169872):
https://lists.openembedded.org/g/openembedded-core/message/169872
Mute This Topic: https://lists.openembedded.org/mt/93248157/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][kirkstone 5/6] wic/bootimg-efi: use cross objcopy when building unified kernel image
We can't rely on the host objcopy knowing how to process target binaries,
so use the cross objcopy in the sysroot instead.
Also construct the command argument-by-argument as the format expression
was getting unwieldy.
(From OE-Core rev: 0264aeedbf21e9e7a104243c11b3b57f00e38bda)
Signed-off-by: Ross Burton
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
---
scripts/lib/wic/plugins/source/bootimg-efi.py | 25 +--
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 0391aebdc84..a65a5b97804 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -326,21 +326,20 @@ class BootimgEFIPlugin(SourcePlugin):
exec_cmd(install_cmd)
staging_dir_host = get_bitbake_var("STAGING_DIR_HOST")
+target_sys = get_bitbake_var("TARGET_SYS")
#
https://www.freedesktop.org/software/systemd/man/systemd-stub.html
-objcopy_cmd = "objcopy \
---add-section .osrel=%s --change-section-vma
.osrel=0x2 \
---add-section .cmdline=%s --change-section-vma
.cmdline=0x3 \
---add-section .linux=%s --change-section-vma
.linux=0x200 \
---add-section .initrd=%s --change-section-vma
.initrd=0x300 \
-%s %s" % \
-("%s/usr/lib/os-release" % staging_dir_host,
-cmdline.name,
-"%s/%s" % (staging_kernel_dir, kernel),
-initrd.name,
-efi_stub,
-"%s/EFI/Linux/linux.efi" % hdddir)
-exec_cmd(objcopy_cmd)
+objcopy_cmd = "%s-objcopy" % target_sys
+objcopy_cmd += " --add-section .osrel=%s/usr/lib/os-release" %
staging_dir_host
+objcopy_cmd += " --change-section-vma .osrel=0x2"
+objcopy_cmd += " --add-section .cmdline=%s" % cmdline.name
+objcopy_cmd += " --change-section-vma .cmdline=0x3"
+objcopy_cmd += " --add-section .linux=%s/%s" %
(staging_kernel_dir, kernel)
+objcopy_cmd += " --change-section-vma .linux=0x200"
+objcopy_cmd += " --add-section .initrd=%s" % initrd.name
+objcopy_cmd += " --change-section-vma .initrd=0x300"
+objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub,
hdddir)
+exec_native_cmd(objcopy_cmd, native_sysroot)
else:
install_cmd = "install -m 0644 %s/%s %s/%s" % \
(staging_kernel_dir, kernel, hdddir, kernel)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169870):
https://lists.openembedded.org/g/openembedded-core/message/169870
Mute This Topic: https://lists.openembedded.org/mt/93248208/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][kirkstone 4/6] wic: add target tools to PATH when executing native commands
We might want to run a cross tool, such as objcopy, in wic. These are
in a TARGET_SYS/ subdirectory under /usr/bin, so add that directory to
the search path too.
(From OE-Core rev: c523549141e5c31edc75281f581d97867b7d251d)
Signed-off-by: Ross Burton
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
---
scripts/lib/wic/misc.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
index 3e118229960..a8aab6c524e 100644
--- a/scripts/lib/wic/misc.py
+++ b/scripts/lib/wic/misc.py
@@ -140,11 +140,12 @@ def exec_native_cmd(cmd_and_args, native_sysroot,
pseudo=""):
cmd_and_args = pseudo + cmd_and_args
hosttools_dir = get_bitbake_var("HOSTTOOLS_DIR")
+target_sys = get_bitbake_var("TARGET_SYS")
-native_paths = "%s/sbin:%s/usr/sbin:%s/usr/bin:%s/bin:%s" % \
+native_paths = "%s/sbin:%s/usr/sbin:%s/usr/bin:%s/usr/bin/%s:%s/bin:%s" % \
(native_sysroot, native_sysroot,
-native_sysroot, native_sysroot,
-hosttools_dir)
+native_sysroot, native_sysroot, target_sys,
+native_sysroot, hosttools_dir)
native_cmd_and_args = "export PATH=%s:$PATH;%s" % \
(native_paths, cmd_and_args)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169869):
https://lists.openembedded.org/g/openembedded-core/message/169869
Mute This Topic: https://lists.openembedded.org/mt/93248205/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][kirkstone 6/6] wic: depend on cross-binutils
Wic can build an unified kernel image, but this needs the cross-objcopy
from binutils.
(From OE-Core rev: 7c7a488116f49083ca42d3628ebc0870585110c3)
Signed-off-by: Ross Burton
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
---
meta/classes/image_types_wic.bbclass | 2 ++
meta/recipes-core/meta/wic-tools.bb | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index e3863c88a9a..5374d6125e1 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -84,6 +84,8 @@ do_image_wic[deptask] += "do_image_complete"
WKS_FILE_DEPENDS_DEFAULT = '${@bb.utils.contains_any("BUILD_ARCH", [ 'x86_64',
'i686' ], "syslinux-native", "",d)}'
WKS_FILE_DEPENDS_DEFAULT += "bmap-tools-native cdrtools-native
btrfs-tools-native squashfs-tools-native e2fsprogs-native"
+# Unified kernel images need objcopy
+WKS_FILE_DEPENDS_DEFAULT += "virtual/${TARGET_PREFIX}binutils"
WKS_FILE_DEPENDS_BOOTLOADERS = ""
WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux grub-efi systemd-boot
os-release"
diff --git a/meta/recipes-core/meta/wic-tools.bb
b/meta/recipes-core/meta/wic-tools.bb
index ba0916cb567..daaf3ea5768 100644
--- a/meta/recipes-core/meta/wic-tools.bb
+++ b/meta/recipes-core/meta/wic-tools.bb
@@ -6,7 +6,8 @@ DEPENDS = "\
parted-native gptfdisk-native dosfstools-native \
mtools-native bmap-tools-native grub-native cdrtools-native \
btrfs-tools-native squashfs-tools-native pseudo-native \
- e2fsprogs-native util-linux-native tar-native\
+ e2fsprogs-native util-linux-native tar-native \
+ virtual/${TARGET_PREFIX}binutils \
"
DEPENDS:append:x86 = " syslinux-native syslinux grub-efi systemd-boot"
DEPENDS:append:x86-64 = " syslinux-native syslinux grub-efi systemd-boot"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169871):
https://lists.openembedded.org/g/openembedded-core/message/169871
Mute This Topic: https://lists.openembedded.org/mt/93248209/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][kirkstone 3/6] oeqa/gotoolchain: set CGO_ENABLED=1
In cross-compiles CGO_ENABLED=1 needs to be set explicitly, as otherwise
Go refuses to use it even if CC is already set.
This fixes the selftest on setups where the host and the SDK target
don't have matching architectures.
[ YOCTO #14859 ]
(From OE-Core rev: 19be072619d39267df44f23c4c8b64f3808f6148)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/gotoolchain.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oeqa/selftest/cases/gotoolchain.py
b/meta/lib/oeqa/selftest/cases/gotoolchain.py
index 345f533379c..978898b86f1 100644
--- a/meta/lib/oeqa/selftest/cases/gotoolchain.py
+++ b/meta/lib/oeqa/selftest/cases/gotoolchain.py
@@ -51,6 +51,7 @@ class oeGoToolchainSelfTest(OESelftestTestCase):
cmd = cmd + ". %s; " % self.env_SDK
cmd = cmd + "export GOPATH=%s; " % self.go_path
cmd = cmd + "export GOFLAGS=-modcacherw; "
+cmd = cmd + "export CGO_ENABLED=1; "
cmd = cmd + "${CROSS_COMPILE}go %s" % gocmd
return runCmd(cmd).status
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169868):
https://lists.openembedded.org/g/openembedded-core/message/169868
Mute This Topic: https://lists.openembedded.org/mt/93248204/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][kirkstone 1/6] oeqa/selftest: rename git.py to intercept.py
By naming this test class git.py, any attempt to import GitPython (as
needed by oelib.buildhistory) failed.
As this class exercises the intercepts, rename it to intercept.py.
(From OE-Core rev: d557cbbf86767bc2ebf2beb3d70af3b3ca5e0529)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/{git.py => intercept.py} | 0
meta/lib/oeqa/selftest/cases/oelib/buildhistory.py| 6 +++---
2 files changed, 3 insertions(+), 3 deletions(-)
rename meta/lib/oeqa/selftest/cases/{git.py => intercept.py} (100%)
diff --git a/meta/lib/oeqa/selftest/cases/git.py
b/meta/lib/oeqa/selftest/cases/intercept.py
similarity index 100%
rename from meta/lib/oeqa/selftest/cases/git.py
rename to meta/lib/oeqa/selftest/cases/intercept.py
diff --git a/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
b/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
index 802a91a4886..33bd6df2f3f 100644
--- a/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
+++ b/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
@@ -3,6 +3,7 @@
#
import os
+import sys
from oeqa.selftest.case import OESelftestTestCase
import tempfile
import operator
@@ -11,15 +12,14 @@ from oeqa.utils.commands import get_bb_var
class TestBlobParsing(OESelftestTestCase):
def setUp(self):
-import time
self.repo_path = tempfile.mkdtemp(prefix='selftest-buildhistory',
dir=get_bb_var('TOPDIR'))
try:
from git import Repo
self.repo = Repo.init(self.repo_path)
-except ImportError:
-self.skipTest('Python module GitPython is not present')
+except ImportError as e:
+self.skipTest('Python module GitPython is not present (%s) (%s)'
% (e, sys.path))
self.test_file = "test"
self.var_map = {}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169866):
https://lists.openembedded.org/g/openembedded-core/message/169866
Mute This Topic: https://lists.openembedded.org/mt/93248202/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][kirkstone 2/6] oeqa/gotoolchain: put writable files in the Go module cache
By default 'go mod' creates read-only files, but that just complicates
things. Add -modcacherw to make the cache read/write, so it can be
cleaned up without needing to chmod.
(From OE-Core rev: 7ff30e0d9fe8527cbc2f8ca84e0300fdc84663b6)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/gotoolchain.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/gotoolchain.py
b/meta/lib/oeqa/selftest/cases/gotoolchain.py
index c809d7c9b14..345f533379c 100644
--- a/meta/lib/oeqa/selftest/cases/gotoolchain.py
+++ b/meta/lib/oeqa/selftest/cases/gotoolchain.py
@@ -43,12 +43,6 @@ class oeGoToolchainSelfTest(OESelftestTestCase):
@classmethod
def tearDownClass(cls):
-# Go creates file which are readonly
-for dirpath, dirnames, filenames in os.walk(cls.tmpdir_SDKQA):
-for filename in filenames + dirnames:
-f = os.path.join(dirpath, filename)
-if not os.path.islink(f):
-os.chmod(f, 0o775)
shutil.rmtree(cls.tmpdir_SDKQA, ignore_errors=True)
super(oeGoToolchainSelfTest, cls).tearDownClass()
@@ -56,6 +50,7 @@ class oeGoToolchainSelfTest(OESelftestTestCase):
cmd = "cd %s/src/%s/%s; " % (self.go_path, proj, name)
cmd = cmd + ". %s; " % self.env_SDK
cmd = cmd + "export GOPATH=%s; " % self.go_path
+cmd = cmd + "export GOFLAGS=-modcacherw; "
cmd = cmd + "${CROSS_COMPILE}go %s" % gocmd
return runCmd(cmd).status
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169867):
https://lists.openembedded.org/g/openembedded-core/message/169867
Mute This Topic: https://lists.openembedded.org/mt/93248203/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] meta/conf: move default configuration templates into meta/conf/templates/default
Hello Alex, On Wed, 24 Aug 2022 14:42:33 +0200 "Alexander Kanavin" wrote: > This sets the ground for standardizing (and enforcing) the location of > configuration templates: let's start with the default one. > > Signed-off-by: Alexander Kanavin I have been trying to apply this patch, and it applies on oe-core, but then combo-layer fails in picking it because poky has a different .templateconf file. I'm not sure how this should be fixed, maybe the patch should be done against meta-yocto (which has a .templateconf identical to the one in poky)? -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169865): https://lists.openembedded.org/g/openembedded-core/message/169865 Mute This Topic: https://lists.openembedded.org/mt/93225499/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 6/6] wic: depend on cross-binutils
Wic can build an unified kernel image, but this needs the cross-objcopy
from binutils.
(From OE-Core rev: 7c7a488116f49083ca42d3628ebc0870585110c3)
Signed-off-by: Ross Burton
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
---
meta/classes/image_types_wic.bbclass | 2 ++
meta/recipes-core/meta/wic-tools.bb | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index e3863c88a9a..5374d6125e1 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -84,6 +84,8 @@ do_image_wic[deptask] += "do_image_complete"
WKS_FILE_DEPENDS_DEFAULT = '${@bb.utils.contains_any("BUILD_ARCH", [ 'x86_64',
'i686' ], "syslinux-native", "",d)}'
WKS_FILE_DEPENDS_DEFAULT += "bmap-tools-native cdrtools-native
btrfs-tools-native squashfs-tools-native e2fsprogs-native"
+# Unified kernel images need objcopy
+WKS_FILE_DEPENDS_DEFAULT += "virtual/${TARGET_PREFIX}binutils"
WKS_FILE_DEPENDS_BOOTLOADERS = ""
WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux grub-efi systemd-boot
os-release"
diff --git a/meta/recipes-core/meta/wic-tools.bb
b/meta/recipes-core/meta/wic-tools.bb
index ba0916cb567..daaf3ea5768 100644
--- a/meta/recipes-core/meta/wic-tools.bb
+++ b/meta/recipes-core/meta/wic-tools.bb
@@ -6,7 +6,8 @@ DEPENDS = "\
parted-native gptfdisk-native dosfstools-native \
mtools-native bmap-tools-native grub-native cdrtools-native \
btrfs-tools-native squashfs-tools-native pseudo-native \
- e2fsprogs-native util-linux-native tar-native\
+ e2fsprogs-native util-linux-native tar-native \
+ virtual/${TARGET_PREFIX}binutils \
"
DEPENDS:append:x86 = " syslinux-native syslinux grub-efi systemd-boot"
DEPENDS:append:x86-64 = " syslinux-native syslinux grub-efi systemd-boot"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169864):
https://lists.openembedded.org/g/openembedded-core/message/169864
Mute This Topic: https://lists.openembedded.org/mt/93248165/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 5/6] wic/bootimg-efi: use cross objcopy when building unified kernel image
We can't rely on the host objcopy knowing how to process target binaries,
so use the cross objcopy in the sysroot instead.
Also construct the command argument-by-argument as the format expression
was getting unwieldy.
(From OE-Core rev: 0264aeedbf21e9e7a104243c11b3b57f00e38bda)
Signed-off-by: Ross Burton
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
---
scripts/lib/wic/plugins/source/bootimg-efi.py | 25 +--
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 0391aebdc84..a65a5b97804 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -326,21 +326,20 @@ class BootimgEFIPlugin(SourcePlugin):
exec_cmd(install_cmd)
staging_dir_host = get_bitbake_var("STAGING_DIR_HOST")
+target_sys = get_bitbake_var("TARGET_SYS")
#
https://www.freedesktop.org/software/systemd/man/systemd-stub.html
-objcopy_cmd = "objcopy \
---add-section .osrel=%s --change-section-vma
.osrel=0x2 \
---add-section .cmdline=%s --change-section-vma
.cmdline=0x3 \
---add-section .linux=%s --change-section-vma
.linux=0x200 \
---add-section .initrd=%s --change-section-vma
.initrd=0x300 \
-%s %s" % \
-("%s/usr/lib/os-release" % staging_dir_host,
-cmdline.name,
-"%s/%s" % (staging_kernel_dir, kernel),
-initrd.name,
-efi_stub,
-"%s/EFI/Linux/linux.efi" % hdddir)
-exec_cmd(objcopy_cmd)
+objcopy_cmd = "%s-objcopy" % target_sys
+objcopy_cmd += " --add-section .osrel=%s/usr/lib/os-release" %
staging_dir_host
+objcopy_cmd += " --change-section-vma .osrel=0x2"
+objcopy_cmd += " --add-section .cmdline=%s" % cmdline.name
+objcopy_cmd += " --change-section-vma .cmdline=0x3"
+objcopy_cmd += " --add-section .linux=%s/%s" %
(staging_kernel_dir, kernel)
+objcopy_cmd += " --change-section-vma .linux=0x200"
+objcopy_cmd += " --add-section .initrd=%s" % initrd.name
+objcopy_cmd += " --change-section-vma .initrd=0x300"
+objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub,
hdddir)
+exec_native_cmd(objcopy_cmd, native_sysroot)
else:
install_cmd = "install -m 0644 %s/%s %s/%s" % \
(staging_kernel_dir, kernel, hdddir, kernel)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169863):
https://lists.openembedded.org/g/openembedded-core/message/169863
Mute This Topic: https://lists.openembedded.org/mt/93248163/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/6] wic: add target tools to PATH when executing native commands
We might want to run a cross tool, such as objcopy, in wic. These are
in a TARGET_SYS/ subdirectory under /usr/bin, so add that directory to
the search path too.
(From OE-Core rev: c523549141e5c31edc75281f581d97867b7d251d)
Signed-off-by: Ross Burton
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
---
scripts/lib/wic/misc.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
index 3e118229960..a8aab6c524e 100644
--- a/scripts/lib/wic/misc.py
+++ b/scripts/lib/wic/misc.py
@@ -140,11 +140,12 @@ def exec_native_cmd(cmd_and_args, native_sysroot,
pseudo=""):
cmd_and_args = pseudo + cmd_and_args
hosttools_dir = get_bitbake_var("HOSTTOOLS_DIR")
+target_sys = get_bitbake_var("TARGET_SYS")
-native_paths = "%s/sbin:%s/usr/sbin:%s/usr/bin:%s/bin:%s" % \
+native_paths = "%s/sbin:%s/usr/sbin:%s/usr/bin:%s/usr/bin/%s:%s/bin:%s" % \
(native_sysroot, native_sysroot,
-native_sysroot, native_sysroot,
-hosttools_dir)
+native_sysroot, native_sysroot, target_sys,
+native_sysroot, hosttools_dir)
native_cmd_and_args = "export PATH=%s:$PATH;%s" % \
(native_paths, cmd_and_args)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169862):
https://lists.openembedded.org/g/openembedded-core/message/169862
Mute This Topic: https://lists.openembedded.org/mt/93248160/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/6] oeqa/gotoolchain: put writable files in the Go module cache
By default 'go mod' creates read-only files, but that just complicates
things. Add -modcacherw to make the cache read/write, so it can be
cleaned up without needing to chmod.
(From OE-Core rev: 7ff30e0d9fe8527cbc2f8ca84e0300fdc84663b6)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/gotoolchain.py | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/gotoolchain.py
b/meta/lib/oeqa/selftest/cases/gotoolchain.py
index c809d7c9b14..345f533379c 100644
--- a/meta/lib/oeqa/selftest/cases/gotoolchain.py
+++ b/meta/lib/oeqa/selftest/cases/gotoolchain.py
@@ -43,12 +43,6 @@ class oeGoToolchainSelfTest(OESelftestTestCase):
@classmethod
def tearDownClass(cls):
-# Go creates file which are readonly
-for dirpath, dirnames, filenames in os.walk(cls.tmpdir_SDKQA):
-for filename in filenames + dirnames:
-f = os.path.join(dirpath, filename)
-if not os.path.islink(f):
-os.chmod(f, 0o775)
shutil.rmtree(cls.tmpdir_SDKQA, ignore_errors=True)
super(oeGoToolchainSelfTest, cls).tearDownClass()
@@ -56,6 +50,7 @@ class oeGoToolchainSelfTest(OESelftestTestCase):
cmd = "cd %s/src/%s/%s; " % (self.go_path, proj, name)
cmd = cmd + ". %s; " % self.env_SDK
cmd = cmd + "export GOPATH=%s; " % self.go_path
+cmd = cmd + "export GOFLAGS=-modcacherw; "
cmd = cmd + "${CROSS_COMPILE}go %s" % gocmd
return runCmd(cmd).status
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169860):
https://lists.openembedded.org/g/openembedded-core/message/169860
Mute This Topic: https://lists.openembedded.org/mt/93248158/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/6] oeqa/selftest: rename git.py to intercept.py
By naming this test class git.py, any attempt to import GitPython (as
needed by oelib.buildhistory) failed.
As this class exercises the intercepts, rename it to intercept.py.
(From OE-Core rev: d557cbbf86767bc2ebf2beb3d70af3b3ca5e0529)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/{git.py => intercept.py} | 0
meta/lib/oeqa/selftest/cases/oelib/buildhistory.py| 6 +++---
2 files changed, 3 insertions(+), 3 deletions(-)
rename meta/lib/oeqa/selftest/cases/{git.py => intercept.py} (100%)
diff --git a/meta/lib/oeqa/selftest/cases/git.py
b/meta/lib/oeqa/selftest/cases/intercept.py
similarity index 100%
rename from meta/lib/oeqa/selftest/cases/git.py
rename to meta/lib/oeqa/selftest/cases/intercept.py
diff --git a/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
b/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
index 802a91a4886..33bd6df2f3f 100644
--- a/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
+++ b/meta/lib/oeqa/selftest/cases/oelib/buildhistory.py
@@ -3,6 +3,7 @@
#
import os
+import sys
from oeqa.selftest.case import OESelftestTestCase
import tempfile
import operator
@@ -11,15 +12,14 @@ from oeqa.utils.commands import get_bb_var
class TestBlobParsing(OESelftestTestCase):
def setUp(self):
-import time
self.repo_path = tempfile.mkdtemp(prefix='selftest-buildhistory',
dir=get_bb_var('TOPDIR'))
try:
from git import Repo
self.repo = Repo.init(self.repo_path)
-except ImportError:
-self.skipTest('Python module GitPython is not present')
+except ImportError as e:
+self.skipTest('Python module GitPython is not present (%s) (%s)'
% (e, sys.path))
self.test_file = "test"
self.var_map = {}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169859):
https://lists.openembedded.org/g/openembedded-core/message/169859
Mute This Topic: https://lists.openembedded.org/mt/93248157/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 3/6] oeqa/gotoolchain: set CGO_ENABLED=1
In cross-compiles CGO_ENABLED=1 needs to be set explicitly, as otherwise
Go refuses to use it even if CC is already set.
This fixes the selftest on setups where the host and the SDK target
don't have matching architectures.
[ YOCTO #14859 ]
(From OE-Core rev: 19be072619d39267df44f23c4c8b64f3808f6148)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/gotoolchain.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oeqa/selftest/cases/gotoolchain.py
b/meta/lib/oeqa/selftest/cases/gotoolchain.py
index 345f533379c..978898b86f1 100644
--- a/meta/lib/oeqa/selftest/cases/gotoolchain.py
+++ b/meta/lib/oeqa/selftest/cases/gotoolchain.py
@@ -51,6 +51,7 @@ class oeGoToolchainSelfTest(OESelftestTestCase):
cmd = cmd + ". %s; " % self.env_SDK
cmd = cmd + "export GOPATH=%s; " % self.go_path
cmd = cmd + "export GOFLAGS=-modcacherw; "
+cmd = cmd + "export CGO_ENABLED=1; "
cmd = cmd + "${CROSS_COMPILE}go %s" % gocmd
return runCmd(cmd).status
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169861):
https://lists.openembedded.org/g/openembedded-core/message/169861
Mute This Topic: https://lists.openembedded.org/mt/93248159/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] wpa_supplicant automatic installation
> On 24 Aug 2022, at 08:16, Markus Volk via lists.openembedded.org > wrote: > > Hi, > > one question regarding this part of packagegroup-base.bb: > > SUMMARY:packagegroup-base-wifi = "WiFi support" > RDEPENDS:packagegroup-base-wifi = "\ > iw \ > wireless-regdb-static \ > wpa-supplicant" > > > wpa_supplicant gets installed on every system, that has DISTRO_FEATURE wifi > set, which gets problematic, once you want to replace it. Would it be > conceivable to remove wpa_supplicant from RDEPENDS:packagegroup-base-wifi and > instead hand over the responsibility for the wireless daemon to be used to > the recipes in particular the network managers ? > > Otherwise choice would be broken. Sure. At least it should be a recommends and then iwd/wpa_supplicant can conflict with each other. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169858): https://lists.openembedded.org/g/openembedded-core/message/169858 Mute This Topic: https://lists.openembedded.org/mt/93222109/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][PATCHv2] connman: add PACKAGECONFIG to support iwd
On 24 Aug 2022, at 13:50, Markus Volk via lists.openembedded.org
wrote:
> +# For smooth operation it would be best to start only one wireless daemon at
> a time.
> +# If wpa_supplicant is running, connman will use it preferentially.
> +# Select either wpa_supplicant or iwd
> +WIRELESS_DAEMON ??= "wpa_supplicant"
> PACKAGECONFIG ??= "wispr iptables client\
> - ${@bb.utils.filter('DISTRO_FEATURES', '3g systemd wifi',
> d)} \
> + ${@bb.utils.filter('DISTRO_FEATURES', '3g systemd', d)} \
>${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth',
> 'bluez', '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'wifi
> ${WIRELESS_DAEMON}', '', d)} \
> "
This is over-complicating things. Why is the wifi daemon a special
configuration option? Just have wpa_supplicant in the default PACKAGECONFIG,
and people who want to use iwd can set PACKAGECONFIG.
> +PACKAGECONFIG[wpa_supplicant] = ",,wpa-supplicant,wpa-supplicant"
> +# iwd would be required as a runtime dependency. it is nevertheless given as
> a recommendation because the recipe for it
> +# is not included in oe-core.
> +PACKAGECONFIG[iwd] = "--enable-iwd,--disable-iwd,,,iwd"
This definitely should be RDEPENDS.
Note that if wpa_supplicant and iwd are mutually exclusive, you can express
that in the PACKAGECONFIG:
https://docs.yoctoproject.org/ref-manual/variables.html?#term-PACKAGECONFIG
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169857):
https://lists.openembedded.org/g/openembedded-core/message/169857
Mute This Topic: https://lists.openembedded.org/mt/93225636/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] connman: add PACKAGECONFIG to support iwd
On 24 Aug 2022, at 13:09, Quentin Schulz via lists.openembedded.org wrote: > > Hi all, > > On 8/24/22 11:51, Luca Ceresoli via lists.openembedded.org wrote: >> Hello Markus, >> On Wed, 24 Aug 2022 10:56:54 +0200 >> "Markus Volk" wrote: >>> Hello Luca, >>> >>> Am Mi, 24. Aug 2022 um 10:54:40 +0200 schrieb Luca Ceresoli >>> : I would think iwd should be an rdepends, not an rrecommends. Any reson for that? Or is it just an unintended extra ','? >>> >>> Only reason for this was the fact, that iwd is not in oe-core so it >>> felt wrong somehow to set it RDEPEND >> I see, that's fine, but I wonder whether this should be clarified in a >> comment. I'll be taking the patch for testing as is anyway. > > IIRC the policy is to have a default configuration working. It is fine to > have PACKAGECONFIG options with dependencies on recipes/packages not in the > same layer. > > Here, if someone builds with NO_RECOMMENDATIONS to have a minimal setup but > have iwd as WIRELESS_DAEMON, connman won't work because the package won't be > added to the image, it'll be a bit harder to debug than a build failing > because iwd recipe could not be found (especially since I also didn't notice > the additional comma). Even worse: I can enable iwd in connman without meta-oe. As there’s no DEPENDS it will build find, the recommendation won’t pull in anything, but connman doesn’t work. Enabling IWD must RDEPEND on iwd. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169856): https://lists.openembedded.org/g/openembedded-core/message/169856 Mute This Topic: https://lists.openembedded.org/mt/93208331/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 2/2] oeqa/sdk: extend rust test to also use a build script
Hi Richard, On 2022-08-25 10:21, Richard Purdie wrote: I've tried locally to reproduce something. I've built and tested genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the target for the autobuilder. Both tests passes. The failure I see in the autobuilder logs is that the build script can not be executed. On my machine I have that file and it can clearly be executed: $ find tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/ -name build-script-build tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build $ tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build $ file tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux 3.2.0, with debug_info, not stripped Found one interesting link here https://github.com/rust-lang/cargo/issues/3553. Unfortunately without answer. But also checked the interpreter in my build which looks correct? $ readelf -a tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build grep interpreter [Requesting program interpreter: /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2] So there are some differences between my machine and the autobuilder setup that I can't get. I would need help here as I'm not that familiar with the autobuilder setup. Can it still be some host dependency? I'm running on Ubuntu 22.04. Is it possible to check in a autobuilder setup if the file 'build-script-build' is present and possible to execute? After staring at this for an hour, I think the pattern is that is it failing on builds with: SDKMACHINE = "i686" which probably means the linker isn't linking against the libc and loader in the SDK properly. (i686 SDK binaries should run on x86_64 hosts since we provide our own loader and libc) Thanks a lot for the reproducer. You are correct, with SDKMACHINE i686 I was able to reproduce. I want to share some weird stuff and see if someone can get a clue for a solution. Did same analyze on the build-script-build file as I did on a working one: $ /storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build -bash: /storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build: No such file or directory $ file /storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build /storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-linux/lib/ld-linux.so.2, BuildID[sha1]=4c32d67e8597f30ce774e2bb32ea5170b9878957, for GNU/Linux 3.2.0, with debug_info, not stripped $ ldd /storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build linux-gate.so.1 (0xf7f62000) libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf7ecd000) libc.so.6 => /lib32/libc.so.6 (0xf7c9c000) /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-linux/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xf7f64000) $ readelf -a /storage/yocto/esp5-platform/build/qemuarm64/tmp/work/qemuarm64-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-2c1c69e3bd7e958d/build-script-build | grep interpreter [Requesting program interpreter: /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-pokysdk-linux/lib/ld-linux.so.2] The interpreter is wrong and pointing to a non existing file. It has '/usr/local/oe-sdk-hardcoded-buildpath' in its path which seems really bad and is equal to SDKPATH variable. Best regards, /Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all
[OE-core] [dunfell][PATCH] golang: Fix security issue in go
Source: https://github.com/golang/go
MR: 120622, 120625
Type: Security Fix
Disposition: Backport from
https://github.com/golang/go/commit/76f8b7304d1f7c25834e2a0cc9e88c55276c47df &&
https://github.com/golang/go/commit/2678d0c957193dceef336c969a9da74dd716a827
ChangeID: aabb29a6dd6a89842f451c95af228aaf66e58bb5
Description:
Fixed CVE:
1. CVE-2022-30632
2. CVE-2022-30633
Signed-off-by: Hitendra Prajapati
---
meta/recipes-devtools/go/go-1.14.inc | 2 +
.../go/go-1.14/CVE-2022-30632.patch | 71 ++
.../go/go-1.14/CVE-2022-30633.patch | 131 ++
3 files changed, 204 insertions(+)
create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-30632.patch
create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-30633.patch
diff --git a/meta/recipes-devtools/go/go-1.14.inc
b/meta/recipes-devtools/go/go-1.14.inc
index 6089fd501d..84babc38cb 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -27,6 +27,8 @@ SRC_URI += "\
file://CVE-2021-31525.patch \
file://CVE-2022-30629.patch \
file://CVE-2022-30631.patch \
+file://CVE-2022-30632.patch \
+file://CVE-2022-30633.patch \
"
SRC_URI_append_libc-musl = "
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-30632.patch
b/meta/recipes-devtools/go/go-1.14/CVE-2022-30632.patch
new file mode 100644
index 00..c54ef56a0e
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-30632.patch
@@ -0,0 +1,71 @@
+From 35d1dfe9746029aea9027b405c7d41ffd2f8 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Thu, 25 Aug 2022 13:12:40 +0530
+Subject: [PATCH] CVE-2022-30632
+
+Upstream-Status: Backport
[https://github.com/golang/go/commit/76f8b7304d1f7c25834e2a0cc9e88c55276c47df]
+CVE: CVE-2022-30632
+Signed-off-by: Hitendra Prajapati
+---
+ src/path/filepath/match.go | 16 +++-
+ src/path/filepath/match_test.go | 10 ++
+ 2 files changed, 25 insertions(+), 1 deletion(-)
+
+diff --git a/src/path/filepath/match.go b/src/path/filepath/match.go
+index 46badb5..ba68daa 100644
+--- a/src/path/filepath/match.go
b/src/path/filepath/match.go
+@@ -232,6 +232,20 @@ func getEsc(chunk string) (r rune, nchunk string, err
error) {
+ // The only possible returned error is ErrBadPattern, when pattern
+ // is malformed.
+ func Glob(pattern string) (matches []string, err error) {
++ return globWithLimit(pattern, 0)
++}
++
++func globWithLimit(pattern string, depth int) (matches []string, err error) {
++ // This limit is used prevent stack exhaustion issues. See
CVE-2022-30632.
++ const pathSeparatorsLimit = 1
++ if depth == pathSeparatorsLimit {
++ return nil, ErrBadPattern
++ }
++
++ // Check pattern is well-formed.
++ if _, err := Match(pattern, ""); err != nil {
++ return nil, err
++ }
+ if !hasMeta(pattern) {
+ if _, err = os.Lstat(pattern); err != nil {
+ return nil, nil
+@@ -257,7 +271,7 @@ func Glob(pattern string) (matches []string, err error) {
+ }
+
+ var m []string
+- m, err = Glob(dir)
++ m, err = globWithLimit(dir, depth+1)
+ if err != nil {
+ return
+ }
+diff --git a/src/path/filepath/match_test.go b/src/path/filepath/match_test.go
+index b865762..c37c812 100644
+--- a/src/path/filepath/match_test.go
b/src/path/filepath/match_test.go
+@@ -154,6 +154,16 @@ func TestGlob(t *testing.T) {
+ }
+ }
+
++func TestCVE202230632(t *testing.T) {
++ // Prior to CVE-2022-30632, this would cause a stack exhaustion given a
++ // large number of separators (more than 4,000,000). There is now a
limit
++ // of 10,000.
++ _, err := Glob("/*" + strings.Repeat("/", 10001))
++ if err != ErrBadPattern {
++ t.Fatalf("Glob returned err=%v, want ErrBadPattern", err)
++ }
++}
++
+ func TestGlobError(t *testing.T) {
+ _, err := Glob("[]")
+ if err == nil {
+--
+2.25.1
+
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-30633.patch
b/meta/recipes-devtools/go/go-1.14/CVE-2022-30633.patch
new file mode 100644
index 00..c16cb5f50c
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-30633.patch
@@ -0,0 +1,131 @@
+From ab6e2ffdcab0501bcc2de4b196c1c18ae2301d4b Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Thu, 25 Aug 2022 13:29:55 +0530
+Subject: [PATCH] CVE-2022-30633
+
+Upstream-Status: Backport
[https://github.com/golang/go/commit/2678d0c957193dceef336c969a9da74dd716a827]
+CVE: CVE-2022-30633
+Signed-off-by: Hitendra Prajapati
+---
+ src/encoding/xml/read.go | 27 +++
+ src/encoding/xml/read_test.go | 14 ++
+ 2 files changed, 33 insertions(+), 8 deletions(-)
+
+diff --git a/src/encoding/xml/read.go b/src/encoding/xml/read.go
+index 10a60ee..4ffed80 100644
[OE-core] [PATCH] oeqa/selftest: add test for debuginfod
Add a new selftest to exercise the debuginfod support, by starting a
debuginfod on DEPLOY_DIR and verifying that an image can fetch the
symbols for a binary.
Signed-off-by: Ross Burton
---
meta/lib/oeqa/selftest/cases/debuginfod.py | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/debuginfod.py
diff --git a/meta/lib/oeqa/selftest/cases/debuginfod.py
b/meta/lib/oeqa/selftest/cases/debuginfod.py
new file mode 100644
index 000..01359ec6499
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/debuginfod.py
@@ -0,0 +1,44 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+import os
+import socketserver
+import subprocess
+
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake, get_bb_var, runqemu
+
+class Debuginfod(OESelftestTestCase):
+def test_debuginfod(self):
+self.write_config("""
+DISTRO_FEATURES:append = " debuginfod"
+CORE_IMAGE_EXTRA_INSTALL += "elfutils"
+""")
+bitbake("core-image-minimal elfutils-native:do_addto_recipe_sysroot")
+
+native_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", "elfutils-native")
+cmd = [os.path.join(native_sysroot, "usr", "bin", "debuginfod"),
"--verbose", get_bb_var("DEPLOY_DIR")]
+for format in get_bb_var("PACKAGE_CLASSES").split():
+if format == "package_deb":
+cmd.append("--scan-deb-dir")
+elif format == "package_ipk":
+cmd.append("--scan-deb-dir")
+elif format == "package_rpm":
+cmd.append("--scan-rpm-dir")
+# Find a free port
+with socketserver.TCPServer(("localhost", 0), None) as s:
+port = s.server_address[1]
+cmd.append("--port=%d" % port)
+
+try:
+debuginfod = subprocess.Popen(cmd)
+
+with runqemu("core-image-minimal", runqemuparams="nographic") as
qemu:
+cmd = "DEBUGINFOD_URLS=http://%s:%d/ debuginfod-find debuginfo
/usr/bin/debuginfod" % (qemu.server_ip, port)
+status, output = qemu.run_serial(cmd)
+# This should be more comprehensive
+self.assertIn("/.cache/debuginfod_client/", output)
+finally:
+debuginfod.kill()
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169853):
https://lists.openembedded.org/g/openembedded-core/message/169853
Mute This Topic: https://lists.openembedded.org/mt/93246284/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] rust: Fix crossbeam-utils for arches without atomics
On Thu, 2022-08-25 at 13:04 +0200, Alexander Kanavin wrote: > On Thu, 25 Aug 2022 at 12:59, Richard Purdie > wrote: > > The usptreamable version of the patch would probably be something which > > splits the target names in no_atomics up into components and matched on > > subsections of it rather than the whole string. My rust isn't really up > > to doing that though. > > > > I didn't really want us to maintain a separate list of targets which > > have atomics issues given it and the list in no_atomics would get out > > of sync very easily too. > > But then the same patch needs to be applied to (and maintained > separately in) librsvg - and everything else that includes a copy of > crossbeam. Perhaps it's worth to at least make the above suggestion > about making it upstreamable in the patch commit message? Yes, I can improve the patch header. I do understand the patch isn't ideal. The alternatives are: * we take my patch * we break powerpc, mips, armv5, riscv32 and others * we drop the rust upgrades (the latent problem still exists) * we rewrite the patch For me to rewrite the patch, I'll need to learn more rust. I'm sure I can do that but it will take time and that time is time I can't use for other things. I'm hoping that by explaining the issue and documenting it, *someone* would step up and work out the upstreamable patch. This hasn't worked well for the rust recipes so far as I've had to do a lot of work to get them more into shape. I'm hoping the problem was just the shear scale and now issues are in easier smaller pieces others can/will help. It will certainly be time before someone else can schedule that in, we don't have anyone who can do it now. I will say that I'm really really tired. I have a ton of autobuilder failures and in order to resolve them I'm rewriting patches many times over, first to get them to work, then taking review feedback and people complaining they're not perfect or don't fix other issues. I have a pile of other problems like this. I appreciate the desire not to have patches, particularly when they're as painful as the rust ones are. I appreciate the patch can be improved and should go upstream. I was hoping to take some time off tomorrow but it looks like I have other things to do (in reality probably on the weekend, I need to rework the llvm patches too and both sets take hours in rebuild time even to test). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169852): https://lists.openembedded.org/g/openembedded-core/message/169852 Mute This Topic: https://lists.openembedded.org/mt/93245408/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] rust: Fix crossbeam-utils for arches without atomics
On Thu, 25 Aug 2022 at 12:59, Richard Purdie wrote: > The usptreamable version of the patch would probably be something which > splits the target names in no_atomics up into components and matched on > subsections of it rather than the whole string. My rust isn't really up > to doing that though. > > I didn't really want us to maintain a separate list of targets which > have atomics issues given it and the list in no_atomics would get out > of sync very easily too. But then the same patch needs to be applied to (and maintained separately in) librsvg - and everything else that includes a copy of crossbeam. Perhaps it's worth to at least make the above suggestion about making it upstreamable in the patch commit message? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169851): https://lists.openembedded.org/g/openembedded-core/message/169851 Mute This Topic: https://lists.openembedded.org/mt/93245408/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] rust: Fix crossbeam-utils for arches without atomics
On Thu, 2022-08-25 at 12:52 +0200, Alexander Kanavin wrote: > This will complicate version updates unfortunately, as updating > .cargo-checksum.json is a pain :( > Can we try to arrive at something upstreamable? The usptreamable version of the patch would probably be something which splits the target names in no_atomics up into components and matched on subsections of it rather than the whole string. My rust isn't really up to doing that though. I didn't really want us to maintain a separate list of targets which have atomics issues given it and the list in no_atomics would get out of sync very easily too. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169850): https://lists.openembedded.org/g/openembedded-core/message/169850 Mute This Topic: https://lists.openembedded.org/mt/93245408/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] rust: Fix crossbeam-utils for arches without atomics
On Thu, 2022-08-25 at 12:53 +0200, Alexander Kanavin wrote: > What would be much preferred is an explicit switch to disable atomics > on the platforms where we know they don't work. There is a list of such platforms in no_atomics.rs. This patch means we don't have to add the switch for every platform by fixing the detection code. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169849): https://lists.openembedded.org/g/openembedded-core/message/169849 Mute This Topic: https://lists.openembedded.org/mt/93245408/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] rust: Fix crossbeam-utils for arches without atomics
What would be much preferred is an explicit switch to disable atomics
on the platforms where we know they don't work.
Alex
On Thu, 25 Aug 2022 at 12:52, Alexander Kanavin wrote:
>
> This will complicate version updates unfortunately, as updating
> .cargo-checksum.json is a pain :(
> Can we try to arrive at something upstreamable?
>
> Alex
>
> On Thu, 25 Aug 2022 at 12:49, Richard Purdie
> wrote:
> >
> > crossbeam-utils tries to use the triplet to look up whether the target
> > supports various forms of atomics. We use TARGET_VENDOR and not "-unknown"
> > in the target case which means this fails and breaks platforms like mips
> > and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case.
> >
> > Signed-off-by: Richard Purdie
> > ---
> > meta/recipes-devtools/rust/rust-source.inc| 1 +
> > .../rust/rust/crossbeam_atomic.patch | 33 +++
> > meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++
> > 3 files changed, 37 insertions(+)
> > create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> >
> > diff --git a/meta/recipes-devtools/rust/rust-source.inc
> > b/meta/recipes-devtools/rust/rust-source.inc
> > index d8be2701367..ce6c983fc0b 100644
> > --- a/meta/recipes-devtools/rust/rust-source.inc
> > +++ b/meta/recipes-devtools/rust/rust-source.inc
> > @@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] =
> > "8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e
> >
> > SRC_URI:append:class-target:pn-rust = " \
> > file://hardcodepaths.patch \
> > +file://crossbeam_atomic.patch \
> > file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch"
> > SRC_URI:append:class-nativesdk:pn-nativesdk-rust = "
> > file://hardcodepaths.patch"
> >
> > diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> > b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> > new file mode 100644
> > index 000..64c73810a89
> > --- /dev/null
> > +++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> > @@ -0,0 +1,33 @@
> > +Upstream-Status: Inappropriate [OE Specific tweak]
> > +
> > +Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
> > +===
> > +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs
> > rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
> > +@@ -29,7 +29,7 @@ use std::env;
> > + include!("no_atomic.rs");
> > +
> > + fn main() {
> > +-let target = match env::var("TARGET") {
> > ++let mut target = match env::var("TARGET") {
> > + Ok(target) => target,
> > + Err(e) => {
> > + println!(
> > +@@ -40,6 +40,8 @@ fn main() {
> > + return;
> > + }
> > + };
> > ++let vendor = env::var("TARGET_VENDOR").unwrap();
> > ++target = target.replace(, "-unknown");
> > +
> > + // Note that this is `no_*`, not `has_*`. This allows treating
> > + // `cfg(target_has_atomic = "ptr")` as true when the build script
> > doesn't
> > +Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
> > +===
> > +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json
> > rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
> > +@@ -1 +1 @@
> >
Re: [OE-core] [PATCH 1/3] rust: Fix crossbeam-utils for arches without atomics
This will complicate version updates unfortunately, as updating
.cargo-checksum.json is a pain :(
Can we try to arrive at something upstreamable?
Alex
On Thu, 25 Aug 2022 at 12:49, Richard Purdie
wrote:
>
> crossbeam-utils tries to use the triplet to look up whether the target
> supports various forms of atomics. We use TARGET_VENDOR and not "-unknown"
> in the target case which means this fails and breaks platforms like mips
> and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case.
>
> Signed-off-by: Richard Purdie
> ---
> meta/recipes-devtools/rust/rust-source.inc| 1 +
> .../rust/rust/crossbeam_atomic.patch | 33 +++
> meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++
> 3 files changed, 37 insertions(+)
> create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
>
> diff --git a/meta/recipes-devtools/rust/rust-source.inc
> b/meta/recipes-devtools/rust/rust-source.inc
> index d8be2701367..ce6c983fc0b 100644
> --- a/meta/recipes-devtools/rust/rust-source.inc
> +++ b/meta/recipes-devtools/rust/rust-source.inc
> @@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] =
> "8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e
>
> SRC_URI:append:class-target:pn-rust = " \
> file://hardcodepaths.patch \
> +file://crossbeam_atomic.patch \
> file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch"
> SRC_URI:append:class-nativesdk:pn-nativesdk-rust = "
> file://hardcodepaths.patch"
>
> diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> new file mode 100644
> index 000..64c73810a89
> --- /dev/null
> +++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
> @@ -0,0 +1,33 @@
> +Upstream-Status: Inappropriate [OE Specific tweak]
> +
> +Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
> +===
> +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs
> rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
> +@@ -29,7 +29,7 @@ use std::env;
> + include!("no_atomic.rs");
> +
> + fn main() {
> +-let target = match env::var("TARGET") {
> ++let mut target = match env::var("TARGET") {
> + Ok(target) => target,
> + Err(e) => {
> + println!(
> +@@ -40,6 +40,8 @@ fn main() {
> + return;
> + }
> + };
> ++let vendor = env::var("TARGET_VENDOR").unwrap();
> ++target = target.replace(, "-unknown");
> +
> + // Note that this is `no_*`, not `has_*`. This allows treating
> + // `cfg(target_has_atomic = "ptr")` as true when the build script
> doesn't
> +Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
> +===
> +--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json
> rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
> +@@ -1 +1 @@
>
[OE-core] [PATCH 2/3] rust-target-config: Drop has-elf-tls option
This option doesn't seem to exist any more and causes lots of warnings.
Remove it.
Signed-off-by: Richard Purdie
---
meta/classes-recipe/rust-target-config.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes-recipe/rust-target-config.bbclass
b/meta/classes-recipe/rust-target-config.bbclass
index 34050864023..e30eaa1da30 100644
--- a/meta/classes-recipe/rust-target-config.bbclass
+++ b/meta/classes-recipe/rust-target-config.bbclass
@@ -362,7 +362,6 @@ def rust_gen_target(d, thing, wd, arch):
tspec['linker-is-gnu'] = True
tspec['linker-flavor'] = "gcc"
tspec['has-rpath'] = True
-tspec['has-elf-tls'] = True
tspec['position-independent-executables'] = True
tspec['panic-strategy'] = d.getVar("RUST_PANIC_STRATEGY")
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169845):
https://lists.openembedded.org/g/openembedded-core/message/169845
Mute This Topic: https://lists.openembedded.org/mt/93245409/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/3] rust: Fix crossbeam-utils for arches without atomics
crossbeam-utils tries to use the triplet to look up whether the target
supports various forms of atomics. We use TARGET_VENDOR and not "-unknown"
in the target case which means this fails and breaks platforms like mips
and powerpc 32 bit. Add a patch to handle TARGET_VENDOR in this case.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/rust/rust-source.inc| 1 +
.../rust/rust/crossbeam_atomic.patch | 33 +++
meta/recipes-devtools/rust/rust_1.63.0.bb | 3 ++
3 files changed, 37 insertions(+)
create mode 100644 meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
diff --git a/meta/recipes-devtools/rust/rust-source.inc
b/meta/recipes-devtools/rust/rust-source.inc
index d8be2701367..ce6c983fc0b 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -3,6 +3,7 @@ SRC_URI[rust.sha256sum] =
"8f44af6dc44cc4146634a4dd5e4cc5470b3052a2337019b870c0e
SRC_URI:append:class-target:pn-rust = " \
file://hardcodepaths.patch \
+file://crossbeam_atomic.patch \
file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch"
SRC_URI:append:class-nativesdk:pn-nativesdk-rust = "
file://hardcodepaths.patch"
diff --git a/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
new file mode 100644
index 000..64c73810a89
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust/crossbeam_atomic.patch
@@ -0,0 +1,33 @@
+Upstream-Status: Inappropriate [OE Specific tweak]
+
+Index: rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
+===
+--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/build.rs
rustc-1.63.0-src/vendor/crossbeam-utils/build.rs
+@@ -29,7 +29,7 @@ use std::env;
+ include!("no_atomic.rs");
+
+ fn main() {
+-let target = match env::var("TARGET") {
++let mut target = match env::var("TARGET") {
+ Ok(target) => target,
+ Err(e) => {
+ println!(
+@@ -40,6 +40,8 @@ fn main() {
+ return;
+ }
+ };
++let vendor = env::var("TARGET_VENDOR").unwrap();
++target = target.replace(, "-unknown");
+
+ // Note that this is `no_*`, not `has_*`. This allows treating
+ // `cfg(target_has_atomic = "ptr")` as true when the build script doesn't
+Index: rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
+===
+--- rustc-1.63.0-src.orig/vendor/crossbeam-utils/.cargo-checksum.json
rustc-1.63.0-src/vendor/crossbeam-utils/.cargo-checksum.json
+@@ -1 +1 @@
[OE-core] [PATCH 3/3] rust-target-config: Fix qemuppc target cpu option
We see a lot of warnings about incorrect processor types on qemuppc, drowning out anything else. Fix the option. Signed-off-by: Richard Purdie --- meta/classes-recipe/rust-target-config.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes-recipe/rust-target-config.bbclass b/meta/classes-recipe/rust-target-config.bbclass index e30eaa1da30..259cba7bbd0 100644 --- a/meta/classes-recipe/rust-target-config.bbclass +++ b/meta/classes-recipe/rust-target-config.bbclass @@ -272,7 +272,7 @@ def llvm_cpu(d): trans['x86-64'] = "x86-64" trans['i686'] = "i686" trans['i586'] = "i586" -trans['powerpc'] = "powerpc" +trans['powerpc'] = "7400" trans['mips64'] = "mips64" trans['mips64el'] = "mips64" trans['riscv64'] = "generic-rv64" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169846): https://lists.openembedded.org/g/openembedded-core/message/169846 Mute This Topic: https://lists.openembedded.org/mt/93245410/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.19.rc1)
Hi Everyone, QA for yocto-3.1.19.rc1 is completed. This is the full report for this release: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Jay > -Original Message- > From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User > Sent: Tuesday, 23 August, 2022 5:59 AM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [qa-build-notification] QA notification for completed autobuilder > build (yocto-3.1.19.rc1) > > > A build flagged for QA (yocto-3.1.19.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.19.rc1 > > > Build hash information: > > bitbake: 17be38290d1e971cd89785e6bf44caef0a6416f8 > meta-agl: 8ce71214c1935c2160d139140972f328afacabee > meta-arm: 69547052727a461f33967e64630aa03b34a7eadd > meta-aws: bc38cc397e98c6d6d8d4b701de5944f72d169108 > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > meta-intel: 8ed6f20cfb116e88e573ee6a08637aa5ac12e1c5 > meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 > meta-openembedded: f22bf6efaae61a8fd9272be64e7d75223c58922e > meta-virtualization: a63a54df3170fed387f810f23cdc2f483ad587df > oecore: a3cba15142e98177119ef36c09f553d09acf35ef > poky: 4aad5914efe9789755789856882aac53de6c4ed3 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169843): https://lists.openembedded.org/g/openembedded-core/message/169843 Mute This Topic: https://lists.openembedded.org/mt/93196816/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: conditionally copy tools like rustfmt
On Thu, 25 Aug 2022 at 11:46, Richard Purdie wrote: > Digging further crossbeam-utils has a no_atomics.rs file listing all > the triplets that can't use atomic or have limited 64 bit ones. > > Sadly those triplets don't match the ones were using as we have > TARGET_VENDOR in ours, for reasons. That will be why it breaks. Not sure if this helps, but librsvg deals with it thusly: RUSTFLAGS:append:mips = " --cfg crossbeam_no_atomic_64" RUSTFLAGS:append:mipsel = " --cfg crossbeam_no_atomic_64" RUSTFLAGS:append:powerpc = " --cfg crossbeam_no_atomic_64" RUSTFLAGS:append:riscv32 = " --cfg crossbeam_no_atomic_64" (it's perhaps worth investigating how this flag is used there) Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169842): https://lists.openembedded.org/g/openembedded-core/message/169842 Mute This Topic: https://lists.openembedded.org/mt/93137855/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/3] ccache: Upgrade to 4.6.2
Hi Khem, On Wed, 24 Aug 2022 09:57:13 -0700 "Khem Raj" wrote: > On Wed, Aug 24, 2022 at 9:52 AM Luca Ceresoli > wrote: > > > > Hi Khem, > > > > On Tue, 23 Aug 2022 11:01:51 -0700 > > "Khem Raj" wrote: > > > > > Fix build with musl > > > > > > Signed-off-by: Khem Raj > > > > AB testing with these 3 patches I got an error in test_ccache_tool. Not > > sure these patches are guilty, but they are the only ones > > ccache-related. > > > > Maybe you can have a look? > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/4037/steps/15/logs/stdio > > > > drop the upgrade patch > > [3/3] ccache: Upgrade to 4.6.2 > > and see if that helps. We dont really need that for gcc 12 issue. My build with the first two patches + the gcc 12.2.0 upgrade succeeded. Thanks! Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169841): https://lists.openembedded.org/g/openembedded-core/message/169841 Mute This Topic: https://lists.openembedded.org/mt/93210245/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: conditionally copy tools like rustfmt
On Fri, 2022-08-19 at 19:29 -0700, Randy MacLeod wrote:
> For qemuppc/mips, rustfmt isn't being built so check
> that it and related tools exist before copying them.
> qemuppc/mips are not well-supported in the Rust world
> but will work to get the build to fixed later.
>
> Signed-off-by: Randy MacLeod
> ---
> meta/recipes-devtools/rust/rust_1.63.0.bb | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-devtools/rust/rust_1.63.0.bb
> b/meta/recipes-devtools/rust/rust_1.63.0.bb
> index 3081cd5ef3..050f398794 100644
> --- a/meta/recipes-devtools/rust/rust_1.63.0.bb
> +++ b/meta/recipes-devtools/rust/rust_1.63.0.bb
> @@ -43,8 +43,10 @@ rust_do_install:class-nativesdk() {
>
> install -d ${D}${bindir}
> for i in cargo-clippy clippy-driver rustfmt; do
> -cp build/${RUST_BUILD_SYS}/stage2-tools/${RUST_HOST_SYS}/release/$i
> ${D}${bindir}
> -chrpath -r "\$ORIGIN/../lib" ${D}${bindir}/$i
> +if [ -e
> build/${RUST_BUILD_SYS}/stage2-tools/${RUST_HOST_SYS}/release/$i ]; then
> +cp
> build/${RUST_BUILD_SYS}/stage2-tools/${RUST_HOST_SYS}/release/$i ${D}${bindir}
> +chrpath -r "\$ORIGIN/../lib" ${D}${bindir}/$i
> +fi
> done
>
> chown root:root ${D}/ -R
> @@ -60,8 +62,10 @@ rust_do_install:class-target() {
>
> install -d ${D}${bindir}
> for i in cargo-clippy clippy-driver rustfmt; do
> -cp build/${RUST_BUILD_SYS}/stage2-tools/${RUST_HOST_SYS}/release/$i
> ${D}${bindir}
> -chrpath -r "\$ORIGIN/../lib" ${D}${bindir}/$i
> +if [ -e
> build/${RUST_BUILD_SYS}/stage2-tools/${RUST_HOST_SYS}/release/$i ]; then
> +cp
> build/${RUST_BUILD_SYS}/stage2-tools/${RUST_HOST_SYS}/release/$i ${D}${bindir}
> +chrpath -r "\$ORIGIN/../lib" ${D}${bindir}/$i
> +fi
> done
>
> chown root:root ${D}/ -R
I did look into this a bit. The compile logs for ppc are full of
horrible warnings and I have patches to clean that up. Once that is
done, it comes down to crossbeam-utils trying to use AtomicI64 which
doesn't exist on mips or powerpc 32 bit.
https://github.com/tikv/rust-prometheus/issues/315
has some interesting info.
error[E0412]: cannot find type `AtomicU64` in module `core::sync::atomic`
-->
/usr/src/debug/rust/1.63.0-r0/rustc-1.63.0-src/vendor/crossbeam-utils/src/atomic/consume.rs:78:14
|
78 | impl_atomic!(AtomicU64, u64);
|^ help: a struct with a similar name exists:
`AtomicU16`
error[E0412]: cannot find type `AtomicI64` in module `core::sync::atomic`
Digging further crossbeam-utils has a no_atomics.rs file listing all
the triplets that can't use atomic or have limited 64 bit ones.
Sadly those triplets don't match the ones were using as we have
TARGET_VENDOR in ours, for reasons. That will be why it breaks.
I'm trying a patch which changes TARGET_VENDOR -> "-unknown" but I've
never written rust code and it takes an age to cycle through so we'll
see...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169840):
https://lists.openembedded.org/g/openembedded-core/message/169840
Mute This Topic: https://lists.openembedded.org/mt/93137855/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 2/2] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid
On Thu, 25 Aug 2022 at 09:19, Peter Kjellerstedt wrote: > > > We are trying to move towards standardizing build configuration > > management. One step towards that goal is that config templates must > > live in meta-some-layer/conf/templates, and aren't scattered around, > > or generated on the fly. This rule only makes sense if there is some > > way to enforce it, which is what this change does. > > Well, we gave up on the static templates almost immediately after we > started using Yocto when we realized that they did not fit into our > idea of being able to mix layers in different combinations in different > builds. We rely on repo fetching the layers that are supposed to be part > of the build, and then we generate a bblayers.conf.sample that matches > the fetched layers. The static templates is only a starting point. The next step would be to support prefabricated 'configuration fragments' stored inside layers that can be dynamically added/removed into local.conf and/or a distro definition, so ideas for the design and UI would be welcome. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169839): https://lists.openembedded.org/g/openembedded-core/message/169839 Mute This Topic: https://lists.openembedded.org/mt/93225500/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 2/2] oeqa/sdk: extend rust test to also use a build script
Hi Peter,
On Thu, 2022-08-25 at 09:17 +0200, Peter Bergin wrote:
> On 2022-08-24 10:52, Richard Purdie wrote:
> > On Tue, 2022-08-23 at 10:56 +0200, Peter Bergin wrote:
> > > The test for rust in the SDK is extended with the simplest
> > > possible build script. This will make use of the host toolchain
> > > for building build.rs before building the rust package for target.
> > >
> > > Signed-off-by: Peter Bergin
> > > ---
> > > meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++
> > > 1 file changed, 3 insertions(+)
> > > create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > >
> > > diff --git a/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > > b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > > new file mode 100644
> > > index 000..b1a533d5dfa
> > > --- /dev/null
> > > +++ b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
> > > @@ -0,0 +1,3 @@
> > > +/* This is the simplest build script just to invoke host compiler
> > > + in the build process. */
> > > +fn main() {}
> > This seemed to break everywhere :(
> Not good. :-|
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5773/steps/13/logs/stdio
> >
> > and many others.
>
> I've tried locally to reproduce something. I've built and tested
> genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the
> target for the autobuilder. Both tests passes. The failure I see in the
> autobuilder logs is that the build script can not be executed. On my
> machine I have that file and it can clearly be executed:
>
> $ find
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
>
> -name build-script-build
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>
>
> $
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>
>
> $ file
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>
>
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
>
> ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter
> /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
>
> BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux
> 3.2.0, with debug_info, not stripped
>
> Found one interesting link here
> https://github.com/rust-lang/cargo/issues/3553. Unfortunately without
> answer. But also checked the interpreter in my build which looks correct?
>
> $ readelf -a
> tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
>
> > grep interpreter
> [Requesting program interpreter:
> /storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
>
>
>
> So there are some differences between my machine and the autobuilder
> setup that I can't get. I would need help here as I'm not that familiar
> with the autobuilder setup. Can it still be some host dependency? I'm
> running on Ubuntu 22.04. Is it possible to check in a autobuilder setup
> if the file 'build-script-build' is present and possible to execute?
After staring at this for an hour, I think the pattern is that is it
failing on builds with:
SDKMACHINE = "i686"
which probably means the linker isn't linking against the libc and
loader in the SDK properly.
(i686 SDK binaries should run on x86_64 hosts since we provide our own
loader and libc)
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169838):
https://lists.openembedded.org/g/openembedded-core/message/169838
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [kirkstone] [PATCH] sqlite: Increase the size of loop variables in the printf() implementation to avoid harmless compiler warnings.
On Thu, Aug 25, 2022 at 9:25 AM ghassaneben wrote: > From: ghassaneben > > Increase the size of loop variables in the printf() implementation to > avoid integer overflow on multi-gigabyte string arguments. CVE-2022-35737. > This bug fix refers to: CVE-2022-35737 and it's a backport of a fix added > in sqlite 3.39.2 (2022-07-21). > Original commit: https://www.sqlite.org/src/info/aab790a16e1bdff7. > > Steve, I'm adding it to your watch list. This is a CVE fix contrary to the "harmless warnings" one of the commit messages is telling us. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169837): https://lists.openembedded.org/g/openembedded-core/message/169837 Mute This Topic: https://lists.openembedded.org/mt/93243836/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 1/2] zlib: split SRC_URI into inc file
On 08/08/2022 12.20, Sean Nyekjaer wrote:
On Mon, Jul 18, 2022 at 04:12:25PM +, Ross Burton wrote:
This still seems overkill. You can build minizip from inside the zlib recipe
by fixing the minizip Makefile (fix posted to
https://github.com/madler/zlib/pull/681) and then adding one line to do_compile:
oe_runmake -C contrib/minizip CC="${CC}" CFLAGS="${CFLAGS}"
LDFLAGS="${LDFLAGS}"
A corresponding manual do_install too, obviously.
Ross
Hi Ross,
Thanks for the patch :)
However this will create a minizip that is statically linked with zlib :(
Guess we need to add some more to the Makefile (or just use the
autotools generated one)
Something along this:
diff --git a/contrib/minizip/Makefile b/contrib/minizip/Makefile
index 4a0465f..cf9e79a 100644
--- a/contrib/minizip/Makefile
+++ b/contrib/minizip/Makefile
@@ -1,13 +1,26 @@
CPPFLAGS = -I../..
-UNZ_OBJS = miniunz.o unzip.o ioapi.o ../../libz.a
-ZIP_OBJS = minizip.o zip.o ioapi.o ../../libz.a
+libminizip_so_SOURCES = \
+ ioapi.c \
+ mztools.c \
+ unzip.c \
+ zip.c
-all: miniunz minizip
+miniunzip_SOURCES = miniunz.c
+miniunzip_LDADD = libminizip.so
+minizip_SOURCES = minizip.c
+minizip_LDADD = libminizip.so -lz
-miniunz: $(UNZ_OBJS)
+all: libminizip.so miniunz minizip
-minizip: $(ZIP_OBJS)
+libminizip.so:
+ $(CC) -fPIC -shared $(libminizip_so_SOURCES) -o libminizip.so
+
+miniunz: libminizip.so
+ $(CC) $(miniunzip_SOURCES) $(miniounzip_LDADD) -o miniunz
+
+minizip: libminizip.so
+ $(CC) $(minizip_SOURCES) $(minizip_LDADD) -o minizip
test: miniunz minizip
@rm -f test.*
Or?
Hi Ross, Richard
Back from vacation? :)
/Sean
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169836):
https://lists.openembedded.org/g/openembedded-core/message/169836
Mute This Topic: https://lists.openembedded.org/mt/92398812/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] sqlite: Increase the size of loop variables in the printf() implementation to avoid harmless compiler warnings.
From: ghassaneben
Increase the size of loop variables in the printf() implementation to avoid
integer overflow on multi-gigabyte string arguments. CVE-2022-35737. This bug
fix refers to: CVE-2022-35737 and it's a backport of a fix added in sqlite
3.39.2 (2022-07-21).
Original commit: https://www.sqlite.org/src/info/aab790a16e1bdff7.
Signed-off-by: Ghassane Ben El Aattar
---
...riables-in-the-printf-implementation.patch | 31 +++
meta/recipes-support/sqlite/sqlite3_3.38.5.bb | 5 +++
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-support/sqlite/sqlite/0001-sqlite-Increased-the-size-of-loop-variables-in-the-printf-implementation.patch
diff --git
a/meta/recipes-support/sqlite/sqlite/0001-sqlite-Increased-the-size-of-loop-variables-in-the-printf-implementation.patch
b/meta/recipes-support/sqlite/sqlite/0001-sqlite-Increased-the-size-of-loop-variables-in-the-printf-implementation.patch
new file mode 100644
index 00..998e93bc6c
--- /dev/null
+++
b/meta/recipes-support/sqlite/sqlite/0001-sqlite-Increased-the-size-of-loop-variables-in-the-printf-implementation.patch
@@ -0,0 +1,31 @@
+From ec75530b8d8268cb07d8e476d79e1b0e59492fa2 Mon Sep 17 00:00:00 2001
+From: drh
+Date: Thu, 18 Aug 2022 15:10:46 +0200
+Subject: [PATCH] sqlite: Increase the size of loop variables in the printf()
implementation to avoid harmless compiler warnings.
+
+Increase the size of loop variables in the printf() implementation to avoid
integer overflow on multi-gigabyte string arguments. CVE-2022-35737. This bug
fix refers to: CVE-2022-35737 and it's a backport of a fix added in sqlite
3.39.2 (2022-07-21).
+Original commit: https://www.sqlite.org/src/info/aab790a16e1bdff7.
+
+Signed-off-by: Ghassane Ben El Aattar
+
+CVE: CVE-2022-35737
+
+Upstream-Status: Backport
https://github.com/sqlite/sqlite/commit/6eb7354fabede50a3601f251caaec172556a3a82
+---
+ src/printf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/printf.c b/src/printf.c
+index f867d62..490199a 100644
+--- a/src/printf.c
b/src/printf.c
+@@ -542,7 +542,8 @@ static int vxprintf(
+ case etSQLESCAPE:
+ case etSQLESCAPE2:
+ {
+- int i, j, n, c, isnull;
++ i64 i, j, n, c;
++ int isnull;
+ char *arg = va_arg(ap,char*);
+ isnull = arg==0;
+ if( isnull ) arg = (xtype==etSQLESCAPE2 ? "NULL" : "(NULL)");
diff --git a/meta/recipes-support/sqlite/sqlite3_3.38.5.bb
b/meta/recipes-support/sqlite/sqlite3_3.38.5.bb
index d56a3a0209..7b62980e24 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.38.5.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.38.5.bb
@@ -12,3 +12,8 @@ CVE_CHECK_IGNORE += "CVE-2019-19242"
CVE_CHECK_IGNORE += "CVE-2015-3717"
# Issue in an experimental extension we don't have/use. Fixed by
https://sqlite.org/src/info/b1e0c22ec981cf5f
CVE_CHECK_IGNORE += "CVE-2021-36690"
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+
+SRC_URI +=
"file://0001-sqlite-Increased-the-size-of-loop-variables-in-the-printf-implementation.patch"
+
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169835):
https://lists.openembedded.org/g/openembedded-core/message/169835
Mute This Topic: https://lists.openembedded.org/mt/93243836/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [dunfell][PATCH] golang: Fix security issue
Source: https://github.com/golang/go
MR: 120613, 120613
Type: Security Fix
Disposition: Backport from
https://github.com/golang/go/commit/c15a8e2dbb5ac376a6ed890735341b812d6b965c &&
https://github.com/golang/go/commit/0117dee7dccbbd7803d88f65a2ce8bd686219ad3
ChangeID: 366db775dec045d7b312b8da0436af36ab322046
Description:
Fixed CVE:
1. CVE-2022-30629
2. CVE-2022-30631
Signed-off-by: Hitendra Prajapati
---
meta/recipes-devtools/go/go-1.14.inc | 2 +
.../go/go-1.14/CVE-2022-30629.patch | 47 +++
.../go/go-1.14/CVE-2022-30631.patch | 116 ++
3 files changed, 165 insertions(+)
create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-30629.patch
create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-30631.patch
diff --git a/meta/recipes-devtools/go/go-1.14.inc
b/meta/recipes-devtools/go/go-1.14.inc
index b160222f76..6089fd501d 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -25,6 +25,8 @@ SRC_URI += "\
file://CVE-2021-44717.patch \
file://CVE-2022-24675.patch \
file://CVE-2021-31525.patch \
+file://CVE-2022-30629.patch \
+file://CVE-2022-30631.patch \
"
SRC_URI_append_libc-musl = "
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-30629.patch
b/meta/recipes-devtools/go/go-1.14/CVE-2022-30629.patch
new file mode 100644
index 00..47313a547f
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-30629.patch
@@ -0,0 +1,47 @@
+From 8d0bbb5a6280c2cf951241ec7f6579c90d38df57 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Thu, 25 Aug 2022 10:55:08 +0530
+Subject: [PATCH] CVE-2022-30629
+
+Upstream-Status: Backport
[https://github.com/golang/go/commit/c15a8e2dbb5ac376a6ed890735341b812d6b965c]
+CVE: CVE-2022-30629
+Signed-off-by: Hitendra Prajapati
+---
+ src/crypto/tls/handshake_server_tls13.go | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/src/crypto/tls/handshake_server_tls13.go
b/src/crypto/tls/handshake_server_tls13.go
+index 5432145..d91797e 100644
+--- a/src/crypto/tls/handshake_server_tls13.go
b/src/crypto/tls/handshake_server_tls13.go
+@@ -9,6 +9,7 @@ import (
+ "crypto"
+ "crypto/hmac"
+ "crypto/rsa"
++ "encoding/binary"
+ "errors"
+ "hash"
+ "io"
+@@ -742,6 +743,19 @@ func (hs *serverHandshakeStateTLS13) sendSessionTickets()
error {
+ }
+ m.lifetime = uint32(maxSessionTicketLifetime / time.Second)
+
++ // ticket_age_add is a random 32-bit value. See RFC 8446, section 4.6.1
++ // The value is not stored anywhere; we never need to check the ticket
age
++ // because 0-RTT is not supported.
++ ageAdd := make([]byte, 4)
++ _, err = hs.c.config.rand().Read(ageAdd)
++ if err != nil {
++ return err
++ }
++ m.ageAdd = binary.LittleEndian.Uint32(ageAdd)
++
++ // ticket_nonce, which must be unique per connection, is always left at
++ // zero because we only ever send one ticket per connection.
++
+ if _, err := c.writeRecord(recordTypeHandshake, m.marshal()); err !=
nil {
+ return err
+ }
+--
+2.25.1
+
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-30631.patch
b/meta/recipes-devtools/go/go-1.14/CVE-2022-30631.patch
new file mode 100644
index 00..5dcfd27f16
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-30631.patch
@@ -0,0 +1,116 @@
+From d10fc3a84e3344f2421c1dd3046faa50709ab4d5 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Thu, 25 Aug 2022 11:01:21 +0530
+Subject: [PATCH] CVE-2022-30631
+
+Upstream-Status: Backport
[https://github.com/golang/go/commit/0117dee7dccbbd7803d88f65a2ce8bd686219ad3]
+CVE: CVE-2022-30631
+Signed-off-by: Hitendra Prajapati
+---
+ src/compress/gzip/gunzip.go | 60 +++-
+ src/compress/gzip/gunzip_test.go | 16 +
+ 2 files changed, 45 insertions(+), 31 deletions(-)
+
+diff --git a/src/compress/gzip/gunzip.go b/src/compress/gzip/gunzip.go
+index 924bce1..237b2b9 100644
+--- a/src/compress/gzip/gunzip.go
b/src/compress/gzip/gunzip.go
+@@ -248,42 +248,40 @@ func (z *Reader) Read(p []byte) (n int, err error) {
+ return 0, z.err
+ }
+
+- n, z.err = z.decompressor.Read(p)
+- z.digest = crc32.Update(z.digest, crc32.IEEETable, p[:n])
+- z.size += uint32(n)
+- if z.err != io.EOF {
+- // In the normal case we return here.
+- return n, z.err
+- }
++ for n == 0 {
++ n, z.err = z.decompressor.Read(p)
++ z.digest = crc32.Update(z.digest, crc32.IEEETable, p[:n])
++ z.size += uint32(n)
++ if z.err != io.EOF {
++ // In the normal case we return here.
++ return n, z.err
++ }
+
+- // Finished file; check checksum
[OE-core] [PATCH] apr: Cache configure tests which use AC_TRY_RUN
AC_TRY_RUN macro means the test needs to run to find the result and we are cross compiling so this will always get wrong results, this results in miscompiling apache2 on musl because it disables rlimit (ac_cv_struct_rlimit) wrongly. All these variables are determined with AC_TRY_RUN checks Signed-off-by: Khem Raj --- meta/recipes-support/apr/apr_1.7.0.bb | 9 + 1 file changed, 9 insertions(+) diff --git a/meta/recipes-support/apr/apr_1.7.0.bb b/meta/recipes-support/apr/apr_1.7.0.bb index 07bf61545e..1fbdeddeb2 100644 --- a/meta/recipes-support/apr/apr_1.7.0.bb +++ b/meta/recipes-support/apr/apr_1.7.0.bb @@ -37,6 +37,15 @@ OE_BINCONFIG_EXTRA_MANGLE = " -e 's:location=source:location=installed:'" # Added to fix some issues with cmake. Refer to https://github.com/bmwcarit/meta-ros/issues/68#issuecomment-19896928 CACHED_CONFIGUREVARS += "apr_cv_mutex_recursive=yes" +# Enable largefile +CACHED_CONFIGUREVARS += "apr_cv_use_lfs64=yes" +# Additional AC_TRY_RUN tests which will need to be cached for cross compile +CACHED_CONFIGUREVARS += "apr_cv_epoll=yes epoll_create1=yes apr_cv_sock_cloexec=yes ac_cv_struct_rlimit=yes \ + ac_cv_func_sem_open=yes apr_cv_process_shared_works=yes \ + ac_cv_func_pthread_mutexattr_setpshared=yes" +# robust mutexes exist on glibc but not musl +CACHED_CONFIGUREVARS:append:libc-musl = " apr_cv_mutex_robust_shared=no" +CACHED_CONFIGUREVARS:append:libc-glibc = " apr_cv_mutex_robust_shared=yes" # Also suppress trying to use sctp. # -- 2.37.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169833): https://lists.openembedded.org/g/openembedded-core/message/169833 Mute This Topic: https://lists.openembedded.org/mt/93243812/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 2/2] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid
> -Original Message- > From: Alexander Kanavin > Sent: den 24 augusti 2022 16:53 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org; Alexander Kanavin > > Subject: Re: [OE-core] [PATCH 2/2] scripts/oe-setup-builddir: add a check > that TEMPLATECONF is valid > > On Wed, 24 Aug 2022 at 16:43, Peter Kjellerstedt > wrote: > > We create the sample files in a small wrapper for oe-init-build-env > > so that to the users, everything works just as described in the Yocto > > documentation. And since the OE scripts expect TEMPLATECONF to be set > > and contain sample files, that is what we create. > > Actually they don't expect that. You can simply create the configs > directly into the target build directory in your wrapper, and drop > TEMPLATECONF altogether. Then the OE scripts will detect that the > configs are already there and will skip the step of copying the > templates. Hmm, ok. I will have to look into that... > > Sure, that is fine. But the expectation I have is that TEMPLATECONF > > refers to the directory that has the sample files needed to set up > > the build environment. And that is it. As long as the sample files > > exist where it says they should be, why do you need the scripts to > > fail because the environment around the directory does not look > > like what you happen to expect? It is only the contents of the > > directory that matters. Or am I missing something? > > We are trying to move towards standardizing build configuration > management. One step towards that goal is that config templates must > live in meta-some-layer/conf/templates, and aren't scattered around, > or generated on the fly. This rule only makes sense if there is some > way to enforce it, which is what this change does. Well, we gave up on the static templates almost immediately after we started using Yocto when we realized that they did not fit into our idea of being able to mix layers in different combinations in different builds. We rely on repo fetching the layers that are supposed to be part of the build, and then we generate a bblayers.conf.sample that matches the fetched layers. > Alex //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169832): https://lists.openembedded.org/g/openembedded-core/message/169832 Mute This Topic: https://lists.openembedded.org/mt/93225500/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 2/2] oeqa/sdk: extend rust test to also use a build script
Hi Richard,
On 2022-08-24 10:52, Richard Purdie wrote:
On Tue, 2022-08-23 at 10:56 +0200, Peter Bergin wrote:
The test for rust in the SDK is extended with the simplest
possible build script. This will make use of the host toolchain
for building build.rs before building the rust package for target.
Signed-off-by: Peter Bergin
---
meta/lib/oeqa/sdk/files/rust/hello/build.rs | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 meta/lib/oeqa/sdk/files/rust/hello/build.rs
diff --git a/meta/lib/oeqa/sdk/files/rust/hello/build.rs
b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
new file mode 100644
index 000..b1a533d5dfa
--- /dev/null
+++ b/meta/lib/oeqa/sdk/files/rust/hello/build.rs
@@ -0,0 +1,3 @@
+/* This is the simplest build script just to invoke host compiler
+ in the build process. */
+fn main() {}
This seemed to break everywhere :(
Not good. :-|
https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/5773/steps/13/logs/stdio
and many others.
I've tried locally to reproduce something. I've built and tested
genericx86 and qemuarm64 now on core-image-sato sdk that I saw was the
target for the autobuilder. Both tests passes. The failure I see in the
autobuilder logs is that the build script can not be executed. On my
machine I have that file and it can clearly be executed:
$ find
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/
-name build-script-build
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
$
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
$ file
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2,
BuildID[sha1]=c5d5e70657f8342addf5343d0206c77d9d767fd8, for GNU/Linux
3.2.0, with debug_info, not stripped
Found one interesting link here
https://github.com/rust-lang/cargo/issues/3553. Unfortunately without
answer. But also checked the interpreter in my build which looks correct?
$ readelf -a
tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/hello/target/debug/build/hello-4dbf26d86b93a892/build-script-build
| grep interpreter
[Requesting program interpreter:
/storage/yocto/esp5-platform/build/genericx86/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
So there are some differences between my machine and the autobuilder
setup that I can't get. I would need help here as I'm not that familiar
with the autobuilder setup. Can it still be some host dependency? I'm
running on Ubuntu 22.04. Is it possible to check in a autobuilder setup
if the file 'build-script-build' is present and possible to execute?
Best regards,
/Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169831):
https://lists.openembedded.org/g/openembedded-core/message/169831
Mute This Topic: https://lists.openembedded.org/mt/93200332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
