Date   

[meta-raspberrypi][PATCH] xserver-xorg: remove xshmfence configure option

Yu, Mingli
 

From: Mingli Yu <mingli.yu@...>

After the commit [1] introduced in openembedded-core layer,
some configure options is't carried over include xshmfence
option, so remove the xshmfence configure option to silence
the below warning.
WARNING: xserver-xorg-2_21.1.1-r0 do_configure: QA Issue: xserver-xorg: invalid PACKAGECONFIG: xshmfence [invalid-packageconfig]

[1] https://git.openembedded.org/openembedded-core/commit/?id=e05abd87ee5d23750c641d0129d9c83db68ee2e8

Signed-off-by: Mingli Yu <mingli.yu@...>
---
recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
index 25829c2..ee4812f 100644
--- a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
@@ -1,4 +1,4 @@
-OPENGL_PKGCONFIGS:rpi = "dri glx ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3 xshmfence glamor', '', d)}"
+OPENGL_PKGCONFIGS:rpi = "dri glx ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3 glamor', '', d)}"

# when using userland graphic KHR/khrplatform.h is provided by userland but virtual/libgl is provided by mesa-gl where
# we explicitly delete KHR/khrplatform.h since its already coming from userland package
--
2.17.1


Re: [meta-rockchip][PATCH] u-boot: Replace virtual/trusted-firmware-a with trusted-firmware-a

Khem Raj
 



On Wed, Dec 8, 2021 at 6:03 PM Trevor Woerner <twoerner@...> wrote:
On Wed 2021-12-08 @ 01:15:26 PM, Khem Raj wrote:
> meta-arm has dropped exporting virtual/trusted-firmware-a and expects
> direct use of trusted-firmware-a on depends sections
>
> Signed-off-by: Khem Raj <raj.khem@...>
> ---
>  recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Oops, looks like we both noticed this at about the same time.
Since both our patches are identical, I simply added your SoB line.

Cool



Thanks!


Re: [meta-rockchip][PATCH] u-boot: remove "virtual" keyword in dependency

Trevor Woerner
 

On Wed 2021-12-08 @ 03:29:14 PM, Trevor Woerner wrote:
The latest trusted-firmware-a recipe in meta-arm no longer considers
trusted-firmware-a to have potentially multiple providers.

