Date   

Customizing SERIAL_CONSOLES

chris yocto
 

Hi,

 

I’m trying to customize the SERIAL_CONSOLES variable. In another thread I read this can be done by adding a machine-extra.conf file too my custom layer. So I added “ SERIAL_CONSOLES = "115200;ttymxc0" ” to my machine-extra.conf, but when I  bitbake my custom image, no changes are found.

In the conf file from the bsp for the board I’m using I found “SERIAL_CONSOLES = "115200;ttymxc2", when I change this to SERIAL_CONSOLES ?= "115200;ttymxc2" my changes are being applied.

This off course is not ideal since I then still don’t have all changes in my own layer.  

Is there a way I can solve this?

 

Kind regards,

 

Chris


[PATCH yocto-autobuilder-helper] config.json: Set SDKMACHINE to aarch64 for oe-selftest-armhost

Ross Burton
 

Although bitbake.conf sets the default SDKMACHINE to the build
architecture, config.json resets that to i686.

As oe-selftest assumes that the SDKs it builds are usable on the host
machine, we should set SDKMACHINE=3Daarch64 in the oe-selftest-armhost
build.

A follow-up more invasive patch to clean up the SDKMACHINE assignments
is in progress, once it has been verified to not cause regressions.

Signed-off-by: Ross Burton <ross.burton@...>
---
config.json | 1 +
1 file changed, 1 insertion(+)

diff --git a/config.json b/config.json
index 15adeb3..ce76056 100644
--- a/config.json
+++ b/config.json
@@ -881,6 +881,7 @@
"TEMPLATE" : "selftest"
},
"oe-selftest-armhost" : {
+ "SDKMACHINE": "aarch64",
"TEMPLATE" : "selftest"
},
"reproducible" : {
--=20
2.34.1


Sorry, a test

Ross Burton
 

Apologies for the test spam.  Hopefully this doesn’t have a legal disclaimer attached.

 

Ross


Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>
 

On Mon, 11 Jul 2022 17:46 +0200, Gregory Anders wrote:
On Friday, July 08, 2022 08:12 AM MDT, Khem Raj <raj.khem@...> wrote:

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
Problem solved: the issue was actually that I was using a network
sstate cache,
and the cached output of gcc-cross did not contain gfortran.
Disabling the
sstate cache for gcc-cross causes gfortran to be included in the
sysroot and
now all is working as expected.
You shouldn't have to disable the sstate cache but glad you got it
working. Which release series is that with?
I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).

Perhaps it’s using locked sstate which might be the reason
I didn't know the sstate could be locked -- how would one unlock it? Could you
point me toward some relevant docs?

After some cursory searching the only thing I've found is the 'locked-sigs.inc'
file. And indeed, Petalinux does ship with a locked-sigs.inc file which
includes a signature for gcc-cross-arm. But adding gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES doesn't seem to have any effect.
I think I've finally figured this out and just wanted to provide some
closure for posterity's sake.

My initial "solution" of clearing the SSTATE_MIRRORS variable was not
actually correct. It turns out I was not actually even clearing it
correctly, and when I "fixed" it to correctly clear the variable it
caused a build error.

The solution was, in fact, to add gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES. I simply added this line to my configuration:

SIGGEN_UNLOCKED_RECIPES += "gcc-cross-arm gcc-runtime libgcc"

In my last message, I said that this had no effect. I can only guess
that it appeared that way because some other part of the build was being
cached. After clearing everything in the build directory and
re-building, it seems to work as expected.

Thanks to everyone who offered help.

Greg


Recipe fails at do_rm_work due to failed attempt to delete a named pipe (FIFO)

d.antliff@...
 

Hi,

I'm working with a PetaLinux 2021.2 project, which defines a recipe called "petalinux-initramfs-image".

# Simple petalinux initramfs image.
DESCRIPTION = "Small image capable of booting a device. The kernel includes \
the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \
first 'init' program more efficiently."

INITRAMFS_SCRIPTS ?= "initramfs-framework-base \
            initramfs-module-e2fs \
            initramfs-module-udhcpc \
            initramfs-module-searche2fs \
            "

INITRAMFS_SCRIPTS_append_k26 = " initramfs-module-exec"

INITRAMFS_PACKAGES ?= "${VIRTUAL-RUNTIME_base-utils} \
            base-passwd \
            e2fsprogs \
            ${ROOTFS_BOOTSTRAP_INSTALL} \
            ${MACHINE_ESSENTIAL_EXTRA_RDEPENDS} \
            "

BAD_RECOMMENDATIONS += "initramfs-module-rootfs"

