Date   

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


[meta-selinux][PATCH 1/3] selinux-python: add RDEPENDES on audit-python

Yi Zhao
 

Add RDEPENDS on audit-python for selinux-python-semanage.

Fixes:
$ semanage fcontext -a -t user_home_t "/web(/.*)?"
Traceback (most recent call last):
File "/usr/sbin/semanage", line 975, in <module>
do_parser()
File "/usr/sbin/semanage", line 947, in do_parser
args.func(args)
File "/usr/sbin/semanage", line 329, in handleFcontext
OBJECT.add(args.file_spec, args.type, args.ftype, args.range, args.seuser)
File "/usr/lib/python3.9/site-packages/seobject.py", line 2485, in add
self.__add(target, type, ftype, serange, seuser)
File "/usr/lib/python3.9/site-packages/seobject.py", line 2481, in __add
self.mylog.log_change("resrc=fcontext op=add %s ftype=%s tcontext=%s:%s:%s:%s"
% (audit.audit_encode_nv_string("tglob", target, 0), ftype_to_audit[ftype],)
NameError: name 'audit' is not defined

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-python_3.2.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-security/selinux/selinux-python_3.2.bb b/recipes-security/selinux/selinux-python_3.2.bb
index a954676..d130900 100644
--- a/recipes-security/selinux/selinux-python_3.2.bb
+++ b/recipes-security/selinux/selinux-python_3.2.bb
@@ -50,6 +50,7 @@ RDEPENDS:${BPN}-semanage += "\
python3-xml \
python3-misc \
libselinux-python \
+ audit-python \
${BPN} \
"
RDEPENDS:${BPN}-sepolicy += "\
--
2.25.1


[meta-realtime][PATCH] schedtool-dl: add branch and protocol in SRC_URI

Chen Qi
 

Add branch and prototol to avoid do_fetch warnings.

Signed-off-by: Chen Qi <Qi.Chen@...>
---
recipes-tools/schedtool-dl/schedtool-dl.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb b/recipes-tools/schedtool-dl/schedtool-dl.bb
index 59e3b32..c8f5d1e 100644
--- a/recipes-tools/schedtool-dl/schedtool-dl.bb
+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb
@@ -3,7 +3,7 @@ SECTION = "devel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=dc1f51f7ca94aebffb9b3663d82873ec"

-SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=git \
+SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=https;branch=master \
file://0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch \
"
SRCREV = "3ffb479929c31cbae09de08f94f58b8f0f061d91"
--
2.33.0


Re: Touchscreen not working if keyboard or mouse plugged in

Khem Raj
 

On Tue, Dec 7, 2021 at 2:07 PM Greg Wilson-Lindberg
<gwilson@...> wrote:

We are building yocto Zeus for the Raspberrypi 4. We are using a touchscreen on the system, and it works just fine. But if a keyboard or mouse is plugged in when the system boots then the touchscreen is disabled.



I am wondering if there is a configuration somewhere that can be set to allow both the touchscreen and an external keyboard at the same time?

I wonder if its some overlap in device tree overlays


I’m sorry if this is the wrong forum to ask this, please point me in the right direction if not.
perhaps you can open a github issue here
https://github.com/agherzan/meta-raspberrypi/issues


Regards,

Greg Wilson-Lindberg




Touchscreen not working if keyboard or mouse plugged in

Greg Wilson-Lindberg
 

We are building yocto Zeus for the Raspberrypi 4. We are using a touchscreen on the system, and it works just fine. But if a keyboard or mouse is plugged in when the system boots then the touchscreen is disabled.

 

I am wondering if there is a configuration somewhere that can be set to allow both the touchscreen and an external keyboard at the same time?

 

I’m sorry if this is the wrong forum to ask this, please point me in the right direction if not.

 

Regards,

Greg Wilson-Lindberg


Re: Help with Inclusive Language in OpenEmbedded/Yocto Project

Michael Opdenacker
 

Hi Jon,

On 12/7/21 2:01 AM, 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.

Definitely interested. I had already started contributing to
https://wiki.yoctoproject.org/wiki/Inclusive_language. Count me in.
Thanks
Michael.

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


Re: Is there any recipe for #frr

Khem Raj
 

check

https://layers.openembedded.org/layerindex/branch/master/recipes/

if its not there then perhaps no one published it yet.

On Mon, Dec 6, 2021 at 11:24 PM <mousavy.system2005@...> wrote:

Hi
There is an old discussion regarding this in this link:
https://lists.frrouting.org/pipermail/frog/2019-January/000445.html
But I can't find any updated one. Is there an updated recipe to build FRR?
Thanks


Re: ls command

Khem Raj
 

On Tue, Dec 7, 2021 at 1:45 AM <msabood2014@...> wrote:

Hi Guys i am new in YOCTO project. i have build images before and the images were included the "ls" and "clear" and all busybox commands. i do not know what happend now the image does not have anymore the "ls" or "clear" and all that commands and also there is a folder named && in the root directory ? What to do ?
Sorry if my question is stupid but i am just a new in Yocto and linux
try to see if /bin/ls exists. if its not there then maybe its deleted
somehow. best is to flash a new rootfs


Yocto Project Status WW49`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M1 is due to build this week
  • YP 3.4.1 is likely to be released this week
  • There were some changes to the yocto-check-layer script to verify more of the contents of README files which has led to improvements in a number of layer README files.
  • The Yocto Project Summit and OpenEmbedded Developer virtual meetings last week seemed successful, thanks to the organizers and presenters for their hard work and presentations and everyone who attended to make it a success.
  • We have continued to audit a number of the patches in OE-Core with the removal of quite a number of obsolete patches and a number being submitted to the appropriate upstreams. This will result in an improvement to the quality of the core layer and make general maintenance easier going forward. Any help, particularly from those with knowledge of specific areas or upstreams would be most welcome.
  • We continue to see a reduction in the number of patches in the “Pending” state. Many thanks to everyone who has taken the time to review patch status and handle accordingly, particularly where they were accepted upstream. This will significantly benefit the project in the long term.
  • Intermittent issues continue to rise and help is very much welcome on these issues. 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
  • SWAT handling of autobuilder issues has sadly not been functioning correctly for the last couple of weeks with a large backlog of untriaged issues.

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 build date 2021/12/06
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.12 is released
  • YP 3.4.1 is out of QA.
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • 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@...

 


Re: Setting BUILDNAME to a string broke in 3.1.12

Steve Sakoman
 

On Tue, Dec 7, 2021 at 12:21 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi

On Tue, Dec 7, 2021 at 1:34 AM Richard Purdie
<richard.purdie@...> wrote:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
# Convert UTC into %4Y%2m%2d%2H%2M%2S
sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.
confirmed by commenting out the echo above that that "solves the
issue", so it's in fact this code that is now wrongfully triggered.
I think Richard was suggesting that you add
REPRODUCIBLE_TIMESTAMP_ROOTFS to "" to your local.conf.

I did so and confirmed that /etc/version now has BUILDNAME for its
contents as expected.

Richard is correct that the patch was setting
REPRODUCIBLE_TIMESTAMP_ROOTFS incidentally. This part of Mark's patch
seems to be the cause:

-inherit ${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') ==
'1', 'reproducible_build_simple', '')}
+inherit reproducible_build_simple

And reproducible_build_simple does:

BUILD_REPRODUCIBLE_BINARIES = "1"

export PYTHONHASHSEED = "0"
export PERL_HASH_SEED = "0"
export SOURCE_DATE_EPOCH ??= "1520598896"

REPRODUCIBLE_TIMESTAMP_ROOTFS ??= "1520598896"

So it is now overwriting what you've set in local.conf for
BUILD_REPRODUCIBLE_BINARIES. And if you look at your rootfs, you'll
probably see that all of the files are dated March 2019.

Master branch has restructured the code, but retained this behavior.

I'm not sure what the right answer is for dealing with the BUILDNAME
issue. Richard and Mark understand the reproducible build code far
better than I, perhaps they can offer an opinion on what to do here.

Steve

2301 - 2320 of 57778