Signed-off-by: Trevor Woerner <twoerner@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Applied to meta-rockchip (with Khem's SoB added) master.


Re: [meta-rockchip][PATCH] u-boot: Replace virtual/trusted-firmware-a with trusted-firmware-a

Trevor Woerner
 

On Wed 2021-12-08 @ 01:15:26 PM, Khem Raj wrote:
meta-arm has dropped exporting virtual/trusted-firmware-a and expects
direct use of trusted-firmware-a on depends sections

Signed-off-by: Khem Raj <raj.khem@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Oops, looks like we both noticed this at about the same time.
Since both our patches are identical, I simply added your SoB line.

Thanks!


Re: [meta-rockchip][PATCH] trusted-firmware-a: Drop 0001-Fix-build-with-gcc-11.patch

Trevor Woerner
 

On Wed 2021-12-08 @ 11:54:04 AM, Khem Raj wrote:
This has been included upstream see [1]

[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/f943b7c8e292e3aad2fcbdd0a37505f62b3b4c87%5E%21/#F0

Signed-off-by: Khem Raj <raj.khem@...>
---
.../files/0001-Fix-build-with-gcc-11.patch | 34 -------------------
.../trusted-firmware-a_%.bbappend | 1 -
2 files changed, 35 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
Applied to meta-rockchip master. Thanks!


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Tim Orling
 



On Wed, Dec 8, 2021 at 2:08 PM Nicolas Dechesne <nicolas.dechesne@...> wrote:


On Wed, Dec 8, 2021 at 10:57 PM Michael Opdenacker <michael.opdenacker@...> wrote:
Quentin, Nico,

On 12/3/21 11:51 AM, Quentin Schulz wrote:
>
> I think all our issues always come down to this weird and inefficient
> organization we have for docs and common files between doc releases.
> We'll need to settle on something one day because I don't think what
> we're doing today is working :/


Thanks for your reviews. Good to know that the "transition" branch is
still in use in spite of what I wrongly believed.
It indeed, it's a good idea to see what other projects are doing. Maybe
what we are doing is unnecessarily complicated.

Look at Python docs (https://docs.python.org/) for example. They have a
switcher as we do, and also a left bar the latest versions and a
separate page for all versions. However, such versions are only shown on
the top page. When you enter one of the documents though for a given
version, the left bar is used for navigation between sections instead,
and you no longer have references to other versions.

docs.pythong.org is where we stole the idea of the switcher ;-) 
Would anyone be able to figure out if their 'publishing' script is available anywhere? if we could mimic that somehow that might be good. 

 

Let's keep thinking about this, to find an easier to manage solution.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com





Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Nicolas Dechesne
 



On Wed, Dec 8, 2021 at 10:57 PM Michael Opdenacker <michael.opdenacker@...> wrote:
Quentin, Nico,

On 12/3/21 11:51 AM, Quentin Schulz wrote:
>
> I think all our issues always come down to this weird and inefficient
> organization we have for docs and common files between doc releases.
> We'll need to settle on something one day because I don't think what
> we're doing today is working :/


Thanks for your reviews. Good to know that the "transition" branch is
still in use in spite of what I wrongly believed.
It indeed, it's a good idea to see what other projects are doing. Maybe
what we are doing is unnecessarily complicated.

Look at Python docs (https://docs.python.org/) for example. They have a
switcher as we do, and also a left bar the latest versions and a
separate page for all versions. However, such versions are only shown on
the top page. When you enter one of the documents though for a given
version, the left bar is used for navigation between sections instead,
and you no longer have references to other versions.

docs.pythong.org is where we stole the idea of the switcher ;-) 
Would anyone be able to figure out if their 'publishing' script is available anywhere? if we could mimic that somehow that might be good. 
 

Let's keep thinking about this, to find an easier to manage solution.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Michael Opdenacker
 

Quentin, Nico,

On 12/3/21 11:51 AM, Quentin Schulz wrote:

I think all our issues always come down to this weird and inefficient
organization we have for docs and common files between doc releases.
We'll need to settle on something one day because I don't think what
we're doing today is working :/

Thanks for your reviews. Good to know that the "transition" branch is
still in use in spite of what I wrongly believed.
It indeed, it's a good idea to see what other projects are doing. Maybe
what we are doing is unnecessarily complicated.

Look at Python docs (https://docs.python.org/) for example. They have a
switcher as we do, and also a left bar the latest versions and a
separate page for all versions. However, such versions are only shown on
the top page. When you enter one of the documents though for a given
version, the left bar is used for navigation between sections instead,
and you no longer have references to other versions.

Let's keep thinking about this, to find an easier to manage solution.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


[meta-rockchip][PATCH] u-boot: Replace virtual/trusted-firmware-a with trusted-firmware-a

Khem Raj
 

meta-arm has dropped exporting virtual/trusted-firmware-a and expects
direct use of trusted-firmware-a on depends sections

Signed-off-by: Khem Raj <raj.khem@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 7916e45..9108a36 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -8,9 +8,9 @@ do_compile:append:rock2-square () {
ATF_DEPENDS ??= ""

EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
-ATF_DEPENDS:rk3399 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
-ATF_DEPENDS:rk3328 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

--
2.34.1


Re: Trouble building core-image-minimal-initramfs for j7-evm target #grub

Tom Rini
 

On Wed, Dec 08, 2021 at 12:06:49PM -0800, chiefsleepyeye@... wrote:
I'm on the "dunfell" branch and trying to build core-image-minimal-initramfs for a j7-evm target.  When I do that I get the following error:


* Solver encountered 1 problem(s):
* Problem 1/1:
*   - nothing provides grub needed by
initramfs-module-install-1.0-r1.aarch64
*
* Solution 1:
*   - do not ask to install a package providing initramfs-module-install
If I build for the genericx86-64 target it builds successfully.  I think the problem is with it needing "grub" for the j7-evm target because I don't believe grub is needed nor built for that target.  The bootloader in that case is u-boot.  Is there something I need to do to tell it the bootloader is u-boot rather than grub maybe?  Anyone have any ideas and/or guidance?  Thanks in advance.
Note that using grub-efi on aarch64 is expected and normal, building
"grub" is not. I think the core-image-minimal-initramfs recipes and/or
initramfs-module-install recipes need a bit of tweaking.

--
Tom


[meta-rockchip][PATCH] u-boot: remove "virtual" keyword in dependency

Trevor Woerner
 

The latest trusted-firmware-a recipe in meta-arm no longer considers
trusted-firmware-a to have potentially multiple providers.

Signed-off-by: Trevor Woerner <twoerner@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 7916e45..9108a36 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -8,9 +8,9 @@ do_compile:append:rock2-square () {
ATF_DEPENDS ??= ""

EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
-ATF_DEPENDS:rk3399 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
-ATF_DEPENDS:rk3328 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

--
2.34.0.rc1.14.g88d915a634


[meta-rockchip][PATCH] trusted-firmware-a: Drop 0001-Fix-build-with-gcc-11.patch

Khem Raj
 

This has been included upstream see [1]

[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/f943b7c8e292e3aad2fcbdd0a37505f62b3b4c87%5E%21/#F0

Signed-off-by: Khem Raj <raj.khem@...>
---
.../files/0001-Fix-build-with-gcc-11.patch | 34 -------------------
.../trusted-firmware-a_%.bbappend | 1 -
2 files changed, 35 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch b/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
deleted file mode 100644
index 7956717..0000000
--- a/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From d4c60a312271e000e8339f0b47a302c325313758 Mon Sep 17 00:00:00 2001
-From: Khem Raj <raj.khem@...>
-Date: Tue, 11 May 2021 11:46:30 -0700
-Subject: [PATCH] Fix build with gcc 11
-
-Fixes
-plat/rockchip/rk3399/drivers/dram/dram.c:13:22: error: ignoring attribute 'section (".pmusram.data")' because it conflicts with previous 'section (".sram.data")' [-Werror=attributes]
-
-See [1]
-
-[1] https://developer.trustedfirmware.org/T925
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj <raj.khem@...>
----
- plat/rockchip/rk3399/drivers/dram/dram.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/drivers/dram/dram.h b/plat/rockchip/rk3399/drivers/dram/dram.h
-index 0eb12cf29..5572b1612 100644
---- a/plat/rockchip/rk3399/drivers/dram/dram.h
-+++ b/plat/rockchip/rk3399/drivers/dram/dram.h
-@@ -149,7 +149,7 @@ struct rk3399_sdram_params {
- uint32_t rx_cal_dqs[2][4];
- };
-
--extern __sramdata struct rk3399_sdram_params sdram_config;
-+extern struct rk3399_sdram_params sdram_config;
-
- void dram_init(void);
-
---
-2.31.1
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..074d0e0 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -8,7 +8,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
file://serial-console-baudrate.patch \
- file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
--
2.34.1


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: make all versions list releases known to master

Michael Opdenacker
 

Hi Quentin,

Thanks for the review and for your suggestions.

On 12/3/21 10:34 AM, Quentin Schulz wrote:
Hi Michael,

On Wed, Dec 01, 2021 at 02:49:31PM +0100, Michael Opdenacker wrote:
This allows all versions of Bitbake and Yocto Project manuals
to see the manuals for the latest versions.

This also simplifies the release process, not having to update the
releases.rst file for all releases every time a new release is made.

Note that such synchronization is already done for the
switchers.js file (but in a different way). This way, advertised
releases are in sync with switchers.js.
Why don't we migrate this different method (find) to the one you
implement in this commit too?

I could see a variable storing all "force-latest" files or someting like
that to make it obvious why they have a specific handling.

I tried, but I stumble on the need to copy the latest switchers.js from
yocto-docs to the Bitbake branches too.

And since the Bitbake branches need to be checked out and processed
first, I hesitate to add a special extra step to checkout the yocto-docs
repo before. Possible but adding complexity.

So, if I don't use this way for the Bitbake branches, I still need a
find command at the end...

If you don't think about any better idea, I'd propose to stick to this
version of the patch.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [oe] Help with Inclusive Language in OpenEmbedded/Yocto Project

Scott Murray
 

On Mon, 6 Dec 2021, Jon Mason wrote:

This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.
I am also interested in helping move this forward, please count me in.

Scott


[meta-raspberrypi] Changing rootfstype to squashfs

Beek, Léon van de
 

Dear all,

 

My goal is to have a squashfs rootfstype and ext4 data partition that get combined in an overlayfs and switched to the root during boot.

I managed to get the overlayfs and switching of root working thanks to meta-readonly-rootfs and some changes locally, but only with 2 ext4 partitions and not with a squashfs partition.

I changed the rootfs to squash fs by changing the following 2 things:

  • Change to --fstype=squashfs in .wks file
  • Change IMAGE_FSTYPE to “squashfs wic.bz2” although I believe this is only necessary to get a .squashfs rootfs file

 

Please note I am running the image on a raspberrypi3-64, and I also noticed that the cmdline.txt still had rootfstype=ext4, but after changing this to squashfs I got a kernel panic with error:

“Not syncing: vfs: Unable to mount root fs on unknown-blick(179,6)”

Which I believe means in this case that the kernel module for Squashfs is not loaded? Could someone help me out how to load this module or point out something else I am missing?

 

Kind regards,

Léon


Re: Behaviour of .bbappend when default script is not present

tomzy
 

Hi,

You could also consider using the `BBFILES_DYNAMIC`[1] variable, this way your bbappend
would only apply when there is `meta-raspberrypi` in the build configuration. Your bbappend
could be placed in custom layer under
`dynamic-layers/raspberrypi/recipes-bsp/bootfiles/
rpi-cmdline.bbappend` path and than in its
layer.conf file add

BBFILES_DYNAMIC += " \
    raspberrypi:${LAYERDIR}/dynamic-layers/raspberrypi/recipes-*/*/*.bbappend \
"

Looks like the best option to add kernel command parameters is to use `
rpi-cmdline.bbappend`
with dynamic-layers as mentioned above. You should add changes to CMDLINE[2] variable

[1]https://docs.yoctoproject.org/ref-manual/variables.html#term-BBFILES_DYNAMIC
[2]https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/bootfiles/rpi-cmdline.bb#L39

Regards
--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com


Re: Behaviour of .bbappend when default script is not present

Konrad Weihmann <kweihmann@...>
 

You can either use BBMASK in your local.conf to remove the bbappend from the parsing tree or set BB_DANGLINGAPPENDS_WARNONLY in your specific build.

both can be added to your specific kas yaml without any issues

[1] https://docs.yoctoproject.org/ref-manual/variables.html#term-BB_DANGLINGAPPENDS_WARNONLY

On 08.12.21 10:26, Beek, Léon van de wrote:
Dear all,
My situation is as follows:
* Using Kas container to build and enable easy CI, I have 2 .yaml
files creating my 2 builds for 2 different machines: RaspberryPi and
Qemu.
* Qemu yaml file does not contain meta-raspberrypi repo
* Custom distro that extends poky has a script rpi-cmdline.bbappend
that appends script with the same name from meta-raspberrypi
* Rpi-cmdline.bbappend is used to simply add 2 kernel commands to
cmdline.txt
* Rpi-cmdline.bbappend contains line on top with: COMPATIBLE_MACHINE =
"^rpi$"
When running the Qemu build, Bitbake will say that the default .bb file is not present for the rpi-cmdline.bbappend script, which of course is true, but I don’t want to include the meta-raspberrypi repo in my sources for this build as well.
It seems like the “COMPATIBLE_MACHINE = "^rpi$"” is only regarded after parsing the script, which still requires the default script to be present.
I’ve searched the internet but have not found a way of achieving my goal so far, so my question is:
Is there any way of having this .bbappend file present without the default .bb file there? Or maybe there is a better solution to add kernel command parameters to cmdline without using this rpi only script?
Thanks in advance.
Kind regards,
Léon van de Beek


Behaviour of .bbappend when default script is not present

Beek, Léon van de
 

Dear all,

 

My situation is as follows:

 

  • Using Kas container to build and enable easy CI, I have 2 .yaml files creating my 2 builds for 2 different machines: RaspberryPi and Qemu.
  • Qemu yaml file does not contain meta-raspberrypi repo
  • Custom distro that extends poky has a script rpi-cmdline.bbappend that appends script with the same name from meta-raspberrypi
  • Rpi-cmdline.bbappend is used to simply add 2 kernel commands to cmdline.txt
  • Rpi-cmdline.bbappend contains line on top with: COMPATIBLE_MACHINE = "^rpi$"

 

When running the Qemu build, Bitbake will say that the default .bb file is not present for the rpi-cmdline.bbappend script, which of course is true, but I don’t want to include the meta-raspberrypi repo in my sources for this build as well.

It seems like the “COMPATIBLE_MACHINE = "^rpi$"” is only regarded after parsing the script, which still requires the default script to be present.

 

I’ve searched the internet but have not found a way of achieving my goal so far, so my question is:

Is there any way of having this .bbappend file present without the default .bb file there? Or maybe there is a better solution to add kernel command parameters to cmdline without using this rpi only script?

 

Thanks in advance.

 

Kind regards,

Léon van de Beek

 


[meta-selinux][PATCH 3/3] selinux: upgrade 3.2 -> 3.3

Yi Zhao
 

Drop backport CVE patches.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
...{checkpolicy_3.2.bb => checkpolicy_3.3.bb} | 0
...python_3.2.bb => libselinux-python_3.3.bb} | 0
.../{libselinux_3.2.bb => libselinux_3.3.bb} | 0
...{libsemanage_3.2.bb => libsemanage_3.3.bb} | 0
.../selinux/libsepol/CVE-2021-36084.patch | 99 -------------
.../selinux/libsepol/CVE-2021-36085.patch | 38 -----
.../selinux/libsepol/CVE-2021-36086.patch | 46 ------
.../{libsepol_3.2.bb => libsepol_3.3.bb} | 4 -
.../{mcstrans_3.2.bb => mcstrans_3.3.bb} | 0
...oreutils_3.2.bb => policycoreutils_3.3.bb} | 0
...{restorecond_3.2.bb => restorecond_3.3.bb} | 0
.../selinux/secilc/CVE-2021-36087.patch | 134 ------------------
.../selinux/{secilc_3.2.bb => secilc_3.3.bb} | 2 -
...elinux-dbus_3.2.bb => selinux-dbus_3.3.bb} | 0
...{selinux-gui_3.2.bb => selinux-gui_3.3.bb} | 0
...ux-python_3.2.bb => selinux-python_3.3.bb} | 0
...-sandbox_3.2.bb => selinux-sandbox_3.3.bb} | 0
recipes-security/selinux/selinux_common.inc | 2 +-
...ule-utils_3.2.bb => semodule-utils_3.3.bb} | 0
19 files changed, 1 insertion(+), 324 deletions(-)
rename recipes-security/selinux/{checkpolicy_3.2.bb => checkpolicy_3.3.bb} (100%)
rename recipes-security/selinux/{libselinux-python_3.2.bb => libselinux-python_3.3.bb} (100%)
rename recipes-security/selinux/{libselinux_3.2.bb => libselinux_3.3.bb} (100%)
rename recipes-security/selinux/{libsemanage_3.2.bb => libsemanage_3.3.bb} (100%)
delete mode 100644 recipes-security/selinux/libsepol/CVE-2021-36084.patch
delete mode 100644 recipes-security/selinux/libsepol/CVE-2021-36085.patch
delete mode 100644 recipes-security/selinux/libsepol/CVE-2021-36086.patch
rename recipes-security/selinux/{libsepol_3.2.bb => libsepol_3.3.bb} (85%)
rename recipes-security/selinux/{mcstrans_3.2.bb => mcstrans_3.3.bb} (100%)
rename recipes-security/selinux/{policycoreutils_3.2.bb => policycoreutils_3.3.bb} (100%)
rename recipes-security/selinux/{restorecond_3.2.bb => restorecond_3.3.bb} (100%)
delete mode 100644 recipes-security/selinux/secilc/CVE-2021-36087.patch
rename recipes-security/selinux/{secilc_3.2.bb => secilc_3.3.bb} (90%)
rename recipes-security/selinux/{selinux-dbus_3.2.bb => selinux-dbus_3.3.bb} (100%)
rename recipes-security/selinux/{selinux-gui_3.2.bb => selinux-gui_3.3.bb} (100%)
rename recipes-security/selinux/{selinux-python_3.2.bb => selinux-python_3.3.bb} (100%)
rename recipes-security/selinux/{selinux-sandbox_3.2.bb => selinux-sandbox_3.3.bb} (100%)
rename recipes-security/selinux/{semodule-utils_3.2.bb => semodule-utils_3.3.bb} (100%)