PACKAGE_INSTALL ?= "packagegroup-core-boot ${INITRAMFS_PACKAGES} ${INITRAMFS_SCRIPTS}"

# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = ""

export IMAGE_BASENAME = "petalinux-initramfs-image"
IMAGE_LINGUAS = ""

LICENSE = "MIT"

IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
inherit core-image

IMAGE_ROOTFS_SIZE = "8192"
IMAGE_ROOTFS_EXTRA_SPACE = "0"

rm_work_rootfs[noexec] = "1"
rm_work_rootfs[cleandirs] = ""
RM_WORK_EXCLUDE_ITEMS = "rootfs"


For reasons I don't understand, this recipe fails to build at the do_rm_work task. Looking at the bitbake -v log, I can see that this recipe is somehow causing the temp directory in the build directory to be deleted:

+ rm -rf recipe-sysroot-native

+ for dir in *

+ '[' rootfs = pseudo ']'

+ echo rootfs

+ grep -q -w rootfs

+ for dir in *

+ '[' temp = pseudo ']'

+ echo rootfs

+ grep -q -w temp

+ rm -rf temp

+ ret=0

+ trap '' 0

+ exit 0

ERROR: petalinux-initramfs-image-1.0-r0 do_rm_work: [Errno 2] No such file or directory: '/[removed]/build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.59670'

I think whatever is calling do_rm_work (in rm_work.bbclass) is creating a named pipe (FIFO) file in the build/...petalinux-initramfs-image/1.0-r0/temp directory, for whatever purpose, and then when this recipe (for whatever reason) causes the deletion of the temp directory and exits, this outer entity then expects to be able to clean up the FIFO file it created, fails to do so, and raises the fatal error.

I'm assuming that this is a problem with the recipe itself, but I (with my limited knowledge and experience in this area) cannot see anything obvious in there that would lead to the inadvertent deletion of the temp directory.

Note that if I add RM_WORK_EXCLUDE += "petalinux-initramfs-image" then the build does not fail and I see this instead:

NOTE: Executing Tasks
+ do_rm_work
+ for p in petalinux-initramfs-image

NOTE: petalinux-initramfs-image-1.0-r0 do_rm_work: rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE
+ '[' petalinux-initramfs-image = petalinux-initramfs-image ']'
+ bbnote 'rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE'
+ '[' -p /[removed]/build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.60213 ']'
+ printf '%b\0' 'bbnote rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE'
+ exit 0
+ bb_bash_exit_handler 'exit 0'
+ ret=0

+ set +x

There the named pipe file is mentioned, but I'm not sure why a test for its existence is here, interleaved with output from rm_work.bbclass. I don't see that in rm_work.bbclass anywhere - or is it a part of bbnote​?

Any idea what's going on with this recipe?

-- David.






M+ & H bugs with Milestone Movements WW2"All,

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW28 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

14065

Automated ptest regression testing

randy.macleod@...

ross.burton@...

4.1 M2

4.1 M3

Medium+

14775

AB-INT: SDK preparation failure: SState: cannot test file://[...] TimeoutError('timed out')

richard.purdie@...

unassigned@...

4.1 M2

4.1 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW28!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

alejandro@...

2

yogesh.tyagi@...

1

ptsneves@...

1

randy.macleod@...

1

ross.burton@...

1

Grand Total

6

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 4.1

Stephen Jolley
 

All,

Below is the list as of top 35 bug owners as of the end of WW28 of who have open medium or higher bugs and enhancements against YP 4.1.   There are 77 possible work days left until the final release candidates for YP 4.1 needs to be released.

Who

Count

michael.opdenacker@...

36

ross.burton@...

27

david.reyna@...

23

bruce.ashfield@...

21

randy.macleod@...

16

richard.purdie@...

10

saul.wold@...

10

JPEWhacker@...

9

sakib.sajal@...

9

Aryaman.Gupta@...

6

tim.orling@...

6

mhalstead@...

5

jon.mason@...

4

akuster808@...

3

tvgamblin@...

2

pavel@...

2

pgowda.cve@...

2

Qi.Chen@...

2

hongxu.jia@...

2

sundeep.kokkonda@...

2

mostthingsweb@...

1

aehs29@...

1

behanw@...

1

martin.beeger@...

1

Ahmed.Hossam@...

1

nicolas.dechesne@...

1

raj.khem@...

1

Martin.Jansa@...

1

thomas.perrot@...

1

shachar@...

1

ola.x.nilsson@...

1

alexandre.belloni@...

1

luca.ceresoli@...

