Date   

Re: How can I create a truly minimal distribution that runs entirely from RAM?

Joshua Watt
 


On 3/14/21 6:16 PM, p32 via lists.yoctoproject.org wrote:
Thank you very much. I figured out that you can have Yocto create a suitable U-Boot wrapper as follows (from the image recipe):
IMAGE_FSTYPES = "cpio.xz.u-boot"

Now there is only one last issue that I wasn't able to solve yet: I would like Yocto to not only generate this U-Boot file but also add it to the boot partition of a wic.gz image. I tried to extend the image recipe as follows:
IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
IMAGE_BOOT_FILES_append += "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"

Unfortunately, there is a dependency issue here. BitBake schedules the do_image_wic task before the do_image_cpio task, which creates the u-boot file. I tried to fix it as follows (from the image recipe):
do_image_wic[depends] = "my-image-recipe:do_image_cpio"

While the dependency graph acknowledges this dependency, BitBake does not seem to care about it. Whatever I try, do_image_wic is always executed first and, obviously, does not succeed. I think the problem is comparable to the unsolved one outlined here:
https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image

How can I instruct Yocto to execute do_image_cpio first?

You might try splitting it up with two images; one that makes your CPIO and one that makes the wic image. Since the wic image (presumably?) doesn't even have the rootfs specified, it probably doesn't even matter what the image is (e.g. you could use core-image-minimal as a test, or try to make some even slimmer empty image).

I think by doing that you could do something like:

 IMAGE_BOOT_FILES += "my-cpio-image.cpio.xz.u-boot"

 IMAGE_FILE_DEPENDS += "my-cpio-image"

Then:

 bitbake core-image-minimal

Would sort of do what you are asking

I think they key is that you need a "root file system image" that is *not* your CPIO because wic expects to be tied to one that it can write to the .wic image, even if thats not actually what you are doing.





Re: How can I create a truly minimal distribution that runs entirely from RAM?

Richard Purdie
 

On Mon, 2021-03-15 at 17:01 +0100, Zoran wrote:
How can I instruct Yocto to execute do_image_cpio first?
YOCTO people are entitled to answer that question. Aren't ya, INTEL folks???

Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is
90% from INTEL), and I assume INTEL YOCTO people are entitled
answering that///
For the record and for the alleviation of any doubt, Intel was one of 
a group of founders of the project and continues to be a valued 
contributor but has never been 90% of the project. Intel has reduced
its involvement more recently both in Yocto Project and in other open source
efforts as it's focus has changed over time. Many of the people who
did work for Intel and contributed to the project now work for different
organisations but still contribute, Ross and myself included.

I'd *strongly* suggest sticking to technical discussion rather than
directing comments at any specific company in future. Your comments are
confusing and off putting for people.

Cheers,

Richard


M+ & H bugs with Milestone Movements WW11

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5322

Global DNS fallback mechanism not present in poky distro

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

11766

nobody group added by systemd sysusers.d

yi.zhao@...

yi.zhao@...

3.3 M3

3.3 M4

 

11906

rpmbuild: Can not build packages on qemu target

randy.macleod@...

hongxu.jia@...

3.3 M4

3.4 M1

 

 

hongxu.jia@...

hongxu.jia@...

3.3 M3

3.3 M4

 

12279

enhance manifest not found warning

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

12342

lib32-core-image-sato -ctestimage failed due to wrong package names

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.3 M3

3.3 M4

 

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

13008

toaster testing

david.reyna@...

david.reyna@...

3.3 M3

3.4

 

13109

Implement CPE to package to Release mapping

david.reyna@...

david.reyna@...

3.3 M3

3.4

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.3 M3

3.3 M4

 

13182

Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx failed

randy.macleod@...

Qi.Chen@...

3.4

3.4 M2

 

 

Qi.Chen@...

Qi.Chen@...

3.3 M3

3.4

 

13306

bitbake starts up to n^2 processes with n cpus

liezhi.yang@...

liezhi.yang@...

3.3 M4

Future

 

 

 

 

3.3 M3

3.3 M4

 

 

randy.macleod@...

liezhi.yang@...

Future

3.99

 

13311

