Date   

Re: Warning message after building recipe:

Quentin Schulz
 

Hi Pavan,

On Fri, Nov 22, 2019 at 09:38:05PM +0800, pavan wrote:
Hi All,

After building the recipe, I'm getting warning message:
"Warning: do_package_qa QA Issue: <recipe-dbg>: found library in wrong
location.
Any suggestion to resolve this issue?
Hopefully explained well enough here:
https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-libdir

Regards,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.schulz@..., www.streamunlimited.com


repost: how to create a SPDX "notice file" from a build?

Robert P. J. Day
 

i asked about this a couple months ago but didn't see any replies,
so i'll ask again with a little more detail.

colleague wants to, from YP (actually petalinux but should be
irrelevant), some sort of SPDX "notice file", along the lines of what
can be generated by black duck. it doesn't need to be identical, but
it would be useful to at least have a first pass that people can look
at and say what they want tweaked.

is there an example of how to (using the spdx.bbclass class file, i
assume) do something like this? thanks.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Coreutils missing in Yocto 2.6.3 sdk

Alessio Moscatello
 

Hello,
probably coreutils package isnot explicitly installed in the SDK.

You can add packages to the SDK using two variables:

BR,

Alessio


Warning message after building recipe:

pavan
 

Hi All,

After building the recipe, I'm getting warning message: 
"Warning: do_package_qa QA Issue: <recipe-dbg>: found library in wrong location.
Any suggestion to resolve this issue?


Regards,
Pavan


Regarding esdk build error error

kamal pandey
 

Hi,

I tried building extended SDK using the command $bitbake  <custom-core-image>  -c populate_sdk_ext,  but got errors which are as follows:

 

ERROR: Task xilinx-r5-bsp.do_fetch attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_prepare_recipe_sysroot attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_unpack attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_patch attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_create_yaml attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_configure attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_compile attempted to execute unexpectedly

ERROR: Task layer-r5-firmware.do_fetch attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_deploy attempted to execute unexpectedly and should have been setscened

ERROR: Task layer-r5-firmware.do_unpack attempted to execute unexpectedly

ERROR: Task layer-r5-firmware.do_patch attempted to execute unexpectedly

ERROR: Task xilinx-r5-bsp.do_populate_sysroot attempted to execute unexpectedly and should have been setscened

ERROR: Task layer-r5-firmware.do_prepare_recipe_sysroot attempted to execute unexpectedly

ERROR: Task layer-r5-firmware.do_configure attempted to execute unexpectedly

ERROR: Task layer-r5-firmware.do_compile attempted to execute unexpectedly

ERROR: Task layer-r5-firmware.do_deploy attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-r5-bsp.do_package attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-bootbin.do_prepare_recipe_sysroot attempted to execute unexpectedly

ERROR: Task xilinx-bootbin.do_configure attempted to execute unexpectedly

ERROR: Task xilinx-bootbin.do_compile attempted to execute unexpectedly

ERROR: Task xilinx-bootbin.do_install attempted to execute unexpectedly

ERROR: Task xilinx-bootbin.do_package attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-r5-bsp.do_packagedata attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-bootbin.do_packagedata attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-r5-bsp.do_package_write_rpm attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-bootbin.do_populate_sysroot attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-bootbin.do_deploy attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-bootbin.do_package_qa attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-r5-bsp.do_package_qa attempted to execute unexpectedly and should have been setscened

ERROR: Task xilinx-bootbin.do_package_write_rpm attempted to execute unexpectedly and should have been setscened

ERROR: Task layer-r5-firmware.do_populate_sysroot attempted to execute unexpectedly and should have been setscened

NOTE: Tasks Summary: Attempted 6604 tasks of which 6604 didn't need to be rerun and all succeeded.

 

Summary: There was 1 WARNING message shown.

Summary: There were 31 ERROR messages shown, returning a non-zero exit code.

----------

 

NOTE: "attempted to execute unexpectedly and should have been setscened" errors indicate this may be caused by missing sstate artifacts that were likely produced in earlier builds, but have been subsequently deleted for some reason.

 

ERROR: core-image-special-custom3-1.0-r0 do_populate_sdk_ext: Function failed: copy_buildsystem

ERROR: Logfile of failure stored in: /home/iepl007/yocto_build/build_dir/tmp/work/custom3_zynqmp-custom3-linux/core-image-special-custom3/1.0-r0/temp/log.do_populate_sdk_ext.31041