1

alejandro@...

1

open.source@...

1

Grand Total

212

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 410 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,  “4.1”, “4.2”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.

 

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@...

 


missing cgroups when trying to re-mount rootfs from initramfs busybox image

Embedded 1
 

I have busybox with an initramfs. When I try to re-mount the rootfs I
see this. This is with Yocto. Do I need to include systemd in my
initramfs image?

sh-5.0# exec switch_root /root /sbin/init
switch_root: failed to mount moving /run to /root/run: Invalid argument
switch_root: forcing unmount of /run
[ 339.929584] systemd[1]: System time before build time, advancing clock.
[ 339.974784] systemd[1]: Module 'autofs4' is built in
[ 339.980811] systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file
or directory
[ 339.989411] systemd[1]: Failed to mount cgroup at /sys/fs/cgroup/systemd: No
such file or directory
[!!!!!!] Failed to mount API filesystems.
[ 340.024657] systemd[1]: Freezing execution.


Re: Installing gfortran into native sysroot for libgfortran

Philip Balister
 

In my notes:

cat /dev/null > conf/locked-signs.inc

Philip

On 7/11/22 12:49, Gregory Anders wrote:
On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:

On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto:greg@...>> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
>On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
>> Problem solved: the issue was actually that I was using a network
>> sstate cache,
>> and the cached output of gcc-cross did not contain gfortran.
>> Disabling the
>> sstate cache for gcc-cross causes gfortran to be included in the
>> sysroot and
>> now all is working as expected.
>
>You shouldn't have to disable the sstate cache but glad you got it
>working. Which release series is that with?

I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).


Perhaps it’s using locked sstate which might be the reason
It is. It was great fun to find the path to disable it when I also had
this issue :)

Philip
(Apologies for the double post to the list.)
Philip, would you mind sharing what you did to disable it?
Thanks,
Greg


Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>
 

On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:

On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto:greg@...>> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
>On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
>> Problem solved: the issue was actually that I was using a network
>> sstate cache,
>> and the cached output of gcc-cross did not contain gfortran.
>> Disabling the
>> sstate cache for gcc-cross causes gfortran to be included in the
>> sysroot and
>> now all is working as expected.
>
>You shouldn't have to disable the sstate cache but glad you got it
>working. Which release series is that with?

I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).


Perhaps it’s using locked sstate which might be the reason
It is. It was great fun to find the path to disable it when I also had
this issue :)

Philip
(Apologies for the double post to the list.)

Philip, would you mind sharing what you did to disable it?

Thanks,

Greg


How to get license text

William Huang <whuang8933@...>
 

Hi,
I was wondering if it is possible to get the license information for all of the deployed packages in the image? I know there's a license.manifest file in deploy/licenses, but I'm looking for a file that includes that manifest as well as the paragraph associated with the license. Closest I found was in the /usr/share/common-license folder which has the LICENSE or COPYING file for each package, but I am looking if there's a single file that contains this information instead.

Thanks


Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>
 

On Friday, July 08, 2022 08:12 AM MDT, Khem Raj <raj.khem@...> wrote:

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
Problem solved: the issue was actually that I was using a network
sstate cache,
and the cached output of gcc-cross did not contain gfortran.
Disabling the
sstate cache for gcc-cross causes gfortran to be included in the
sysroot and
now all is working as expected.
You shouldn't have to disable the sstate cache but glad you got it
working. Which release series is that with?
I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).

Perhaps it’s using locked sstate which might be the reason
I didn't know the sstate could be locked -- how would one unlock it? Could you
point me toward some relevant docs?

After some cursory searching the only thing I've found is the 'locked-sigs.inc'
file. And indeed, Petalinux does ship with a locked-sigs.inc file which
includes a signature for gcc-cross-arm. But adding gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES doesn't seem to have any effect.


ALTERNATIVE and RDEPENDS

Konrad Weihmann <kweihmann@...>
 

Hi all,

is there a way to set the package metadata in a way that it would require one of the packages providing a tool via the ALTERNATIVE_ mechanism?

E.g. sed for instance could be provided by busybox (if enabled in config) or by the standalone sed recipe - within my recipe I would just want to make sure that any of the providing packages is available/used when assembling the image.

This basically affects all of the tools that are provided by coreutils and busybox too

I would be happy about any pointer...

Regards
Konrad


Re: source-less python

Aurum Nitrogen
 

Hi, 
So after a little bit of research, I've implemented this feature in poky.
The way buildroot works, is that it doesn't create any .pyc files during the build process of single packages but has a post rootfs hook that (If that's what the user has configured) compiles the .py files into .pyc files and removes the .py files.
The compilation to .pyc files is done using a small script that uses python's py_compile module.
 
