1. Yocto
  2. Messages

Expanded

Topics Messages
   Date   
Re: How to contribute to Yocto core ?

Maciej Pijanowski
 

On 4/7/22 00:17, Bel Hadj Salem Talel wrote:
Hello All,
Hello,

I am an experienced Yocto engineer, and I want to contribute to Yocto project (bitbake core, poky layers, etc) but I do not know what to contribute or is there a TODO list that I can help with.
I think you can look through Bugzilla for unassigned tasks [1], for example.

Besides, I have some classes that I can contribute to poky, but I do not know where to commit it.
This one should help on commiting [2]. You should send patches to the
relevant mailing list [3]. For the core, it should be the openembedded-core list [4].

Can anyone help me.

[1] https://wiki.yoctoproject.org/wiki/Bug_Triage
[2] https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
[3] https://www.yoctoproject.org/community/mailing-lists/
[4] https://lists.openembedded.org/g/openembedded-core

Thanks,

Thanks in advance.
Talel

--
Maciej Pijanowski
Engineering Manager
GPG: 9963C36AAC3B2B46
https://3mdeb.com | @3mdeb_com
How to contribute to Yocto core ?

Bel Hadj Salem Talel <bhstalel@...>
 

Hello All,

I am an experienced Yocto engineer, and I want to contribute to Yocto project (bitbake core, poky layers, etc) but I do not know what to contribute or is there a TODO list that I can help with.

Besides, I have some classes that I can contribute to poky, but I do not know where to commit it.

Can anyone help me.

Thanks in advance.
Talel
Re: [Question] How to handle GPLv3 packages?

Mans Zigher <mans.zigher@...>
 

Thanks all for your quick response. You have given me something to
think of so I will look into it to see if some of my issues are
related to the way we have set things up. I will post my findings once
I have gone through your comments to see if we could use it in our
build.

Thanks

Den ons 6 apr. 2022 kl 11:23 skrev <Mikko.Rapeli@...>:


Hi

I set INCOMPATIBLE_LICENSE_append = " GPLv3 GPLv3+ LGPLv3 LGPLv3+"
but then allow compiling several recipes with those licenses as long
as they don't end up on images and in the product. For example:

...
WHITELIST_GPL-3.0+ += "cairo"
PACKAGE_EXCLUDE += "cairo-src cairo-dbg cairo-perf-utils cairo-staticdev cairo-locale"

WHITELIST_GPL-3.0 += "binutils"
PACKAGE_EXCLUDE += "binutils-dbg binutils-staticdev binutils-dev binutils-doc binutils-locale libbfd binutils"

WHITELIST_GPL-3.0 += "gdb"
PACKAGE_EXCLUDE += "gdb-sdktests-dbg gdb-sdktests gdbserver gdb-dbg gdb-staticdev gdb-dev gdb-doc gdb-locale gdb"
...

I do this in the distro config.

Results works but you may need to revisit several recipes and detect where exactly
the GPLv3 license is being used.

bash dependency is annoying but products can be made without. Same for GNU readline
support.

These are much work and better then using meta-gplv2 with its unmaintained SW
versions.

Would be nice to collaborate in yocto upstream on a build config which disables most
GPLv3 packages from rootfs but keeps the development tools etc working in
the SDK.

Cheers,

-Mikko
Re: [Question] How to handle GPLv3 packages?

Mikko Rapeli <mikko.rapeli@...>
 

Hi

I set INCOMPATIBLE_LICENSE_append = " GPLv3 GPLv3+ LGPLv3 LGPLv3+"
but then allow compiling several recipes with those licenses as long
as they don't end up on images and in the product. For example:

...
WHITELIST_GPL-3.0+ += "cairo"
PACKAGE_EXCLUDE += "cairo-src cairo-dbg cairo-perf-utils cairo-staticdev cairo-locale"

WHITELIST_GPL-3.0 += "binutils"
PACKAGE_EXCLUDE += "binutils-dbg binutils-staticdev binutils-dev binutils-doc binutils-locale libbfd binutils"

WHITELIST_GPL-3.0 += "gdb"
PACKAGE_EXCLUDE += "gdb-sdktests-dbg gdb-sdktests gdbserver gdb-dbg gdb-staticdev gdb-dev gdb-doc gdb-locale gdb"
...

I do this in the distro config.

Results works but you may need to revisit several recipes and detect where exactly
the GPLv3 license is being used.

bash dependency is annoying but products can be made without. Same for GNU readline
support.

These are much work and better then using meta-gplv2 with its unmaintained SW
versions.

Would be nice to collaborate in yocto upstream on a build config which disables most
GPLv3 packages from rootfs but keeps the development tools etc working in
the SDK.