xargs: fdleak.c:396: complain_about_leaky_fds: Assertion `no_leaks' failed.

randy.macleod@...

mingli.yu@...

3.4

3.3 M4

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.3 M3

3.4

 

13674

master dnf failures on qemumips

randy.macleod@...

mingli.yu@...

3.4

3.4 M1

 

14020

environment-setup script in multilib eSDK doesn't work for multilib variant

liezhi.yang@...

liezhi.yang@...

3.3 M3

3.3 M4

 

14041

qemuarm-alt  failed to load rpcbind

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

14085

Toaster UI should know when bitbake crashed

david.reyna@...

david.reyna@...

3.3 M3

3.3 M4

 

14117

When ifupdown ist configured for DHCP with IPv6 the system boot hangs

yi.zhao@...

yi.zhao@...

3.3 M3

3.4 M4

 

14118

systemd services not enabled when using package feed

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

14152

cups: under systemd needs to use /run/cups as rundir

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

 

14177

tcl ptest intermittent failure

randy.macleod@...

mingli.yu@...

3.4

3.4 M1

 

14214

rpm-native: do_configure failed

hongxu.jia@...

hongxu.jia@...

3.3 M3

3.3 M4

 

14250

core-image-sato.bb:do_testimage failure at systemd.SystemdBasicTests.test_systemd_failed

kai.kang@...

kai.kang@...

3.3 M3

3.3 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW11!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

4

alexandre.belloni@...

3

richard.purdie@...

3

ross@...

1

kory.maincent@...

1

bruce.ashfield@...

1

Grand Total

13

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

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

30

ross@...

25

bluelightning@...

15

JPEWhacker@...

10

bruce.ashfield@...

8

mark.morton@...

7

raj.khem@...

6

chee.yang.lee@...

6

akuster808@...

5

sakib.sajal@...

5

trevor.gamblin@...

4

Qi.Chen@...

4

idadelm@...

4

timothy.t.orling@...

3

randy.macleod@...

3

mostthingsweb@...

3

matthewzmd@...

2

jaewon@...

2

stacygaikovaia@...

2

limon.anibal@...

2

jeanmarie.lemetayer@...

2

ydirson@...

2

nicolas.dechesne@...

2

pokylinux@...

2

alejandro@...

2

jon.mason@...

2

kexin.hao@...

1

anuj.mittal@...

1

charles.davies@...

1

open.source@...

1

mhalstead@...

1

twoerner@...

1

yifan.yu@...

1

kergoth@...

1

dl9pf@...

1

Martin.Jansa@...

1

dorindabassey@...

1

john.kaldas.enpj@...

1

shachar@...

1

steve@...

1

mister_rs@...

1

mark.hatle@...

1

yoctoproject@...

1

matt.ranostay@...

1

victor.kamensky7@...

1

aehs29@...

1

hongxu.jia@...

1

mshah@...

1

Grand Total

180

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 364 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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

 


Re: How can I create a truly minimal distribution that runs entirely from RAM?

Zoran
 

Please be aware that this is a community mailing list for the Yocto
Project, and we expect everyone to be as pleasant as possible
I don't think the tone of your last email is appropriate for our
mailing lists.
Unfortunately, Nicolas, you are barking under the wrong tree.

Please, go to Ross Burton, bark there, and align the (?) views (nothing against
your attack against me).

Thank you,
Zoran Stojsavljevic
_______

On Mon, Mar 15, 2021 at 6:21 PM Nicolas Dechesne
<nicolas.dechesne@...> wrote:

hey Zoran,


On Mon, Mar 15, 2021 at 5:01 PM Zoran <zoran.stojsavljevic@...> wrote:

How can I instruct Yocto to execute do_image_cpio first?
YOCTO people are entitled to answer that question. Aren't ya, INTEL folks???

Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is
90% from INTEL), and I assume INTEL YOCTO people are entitled
answering that///
Please be aware that this is a community mailing list for the Yocto
Project, and we expect everyone to be as pleasant as possible. I don't
think the tone of your last email is appropriate for our mailing
lists. Please refrain yourself from such claims, or we will need to
use moderation. Let's make sure our discussions are about technical
content and in case of any doubt, please refer to our CoC, at
https://www.yoctoproject.org/community/code-of-conduct/.



Thank you,
Zee (Zoran)
_______

On Mon, Mar 15, 2021 at 12:17 AM p32 via lists.yoctoproject.org
<p32=tuta.io@...> wrote:

Thank you very much. I figured out that you can have Yocto create a suitable U-Boot wrapper as follows (from the image recipe):
IMAGE_FSTYPES = "cpio.xz.u-boot"

Now there is only one last issue that I wasn't able to solve yet: I would like Yocto to not only generate this U-Boot file but also add it to the boot partition of a wic.gz image. I tried to extend the image recipe as follows:
IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
IMAGE_BOOT_FILES_append += "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"

Unfortunately, there is a dependency issue here. BitBake schedules the do_image_wic task before the do_image_cpio task, which creates the u-boot file. I tried to fix it as follows (from the image recipe):
do_image_wic[depends] = "my-image-recipe:do_image_cpio"

While the dependency graph acknowledges this dependency, BitBake does not seem to care about it. Whatever I try, do_image_wic is always executed first and, obviously, does not succeed. I think the problem is comparable to the unsolved one outlined here:
https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image

How can I instruct Yocto to execute do_image_cpio first?




Re: How can I create a truly minimal distribution that runs entirely from RAM?

Zoran
 

I can tell you... Ross!

Please, focus on The Problem. Could you, please???

Since, I, an independent entity, am trying to help the people!

OK? Since I do not care about political IOTG development, rather than
on overall (NOT INTEL) resolution of the problem?!

Do you understand the core of the problem (since I am the only one
trying to help here)???

Or do I need to explain it more to (you and INTEL) the ground???

Did you contribute to the solution of the problem??? Or you need salt
and pepper from me?

Do you get it???

Thank you for understanding,
Zoran Stojsavljevic
_______


Re: How can I create a truly minimal distribution that runs entirely from RAM?

Nicolas Dechesne
 

hey Zoran,


On Mon, Mar 15, 2021 at 5:01 PM Zoran <zoran.stojsavljevic@...> wrote:

How can I instruct Yocto to execute do_image_cpio first?
YOCTO people are entitled to answer that question. Aren't ya, INTEL folks???

Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is
90% from INTEL), and I assume INTEL YOCTO people are entitled
answering that///
Please be aware that this is a community mailing list for the Yocto
Project, and we expect everyone to be as pleasant as possible. I don't
think the tone of your last email is appropriate for our mailing
lists. Please refrain yourself from such claims, or we will need to
use moderation. Let's make sure our discussions are about technical
content and in case of any doubt, please refer to our CoC, at
https://www.yoctoproject.org/community/code-of-conduct/.



Thank you,
Zee (Zoran)
_______

On Mon, Mar 15, 2021 at 12:17 AM p32 via lists.yoctoproject.org
<p32=tuta.io@...> wrote:

Thank you very much. I figured out that you can have Yocto create a suitable U-Boot wrapper as follows (from the image recipe):
IMAGE_FSTYPES = "cpio.xz.u-boot"

Now there is only one last issue that I wasn't able to solve yet: I would like Yocto to not only generate this U-Boot file but also add it to the boot partition of a wic.gz image. I tried to extend the image recipe as follows:
IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
IMAGE_BOOT_FILES_append += "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"

Unfortunately, there is a dependency issue here. BitBake schedules the do_image_wic task before the do_image_cpio task, which creates the u-boot file. I tried to fix it as follows (from the image recipe):
do_image_wic[depends] = "my-image-recipe:do_image_cpio"

While the dependency graph acknowledges this dependency, BitBake does not seem to care about it. Whatever I try, do_image_wic is always executed first and, obviously, does not succeed. I think the problem is comparable to the unsolved one outlined here:
https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image

How can I instruct Yocto to execute do_image_cpio first?




Re: How can I create a truly minimal distribution that runs entirely from RAM?

Zoran
 

How can I instruct Yocto to execute do_image_cpio first?
YOCTO people are entitled to answer that question. Aren't ya, INTEL folks???

Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is
90% from INTEL), and I assume INTEL YOCTO people are entitled
answering that///

Thank you,
Zee (Zoran)
_______

On Mon, Mar 15, 2021 at 12:17 AM p32 via lists.yoctoproject.org
<p32=tuta.io@...> wrote:

Thank you very much. I figured out that you can have Yocto create a suitable U-Boot wrapper as follows (from the image recipe):
IMAGE_FSTYPES = "cpio.xz.u-boot"

Now there is only one last issue that I wasn't able to solve yet: I would like Yocto to not only generate this U-Boot file but also add it to the boot partition of a wic.gz image. I tried to extend the image recipe as follows:
IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
IMAGE_BOOT_FILES_append += "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"

Unfortunately, there is a dependency issue here. BitBake schedules the do_image_wic task before the do_image_cpio task, which creates the u-boot file. I tried to fix it as follows (from the image recipe):
do_image_wic[depends] = "my-image-recipe:do_image_cpio"

While the dependency graph acknowledges this dependency, BitBake does not seem to care about it. Whatever I try, do_image_wic is always executed first and, obviously, does not succeed. I think the problem is comparable to the unsolved one outlined here:
https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image

How can I instruct Yocto to execute do_image_cpio first?



Re: [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report

Milan Shah
 

Hi,

Review reminder for [YOCTO #9700].


Thanks & Regards,
Milan Shah

Milan Shah | Software Engineer
a: MontaVista Software, LLC | Bangalore, India
e: info@... | w: www.mvista.com/
p: +91-80-4939-5000


On Tue, Feb 23, 2021 at 3:21 PM Milan Shah <mshah@...> wrote:
Hi All,

This has not been reviewed yet and it is given since January 6th.
Please review it and provide review comments if any as soon as possible to resolve this issue.

Thanks & Regards,
Milan Shah

Milan Shah | Software Engineer
a: MontaVista Software, LLC | Bangalore, India
e: info@... | w: www.mvista.com/
p: +91-80-4939-5000


On Mon, Feb 1, 2021 at 10:06 AM Milan Shah <mshah@...> wrote:
Hi All,

A gentle reminder to review this patch.

-----------------------
Thanks & Regards,
Milan Shah
MontaVista Software, Bangalore, India


On Mon, Jan 11, 2021 at 6:45 PM Milan Shah <mshah@...> wrote:
Hi All,

This is a Gentle Reminder to review this Patch.

-----------------------
Thanks & Regards,
Milan Shah
MontaVista Software, Bangalore, India


On Wed, Jan 6, 2021 at 7:09 PM Milan Shah <mshah@...> wrote:
Instead of just providing local.conf info, add layer names and their
revisions with bitbake version information into error report
makes it easier to understand and reproduce failed build.

[YOCTO #9700]

Signed-off-by: Milan Shah <mshah@...>
---
 meta/classes/report-error.bbclass | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/report-error.bbclass b/meta/classes/report-error.bbclass
index 1a12db1..9cb6b0b 100644
--- a/meta/classes/report-error.bbclass
+++ b/meta/classes/report-error.bbclass
@@ -6,6 +6,8 @@
 #
 # Licensed under the MIT license, see COPYING.MIT for details

+inherit base
+
 ERR_REPORT_DIR ?= "${LOG_DIR}/error-report"

 def errorreport_getdata(e):
@@ -64,6 +66,8 @@ python errorreport_handler () {
             data['failures'] = []
             data['component'] = " ".join(e.getPkgs())
             data['branch_commit'] = str(base_detect_branch(e.data)) + ": " + str(base_detect_revision(e.data))
+            data['bitbake_version'] = e.data.getVar("BB_VERSION")
+            data['layer_version'] = get_layers_branch_rev(e.data)
             data['local_conf'] = get_conf_data(e, 'local.conf')
             data['auto_conf'] = get_conf_data(e, 'auto.conf')
             lock = bb.utils.lockfile(datafile + '.lock')
--
2.7.4


Re: How can I create a truly minimal distribution that runs entirely from RAM?

p32@...
 

Thank you very much. I figured out that you can have Yocto create a suitable U-Boot wrapper as follows (from the image recipe):
IMAGE_FSTYPES = "cpio.xz.u-boot"

Now there is only one last issue that I wasn't able to solve yet: I would like Yocto to not only generate this U-Boot file but also add it to the boot partition of a wic.gz image. I tried to extend the image recipe as follows:
IMAGE_FSTYPES = "cpio.xz.u-boot wic.gz"
IMAGE_BOOT_FILES_append += "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cpio.xz.u-boot"

Unfortunately, there is a dependency issue here. BitBake schedules the do_image_wic task before the do_image_cpio task, which creates the u-boot file. I tried to fix it as follows (from the image recipe):
do_image_wic[depends] = "my-image-recipe:do_image_cpio"

While the dependency graph acknowledges this dependency, BitBake does not seem to care about it. Whatever I try, do_image_wic is always executed first and, obviously, does not succeed. I think the problem is comparable to the unsolved one outlined here:
https://stackoverflow.com/questions/58954170/yocto-creating-a-dependency-for-wic-to-cpio-gz-image

How can I instruct Yocto to execute do_image_cpio first?


Re: How can I create a truly minimal distribution that runs entirely from RAM?

Zoran
 

1. have Yocto generate an initramfs.cpio.xz.uboot file
instead of just an initramfs.cpio.xz file and to
I assume this is not too hard to achieve. Somewhere in some bitbake
config file this should be added, but either me do not know that.

So, we'll both wait for this info, maybe some new variable should be
defined for such cases as initramfs, for YOCTO build system to
generate.

For example, adding INITRAMFS_CONF = "1" into local.conf (initially
this variable should be set to INITRAMFS_CONF ??= "0") in some YOCTO
defconfig file?!

2. modify the default environment that Yocto will
compile into the U-Boot binary?
This, I believe, is achievable by the following steps:

1. Taking/cloning last U-Boot from denx git;
2. Modifying the ./include/configs/<board.h> file, introducing
the following:

#ifdef CONFIG_SUPPORT_INITRAMFS_BOOT
#define INITRAMFS_ENV \
<place here modified by you initramfs ash script>
#else
#define INITRAMFS_ENV ""
#endif

3. Compile U-boot, place it on SDcard and test, to see if you
are able to make it work after rebooting the system;
4. tar again U-Boot source code with these changes, and upload
it on your server;
5. Change the U-boot recipe to be downloaded from your server!

Another approach I do not know (maybe YOCTO people do know a better
approach from inside the YOCTO build system).

Hope this helps.

Zoran
_______


On Fri, Mar 12, 2021 at 10:49 PM p32 via lists.yoctoproject.org
<p32=tuta.io@...> wrote:

Thank you very much for your help on the second issue! I was unaware of the fact that another mkimage call is necessary. After taking a look at the the references you provided, I was able to boot the system from an initramfs.

However, my current approach requires two manual steps after running Yocto: I need to call mkimage on the cpio.xz file and to extend/configure the U-Boot environment in the running system. Is there a way to automate this?

More specifically, is it possible to...

have Yocto generate an initramfs.cpio.xz.uboot file instead of just an initramfs.cpio.xz file and to
modify the default environment that Yocto will compile into the U-Boot binary?




[meta-selinux][PATCH 16/16] setools: upgrade 4.3.0 -> 4.4.0

Yi Zhao
 

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../setools/{setools_4.3.0.bb => setools_4.4.0.bb} | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
rename recipes-security/setools/{setools_4.3.0.bb => setools_4.4.0.bb} (89%)

diff --git a/recipes-security/setools/setools_4.3.0.bb b/recipes-security/setools/setools_4.4.0.bb
similarity index 89%
rename from recipes-security/setools/setools_4.3.0.bb
rename to recipes-security/setools/setools_4.4.0.bb
index 0f166c8..4dd094f 100644
--- a/recipes-security/setools/setools_4.3.0.bb
+++ b/recipes-security/setools/setools_4.4.0.bb
@@ -11,11 +11,11 @@ LICENSE = "GPLv2 & LGPLv2.1"
BBCLASSEXTEND = "native nativesdk "

S = "${WORKDIR}/git"
-SRC_URI = "git://github.com/SELinuxProject/${BPN}.git;branch=4.3 \
+SRC_URI = "git://github.com/SELinuxProject/${BPN}.git;branch=4.4 \
file://setools4-fixes-for-cross-compiling.patch \
"

-SRCREV = "a57ad3cdb669a39f785c4e85d63416a469c8d445"
+SRCREV = "4758cdf803d93274f49cb6445cb2bab527d6549f"

LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=83a5eb6974c11f30785e90d0eeccf40c \
file://${S}/COPYING.GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
@@ -30,8 +30,6 @@ RDEPENDS_${PN} += "python3-networkx python3-decorator python3-setuptools \

RDEPENDS_${PN}_class-native = ""

-CFLAGS_append = " -Wno-deprecated-declarations"
-
RPROVIDES_${PN} += "${PN}-console"

inherit setuptools3
--
2.25.1


[meta-selinux][PATCH 15/16] semodule-utils: update to 3.2

Yi Zhao
 

Merge inc file into bb file.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/semodule-utils_3.1.bb | 7 -------
.../selinux/{semodule-utils.inc => semodule-utils_3.2.bb} | 7 ++++++-
2 files changed, 6 insertions(+), 8 deletions(-)
delete mode 100644 recipes-security/selinux/semodule-utils_3.1.bb
rename recipes-security/selinux/{semodule-utils.inc => semodule-utils_3.2.bb} (83%)

diff --git a/recipes-security/selinux/semodule-utils_3.1.bb b/recipes-security/selinux/semodule-utils_3.1.bb
deleted file mode 100644
index 02a63f8..0000000
--- a/recipes-security/selinux/semodule-utils_3.1.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20200710.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "d9520d0cdef3d1be412155dc72ec2936"
-SRC_URI[sha256sum] = "0cc37f9cec751d9c2abb5f2b228b060567e973cb47c19b53b8a4a7378baaa853"
diff --git a/recipes-security/selinux/semodule-utils.inc b/recipes-security/selinux/semodule-utils_3.2.bb
similarity index 83%
rename from recipes-security/selinux/semodule-utils.inc
rename to recipes-security/selinux/semodule-utils_3.2.bb
index 23cbd14..7773d5b 100644
--- a/recipes-security/selinux/semodule-utils.inc
+++ b/recipes-security/selinux/semodule-utils_3.2.bb
@@ -2,20 +2,25 @@ SUMMARY = "Utilities to manipulate SELinux policy module package"
DESCRIPTION = "\
The utilities to create, expand, link and show the dependencies between \
the SELinux policy module packages."
-
SECTION = "base"
LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"
+
+require selinux_common.inc

DEPENDS += "libsepol"
RDEPENDS_${PN}-dev = ""

EXTRA_OEMAKE += "LIBSEPOLA=${STAGING_LIBDIR}/libsepol.a"

+S = "${WORKDIR}/git/semodule-utils"
+
PACKAGES =+ "\
${PN}-semodule-expand \
${PN}-semodule-link \
${PN}-semodule-package \
"
+
FILES_${PN}-semodule-expand += "${bindir}/semodule_expand"
FILES_${PN}-semodule-link += "${bindir}/semodule_link"
FILES_${PN}-semodule-package += "\
--
2.25.1


[meta-selinux][PATCH 14/16] selinux-sandbox: update to 3.2

Yi Zhao
 

Merge inc file into bb file.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-sandbox_3.1.bb | 7 -------
.../{selinux-sandbox.inc => selinux-sandbox_3.2.bb} | 9 ++++++---
2 files changed, 6 insertions(+), 10 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-sandbox_3.1.bb
rename recipes-security/selinux/{selinux-sandbox.inc => selinux-sandbox_3.2.bb} (77%)

diff --git a/recipes-security/selinux/selinux-sandbox_3.1.bb b/recipes-security/selinux/selinux-sandbox_3.1.bb
deleted file mode 100644
index 8a95044..0000000
--- a/recipes-security/selinux/selinux-sandbox_3.1.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20200710.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "d38fda12b028c06f751be9c25e309c6b"
-SRC_URI[sha256sum] = "c79b958e2f64570a59e60638fd13c15fd77c7c2bbac31c7ad4afb03718432b84"
diff --git a/recipes-security/selinux/selinux-sandbox.inc b/recipes-security/selinux/selinux-sandbox_3.2.bb
similarity index 77%
rename from recipes-security/selinux/selinux-sandbox.inc
rename to recipes-security/selinux/selinux-sandbox_3.2.bb
index c8e335a..2c6a823 100644
--- a/recipes-security/selinux/selinux-sandbox.inc
+++ b/recipes-security/selinux/selinux-sandbox_3.2.bb
@@ -3,12 +3,15 @@ DESCRIPTION = "\
Run application within a tightly confined SELinux domain. The default \
sandbox domain only allows applications the ability to read and write \
stdin, stdout and any other file descriptors handed to it."
-
SECTION = "base"
LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"

-SRC_URI += "file://sandbox-de-bashify.patch \
-"
+require selinux_common.inc
+
+SRC_URI += "file://sandbox-de-bashify.patch"
+
+S = "${WORKDIR}/git/sandbox"

DEPENDS += "libcap-ng libselinux"

--
2.25.1


[meta-selinux][PATCH 13/16] selinux-gui: update to 3.2

Yi Zhao
 

Merge inc file into bb file.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-gui_3.1.bb | 7 -------
.../selinux/{selinux-gui.inc => selinux-gui_3.2.bb} | 6 +++++-
2 files changed, 5 insertions(+), 8 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-gui_3.1.bb
rename recipes-security/selinux/{selinux-gui.inc => selinux-gui_3.2.bb} (75%)

diff --git a/recipes-security/selinux/selinux-gui_3.1.bb b/recipes-security/selinux/selinux-gui_3.1.bb
deleted file mode 100644
index 3038ebc..0000000
--- a/recipes-security/selinux/selinux-gui_3.1.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20200710.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "1e0ea65dfb2b5408969bbe55f6f9d04e"
-SRC_URI[sha256sum] = "40775eaef965259ca2f8ad49c23b03ff2c8f70808a9e0587b1075970b2509c3d"
diff --git a/recipes-security/selinux/selinux-gui.inc b/recipes-security/selinux/selinux-gui_3.2.bb
similarity index 75%
rename from recipes-security/selinux/selinux-gui.inc
rename to recipes-security/selinux/selinux-gui_3.2.bb
index 725eb23..5818e49 100644
--- a/recipes-security/selinux/selinux-gui.inc
+++ b/recipes-security/selinux/selinux-gui_3.2.bb
@@ -2,9 +2,13 @@ SUMMARY = "SELinux GUI tools"
DESCRIPTION = "\
Provide SELinux Management tool (system-config-selinux) and SELinux \
Policy Generation Tool (selinux-polgengui)"
-
SECTION = "base"
LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"
+
+require selinux_common.inc
+
+S = "${WORKDIR}/git/gui"

RDEPENDS_${PN} += "python3-core"

--
2.25.1


[meta-selinux][PATCH 12/16] selinux-dbus: update to 3.2

Yi Zhao
 

Merge inc file into bb file.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-dbus_3.1.bb | 7 -------
.../selinux/{selinux-dbus.inc => selinux-dbus_3.2.bb} | 6 +++++-
2 files changed, 5 insertions(+), 8 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-dbus_3.1.bb
rename recipes-security/selinux/{selinux-dbus.inc => selinux-dbus_3.2.bb} (75%)

diff --git a/recipes-security/selinux/selinux-dbus_3.1.bb b/recipes-security/selinux/selinux-dbus_3.1.bb
deleted file mode 100644
index 04e7565..0000000
--- a/recipes-security/selinux/selinux-dbus_3.1.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20200710.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "b6ad8b3d8497782c6ed480514dfc8ee8"
-SRC_URI[sha256sum] = "61f936d200ff8302c513883c67bb7c4c496513e78122954cbd33db62086a06f2"
diff --git a/recipes-security/selinux/selinux-dbus.inc b/recipes-security/selinux/selinux-dbus_3.2.bb
similarity index 75%
rename from recipes-security/selinux/selinux-dbus.inc
rename to recipes-security/selinux/selinux-dbus_3.2.bb
index 62e45b7..bc34f89 100644
--- a/recipes-security/selinux/selinux-dbus.inc
+++ b/recipes-security/selinux/selinux-dbus_3.2.bb
@@ -1,9 +1,13 @@
SUMMARY = "SELinux dbus service files"
DESCRIPTION = "\
Provide SELinux dbus service files and scripts."
-
SECTION = "base"
LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"
+
+require selinux_common.inc
+
+S = "${WORKDIR}/git/dbus"

RDEPENDS_${PN} += "python3-core selinux-python-sepolicy"

--
2.25.1


[meta-selinux][PATCH 11/16] selinux-python: update to 3.2

Yi Zhao
 

Merge inc file into bb file.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../selinux/selinux-python_3.1.bb | 7 -------
...linux-python.inc => selinux-python_3.2.bb} | 20 +++++++++++--------
2 files changed, 12 insertions(+), 15 deletions(-)
delete mode 100644 recipes-security/selinux/selinux-python_3.1.bb
rename recipes-security/selinux/{selinux-python.inc => selinux-python_3.2.bb} (89%)

diff --git a/recipes-security/selinux/selinux-python_3.1.bb b/recipes-security/selinux/selinux-python_3.1.bb
deleted file mode 100644
index a0555d2..0000000
--- a/recipes-security/selinux/selinux-python_3.1.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20200710.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "ec75687b680e0dd63e3ded05bd41cb5a"
-SRC_URI[sha256sum] = "f4d0a1a030bc291a6af498b26e0676b745075dd289a8ba16cdec86c3ea8f2f02"
diff --git a/recipes-security/selinux/selinux-python.inc b/recipes-security/selinux/selinux-python_3.2.bb
similarity index 89%
rename from recipes-security/selinux/selinux-python.inc
rename to recipes-security/selinux/selinux-python_3.2.bb
index 827fa8b..a827a90 100644
--- a/recipes-security/selinux/selinux-python.inc
+++ b/recipes-security/selinux/selinux-python_3.2.bb
@@ -2,14 +2,20 @@ SUMMARY = "Python modules and various SELinux utilities."
DESCRIPTION = "\
This package contains Python modules sepolgen, sepolicy; And the \
SELinux utilities audit2allow, chcat, semanage ..."
-
SECTION = "base"
LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"

-SRC_URI += "file://fix-sepolicy-install-path.patch"
+require selinux_common.inc

inherit python3native

+SRC_URI += "file://fix-sepolicy-install-path.patch"
+
+S = "${WORKDIR}/git/python"
+
+EXTRA_OEMAKE += "LIBSEPOLA=${STAGING_LIBDIR}/libsepol.a"
+
DEPENDS += "python3 libsepol libselinux"
RDEPENDS_${BPN}-audit2allow += "\
python3-core \
@@ -97,11 +103,9 @@ FILES_${PN} += "\
${libdir}/python${PYTHON_BASEVERSION}/site-packages/sepolicy/* \
"

-EXTRA_OEMAKE += "LIBSEPOLA=${STAGING_LIBDIR}/libsepol.a"
-
do_install() {
- oe_runmake DESTDIR="${D}" \
- PYLIBVER='python${PYTHON_BASEVERSION}' \
- PYTHONLIBDIR='${libdir}/python${PYTHON_BASEVERSION}/site-packages' \
- install
+ oe_runmake DESTDIR="${D}" \
+ PYLIBVER='python${PYTHON_BASEVERSION}' \
+ PYTHONLIBDIR='${libdir}/python${PYTHON_BASEVERSION}/site-packages' \
+ install
}
--
2.25.1


[meta-selinux][PATCH 10/16] restorecond: update to 3.2

Yi Zhao
 

* Merge inc file into bb file.
* Drop obsolete patches:
policycoreutils-make-O_CLOEXEC-optional.patch

Signed-off-by: Yi Zhao <yi.zhao@...>
---
...icycoreutils-make-O_CLOEXEC-optional.patch | 48 -------------------
recipes-security/selinux/restorecond_3.1.bb | 7 ---
.../{restorecond.inc => restorecond_3.2.bb} | 7 +--
3 files changed, 4 insertions(+), 58 deletions(-)
delete mode 100644 recipes-security/selinux/restorecond/policycoreutils-make-O_CLOEXEC-optional.patch
delete mode 100644 recipes-security/selinux/restorecond_3.1.bb
rename recipes-security/selinux/{restorecond.inc => restorecond_3.2.bb} (88%)

diff --git a/recipes-security/selinux/restorecond/policycoreutils-make-O_CLOEXEC-optional.patch b/recipes-security/selinux/restorecond/policycoreutils-make-O_CLOEXEC-optional.patch
deleted file mode 100644
index 83250eb..0000000
--- a/recipes-security/selinux/restorecond/policycoreutils-make-O_CLOEXEC-optional.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From 4adc1c02e4da42f64249c05534875e732f043693 Mon Sep 17 00:00:00 2001
-From: Joe MacDonald <joe_macdonald@...>
-Date: Wed, 6 Nov 2019 23:17:50 +0800
-Subject: [PATCH] policycoreutils: make O_CLOEXEC optional
-
-Various commits in the selinux tree in the current release added
-O_CLOEXEC to open() calls in an attempt to address file descriptor leaks
-as described:
-
- http://danwalsh.livejournal.com/53603.html
-
-However O_CLOEXEC isn't available on all platforms, so make it a
-compile-time option and generate a warning when it is not available.
-The actual impact of leaking these file descriptors is minimal, though
-it does produce curious AVC Denied messages.
-
-Upstream-Status: Inappropriate
-[O_CLOEXEC has been in Linux since 2007 and POSIX since 2008]
-
-Signed-off-by: Joe MacDonald <joe.macdonald@...>
-Signed-off-by: Wenzong Fan <wenzong.fan@...>
-Signed-off-by: Yi Zhao <yi.zhao@...>
----
- user.c | 8 +++++++-
- 1 file changed, 7 insertions(+), 1 deletion(-)
-
-diff --git a/user.c b/user.c
-index 714aae7..bbf018e 100644
---- a/user.c
-+++ b/user.c
-@@ -202,7 +202,13 @@ static int local_server(void) {
- perror("asprintf");
- return -1;
- }
-- local_lock_fd = open(ptr, O_CREAT | O_WRONLY | O_NOFOLLOW | O_CLOEXEC, S_IRUSR | S_IWUSR);
-+ local_lock_fd = open(ptr, O_CREAT | O_WRONLY | O_NOFOLLOW
-+ #ifdef O_CLOEXEC
-+ | O_CLOEXEC
-+ #else
-+ #warning O_CLOEXEC undefined on this platform, this may leak file descriptors
-+ #endif
-+ , S_IRUSR | S_IWUSR);
- if (debug_mode)
- g_warning ("Lock file: %s", ptr);
-
---
-2.7.4
-
diff --git a/recipes-security/selinux/restorecond_3.1.bb b/recipes-security/selinux/restorecond_3.1.bb
deleted file mode 100644
index d4e0d06..0000000
--- a/recipes-security/selinux/restorecond_3.1.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require selinux_20200710.inc
-require ${BPN}.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
-
-SRC_URI[md5sum] = "8daf761739a150a7a29bb491726a6cd9"
-SRC_URI[sha256sum] = "82ca45099685a45d718f11f8859963c1ba83d98e510312cbf0b7dc5664c60ad0"
diff --git a/recipes-security/selinux/restorecond.inc b/recipes-security/selinux/restorecond_3.2.bb
similarity index 88%
rename from recipes-security/selinux/restorecond.inc
rename to recipes-security/selinux/restorecond_3.2.bb
index a5b1635..d9def9a 100644
--- a/recipes-security/selinux/restorecond.inc
+++ b/recipes-security/selinux/restorecond_3.2.bb
@@ -4,12 +4,11 @@ The restorecond daemon uses inotify to watch files listed in the \
/etc/selinux/restorecond.conf, when they are created, this daemon \
will make sure they have the correct file context associated with \
the policy."
-
SECTION = "base"
LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"

-SRC_URI += "file://policycoreutils-make-O_CLOEXEC-optional.patch \
-"
+require selinux_common.inc

inherit systemd update-rc.d

@@ -19,6 +18,8 @@ EXTRA_OEMAKE += "SYSTEMDSYSTEMUNITDIR=${systemd_system_unitdir} \
SYSTEMDUSERUNITDIR=${systemd_user_unitdir} \
"

+S = "${WORKDIR}/git/restorecond"
+
FILES_${PN} += "${datadir}/dbus-1/services/org.selinux.Restorecond.service \
${systemd_user_unitdir}/* \
"
--
2.25.1

4701 - 4720 of 57387