|
Current high bug count owners for Yocto Project 3.5
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 394 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.5" and then “3.6”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Logical Volumes not present at boot time with sysvinit, mountall.sh
#honister
bgctkd@...
I am seeing that logical volumes in /etc/fstab are not present at boot time when mountall.sh is being run
on my image based off Poky/Honister, with lvm2 recipe After boot, once I log in, lsblk shows the mount points and "mount -a" works as expected. At boot, alas no dice. Any suggestions on how to get the logical volumes in place so that they can be mounted from /etc/fstab during boot when mountall.sh is being run? During boot: At Beginning of mountall.sh NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 55.9G 0 disk |-sda1 8:1 0 101.9M 0 part `-sda2 8:2 0 55.8G 0 part Mon Apr 4 17:33:05 UTC 2022 After mounting file systems Post Boot: root@intel-corei7-64:/tmp# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 55.9G 0 disk |-sda1 8:1 0 101.9M 0 part `-sda2 8:2 0 55.8G 0 part |-mount-pt-a 252:0 0 1000M 0 lvm |-mount-pt-b 252:1 0 100M 0 lvm |-mount-pt-c 252:2 0 6.3G 0 lvm Thanks, Bruce |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-zephyr][PATCH] zephyr-kernel-src: add whitespace to fix File not found during build
Davide Gardenal
Signed-off-by: Davide Gardenal <davide.gardenal@...>
--- .../recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc index f4ea7d3..61a5076 100644 --- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc @@ -69,4 +69,4 @@ SRCREV_zscilib = "12bfe3f0a9fcbfe3edab7eabc9678b6c62875d34" ZEPHYR_BRANCH = "v3.0-branch" PV = "3.0.0+git${SRCPV}" -SRC_URI += "file://0001-lvgl-add-support-for-lvgl-v8.2.0.patch" +SRC_URI += "file://0001-lvgl-add-support-for-lvgl-v8.2.0.patch " -- 2.32.0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH] fscrypt: update dependecy from go-dep-native to go-native
Davide Gardenal
Signed-off-by: Davide Gardenal <davide.gardenal@...>
--- recipes-security/fscrypt/fscrypt_1.0.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-security/fscrypt/fscrypt_1.0.0.bb b/recipes-security/fscrypt/fscrypt_1.0.0.bb index 66bf429..663d8e2 100644 --- a/recipes-security/fscrypt/fscrypt_1.0.0.bb +++ b/recipes-security/fscrypt/fscrypt_1.0.0.bb @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://src/${GO_IMPORT}/LICENSE;md5=3b83ef96387f14655fc854dd BBCLASSEXTEND = "native nativesdk" # fscrypt depends on go and libpam -DEPENDS += "go-dep-native libpam" +DEPENDS += "go-native libpam" SRCREV = "92b1e9a8670ccd3916a7d24a06cab1e4c9815bc4" SRC_URI = "git://github.com/google/fscrypt.git;branch=master;protocol=https" -- 2.32.0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH] clamav: add COMPATIBLE_HOST to fix build error
Davide Gardenal
Add COMPATIBLE_HOST to match what is found in glibc
to avoid build error when using musl Signed-off-by: Davide Gardenal <davide.gardenal@...> --- recipes-scanners/clamav/clamav_0.104.0.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb index f0889de..ae2d292 100644 --- a/recipes-scanners/clamav/clamav_0.104.0.bb +++ b/recipes-scanners/clamav/clamav_0.104.0.bb @@ -6,6 +6,8 @@ LICENSE = "LGPL-2.1" DEPENDS = "glibc llvm libtool db openssl zlib curl libxml2 bison pcre2 json-c libcheck" +COMPATIBLE_HOST:libc-musl:class-target = "null" + LIC_FILES_CHKSUM = "file://COPYING.txt;beginline=2;endline=3;md5=f7029fbbc5898b273d5902896f7bbe17" # July 27th -- 2.32.0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Specified SDKMACHINE value is not valid
Ross Burton <ross@...>
Is Raspian 32- or 64-bit? We don't suppose 32-bit arm SDKs.
As Khem said, set SDKMACHINE to i686 explicitly to avoid this. Note that compiling on a RPi4 is *very slow*. Ross On Sat, 2 Apr 2022 at 17:37, jchludzinski via lists.yoctoproject.org <jchludzinski=vivaldi.net@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Building a core-image-weston with custom app using rust and gtk3
Alexander Kanavin
It helps if you show the error messages. Otherwise, the only thing we can say in response is 'yes, apparently'. Alex On Sat, 2 Apr 2022 at 10:53, Artur Czajkowski <atch.cpp@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Announcing the Yocto Project Summit 2022.5
Hello Yocto and OpenEmbedded professionals and enthusiasts,
The Yocto Project will be hosting a 3 day virtual summit that begins on May 17th, 2022 [1]. The CFP is now open and will close on April 26th [2]. The cost is the same as before: $40 USD. For more information, you can visit the links below. [1][2] Hope to see you there. Kind regards, Armin On behalf of the Yocto Project Summit Committee. [1] https://www.yoctoproject.org/yocto-project-summit-2022-05/ [2] https://pretalx.com/yocto-project-summit-2022-05/cfp/ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Fedora 36 / uninative GLIBCXX 3.4.30
Federico Pellegrin
Hello, Thanks for the feedback! Indeed the check is only on the "ldd --version" output which doesn't account for the libstdc++ and that explains it. As compared to Ubuntu 22.04, Fedora 36 actually has also GCC 12.0.1 as default compiler. As Martin mentions not sure if there is an easy portable way. He mentions objdump which is for sure effective but maybe complicated and I feel like relies on the filename being guessed (well should be known, the main link at least) and feels a bit overcomplicated (if we need to go that low level in case I'd suggest just to just use "strings" and grep there instead). Would relying just on the filename be too shaky? I can see here https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html in point 3 of "History" that it would seem quite well defined. Actually I guess if we would just compare the system libstdc++.so.X.Y.Z (which we may be easily able to get it from the libstdc++.so link) to uninative one maybe would be enough to determine it is newer? Hardcoding the path to libstdc++.so (as ie. /usr/lib64/libstdc++.so) is probably not nice (ie. for custom toolchains), so maybe we can ask g++ (-print-search-dirs, libraries section) and look in those? Then not sure if there are some distros/installs that do the insane-isy thing of just installing directly the .so stripping the versions from the name, hopefully not. I'm not sure using anything from g++ -dumpspecs would be viable if as Martin mentions you may have (ie. ubuntu-2204) a version with new stdc++ but older g++. Federico Il giorno dom 3 apr 2022 alle ore 16:52 Martin Jansa <martin.jansa@...> ha scritto:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH] samhain: update to 4.4.7
This fixes musl builds too.
Signed-off-by: Armin Kuster <akuster808@...> --- recipes-ids/samhain/samhain.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc index d64cddb..5c1d6f5 100644 --- a/recipes-ids/samhain/samhain.inc +++ b/recipes-ids/samhain/samhain.inc @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.la-samhna.de/samhain/" LICENSE = "GPL-2.0-or-later" LIC_FILES_CHKSUM = "file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b" -PV = "4.4.6" +PV = "4.4.7" SRC_URI = "https://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \ file://${INITSCRIPT_NAME}.init \ @@ -21,7 +21,7 @@ SRC_URI = "https://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \ file://samhain-fix-initializer-element-is-not-constant.patch \ " -SRC_URI[sha256sum] = "0b511a184066759cd864f6d15fe941ed3fe60f0cdc886dab68daa191d567de24" +SRC_URI[sha256sum] = "0aa978accb635000c2d9170f307bff8a95836f8ec01615a53dbd9c2af9564d44" UPSTREAM_CHECK_URI = "https://www.la-samhna.de/samhain/archive.html" UPSTREAM_CHECK_REGEX = "samhain_signed-(?P<pver>(\d+(\.\d+)+))\.tar" -- 2.25.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 2/2] linux-yocto_security.inc: add lkrg kfrags
Signed-off-by: Armin Kuster <akuster808@...>
--- recipes-kernel/linux/files/lkrg.cfg | 4 ++++ recipes-kernel/linux/files/lkrg.scc | 5 +++++ recipes-kernel/linux/linux-yocto_security.inc | 3 +++ 3 files changed, 12 insertions(+) create mode 100644 recipes-kernel/linux/files/lkrg.cfg create mode 100644 recipes-kernel/linux/files/lkrg.scc diff --git a/recipes-kernel/linux/files/lkrg.cfg b/recipes-kernel/linux/files/lkrg.cfg new file mode 100644 index 0000000..e02bf76 --- /dev/null +++ b/recipes-kernel/linux/files/lkrg.cfg @@ -0,0 +1,4 @@ +CONFIG_DEBUG_KERNEL=y +CONFIG_KALLSYMS_ALL=y +CONFIG_JUMP_LABEL=y +CONFIG_DEBUG_SECTION_MISMATCH=y diff --git a/recipes-kernel/linux/files/lkrg.scc b/recipes-kernel/linux/files/lkrg.scc new file mode 100644 index 0000000..83397f8 --- /dev/null +++ b/recipes-kernel/linux/files/lkrg.scc @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: MIT +define KFEATURE_DESCRIPTION "Enable Support for LKRG" +define KFEATURE_COMPATIBILITY board + +kconf hardware lkrg.cfg diff --git a/recipes-kernel/linux/linux-yocto_security.inc b/recipes-kernel/linux/linux-yocto_security.inc index defca57..b79af80 100644 --- a/recipes-kernel/linux/linux-yocto_security.inc +++ b/recipes-kernel/linux/linux-yocto_security.inc @@ -1,3 +1,6 @@ +FILESEXTRAPATHS:prepend := "${THISDIR}/files:" + KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}" KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}" KERNEL_FEATURES:append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}" +SRC_URI += " ${@bb.utils.contains("DISTRO_FEATURES", "lkrg", "file://lkrg.scc", "" ,d)}" -- 2.25.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 1/2] lkrg-module: covert to git fetcher
This allows to track tip easier.
refresh patch Fix LICENSE to match SPDX format Signed-off-by: Armin Kuster <akuster808@...> --- recipes-kernel/lkrg/files/makefile_cleanup.patch | 6 +++--- recipes-kernel/lkrg/lkrg-module_0.9.2.bb | 10 +++++----- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/recipes-kernel/lkrg/files/makefile_cleanup.patch b/recipes-kernel/lkrg/files/makefile_cleanup.patch index a4db2d9..799b1a6 100644 --- a/recipes-kernel/lkrg/files/makefile_cleanup.patch +++ b/recipes-kernel/lkrg/files/makefile_cleanup.patch @@ -4,10 +4,10 @@ This needs more work. Its my starting point. Signed-off-by: Armin Kuster <akuster808@...> -Index: lkrg-0.9.2/Makefile +Index: git/Makefile =================================================================== ---- lkrg-0.9.2.orig/Makefile -+++ lkrg-0.9.2/Makefile +--- git.orig/Makefile ++++ git/Makefile @@ -4,28 +4,10 @@ # Author: # - Adam 'pi3' Zabrocki (http://pi3.com.pl) diff --git a/recipes-kernel/lkrg/lkrg-module_0.9.2.bb b/recipes-kernel/lkrg/lkrg-module_0.9.2.bb index e055fbe..85f7d44 100644 --- a/recipes-kernel/lkrg/lkrg-module_0.9.2.bb +++ b/recipes-kernel/lkrg/lkrg-module_0.9.2.bb @@ -3,18 +3,18 @@ DESCRIPTION="LKRG performs runtime integrity checking of the Linux \ kernel and detection of security vulnerability exploits against the kernel." SECTION = "security" HOMEPAGE = "https://www.openwall.com/lkrg/" -LICENSE = "GPLv2" +LICENSE = "GPL-2.0-only" LIC_FILES_CHKSUM = "file://LICENSE;md5=5105ead24b08a32954f34cbaa7112432" DEPENDS = "virtual/kernel elfutils" -SRC_URI = "https://download.openwall.net/pub/projects/lkrg/lkrg-${PV}.tar.gz \ - file://makefile_cleanup.patch " +SRCREV = "43db5f19fca259feb1962f6db33382348cbc8320" -SRC_URI[sha256sum] = "c2b501c47089cce3ec3114cef6520b73aa3a098836183186b9bb5e097c99ac27" +SRC_URI = "git://github.com/lkrg-org/lkrg.git;protocol=https;branch=main \ + file://makefile_cleanup.patch " -S = "${WORKDIR}/lkrg-${PV}" +S = "${WORKDIR}/git" inherit module kernel-module-split -- 2.25.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Fedora 36 / uninative GLIBCXX 3.4.30
Martin Jansa
FWIW: the same is happening now with ubuntu-22.04 where libstdc++6 package is now built from gcc-12 sources (even when gcc itself still defaults to gcc-11). I was trying to add the check in uninative.bbclass, but haven't found easy portable way to detect the version from libstdc++.so.6 (other than parsing objdump -x /full/path/to/libstdc++.so.6 output). On Sun, Apr 3, 2022 at 12:44 PM Richard Purdie <richard.purdie@...> wrote: On Sun, 2022-04-03 at 09:12 +0200, Federico Pellegrin wrote: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Fedora 36 / uninative GLIBCXX 3.4.30
Richard Purdie
On Sun, 2022-04-03 at 09:12 +0200, Federico Pellegrin wrote:
I've been playing around building a Yocto imagine based on kirkstone/master onThanks for reporting it. I think to generate the newer version we need gcc 12 which is still in pre-release. We generate the uninative tarball using our own builds on the autobuilder so until we have gcc 12 recipes there, we can't generate that. Once gcc 12 is out, we will release a new uninative (assuming we can update our recipes). I'd like to think the checks in uninative would have noticed the mismatch, we do have some code there to detect libc version but perhaps not the CXX pieces so I'd welcome help in adding something for that. Cheers, Richard |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Fedora 36 / uninative GLIBCXX 3.4.30
Federico Pellegrin
Hello, I've been playing around building a Yocto imagine based on kirkstone/master on the just released Fedora 36 beta test image. (just to give a few bits more details: builds a MX8X image, works perfectly fine with Fedora 34 and 35 since quite some time) The first and most obvious thing I've found out is that it is based on a newer version of glibcxx (3.4.30) when the very latest uninative available (as far as I could see, apologies if I'm wrong) is on 3.4.29, so at some point this will break the build (when pzstd is called). Of course for the time being I just disabled uninative and the build is going on (will report of course should I find something else). I'm not sure (still checking this) if that should have happened automatically, but there was actually no warning in that sense (maybe because is GLIBCXX and not GLIBC itself?) But the question is: should I try to contribute that tarball (I will search for details, but if there is any good reference more than welcome!) or is it something that is likely done by the core team? Of course FC36 is still a test distro so there is no surprise it broke, but as we are close to Kirkstone release and possibly other distros will get the same upgrade, I guess it could be great if we may fix this before that deadline. Many thanks! Federico |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: installed and not shipped files. [installed-vs-shipped]
Konstantin Kletschke
On Sat, Apr 02, 2022 at 12:13:26PM +0200, Quentin Schulz wrote:
FILES variables is compatible with glob from Python so that should work but that's really the first time I see this, usually it's just the directory or dir/*. Learned something new today :):-) Are you on honister (or master/soon kirkstone) release? If so, it's FILES:${PN} and not FILES_${PN}.That's it! I wasn't aware of this change, could have searched for another couple of days! Thank. you. very. much. Kind Regards Konsti -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Straße 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletschke@... http://www.inside-m2m.de Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig HRB: 111204, AG Hannover |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Specified SDKMACHINE value is not valid
On Sat, Apr 2, 2022 at 9:37 AM jchludzinski <jchludzinski@...> wrote:
Oh I see. we do support aarch64 as build host, so if you are trying 64bit OS on rpi then it should work although, rpi4 may not have enough muscle to build, perhaps using SSD with rpi4 might help a bit So find out if rpi4 is running in 64bit mode if not then building on armv7 might have issues. in anycase try setting SDKMACHINE = "i686" this should get you past this particular error, there might be more after it. Fixed when x11 is not in DISTRO_FEATURES: $ bitbake wxwidgets ERROR: Nothing PROVIDES 'wxwidgets' wxwidgets was skipped: missing required distro feature 'x11' (not in DISTRO_FEATURES) On 2022-04-02 12:15, Khem Raj wrote:On Sat, Apr 2, 2022 at 1:47 AM jchludzinski <jchludzinski@...>-- |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Specified SDKMACHINE value is not valid
jchludzinski
I’m actually trying this on an RP4 running Raspbian.
toggle quoted message
Show quoted text
On 2022-04-02 12:15, Khem Raj wrote:
On Sat, Apr 2, 2022 at 1:47 AM jchludzinski <jchludzinski@...> wrote:$ git clone git://git.yoctoproject.org/poky.gitare you on a x86_64 host? Secondly try to uncomment SDKMACHINE setting --
NULL |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Specified SDKMACHINE value is not valid
On Sat, Apr 2, 2022 at 1:47 AM jchludzinski <jchludzinski@...> wrote:
are you on a x86_64 host? Secondly try to uncomment SDKMACHINE setting in local.conf and see if it helps. Also check if your default shell is bash or dash.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|