Cheers,

-Mikko
Re: [Question] How to handle GPLv3 packages?

Ross Burton <ross@...>
 

On Wed, 6 Apr 2022 at 09:59, Mans Zigher <mans.zigher@...> wrote:
A more specific issue is that there are so many packages with bash
dependencies which are pulling in bash which is GPLv3 so how have you
solved that? Currently we have done some pretty uggly hacks which I am
not that happy with but we needed to keep it out of the image.
As you're not naming recipes it is hard to offer concrete advice, but
I will note that a large percentage of the bash dependencies in
oe-core are specific to the ptest packages. If you don't need those
then you can turn off the ptest DISTRO_FEATURE.

Ross
Re: [Question] How to handle GPLv3 packages?

Alexander Kanavin
 

I'd suggest you start by setting INCOMPATIBLE_LICENSE per image, e.g.
enable gpl3 ban only in the images that ship to the customers and not
across the entire build. Then carefully look at what pulls in bash
into those images and why, and reconfigure those pieces to not do that
(e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the scripts in
posix shell.

Alex

On Wed, 6 Apr 2022 at 10:59, Mans Zigher <mans.zigher@...> wrote:

Hi,

I cannot use GPLv3 packages in our image build. I am no legal expert
but from what I can understand most companies will not be able to
comply with this license without allowing the customer to compile and
deploy a new version of any GPLv3 package to the target. I know it is
possible to comply with this but we are using secure boot and have not
the time and probably no interest in setting up a solution for
allowing customers to be able to deploy GPLv3 packages on the target.
We are trying to make use of INCOMPATIBLE_LICENSE but that results in
several issues. We have made sure that we don't include GPLv3 in the
image build using a manual process but would like to use
INCOMPATIBLE_LICENSE to alert any developer about the issue. It seems
like INCOMPATIBLE_LICENSE is a bit harsh since it will catch any
packages even if it is only part of the SDK and also for native
packages that are not part of the image build.

I cannot be the only one with this problem so how are other companies
solving this issue? Are they just not using the INCOMPATIBLE_LICENSE?
Are you setting up a parallel process for checking for any
incompatible licenses issues?

A more specific issue is that there are so many packages with bash
dependencies which are pulling in bash which is GPLv3 so how have you
solved that? Currently we have done some pretty uggly hacks which I am
not that happy with but we needed to keep it out of the image.

Thanks
[Question] How to handle GPLv3 packages?

Mans Zigher <mans.zigher@...>
 

Hi,

I cannot use GPLv3 packages in our image build. I am no legal expert
but from what I can understand most companies will not be able to
comply with this license without allowing the customer to compile and
deploy a new version of any GPLv3 package to the target. I know it is
possible to comply with this but we are using secure boot and have not
the time and probably no interest in setting up a solution for
allowing customers to be able to deploy GPLv3 packages on the target.
We are trying to make use of INCOMPATIBLE_LICENSE but that results in
several issues. We have made sure that we don't include GPLv3 in the
image build using a manual process but would like to use
INCOMPATIBLE_LICENSE to alert any developer about the issue. It seems
like INCOMPATIBLE_LICENSE is a bit harsh since it will catch any
packages even if it is only part of the SDK and also for native
packages that are not part of the image build.

I cannot be the only one with this problem so how are other companies
solving this issue? Are they just not using the INCOMPATIBLE_LICENSE?
Are you setting up a parallel process for checking for any
incompatible licenses issues?

A more specific issue is that there are so many packages with bash
dependencies which are pulling in bash which is GPLv3 so how have you
solved that? Currently we have done some pretty uggly hacks which I am
not that happy with but we needed to keep it out of the image.

Thanks
QA notification for completed autobuilder build (yocto-4.0.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-4.0.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.0.rc1


Build hash information:

bitbake: 41eeb4f34fb2306303f7688ec5e0ae965a573aa4
meta-agl: fa5152323ad2bd3d433aec72c4fec6614656f06d
meta-arm: 5c83fa83649c522137c96d3c5aab49d660f8807f
meta-aws: 214a5867b3b0d9ba54818aabb1711eadf4ba9eb3
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: 68e00896f2c669044f6ad8cbbc9958332254a4e4
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: 173352732d17b3d1fa469b6eea43a2a3c8a670d3
oecore: 62851965fc180f33ed6feb62ff5ac14706e4732a
poky: ed98f1a1ae7e4e2c8e089003a619ae9260a852ad



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
Re: Wrong file installed when building a machine

Marco Cavallini
 

On Tue, Apr 5, 2022 at 04:38 PM, Rombola Davide wrote:
FILESEXTRAPATHS_prepend_${MACHINE} := "${YOCTOROOT}/meta-a/recipes-my/${PN}/${PN}_rel:"

The following line is sayng that you want to select meta-a when you have a MACHINE = every machine you have therefore machinec

FILESEXTRAPATHS_prepend_${MACHINE} := "${YOCTOROOT}/meta-a/recipes-my/${PN}/${PN}_rel:"

You can read it as 

FILESEXTRAPATHS_prepend_machinec := "${YOCTOROOT}/meta-a/recipes-my/${PN}/${PN}_rel:"

Yocto Project Status WW14`22

Stephen Jolley
 

Current Dev Position: YP 3.5 M4

Next Deadline: 4th April. 2022 YP 3.5 M4 build

 

Next Team Meetings:

 

Key Status/Updates:

  • We will build the first release candidate build for YP 4.0 (3.5) later today.
  • YP 3.4.3 was released
  • YP 3.3.6, the final hardknott release will build after 4.0 rc1.
  • We’re planning to take a couple of further changes (pseudo fix, apt signing minus the test and the unwind sdl workaround) and then call the first release candidate build good.
  • There were a number of good fixes for memory resident bitbake this week and also some interesting and useful fixes for the bitbake parsing process which should avoid lockups in the error case. The hope is these should avoid some of the intermittent issues we’ve been seeing on the autobuilder.
  • An issue with make 4.2.1 on some distros remains, often causing hangs in kernel and perl builds in particular. Help in developing a workaround for this (a make buildtools tarball?) would be appreciated.
  • YP 4.1 planning document is available for review at: https://docs.google.com/document/d/1-g7DatSdmIETwD3xFSCxV7MbWVVkpQvQ788mIr1MPTI/edit?usp=sharing
  • If people see intermittent issues in their own builds, particularly if they’re the same as intermittent issues seen on the autobuilder, please do comment in the bugs mentioning when they happen as the frequency information does help us prioritize fixing the most common issues.
  • Intermittent issues continue to be at high levels and help is very much welcome in trying to resolve them. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We did work out the cause of the infamous tinfoil wait_event intermittent issue.

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.4.3 is released.
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 
[yocto-autobuilder-helper][kirkstone] config.json: move kirkstone sstate to its own directory

Steve Sakoman
 

Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index 4dfc865..e779e0b 100644
--- a/config.json
+++ b/config.json
@@ -30,8 +30,8 @@
"SDKMACHINE" : "i686",
"PACKAGE_CLASSES" : "package_rpm package_deb package_ipk",
"DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'",
- "SSTATEDIR" : ["SSTATE_DIR ?= '${BASE_SHAREDDIR}/pub/sstate'"],
- "SSTATEDIR_RELEASE" : ["SSTATE_MIRRORS += 'file://.* file://${BASE_SHAREDDIR}/pub/sstate/PATH'", "SSTATE_DIR ?= '${BASE_PUBLISHDIR}/sstate/@RELEASENUM@'"],
+ "SSTATEDIR" : ["SSTATE_DIR ?= '${BASE_SHAREDDIR}/pub/sstate-kirkstone'"],
+ "SSTATEDIR_RELEASE" : ["SSTATE_MIRRORS += 'file://.* file://${BASE_SHAREDDIR}/pub/sstate-kirkstone/PATH'", "SSTATE_DIR ?= '${BASE_PUBLISHDIR}/sstate/@RELEASENUM@'"],
"SDKEXTRAS" : ["SSTATE_MIRRORS += '\\", "file://.* http://sstate.yoctoproject.org/dev/@RELEASENUM@PATH;downloadfilename=PATH'", "BB_HASHSERVE = 'auto'"],
"BUILDINFO" : false,
"BUILDHISTORY" : false,
--
2.25.1
Wrong file installed when building a machine

Rombola Davide <davide.rombola@...>
 

I have 3 layers:
meta-a:
meta-a
└── recipes-my
    └── mypgk
        ├── mypgk_1.0.bb
        └── mypkg_rel
            ├── config.conf
            └── mypkg.service
  • mypgk_1.0.bb:
FILESEXTRAPATHS_prepend_$(MACHINE) := "${THISDIR}/${PN}_rel:"

SRC_URI = "file://config.conf "

SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} = " mypkg.service"

do_install() {
         install -m 755 -d ${D}${bindir}
         install -m 755 -d ${D}${sysconfdir}
         install -m 644 ${WORKDIR}/config.conf ${D}${sysconfdir}/config.conf

         install -d ${D}${systemd_system_unitdir}
         install -m 644 ${WORKDIR}/mypkg.service ${D}${systemd_system_unitdir}/mypkg.service
}
meta-b:
meta-b
└── recipes-my
    └── mypgk
        ├── mypgk_1.0.bbappend
        └── mypkg
            └── config.conf
  • mypgk_1.0.bbappend:
FILESEXTRAPATHS_prepend_${MACHINE} := "${YOCTOROOT}/meta-a/recipes-my/${PN}/${PN}_rel:"  
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"  
SRC_URI += "file://config.conf "
I also have a meta-c layer. meta-c/recipes-my doesn't exists, i want to use the meta-b one.
  • meta-c depends on meta-b,
  • meta-b depends on meta-a.
In meta-c layer.conf i have this: 
LAYERDEPENDS_c = "b"

Layers priority:
  • meta-a = 14
  • meta-b = 15
  • meta-c = 16
Every layer defines a machine (machinea, machineb, machinec)
When I build machinea, the config.conf file from meta-a is installed.
When I build machineb, the config.conf file from meta-b is installed.
When I build machinec, the config.conf file from meta-a is installed instead the one in meta-b which have a higher priority.
When I build machinec I want mypkg from meta-b as-is, why bitbake use the other config.conf file?
Also copying recipes-my/* from meta-b to meta-c/ doesn't work and config.conf from meta-a is installed.
If I rename config.conf to config_b.conf (changing .bbappend accordingly) in meta-b everything works as axpected.
[meta-zephyr][PATCH v2] generate-zephyr-machine: add leading whitespace to SRC_URI

Davide Gardenal
 

Signed-off-by: Davide Gardenal <davide.gardenal@...>
---
meta-zephyr-bsp/recipes-meta/meta/generate-zephyr-machines.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-zephyr-bsp/recipes-meta/meta/generate-zephyr-machines.bb b/meta-zephyr-bsp/recipes-meta/meta/generate-zephyr-machines.bb
index b93aa92..30d362c 100644
--- a/meta-zephyr-bsp/recipes-meta/meta/generate-zephyr-machines.bb
+++ b/meta-zephyr-bsp/recipes-meta/meta/generate-zephyr-machines.bb
@@ -8,7 +8,7 @@ inherit ${ZEPHYR_INHERIT_CLASSES}

require recipes-kernel/zephyr-kernel/zephyr-sample.inc

-SRC_URI:append = "file://0001-zephyr-Export-an-OpenEmbedded-machine-config.patch"
+SRC_URI:append = " file://0001-zephyr-Export-an-OpenEmbedded-machine-config.patch"

ZEPHYR_SRC_DIR = "${S}/samples/hello_world"

--
2.32.0
Re: [meta-zephyr][PATCH] zephyr-kernel-src: add whitespace to fix File not found during build

Davide Gardenal
 

Sorry, my bad, I was looking at an older version. I'm sending v2 with the correct source of the problem.

Thanks for the feedback
Re: [meta-zephyr][PATCH] zephyr-kernel-src: add whitespace to fix File not found during build

Naveen Saini
 

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Davide Gardenal
Sent: Monday, April 4, 2022 9:17 PM
To: yocto@...
Cc: Davide Gardenal <davide.gardenal@...>
Subject: [yocto] [meta-zephyr][PATCH] zephyr-kernel-src: add whitespace to
fix File not found during build

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 "
[Naveen] It does not apply. Did you send any patch previously, which I missed ?

https://git.yoctoproject.org/meta-zephyr/tree/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc#n70

--
2.32.0
Enhancements/Bugs closed WW14!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

7

ross@...

2

richard.purdie@...

1

Grand Total

10

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 
Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

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

Who

Count

michael.opdenacker@...

34

ross@...

25

randy.macleod@...

15

bruce.ashfield@...

13

tim.orling@...

12

david.reyna@...

11

richard.purdie@...

11

trevor.gamblin@...

7

mhalstead@...

7

bluelightning@...

6

sakib.sajal@...

6

chee.yang.lee@...

4

hongxu.jia@...

3

JPEWhacker@...

3

kai.kang@...

2

Qi.Chen@...

2

pgowda.cve@...

2

saul.wold@...

2

mshah@...

2

akuster808@...

2

jon.mason@...

1

mostthingsweb@...

1

alexandre.belloni@...

1

yi.zhao@...

1

sundeep.kokkonda@...

1

pokylinux@...

1

pavel@...

1

raj.khem@...

1

andrei@...

1

aehs29@...

1

thomas.perrot@...

1

matthewzmd@...

1

TicoTimo@...

1

nicolas.dechesne@...

1

jaskij@...

1

mark.hatle@...

1

open.source@...

1

john.kaldas.enpj@...

1

alejandro@...

1

Grand Total

188

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
3481 - 3500 of 60111