ERROR: Task (/home/iepl007/yocto_build/poky/../meta-custom3-dev/meta-layer-custom3/recipes-core/images/core-image-special-custom3.bb:do_populate_sdk_ext) failed with exit code '1'

 

Please suggest me how to fix this issue. Also if I want to make a sdk from the beginning i.e cleaning previous build and creating new one. What steps do I need to follow.

I am seeing the sstate-cache entries for above mentioned packages. How come it is not picking them.

 

Thanks and regards

Kamal Pandey

 

 


Coreutils missing in Yocto 2.6.3 sdk

Agnes Amreetha Joseph Arulraj
 

Hi,

 

We are working on Yocto 2.6.3. We are generating the sdk using “bitbake core-image-sato-sdk -c populate_sdk”.

After installation of sdk, we observed, usr/bin/*.coreutils are not available.

However, in the build directory, rpm’s are generated in deploy-rpms. And coreutils are present there, but they are not shipped into the sdk.

 

Could you guide us in this ASAP. This will help us in proceeding.

 

Thanks & Regards,

J. Agnes Amreetha

 

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.


Re: is there a rationale for YP using sysvinit as default init manager?

Josef Holzmayr <holzmayr@...>
 

On Thu, Nov 21, 2019 at 10:35:39PM +0100, Alexander Kanavin wrote:
On Thu, 21 Nov 2019 at 22:18, Richard Purdie <
richard.purdie@...> wrote:

We got so far and after looking at the position we ended up I decided
it was easier to switch poky-altcfg rather than change poky and/or OE
defaults. I resolved that bug as "complete" as we now had testing of
systemd on a near enough equal footing to sysvinit which was the
concern people had raised. There are problems in oe-selftest and some
other corner cases but nothing people seem to be running into day-to-
day.
It is also quite amazing that the project, by design, has entirely
sidestepped the divisive init system wars that have been gripping the
mainstream linux distros for years (and still are). I'd say it hardly
matters what the default is, if the other options are well supported.

Alex
Thats my take as well. By sysv being the default andsystemd being
massively used we almost automatically end up with good testing of both.

Greetz

--
———————————————
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


[meta-selinux][warrior][PATCH 2/2] refpolicy: fix labels for busybox init.sysvinit and start_getty

Yi Zhao
 

Fix busybox directory aliases issue.
Set correct labels for /sbin/init.sysvinit and /bin/start_getty.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
...bs_dist-fix-busybox-directory-aliase.patch | 32 +++++++++++++++++++
...fc-set-correct-label-for-start_getty.patch | 32 +++++++++++++++++++
...-set-correct-label-for-init.sysvinit.patch | 29 +++++++++++++++++
...bs_dist-fix-busybox-directory-aliase.patch | 32 +++++++++++++++++++
...fc-set-correct-label-for-start_getty.patch | 32 +++++++++++++++++++
...-set-correct-label-for-init.sysvinit.patch | 29 +++++++++++++++++
.../refpolicy/refpolicy_common.inc | 3 ++
7 files changed, 189 insertions(+)
create mode 100644 recipes-security/refpolicy/refpolicy-2.20190201/file_contexts.subs_dist-fix-busybox-directory-aliase.patch
create mode 100644 recipes-security/refpolicy/refpolicy-2.20190201/getty.fc-set-correct-label-for-start_getty.patch
create mode 100644 recipes-security/refpolicy/refpolicy-2.20190201/init.fc-set-correct-label-for-init.sysvinit.patch
create mode 100644 recipes-security/refpolicy/refpolicy-git/file_contexts.subs_dist-fix-busybox-directory-aliase.patch
create mode 100644 recipes-security/refpolicy/refpolicy-git/getty.fc-set-correct-label-for-start_getty.patch
create mode 100644 recipes-security/refpolicy/refpolicy-git/init.fc-set-correct-label-for-init.sysvinit.patch

diff --git a/recipes-security/refpolicy/refpolicy-2.20190201/file_contexts.subs_dist-fix-busybox-directory-aliase.patch b/recipes-security/refpolicy/refpolicy-2.20190201/file_contexts.subs_dist-fix-busybox-directory-aliase.patch
new file mode 100644
index 0000000..9fe2548
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20190201/file_contexts.subs_dist-fix-busybox-directory-aliase.patch
@@ -0,0 +1,32 @@
+From 24c0c6a35c13c6156dfa385cf22a130b6893f24a Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@...>
+Date: Fri, 22 Nov 2019 14:01:08 +0800
+Subject: [PATCH] file_contexts.subs_dist: fix busybox directory aliases
+
+The /usr/bin and /usr/sbin are the original paths which configured in
+file contextes.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ config/file_contexts.subs_dist | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/config/file_contexts.subs_dist b/config/file_contexts.subs_dist
+index 04fca3c..c720871 100644
+--- a/config/file_contexts.subs_dist
++++ b/config/file_contexts.subs_dist
+@@ -44,7 +44,7 @@
+
+ # busybox aliases
+ # quickly match up the busybox built-in tree to the base filesystem tree
+-/usr/lib/busybox/bin /bin
+-/usr/lib/busybox/sbin /sbin
++/usr/lib/busybox/bin /usr/bin
++/usr/lib/busybox/sbin /usr/sbin
+ /usr/lib/busybox/usr /usr
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy-2.20190201/getty.fc-set-correct-label-for-start_getty.patch b/recipes-security/refpolicy/refpolicy-2.20190201/getty.fc-set-correct-label-for-start_getty.patch
new file mode 100644
index 0000000..35e8eed
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20190201/getty.fc-set-correct-label-for-start_getty.patch
@@ -0,0 +1,32 @@
+From 83ba87de0b5163cd7f3db8ef0a1f10f89240afa6 Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@...>
+Date: Fri, 22 Nov 2019 14:12:55 +0800
+Subject: [PATCH] getty.fc: set correct label for start_getty
+
+The start_getty label should be set to bin_t not getty_exec_t.
+
+Fix error:
+setsid: failed to execute /sbin/getty: Permission denied
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ policy/modules/system/getty.fc | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/system/getty.fc b/policy/modules/system/getty.fc
+index 116ea64..53ff613 100644
+--- a/policy/modules/system/getty.fc
++++ b/policy/modules/system/getty.fc
+@@ -4,6 +4,7 @@
+ /run/agetty\.reload -- gen_context(system_u:object_r:getty_runtime_t,s0)
+
+ /usr/bin/.*getty -- gen_context(system_u:object_r:getty_exec_t,s0)
++/usr/bin/start_getty -- gen_context(system_u:object_r:bin_t,s0)
+
+ /usr/sbin/.*getty -- gen_context(system_u:object_r:getty_exec_t,s0)
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy-2.20190201/init.fc-set-correct-label-for-init.sysvinit.patch b/recipes-security/refpolicy/refpolicy-2.20190201/init.fc-set-correct-label-for-init.sysvinit.patch
new file mode 100644
index 0000000..0f024c6
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-2.20190201/init.fc-set-correct-label-for-init.sysvinit.patch
@@ -0,0 +1,29 @@
+From 99f1d3d2caf1281ee922ce2c8e93fb53fea576a2 Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@...>
+Date: Fri, 22 Nov 2019 14:09:44 +0800
+Subject: [PATCH] init.fc: set correct label for init.sysvinit
+
+The /sbin/init.sysvinit should be set the label init_exec_t.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ policy/modules/system/init.fc | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/system/init.fc b/policy/modules/system/init.fc
+index 11a6ce9..3c063b1 100644
+--- a/policy/modules/system/init.fc
++++ b/policy/modules/system/init.fc
+@@ -40,6 +40,7 @@ ifdef(`distro_gentoo',`
+ /usr/libexec/dcc/stop-.* -- gen_context(system_u:object_r:initrc_exec_t,s0)
+
+ /usr/sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
++/usr/sbin/init\.sysvinit -- gen_context(system_u:object_r:init_exec_t,s0)
+ /usr/sbin/open_init_pty -- gen_context(system_u:object_r:initrc_exec_t,s0)
+ /usr/sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy-git/file_contexts.subs_dist-fix-busybox-directory-aliase.patch b/recipes-security/refpolicy/refpolicy-git/file_contexts.subs_dist-fix-busybox-directory-aliase.patch
new file mode 100644
index 0000000..9fe2548
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-git/file_contexts.subs_dist-fix-busybox-directory-aliase.patch
@@ -0,0 +1,32 @@
+From 24c0c6a35c13c6156dfa385cf22a130b6893f24a Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@...>
+Date: Fri, 22 Nov 2019 14:01:08 +0800
+Subject: [PATCH] file_contexts.subs_dist: fix busybox directory aliases
+
+The /usr/bin and /usr/sbin are the original paths which configured in
+file contextes.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ config/file_contexts.subs_dist | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/config/file_contexts.subs_dist b/config/file_contexts.subs_dist
+index 04fca3c..c720871 100644
+--- a/config/file_contexts.subs_dist
++++ b/config/file_contexts.subs_dist
+@@ -44,7 +44,7 @@
+
+ # busybox aliases
+ # quickly match up the busybox built-in tree to the base filesystem tree
+-/usr/lib/busybox/bin /bin
+-/usr/lib/busybox/sbin /sbin
++/usr/lib/busybox/bin /usr/bin
++/usr/lib/busybox/sbin /usr/sbin
+ /usr/lib/busybox/usr /usr
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy-git/getty.fc-set-correct-label-for-start_getty.patch b/recipes-security/refpolicy/refpolicy-git/getty.fc-set-correct-label-for-start_getty.patch
new file mode 100644
index 0000000..35e8eed
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-git/getty.fc-set-correct-label-for-start_getty.patch
@@ -0,0 +1,32 @@
+From 83ba87de0b5163cd7f3db8ef0a1f10f89240afa6 Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@...>
+Date: Fri, 22 Nov 2019 14:12:55 +0800
+Subject: [PATCH] getty.fc: set correct label for start_getty
+
+The start_getty label should be set to bin_t not getty_exec_t.
+
+Fix error:
+setsid: failed to execute /sbin/getty: Permission denied
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ policy/modules/system/getty.fc | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/system/getty.fc b/policy/modules/system/getty.fc
+index 116ea64..53ff613 100644
+--- a/policy/modules/system/getty.fc
++++ b/policy/modules/system/getty.fc
+@@ -4,6 +4,7 @@
+ /run/agetty\.reload -- gen_context(system_u:object_r:getty_runtime_t,s0)
+
+ /usr/bin/.*getty -- gen_context(system_u:object_r:getty_exec_t,s0)
++/usr/bin/start_getty -- gen_context(system_u:object_r:bin_t,s0)
+
+ /usr/sbin/.*getty -- gen_context(system_u:object_r:getty_exec_t,s0)
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy-git/init.fc-set-correct-label-for-init.sysvinit.patch b/recipes-security/refpolicy/refpolicy-git/init.fc-set-correct-label-for-init.sysvinit.patch
new file mode 100644
index 0000000..0f024c6
--- /dev/null
+++ b/recipes-security/refpolicy/refpolicy-git/init.fc-set-correct-label-for-init.sysvinit.patch
@@ -0,0 +1,29 @@
+From 99f1d3d2caf1281ee922ce2c8e93fb53fea576a2 Mon Sep 17 00:00:00 2001
+From: Yi Zhao <yi.zhao@...>
+Date: Fri, 22 Nov 2019 14:09:44 +0800
+Subject: [PATCH] init.fc: set correct label for init.sysvinit
+
+The /sbin/init.sysvinit should be set the label init_exec_t.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao <yi.zhao@...>
+---
+ policy/modules/system/init.fc | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/system/init.fc b/policy/modules/system/init.fc
+index 11a6ce9..3c063b1 100644
+--- a/policy/modules/system/init.fc
++++ b/policy/modules/system/init.fc
+@@ -40,6 +40,7 @@ ifdef(`distro_gentoo',`
+ /usr/libexec/dcc/stop-.* -- gen_context(system_u:object_r:initrc_exec_t,s0)
+
+ /usr/sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
++/usr/sbin/init\.sysvinit -- gen_context(system_u:object_r:init_exec_t,s0)
+ /usr/sbin/open_init_pty -- gen_context(system_u:object_r:initrc_exec_t,s0)
+ /usr/sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
+
+--
+2.7.4
+
diff --git a/recipes-security/refpolicy/refpolicy_common.inc b/recipes-security/refpolicy/refpolicy_common.inc
index 137ccee..e567f78 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -52,6 +52,9 @@ SRC_URI += " \
file://0032-policy-module-init-update-for-systemd-related-allow-.patch \
file://0033-refpolicy-minimum-make-sysadmin-module-optional.patch \
file://0034-policy-module-apache-add-rules-for-the-symlink-of-va.patch \
+ file://file_contexts.subs_dist-fix-busybox-directory-aliase.patch \
+ file://init.fc-set-correct-label-for-init.sysvinit.patch \
+ file://getty.fc-set-correct-label-for-start_getty.patch \
"

S = "${WORKDIR}/refpolicy"
--
2.17.1


[meta-selinux][warrior][PATCH 1/2] Revert "mesa: switch to meson build"

Yi Zhao
 

This reverts commit 184857a52ecc9b7088021d7362c7d85e1c3551d6.

The mesa hasn't switched to meson build in this branch.

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-graphics/mesa/mesa_%.bbappend | 2 +-
recipes-graphics/mesa/mesa_selinux.inc | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
create mode 100644 recipes-graphics/mesa/mesa_selinux.inc

diff --git a/recipes-graphics/mesa/mesa_%.bbappend b/recipes-graphics/mesa/mesa_%.bbappend
index 02c4918..b0b03ec 100644
--- a/recipes-graphics/mesa/mesa_%.bbappend
+++ b/recipes-graphics/mesa/mesa_%.bbappend
@@ -1,2 +1,2 @@
-inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'meson-selinux', '', d)}
+require ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', '${BPN}_selinux.inc', '', d)}

diff --git a/recipes-graphics/mesa/mesa_selinux.inc b/recipes-graphics/mesa/mesa_selinux.inc
new file mode 100644
index 0000000..0004f71
--- /dev/null
+++ b/recipes-graphics/mesa/mesa_selinux.inc
@@ -0,0 +1,6 @@
+inherit enable-selinux
+
+# But wait! There's more! mesa builds a host program named builtin_compiler
+# and it needs selinux, too. We replace the PACKAGECONFIG[] in the bbclass.
+#
+PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux libselinux-native,"
--
2.17.1


Re: busybox + SELinux (warrior) - reboot issue

Yi Zhao
 

Hi Yair,


On 11/14/19 2:06 AM, Yair Itzhaki wrote:

Hi ,

I'm using Poky (Warrior), with busybox (aiming at a lightweight system).

Recently, added SELinux to my project (by adding "packagegroup-core-selinux" to my local.conf, with mls policy).

 

Booted with "selinux=1 enforing=0".

The auto-relabeling reported an error, since the root is mounted RO.

So, patched slelinux-autorelabel script to mount "/" RW before relabeling.

Booted again.

This time, selinux-init had the same issue ( / mounted RO).

Patched this one as well, but the system keeps rebooting:

It seems that the init process keeps it's kernel_t context, which forces re-labeling, reboot and so on…. (per the selinux-init script)

 

Q1: Is SELinux+busybox a valid combination, or should I switch to systemd?

SElinux+busybox should work. But there are some security label issues with busybox.

I attached a fix. You can try it.


Q2: Which context should the init process end up as?

This is because /sbin/init.sysvinit doesn't set the correct label. Please also see the attachment. I will send the formal patch later.


 

BTW – the build of "core-image-selinux" fails, with the following error

   Copying files into the device: set_inode_xattr: No data available while reading attribute "security.selinux" of "network"

I didn't encountered this issue. Please make sure the setting DISTRO_FEATURES_append = " acl xattr pam selinux" is in your conf/local.conf


//Yi


Any idea?

 

Thanks,

Yair

 

 



Re: Mailing list platform change November 21st

Michael Halstead
 

The migration is complete. Please update your address books to point to the new list e-mail addresses. There are rewrites in place so the previous mailing list addresses will continue to work for a limited time. I am sending this message to the old addresses to test that functionality. In the next few days we will have redirects for the old pipermail archives to keep links working. We are also in the process of setting up https://public-inbox.org/README.html for users who would like to retrieve list mail using git. Lists and archives are currently accessible via the links at https://www.yoctoproject.org/community/mailing-lists/.

If you are currently a member of any list your account is already created. Visit https://lists.yoctoproject.org/sendloginlink and enter the e-mail you receive list mail at to receive a login link and set a password.

If you have questions please visit https://wiki.yoctoproject.org/wiki/index.php?title=GroupsMigration to see if they have been answered. E-mail pointofcontact@... with new questions.

--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


On Wed, Nov 20, 2019 at 11:23 PM Michael Halstead <mhalstead@...> wrote:
The window for the mailing list move has shifted forward to November 21st from 4pm to 8pm Pacific Standard Time. (2019-11-22 00:00-04:00 UTC)

Moderators please tend to all pending requests today.

Thank you,
--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

On Fri, Nov 15, 2019 at 4:25 PM Michael Halstead <mhalstead@...> wrote:
After backing out of the first attempt to migrate we are again moving
our lists from Mailman to Groups.io. E-mail to lists will be delayed
during the move window on November 21st between 17:00 and 23:00 UTC.

A new account will be created for you on the Groups.io platform and most
users will only need to update their list mailing address from the
@yoctoproject.org to @lists.yoctoproject.org.

Moderators please attend to all pending requests next Wednesday November
20th.

Please read more about the change on the wiki:

https://wiki.yoctoproject.org/wiki/index.php?title=GroupsMigration

If there are serious issues we will rollback the changes. We will e-mail
all lists when work is complete.

--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


Re: is there a rationale for YP using sysvinit as default init manager?

Alexander Kanavin
 

On Thu, 21 Nov 2019 at 22:18, Richard Purdie <richard.purdie@...> wrote:
We got so far and after looking at the position we ended up I decided
it was easier to switch poky-altcfg rather than change poky and/or OE
defaults. I resolved that bug as "complete" as we now had testing of
systemd on a near enough equal footing to sysvinit which was the
concern people had raised. There are problems in oe-selftest and some
other corner cases but nothing people seem to be running into day-to-
day.

It is also quite amazing that the project, by design, has entirely sidestepped the divisive init system wars that have been gripping the mainstream linux distros for years (and still are). I'd say it hardly matters what the default is, if the other options are well supported.

Alex


Re: is there a rationale for YP using sysvinit as default init manager?

Richard Purdie
 

On Fri, 2019-11-22 at 10:08 +1300, Paul Eggleton wrote:
On Friday, 22 November 2019 9:40:35 AM NZDT Richard Purdie wrote:
On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
don't get me wrong, i have no problem with that, but a
colleague
asked me what the reason was for using sysvinit as the *default*.
i
hemmed and hawed and suggested it was for simplicity and
reliability,
and that a lot of embedded systems didn't need the flashy
features of
systemd, and so on.

is there any short answer to give to that question?
The project existed before systemd and we haven't changed the
default.

We can change the default, it just means someone going through and
fixing the build failures it generates and rewriting all the test
metadata to invert poky and poky-altcfg. Personally I've got other
things I'd prefer to do...
Kai was working on changing this in the last cycle but AFAICT not all
issues were able to be resolved in time. Kai, do you have a status
update?
We got so far and after looking at the position we ended up I decided
it was easier to switch poky-altcfg rather than change poky and/or OE
defaults. I resolved that bug as "complete" as we now had testing of
systemd on a near enough equal footing to sysvinit which was the
concern people had raised. There are problems in oe-selftest and some
other corner cases but nothing people seem to be running into day-to-
day.

There has been representation at OE meetings, in surveys and from YP
members for us not to switch the default FWIW.

Cheers,

Richard


OpenEmbedded Workshop at FOSDEM20 CFP

Jon Mason
 

We are proud to announce the inaugural OpenEmbedded Workshop. It is
being held on 03 February 2020 in Brussels, Belgium. The day after
FOSDEM.

The Call for Participation is open now. For more information, go to
https://pretalx.com/oe-workshop-2020/cfp

Early-bird tickets coming soon!

Thank you,
The OpenEmbedded Board


Re: is there a rationale for YP using sysvinit as default init manager?

Paul Eggleton
 

On Friday, 22 November 2019 9:40:35 AM NZDT Richard Purdie wrote:
On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
don't get me wrong, i have no problem with that, but a colleague
asked me what the reason was for using sysvinit as the *default*. i
hemmed and hawed and suggested it was for simplicity and reliability,
and that a lot of embedded systems didn't need the flashy features of
systemd, and so on.

is there any short answer to give to that question?
The project existed before systemd and we haven't changed the default.

We can change the default, it just means someone going through and
fixing the build failures it generates and rewriting all the test
metadata to invert poky and poky-altcfg. Personally I've got other
things I'd prefer to do...
Kai was working on changing this in the last cycle but AFAICT not all issues
were able to be resolved in time. Kai, do you have a status update?

Thanks
Paul

--

Paul Eggleton
Intel System Software Products


Re: is there a rationale for YP using sysvinit as default init manager?

Richard Purdie
 

On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
don't get me wrong, i have no problem with that, but a colleague
asked me what the reason was for using sysvinit as the *default*. i
hemmed and hawed and suggested it was for simplicity and reliability,
and that a lot of embedded systems didn't need the flashy features of
systemd, and so on.

is there any short answer to give to that question?
The project existed before systemd and we haven't changed the default.

We can change the default, it just means someone going through and
fixing the build failures it generates and rewriting all the test
metadata to invert poky and poky-altcfg. Personally I've got other
things I'd prefer to do...

Cheers,

Richard


Re: populate_sdk with my image

Mark Hatle
 

On 11/21/19 12:00 PM, Mauro Ziliani wrote:
Thanks.

This is true for a Krogoth based project?
Same class, slightly different semantics. I don't believe src-pkgs existed yet
at that point, but dev-pkgs would have.

You will have to investigate the class for the parameters.. but general behavior
is the same.

--Mark

Il 21/11/19 17:40, Mark Hatle ha scritto:
populate_sdk uses the same configuration as the regular image, as well as adding
"dev-pkgs dbg-pkgs src-pkgs" and optionally doc-pkgs.

See:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass

Lines 3-11, and 22.

If dev-pkgs/src-pkgs isn't inclyding your Qt/Qml development components, then
they may not be packaged properly.

The way dev-pkgs works (like 5) is by taking a list of each package installed in
the system and then trying to add '-dev' to it, and then install that. (Roughly)

--Mark


On 11/21/19 10:31 AM, Mauro Ziliani wrote:
Hi all.

I have a recipe for my image with depends from Qt/Qml recipes

When I do

bitbake -c populate_sdk myimage.bb


the sdk doesn't contains the dev version of the Qt/Qml libraries installed in
the final image


I managing the bitbake variables  TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK
adding manually the dependecies.


There is an automatic way to do that?


M


is there a rationale for YP using sysvinit as default init manager?

Robert P. J. Day
 

don't get me wrong, i have no problem with that, but a colleague
asked me what the reason was for using sysvinit as the *default*. i
hemmed and hawed and suggested it was for simplicity and reliability,
and that a lot of embedded systems didn't need the flashy features of
systemd, and so on.

is there any short answer to give to that question?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: populate_sdk with my image

Mauro Ziliani
 

Thanks.

This is true for a Krogoth based project?

Il 21/11/19 17:40, Mark Hatle ha scritto:

populate_sdk uses the same configuration as the regular image, as well as adding
"dev-pkgs dbg-pkgs src-pkgs" and optionally doc-pkgs.

See:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass

Lines 3-11, and 22.

If dev-pkgs/src-pkgs isn't inclyding your Qt/Qml development components, then
they may not be packaged properly.

The way dev-pkgs works (like 5) is by taking a list of each package installed in
the system and then trying to add '-dev' to it, and then install that.  (Roughly)

--Mark


On 11/21/19 10:31 AM, Mauro Ziliani wrote:
Hi all.

I have a recipe for my image with depends from Qt/Qml recipes

When I do

bitbake -c populate_sdk myimage.bb


the sdk doesn't contains the dev version of the Qt/Qml libraries installed in
the final image


I managing the bitbake variables  TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK
adding manually the dependecies.


There is an automatic way to do that?


M



Re: populate_sdk with my image

Mark Hatle
 

populate_sdk uses the same configuration as the regular image, as well as adding
"dev-pkgs dbg-pkgs src-pkgs" and optionally doc-pkgs.

See:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/populate_sdk_base.bbclass

Lines 3-11, and 22.

If dev-pkgs/src-pkgs isn't inclyding your Qt/Qml development components, then
they may not be packaged properly.

The way dev-pkgs works (like 5) is by taking a list of each package installed in
the system and then trying to add '-dev' to it, and then install that. (Roughly)

--Mark

On 11/21/19 10:31 AM, Mauro Ziliani wrote:
Hi all.

I have a recipe for my image with depends from Qt/Qml recipes

When I do

bitbake -c populate_sdk myimage.bb


the sdk doesn't contains the dev version of the Qt/Qml libraries installed in
the final image


I managing the bitbake variables  TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK
adding manually the dependecies.


There is an automatic way to do that?


M

10421 - 10440 of 57804