I have attached the diff to poky for implementation of this feature and the pycompile.py script.
I would love to get your input on this.

Another thing I noticed while doing this research was that the python recipe has a variable called INCLUDE_PYCS that decides if to include the .pyc files in the package. This is nice but why not implement this in the rest of the python package recipes? It can be added to setuptools3.bbclass or something like that. What do you think?

Thanks a lot,

John

‫בתאריך יום ה׳, 23 ביוני 2022 ב-19:10 מאת ‪Ross Burton‬‏ <‪Ross.Burton@...‬‏>:‬

On 23 Jun 2022, at 23:40, Aurum Nitrogen via lists.yoctoproject.org <aurumnitrogen=gmail.com@...> wrote:
>
> Hi,
> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
> I know that in buildroot it is supported.
> Was this discussed and decided against? Is this an open issue?


There’s an open issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434

The easiest implementation would be a rootfs-time postprocessing step where you compile every .py file, and then delete the .py.  Is this what buildroot does?

This does break feeds, but the alternative (of changing how packaging is done) would be a lot more invasive.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: meta-riscv layer *seems* to have broken opensbi_%.bbappend file

Khem Raj
 



On Sun, Jul 10, 2022 at 7:56 AM Robert P. J. Day <rpjday@...> wrote:

  the SRC_URI line:

  SRC_URI:append:nezha = " \ ...

seems odd since the machine name is actually "nezha-allwinner-d1", not
just "nezha". i checked and the two listed patches there don't appear
to be applied, for what i assume is just that reason.

This is a bug and this should be fixed to use full machine name for override since we do not have nezha SoC override


  or is this somehow related to the "nezha.yml" file in the meta-riscv
layer?

No it’s unrelated 



rday




meta-riscv layer *seems* to have broken opensbi_%.bbappend file

Robert P. J. Day
 

the SRC_URI line:

SRC_URI:append:nezha = " \ ...

seems odd since the machine name is actually "nezha-allwinner-d1", not
just "nezha". i checked and the two listed patches there don't appear
to be applied, for what i assume is just that reason.

or is this somehow related to the "nezha.yml" file in the meta-riscv
layer?

rday


Re: Installing gfortran into native sysroot for libgfortran

Philip Balister
 

On 7/8/22 09:12, Khem Raj wrote:
On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@... <mailto:greg@...>> wrote:
On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
>On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
>> Problem solved: the issue was actually that I was using a network
>> sstate cache,
>> and the cached output of gcc-cross did not contain gfortran.
>> Disabling the
>> sstate cache for gcc-cross causes gfortran to be included in the
>> sysroot and
>> now all is working as expected.
>
>You shouldn't have to disable the sstate cache but glad you got it
>working. Which release series is that with?
I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).
Perhaps it’s using locked sstate which might be the reason
It is. It was great fun to find the path to disable it when I also had this issue :)

Philip


[meta-zephyr][PATCH 1/3] qemu-nios2: use glibc

Jon Mason
 

newlib fails to compile for nios2 architecture. Work around this by
using glibc instead.

Signed-off-by: Jon Mason <jon.mason@...>
---
meta-zephyr-bsp/conf/machine/qemu-nios2.conf | 2 ++
meta-zephyr-core/conf/distro/zephyr.conf | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta-zephyr-bsp/conf/machine/qemu-nios2.conf b/meta-zephyr-bsp/conf/machine/qemu-nios2.conf
index de20320..c41f505 100644
--- a/meta-zephyr-bsp/conf/machine/qemu-nios2.conf
+++ b/meta-zephyr-bsp/conf/machine/qemu-nios2.conf
@@ -14,3 +14,5 @@ QB_OPT_APPEND = "-nographic"
QB_CPU = "-cpu nios2"

ARCH:qemu-nios2 = "nios2"
+
+TCLIBC = "glibc"
diff --git a/meta-zephyr-core/conf/distro/zephyr.conf b/meta-zephyr-core/conf/distro/zephyr.conf
index 6ecd421..bdf1821 100644
--- a/meta-zephyr-core/conf/distro/zephyr.conf
+++ b/meta-zephyr-core/conf/distro/zephyr.conf
@@ -4,7 +4,7 @@ DISTRO_VERSION = "1.0"

TARGET_VENDOR = "-yocto"

-TCLIBC = "newlib"
+TCLIBC ?= "newlib"

TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"
--
2.17.1

1181 - 1200 of 58636