diff --git a/recipes-security/selinux/checkpolicy_3.2.bb b/recipes-security/selinux/checkpolicy_3.3.bb
similarity index 100%
rename from recipes-security/selinux/checkpolicy_3.2.bb
rename to recipes-security/selinux/checkpolicy_3.3.bb
diff --git a/recipes-security/selinux/libselinux-python_3.2.bb b/recipes-security/selinux/libselinux-python_3.3.bb
similarity index 100%
rename from recipes-security/selinux/libselinux-python_3.2.bb
rename to recipes-security/selinux/libselinux-python_3.3.bb
diff --git a/recipes-security/selinux/libselinux_3.2.bb b/recipes-security/selinux/libselinux_3.3.bb
similarity index 100%
rename from recipes-security/selinux/libselinux_3.2.bb
rename to recipes-security/selinux/libselinux_3.3.bb
diff --git a/recipes-security/selinux/libsemanage_3.2.bb b/recipes-security/selinux/libsemanage_3.3.bb
similarity index 100%
rename from recipes-security/selinux/libsemanage_3.2.bb
rename to recipes-security/selinux/libsemanage_3.3.bb
diff --git a/recipes-security/selinux/libsepol/CVE-2021-36084.patch b/recipes-security/selinux/libsepol/CVE-2021-36084.patch
deleted file mode 100644
index 1001563..0000000
--- a/recipes-security/selinux/libsepol/CVE-2021-36084.patch
+++ /dev/null
@@ -1,99 +0,0 @@
-From f34d3d30c8325e4847a6b696fe7a3936a8a361f3 Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Thu, 8 Apr 2021 13:32:01 -0400
-Subject: [PATCH] libsepol/cil: Destroy classperms list when resetting
- classpermission
-
-Nicolas Iooss reports:
- A few months ago, OSS-Fuzz found a crash in the CIL compiler, which
- got reported as
- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28648 (the title
- is misleading, or is caused by another issue that conflicts with the
- one I report in this message). Here is a minimized CIL policy which
- reproduces the issue:
-
- (class CLASS (PERM))
- (classorder (CLASS))
- (sid SID)
- (sidorder (SID))
- (user USER)
- (role ROLE)
- (type TYPE)
- (category CAT)
- (categoryorder (CAT))
- (sensitivity SENS)
- (sensitivityorder (SENS))
- (sensitivitycategory SENS (CAT))
- (allow TYPE self (CLASS (PERM)))
- (roletype ROLE TYPE)
- (userrole USER ROLE)
- (userlevel USER (SENS))
- (userrange USER ((SENS)(SENS (CAT))))
- (sidcontext SID (USER ROLE TYPE ((SENS)(SENS))))
-
- (classpermission CLAPERM)
-
- (optional OPT
- (roletype nonexistingrole nonexistingtype)
- (classpermissionset CLAPERM (CLASS (PERM)))
- )
-
- The CIL policy fuzzer (which mimics secilc built with clang Address
- Sanitizer) reports:
-
- ==36541==ERROR: AddressSanitizer: heap-use-after-free on address
- 0x603000004f98 at pc 0x56445134c842 bp 0x7ffe2a256590 sp
- 0x7ffe2a256588
- READ of size 8 at 0x603000004f98 thread T0
- #0 0x56445134c841 in __cil_verify_classperms
- /selinux/libsepol/src/../cil/src/cil_verify.c:1620:8
- #1 0x56445134a43e in __cil_verify_classpermission
- /selinux/libsepol/src/../cil/src/cil_verify.c:1650:9
- #2 0x56445134a43e in __cil_pre_verify_helper
- /selinux/libsepol/src/../cil/src/cil_verify.c:1715:8
- #3 0x5644513225ac in cil_tree_walk_core
- /selinux/libsepol/src/../cil/src/cil_tree.c:272:9
- #4 0x564451322ab1 in cil_tree_walk
- /selinux/libsepol/src/../cil/src/cil_tree.c:316:7
- #5 0x5644513226af in cil_tree_walk_core
- /selinux/libsepol/src/../cil/src/cil_tree.c:284:9
- #6 0x564451322ab1 in cil_tree_walk
- /selinux/libsepol/src/../cil/src/cil_tree.c:316:7
- #7 0x5644512b88fd in cil_pre_verify
- /selinux/libsepol/src/../cil/src/cil_post.c:2510:7
- #8 0x5644512b88fd in cil_post_process
- /selinux/libsepol/src/../cil/src/cil_post.c:2524:7
- #9 0x5644511856ff in cil_compile
- /selinux/libsepol/src/../cil/src/cil.c:564:7
-
-The classperms list of a classpermission rule is created and filled
-in when classpermissionset rules are processed, so it doesn't own any
-part of the list and shouldn't retain any of it when it is reset.
-
-Destroy the classperms list (without destroying the data in it) when
-resetting a classpermission rule.
-
-Reported-by: Nicolas Iooss <nicolas.iooss@...>
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-CVE: CVE-2021-36084
-Signed-off-by: Armin Kuster <akuster@...>
-
----
- libsepol/cil/src/cil_reset_ast.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: libsepol-3.0/cil/src/cil_reset_ast.c
-===================================================================
---- libsepol-3.0.orig/cil/src/cil_reset_ast.c
-+++ libsepol-3.0/cil/src/cil_reset_ast.c
-@@ -52,7 +52,7 @@ static void cil_reset_classpermission(st
- return;
- }
-
-- cil_reset_classperms_list(cp->classperms);
-+ cil_list_destroy(&cp->classperms, CIL_FALSE);
- }
-
- static void cil_reset_classperms_set(struct cil_classperms_set *cp_set)
diff --git a/recipes-security/selinux/libsepol/CVE-2021-36085.patch b/recipes-security/selinux/libsepol/CVE-2021-36085.patch
deleted file mode 100644
index 4bd05eb..0000000
--- a/recipes-security/selinux/libsepol/CVE-2021-36085.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From 2d35fcc7e9e976a2346b1de20e54f8663e8a6cba Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Thu, 8 Apr 2021 13:32:04 -0400
-Subject: [PATCH] libsepol/cil: Destroy classperm list when resetting map perms
-
-Map perms share the same struct as regular perms, but only the
-map perms use the classperms field. This field is a pointer to a
-list of classperms that is created and added to when resolving
-classmapping rules, so the map permission doesn't own any of the
-data in the list and this list should be destroyed when the AST is
-reset.
-
-When resetting a perm, destroy the classperms list without destroying
-the data in the list.
-
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-CVE: CVE-2021-36085
-Signed-off-by: Armin Kuster <akuster@...>
-
----
- libsepol/cil/src/cil_reset_ast.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: libsepol-3.0/cil/src/cil_reset_ast.c
-===================================================================
---- libsepol-3.0.orig/cil/src/cil_reset_ast.c
-+++ libsepol-3.0/cil/src/cil_reset_ast.c
-@@ -34,7 +34,7 @@ static void cil_reset_class(struct cil_c
-
- static void cil_reset_perm(struct cil_perm *perm)
- {
-- cil_reset_classperms_list(perm->classperms);
-+ cil_list_destroy(&perm->classperms, CIL_FALSE);
- }
-
- static inline void cil_reset_classperms(struct cil_classperms *cp)
diff --git a/recipes-security/selinux/libsepol/CVE-2021-36086.patch b/recipes-security/selinux/libsepol/CVE-2021-36086.patch
deleted file mode 100644
index 7a2d616..0000000
--- a/recipes-security/selinux/libsepol/CVE-2021-36086.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 49f9aa2a460fc95f04c99b44f4dd0d22e2f0e5ee Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Thu, 8 Apr 2021 13:32:06 -0400
-Subject: [PATCH] libsepol/cil: cil_reset_classperms_set() should not reset
- classpermission
-
-In struct cil_classperms_set, the set field is a pointer to a
-struct cil_classpermission which is looked up in the symbol table.
-Since the cil_classperms_set does not create the cil_classpermission,
-it should not reset it.
-
-Set the set field to NULL instead of resetting the classpermission
-that it points to.
-
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-[https://github.com/SELinuxProject/selinux/commit/c49a8ea09501ad66e799ea41b8154b6770fec2c8]
-
-CVE: CVE-2021-36086
-
-Signed-off-by: Yi Zhao <yi.zhao@...>
----
- cil/src/cil_reset_ast.c | 6 +++++-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
-diff --git a/cil/src/cil_reset_ast.c b/cil/src/cil_reset_ast.c
-index 89f91e5..1d9ca70 100644
---- a/cil/src/cil_reset_ast.c
-+++ b/cil/src/cil_reset_ast.c
-@@ -59,7 +59,11 @@ static void cil_reset_classpermission(struct cil_classpermission *cp)
-
- static void cil_reset_classperms_set(struct cil_classperms_set *cp_set)
- {
-- cil_reset_classpermission(cp_set->set);
-+ if (cp_set == NULL) {
-+ return;
-+ }
-+
-+ cp_set->set = NULL;
- }
-
- static inline void cil_reset_classperms_list(struct cil_list *cp_list)
---
-2.17.1
-
diff --git a/recipes-security/selinux/libsepol_3.2.bb b/recipes-security/selinux/libsepol_3.3.bb
similarity index 85%
rename from recipes-security/selinux/libsepol_3.2.bb
rename to recipes-security/selinux/libsepol_3.3.bb
index 192f1b3..48d5f49 100644
--- a/recipes-security/selinux/libsepol_3.2.bb
+++ b/recipes-security/selinux/libsepol_3.3.bb
@@ -9,10 +9,6 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"

require selinux_common.inc

-SRC_URI += "file://CVE-2021-36084.patch \
- file://CVE-2021-36085.patch \
- file://CVE-2021-36086.patch "
-
inherit lib_package

S = "${WORKDIR}/git/libsepol"
diff --git a/recipes-security/selinux/mcstrans_3.2.bb b/recipes-security/selinux/mcstrans_3.3.bb
similarity index 100%
rename from recipes-security/selinux/mcstrans_3.2.bb
rename to recipes-security/selinux/mcstrans_3.3.bb
diff --git a/recipes-security/selinux/policycoreutils_3.2.bb b/recipes-security/selinux/policycoreutils_3.3.bb
similarity index 100%
rename from recipes-security/selinux/policycoreutils_3.2.bb
rename to recipes-security/selinux/policycoreutils_3.3.bb
diff --git a/recipes-security/selinux/restorecond_3.2.bb b/recipes-security/selinux/restorecond_3.3.bb
similarity index 100%
rename from recipes-security/selinux/restorecond_3.2.bb
rename to recipes-security/selinux/restorecond_3.3.bb
diff --git a/recipes-security/selinux/secilc/CVE-2021-36087.patch b/recipes-security/selinux/secilc/CVE-2021-36087.patch
deleted file mode 100644
index 5410477..0000000
--- a/recipes-security/selinux/secilc/CVE-2021-36087.patch
+++ /dev/null
@@ -1,134 +0,0 @@
-From bad0a746e9f4cf260dedba5828d9645d50176aac Mon Sep 17 00:00:00 2001
-From: James Carter <jwcart2@...>
-Date: Mon, 19 Apr 2021 09:06:15 -0400
-Subject: [PATCH] secilc/docs: Update the CIL documentation for various blocks
-
-Update the documentation for macros, booleans, booleanifs, tunables,
-tunableifs, blocks, blockabstracts, blockinherits, and optionals to
-tell where these statements can be used and, for those that have
-blocks, what statements are not allowed in them.
-
-Signed-off-by: James Carter <jwcart2@...>
-
-Upstream-Status: Backport
-CVE: CVE-2021-36087
-Signed-off-by: Armin Kuster <akuster@...>
-
----
- docs/cil_call_macro_statements.md | 2 ++
- docs/cil_conditional_statements.md | 6 +++++
- docs/cil_container_statements.md | 28 +++++++++++++++--------
- 3 files changed, 26 insertions(+), 10 deletions(-)
-
-Index: secilc/docs/cil_call_macro_statements.md
-===================================================================
---- secilc.orig/docs/cil_call_macro_statements.md
-+++ secilc/docs/cil_call_macro_statements.md
-@@ -58,6 +58,8 @@ When resolving macros the following plac
-
- - Items defined in the global namespace
-
-+[`tunable`](cil_conditional_statements.md#tunable), [`in`](cil_container_statements.md#in), [`block`](cil_container_statements.md#block), [`blockinherit`](cil_container_statements.md#blockinherit), [`blockabstract`](cil_container_statements.md#blockabstract), and other [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in [`macro`](cil_call_macro_statements.md#macro) blocks.
-+
- **Statement definition:**
-
- ```secil
-Index: secilc/docs/cil_conditional_statements.md
-===================================================================
---- secilc.orig/docs/cil_conditional_statements.md
-+++ secilc/docs/cil_conditional_statements.md
-@@ -6,6 +6,8 @@ boolean
-
- Declares a run time boolean as true or false in the current namespace. The [`booleanif`](cil_conditional_statements.md#booleanif) statement contains the CIL code that will be in the binary policy file.
-
-+[`boolean`](cil_conditional_statements.md#boolean) are not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -126,6 +128,8 @@ Tunables are similar to booleans, howeve
-
- Note that tunables can be treated as booleans by the CIL compiler command line parameter `-P` or `--preserve-tunables` flags.
-
-+Since [`tunableif`](cil_conditional_statements.md#tunableif) statements are resolved first, [`tunable`](cil_conditional_statements.md#tunable) statements are not allowed in [`in`](cil_container_statements.md#in), [`macro`](cil_call_macro_statements.md#macro), [`optional`](cil_container_statements.md#optional), and [`booleanif`](cil_conditional_statements.md#booleanif) blocks. To simplify processing, they are also not allowed in [`tunableif`](cil_conditional_statements.md#tunableif) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -164,6 +168,8 @@ tunableif
-
- Compile time conditional statement that may or may not add CIL statements to be compiled.
-
-+If tunables are being treated as booleans (by using the CIL compiler command line parameter `-P` or `--preserve-tunables` flag), then only the statements allowed in a [`booleanif`](cil_conditional_statements.md#booleanif) block are allowed in a [`tunableif`](cil_conditional_statements.md#tunableif) block. Otherwise, [`tunable`](cil_conditional_statements.md#tunable) statements are not allowed in a [`tunableif`](cil_conditional_statements.md#tunableif) block.
-+
- **Statement definition:**
-
- ```secil
-Index: secilc/docs/cil_container_statements.md
-===================================================================
---- secilc.orig/docs/cil_container_statements.md
-+++ secilc/docs/cil_container_statements.md
-@@ -4,7 +4,11 @@ Container Statements
- block
- -----
-
--Start a new namespace where any CIL statement is valid.
-+Start a new namespace.
-+
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro) and [`optional`](cil_container_statements.md#optional) blocks.
-+
-+[`sensitivity`](cil_mls_labeling_statements.md#sensitivity) and [`category`](cil_mls_labeling_statements.md#category) statements are not allowed in [`block`](cil_container_statements.md#block) blocks.
-
- **Statement definition:**
-
-@@ -47,6 +51,8 @@ blockabstract
-
- Declares the namespace as a 'template' and does not generate code until instantiated by another namespace that has a [`blockinherit`](cil_container_statements.md#blockinherit) statement.
-
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro) and [`optional`](cil_container_statements.md#optional) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -97,6 +103,8 @@ blockinherit
-
- Used to add common policy rules to the current namespace via a template that has been defined with the [`blockabstract`](cil_container_statements.md#blockabstract) statement. All [`blockinherit`](cil_container_statements.md#blockinherit) statements are resolved first and then the contents of the block are copied. This is so that inherited blocks will not be inherited. For a concrete example, please see the examples section.
-
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro) blocks.
-+
- **Statement definition:**
-
- ```secil
-@@ -199,15 +207,11 @@ This example contains a template `client
- optional
- --------
-
--Declare an [`optional`](cil_container_statements.md#optional) namespace. All CIL statements in the optional block must be satisfied before instantiation in the binary policy. [`tunableif`](cil_conditional_statements.md#tunableif) and [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in optional containers. The same restrictions apply to CIL policy statements within [`optional`](cil_container_statements.md#optional)'s that apply to kernel policy statements, i.e. only the policy statements shown in the following table are valid:
-+Declare an [`optional`](cil_container_statements.md#optional) namespace. All CIL statements in the optional block must be satisfied before instantiation in the binary policy.
-
--| | | | |
--| ------------------- | -------------- | ------------------ | ------------------ |
--| [`allow`](cil_access_vector_rules.md#allow) | [`allowx`](cil_access_vector_rules.md#allowx) | [`auditallow`](cil_access_vector_rules.md#auditallow) | [`auditallowx`](cil_access_vector_rules.md#auditallowx) |
--| [`booleanif`](cil_conditional_statements.md#booleanif) | [`dontaudit`](cil_access_vector_rules.md#dontaudit) | [`dontauditx`](cil_access_vector_rules.md#dontauditx) | [`typepermissive`](cil_type_statements.md#typepermissive) |
--| [`rangetransition`](cil_mls_labeling_statements.md#rangetransition) | [`role`](cil_role_statements.md#role) | [`roleallow`](cil_role_statements.md#roleallow) | [`roleattribute`](cil_role_statements.md#roleattribute) |
--| [`roletransition`](cil_role_statements.md#roletransition) | [`type`](cil_type_statements.md#type) | [`typealias`](cil_type_statements.md#typealias) | [`typeattribute`](cil_type_statements.md#typeattribute) |
--| [`typechange`](cil_type_statements.md#typechange) | [`typemember`](cil_type_statements.md#typemember) | [`typetransition`](cil_type_statements.md#typetransition) | |
-+Not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) blocks.
-+
-+[`tunable`](cil_conditional_statements.md#tunable), [`in`](cil_container_statements.md#in), [`block`](cil_container_statements.md#block), [`blockabstract`](cil_container_statements.md#blockabstract), and [`macro`](cil_call_macro_statements.md#macro) statements are not allowed in [`optional`](cil_container_statements.md#optional) blocks.
-
- **Statement definition:**
-
-@@ -266,7 +270,11 @@ This example will instantiate the option
- in
- --
-
--Allows the insertion of CIL statements into a named container ([`block`](cil_container_statements.md#block), [`optional`](cil_container_statements.md#optional) or [`macro`](cil_call_macro_statements.md#macro)). This statement is not allowed in [`booleanif`](cil_conditional_statements.md#booleanif) or [`tunableif`](cil_conditional_statements.md#tunableif) statements. This only works for containers that aren't inherited using [`blockinherit`](cil_conditional_statements.md#blockinherit).
-+Allows the insertion of CIL statements into a named container ([`block`](cil_container_statements.md#block), [`optional`](cil_container_statements.md#optional) or [`macro`](cil_call_macro_statements.md#macro)).
-+
-+Not allowed in [`macro`](cil_call_macro_statements.md#macro), [`booleanif`](cil_conditional_statements.md#booleanif), and other [`in`](cil_container_statements.md#in) blocks.
-+
-+[`tunable`](cil_conditional_statements.md#tunable) and [`in`](cil_container_statements.md#in) statements are not allowed in [`in`](cil_container_statements.md#in) blocks.
-
- **Statement definition:**
-
diff --git a/recipes-security/selinux/secilc_3.2.bb b/recipes-security/selinux/secilc_3.3.bb
similarity index 90%
rename from recipes-security/selinux/secilc_3.2.bb
rename to recipes-security/selinux/secilc_3.3.bb
index 50413e0..60ab2fe 100644
--- a/recipes-security/selinux/secilc_3.2.bb
+++ b/recipes-security/selinux/secilc_3.3.bb
@@ -8,8 +8,6 @@ LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=c7e802b9a3b0c2c852669864c08b9138"

require selinux_common.inc

-SRC_URI += "file://CVE-2021-36087.patch"
-
DEPENDS += "libsepol xmlto-native"

S = "${WORKDIR}/git/secilc"
diff --git a/recipes-security/selinux/selinux-dbus_3.2.bb b/recipes-security/selinux/selinux-dbus_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-dbus_3.2.bb
rename to recipes-security/selinux/selinux-dbus_3.3.bb
diff --git a/recipes-security/selinux/selinux-gui_3.2.bb b/recipes-security/selinux/selinux-gui_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-gui_3.2.bb
rename to recipes-security/selinux/selinux-gui_3.3.bb
diff --git a/recipes-security/selinux/selinux-python_3.2.bb b/recipes-security/selinux/selinux-python_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-python_3.2.bb
rename to recipes-security/selinux/selinux-python_3.3.bb
diff --git a/recipes-security/selinux/selinux-sandbox_3.2.bb b/recipes-security/selinux/selinux-sandbox_3.3.bb
similarity index 100%
rename from recipes-security/selinux/selinux-sandbox_3.2.bb
rename to recipes-security/selinux/selinux-sandbox_3.3.bb
diff --git a/recipes-security/selinux/selinux_common.inc b/recipes-security/selinux/selinux_common.inc
index dc4ccd5..8bdf8ad 100644
--- a/recipes-security/selinux/selinux_common.inc
+++ b/recipes-security/selinux/selinux_common.inc
@@ -1,7 +1,7 @@
HOMEPAGE = "https://github.com/SELinuxProject"

SRC_URI = "git://github.com/SELinuxProject/selinux.git;branch=master;protocol=https"
-SRCREV = "cf853c1a0c2328ad6c62fb2b2cc55d4926301d6b"
+SRCREV = "7f600c40bc18d8180993edcd54daf45124736776"

UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+(\.\d+)+)"

diff --git a/recipes-security/selinux/semodule-utils_3.2.bb b/recipes-security/selinux/semodule-utils_3.3.bb
similarity index 100%
rename from recipes-security/selinux/semodule-utils_3.2.bb
rename to recipes-security/selinux/semodule-utils_3.3.bb
--
2.25.1


[meta-selinux][PATCH 2/3] selinux: move selinux scripts to selinux-scripts

Yi Zhao
 

There are too many recipes in recipes-security/selinux. Keep the selinux
userspace recipes and move selinux scripts to selinux-scripts directory
to make the directory hierarchy clearer.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../selinux-autorelabel/selinux-autorelabel.service | 0
.../selinux-autorelabel/selinux-autorelabel.sh | 0
.../{selinux => selinux-scripts}/selinux-autorelabel_0.1.bb | 0
.../selinux-init/selinux-init.service | 0
.../{selinux => selinux-scripts}/selinux-init/selinux-init.sh | 0
.../selinux-init/selinux-init.sh.sysvinit | 0
recipes-security/{selinux => selinux-scripts}/selinux-init_0.1.bb | 0
recipes-security/{selinux => selinux-scripts}/selinux-initsh.inc | 0
.../selinux-labeldev/selinux-labeldev.service | 0
.../selinux-labeldev/selinux-labeldev.sh | 0
.../{selinux => selinux-scripts}/selinux-labeldev_0.1.bb | 0
11 files changed, 0 insertions(+), 0 deletions(-)
rename recipes-security/{selinux => selinux-scripts}/selinux-autorelabel/selinux-autorelabel.service (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-autorelabel/selinux-autorelabel.sh (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-autorelabel_0.1.bb (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init/selinux-init.service (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init/selinux-init.sh (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init/selinux-init.sh.sysvinit (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-init_0.1.bb (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-initsh.inc (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-labeldev/selinux-labeldev.service (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-labeldev/selinux-labeldev.sh (100%)
rename recipes-security/{selinux => selinux-scripts}/selinux-labeldev_0.1.bb (100%)

diff --git a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.service b/recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.service
similarity index 100%
rename from recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.service
rename to recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.service
diff --git a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh b/recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.sh
similarity index 100%
rename from recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
rename to recipes-security/selinux-scripts/selinux-autorelabel/selinux-autorelabel.sh
diff --git a/recipes-security/selinux/selinux-autorelabel_0.1.bb b/recipes-security/selinux-scripts/selinux-autorelabel_0.1.bb
similarity index 100%
rename from recipes-security/selinux/selinux-autorelabel_0.1.bb
rename to recipes-security/selinux-scripts/selinux-autorelabel_0.1.bb
diff --git a/recipes-security/selinux/selinux-init/selinux-init.service b/recipes-security/selinux-scripts/selinux-init/selinux-init.service
similarity index 100%
rename from recipes-security/selinux/selinux-init/selinux-init.service
rename to recipes-security/selinux-scripts/selinux-init/selinux-init.service
diff --git a/recipes-security/selinux/selinux-init/selinux-init.sh b/recipes-security/selinux-scripts/selinux-init/selinux-init.sh
similarity index 100%
rename from recipes-security/selinux/selinux-init/selinux-init.sh
rename to recipes-security/selinux-scripts/selinux-init/selinux-init.sh
diff --git a/recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit b/recipes-security/selinux-scripts/selinux-init/selinux-init.sh.sysvinit
similarity index 100%
rename from recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit
rename to recipes-security/selinux-scripts/selinux-init/selinux-init.sh.sysvinit
diff --git a/recipes-security/selinux/selinux-init_0.1.bb b/recipes-security/selinux-scripts/selinux-init_0.1.bb
similarity index 100%
rename from recipes-security/selinux/selinux-init_0.1.bb
rename to recipes-security/selinux-scripts/selinux-init_0.1.bb
diff --git a/recipes-security/selinux/selinux-initsh.inc b/recipes-security/selinux-scripts/selinux-initsh.inc
similarity index 100%
rename from recipes-security/selinux/selinux-initsh.inc
rename to recipes-security/selinux-scripts/selinux-initsh.inc
diff --git a/recipes-security/selinux/selinux-labeldev/selinux-labeldev.service b/recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.service
similarity index 100%
rename from recipes-security/selinux/selinux-labeldev/selinux-labeldev.service
rename to recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.service
diff --git a/recipes-security/selinux/selinux-labeldev/selinux-labeldev.sh b/recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.sh
similarity index 100%
rename from recipes-security/selinux/selinux-labeldev/selinux-labeldev.sh
rename to recipes-security/selinux-scripts/selinux-labeldev/selinux-labeldev.sh
diff --git a/recipes-security/selinux/selinux-labeldev_0.1.bb b/recipes-security/selinux-scripts/selinux-labeldev_0.1.bb
similarity index 100%
rename from recipes-security/selinux/selinux-labeldev_0.1.bb
rename to recipes-security/selinux-scripts/selinux-labeldev_0.1.bb
--
2.25.1

2321 - 2340 of 57807